Messages in this thread | | | Date | Thu, 13 Feb 2003 13:19:54 -0600 (CST) | From | Patrick Mochel <> | Subject | Re: [PATCH][RFC] Proposal for a new watchdog interface using sysfs |
| |
On 13 Feb 2003, Rusty Lynch wrote:
> On Thu, 2003-02-13 at 11:07, Dave Jones wrote: > > On Thu, Feb 13, 2003 at 07:51:45AM -0800, Rusty Lynch wrote: > > > > > > You could regard them as 'system' devices, and have them show up in > > > > devices/sys/, which would make more sense than 'legacy'. > > > Ok, system device is the winner. > > > > Why? Stop for a second and look what we have in those dirs. > > They both contain things that are essentially motherboard resources. > > > > These are add-on cards we're talking about. Surely a more sensible > > place for them to live is somewhere under devices/pci0/ or whatever > > bus-type said card is for. > > > > Whilst there are some watchdogs which _are_ part of the motherboard > > chipset (which is arguably 'system'), these still show up in PCI > > space as regular PCI devices. > > > > Lumping them all into the same category as things like rtc, pic, > > fdd etc is just _wrong_. > > > > Dave > > > > The thing I would like to see is an easy way for a user space > application to see the available watchdog devices without searching > every possible bus type. If we had that one location to find all > watchdog devices, then each device could just be a symbolic link to the > device in it's real bus.
Create a watchdog timer class. That will contain all watchdog timers, no matter what bus they are on.
I apologize for leading you astray with suggesting you treat them as system devices; I was under the assumption they were more important. :) They should always be in the most accurate place in the tree. Don't worry about what the user sees; consistency and accuracy are more important..
-pat
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |