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

[Tejun Heo]

Kay Sievers wrote:
>> 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.

Right, I was somehow fixated on sound devices having "sound" subsystem.
 That isn't necessary and if some special treatment is needed, we can
play with udev rules and so on.  Okay, will drop the kobject_uevent
changes and hotplug_info stuff.  It seems dev_info is all that's needed.

Thanks.

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