Subject: Re: devfs, was Re: ptyfs fully working now...
To: Bill Studenmund <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 11/14/2004 16:33:09
On Nov 14, 1:13pm, firstname.lastname@example.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=
| (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=
| 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=
| 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=
| two files. Thus we will (should) always have a good version of the db=20
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.