Callers only need to initialize d_secperunit now, but should
initialize d_type (to reduce the IDE/SCSI confusion), d_typename
(put the disk model in it) and geometry info (if it isn't completely
ficticious). Callers will soon need to initialize d_secsize.
normally only defined in opt_devfs.h, so testing it before including
anything is normally a no-op. Undef'ing DEVFS before including
opt_devfs.h is similarly useless. OTOH, DEVFS support for sliced
but not SLICEd (despite defined(SLICE)) devices is either harmless
(if there are no such devices, then nothing in this file is used)
or necessary (otherwise). It even seems to work for sliced cd
devices.
This makes it possible to run make from cron, i.e.:
root's crontab:
( cd /etc/mail; make all install )
without the error:
makemap hash /etc/mail/spamsites < /etc/mail/block_domains.txt
makemap: not found
*** Error code 127
If this solution is widely accepted, I'd like to merge it into -STABLE
in rev.1.9). fsck uses the per-partition ffs-related information
in the label to find alternate superblocks when the main superblock
is hosed. Rev.1.9 broke this by deleting the code that wrote the
label.
PR: 2537
xref: fsck/setup.c rev.1.8
d_packname in in-core labels, so they are garbage if d_packname is
initialized in the dummy label for the whole disk. dsopen() will soon
initialize d_packname to "fictitious" if it is not already initialized.
Fixed nearby error handling. Rev.1.7 apparently confused Perror()
with perror().
small part of a bug suite beginning in the SLICE probes but mostly in the
floppy driver. This is a quick fix: the auto case shouldn't be special;
DMA should also be stopped in isa_dma_release(); isa_dmastop() probably
shouldn't exist; common DMA registers should not be accessed without
locking.
controller reports a successful seek, it is very unlikely to report
seeking to a cylinder other than the one requested, but we check for
this, and botched the error handling for the requested_cylinder != 0
case. This error happened when the bug fixed in rev.1.52 of <sys/buf.h>
caused the head of buffer queue to change to one starting on a different
cylnder - the requested cylinder was found, but it wasn't what we
thought we requested. The fix is simply to arrange to reset the state
machine.
Corruption of the buffer queue seems to only have been a problem in the
floppy driver. Other drivers dequeue the head of the queue before doing
physical i/o on it, so the corruption at worse broke the elevator sort
order. Dequeueing breaks it anyway.
o When reporting a int21 function we don't know about yet, report
AH as the major and AL as the minor, as opposed to reporting AL
as the major.
o Add support for 21:44:7: ioctl check output status. We
optimistically say that output is always ready.
o Add half support for 21:23: get file size. We always now return
failure. This function isn't supported, according to the interrupt
list, by the DOS box in windows, so I don't feel too bad.
o Remove init printf
o Don't set optind from return value for do_args. getopt has already
done this.
o Bump EMS memory from 1M to 10M (this really should be a command line
option).
o Open /dev/null when requested to open emmxxxx0 to allow many programs
checking to see if EMS is installed to find it.
o Route int67 to ems_entry to allow EMS to be used when DOS is emulated
as well as when DOS is booted. This may obviate the need for the
driver doing anything at all in a really booted situation and won't
hurt that case.
I can now run the DOS program I'm interested in running with enough
EMS memory that its "advanced" functions are enabled and working.
run at the same time.
Notes:
The fileupdate function is still somewhat broken. Instead of
returning a failure code if it can't modify the original file it
renames the .new file and continues as though nothing is wrong.
This will cause the lock on the original file to be lost and could
lead to a similar race condition. I left that portion of the code
alone since I feel that the maintainer of the code would have a
better concept of how he wants to handle errors in that function
than I do.
PR: bin/6787
Submitted by: Craig Spannring <cts@internetcds.com>
