[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1220018057.24737.36.camel@lgn.site>
Date: Fri, 29 Aug 2008 15:54:17 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Tejun Heo <tj@...nel.org>
Cc: Greg KH <greg@...ah.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Zeuthen <david@...ar.dk>
Subject: Re: [PATCH 2/2] uevent: handle duplicate uevent_var keys properly
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists