the i386 bios apm code (now removed).
Remove the same code from the clone dev/hpc/apm/apmdev.c
Remove some not-used options from dev/apm/files.apm and the commented out
lines in ALL and GENERIC.
Maybe the APM_V10_ONLY and APM_NO_V12 could also be shot, but they are
further entwined in the code.
when a on-disk block/inode allocation triggers allocating a new
quota entry, the new quota entry is not in the quota2 header block,
and the allocation will later be denied, the changes to the quota block would
not be flushed to disk, leading to list corruption (detected by fsck).
This is the code that predates ACPI, and might once have been able to
power down some laptops.
It hasn't been compiled for ages (it isn't it i386/ALL or any other
standard kernel) and hasn't worked for even longer.
The APM specification was made obsolete by ACPI before it was widely
implemented.
This will allow some other, even more dubious code be removed.
Unfortunately apmbios.h is used by the world !
Don't use broken 48bit accesses for ISID either.
This fixes the LUN ghosting problem on big-endian systems.
LUN handling is still incorrect because it assumes a LUN value < 256
and doesn't parse the 64bit LUN for extended formats.
do-sys-modules target was removed from src/Makefile in rev 1.299.
Fixes PR/46994.
Also remove a redundant bomb message which is already handled by
make_in_dir().
From "http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-00":
A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equal to 0 and the "M" bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPV6 Source Address, IPv6 Destination Address, Fragment
Identification}. That is, the Fragment Header of "atomic
fragments" should be removed by the receiving host, and the
resulting packet should be processed as a non-fragmented IPv6
datagram. Additionally, any fragments already queued with the
same set {IPV6 Source Address, IPv6 Destination Address, Fragment
Identification} should not be discarded upon receipt of the
"colliding" IPv6 atomic fragment, since IPv6 atomic fragments do
not really interfere with "normal" fragmented traffic.
christos