Following this thread, I have come up with some toughts ...
[...]
> Umm... that's what I'm taking about. Sorry -- I tend to forget that you
> can't be telepathic over email.
>
> 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.
Of course, the devfs should be initialized and "mounted" at the very first
kernel boot stage, so it make no sense to make devfs be a module.
[...]
> > 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).
What about a scheme like this:
- /dev, a filesystem a la /proc
- Entries in the /dev filesystem are created at boot time: every device
driver should have a kernel-proper part (I think a data structure
containing at least "char *dev_name;" and, if we want to mantain the
concept of maj/min numbers, the maj and min numbers of the device) and a
modularizable part, the device driver itself.
When devfs is created, there are no registered devices, but all the
device files are present. When trying open() on such a device, we
receive an error of -ENODEV. Since the behaviour of all these files is
the same, we can create a file called /dev/nodev and hardlink (or
symlink) all the devices known to the kernel to this nodev.
At boot time a driver can be in 2 different states:
- Compiled into the kernel. In this case the device driver should call,
during boot, devfs_register() so that the /dev/devname hardlink is
"removed" and /dev/devname is attached to the device driver.
- Modularized. In this case when the module is not loaded, we have
/dev/devname linked to /dev/nodev. When the module is loaded it must
call devfs_register() to attach the /dev/devname
> > 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).
Not so far from my proposal too, you just have to transform the /dev/nodev
hardlink to a real device. With my scheme, the device file is alredy
present, you should only change its behaviour.
> > 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.
Not so shit. The kernel registers at boot time all the possible device
entries, but it links them to /dev/nodev. Then when you devfs_register()
you should only substitute the nodev hooks with hooks to device code and
transform the /dev/devname to something that seems the real device file.
> 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.
Suppose you have a third party binary-only module ... call it minnie that
drives the minnie device on your machine, the kernel at boot don't
know nothing about minnie, but you still can do something with /proc ...
just like 'echo "register minnie <maj> <min>" > /proc/sys/kernel/devices'
to register the /dev/minnie (linked to /dev/nodev). Then you can
'insmod minnie' that calls devfs_register()
> But we still need to have nodes for stuff that isn't neccessarly there. Shit.
You can even
'echo "unregister hdd" > /proc/sys/kernel/devices'
or 'rm /dev/hdd' if the hdd is not present on your machine.
Am I wrong ?
Ciao,
Riccardo.