Age | Commit message (Collapse) | Author |
|
|
|
|
|
because i already have a trivial addition in afterboot, to briefly document
rc.d(8), i have committed that bit also. that saves me making (even more)
trivial changes to this file, however the text was suggested by ingo and
i'm still waiting for his reply which, to be fair, has only been a wait of
some 30 mins so far. so, the rc.d blurb was requested by ross richardson,
suggested by ingo, and probably ok ingo. but if he objects, we can tweak
it further.
|
|
|
|
|
|
|
|
|
|
not to hand!) reports non-working devices. accordingly, remove the note
in BUGS asking people to report working devices, but leave the note
saying not everything works correctly.
|
|
requested by Ross L Richardson, and provided by djm
|
|
|
|
|
|
|
|
|
|
- Link libpthread.so with -znodlopen. Because libpthread overrides
the weak symbols in libc, we can't allow it to be dynamically
loaded or else libc's weak symbols might have already been
resolved by ld.so. (Also, major bump because this is technically
a backwards incompat change in behavior, although dlopen()ing
libpthread never really worked.)
- Link libc.so with -nodefaultlibs -lgcc. This ensures that libc
doesn't try to link against itself (which ld.so wouldn't like).
- Change GCC 4 to link shared objects with -lpthread and -lc as
appropriate, now that there's no issues with doing so. This means
that it's no longer necessary to patch software to use -pthread
instead of -lpthread. (Ports tree rejoice!)
Also, to preemptively answer this question: No, this does not
eliminate the need for LD_PRELOAD=libpthread.so. That's a separate
issue that won't be resolved until we eliminate libc's weak symbols.
Discussed extensively on email and icb over the past few months.
ok deraadt
|
|
- remove the compat_* text: there's only one left, and the text makes little
sense here
from Ross Richardson
ok schwarze
|
|
accordingly so vax can build again.
ok deraadt
|
|
from brad, ok jsg
|
|
diff originally by stsp@
"please commit it" deraadt@
"don't care" stsp@
"don't like" bluhm@
|
|
|
|
|
|
six years (since bioctl support was added).
ok krw@ dlg@
|
|
RFC 3986. This allows the following idiom in ftp:
ftp http[s]://user:pass@host/file
With some pointers from halex a lot of testing and feedback from lteo,
thanks a lot.
ok lteo@
|
|
COMPILER_VERSION now.
From Brad.
|
|
objects, inspired by NetBSD.
Discussed with kurt, kettenis, and millert.
ok kettenis
|
|
|
|
|
|
than snoop scsi commands and copy it in an io path.
no functional change, but the code has one less XXX now.
|
|
of its scsibus. only advertise 1 lun on logical volumes instead of letting
the midlayer fix it up to 8.
give every target on the bus max_cmds openings. iopools means they will
properly share access to them.
this in particular is useful on skinny controllers which only advertise 31
command slots. if you have 16 volumes, theyll only get 1 opening each with
the old maths. this way round the ones that are busy will share the slots.
tested on a perc5 with two volumes and hard workloads.
|
|
|
|
|
|
from the choose-tree defaults.
|
|
ok sthen@ benno@ claudio@
|
|
ok krw@
|
|
ok matthew@
|
|
TAILQ_FOREACH_SAFE. From Tiago Cunha.
|
|
from robert at peichaer dot org
discussed with and ok halex@
|
|
|
|
From Brad.
OK jsg@
|
|
like "Dell PERC 5/i" in dmesg. the firmware on the board knows its own name
so we can use that instead. saves some bytes in the kernel.
|
|
ok deraadt@
|
|
are.
noted by haesbaert@
|
|
|
|
transition_firmware into a member of the iop structures.
ok mikeb@ haesbaert@
|
|
|
|
"guess you get more commits" deraadt@
|
|
ok deraadt@
|
|
prodded by deraadt@
|
|
|
|
ok by mikeb@ haesbaert@ deraadt@ matthew@
|
|
after the ones currently supported by mfi(4).
mfii is to mfi what mpii is to mpi. it is also strange in that it reuses
bits of both mfi(4) and mpii(4) hardware structures. the register layout
is sort of like mfi, but the majority of the messaging (post and
completion paths) are like mpii. the new logical disk io message is
the same as the scsi io command in mpii with an extra raid context bit on
the end.
other operating systems have supported the new hardware in their existing
megaraid sas drivers by cutting them in half and using a metric buttload of
function pointers at pretty much every driver entry point to switch between
the non-fusion behaviour and the fusion behavior. the only really common
code seems to be the handling of the management commands before branching
off into the chip specific message handling to move it on and off the
hardware. i'll deal with abstracting the mgmt stuff out later.
this is working so im getting it in now to polish further in the tree.
ok by mikeb@ haesbaert@ deraadt@ matthew@
|