On Nov 14,  1:52pm, wrstuden@netbsd.org (Bill Studenmund) wrote:
-- Subject: Re: devfs, was Re: ptyfs fully working now...

| Why? We need it before we can try mounting "critical" file systems, so we=
| =20
| can't delay it long. And I don't see any benefit to waiting; I don't see=20
| what we would want to do strictly before mounting devfs, and we also would=
| =20
| be adding a new dependency to the rc scripts - we need to know what ones=20
| need devices around.
| 
| If you can help me see what we would do, I can either try to think of a=20
| different way to do it, or I can admit your right. :-)

I was thinking that it needs a place to write, so it should be done after
root is mounted read-write. But I guess it will not read to write to that
file immediately, so the kernel/init can mount devfs readonly, and then
the rc script can update it to read-write.


| Another thing I had in mind was (eventually) being able to support devfs=20
| mount updates. For instance, I think it would be reasonable to permit=20
| changing what files are used as the devfs database - mount -t devfs -u=20
| /new/file/location /dev should work. I'm not certain if the new file=20
| should change current settings, or if it should just be a destination for=
| =20
| future updates.
| 
| Oh, the tool I had in mind was for sysinst & such. You point it at your=20
| current /dev, and it generates the db file needed to transition to it.=20
| Thus you can preserve your settings (both name and permission) when you=20
| make the transition to devfs.
| 

Ok, I see. Sounds good then. Another idea was to have a way to freeze devfs
in its current configuration. I.e. make it so that new devices don't appear
automatically. This may be a requirement for certain security applications.

christos