> is it a bad thing to change bits in the kernel itself?

Depends on the context.

> I was recommended recently to go and change things in the kernel file
> with gdb (set nbuf=128), and it didn't seem to cause any problems
> with the running of the system at the time.

That's because the on-disk kernel is ignored once the system is up,
except for purposes of things like nlist(), and that's under discussion
periodically too.

> if this is allowed, then why can't there be a part of the device
> description structure that says who owns it and who is allowed to
> write to it?  any changes made to the devfs filesystem mounted on
> /dev could be written to the running kernel by the devfs filesystem?

This is not possible on ports where the kernel isn't accessible once
the system is up (I think the mac68k port works this way, doesn't it?)
or are not writeable once the system is up (like any system with a
read-only boot disk - though granted, in this latter case you're not
likely to be frobbing stuff in /dev).

I'm also uncomfortable with the kernel bashing on its own on-disk
image.  Perhaps the info file could be the "device" portion of a devfs
mount?

# touch /etc/dev-mods
# mount -t devfs /etc/dev-mods /dev

Then devfs can use /etc/dev-mods as permanent record of changes that
are made to /dev.

However, I don't really like this idea, because if devfs is to support
the full suite of filesystem operations it will be quite complicated,
and if not, /dev becomes a bit too special for my taste.

On IRIX, there's a mapping table between major device numbers in /dev
and indices into [bc]devsw.  Perhaps that's what we need here: reserve
part of the major number space - 1000-2000, maybe; negative, maybe -
for cross-port devices.  Majors in this range go through a
port-specific mapping table to get the index into the device switch
table.  Then /dev remains just what it always has been, a part of the
root filesystem, only that /dev/*sd*, /dev/tty, /dev/console, etc, have
majors in this "multi-port" range.

I don't like approaches that deal with MAKEDEV because they don't
address the wish to share /dev across heterogenous machines.  (I'm not
sure how reasonable a wish this is, but it's really not that hard to
satisfy.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B