Subject: Re: 32 bit dev_t, Revision 2
To: None <tech-kern@NetBSD.ORG>
From: Chris G. Demetriou <email@example.com>
Date: 01/11/1998 18:57:29
Paul Vixie said:
> until today i thought that netbsd kernel people were experienced internet
> users. i now realize that the expertise here runs toward kernel bitting
> and away from e-mail headers. that is to say, when you reply to a thread
> on the mailing list, please edit the headers so that everybody who has ever
> participated in the thread doesn't have to see two copies of your message.
Uh, actually, some of us _like_ getting the extra copies. It lets
people who want to 'actively' discuss the issue get copies faster.
At your request, however, i've just sent this message back to
Looking at it another way, senders who don't want extra copies might
set reply-to... 8-)
> back on topic, can someone 'splain to me why device special files are still
> inside a UFS/FFS container with special "MAKEDEV" scripts? if we can do
> /proc it seems to me that /dev can be a special file system whose entries
> are _made_ at successful probe time, using monotonically increasing dev_t's
> with an opaque internal structure? ted says this has been done in some
> form. if we're going to pull dev_t through a knothole backward and touch
> the kernel in 125 places to do it, why not do the Right Thing and just stop
> trying to figure out whether 12/20 is a good split or whether MI and MD need
> different ranges and whether one or two tables are the right approach. we
> KNOW this isn't the right approach, why are we taking it anyway?
(1) there are a number of unsolved problems with approaches like this.
e.g. "how do you keep permissions the same between boots, without
wasting a bunch of time while booting."
(2) some people aren't keen on being forced to waste kernel space for
the file system and built-up data structures, when small statically
allocated ones work just fine.
(2) you can't get rid of device nodes completely no matter what you
do, though that's mostly irrelevant. 8-)