Devfs has to be linked into the kernel proper (it needs to exist long before
you normaly load modules). But I want the policy to be in a independent
runtime replacable section.
> > > I don't see a problem with such an interface. What I don't see is why
> > > you would want a user-space daemon at all. I think (hope) that a
> > > simple implementation can be developed without any need for a daemon,
> > > yet still retaining necessary functionality.
> > So do I. But we should have a replacable way of doing this, and it should
> > cost only a jnz, and a jmp. (Is overide_create != NULL? Then call that
> > function with the same arguments we got (same arguments == no need to pass
> > them again, our caller already did all the work)).
>
> devfs_register ();
> devfs_unregister ();
>
> and such should be able to provide all the overloading you need.
Right. I was just talking about their implementation (or, more specificly,
the implementation of the functions that use this information).
> So, my current thinking is:
>
> Device driver startup code registers the device entry, giving the name
> of the /dev entry, the permissions, ownership and so on as well as
> major&minor numbers for legacy disc-based /dev systems.
OK, you are with me here (mine just gives the name, but close enough).
> Another
> parameter would be the name of the module to pass to kerneld when
> someone open()s /dev/someentry. The ctime of these entries would be 0
> (or perhaps system boot time).
Huha? OUCH! I had forgot about that... we don't just want entries for
every divice existant... you need one for every divice possible, so the
device files exist before the driver is loaded to create the dynamic entries
in the devfs... sombody please tell me that I havn't been using a circular
path for devices that we need to access before we know how to access them...
Shit.
I don't like the idea of creating a file for every possible device; it takes
away the whole point of a dynamic devfs.
Shit.
How about this redisign:
<devfs' root>/
possible/ (note - for backwards compatablity, mount devfs on /devfs, and
make /dev be a symlink to /devfs/possible/)
<a divice for everything in Documentation/devices.txt>
loaded/
<various shit> (Including lots of trees (for chained devices, devices of
the same type, etc...))
But we still need to have nodes for stuff that isn't neccessarly there. Shit.
> A system script could be used to change permissions of /dev entries,
> which is called by /etc/rc or whatever. This script uses a simple
> database to determine which devices to fiddle.
OK.
> Another system script is called when shutting down the system which
> scans /dev for entries with a ctime newer than 0|boot-time. Any
> modified entries will be written to the database mentioned above. The
> point of this is that when the sysadmin manually changes
> permissions/ownership from the shell, those settings will be preserved
> across reboots. The beauty of this scheme is that it needs bugger-all
> help from the kernel (read: no kernel bloat), and also doesn't require
> the kernel to ask a user-space daemon about permission details.
Cool.
> A simple implementation of this will require one kernel-memory inode
> per available device. Given that there are usually not many available
> devices, this overhead should be minimal. If this were ever to become
> a problem, we could look at ways of avoiding creating VFS inodes for
> each device.
Yes; I think we are in agreement with how to store the fs: have un-reapable
i&dcache entries.
> The question of symlinks: either the devfs supports creation of
> symlinks (stored in RAM) or you require symlinks from an external
> filesystem (not very nice).
Don't do symlinks; make hardlinks. All data for the hardlink is in the
inode, so we don't have to handle file contents. But a symlink has its data
as contents, so we would have to put it somewhere, which would involve real
work. The icache (inode cache) can handle device files by itself, the
dcache can handle directories; contents would require a new in-memory
structure.
> So, comments please. I'm trying to evolve the above into a
> specification. Once all the necessary requirements are laid down,
> implementation can start. Given that this topic is somewhat
> controversial, I think the best way of sorting it out is to implement
> a reasonable solution and let people play with it.
>
> Regards,
> Richard....
-- 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)