Date: Mon, 13 Mar 1995 12:52:09 -0500 From: mtaylor@gateway.cybernet.com (Mark J. Taylor) To: hackers@FreeBSD.org Subject: Kernel reconfiguration process suggestions Message-ID: <v01510100ab8a1e944f9e@[192.245.33.12]>
next in thread | raw e-mail | index | archive | help
Peter Dufault writes:
[....]
>
>I doubt that Jordan and David are slapping themselves on the forehead
>now and saying "Of course! It would work better if we SAVED
>userconfig someplace!"
>
>Julian had a suggestion inspired by an OSF approach for some separate
>file that you load at boot. I'd propose a kernel-zapping ioctl
>that modified the on disk kernel after you were up and running if
>I wasn't afraid I'd get chased out of town.
>
>"-c" has helped many people get the distribution booted. It isn't
>fair to suggest that because it doesn't dance it shouldn't come
>out on stage to sing.
>
Didn't Apple's A/UX have some kind of command-line utility that allowed you
to modify kernel parameters w/o having to rebuild the kernel? Or did it
rebuild it for you? This would be good enough IMHO- a tool that took the
probe's output (via 'dmesg' and 'grep') and re-'config'ed, 'make'd a kernel
based on it, and installed it? It would go something like:
kconfig: You have a WizBang-2000 controller on the isa bus at irq 15 and i/o
address 0x300 in your system's last boot. Would you like to:
[K]eep it in the system at the same settings that was last booted at
[M]odify the settings for future boots
[R]emove it from the system
[L]ist config lines of all kernel-installed devices
user: K
user: M
kconfig: The following parameters may be changed:
1) bus [isa]
2) irq [15]
3) i/o address [0x300]
0) End changes
user: 2
kconfig: Enter new irq [15]:
user: 12
kconfig: Warning, you have a device, a FooBlaster-600, at this irq setting,
would you like to make the change anyway? [Yes]
user: Y
kconfig: The following parameters may be changed:
1) bus [isa]
2) irq [12]
3) i/o address [0x300]
0) End changes
user: 0
kconfig: You have a WizBang-2000 controller on the isa bus at irq 12 and i/o
address 0x300 in your system. Would you like to:
[K]eep it in the system at these settings
[M]odify the settings for future boots
[R]emove it from the system
[L]ist config lines of all kernel-installed devices
user: K
kconfig: You have a TCS 1654 device on the pci bus at automatic configuration
in your system's last boot. Would you like to:
[K]eep it in the system at the same settings that was last booted at
[M]odify the settings for future boots
[R]emove it from the system
[L]ist config lines of all kernel-installed devices
...
You get the idea. When the user was done, kconfig would build a new config
file and create a kernel based on the user's input.
Of course, it would be hard to do this, unless there was some file that
related the strings spat out during the probe to parsable device
information. Something like a sscanf string: [note that I got these
examples from a 1.1.5.1 'dmesg' output]
wdc controller "wdc%d at %x-%x irq %d on %s", devnum, ios, ioe, irq, bus
ed device "ed%d at %x-%x irq %d maddr %x msize %d on %s", devnum, ios,
ioe, mems, msize, bus
...
where devnum, ios, ioe, irq, bus, etc. were keywords used by the kconfig
program.
Would if be a big deal to require device drivers to provide this kind of
information? To make it easier, it might be able to automatically generate
these config strings based on some macros defined in the source code- by
doing a 'grep' for something like '#define CONFIG_STRING' in the
/sys/i386/isa/*.{c,h}, /sys/i386/pci/*.{c,h}, /sys/i386/eisa/*.{c,h} files.
This macro need not be used by the device code at all, just defined
somewhere in the modules.
The last boot message that the user should see if they booted with '-c'
should be "System booted with new configuration- please run 'kconfig' to
make any changes permanent." or something similar.
Also interesting:
I think that the way that Apple's A/UX did reconfiguration was to have a
file that indexed into the kernel to point to variables that were
configurable. The file looked something like:
kernelvariablename indexintokernelfile valuetype comments
slip_enabled 0x1400 boolean SLIP enable
slip_mtu 0x1432 short int maximum transmission
unit for SLIP
wizbang_enabled 0x2140 boolean WizBang-2000 enable
wizbang_irq 0x2146 short int IRQ setting for the
WizBang-2000
and the kconfig program parsed this file and let you change the values of
these variables, re-writing the values directly in the kernel file. In
FreeBSD's case, (some of?) the symbols are kept in the kernel file (do a
'nm /386bsd' or 'nm /kernel' for those of you who've never done it). Maybe
this would help? All we'd need would be the value types. If not, then
part of the process of making a kernel should make this file of
configurable variable offsets. (Maybe a null macro called 'CONFIGABLE'
gets put in front of the configurable variable, so it's easier to grep for
them to build the table.) The same type of auto-reconfig could be parsed
out of the 'dmesg' output if there was a symbol naming convention...
Having all modules compiled into the kernel would be necessary in this
case, because this kconfig would only allow modification of existing
variables, not the addition of new ones. This would be fine with me. I'd
prefer this approach to the one mentioned above (seems simpler to
implement, and not too confusing for a beginner). Only problem that I see
is that the kernel will be a bit large.
Joe User: "I need to change the settings for my WizBang-2000. How do I do it?"
Hackers/FAQ: "Run /sbin/kconfig and set the configuration variable
wizbang_enabled to TRUE, then make sure the wizbang_{irq,ioaddress} are set
to your system's configuration. Then reboot. Everything should be OK
then, Joe."
This is all just a thought, of course. Seems like a cool task for someone
to write, and I'm sure that alot of people would thank you for implementing
it...
-Mark Taylor
mtaylor@cybernet.com
Any opinions expressed in this message are my own, and do not reflect the
official position of Cybernet Systems.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v01510100ab8a1e944f9e>