> 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)

The concern that I had was that people would actually start using the stupid thing, and start to rely on the path and existence of them. But, I suppose if people really _want_ to do that, we shouldn't stop them from hurting themselves. ;)

Userspace does need to know major/minor, as well as block vs. char. We could encode those in one file each, but a device node gives us all three in a standard format.

So, appended is a patch that allows you to create a device node in driverfs. The API is:

The name is "node", and it's created in the device's directory. There are plans to call /sbin/hotplug after the device is registered with its class. It's then that the kernel will know what type of device it is, and what the major/minor should be. The device path will be passed to /sbin/hotplug, which can then query the node as a template for creating other device nodes.

Note that ->fops is not set, though it appears that a request_module() happpens when you try to write to it.

Also, the owner of the device is root, and I easily make the permissions more stringent (i.e. make it S_IRUGO only always).

Attached is a simple little module to illustrate the use of the API. It creates a device 'foo0' and a node inside its directory once registered:

extern int driverfs_create_symlink(struct driver_dir_entry * parent, /* * foodev.c - simple illustration of device node creation in driverfs. * * Copyright (c) 2002 Patrick Mochel * * This is simple and stupid. We declare a platform device, register it * with the system, then create a device node for it. * The major/minor used is the char misc device, and the first free minor * (right after the mk712 touchscreen; stupid mk712). * * This is very buggy, but it's not meant to be perfect. We should check * the return of the registration and creation functions. * And, the module can be unloaded while there are still references to * the device. Oh well.. * * Also, the device has no parent or bus. Don't do that. Ever. I wrote * the API, so I'm special. ;) * * Compiled with:CFLAGS = -Wall -O2 -fomit-frame-pointer -DMODULE -D__KERNEL__IDIR = /home/mochel/src/kernel/devel/linux-2.5/include