Route(1) has a bug that sends a bad message to the kernel. The kernel
trusts it and crashes. Add some sanity checks so that
we don't trust the user quite as much any more.
(also add a comment in if_ethersubr.c)
facilitate the new saver loading/unloading notification interface
in syscons.
daemon_saver:
- M_NOWAIT was wrong, since NULL returns are not handled. Just use
M_WAITOK.
- use `ostype' instead of hard-coded "FreeBSD". Now there is no more
hard-coded string! (But, who will run this screen saver on other
OS?!)
- put macros and data declarations in a consistent order.
- -DDEAMON_ONLY and -DSHOW_HOSTNAME options added in the previous commit
are removed. Options of this kind can go stale and no one notices
because no one uses them. DEAMON_ONLY is just removed. SHOW_HOSTNAME
is made default.
snake_saver:
- use `ostype' and `osrelease' as in the daemon saver. The string changes
slightly - there was a hyphen after "FreeBSD"; now there is a space.
(It is consistent with uname -a, like the daemon server already is.)
all screen savers:
- Use the new add_scrn_saver()/remove_scrn_saver() in syscons.c
to declare loading/unloading of a screen saver. Removed reference
to `current_saver' and the variable `old_saver' as they are not
necessary anymore.
- The blank, fade and green screen savers manipulate VGA registers.
Module loading should fail for non-VGA cards.
- `scrn_blanked' is consistently treated as a number/counter rather
than boolean.
- Some savers touch `scp->start' and `scp->end' to force entire screen
update when stopping themselves. This is unnecessary now because
syscons.c takes care of that.
- cleared up many unused or unnecessary #include statements.
- Removed -DLKM from Makefiles.
YOU NEED TO RECOMPILE BOTH SCREEN SAVERS AND KERNEL AS OF THIS CHANGE.
1. Add new interface, add_scrn_saver()/remove_scrn_saver(), to declare
loading/unloading of a screen saver. The screen saver calls these
functions to notify syscons of loading/unloading events.
It was possible to load multiple savers each of which will try to
remember the previous saver in a local variable (`old_saver'). The
scheme breaks easily if the user load two savers and unload them in a
wrong order; if the first saver is unloaded first, `old_saver' in the
second saver points to nowhere.
Now only one screen saver is allowed in memory at a time.
Soeren will be looking into this issue again later. syscons is
becoming too heavy. It's time to cut things down, rather than adding
more...
2. Make scrn_timer() to be the primary caller of the screen saver
(*current_saver)(). scintr(), scioctl() and ansi_put() update
`scrn_time_stamp' to indicate that they want to stop the screen saver.
There are three exceptions, however.
One is remove_scrn_saver() which need to stop the current screen saver
if it is running. To guard against scrn_timer() calling the saver during
this operation, `current_saver' is set to `none_saver' early.
The others are sccngetc() and sccncheckc(); they will unblank the
screen too. When the kernel enters DDB (via the hot key or a
break point), the screen saver will be stopped by sccngetc().
However, we have a reentrancy problem here. If the system has been in
the middle of the screen saver...
(The screen saver reentrancy problem has always been with sccnputc()
and sccngetc() in the -current source. So, the new code is doing no
worse, I reckon.)
3. Use `mono_time' rather than `time'.
4. Make set_border() work for EGA and CGA in addition to VGA. Do
nothing for MDA.
Changes to the LKM screen saver modules will follow shortly. YOU NEED
TO RECOMPILE BOTH SCREEN SAVERS AND KERNEL AS OF THESE CHANGES.
Reviewed by: sos and bde
to this when raised, and most were in favor of at least this option
(some also asked for semaphores and messages, but I'll leave that argument
for another time :).
and released. It should use `spcl' consistently in both cases,
otherwise shift/control/alt state may not be correctly set/reset.
(Even with this fix, you can still make syscons confused and fail to
change internal state if you really want to, by installing a really
arcane and artificial keymap.)
PR: i386/4030
Reviewed by: sos
chown(). Previously, it wasn't marked for null chown()'s. We
permit null chown()s as a special case of "appropriate privilege"
- everyone has enough priviilege to not change ids (this is a better
argument than the one I gave for rev.1.13, that null changes aren't
really changes). However, POSIX.1 requires the update independently
of whether anything has changed.
Clear both the setuid and the setgid bits upon successful completion
of non-null chown()s by non-root. Previously, the setuid bit was
only changed for non-null changes of the uid, etc. POSIX.1 requires
clearing both unless the call was made by a process with "appropriate
privilege", in which case altering the bits is implementation-defined.
We define appropriate privilege as `process is root, or the change
is null', and the implementation-defined behaviour as not altering
the bits. There is no interpretation that permits clearing only
one of the bits.
Reviewed by: jdp
instructions more (many cases were already intended to be byte-sized
but were missing prefixes so gas assembled them bogusly), and
rearranging a loop to test at the end.
this code is controlled by smptests.h: TEST_CPUSTOP, OFF by default
new code for handling mixed-mode 8259/APIC programming without 'ExtInt'
this code is controlled by smptests.h: TEST_ALTTIMER, ON by default
- TEST_CPUSTOP adds stop_cpus()/restart_cpus(), OFF by default
- TEST_ALTTIMER new method for attaching 8259 PIC to APIC
this method avoids 'ExtInt' programming, ON by default
- TIMER_ALL sends 8259/8254 timer INTs to all CPUs, ON by default
- ASMPOSTCODExxx code to display bytes to POST hardware, OFF by default
and bios.S were small enough and have been merged back into their
respective files in biosboot/, conditionalized on CDBOOT. Other
files might be merged at a later stage.
Caveat emptor: i cannot test this right now.
This is the long-threatened ISO 9660 CD-ROM bootstrap code.
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
This work has been sponsored by Plutotech International, Inc (who paid
the initial work), and interface business GmbH (where i did most of
the work). A big thanks also goes to Bruce Evans, for his continuing
help and answering my stupid questions.
The code is basically functioning, with the following caveats:
. Rock Ridge attributes are not yet supported.
. Only SCSI CD-ROMs are supported, since i fail to see any possibility
to determine the drive type using BIOS functions. (Even for hard disks,
this determination is done by a big hack only.)
. El Torito specifies a lot of crap and useless misfeatures, but crucial
things like the ability to figure out the CD TOC have been ``forgotten''.
Thus, if you wanna boot a multisession CD, you need to know at which CD
block your session starts, and need to speciffy it using the @ clause.
. None of the CD-ROM controllers i've seen so far implements the full
El Torito specification at all. Adaptec is probably the closest, but
they miss on non-emulation booting (which would be the most logical
choice for us). Thus, the current code bloats the 7.5 KB boot code
up to 1.44 MB, in order to fake a `floppy' image.
If you wanna use it, specify this file as the boot image on the
command-line of the mksiosfs command (option -b).
Caveat emptor: some versions of the Adaptec BIOS might even fail to
access the CD-ROM at all, using the BIOS functions. I think i've
notice this for ver 1.26, the code has been tested with ver 1.23.
The boot string is as follows:
[@sess-start] [filename] [-flags]
sess-start Extend # where the last session starts, measured in
CD-ROM blocks.
filename As usual, but the input is case-insensitive by now
(since we don't grok RR anyway).
flags As usual, but -C (use CDROM root f/s) is default, so
specifying -C will decactivate this option (which is
probably not what you want :).
A lot of cleanup work is probably required, and some of the files
could/should be merged back to biosboot, perhaps made conditional on
some #ifdef. The malloc implementation that comes with cdboot might
also be useful for kzipboot. (I needed a malloc() since the root dir
ain't fixed in size on a CD.)
I've been testing all this with a 2.2-STABLE as the base for biosboot.
I don't expect too many surprises, although i know the biosboot stuff
has been changed a lot in -current lately. I'm sure Bruce will
comment on all this here anyway. :-)
