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

From: Greg KH
Date: Tue Oct 18 2005 - 02:35:55 EST


On Tue, Oct 18, 2005 at 12:05:15AM -0700, Greg KH wrote:
> On Mon, Oct 17, 2005 at 11:04:35PM -0700, Greg KH wrote:
> > On Mon, Oct 17, 2005 at 02:44:30PM -0700, Greg KH wrote:
> > > 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.
> >
> > Below is a patch that does this for the event portion of input. Good
> > news is that the symlink shows up just fine in sysfs. Bad news is that
> > even with your previously posted patch, udev dies a horrible death.
> >
> > And udev dies today with the nested stuff too, so that's not good
> > either.
>
> Nevermind, that was due to the kernel oops, not udev.
>
> Kay, your original udev patch works just fine. What I don't see is why
> the existing udev release doesn't also work, now that I have the
> symlinks set up. I'll try to figure that one out too...

Bleah, here's a one character patch to the current udev that makes
udevstart work properly with my symlink patch.

diff --git a/udevstart.c b/udevstart.c
index ce96f38..ce72b82 100644
--- a/udevstart.c
+++ b/udevstart.c
@@ -131,7 +131,7 @@ static int add_device(const char *devpat
setenv("UDEV_RUN", udev_run_str, 1);
dbg("add '%s'", devpath);

- snprintf(path, sizeof(path), "%s%s", sysfs_path, devpath);
+ snprintf(path, sizeof(path), "%s%s/", sysfs_path, devpath);
path[sizeof(path)-1] = '\0';
class_dev = sysfs_open_class_device_path(path);
if (class_dev == NULL) {

So, any way we do it, users are going to have to upgrade udev to get
things to work properly.

But I guess we should use the symlink patch in the kernel too, just to
keep any other tools that don't have this kind of bug in them working
properly...

Opinions?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/