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

| 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 time
| (or before), life will be easier.
| 
| Also, for the same reason that init needs /dev/console, I think we need=20
| devfs to be mounted before init starts.

For what devices? The disks? As init can create /dev/console it can probably
mount devfs. I would prefer though to be done later in the rc process.

| What benefit is there for not using devfs once we have transitioned to it=
| =20
| (both as a project and at a given installation)?

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.

| Oh, this part doesn't fit so well in the above, but I have been thinking=20
| some about what "mounting" a devfs would mean, and what we could do with=20
| it. The biggest thing I see we would want to deal with is the case where=20
| the saved database is corrupt. Say there was a crash during a file write.
| 
| My thought is that when devfs mounts (even when the kernel or init=20
| automounts it), the mountfrom name is taken as the base name for two file=
| =20
| names, and both are opened by the kernel code. devfs then looks at the=20
| newer of the two files. If it passes db consistency checks (looks like a=20
| good file, no bogus lengths, etc.), then it is the one that gets read into=
| =20
| the running devfs. If it fails (either botched up, or doesn't exist), we=20
| look at the other, old file. If it passes, we use it (chances are there=20
| was an update issue). If it too doesn't work out, we just run with the=20
| node defaults.
| 
| Then when we need to save out the database, we overwrite the older of the=
| =20
| two files. Thus we will (should) always have a good version of the db=20
| around.
| 

That is a good idea (having 2 files around).

| Another thing I think we'd need is a tool that you can point at a=20
| directory (an existing /dev) and it'll generate a db file.

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.

christos