Re: [patch 0/8] Nesting class_device patches that actually work

[Adam Belay <ambx1@neo.rr.com>]

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...)
> 
> 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.
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.

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.

Thanks,
Adam
-
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/