I think these problems can be (mostly) solved with module options.
> > 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.)
Hold on! Why bother with this stuff? I'm proposing straight /proc
entries. You don't need major&minor block/char special files. The link
between the driver and the VFS is by name, not major&minor.
> 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
Really? Programmes should not be relying on major&minor numbers. After
all, they can change. That's why you access via /dev/*.
> > 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?)).
Possibly the existing /proc interface would require an inode per
device. If this is a problem, the solution would be to create a /dev
filesystem driver rather than using the /proc filesystem driver.
The /dev FS would generate inode numbers automatically, but wouldn't
need to create an inode for each device. There would be a single
sharded inode to keep the VFS happy (I think: I'll have to check on
this). Obviously, there would be no hard links inside the /dev FS, but
that doesn't matter.
However, that's a detail: the utility functions which drivers use will
hide those implementation details. This would allow us to start
developing/experimenting with /prov/dev and if inode consumption
became an issue, we could develop devfs without having to change the
drivers.
> > 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.
Correct.
> > 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.
I don't see that it matters much. The extra code to create the
/proc/dev directory and the interface functions would be pretty small,
and besides they'd be wrapped in #ifdef's.
> > 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.
I guess when CONFIG_PROC_DEV is enabled then get_devnumb would expand
to something that just ignores the major&minor stuff. That would have
the advantage of removing the need for #ifdef's in each driver.
Regards,
Richard....