difference, but might later on when we implement some sort of multi-head
console mode. Select a console after probing them all.
Don't strdup a potentially NULL return from getenv().
If we don't select an active console, choose the first regardless.
Call the console init function, at startup time and on a manual change.
The env_setenv() function needs EV_VOLATILE because it's pointing to
data that isn't malloc'ed and will cause a fault if it's freed later.
Cosmetic change to the init-time character eater (like, make it increment
the index counter - if there's a problem, it would sit there in an infinite
loop instead of only running 10 times).
Also, make sure we set %dx each time around otherwise the commands
suddenly start trying to work on things like com92 instead of com1.
Make sure comc_init() is only run once.
Cosmetic change to init-time character eater.
fxp_stop is called as the first thing in fxp_init, and if the tx desc
list has junk in it, the system may panic. This bug showed up as a side
effect of the changes in rev 1.56, but has been in the code since the
beginning.
Linux and FreeBSD signal numbers. Also, check signal numbers passed
in from application programs for validity. Without these checks,
it is trivial to panic the system from a Linux program.
be converted to fixed-sized integers when they are passed across the
binary interface to the kernel.
Didn't fix rotted bits (including not passing dosdev to the kernel and
serious out of dateness when initially committed).
this myself for ages, but wasn't able to get any feedback from the people
that I sent it to for testing.
Guy Helmer <ghelmer@scl.ameslab.gov> has given it a shot (before getting on
a plane, thanks!) and it appears to stop his reproducable page fault panic
in the testing he was able to do.
o For bt and aha only probe the one I/O range if a specific I/O is specified
in the config file.
o Don't even try to probe I/O ranges that have been seen already.
o If we conflict with an IRQ or DRQ, then fail the probe.
Requested by: bde, gibbs
Approved by: jkh
Implement preloading in a fairly MI way, assuming the information is
prepared.
DDB interface helpers.. Provide some support for db_kld.c so that we
don't have to export too much detail.
Debugging and cosmetic nits left in from development..
The other half of the containing file hack so modules can associate
themselves with their "file".
but I can't think of another (relatively) easy way of getting the info
since the boot-time initialization is not done immediately after "loading".
XXX module_register() gained an extra arg. This might break the alpha
compile, if so, just add a zero to get the old behavior.
should probably be moved to i386/i386/link_machdep.c (and the same for the
alpha).
Implement "deleting" a preloaded module by destroying it's tags. This is a
hack. We cannot reuse the data, it's been destroyed by relocation,
statically initialized variables have been modified, etc. Note that to
reclaim the load space is going to be more machine-dependent work.
Implement a relocate hook for machdep.c to call so that the physical
addresses get converted to the equivalent KVM addresses.
- seperate unload for preloaded linker objects.
- Don't build a kernel object if running as an a.out kernel.
- extract the real kernel name rather than hardwiring "kernel" for kldstat.
(sysctl kern.bootfile getst the full name via bootinfo)
- use real addresses on the kernel "module" rather than fictitious ones.
- preloaded module support
- search module path for file modules.
- symbols are checked to see if they are in the right containing file
before using their indexes into string tables. This is to help ddb
since it only supplies a pointer to an opaque symbol and there is no
telling which file/object/module/whatever it came from.
- symbol_values checks that the symbol is indeed belonging to the
correct symbol and string table pairs before looking up. (since there
could be many pairs, and KLD/DDB need to find out).
- different ops for files versus preload modules - the unload mechanism
is different. (a preloaded module has to be deleted on unload since
the in-core image is tainted by relocation and variables used)
- Do not build an a.out kernel module if we're running on an elf
kernel. :-) Note that it should theoretically be possible to
mix a.out and elf KLD modules providing -mno-underscores was used
to compile it, or some other symbol conversion takes place.
- Support preload modules (even though /boot/loader doesn't yet)
- Search the module path when loading files.
check off SYSINIT entries as they are run, and when more arrive, we re-sort
and restart (skipping the already-run entries).
This can *only* be done after KMEM (and malloc) is up and running - this is
fine because KLD is the only consumer of this and it's done after that.
The nice thing about this is that the SYSINIT's within preloaded KLD modules
are executed in their natural order. It should be possible to register
devices for the probes which follow, etc. (soon.. several key things
prevent this, such as use of linker sets for things like pci devices).
trying to do it in locore. We also walk through the module table
and relocate any MODINFO_ADDR pointers so that they become KVM relative
rather than physical addresses. This means that hacks for adding
0xf0000000 in places like MFS go away.
get to all the symbol tables for all modules, not just the core kernel
symbol table. Yes, DDB can see KLD module symbols with this, both by
lookup and in tracebacks. No more references to _end from tracebacks
within an LKM. :-)
because the alpha boot loader hasn't been converted yet, and because
it needs the full symbol tables with local symbols in order to make sense
of stack tracebacks. KLD will implement this (using full sybmol table
rather than the globals only) shortly.
case it's possible to compile in something like ECOFF)
The three db_xxx.c symbol interfaces are "standard" because config isn't
flexible enough without forcing the user to know about it.
should be MD code since one day we'll have to recover pages from deleted
preload data. MI code can't be expected to know how to deal with pmap
internals, assuming it gets done via pmap that is. :-)
