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

At your request, however, i've just sent this message back to
tech-kern@netbsd.org.

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


chris