* Remove first person sentence start.
* Make use of .Dv for LEASE_READ and LEASE_WRITE.
* Move the LOCKS section below the standard mdoc(7) RETURN VALUES
section.
* Cleanup grammar for RETURN VALUES and AUTHORS section.
* Remove redundant sentence on return values.
callout lock while the callout is happening. So the serialization
that I thought was happening isn't. Therefore, remove the part of the
bugs that says this. Leave in the other bug as it is very hard to
work around (impossible?).
Fix various typos.
Also note that timeout/untimeout are considered to be the old interface and
the callout interface should be used insetad.
Submitted by: bde (first two) and wollman (third)
callout has finished or is in progress. Also document that the
locking of the callout code for FreeBSD 5 has eliminated the 'or is in
progress' clause as a possibility and that such elimination is an
accident of the implementation and shouldn't be relied upon.
o It is the /usr/include files, not the /usr include files.
o Document the practice of converting to the c99 standard uintXX_t
form from the older, but non-standard, BSD-style u_intXX_t. This
has been going on in the tree for a while now, and I've heard other
developers also state that this conversion is happening. Note also
that this is a slow process and should be treated like whitespace
changes.
instances: the memory holding a struct disk should be pre-zeroed so
as to initialize any storage framework private data in the structures
properly. In addition, the memory must be writable so that the
private data may be updated.
Pointed out by: phk
APIs permit disk device drivers to register and deregister storage devices
for use by storage device consumers. No doubt this API will change
more as time flies by, but this should be helpful to the creators of
new storage device drivers.
Reviewed by: phk
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
large to huge amounts of small or medium sized receive buffers. The problem
with these situations is that they eat up the available DMA address space
very quickly when using mbufs or even mbuf clusters. Additionally this
facility provides a direct mapping between 32-bit integers and these buffers.
This is needed for devices originally designed for 32-bit systems. Ususally
the virtual address of the buffer is used as a handle to find the buffer as
soon as it is returned by the card. This does not work for 64-bit machines
and hence this mapping is needed.
