lkml.org 
[lkml]   [2002]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-usb-devel] Re: 2.5.26 hotplug failure
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.593 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site