>> /dev has a few reserved directory (like /dev/id). You have no >> freedom there. Any access other than that goes to devfsd. It has >> knowledge equivalt to sys/arch/*/conf/majors.* as reference. And it >> tracks mknod(2), rename(2), etc per-mount point.
>> When you do mknod(/dev/wd0a); rename(/dev/wd0a, /dev/woah0a); >> open(/dev/woah0a), devfsd resoves it by using DBs and converts it to >> something like /dev/default/wd0a and pass it back to kernel. I'm a little confused, here. How can chmod and chown on /dev/wd0a do anything useful if /dev/wd0a just gets redirected to (say) /dev/default/wd0a? Removing access helps in only a few cases, because someone wishing to bypass the removal can go directly to /dev/default/wd0a. And granting access doesn't help either, because the access will fail on /dev/default/wd0a even if it doesn't on /dev/wd0a. Unless I've misunderstood something.... >> You have to shutdown cleanly, otherwise you lose DB. > Sweet jesus. Talk about brittle solutions... Well, yes. But research efforts are like that. Robustness is pretty much necessary for production use but not for the stage this appears to be at. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
