Function acquired reader lock if needed.
Assert check for reader or writer lock (RA_LOCKED / RA_UNLOCKED)
- While here, add knlist_init_mtx.9 to MLINKS and fix some style(9) issues
Reviewed by: glebius
Approved by: ae(mentor)
MFC after: 2 weeks
3rd argument of ifa->ifa_rtrequest is now ``rt_addrinfo *'' instead of
``sockaddr *''. While here, un-document RTM_RESOLVE cmd argument for
ifa_rtrequest() that became a stub after separating L2 tables in r186119.
MFC after: 1 week
- Document the following routines: pci_alloc_msi(), pci_alloc_msix(),
pci_find_cap(), pci_get_max_read_req(), pci_get_vpd_ident(),
pci_get_vpd_readonly(), pci_msi_count(), pci_msix_count(),
pci_pending_msix(), pci_release_msi(), pci_remap_msix(), and
pci_set_max_read_req().
- Group the functions into five sub-sections: raw configuration access,
locating devices, device information, device configuration, and
message signaled interrupts.
- Discourage use of pci_disable_io() and pci_enable_io() in device drivers.
The PCI bus driver handles this automatically as resources are activated.
MFC after: 2 weeks
not ACPI-specific at all, but deal with PCI power states. Also,
pci_set_powerstate() fails with EOPNOTSUPP if a request is made that the
underlying device does not support rather than falling back to somehow
setting D0.
pci_cfg_save() and pci_cfg_restore() for device drivers to use when
saving and restoring state (e.g. to handle device-specific resets).
Reviewed by: imp
MFC after: 2 weeks
The reasoning behind this, is that if we are consistent in our
documentation about the uint*_t stuff, people will be less tempted to
write new code that uses the non-standard types.
I am not going to bump the man page dates, as these changes can be
considered style nits. The meaning of the man pages is unaffected.
MFC after: 1 month
These functions take a `struct cdev *' -- not a dev_t. Inside the
kernel, dev_t has the same use as in userspace, namely to store a device
identifier.
MFC after: 2 weeks
I was considering adding it to libc as well, but last minute I thought
it would be good enough to add it to libkern exclusively. I forgot to
rename the man page and hook it up.
It seems two of the file system drivers we have in the tree, namely ufs
and ext3, use a function called `skpc()'. The meaning of this function
does not seem to be documented in FreeBSD, but it turns out one needs to
be a VAX programmer to understand what it does.
SPKC is an instruction on the VAX that does the opposite of memchr(). It
searches for the non-equal character. Add a new function called
memcchr() to the tree that has the following advantages over skpc():
- It has a name that makes more sense than skpc(). Just like strcspn()
matches the complement of strspn(), memcchr() is the complement of
memchr().
- It is faster than skpc(). Similar to our strlen() in libc, it compares
entire words, instead of single bytes. It seems that for this routine
this yields a sixfold performance increase on amd64.
- It has a man page.
objects created by shm_open(2) into the kernel's address space. This
provides a convenient way for creating shared memory buffers between
userland and the kernel without requiring custom character devices.
and DEVMETHOD() we can fully hide the explicit mention of kobj(9) from
device drivers.
- Update the example in driver.9 to use DEVMETHOD_END.
Submitted by: jhb
MFC after: 3 days
This enables locking consumers to pass their own structures around as const and
be able to assert locks embedded into those structures.
Reviewed by: ed, kib, jhb
curthread-accessing part of mtx_{,un}lock(9) when using a r210623-style
curthread implementation on sparc64, crashing the kernel in its early
cycles as PCPU isn't set up, yet (and can't be set up as OFW is one of the
things we need for that, which leads to a chicken-and-egg problem). What
happens is that due to the fact that the idea of r210623 actually is to
allow the compiler to cache invocations of curthread, it factors out
obtaining curthread needed for both mtx_lock(9) and mtx_unlock(9) to
before the branch based on kobj_mutex_inited when compiling the kernel
without the debugging options. So change kobj_class_compile_static(9)
to just never acquire kobj_mtx, effectively restricting it to its
documented use, and add a kobj_init_static(9) for initializing objects
using a class compiled with the former and that also avoids using mutex(9)
(and malloc(9)). Also assert in both of these functions that they are
used in their intended way only.
While at it, inline kobj_register_method() and kobj_unregister_method()
as there wasn't much point for factoring them out in the first place
and so that a reader of the code has to figure out the locking for
fewer functions missing a KOBJ_ASSERT.
Tested on powerpc{,64} by andreast.
Reviewed by: nwhitehorn (earlier version), jhb
MFC after: 3 days
document knlist_delete, and better document what knlist_clear does... Note
that both of these functions may sleep, and also unlock/relock the list
lock...
document knlist_init_mtx (forgotten by kib)...
other minor improvements
Reviewed by: ru (previous rev)
MFC after: 1 week
mod_cc.4 and mod_cc.9 respectively to avoid any possible confusion with the cc.1
gcc man page. Update references to these man pages where required.
Requested by: Grenville Armitage
Approved by: re (kib)
MFC after: 3 days
If it overflows before the taskqueue can run, the task will be
re-added to the taskqueue and cause a loop in the task list.
Reported by: Arnaud Lacombe <lacombar@gmail.com>
Submitted by: Ryan Stone <rysto32@gmail.com>
Reviewed by: jhb
Approved by: re (kib)
MFC after: 1 day
If a selinfo object is recorded (via selrecord()) and then it is
quickly destroyed, with the waiters missing the opportunity to awake,
at the next iteration they will find the selinfo object destroyed,
causing a PF#.
That happens because the selinfo interface has no way to drain the
waiters before to destroy the registered selinfo object. Also this
race is quite rare to get in practice, because it would require a
selrecord(), a poll request by another thread and a quick destruction
of the selrecord()'ed selinfo object.
Fix this by adding the seldrain() routine which should be called
before to destroy the selinfo objects (in order to avoid such case),
and fix the present cases where it might have already been called.
Sometimes, the context is safe enough to prevent this type of race,
like it happens in device drivers which installs selinfo objects on
poll callbacks. There, the destruction of the selinfo object happens
at driver detach time, when all the filedescriptors should be already
closed, thus there cannot be a race.
For this case, mfi(4) device driver can be set as an example, as it
implements a full correct logic for preventing this from happening.
Sponsored by: Sandvine Incorporated
Reported by: rstone
Tested by: pluknet
Reviewed by: jhb, kib
Approved by: re (bz)
MFC after: 3 weeks
