since (hardware) ttys have too low a bandwidth to benefit significantly
from large buffers. Use twice the old limit for the new-default case
and 8 times the old limit for the driver-specifies-watermark case.
Nothing uses these cases yet.
Removed related debugging code.
I don't have access to a real VT220 to verify this against.
However, I'm committing the patch in `good faith' because
(a) getting hold of a real VT220 is going to be increasingly difficult
the longer the PR sits around,
(b) some one was troubled enough to in a PR and
(c) the fix is minor and has no other implications.
PR: 7559
Submitted by: Christian Weisgerber <naddy@mips.rhein-neckar.de>
in a SMP system. Unexpected things could happen if each cpu
has a different ldt setting and one cpu tries to use value
of currentldt set by another cpu.
The fix is to move currentldt to the per-cpu area. It includes
patches I filed in PR i386/6219 which are also user ldt related.
PR: i386/7591, i386/6219
Submitted by: Luoqi Chen <luoqi@watermarkgroup.com>
clustering is obsolescent technology so hardly anyone noticed. On
a DORS 32160 SCSI drive with 4 tags, read clustering makes very
little difference even for huge sequential reads. However, on a
ZIP SCSI drive with 0 tags, the minimum overhead per block is about
40 msec, so very large clusters must be used to get anywhere near
the maximum transfer rate. Using clusters consisting of 1 8K block
reduces the transfer rate to about 250K/sec. Under msdosfs, missing
read clustering is normal and a cluster size of 1 512 byte block
reduces the transfer rate to about 25K/sec.
Broken in: rev.1.18
not the necessarily the same as the seconds part of getmicrotime()
yet, and anyway, we should have used `time_second' if we only wanted
a sloppy value for the seconds part. There is no point in making
ibcs2's time(2) more efficient than FreeBSD's time(3).
description of DPT_SHUTDOWN_SLEEP in LINT. Didn't add timestamps
so that the (combined?) sleep interval can be printed as intended
in the original printf.
stability now. ALso modify /sys/conf/files, /sys/i386/conf/GENERIC
and /sys/i386/conf/LINT to add entries for the XL driver. Deactivate
support for the XL adapters in the vortex driver. LAstly, add a man
page.
(Also added an MLINKS entry for the ThunderLAN man page which I forgot
previously.)
applications. Here's how it works.
The kernel should include <machine/elf.h> to get the definitions
for the native architecture. It can reference the various ELF
structures with generic names like Elf_Sym, Elf_Shdr, etc. A define
__ELF_WORD_SIZE is also available with the value 32 or 64 as
appropriate for the native architecture.
Generic applications should include <elf.h>, which is just a wrapper
for <machine/elf.h>.
Applications such as object file dumpers that need to deal with
foreign ELF files can include <sys/elf32.h> and/or <sys/elf64.h>.
Both can be included from the same source file if desired. The
structure names must be referenced using wordsize-specific names
like Elf32_Sym, Elf64_Shdr, etc.
I haven't change the alpha stuff, but I haven't broken it either.
Cast pointers to (vm_offset_t) instead of to (u_long) (as before) or to
(uintptr_t)(void *) (as would be more correct). Don't cast vm_offset_t's
to (u_long) just to do arithmetic on them.
mp_machdep.c:
Cast pointers to (uintptr_t) instead of to (u_long). Don't forget
to cast pointers to (void *) first or to recover from integral
possible integral promotions, although this is too much work for
machine-dependent code.
vm code generally avoids warnings for pointer vs long size mismatches
by using vm_offset_t to represent pointers; pmap.c often uses plain
`unsigned int' instead of vm_offset_t and didn't use u_long elsewhere,
but this style was messed up by code apparently imported from mp_machdep.c.
address constants. This fixes some warnings for conversions from
64-bit integers to 32-bit pointers on i386's with 64-bit longs.
vm86 still uses too many u_longs.
pointers. Neither is portable, but "correct" casts to integral
types are much uglier - they lead to expressions like
ptr = (struct struct_with_too_long_a_name *)(void *)(uintptr_t)
((uintptr_t)(void *)ptr + offset);
Here the cast to the struct pointer is to match the surrounding
style of this file (and not depend on C's feature of properly
converting `void *' on assignment or cast), the `void *' casts are
because uintptr_t is only specified to work on `void *' pointers
(I missed this in about 100 lines of previous changes from [u]long
to [u]intptr_t), the outer cast to a uintptr_t is in case the
addition promoted the type, and the inner cast to a uintptr_t
corresponds to the one cast to an integer in the original code.
Don't depend on gcc's feature of casting lvalues.
It can be integral or a struct in POSIX, so it is difficult to print,
but it is actually declared as unsigned long. Assume that it is
unsigned integral.
