Subject: Re: devfs, was Re: ptyfs fully working now...
To: Christos Zoulas <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 11/16/2004 16:33:27
Content-Type: text/plain; charset=us-ascii
On Sun, Nov 14, 2004 at 05:45:40PM -0500, Christos Zoulas wrote:
> On Nov 14, 1:52pm, firstname.lastname@example.org (Bill Studenmund) wrote:
> -- Subject: Re: devfs, was Re: ptyfs fully working now...
> | If you can help me see what we would do, I can either try to think of a=
> | 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.
Yeah, that was what I was thinking. Or that devfs can be sensitive to the
file system being read-only. Actually, having the devfs mount respect its
read-only flag would be a reasonable way to handle this abstraction. Nice=
> | Oh, the tool I had in mind was for sysinst & such. You point it at your=
> | current /dev, and it generates the db file needed to transition to it.=
> | Thus you can preserve your settings (both name and permission) when you=
> | make the transition to devfs.
> Ok, I see. Sounds good then. Another idea was to have a way to freeze dev=
> in its current configuration. I.e. make it so that new devices don't appe=
> automatically. This may be a requirement for certain security application=
We could make that a mount option, or have mount_devfs deal with this some=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----