Messages in this thread | | | Date | Tue, 18 Oct 2005 10:41:57 -0500 | From | Dmitry Torokhov <> | Subject | Re: [patch 0/8] Nesting class_device patches that actually work |
| |
On 10/18/05, Kay Sievers <kay.sievers@vrfy.org> wrote: > On Tue, Oct 18, 2005 at 03:18:22AM -0400, Adam Belay wrote: > > On Mon, Oct 17, 2005 at 10:26:17PM -0700, Greg KH wrote: > > > On Mon, Oct 17, 2005 at 07:24:30PM -0400, Adam Belay wrote: > > > > > > > > Sounds good to me. The changes to driver model internals may be substantial. > > > > For example, because buses and classes will share more code, it's > > > > reasonable to allow drivers to bind to any "device" object, even class > > > > devices. Of course this would be limited to classes that choose to > > > > implement driver matching etc. We are doing this now with the pci express > > > > port driver. > > > > > > That's a bus, not a class device. Drivers bind to devices through a > > > bus. That's why we have busses. > > > > If class devices and devices belong in the same tree, then clearly the original > > distinction is artificial. "struct bus_type" is a class of "struct device". > > "struct class" is a class of "struct class_dev". We now know of devices > > in between these two extremes (e.g. pci express port driver). It's also > > possible that drivers will want to bind to class devices (e.g. a partition > > driver binding to a block device). Isn't it fair to say that the "bus_type" > > vs. "class" distinction is also artificial? At the very least they are > > duplicating some code. > > I agree and would like to see the "bus" functionality just as set of special > methods of a unified device struture also used for class devices. > > > > > > Oh, one tiny problem. "virtual devices" are not currently represented > > > > > in our device tree, but are in the class tree. Things like the > > > > > different vc and ttys and misc devices are examples of this. I'll just > > > > > put them on the "platform" bus if no one minds. > > > > > > > > I think we should be trying to kill off the platform bus (it's artifical and > > > > doesn't show the real relationships between these devices). Instead, just > > > > hang them off the root of the tree. > > > > > > Everything that's currently a platform device go to the root? No, > > > that's not going to happen, sorry. > > But will sticking stuff like "mice" or "tty" into "platform" will really > work? These devices belong to their own primary class like "input" or "tty" and > they can not be part of a "bus" at the same time, right? > > I'm dreaming of: > - merging "struct device" and "struct class_device" > > - provide current "bus" and "class" methodes for _all_ devices >
This way you are fattening object interface and I don't think it is a good thing. While we may want to have sysfs representation of all devices be in /sys/devices internally we should keep the interfaces and implementation clean and do not turn it into a kitchen sink.
-- Dmitry - 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/
| |