--hYooF8G/hrfVAmum
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 14, 2004 at 04:33:09PM -0500, Christos Zoulas wrote:
> On Nov 14,  1:13pm, wrstuden@netbsd.org (Bill Studenmund) wrote:
> -- Subject: Re: devfs, was Re: ptyfs fully working now...
>=20
> | When we transition to wedges, I think we REALLY REALLY need devfs. I do
> | not think that wedge minor numbers will be stable (or it will be harder=
 to
> | keep them stable) across boot, and so if we jump to devfs at the same t=
ime
> | (or before), life will be easier.
> |=20
> | Also, for the same reason that init needs /dev/console, I think we need=
=3D20
> | devfs to be mounted before init starts.
>=20
> For what devices? The disks? As init can create /dev/console it can proba=
bly
> mount devfs. I would prefer though to be done later in the rc process.

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. :-)

> | What benefit is there for not using devfs once we have transitioned to =
it=3D
> | (both as a project and at a given installation)?
>=20
> Nothing, once we've transitioned to it. I think that for the transition
> period though, we'll have to be able to run both with and without.

I suspect that that transition period will really just be for the=20
developers actively working on devfs. Once we push it into current (or=20
once we turn its mount in init or whatever on), I think we need to run=20
with it. :-)

> | My thought is that when devfs mounts (even when the kernel or init=3D20
> | automounts it), the mountfrom name is taken as the base name for two fi=
le=3D
> | =3D20
> | names, and both are opened by the kernel code. devfs then looks at the=
=3D20
> | newer of the two files. If it passes db consistency checks (looks like =
a=3D20
> | good file, no bogus lengths, etc.), then it is the one that gets read i=
nto=3D
> | =3D20
> | the running devfs. If it fails (either botched up, or doesn't exist), w=
e=3D20
> | look at the other, old file. If it passes, we use it (chances are there=
=3D20
> | was an update issue). If it too doesn't work out, we just run with the=
=3D20
> | node defaults.
> |=20
> | Then when we need to save out the database, we overwrite the older of t=
he=3D
> | =3D20
> | two files. Thus we will (should) always have a good version of the db=
=3D20
> | around.
> |=20
>=20
> That is a good idea (having 2 files around).
>=20
> | Another thing I think we'd need is a tool that you can point at a=3D20
> | directory (an existing /dev) and it'll generate a db file.
>=20
> I think the easiest is to let the kernel do it, since it knows how. We
> just make a device node entry /dev/devdb, and we cat /dev/devdb > foo.db.

For generating copies, that would be fine. Infact that might be a great=20
way to do it.

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.

Take care,

Bill

--hYooF8G/hrfVAmum
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBl9OSWz+3JHUci9cRAm47AJwKi0tVnlfkKOoiAHSjh8RJRXc0MQCgmEGw
GeqoXe9tQT+r1n1ytqLVzgo=
=IQpq
-----END PGP SIGNATURE-----

--hYooF8G/hrfVAmum--