From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: 2.5.26 hotplug failure
Date: Sun, 22 Sep 2002 01:21:06 +0000 (UTC) [thread overview]
Message-ID: <amj5u2$20t$1@penguin.transmeta.com> (raw)
In-Reply-To: <20020921033137.GA26017@kroah.com>
In article <20020921033137.GA26017@kroah.com>, Greg KH <greg@kroah.com> wrote:
>On Fri, Sep 20, 2002 at 07:55:22PM -0700, David Brownell wrote:
>>
>> How about a facility to create the character (or block?) special file
>> node right there in the driverfs directory? Optional of course.
>
>No, Linus has stated that this is not ok to do. See the lkml archives
>for the whole discussion about this.
I'm not totally against it, it's just that it has some issues:
- naming policy in general. Trivially handled by just always calling
the special node something truly boring and nautral like "node", and
be done with it. The _path_ is the real name, the "node" would be
just an openable entity.
- the issue of persistent permissions and ownership.
The latter is the real problem. And I personally think the only sane
policy is to just let "/sbin/hotplug" handle it, which definitely
implies _not_ having the kernel create the real device node. That way
user-space can have any policy it damn well pleases, including having
some default heuristics along with "a priori known nodes".
But clearly that user-space hotplug entity needs to know major and minor
numbers in order to create the real device node, and that's where the
"node" thing may be acceptable - as a template, nothing more. Although
I suspect that there are other, simpler and more acceptable templates
(ie export the dang thing as just a "node" text-file, which describes
the majors and minors and "char vs block" issues)
Linus
next prev parent reply other threads:[~2002-09-22 1:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-18 7:50 Duncan Sands
2002-07-18 18:36 ` Greg KH
2002-07-18 19:07 ` Duncan Sands
2002-09-15 21:53 ` Duncan Sands
2002-09-18 6:52 ` Greg KH
2002-09-18 7:15 ` [linux-usb-devel] " Brad Hards
2002-09-18 16:55 ` Greg KH
2002-09-19 7:37 ` Daniel Phillips
2002-09-19 7:45 ` Daniel Phillips
2002-09-19 7:48 ` Greg KH
2002-09-19 7:55 ` Daniel Phillips
2002-09-19 16:49 ` Greg KH
2002-09-19 20:56 ` Brad Hards
2002-09-19 23:06 ` Greg KH
2002-09-20 20:42 ` [linux-usb-devel] " David Brownell
2002-09-20 23:11 ` Greg KH
2002-09-21 2:55 ` David Brownell
2002-09-21 3:31 ` Greg KH
2002-09-21 3:58 ` David Brownell
2002-09-21 5:48 ` Greg KH
2002-09-22 1:21 ` Linus Torvalds [this message]
2002-09-24 18:26 ` Patrick Mochel
2002-09-24 18:55 ` Linus Torvalds
2002-09-24 19:29 ` Greg KH
2002-09-24 22:37 ` Patrick Mochel
2002-09-20 23:22 ` Brad Hards
2002-09-20 23:36 ` Johannes Erdfelt
2002-09-21 0:11 ` Randy.Dunlap
2002-09-21 0:25 ` Brad Hards
2002-09-21 2:36 ` David Brownell
2002-09-20 23:46 ` Patrick Mochel
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='amj5u2$20t$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.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
Powered by JetHome