[ On , October 8, 1998 at 12:04:26 (-0600), Chris Jones wrote: ]
> Subject: Re: Another changer, another changer problem
>
> devfs:  Nobody thinks this is a bad idea, either, but nobody has the
> time or inclination to implement it just now.  Sounds like a major
> project.

It's already been implemented in a very similar environment.

It's not a trivial project to move that implementation to NetBSD, but
it's not "major" either.  The implementation from FreeBSD can probably
be lifted intact and then there's only the last little missing feature
I've already mentioned that needs to be decided upon and added.

This, along with other useful improvements to the device driver layers,
could be done in fairly short order, especially with the assistance of
the various port maintainers.  I'd certainly tackle this part of the
project if I could get the appropriate resources and commitments in
place.  I can't afford to do it on my own any more than I could afford
to split off my own *BSD.

The problem with even starting such a project if you're not already a
NetBSD developer with commit priviledges is that it might never see the
light of day.

> run-time reconfig:  (referring to changing device settings like IRQs
> without recomiling the kernel)  Again, nobody things this would be a
> bad thing.  But nobody's come up with a good, clean way to implement
> it.

Again, FreeBSD has already done it, and though the specifics of their
implemenation (i.e. it's currently i386 specific) may not be appropriate
for NetBSD, their design is available and the concept is well proven.
NetBSD doesn't do anything radically different that would prevent their
design from being carved to fit -- and in fact it may even clean their
design up somewhat.

> Random idea:  Could the reconfig process tweak variables in the
> on-disk binary of the kernel?  Kind of like using adb on a binary?
> This wouldn't preserve configuration changes across kernel changes,
> but it would eliminate dependency on a config file on your root disk.
> Neither option seems pretty to me, though; and, on further reflection,
> this option seems very unappealing.

Clearly it could.  It's "better" in a unix sort of way to put the
configuration in an adjacent file to the booted kernel, and IMNSHO that
doesn't increase the frailty of the implementation by any unacceptable
amount.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>