> Take for example a miscellaneous character device driver such as the
> PC watchdog. Instead of calling <misc_register> it would call
> <proc_register> instead, creating a /proc/dev/pcwd entry rather than
> relying on /dev/pcwd to exist and have the correct major & minor
> numbers.
Here is basicly how I envision a proclike dev filesystem working:
1) The driver calls get_devnumb(char *name, size_of_tract, want_major,
want_minor). Name = name to appear in listing of allocated device numbers
in /proc/devs. size_of_tract = number of contigous divice numbers to
allocate. (The function returns the first one, they never cross majors
(so 256=give me a whole major)). When it does this, default devices are
created in /dev/<char *name>/n (for 0-size_of_tract), mode 0600. (This is
done for legacy drivers.)
2) The kernel calls a user-space daemon, which creates any other entries in
/dev that it wants (mknod, mv, rm, chown, chmod work in /dev)/.
3) The driver calls mknod_in_dev for any additional divice files it wants to
create in /dev; the nodes aren't directly created, but the userspace
daemon is asked to create them. (If said daemon can't be contacted, then
the kernel should create them directly.)
I think there is probably LOTS of legacy software (not to mention standards)
that will require us to keep the idea of device numbers. Note that the
user-space daemon should probably really be a kernel module (the dev code
would have stub functions that would call the module if it existed. If the
module wanted to call a userspace daemon, it could go right ahead.)
> When writing a new driver you would no longer have to worry
> about allocating major & minor numbers. Another benefit is that
> /prov/dev device entries only exist when the device is available,
> which is kind of neat. Done properly, this should take no more kernel
> memory than the existing major&minor /dev entries.
I'm not shure about the no more memory (we have to keep inodes for each
device in memory); but it shouldn't be all to large. (And most of the
inodes could be swapable (if kernel mem is ever swapable?)).
> All that would be needed is a few simple support functions to make it
> easy to register and unregister /proc/dev entries (for example using a
> common struct inode_operations to conserve kernel memory).
I should assume so, though the read & write would obviously have to be stub
functions that do lookup in a table of their own.
> I know that some may think that this is a departure from the
> "original" philosophy of /proc, but IMHO /proc is a really powerful
> interface with plenty of untapped potential.
I think that this should be a sepperate filesystem. /proc should (though it
isn't now) be moduleable, and this couldn't be.
> If I get general approval from the main kernel hackers, I can put out
> a patch which adds the support functions and modifies some existing
> drivers (pcwd for example).
Shure! I hope you consider my ideas.
> I think it would be good to add a config
> option (CONFIG_PROC_DEV) which if disabled (the default) drivers would
> call <misc_register> as they do now. Enabling CONFIG_PROC_DEV would
> make those drivers which have been patched register a /proc/dev entry
> instead. The documentation for CONFIG_PROC_DEV would tell the sysadmin
> to create symlinks in /dev for compatibility, and should maintain a
> list of which drivers have been converted.
I think that the drivers should always call the new get_devnumb (btw -
Sombody please think of better names for these functions). If the new /dev
is disabled, then it can just hand it off to the proper *_register function.
> Richard....
-=- James Mastros
-- Information as a base of power is coming to an end. In the way the world works tomorrow, the power to *do* *something* *with* *information* is what will matter.-=- James Mastros, rephrasing Nugget (David McNett, distributed.net Big Man)