public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: Tejun Heo <tj@kernel.org>
Cc: Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Zeuthen <david@fubar.dk>
Subject: Re: [PATCH 2/2] uevent: handle duplicate uevent_var keys properly
Date: Fri, 29 Aug 2008 15:54:17 +0200	[thread overview]
Message-ID: <1220018057.24737.36.camel@lgn.site> (raw)
In-Reply-To: <48B7FAEC.80206@kernel.org>

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


  reply	other threads:[~2008-08-29 13:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-28 16:30 [PATCH 1/2] uevent: don't pass envp_ext[] as format string in kobject_uevent_env() Tejun Heo
2008-08-28 16:31 ` [PATCH 2/2] uevent: handle duplicate uevent_var keys properly Tejun Heo
2008-08-28 16:49   ` Greg KH
2008-08-28 17:00     ` Tejun Heo
2008-08-28 17:33       ` Greg KH
2008-08-29  7:48       ` Kay Sievers
2008-08-29  8:02         ` Tejun Heo
2008-08-29 13:27           ` Kay Sievers
2008-08-29 13:34             ` Tejun Heo
2008-08-29 13:54               ` Kay Sievers [this message]
2008-08-29 15:00                 ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1220018057.24737.36.camel@lgn.site \
    --to=kay.sievers@vrfy.org \
    --cc=david@fubar.dk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox