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

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, Oct 17, 2005 at 07:26:55PM -0400, Adam Belay wrote:
> On Mon, Oct 17, 2005 at 04:54:52PM -0500, Dmitry Torokhov wrote:
> > On 10/17/05, Greg KH <gregkh@suse.de> wrote:
> > > 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 :)
> > >
> > 
> > If we are shooting at 2.6.15 I would just go with original 2-class
> > solution (input and input_dev) with doing symlinks in form of
> > /sys/class/input/mouseX/device -> /sys/class/input_dev/inputX
> > 
> > Correct me if I am wrong but this is least invasive and (at least for
> > older hotplug installations) all that is needed to make it work is a
> > symlink from input.agent to input_dev.agent.

Yes, it is almost compatible with the "old" hotplug. On modern setups
it is just one udev rule to catch the right event. On older setups a
simple symlink should work, yes.

> I'm not sure if we want to introduce an incorrect change to the sysfs
> topology only to remove it in the next release.  Currently, class devices
> are not expected to link between one another.

The easiest would be to leave the "device"-link in its current state:
  mouse0 -> ../../../devices/...
and correct that later by getting completely rid of _all_ "device" links
with the move of the device object to /sys/devices/ (the DEVPATH for
"mouse0" will then contain the _complete_ hierarchy including "input0").

Current userspace is not aware to follow two "device" links. Should not be
hard to implement, but seems not really worth the effort, if we plan to
rearrange it to a global device tree anyway.

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/