managed to avoid corruption of this variable by luck (the compiler used a
memory read-modify-write instruction which wasn't interruptable) but other
architectures cannot.
With this change, I am now able to 'make buildworld' on the alpha (sfx: the
crowd goes wild...)
and DSO_NOLABELS flags prevent searching for slices and labels
respectively. Current drivers don't set these flags. When
DSO_NOLABELS is set, the in-core label for the whole disk is cloned
to create an in-core label for each slice. This gives the correct
result (a good in-core label for the compatibility slice) if
DSO_ONESLICE is set or only one slice is found, but usually gives
broken labels otherwise, so DSO_ONESLICE should be set if DSO_NOLABELS
is set.
protection checks. Using the partition-relative blkno in some
parts broke the write protection for partitions at unusual
offsets (only for partitions at offset 1 on i386's).
best place to set it, and the wd and wfd strategy routines don't
set it (for failed transfers) because they expect dscheck() to
initialize everything necessary. dscheck() has always set B_ERROR,
but this is not quite sufficient, because b_resid is used by physio()
to decide how much of a B_ERROR'ed i/o was done.
formats and args to match. Fixed old printf format errors (all related;
most were hidden by calling printf indirectly).
This change somehow avoids compiler bugs for 64-bit longs on i386's,
although it increases the number of 64-bit calculations.
timeslice of the exiting process was counted for both the exiting
process and the next process to run if the next process runs
immediately.
Broken in: mostly in kern_clock.c rev.1.70 (1998/05/28)
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.
nearly so many casts here. Casting an pointer that was an integer
back to an integer just to compare it with -1 is bad, and casting
it back just to compare it with NULL is just wrong.
Access the entry address as a uintfptr_t, not as a long, and not
necessarily as what modload(8) passes (it takes a u_long from the
exec header and passes a u_int).
Fixed bitrot in K&R support (suword() now takes a long word).
Didn't fix corresponding bitrot in store.9 and fetch.9.
The correct types for the store and fetch families are problematic.
The `word' functions are unfortunately named and need to be split
to handle ints/longs/object pointers/function pointers. Storing
argv[] as longs is quite broken when longs are longer than pointers,
but usually works because it clobbers variables that will soon be
reinitialized.
Hopefully caddr_t is large enough to hold function pointers.
Cast object pointers to uintptr_t before casting them to u_long.
Types are wronger than usual for the PT_READ_U case. ptrace() can
only return ints, but longs are accessed.
respectively. Most of the longs should probably have been
u_longs, but this changes is just to prevent warnings about
casts between pointers and integers of different sizes, not
to fix poorly chosen types.
suitable for holding object pointers (ptrint_t -> uintptr_t).
Added corresponding signed type (intptr_t). Changed/added
corresponding non-C9x types for function pointers to match. Don't
use nonstandard types to implement these types, and don't comment
on them in <machine/types.h>.
(long)(u_long)(u_int)-4 = 0x00000000fffffffc on machines with 32-bit
ints and 64-bit longs.
Restored %z format for printing signed hex. %+x shouldn't have been
used since it is an error in userland.
Prepared to nuke %n format by cloning it to %r. %n shouldn't have
been used because it means something completely different in
userland. Now %+r is equivalent to ddb's original %r, and %r is
equivalent to ddb's original %n.
Ignore '+' flag in combination with unsigned formats %{o,p,u,x}.
you can specify the corefile name by using:
sysctl -w kern.corefile="format"
where format is a pathname (relative or absolute -- default is "%N.core"),
with "%N" (process name), "%P" (process ID), and "%U" (user ID) formats.
Reviewed by: Mike Smith, with strong requests by Julian :)
writes of size (100,208]+N*MCLBYTES.
The bug:
sosend() hands each mbuf off to the protocol output routine as soon as it
has copied it, in the hopes of increasing parallelism (see
http://www.kohala.com/~rstevens/vanj.88jul20.txt ). This works well for
TCP as long as the first mbuf handed off is at least the MSS. However,
when doing small writes (between MHLEN and MINCLSIZE), the transaction is
split into 2 small MBUF's and each is individually handed off to TCP.
TCP assumes that the first small mbuf is the whole transaction, so sends
a small packet. When the second small mbuf arrives, Nagle prevents TCP
from sending it so it must wait for a (potentially delayed) ACK. This
sends throughput down the toilet.
The workaround:
Set the "atomic" flag when we're doing small writes. The "atomic" flag
has two meanings:
1. Copy all of the data into a chain of mbufs before handing off to the
protocol.
2. Leave room for a datagram header in said mbuf chain.
TCP wants the first but doesn't want the second. However, the second
simply results in some memory wastage (but is why the workaround is a
hack and not a fix).
The real fix:
The real fix for this problem is to introduce something like a "requested
transfer size" variable in the socket->protocol interface. sosend()
would then accumulate an mbuf chain until it exceeded the "requested
transfer size". TCP could set it to the TCP MSS (note that the
current interface causes strange TCP behaviors when the MSS > MCLBYTES;
nobody notices because MCLBYTES > ethernet's MTU).
Not sure of the result of it..
(may or may not effect anything) but it's fixed now.
(found by: comparing what cvsup sent back to me with what I tested..)
There is only cdevsw (which should be renamed in a later edit to deventry
or something). cdevsw contains the union of what were in both bdevsw an
cdevsw entries. The bdevsw[] table stiff exists and is a second pointer
to the cdevsw entry of the device. it's major is in d_bmaj rather than
d_maj. some cleanup still to happen (e.g. dsopen now gets two pointers
to the same cdevsw struct instead of one to a bdevsw and one to a cdevsw).
rawread()/rawwrite() went away as part of this though it's not strictly
the same patch, just that it involves all the same lines in the drivers.
cdroms no longer have write() entries (they did have rawwrite (?)).
tapes no longer have support for bdev operations.
Reviewed by: Eivind Eklund and Mike Smith
Changes suggested by eivind.
as the value in b_vp is often not really what you want.
(and needs to be frobbed). more cleanups will follow this.
Reviewed by: Bruce Evans <bde@freebsd.org>
