> On 12-Dec-96 Craig Milo Rogers wrote:
> >
> >>I've been thinking about how to best implement a "unified" way of
> >>setting driver parameters for kernel-resident and modularized drivers
> >...
> >>-- Treat the boot command line as a set of environment strings for the
> >
> > If there were a single kernel envar pool, and if drivers were
> >allowed to putenv() as well as getenv(), it could be a unified way to
> >save configuration information across module incarnations, or even
> >across system reboots. This raises the usual questions about built-in
> >drivers being able to autoprobe and/or configure multiple devices, and
> >whether or not module-based drivers can do the same; the envar naming
> >convention is important here.
>
> Setting it up so that (an enhanced) rdev(8) would be able to
> set these kernel variables would be a nice touch.
>
> > Presumably a "/proc" device could be used to handily view and
> >edit the kernel envars.
>
> Nice idea. Especially if rdev(8) (or some new utility) could
> pull the data out of /proc and configure the kernel image file
> so that autoprobing would only be needed the first time the
> kernel is booted.
>
In that case there should be some kinda serial number probing that'd
check if the machine booting the kernel matches the saved data or not...