> > > http://www-106.ibm.com/developerworks/linux/library/l- > fs6/?open&t=grl,l=252,p=lfs6 > ) they talk about the use of /dev-state. The use the new bind ability of > mount.
It is not new actually. And its usage here is not necessary at all - we achieve the same result with devfsd.conf It has one advantage that permissions are preserved even for non-devfs case. It is unlikely be of significant advantage as we do not (expect to) boot without devfs except for real emergency They do later say it turned out to be useful, but I'd like to see the example of it. This is nice, elegant, eye-catching, but absolutely not needed. but they also make a cp ( from their init wrapper ) : > cp -ax /dev-state/compat/* /dev ... > So, if you happen to be using a non-devfs kernel module, you'll need to > create a device node in /dev manually. The problem with this approach is > that > this new device node will be ignored by devfsd, meaning that the next time > you reboot, it will disappear. Our solution to this problem is to have the > /dev-state/compat directory; if you have a non-devfs module, simply create > your old-style device nodes in /dev-state/compat and they will be manually > added to the devfs filesystem at boot time, thanks to the considerate > steps > of our handy init wrapper. > This contradicts with the code. It should be cp -ax /dev-state/compat /dev so that the whole /dev/compat tree is recreated. As it stands now, you have /dev/compat/some-device in non-devfs case and /dev/some-device in devfs case. But yes, having special separate directory for extra files is one possibility. Having it inside /dev gives you advantage of having it both with and without devfs. Unfortunately it does not solve the problem our rc.sysinit tries to solve. You can't simply do 'mknod /dev/foo ...' and expect it to exist after reboot. That is the major problem for end user. You have to modify every package to create files in /dev/compat (or somewhere else) and teach users to do the same. For that matter you can just as well add extra lines to devfsd.conf (good, creating file is simpler, but devfsd.conf provides additional possibilities). -andrej
