Messages in this thread | | | Subject | Re: [PATCH 2/2] uevent: handle duplicate uevent_var keys properly | From | Kay Sievers <> | Date | Fri, 29 Aug 2008 15:54:17 +0200 |
| |
On Fri, 2008-08-29 at 15:34 +0200, Tejun Heo wrote: > Kay Sievers wrote: > >> For OSS emulation, it didn't really matter. For cases where it matters, > >> I think easier path to take would be let the userland emulation set up a > >> directory containing pseudo files and just override DEVPATH to it. > >> Would that work? > > > > No, I don't think so, it's a too bad hack. the SUBSYSTEM key, the entry > > in the class/bus directory, and the target of the symlink in the device > > directory _must_ match. Everything else asks for serious trouble, by the > > inconsistency it creates. > > I'm afraid trying to do that from kernel side would require more scary > hack as CUSE will need to push in random device under unsuspecting > parent / class. Maybe we can add a variable to indicate an emulated > device or to tell
Sure, SUSBYSTEM=cuse will be exactly that value. :) I see no problem, if cuse adds SUBSYSTEM_FAKE, or whatever it would be.
> udev/hal whatever to use alt root for sys hierarchy or > just consider sysfs is not available? I think this problem can be > settled between userland programs.
Exactly, we can do anything needed in userspace to support that. I see no problem doing that.
I just say, that we can _not_ allow to fake the SUBSYSTEM value for "cuse" or any other device. If the kernel wants to let "cuse" devices look like members of a specific subsystem, they have to appear in the class/bus list of that subsystem, and have to have the proper "susbsystem" link, not only a (wrong) environment key.
Userland enumerates devices by looking at class/bus directories for things like: "give me all soundcards", it expects a set of certain sysfs attributes to be present for a specific device, it reads the "subsystem" link, and so on. All that would break and make things "special" and needlessly inconsistent.
So please drop that plan, of faking only a tiny part of driver-core/sysfs device parameters. Either we do it properly, or we don't do it, and leave it up to userspace to pick up a (consistent) "cuse" device, but use it as a device of whatever class.
Thanks, Kay
| |