Messages in this thread | | | Date | Tue, 18 Oct 2005 01:44:00 +0200 | From | Kay Sievers <> | Subject | Re: [patch 0/8] Nesting class_device patches that actually work |
| |
On Mon, Oct 17, 2005 at 07:24:30PM -0400, Adam Belay wrote: > On Mon, Oct 17, 2005 at 02:44:30PM -0700, Greg KH wrote: > > On Sat, Oct 15, 2005 at 05:08:55PM +0200, Kay Sievers wrote: > > > A lot! From general distro specific system-management to subsystem specific > > > setup tools and tons of udev rules... There is definitely no chance to break > > > /sys/class in _all_ subsystems by introducing subdirectories. > > > > I agree. > > > > > > Btw, is your proposal with moving it all into /sys/device less drastic? > > > > > > Definitely, cause it keeps all the curent api! The only difference is that class-devices > > > are reached by symlinks instead of real directories. The pathes to the devices are > > > the same! > > > > Ok, I've spent a while thinking about this proposal and originally I > > thought it was the same thing we had heard years ago. But I was wrong, > > moving the class stuff into the device tree is the right thing to do, as > > long as we keep them as new "things" in the tree (previous proposals > > just had the /sys/class stuff as symlinks pointing to the devices > > themselves, which would not work for a range of reasons.) > > > > So, what to do now? Here's my proposal for the future. > > > > We figure out some way to agree on the input stuff, using class_device > > and get that into 2.6.15. Personally, I like the stuff I just did and > > is in the -mm tree :) > > > > But, if you think we can't break userspace by adding nested class > > devices just yet, I agree, and can probably just put a symlink in > > /sys/class/input to the nested devices, which will make everything "just > > work". I'll try that out later tonight and let you all know how it > > goes. > > > > Then, we move the class stuff into real devices. There was always a lot > > of duplication with the class and device code, and this shows that there > > is a commonality there. At the same time, I'll work on making the > > attribute stuff easier and possibly merge the kobject and device > > structures together a bit (possibly I said, I don't know quite how much > > yet...)
Yeah, would be nice if we can share the attribute define/create/grouping stuff over all devices. Currently we have device/class/block attribute management which are all do almost the same.
> > But this second step is going to take a while, have to not break > > everything along the way, and should hopefully clean up a lot of mess > > tht the current driver core has. I'd be glad to do it :) > > > > Acceptable to everyone? > > Sounds good to me. The changes to driver model internals may be substantial.
Sounds very good to me too. :) I like to see the "dynamic input" as soon as possible in the tree, as I'm waiting for more than a year now to get rid of the old stuff in udev only kept there for "input". :)
/sys/class/input/ and /sys/class/input_device/ and a matching SUBSYSTEM value would be the easiest for userspace without much breakage involved. That would give us a /sbin/hotplug-fork free driver core and we can start rearranging stuff.
> 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.
We should try this, it feels like "buses" can easily become "classes", like the SUBSYSTEM value already looks these days. We'll see...
> It also may make sense to move bus_types to the "class" interface. The > layered classes suggestion is especially useful here because we can have a > "hardware" or "bus" class that acts as a parent for "pci", "usb", etc. > > Also, we could make driver objects a "class" and represent them in the > global device tree, giving each driver instance its own unique namespace. > > > > > 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. If the device doesn't have any parents > or dependencies, then that's logically where it belongs.
We do the same in HAL every unconnected object just lives in the root of the device tree.
Thanks, Kay - 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/
| |