lkml.org 
[lkml]   [2005]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-10-18 01:47    [W:0.111 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site