Re: [PATCH 2/2] uevent: handle duplicate uevent_var keys properly

[Kay Sievers]

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

--
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/