From 1f19f33e45791ea59aed048796fc68672c6723a5 Mon Sep 17 00:00:00 2001 From: Jacob McDonnell Date: Sat, 25 Apr 2026 19:59:05 -0400 Subject: docs: Removed Precompiled HTML --- static/netbsd/man9/KERNEL_LOCK.9 3.html | 228 --- static/netbsd/man9/accept_filter.9 3.html | 140 -- static/netbsd/man9/accf_data.9 3.html | 68 - static/netbsd/man9/acct_process.9 3.html | 50 - static/netbsd/man9/autoconf.9 3.html | 385 ---- static/netbsd/man9/bcdtobin.9 3.html | 51 - static/netbsd/man9/bcopy.9 3.html | 58 - static/netbsd/man9/bufq.9 3.html | 211 --- static/netbsd/man9/bus_space.9 3.html | 2110 ---------------------- static/netbsd/man9/clock.9 3.html | 103 -- static/netbsd/man9/cnmagic.9 3.html | 164 -- static/netbsd/man9/condvar.9 3.html | 362 ---- static/netbsd/man9/cons.9 3.html | 137 -- static/netbsd/man9/cprng.9 3.html | 218 --- static/netbsd/man9/cpu_configure.9 3.html | 54 - static/netbsd/man9/cpu_dumpconf.9 3.html | 69 - static/netbsd/man9/cpu_need_resched.9 3.html | 80 - static/netbsd/man9/cpu_rootconf.9 3.html | 98 - static/netbsd/man9/csf.9 3.html | 295 --- static/netbsd/man9/curproc.9 3.html | 100 - static/netbsd/man9/ddc.9 3.html | 96 - static/netbsd/man9/delay.9 3.html | 51 - static/netbsd/man9/dksubr.9 3.html | 300 --- static/netbsd/man9/dopowerhooks.9 3.html | 51 - static/netbsd/man9/doshutdownhooks.9 3.html | 53 - static/netbsd/man9/driver.9 3.html | 249 --- static/netbsd/man9/errno.9 3.html | 101 -- static/netbsd/man9/evcnt.9 3.html | 257 --- static/netbsd/man9/fileassoc.9 3.html | 338 ---- static/netbsd/man9/firmload.9 3.html | 151 -- static/netbsd/man9/flash.9 3.html | 75 - static/netbsd/man9/fstrans.9 3.html | 307 ---- static/netbsd/man9/genfs.9 3.html | 137 -- static/netbsd/man9/genfs_can_access.9 3.html | 100 - static/netbsd/man9/hardclock.9 3.html | 59 - static/netbsd/man9/heartbeat.9 3.html | 131 -- static/netbsd/man9/hz.9 3.html | 79 - static/netbsd/man9/ieee80211_proto.9 3.html | 80 - static/netbsd/man9/ieee80211_radiotap.9 3.html | 233 --- static/netbsd/man9/imax.9 3.html | 83 - static/netbsd/man9/inittodr.9 3.html | 74 - static/netbsd/man9/interrupt_distribute.9 3.html | 44 - static/netbsd/man9/intro.9 3.html | 347 ---- static/netbsd/man9/ioctl.9 3.html | 289 --- static/netbsd/man9/kcopy.9 3.html | 54 - static/netbsd/man9/kcpuset.9 3.html | 339 ---- static/netbsd/man9/kmem.9 3.html | 297 --- static/netbsd/man9/localcount.9 3.html | 170 -- static/netbsd/man9/lock.9 3.html | 49 - static/netbsd/man9/locking.9 3.html | 333 ---- static/netbsd/man9/ltsleep.9 3.html | 203 --- static/netbsd/man9/man9.x86/rdmsr.9 3.html | 87 - static/netbsd/man9/man9.x86/tsc.9 3.html | 102 -- static/netbsd/man9/memcmp.9 3.html | 55 - static/netbsd/man9/memset.9 3.html | 50 - static/netbsd/man9/microseq.9 3.html | 531 ------ static/netbsd/man9/microtime.9 3.html | 121 -- static/netbsd/man9/module.9 3.html | 539 ------ static/netbsd/man9/namecache.9 3.html | 223 --- static/netbsd/man9/nullop.9 3.html | 80 - static/netbsd/man9/optstr.9 3.html | 128 -- static/netbsd/man9/panic.9 3.html | 91 - static/netbsd/man9/pci_configure_bus.9 3.html | 256 --- static/netbsd/man9/pci_intr.9 3.html | 184 -- static/netbsd/man9/pci_msi.9 3.html | 296 --- static/netbsd/man9/pckbport.9 3.html | 319 ---- static/netbsd/man9/pcq.9 3.html | 162 -- static/netbsd/man9/pfil.9 3.html | 246 --- static/netbsd/man9/physio.9 3.html | 93 - static/netbsd/man9/pmatch.9 3.html | 59 - static/netbsd/man9/pmf.9 3.html | 320 ---- static/netbsd/man9/proc_find.9 3.html | 59 - static/netbsd/man9/pserialize.9 3.html | 185 -- static/netbsd/man9/pslist.9 3.html | 386 ---- static/netbsd/man9/ras.9 3.html | 121 -- static/netbsd/man9/roundup.9 3.html | 100 - static/netbsd/man9/rwlock.9 3.html | 256 --- static/netbsd/man9/scanc.9 3.html | 55 - static/netbsd/man9/sched_4bsd.9 3.html | 103 -- static/netbsd/man9/secmodel_extensions.9 3.html | 103 -- static/netbsd/man9/signal.9 3.html | 482 ----- static/netbsd/man9/sockopt.9 3.html | 157 -- static/netbsd/man9/strlist.9 3.html | 212 --- static/netbsd/man9/tc.9 3.html | 185 -- static/netbsd/man9/tcp_congctl.9 3.html | 87 - static/netbsd/man9/ucom.9 3.html | 204 --- static/netbsd/man9/usbd_status.9 3.html | 97 - static/netbsd/man9/usbnet.9 3.html | 669 ------- static/netbsd/man9/uvm.9 3.html | 580 ------ static/netbsd/man9/uvm_hotplug.9 3.html | 443 ----- static/netbsd/man9/uvm_map.9 3.html | 318 ---- static/netbsd/man9/vattr.9 3.html | 98 - static/netbsd/man9/vfs.9 3.html | 37 - static/netbsd/man9/vfsops.9 3.html | 461 ----- static/netbsd/man9/video.9 3.html | 182 -- static/netbsd/man9/vnodeops.9 3.html | 1441 --------------- static/netbsd/man9/wapbl.9 3.html | 424 ----- static/netbsd/man9/wsbell.9 3.html | 103 -- 98 files changed, 21601 deletions(-) delete mode 100644 static/netbsd/man9/KERNEL_LOCK.9 3.html delete mode 100644 static/netbsd/man9/accept_filter.9 3.html delete mode 100644 static/netbsd/man9/accf_data.9 3.html delete mode 100644 static/netbsd/man9/acct_process.9 3.html delete mode 100644 static/netbsd/man9/autoconf.9 3.html delete mode 100644 static/netbsd/man9/bcdtobin.9 3.html delete mode 100644 static/netbsd/man9/bcopy.9 3.html delete mode 100644 static/netbsd/man9/bufq.9 3.html delete mode 100644 static/netbsd/man9/bus_space.9 3.html delete mode 100644 static/netbsd/man9/clock.9 3.html delete mode 100644 static/netbsd/man9/cnmagic.9 3.html delete mode 100644 static/netbsd/man9/condvar.9 3.html delete mode 100644 static/netbsd/man9/cons.9 3.html delete mode 100644 static/netbsd/man9/cprng.9 3.html delete mode 100644 static/netbsd/man9/cpu_configure.9 3.html delete mode 100644 static/netbsd/man9/cpu_dumpconf.9 3.html delete mode 100644 static/netbsd/man9/cpu_need_resched.9 3.html delete mode 100644 static/netbsd/man9/cpu_rootconf.9 3.html delete mode 100644 static/netbsd/man9/csf.9 3.html delete mode 100644 static/netbsd/man9/curproc.9 3.html delete mode 100644 static/netbsd/man9/ddc.9 3.html delete mode 100644 static/netbsd/man9/delay.9 3.html delete mode 100644 static/netbsd/man9/dksubr.9 3.html delete mode 100644 static/netbsd/man9/dopowerhooks.9 3.html delete mode 100644 static/netbsd/man9/doshutdownhooks.9 3.html delete mode 100644 static/netbsd/man9/driver.9 3.html delete mode 100644 static/netbsd/man9/errno.9 3.html delete mode 100644 static/netbsd/man9/evcnt.9 3.html delete mode 100644 static/netbsd/man9/fileassoc.9 3.html delete mode 100644 static/netbsd/man9/firmload.9 3.html delete mode 100644 static/netbsd/man9/flash.9 3.html delete mode 100644 static/netbsd/man9/fstrans.9 3.html delete mode 100644 static/netbsd/man9/genfs.9 3.html delete mode 100644 static/netbsd/man9/genfs_can_access.9 3.html delete mode 100644 static/netbsd/man9/hardclock.9 3.html delete mode 100644 static/netbsd/man9/heartbeat.9 3.html delete mode 100644 static/netbsd/man9/hz.9 3.html delete mode 100644 static/netbsd/man9/ieee80211_proto.9 3.html delete mode 100644 static/netbsd/man9/ieee80211_radiotap.9 3.html delete mode 100644 static/netbsd/man9/imax.9 3.html delete mode 100644 static/netbsd/man9/inittodr.9 3.html delete mode 100644 static/netbsd/man9/interrupt_distribute.9 3.html delete mode 100644 static/netbsd/man9/intro.9 3.html delete mode 100644 static/netbsd/man9/ioctl.9 3.html delete mode 100644 static/netbsd/man9/kcopy.9 3.html delete mode 100644 static/netbsd/man9/kcpuset.9 3.html delete mode 100644 static/netbsd/man9/kmem.9 3.html delete mode 100644 static/netbsd/man9/localcount.9 3.html delete mode 100644 static/netbsd/man9/lock.9 3.html delete mode 100644 static/netbsd/man9/locking.9 3.html delete mode 100644 static/netbsd/man9/ltsleep.9 3.html delete mode 100644 static/netbsd/man9/man9.x86/rdmsr.9 3.html delete mode 100644 static/netbsd/man9/man9.x86/tsc.9 3.html delete mode 100644 static/netbsd/man9/memcmp.9 3.html delete mode 100644 static/netbsd/man9/memset.9 3.html delete mode 100644 static/netbsd/man9/microseq.9 3.html delete mode 100644 static/netbsd/man9/microtime.9 3.html delete mode 100644 static/netbsd/man9/module.9 3.html delete mode 100644 static/netbsd/man9/namecache.9 3.html delete mode 100644 static/netbsd/man9/nullop.9 3.html delete mode 100644 static/netbsd/man9/optstr.9 3.html delete mode 100644 static/netbsd/man9/panic.9 3.html delete mode 100644 static/netbsd/man9/pci_configure_bus.9 3.html delete mode 100644 static/netbsd/man9/pci_intr.9 3.html delete mode 100644 static/netbsd/man9/pci_msi.9 3.html delete mode 100644 static/netbsd/man9/pckbport.9 3.html delete mode 100644 static/netbsd/man9/pcq.9 3.html delete mode 100644 static/netbsd/man9/pfil.9 3.html delete mode 100644 static/netbsd/man9/physio.9 3.html delete mode 100644 static/netbsd/man9/pmatch.9 3.html delete mode 100644 static/netbsd/man9/pmf.9 3.html delete mode 100644 static/netbsd/man9/proc_find.9 3.html delete mode 100644 static/netbsd/man9/pserialize.9 3.html delete mode 100644 static/netbsd/man9/pslist.9 3.html delete mode 100644 static/netbsd/man9/ras.9 3.html delete mode 100644 static/netbsd/man9/roundup.9 3.html delete mode 100644 static/netbsd/man9/rwlock.9 3.html delete mode 100644 static/netbsd/man9/scanc.9 3.html delete mode 100644 static/netbsd/man9/sched_4bsd.9 3.html delete mode 100644 static/netbsd/man9/secmodel_extensions.9 3.html delete mode 100644 static/netbsd/man9/signal.9 3.html delete mode 100644 static/netbsd/man9/sockopt.9 3.html delete mode 100644 static/netbsd/man9/strlist.9 3.html delete mode 100644 static/netbsd/man9/tc.9 3.html delete mode 100644 static/netbsd/man9/tcp_congctl.9 3.html delete mode 100644 static/netbsd/man9/ucom.9 3.html delete mode 100644 static/netbsd/man9/usbd_status.9 3.html delete mode 100644 static/netbsd/man9/usbnet.9 3.html delete mode 100644 static/netbsd/man9/uvm.9 3.html delete mode 100644 static/netbsd/man9/uvm_hotplug.9 3.html delete mode 100644 static/netbsd/man9/uvm_map.9 3.html delete mode 100644 static/netbsd/man9/vattr.9 3.html delete mode 100644 static/netbsd/man9/vfs.9 3.html delete mode 100644 static/netbsd/man9/vfsops.9 3.html delete mode 100644 static/netbsd/man9/video.9 3.html delete mode 100644 static/netbsd/man9/vnodeops.9 3.html delete mode 100644 static/netbsd/man9/wapbl.9 3.html delete mode 100644 static/netbsd/man9/wsbell.9 3.html (limited to 'static/netbsd/man9') diff --git a/static/netbsd/man9/KERNEL_LOCK.9 3.html b/static/netbsd/man9/KERNEL_LOCK.9 3.html deleted file mode 100644 index bdc4092c..00000000 --- a/static/netbsd/man9/KERNEL_LOCK.9 3.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - -
KERNEL_LOCK(9)Kernel Developer's ManualKERNEL_LOCK(9)
-
-
-

-

KERNEL_LOCK — - compatibility with legacy uniprocessor code

-
-
-

-

#include - <sys/systm.h>

-

void -
- KERNEL_LOCK(int - nlocks, struct lwp - *l);

-

void -
- KERNEL_UNLOCK_ONE(struct - lwp *l);

-

void -
- KERNEL_UNLOCK_ALL(struct - lwp *l, int - *nlocksp);

-

void -
- KERNEL_UNLOCK_LAST(struct - lwp *l);

-

bool -
- KERNEL_LOCKED_P();

-
-
-

-

The KERNEL_LOCK facility serves to - gradually transition software from the kernel's legacy uniprocessor - execution model, where the kernel runs on only a single CPU and never in - parallel on multiple CPUs, to a multiprocessor system.

-

KERNEL_LOCK. - KERNEL_LOCK is meant only for gradual transition of - NetBSD to natively MP-safe code, which uses - mutex(9) or other locking(9) facilities - to synchronize between threads and interrupt handlers. Use of - KERNEL_LOCK hurts system performance and - responsiveness. This man page exists only to document the legacy API in - order to make it easier to transition away from.

-

The kernel lock, sometimes also known as ‘giant - lock’ or ‘big lock’, is a recursive exclusive spin-lock - that can be held by a CPU at any interrupt priority level and is dropped - while sleeping. This means:

-
-
recursive
-
If a CPU already holds the kernel lock, it can be acquired again and - again, as long as it is released an equal number of times.
-
exclusive
-
Only one CPU at a time can hold the kernel lock.
-
spin-lock
-
When one CPU holds the kernel lock and another CPU wants to hold it, the - second CPU ‘spins’, i.e., repeatedly executes instructions - to see if the kernel lock is available yet, until the first CPU releases - it. During this time, no other threads can run on the spinning CPU. -

This means holding the kernel lock for long periods of time, - such as nontrivial computation, must be avoided. Under - LOCKDEBUG kernels, holding the kernel lock for - too long can lead to ‘spinout’ crashes.

-
-
held by a CPU
-
The kernel lock is held by a CPU, not by a process, kthread, LWP, or - interrupt handler. It may be shared by a kthread LWP and several softint - LWPs at the same time, for example, if the softints interrupted the thread - on a CPU.
-
any interrupt priority level
-
The kernel lock does not block interrupts; subsystems - running with the kernel lock use spl(9) to synchronize - with interrupt handlers. -

Interrupt handlers that are not marked MP-safe are always run - with the kernel lock. If the interrupt arrives on a CPU where the kernel - lock is already held, it is simply taken again recursively on interrupt - entry and released to its original recursion depth on interrupt - exit.

-
-
dropped while sleeping
-
Any time the kernel sleeps to let other threads run, for any reason - including tsleep(9) or condvar(9) or - even adaptive mutex(9) locks, it releases the kernel - lock before going to sleep and then reacquires it afterward. -

This means, for instance, that although data structures - accessed only under the kernel lock won't be changed before the sleep, - they may be changed by another thread during the sleep. For example, the - following program may crash on an assertion failure because the sleep in - mutex_enter(9) can allow another CPU to run and change - the global variable x:

-
- 
	KERNEL_LOCK(1, NULL);
-	x = 42;
-	mutex_enter(...);
-	...
-	mutex_exit(...);
-	KASSERT(x == 42);
-	KERNEL_UNLOCK_ONE(NULL);
-
-

This means simply introducing calls to - mutex_enter(9) and mutex_exit(9) can - break kernel-locked assumptions. Subsystems need to be consistently - converted from KERNEL_LOCK and - spl(9) to mutex(9), - condvar(9), etc.; mixing mutex(9) - and KERNEL_LOCK usually doesn't work.

-
-
-

Holding the kernel lock does - not prevent other code from running on other CPUs at the same time. It - only prevents other - - code from running on other CPUs at the same time.

-
-
-

-
-
(nlocks, - l)
-
Acquire nlocks recursive levels of kernel lock. -

If the kernel lock is already held by another CPU, spins until - it can be acquired by this one. If the kernel lock is already held by - this CPU, records the kernel lock recursion depth and returns - immediately.

-

Most of the time - nlocks is 1, but code that deliberately releases - all of the kernel locks held by the current CPU in order to sleep and - later reacquire the same number of kernel locks will pass a value of - nlocks obtained from - ().

-
-
(l)
-
Release one level of the kernel lock. Equivalent to - (1, - l, NULL);.
-
KERNEL_UNLOCK_ALL(l, - nlocksp)
-
Store the kernel lock recursion depth at nlocksp and - release all recursive levels of the kernel lock. -

This is often used inside logic implementing sleep, around a - call to mi_switch(9), so that the same number of - recursive kernel locks can be reacquired afterward once the thread is - reawoken:

-
- 
	int nlocks;
-
-	KERNEL_UNLOCK_ALL(l, &nlocks);
-	... mi_switch(l) ...
-	KERNEL_LOCK(nlocks, l);
-
-
-
(l)
-
Release the kernel lock, which must be held at exactly one level. -

This is normally used at the end of a non-MP-safe thread, - which was known to have started with exactly one level of the kernel - lock, and is now about to exit.

-
-
()
-
True if the kernel lock is held. -

To be used only in diagnostic assertions with - KASSERT(9).

-
-
-

The legacy argument l must be - NULL or curlwp, which mean - the same thing.

-
-
-

-

Some NetBSD kernel abstractions execute - caller-specified functions with the kernel lock held by default, for - compatibility with legacy code, but can be explicitly instructed - to hold - the kernel lock by passing an MP-safe flag:

- -

The following NetBSD subsystems are still - kernel-locked and need re-engineering to take advantage of parallelism on - multiprocessor systems:

- -

All interrupt handlers at IPL_VM, or lower - (spl(9)) run with the kernel lock on most ports.

-
-
-

-

locking(9), mutex(9), - spl(9)

-
-
- - - - - -
February 13, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/accept_filter.9 3.html b/static/netbsd/man9/accept_filter.9 3.html deleted file mode 100644 index d9cd0808..00000000 --- a/static/netbsd/man9/accept_filter.9 3.html +++ /dev/null @@ -1,140 +0,0 @@ - - - - - - -
ACCEPT_FILTER(9)Kernel Developer's ManualACCEPT_FILTER(9)
-
-
-

-

accept_filter, - accept_filt_add, - accept_filt_del, - accept_filt_generic_mod_event, - accept_filt_get — filter - incoming connections

-
-
-

-

#define ACCEPT_FILTER_MOD

-

#include - <sys/param.h> -
- #include <sys/kernel.h> -
- #include <sys/sysctl.h> -
- #include <sys/signalvar.h> -
- #include <sys/socketvar.h> -
- #include - <netinet/accept_filter.h>

-

int -
- accept_filt_add(struct - accept_filter *filt);

-

int -
- accept_filt_del(char - *name);

-

int -
- accept_filt_generic_mod_event(module_t - mod, int event, - void *data);

-

struct accept_filter * -
- accept_filt_get(char - *name);

-
-
-

-

Accept filters allow an application to request that the kernel - pre-process incoming connections. This manual page describes the kernel - interface for accept filters. User applications request accept filters via - the setsockopt(2) system call, passing in an - optname of - SO_ACCEPTFILTER.

-
-
-

-

A module that wants to be an accept filter must provide a - struct accept_filter to the system:

-
-
struct accept_filter {
-	char	accf_name[16];
-	void	(*accf_callback)(struct socket *so, void *arg, int waitflag);
-	void *	(*accf_create)(struct socket *so, char *arg);
-	void	(*accf_destroy)(struct socket *so);
-	SLIST_ENTRY(accept_filter) accf_next;	/* next on the list */
-};
-
-

The module should register it with the function - accept_filt_add(), passing a pointer to a - struct accept_filter, allocated with - malloc(9).

-

The accept filters currently provided with - NetBSD (accf_data(9) and - accf_http(9)) are implemented as pseudo-devices, but an - accept filter may use any supported means of initializing and registering - itself at system startup or later, including the module framework if - supported by the running kernel.

-

The fields of struct accept_filter are as - follows:

-
-
accf_name
-
Name of the filter; this is how it will be accessed from userland.
-
accf_callback
-
The callback that the kernel will do once the connection is established. - It is the same as a socket upcall and will be called when the connection - is established and whenever new data arrives on the socket, unless the - callback modifies the socket's flags.
-
accf_create
-
Called whenever a setsockopt(2) installs the filter onto - a listening socket.
-
accf_destroy
-
Called whenever the user removes the accept filter on the socket.
-
-

The accept_filt_del() function passed the - same string used in accept_filter.accf_name during - registration with accept_filt_add(), the kernel will - then disallow and further userland use of the filter.

-

The accept_filt_get() function is used - internally to locate which accept filter to use via the - setsockopt(2) system call.

-

The accept_filt_generic_mod_event() - function can be used by accept filters which are loadable kernel modules to - add and delete themselves.

-
-
-

-

setsockopt(2), accf_data(9), - accf_http(9), malloc(9)

-
-
-

-

The accept filter mechanism was introduced in - FreeBSD 4.0. It was ported to - NetBSD by Coyote Point Systems, Inc. and appeared in - NetBSD 5.0.

-
-
-

-

This manual page was written by Alfred - Perlstein, Sheldon Hearn, and - Jeroen Ruigrok van der Werven.

-

The accept filter concept was pioneered by David - Filo at Yahoo! and refined to be a loadable module system by - Alfred Perlstein.

-
-
- - - - - -
November 12, 2008NetBSD 10.1
diff --git a/static/netbsd/man9/accf_data.9 3.html b/static/netbsd/man9/accf_data.9 3.html deleted file mode 100644 index e8bdda78..00000000 --- a/static/netbsd/man9/accf_data.9 3.html +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - -
ACCF_DATA(9)Kernel Developer's ManualACCF_DATA(9)
-
-
-

-

accf_data — buffer - incoming connections until data arrives

-
-
-

-

options INET -
- pseudo-device accf_data

-
-
-

-

This is a filter to be placed on a socket that will be using - () - to receive incoming connections.

-

It prevents the application from receiving the - connected descriptor via - () - until data arrives on the connection.

-
-
-

-

If the accf_data accept filter is present - in the kernel configuration, this will enable the data accept filter on the - socket sok.

-
-
	struct accept_filter_arg afa;
-
-	bzero(&afa, sizeof(afa));
-	strcpy(afa.af_name, "dataready");
-	setsockopt(sok, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa));
-
-
-
-

-

setsockopt(2), - accept_filter(9), accf_http(9)

-
-
-

-

The accept filter mechanism and the - accf_data filter were introduced in - FreeBSD 4.0. They were ported to - NetBSD by Coyote Point Systems and appeared in - NetBSD 5.0.

-
-
-

-

This manual page and the filter were written by - Alfred Perlstein.

-
-
- - - - - -
August 10, 2008NetBSD 10.1
diff --git a/static/netbsd/man9/acct_process.9 3.html b/static/netbsd/man9/acct_process.9 3.html deleted file mode 100644 index 1b058cfc..00000000 --- a/static/netbsd/man9/acct_process.9 3.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
ACCT_PROCESS(9)Kernel Developer's ManualACCT_PROCESS(9)
-
-
-

-

acct_process — - populate and write the process accounting record

-
-
-

-

#include - <sys/acct.h>

-

int -
- acct_process(struct - lwp *l);

-
-
-

-

The acct_process function is called when - the process exits. If accounting is turned off, it returns immediately. If - accounting is turned on via acct(2), then the - acct_process populates the accounting structure - described in acct(5), then writes the accounting record to - the file specified by acct(2).

-
-
-

-

acct_process returns 0 on success and the - same error codes as vn_rdwr(9) on failure.

-
-
-

-

acct(2), acct(5), - vn_rdwr(9).

-
-
- - - - - -
August 5, 2024NetBSD 10.1
diff --git a/static/netbsd/man9/autoconf.9 3.html b/static/netbsd/man9/autoconf.9 3.html deleted file mode 100644 index 35df3b00..00000000 --- a/static/netbsd/man9/autoconf.9 3.html +++ /dev/null @@ -1,385 +0,0 @@ - - - - - - -
AUTOCONF(9)Kernel Developer's ManualAUTOCONF(9)
-
-
-

-

autoconf, - config_search, config_found, - config_match, config_attach, - config_attach_pseudo, - config_detach, - config_detach_children, - config_deactivate, - config_defer, - config_interrupts, - config_mountroot, - config_pending_incr, - config_pending_decr, - config_finalize_register — - autoconfiguration framework

-
-
-

-

#include - <sys/param.h> -
- #include <sys/device.h> -
- #include <sys/errno.h>

-

cfdata_t -
- config_search(device_t - parent, void *aux, - const struct cfargs - *);

-

device_t -
- config_found(device_t - parent, void *aux, - cfprint_t print, - const struct cfargs - *);

-

int -
- config_match(device_t - parent, cfdata_t - cf, void *aux);

-

int -
- config_probe(device_t - parent, cfdata_t - cf, void *aux);

-

device_t -
- config_attach(device_t - parent, cfdata_t - cf, void *aux, - cfprint_t print, - const struct cfargs - *);

-

device_t -
- config_attach_pseudo(cfdata_t - cf);

-

int -
- config_detach(device_t - dev, int - flags);

-

int -
- config_detach_children(device_t - dev, int - flags);

-

int -
- config_deactivate(device_t - dev);

-

int -
- config_defer(device_t - dev, void - (*func)(device_t));

-

void -
- config_interrupts(device_t - dev, void - (*func)(device_t));

-

void -
- config_mountroot(device_t - dev, void - (*func)(device_t));

-

void -
- config_pending_incr();

-

void -
- config_pending_decr();

-

int -
- config_finalize_register(device_t - dev, int - (*func)(device_t));

-
-
-

-

Autoconfiguration is the process of matching hardware devices with - an appropriate device driver. In its most basic form, autoconfiguration - consists of the recursive process of finding and attaching all devices on a - bus, including other busses.

-

The autoconfiguration framework supports direct - configuration where the bus driver can determine the devices present. - The autoconfiguration framework also supports indirect - configuration where the drivers must probe the bus looking for the - presence of a device. Direct configuration is preferred since it can find - hardware regardless of the presence of proper drivers.

-

The autoconfiguration process occurs at system bootstrap and is - driven by a table generated from a “machine description” file - by config(1). For a description of the - config(1) “device definition” language, see - config(9).

-

Each device must have a name consisting of an alphanumeric string - that ends with a unit number. The unit number identifies an instance of the - driver. Device data structures are allocated dynamically during - autoconfiguration, giving a unique address for each instance.

-

Several of the autoconfiguration functions take a - strongly-typed variadic list of arguments to pass information from driver - autoconfiguration functions to the kernel's autoconfiguration system. This - list is constructed using the - () - macro, like this example:

-
-
config_search(self, NULL,
-    CFARGS(.search = mainbus_search,
-           .iattr = "mainbus"));
-
-

Each tag is followed by a tag-specific value.

-
-
-
submatch
-
A pointer to a ‘submatch’ function used in - direct configuration.
-
search
-
A pointer to a ‘search’ function used in - indirect configuration.
-
iattr
-
A pointer to a constant C string (const char *) - specifying an interface attribute. If a parent device carries only a - single interface attribute, then this argument may be omitted. If an - interface attribute is specified that the parent device does not carry, or - no interface attribute is specified and the parent device carries more - than one, behavior is undefined. On kernels built with the - DIAGNOSTIC option, this may result in an assertion - panic.
-
locators
-
A pointer to a constant array of integers (const int - *) containing interface attribute-specific locators.
-
devhandle
-
A devhandle_t (passed by value) corresponding to the - device being attached.
-
-
-

If no arguments are to be passed, the special value - CFARGS_NONE may be used in place of the - () - macro.

-
-
-

-
-
config_search(parent, - aux, cfargs)
-
Cfargs consumed: search, - iattr, locators. - -

The role of the search function is to call - () - for each potential child and call - config_attach() for any positive matches. If no - search function is specified, then the parent should record the return - value from config_search() and call - config_attach() itself.

-

Note that this function is designed so that it can be used to - apply an arbitrary function to all potential children. In this case - callers may choose to ignore the return value.

-
-
(parent, - aux, print, - cfargs)
-
Cfargs consumed: submatch, - iattr, locators, - devhandle. -

Performs direct configuration on a - physical device. - () - is called by the parent and in turn calls the specified submatch - function as determined by the configuration table. The submatch function - compares user-specified locators from the machine description file - against those specifying a found device, calling - () - if they match (including wildcard matching). If a submatch function is - not specified, then driver match functions are called directly. The - argument parent is the pointer to the parent's - device structure. If an interface attribute is specified, only potential - children eligible to attach to that interface attribute will be - consulted. If specified, the locators argument lists the locator values - for the found device and may be used by the submatch function and will - be recorded in the device structure of the child device. The given - aux argument describes the device that has been - found. config_found() internally uses - config_search(). The softc - structure for the matched device will be allocated, and the appropriate - driver attach function will be called. If the device is matched, the - system prints the name of the child and parent devices, and then calls - the print function to produce additional - information if desired. If no driver takes a match, the same - print function is called to complain. The print - function is called with the aux argument and, if - the matches failed, the full name (including unit number) of the parent - device, otherwise NULL. The - print function must return an integer value.

-

Two special strings, “not configured” and - “unsupported” will be appended automatically to non-driver - reports if the return value is UNCONF or - UNSUPP respectively; otherwise the function - should return the value QUIET. If a device - handle is specified, that handle will be associated with the resulting - child device structure if a driver matches.

-

() - returns a pointer to the attached device's device - structure if the device is attached, NULL - otherwise. Most callers can ignore this value, since the system will - already have printed a diagnostic.

-
-
(parent, - cf, aux)
-
Match a device (direct configuration). Invokes the driver's match function - according to the configuration table. The - config_match() function returns a nonzero integer - indicating the confidence of supporting this device and a value of 0 if - the driver doesn't support the device.
-
config_probe(parent, - cf, aux)
-
Probe for a device (indirect configuration). Invokes the driver's match - function according to the configuration table. The - config_probe() function returns a nonzero integer - to indicate a successful probe and a value of 0 otherwise. Unlike - config_match(), the return value of - config_probe() is not intended to reflect a - confidence value.
-
config_attach(parent, - cf, aux, - print, cfargs)
-
Cfargs consumed: locators, - devhandle. -

Attach a found device. Allocates the memory - for the softc structure and calls the drivers - attach function according to the configuration table. If successful, - () - returns a pointer to the device structure. If - unsuccessful, it returns NULL.

-
-
config_attach_pseudo(cf)
-
Create an instance of a pseudo-device driver. config(5) - syntax allows the creation of pseudo-devices from which regular - device_t instances can be created. Such objects are - similar to the devices that attach at the root of the device tree. -

The caller is expected to allocate - and fill the cfdata_t object and pass it to - (). - The content of that object is similar to what is returned by - config_search() for regular devices.

-
-
(dev, - flags)
-
Called by the parent to detach the child device. The second argument - flags contains detachment flags. Valid values are - DETACH_FORCE (force detachment, e.g., because of - hardware removal) and DETACH_QUIET (do not print a - notice). config_detach() returns zero if - successful and an error code otherwise. - config_detach() is always called from a thread - context, allowing condition variables to be used while the device detaches - itself.
-
(dev, - flags)
-
Iterate through all attached devices, calling - config_detach() for each child of - dev, passing flags. If - detaching any child results in an error, the iteration will halt and any - remaining devices will not be detached. - config_detach_children() returns zero if - successful and an error code otherwise.
-
(dev)
-
Called by the parent to deactivate the child device - dev. config_deactivate() is - called from interrupt context to immediately relinquish resources and - notify dependent kernel subsystems that the device is about to be - detached. At some later point config_detach() will - be called to finalise the removal of the device.
-
(dev, - func)
-
Called by the child to defer the remainder of its configuration until all - its parent's devices have been attached. At this point, the function - func is called with the argument - dev.
-
(dev, - func)
-
Called by the child to defer the remainder of its configuration until - interrupts are enabled. At this point, the function - func is called with the argument - dev.
-
(dev, - func)
-
Called by the child to defer the remainder of its configuration until the - root file system is mounted. At this point, the function - func is called with the argument - dev. This is used for devices that need to load - firmware image from a mounted file system.
-
()
-
Increment the config_pending semaphore. It is used - to account for deferred configurations before mounting the root file - system.
-
()
-
Decrement the config_pending semaphore. It is used - to account for deferred configurations before mounting the root file - system.
-
(dev, - func)
-
Register a function to be called after all real devices have been found. -

Registered functions are all executed until all of them return - 0. The callbacks should return 0 to indicate they do not require to be - called another time, but they should be aware that they still might be - in case one of them returns 1.

-
-
-
-
-

-

The autoconfiguration framework itself is implemented within the - file sys/kern/subr_autoconf.c. Data structures and - function prototypes for the framework are located in - sys/sys/device.h.

-
-
-

-

config(1), config(5), - condvar(9), config(9), - driver(9)

-
-
-

-

Autoconfiguration first appeared in - 4.1BSD. The autoconfiguration framework was - completely revised in 4.4BSD. The detach and - deactivate interfaces appeared in NetBSD 1.5.

-
-
- - - - - -
August 7, 2021NetBSD 10.1
diff --git a/static/netbsd/man9/bcdtobin.9 3.html b/static/netbsd/man9/bcdtobin.9 3.html deleted file mode 100644 index cdb38943..00000000 --- a/static/netbsd/man9/bcdtobin.9 3.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
BCDTOBIN(9)Kernel Developer's ManualBCDTOBIN(9)
-
-
-

-

bcdtobin, bintobcd - — convert a single byte between (unsigned) packed - bcd and binary

-
-
-

-

#include - <sys/systm.h>

-

unsigned int -
- bcdtobin(unsigned - int bcd);

-

unsigned int -
- bintobcd(unsigned - int bin);

-
-
-

-

The - () - and - () - functions convert a single byte between (unsigned) packed bcd and binary - encodings.

-
-
-

-

The bcdtobin() function returns the binary - value of its BCD-encoded argument, bcd. The - bintobcd() function returns the BCD encoding of its - binary argument, bin.

-
-
- - - - - -
March 11, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/bcopy.9 3.html b/static/netbsd/man9/bcopy.9 3.html deleted file mode 100644 index 2888fc62..00000000 --- a/static/netbsd/man9/bcopy.9 3.html +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - -
BCOPY(9)Kernel Developer's ManualBCOPY(9)
-
-
-

-

bcopy — copy byte - string

-
-
-

-

#include - <sys/systm.h>

-

void -
- bcopy(const - void *src, void - *dst, size_t - len);

-
-
-

-
The - () - interface is obsolete. Do not add new code using it. It will soon be purged. - Use memcpy(9) instead. (The bcopy() - function is now a macro for memcpy(9).)
-

The - () - function copies len bytes from string - src to string dst.

-

-
Unlike bcopy(3) the two strings must not - overlap!
-In the traditional BSD kernel, overlapping copies were - handled by the now-purged - () - function. If you need to copy overlapping data, see - memmove(9). -

If len is zero, no bytes are copied.

-
-
-

-

bcopy(3), memcpy(9), - memmove(9)

-
-
- - - - - -
July 7, 2001NetBSD 10.1
diff --git a/static/netbsd/man9/bufq.9 3.html b/static/netbsd/man9/bufq.9 3.html deleted file mode 100644 index c02fc983..00000000 --- a/static/netbsd/man9/bufq.9 3.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - -
BUFQ(9)Kernel Developer's ManualBUFQ(9)
-
-
-

-

bufq, bufq_init, - bufq_register, - bufq_unregister, bufq_state, - bufq_alloc, bufq_drain, - bufq_free, - bufq_getstrategyname, - bufq_move, bufq_put, - bufq_get, bufq_peek, - bufq_cancel — device buffer - queues

-
-
-

-

#include - <sys/bufq.h>

-

void -
- bufq_init(void);

-

int -
- bufq_register(struct - bufq_strat *);

-

int -
- bufq_unregister(struct - bufq_strat *);

-

int -
- bufq_alloc(struct - bufq_state **bufq, const - char *strategy, int - flags);

-

void -
- bufq_drain(struct - bufq_state *bufq);

-

void -
- bufq_free(struct - bufq_state *bufq);

-

const char * -
- bufq_getstrategyname(struct - bufq_state *bufq);

-

void -
- bufq_move(struct - bufq_state *dst, struct - bufq_state *src);

-

void -
- bufq_put(struct - bufq_state *bufq, struct - buf *bp);

-

struct buf * -
- bufq_get(struct - bufq_state *bufq);

-

struct buf * -
- bufq_peek(struct - bufq_state *bufq);

-

struct buf * -
- bufq_cancel(struct - bufq_state *bufq, struct - buf *bp);

-
-
-

-

The bufq subsystem is a set of operations - for the management of device buffer queues. Various strategies for ordering - of entries in the buffer queues can be provided by loadable kernel modules - (see module(9)). By default, the - BUFQ_FCFS and BUFQ_DISKSORT - strategies are included in the kernel; see options(4) for - more details.

-

The primary data type for using the operations is - the bufq_state structure, which is opaque for users. Each - buffer queue strategy module is defined by the - - structure, which is also opaque for users.

-
-
-

-
-
(void)
-
Initialize the bufq subsystem. This routine must - be called before any other bufq routines.
-
(bs)
-
Registers the specified buffer queue strategy module so it can be used in - subsequent operations.
-
(bs)
-
Unregisters the specified buffer queue strategy module. The routine will - fail if any buffer queues for the specified strategy are in use (see - bufq_alloc() below).
-
bufq_alloc(bufq, - strategy, flags)
-
Allocate and initialize a bufq_state descriptor. -

The argument strategy specifies a buffer - queue strategy to be used for this buffer queue. The following special - values can be used:

-

-
-
-
-
Let - () - select a strategy.
-
-
Let bufq_alloc() select a strategy, assuming - it will be used for a normal disk device.
-
-
-

Valid bits for the flags are:

-

-
-
-
-
sort by b_rawblkno
-
-
sort by - - and then by b_rawblkno
-
-
Fail if a strategy specified by strategy is not - available. In that case, bufq_alloc returns - ENOENT. If this flag is not specified, - () - will silently use one of available strategies.
-
-
-

If a specific strategy is specified but not currently - available, the bufq subsystem will attempt to - auto-load the corresponding kernel module using - module_autoload(9).

-
-
(bufq)
-
Drain a bufq_state descriptor.
-
(bufq)
-
Destroy a bufq_state descriptor.
-
(bufq)
-
Get a strategy identifier of a buffer queue, the string returned will be - NUL-terminated and it always will be a valid strategy name.
-
(dst, - src)
-
Move all requests from the buffer queue src to the - buffer queue dst.
-
(bufq, - bp)
-
Put the buf bp in the queue.
-
(bufq)
-
Get the next buf from the queue and remove it from the queue. Returns - NULL if the queue is empty.
-
(bufq)
-
Get the next buf from the queue without removal. The next buf will remain - the same until bufq_get(), - bufq_put(), or - bufq_drain() is called. Returns - NULL if the queue is empty.
-
(bufq, - bp)
-
Cancel the buf bp issued earlier on the queue. - Returns NULL if the element can not be found on - the queue or bp if it has been found and removed. - This operation can be computationally expensive if there are a lot of - buffers queued.
-
-
-
-

-

The actual code implementing the device buffer queues can be found - in the file sys/kern/subr_bufq.c. The code - implementing specific buffer queue strategies can be found in the files - sys/kern/bufq_*.c.

-
-
-

-

A list of currently available buffer queue strategies is available - via the “kern.bufq.strategies” sysctl(7) - variables.

-
-
-

-

The bufq subsystem appeared in - NetBSD 2.0.

-
-
-

-

The bufq subsystem was written by - Jürgen Hannken-Illjes - ⟨hannken@NetBSD.org⟩.

-
-
- - - - - -
November 17, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/bus_space.9 3.html b/static/netbsd/man9/bus_space.9 3.html deleted file mode 100644 index 71ce652b..00000000 --- a/static/netbsd/man9/bus_space.9 3.html +++ /dev/null @@ -1,2110 +0,0 @@ - - - - - - -
BUS_SPACE(9)Kernel Developer's ManualBUS_SPACE(9)
-
-
-

-

bus_space, - bus_space_barrier, - bus_space_copy_region_1, - bus_space_copy_region_2, - bus_space_copy_region_4, - bus_space_copy_region_8, - bus_space_free, - bus_space_handle_is_equal, - bus_space_is_equal, - bus_space_map, - bus_space_mmap, - bus_space_peek_1, - bus_space_peek_2, - bus_space_peek_4, - bus_space_peek_8, - bus_space_poke_1, - bus_space_poke_2, - bus_space_poke_4, - bus_space_poke_8, - bus_space_read_1, - bus_space_read_2, - bus_space_read_4, - bus_space_read_8, - bus_space_read_multi_1, - bus_space_read_multi_2, - bus_space_read_multi_4, - bus_space_read_multi_8, - bus_space_read_multi_stream_1, - bus_space_read_multi_stream_2, - bus_space_read_multi_stream_4, - bus_space_read_multi_stream_8, - bus_space_read_region_1, - bus_space_read_region_2, - bus_space_read_region_4, - bus_space_read_region_8, - bus_space_read_region_stream_1, - bus_space_read_region_stream_2, - bus_space_read_region_stream_4, - bus_space_read_region_stream_8, - bus_space_read_stream_1, - bus_space_read_stream_2, - bus_space_read_stream_4, - bus_space_read_stream_8, - bus_space_release, - bus_space_reservation_addr, - bus_space_reservation_init, - bus_space_reservation_size, - bus_space_reservation_map, - bus_space_reservation_unmap, - bus_space_reserve, - bus_space_reserve_subregion, - bus_space_set_region_1, - bus_space_set_region_2, - bus_space_set_region_4, - bus_space_set_region_8, - bus_space_subregion, - bus_space_tag_create, - bus_space_tag_destroy, - bus_space_unmap, - bus_space_vaddr, - bus_space_write_1, - bus_space_write_2, - bus_space_write_4, - bus_space_write_8, - bus_space_write_multi_1, - bus_space_write_multi_2, - bus_space_write_multi_4, - bus_space_write_multi_8, - bus_space_write_multi_stream_1, - bus_space_write_multi_stream_2, - bus_space_write_multi_stream_4, - bus_space_write_multi_stream_8, - bus_space_write_region_1, - bus_space_write_region_2, - bus_space_write_region_4, - bus_space_write_region_8, - bus_space_write_region_stream_1, - bus_space_write_region_stream_2, - bus_space_write_region_stream_4, - bus_space_write_region_stream_8, - bus_space_write_stream_1, - bus_space_write_stream_2, - bus_space_write_stream_4, - bus_space_write_stream_8 — - bus space manipulation functions

-
-
-

-

#include - <sys/bus.h>

-

bool -
- bus_space_handle_is_equal(bus_space_tag_t - space, bus_space_handle_t - handle1, - bus_space_handle_t - handle2);

-

bool -
- bus_space_is_equal(bus_space_tag_t - space1, bus_space_tag_t - space2);

-

void -
- bus_space_release(bus_space_tag_t - t, - bus_space_reservation_t - *bsr);

-

int -
- bus_space_reserve(bus_space_tag_t - t, bus_addr_t bpa, - bus_size_t size, - int flags, - bus_space_reservation_t - *bsrp);

-

int -
- bus_space_reserve_subregion(bus_space_tag_t - t, bus_addr_t - reg_start, bus_addr_t - reg_end, bus_size_t - size, bus_size_t - alignment, bus_size_t - boundary, int - flags, - bus_space_reservation_t - *bsrp);

-

void -
- bus_space_reservation_init(bus_space_reservation_t - *bsr, bus_addr_t - addr, bus_size_t - size);

-

bus_size_t -
- bus_space_reservation_size(bus_space_reservation_t - *bsr);

-

int -
- bus_space_reservation_map(bus_space_tag_t - t, - bus_space_reservation_t - *bsr, int flags, - bus_space_handle_t - *bshp);

-

void -
- bus_space_reservation_unmap(bus_space_tag_t - t, bus_space_handle_t - bsh, bus_size_t - size);

-

int -
- bus_space_map(bus_space_tag_t - space, bus_addr_t - address, bus_size_t - size, int flags, - bus_space_handle_t - *handlep);

-

void -
- bus_space_unmap(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - size);

-

int -
- bus_space_subregion(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, bus_size_t - size, bus_space_handle_t - *nhandlep);

-

int -
- bus_space_alloc(bus_space_tag_t - space, bus_addr_t reg_start, - bus_addr_t reg_end, bus_size_t - size, bus_size_t alignment, - bus_size_t boundary, int flags, - bus_addr_t *addrp, bus_space_handle_t - *handlep);

-

void -
- bus_space_free(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - size);

-

void * -
- bus_space_vaddr(bus_space_tag_t - space, bus_space_handle_t - handle);

-

paddr_t -
- bus_space_mmap(bus_space_tag_t - space, bus_addr_t - addr, off_t off, - int prot, - int flags);

-

int -
- bus_space_tag_create(bus_space_tag_t - obst, uint64_t - present, uint64_t - extpresent, const struct - bus_space_overrides *ov, - void *ctx, - bus_space_tag_t - *bstp);

-

void -
- bus_space_tag_destroy(bus_space_tag_t - bst);

-

int -
- bus_space_peek_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - *datap);

-

int -
- bus_space_peek_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - *datap);

-

int -
- bus_space_peek_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - *datap);

-

int -
- bus_space_peek_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - *datap);

-

int -
- bus_space_poke_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - data);

-

int -
- bus_space_poke_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - data);

-

int -
- bus_space_poke_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - data);

-

int -
- bus_space_poke_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - data);

-

uint8_t -
- bus_space_read_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset);

-

uint16_t -
- bus_space_read_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset);

-

uint32_t -
- bus_space_read_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset);

-

uint64_t -
- bus_space_read_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset);

-

void -
- bus_space_write_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - value);

-

void -
- bus_space_write_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - value);

-

void -
- bus_space_write_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - value);

-

void -
- bus_space_write_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - value);

-

void -
- bus_space_barrier(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, bus_size_t - length, int - flags);

-

void -
- bus_space_read_region_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_stream_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_stream_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_stream_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_region_stream_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_stream_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_stream_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_stream_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_region_stream_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_copy_region_1(bus_space_tag_t - space, bus_space_handle_t - srchandle, bus_size_t - srcoffset, - bus_space_handle_t - dsthandle, bus_size_t - dstoffset, bus_size_t - count);

-

void -
- bus_space_copy_region_2(bus_space_tag_t - space, bus_space_handle_t - srchandle, bus_size_t - srcoffset, - bus_space_handle_t - dsthandle, bus_size_t - dstoffset, bus_size_t - count);

-

void -
- bus_space_copy_region_4(bus_space_tag_t - space, bus_space_handle_t - srchandle, bus_size_t - srcoffset, - bus_space_handle_t - dsthandle, bus_size_t - dstoffset, bus_size_t - count);

-

void -
- bus_space_copy_region_8(bus_space_tag_t - space, bus_space_handle_t - srchandle, bus_size_t - srcoffset, - bus_space_handle_t - dsthandle, bus_size_t - dstoffset, bus_size_t - count);

-

void -
- bus_space_set_region_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - value, bus_size_t - count);

-

void -
- bus_space_set_region_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - value, bus_size_t - count);

-

void -
- bus_space_set_region_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - value, bus_size_t - count);

-

void -
- bus_space_set_region_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - value, bus_size_t - count);

-

void -
- bus_space_read_multi_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_stream_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_stream_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_stream_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_read_multi_stream_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint64_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_stream_1(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint8_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_stream_2(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint16_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_stream_4(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint32_t - *datap, bus_size_t - count);

-

void -
- bus_space_write_multi_stream_8(bus_space_tag_t - space, bus_space_handle_t - handle, bus_size_t - offset, const uint64_t - *datap, bus_size_t - count);

-
-
-

-

The bus_space functions exist to allow - device drivers machine-independent access to bus memory and register areas. - All of the functions and types described in this document can be used by - including the <sys/bus.h> - header file.

-

Many common devices are used on multiple architectures, but are - accessed differently on each because of architectural constraints. For - instance, a device which is mapped in one system's I/O space may be mapped - in memory space on a second system. On a third system, architectural - limitations might change the way registers need to be accessed (e.g., - creating a non-linear register space). In some cases, a single driver may - need to access the same type of device in multiple ways in a single system - or architecture. The goal of the bus_space functions - is to allow a single driver source file to manipulate a set of devices on - different system architectures, and to allow a single driver object file to - manipulate a set of devices on multiple bus types on a single - architecture.

-

Not all busses have to implement all functions described in this - document, though that is encouraged if the operations are logically - supported by the bus. Unimplemented functions should cause compile-time - errors if possible.

-

All of the interface definitions described in this document are - shown as function prototypes and discussed as if they were required to be - functions. Implementations are encouraged to implement prototyped - (type-checked) versions of these interfaces, but may implement them as - macros if appropriate. Machine-dependent types, variables, and functions - should be marked clearly in - <machine/bus_defs.h> and in - <machine/bus_funcs.h> to - avoid confusion with the machine-independent types and functions, and, if - possible, should be given names which make the machine-dependence clear.

-
-
-

-

Bus spaces are described by bus space tags, which can be created - only by machine-dependent code. A given machine may have several different - types of bus space (e.g., memory space and I/O space), and thus may provide - multiple different bus space tags. Individual busses or devices on a machine - may use more than one bus space tag. For instance, ISA devices are given an - ISA memory space tag and an ISA I/O space tag. Architectures may have - several different tags which represent the same type of space, for instance - because of multiple different host bus interface chipsets.

-

A range in bus space is described by a bus address and a bus size. - The bus address describes the start of the range in bus space. The bus size - describes the size of the range in bytes. Busses which are not byte - addressable may require use of bus space ranges with appropriately aligned - addresses and properly rounded sizes.

-

Access to regions of bus space is facilitated by use of bus space - handles, which are usually created by mapping a specific range of a bus - space. Handles may also be created by allocating and mapping a range of bus - space, the actual location of which is picked by the implementation within - bounds specified by the caller of the allocation function.

-

All of the bus space access functions require one bus space tag - argument, at least one handle argument, and at least one offset argument (a - bus size). The bus space tag specifies the space, each handle specifies a - region in the space, and each offset specifies the offset into the region of - the actual location(s) to be accessed. Offsets are given in bytes, though - busses may impose alignment constraints. The offset used to access data - relative to a given handle must be such that all of the data being accessed - is in the mapped region that the handle describes. Trying to access data - outside that region is an error.

-

Bus space I/O operations on mappings made - with BUS_SPACE_MAP_PREFETCHABLE or - BUS_SPACE_MAP_CACHEABLE may be reordered or combined - for performance on devices that support it, such as write-combining (a.k.a. - ‘prefetchable’) graphics framebuffers or cacheable ROM images. - The - () - function orders reads and writes in prefetchable or cacheable mappings - relative to other reads and writes in bus spaces. Barriers are needed - when - prefetchable or cacheable mappings are involved:

-
    -
  • Bus space reads and writes on non-prefetchable, non-cacheable mappings at - a single device are totally ordered with one another.
    • -
  • Ordering of memory operations on normal memory with bus space I/O for - triggering DMA or being notified of DMA completion requires - bus_dmamap_sync(9).
    • -
-

People trying to write portable drivers with the - bus_space functions should try to make minimal - assumptions about what the system allows. In particular, they should expect - that the system requires bus space addresses being accessed to be naturally - aligned (i.e., base address of handle added to offset is a multiple of the - access size), and that the system does alignment checking on pointers (i.e., - pointer to objects being read and written must point to properly-aligned - data).

-

The descriptions of the bus_space - functions given below all assume that they are called with proper arguments. - If called with invalid arguments or arguments that are out of range (e.g., - trying to access data outside of the region mapped when a given handle was - created), undefined behaviour results. In that case, they may cause the - system to halt, either intentionally (via panic) or unintentionally (by - causing a fatal trap or by some other means) or may cause improper operation - which is not immediately fatal. Functions which return void or which return - data read from bus space (i.e., functions which don't obviously return an - error code) do not fail. They could only fail if given invalid arguments, - and in that case their behaviour is undefined. Functions which take a count - of bytes have undefined results if the specified count - is zero.

-
-
-

-

Several types are defined in - <machine/bus_defs.h> to - facilitate use of the bus_space functions by - drivers.

-

-
-
bus_addr_t
-
-

The bus_addr_t type is used to describe - bus addresses. It must be an unsigned integral type capable of holding - the largest bus address usable by the architecture. This type is - primarily used when mapping and unmapping bus space.

-

-
-
bus_size_t
-
-

The bus_size_t type is used to describe - sizes of ranges in bus space. It must be an unsigned integral type - capable of holding the size of the largest bus address range usable on - the architecture. This type is used by virtually all of the - bus_space functions, describing sizes when - mapping regions and offsets into regions when performing space access - operations.

-

-
-
bus_space_tag_t
-
-

The bus_space_tag_t type is used to - describe a particular bus space on a machine. Its contents are - machine-dependent and should be considered opaque by machine-independent - code. This type is used by all bus_space - functions to name the space on which they're operating.

-

-
-
bus_space_handle_t
-
-

The bus_space_handle_t type is used to - describe a mapping of a range of bus space. Its contents are - machine-dependent and should be considered opaque by machine-independent - code. This type is used when performing bus space access operations.

-

-
-
bus_space_reservation_t
-
-

The - bus_space_reservation_t type is used to describe a - range of bus space. It logically consists of a - bus_addr_t, the first address in the range, and a - bus_size_t, the length in bytes of the range. - Machine-independent code creates and interrogates a - bus_space_reservation_t using a constructor, - (), - and accessor functions, - () - and - ().

-
-
-
-
-

-

To check whether or not one bus_space_tag_t - refers to the same space as another in machine-independent code, do not use - either memcmp(9) or the C equals (==) operator. Use - (), - instead.

-
-
-

-

Bus space must be mapped before it can be used, and should be - unmapped when it is no longer needed. The - bus_space_map(), - bus_space_reservation_map(), - bus_space_reservation_unmap(), and - bus_space_unmap() functions provide these - capabilities.

-

Some drivers need to be able to pass a - subregion of already-mapped bus space to another driver or module within a - driver. The - () - function allows such subregions to be created.

-

-
-
(space, - address, size, - flags, handlep)
-
-

The - () - function exclusively reserves and maps the region of bus space named by - the space, address, and - size arguments. If successful, it returns zero and - fills in the bus space handle pointed to by - handlep with the handle that can be used to access - the mapped region. If unsuccessful, it will return non-zero and leave - the bus space handle pointed to by handlep in an - undefined state.

-

The flags argument controls how the - space is to be mapped. Supported flags include:

-
-
-
-
Try to map the space so that accesses can be cached by the system - cache. If this flag is not specified, the implementation should map - the space so that it will not be cached. This mapping method will only - be useful in very rare occasions. -

This flag must have a value of 1 on all implementations - for backward compatibility.

-
-
-
Try to map the space so that accesses can be prefetched by the system, - and writes can be buffered. This means, accesses should be side effect - free (idempotent). The - () - methods will flush the write buffer or force actual read accesses. If - this flag is not specified, the implementation should map the space so - that it will not be prefetched or delayed.
-
-
Try to map the space so that its contents can be accessed linearly via - normal memory access methods (e.g., pointer dereferencing and - structure accesses). The bus_space_vaddr() - method can be used to obtain the kernel virtual address of the mapped - range. This is useful when software wants to do direct access to a - memory device, e.g., a frame buffer. If this flag is specified and - linear mapping is not possible, the - bus_space_map() call should fail. If this flag - is not specified, the system may map the space in whatever way is most - convenient. Use of this mapping method is not encouraged for normal - device access; where linear access is not essential, use of the - () - methods is strongly recommended.
-
-
-

Not all combinations of flags make sense or are supported with - all spaces. For instance, - BUS_SPACE_MAP_CACHEABLE may be meaningless when - used on many systems' I/O port spaces, and on some systems - BUS_SPACE_MAP_LINEAR without - BUS_SPACE_MAP_PREFETCHABLE may never work. When - the system hardware or firmware provides hints as to how spaces should - be mapped (e.g., the PCI memory mapping registers' - "prefetchable" bit), those hints should be followed for - maximum compatibility. On some systems, requesting a mapping that cannot - be satisfied (e.g., requesting a non-prefetchable mapping when the - system can only provide a prefetchable one) will cause the request to - fail.

-

Some implementations may keep track of use of bus space for - some or all bus spaces and refuse to allow duplicate allocations. This - is encouraged for bus spaces which have no notion of slot-specific space - addressing, such as ISA and VME, and for spaces which coexist with those - spaces (e.g., EISA and PCI memory and I/O spaces co-existing with ISA - memory and I/O spaces).

-

Mapped regions may contain areas for which there is no device - on the bus. If space in those areas is accessed, the results are - bus-dependent.

-

-
-
(space, - bsr, flags, - handlep)
-
-

The - () - function is similar to bus_space_map() but it - maps a region of bus space that was previously reserved by a call to - bus_space_reserve() or - bus_space_reserve_subregion(). The region is - given by the space and bsr - arguments. If successful, it returns zero and fills in the bus space - handle pointed to by handlep with the handle that - can be used to access the mapped region. If unsuccessful, it will return - non-zero and leave the bus space handle pointed to by - handlep in an undefined state.

-

A region mapped by - () - may only be unmapped by a call to - bus_space_reservation_unmap().

-

For more details, see the description of - ().

-

-
-
(space, - handle, size)
-
-

The - () - function unmaps and relinquishes a region of bus space reserved and - mapped with bus_space_map(). When unmapping a - region, the size specified should be the same as - the size given to bus_space_map() when mapping - that region.

-

After - () - is called on a handle, that handle is no longer valid. (If copies were - made of the handle they are no longer valid, either.)

-

This function will never fail. If it - would fail (e.g., because of an argument error), that indicates a - software bug which should cause a panic. In that case, - () - will never return.

-

-
-
(space, - handle, size)
-
-

The - () - function is similar to bus_space_unmap() but it - should be called on handles mapped by - bus_space_reservation_map() and only on such - handles. Unlike bus_space_unmap(), - bus_space_reservation_unmap() does not - relinquish exclusive use of the bus space named by - handle and size; that is the - job of bus_space_release().

-

-
-
(space, - handle, offset, - size, nhandlep)
-
-

The - () - function is a convenience function which makes a new handle to some - subregion of an already-mapped region of bus space. The subregion - described by the new handle starts at byte offset - offset into the region described by - handle, with the size given by - size, and must be wholly contained within the - original region.

-

If successful, - () - returns zero and fills in the bus space handle pointed to by - nhandlep. If unsuccessful, it returns non-zero and - leaves the bus space handle pointed to by nhandlep - in an undefined state. In either case, the handle described by - handle remains valid and is unmodified.

-

When done with a handle created by - (), - the handle should be thrown away. Under no circumstances should - bus_space_unmap() be used on the handle. Doing - so may confuse any resource management being done on the space, and will - result in undefined behaviour. When - bus_space_unmap() or - bus_space_free() is called on a handle, all - subregions of that handle become invalid.

-

-
-
(tag, - handle)
-
-

This method returns the kernel - virtual address of a mapped bus space if and only if it was mapped with - the BUS_SPACE_MAP_LINEAR flag. The range can be - accessed by normal (volatile) pointer dereferences. If mapped with the - BUS_SPACE_MAP_PREFETCHABLE flag, the - () - method must be used to force a particular access order.

-

-
-
(tag, - addr, off, - prot, flags)
-
-

This method is used to provide support - for memory mapping bus space into user applications. If an address space - is addressable via volatile pointer dereferences, - () - will return the physical address (possibly encoded as a - machine-dependent cookie) of the bus space indicated by - addr and off. - addr is the base address of the device or device - region, and off is the offset into that region - that is being requested. If the request is made with - BUS_SPACE_MAP_LINEAR as a flag, then a linear - region must be returned to the caller. If the region cannot be mapped - (either the address does not exist, or the constraints can not be met), - bus_space_mmap() returns - -1 to indicate failure.

-

Note that it is not necessary that the - region being requested by a - () - call be mapped into a bus_space_handle_t.

-

() - is called once per PAGE_SIZE page in the range. - The prot argument indicates the memory protection - requested by the user application for the range.

-

-
-
(space, - handle1, handle2)
-
Use bus_space_handle_is_equal() to check whether - or not handle1 and handle2 - refer to regions starting at the same address in the bus space - space.
-
-
-
-

-

Some devices require or allow bus space to be allocated by the - operating system for device use. When the devices no longer need the space, - the operating system should free it for use by other devices. The - bus_space_alloc(), - bus_space_free(), - bus_space_reserve(), - bus_space_reserve_subregion(), and - bus_space_release() functions provide these - capabilities. The functions bus_space_reserve(), - bus_space_reserve_subregion(), and - bus_space_release() are not yet available on all - architectures.

-

-
-
(space, - reg_start, reg_end, - size, alignment, - boundary, flags, - addrp, handlep)
-
-

The - () - function allocates and maps a region of bus space with the size given by - size, corresponding to the given constraints. If - successful, it returns zero, fills in the bus address pointed to by - addrp with the bus space address of the allocated - region, and fills in the bus space handle pointed to by - handlep with the handle that can be used to access - that region. If unsuccessful, it returns non-zero and leaves the bus - address pointed to by addrp and the bus space - handle pointed to by handlep in an undefined - state.

-

Constraints on the allocation are given - by the reg_start, reg_end, - alignment, and boundary - parameters. The allocated region will start at or after - reg_start and end before or at - reg_end. The alignment - constraint must be a power of two, and the allocated region will start - at an address that is an even multiple of that power of two. The - boundary constraint, if non-zero, ensures that the - region is allocated so that first address in - region / boundary has the same value as - last address in region / - boundary. If the constraints cannot be met, - () - will fail. It is an error to specify a set of constraints that can never - be met (for example, size greater than - boundary).

-

The flags parameter is the same as the - like-named parameter to bus_space_map, the same - flag values should be used, and they have the same meanings.

-

Handles created by - () - should only be freed with bus_space_free(). - Trying to use bus_space_unmap() on them causes - undefined behaviour. The bus_space_subregion() - function can be used on handles created by - bus_space_alloc().

-

-
-
(t, - bpa, size, - flags, bsrp)
-
-

The - () - function reserves, for the caller's exclusive use, - size bytes starting at the address - bpa in the space referenced by - t.

-

() - does - map the space. The caller should use - bus_space_reservation_map() to map the - reservation. flags contains a hint how the caller - may map the reservation, later. Whenever possible, callers should pass - the same flags to bus_space_reserve() as they - will pass to bus_space_reservation_map() to map - the reservation.

-

On success, - () - records the reservation at bsrp and returns 0. On - failure, bsrp is undefined, and - bus_space_reserve() returns a non-zero error - code. Possible error codes include

-
-
-
ENOMEM
-
There was not sufficient bus space at bpa to - satisfy the request.
-
EOPNOTSUPP
-
bus_space_reserve() is not supported on this - architecture, or flags was incompatible with the - bus space represented by t.
-
-
-

-
-
(t, - reg_start, reg_end, - size, alignment, - boundary, flags, - bsrp)
-
-

The - () - function reserves, for the caller's exclusive use, - size bytes in the space referenced by - t. The parameters reg_start, - reg_end, alignment, - boundary, and flags each - work alike to the bus_space_alloc() parameters - of the same names.

-

On success, - () - records the reservation at bsrp and returns 0. On - failure, bsrp is undefined, and - bus_space_reserve_subregion() returns a non-zero - error code. Possible error codes include

-
-
-
ENOMEM
-
There was not sufficient bus space at bpa to - satisfy the request.
-
EOPNOTSUPP
-
bus_space_reserve() is not supported on this - architecture, or flags was incompatible with the - bus space represented by t.
-
-
-

-
-
(t, - bsr)
-
-

The - () - function releases the bus space bsr in - t that was previously reserved by - bus_space_reserve() or - bus_space_reserve_subregion().

-

If - () - is called on a reservation that has been mapped by - bus_space_reservation_map() without subsequently - being unmapped, the behavior of the system is undefined.

-

-
-
(space, - handle, size)
-
-

The - () - function unmaps and frees a region of bus space mapped and allocated - with bus_space_alloc(). When unmapping a region, - the size specified should be the same as the size - given to bus_space_alloc() when allocating the - region.

-

After - () - is called on a handle, that handle is no longer valid. (If copies were - made of the handle, they are no longer valid, either.)

-

This function will never fail. If it - would fail (e.g., because of an argument error), that indicates a - software bug which should cause a panic. In that case, - () - will never return.

-
-
-
-
-

-

The simplest way to access bus space is to read or write a single - data item. The bus_space_read_N() and - bus_space_write_N() families of functions provide - the ability to read and write 1, 2, 4, and 8 byte data items on busses which - support those access sizes.

-

-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-

The - () - family of functions reads a 1, 2, 4, or 8 byte data item from the offset - specified by offset into the region specified by - handle of the bus space specified by - space. The location being read must lie within the - bus space region specified by handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data item being read. On some systems, not obeying this - requirement may cause incorrect data to be read, on others it may cause - a system crash.

-

Read operations done by the - () - functions may be executed out of order with respect to other read and - write operations if either are on prefetchable or cacheable mappings - unless order is enforced by use of the - bus_space_barrier() function.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-

-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-

The - () - family of functions writes a 1, 2, 4, or 8 byte data item to the offset - specified by offset into the region specified by - handle of the bus space specified by - space. The location being written must lie within - the bus space region specified by handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data item being written. On some systems, not obeying this - requirement may cause incorrect data to be written, on others it may - cause a system crash.

-

Write operations done by the - () - functions may be executed out of order with respect to other read and - write operations if either are on prefetchable or cacheable mappings - unless order is enforced by use of the - bus_space_barrier() function.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-
-
-
-
-

-

One problem with the - () - and bus_space_write_N() family of functions is that - they provide no protection against exceptions which can occur when no - physical hardware or device responds to the read or write cycles. In such a - situation, the system typically would panic due to a kernel-mode bus error. - The bus_space_peek_N() and - bus_space_poke_N() family of functions provide a - mechanism to handle these exceptions gracefully without the risk of crashing - the system.

-

As with - () - and bus_space_write_N(), the peek and poke functions - provide the ability to read and write 1, 2, 4, and 8 byte data items on - busses which support those access sizes. All of the constraints specified in - the descriptions of the bus_space_read_N() and - bus_space_write_N() functions also apply to - bus_space_peek_N() and - bus_space_poke_N().

-

The return value indicates the outcome of - the peek or poke operation. A return value of zero implies that a hardware - device is responding to the operation at the specified offset in the bus - space. A non-zero return value indicates that the kernel intercepted a - hardware exception (e.g., bus error) when the peek or poke operation was - attempted. Note that some busses are incapable of generating exceptions when - non-existent hardware is accessed. In such cases, these functions will - always return zero and the value of the data read by - () - will be unspecified.

-

Finally, it should be noted that at this - time the - () - and bus_space_poke_N() functions are not re-entrant - and should not, therefore, be used from within an interrupt service routine. - This constraint may be removed at some point in the future.

-

-
-
(space, - handle, offset, - datap)
-
-
(space, - handle, offset, - datap)
-
-
(space, - handle, offset, - datap)
-
-
(space, - handle, offset, - datap)
-
-

The - () - family of functions cautiously read a 1, 2, 4, or 8 byte data item from - the offset specified by offset in the region - specified by handle of the bus space specified by - space. The data item read is stored in the - location pointed to by datap. It is permissible - for datap to be NULL, in which case the data item - will be discarded after being read.

-

-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-

The - () - family of functions cautiously write a 1, 2, 4, or 8 byte data item - specified by value to the offset specified by - offset in the region specified by - handle of the bus space specified by - space.

-
-
-
-
-

-

Devices that support prefetchable (also known as - ‘write-combining’) or cacheable I/O may be mapped with - BUS_SPACE_MAP_PREFETCHABLE or - BUS_SPACE_MAP_CACHEABLE for higher performance by - allowing bus space read and write operations to be reordered, fused, torn, - and/or cached by the system.

-

When a driver requires ordering, e.g. to - write to a command ring in bus space and then update the command ring - pointer, the - () - function enforces it.

-

-
-
(space, - handle, offset, - length, flags)
-
-

The - () - function enforces ordering of bus space read and write operations for - the specified subregion (described by the offset - and length parameters) of the region named by - handle in the space named by - space.

-

The flags argument controls what types - of operations are to be ordered. Supported flags are:

-
-
-
-
Guarantee that any program-prior bus space read on - any bus space has returned data from the device or - memory before any program-later bus space read, bus space write, or - memory access via - (), - on the specified range in the given bus space. -

This functions similarly to - membar_acquire(3), but additionally orders bus - space I/O which membar_ops(3) may not.

-
-
-
Guarantee that any program-prior bus space read, bus space write, or - memory access via - (), - on the specified range in the given bus space, has completed before - any program-later bus space write on any bus space. -

This functions similarly to - membar_release(3), but additionally orders bus - space I/O which membar_ops(3) may not.

-
-
- | -
-
Guarantee that any program-prior bus space read, bus space write, or - memory access via - () - on any bus space has completed before any - program-later bus space read, bus space write, or memory access via - bus_space_vaddr() on any bus - space. -

Note that this is independent of the specified bus space - and range.

-

This functions similarly to - membar_sync(3), but additionally orders bus space - I/O which membar_ops(3) may not. This combination - is very unusual, and often much more expensive; most drivers do not - need it.

-
-
-
-

Example: Consider a command ring in bus space with a command - ring pointer register, and a response ring in bus space with a response - ring pointer register.

-
- 
error = bus_space_map(sc->sc_regt, ..., 0, &sc->sc_regh);
-if (error)
-	...
-error = bus_space_map(sc->sc_memt, ..., BUS_SPACE_MAP_PREFETCHABLE,
-    &sc->sc_memh);
-if (error)
-	...
-
-

To submit a command (assuming there is space in the ring), - first write it out and then update the pointer:

-
- 
i = sc->sc_nextcmdslot;
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i), cmd);
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 4, arg1);
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 8, arg2);
-...
-bus_space_write_4(sc->sc_memt, sc->sc_memh, CMDSLOT(i) + 4*n, argn);
-bus_space_barrier(sc->sc_memt, sc->sc_memh, CMDSLOT(i), 4*n,
-    BUS_SPACE_BARRIER_WRITE);
-bus_space_write_4(sc->sc_regt, sc->sc_regh, CMDPTR, i);
-sc->sc_nextcmdslot = (i + n + 1) % sc->sc_ncmdslots;
-
-

To obtain a response, read the pointer first and then the ring - data:

-
- 
ptr = bus_space_read_4(sc->sc_regt, sc->sc_regh, RESPPTR);
-while ((i = sc->sc_nextrespslot) != ptr) {
-	bus_space_barrier(sc->sc_memt, sc->sc_memh, RESPSLOT(i), 4,
-	    BUS_SPACE_BARRIER_READ);
-	status = bus_space_read_4(sc->sc_memt, sc->sc_memh, RESPSLOT(i));
-	handle_response(status);
-	sc->sc_nextrespslot = (i + 1) % sc->sc_nrespslots;
-}
-
-
-
-
-
-

-

Some devices use buffers which are mapped as regions in bus space. - Often, drivers want to copy the contents of those buffers to or from memory, - e.g., into mbufs which can be passed to higher levels of the system or from - mbufs to be output to a network. In order to allow drivers to do this as - efficiently as possible, the - () - and bus_space_write_region_N() families of functions - are provided.

-

Drivers occasionally need to copy one - region of a bus space to another, or to set all locations in a region of bus - space to contain a single value. The - () - family of functions and the bus_space_set_region_N() - family of functions allow drivers to perform these operations.

-

-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-

The - () - family of functions reads count 1, 2, 4, or 8 byte - data items from bus space starting at byte offset - offset in the region specified by - handle of the bus space specified by - space and writes them into the array specified by - datap. Each successive data item is read from an - offset 1, 2, 4, or 8 bytes after the previous data item (depending on - which function is used). All locations being read must lie within the - bus space region specified by handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data items being read and the data array pointer should be - properly aligned. On some systems, not obeying these requirements may - cause incorrect data to be read, on others it may cause a system - crash.

-

Read operations done by the - () - functions may be executed in any order. They may also be executed out of - order with respect to other read and write operations if either are on - prefetchable or cacheable mappings unless order is enforced by use of - the bus_space_barrier() function. There is no - way to insert barriers between reads of individual bus space locations - executed by the bus_space_read_region_N() - functions.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-

-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-

The - () - family of functions reads count 1, 2, 4, or 8 byte - data items from the array specified by datap and - writes them to bus space starting at byte offset - offset in the region specified by - handle of the bus space specified by - space. Each successive data item is written to an - offset 1, 2, 4, or 8 bytes after the previous data item (depending on - which function is used). All locations being written must lie within the - bus space region specified by handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data items being written and the data array pointer should - be properly aligned. On some systems, not obeying these requirements may - cause incorrect data to be written, on others it may cause a system - crash.

-

Write operations done by the - () - functions may be executed in any order. They may also be executed out of - order with respect to other read and write operations if either are on - prefetchable or cacheable mappings unless order is enforced by use of - the bus_space_barrier() function. There is no - way to insert barriers between writes of individual bus space locations - executed by the bus_space_write_region_N() - functions.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-

-
-
(space, - srchandle, srcoffset, - dsthandle, dstoffset, - count)
-
-
(space, - srchandle, srcoffset, - dsthandle, dstoffset, - count)
-
-
(space, - srchandle, srcoffset, - dsthandle, dstoffset, - count)
-
-
(space, - srchandle, srcoffset, - dsthandle, dstoffset, - count)
-
-

The - () - family of functions copies count 1, 2, 4, or 8 - byte data items in bus space from the area starting at byte offset - srcoffset in the region specified by - srchandle of the bus space specified by - space to the area starting at byte offset - dstoffset in the region specified by - dsthandle in the same bus space. Each successive - data item read or written has an offset 1, 2, 4, or 8 bytes after the - previous data item (depending on which function is used). All locations - being read and written must lie within the bus space region specified by - their respective handles.

-

For portability, the starting addresses of the regions - specified by each handle plus its respective offset should be a multiple - of the size of data items being copied. On some systems, not obeying - this requirement may cause incorrect data to be copied, on others it may - cause a system crash.

-

Read and write operations done - by the - () - functions may be executed in any order. They may also be executed out of - order with respect to other read and write operations if either are on - prefetchable or cacheable mappings unless order is enforced by use of - the bus_space_barrier() function. There is no - way to insert barriers between reads or writes of individual bus space - locations executed by the - bus_space_copy_region_N() functions.

-

Overlapping copies between - different subregions of a single region of bus space are handled - correctly by the - () - functions.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-

-
-
(space, - handle, offset, - value, count)
-
-
(space, - handle, offset, - value, count)
-
-
(space, - handle, offset, - value, count)
-
-
(space, - handle, offset, - value, count)
-
-

The - () - family of functions writes the given value to - count 1, 2, 4, or 8 byte data items in bus space - starting at byte offset offset in the region - specified by handle of the bus space specified by - space. Each successive data item has an offset 1, - 2, 4, or 8 bytes after the previous data item (depending on which - function is used). All locations being written must lie within the bus - space region specified by handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data items being written. On some systems, not obeying this - requirement may cause incorrect data to be written, on others it may - cause a system crash.

-

Write operations done by the - () - functions may be executed in any order. They may also be executed out of - order with respect to other read and write operations if either are on - prefetchable or cacheable mappings unless order is enforced by use of - the bus_space_barrier() function. There is no - way to insert barriers between writes of individual bus space locations - executed by the bus_space_set_region_N() - functions.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-
-
-
-
-

-

Some devices implement single locations in bus space which are to - be read or written multiple times to communicate data, e.g., some ethernet - devices' packet buffer FIFOs. In order to allow drivers to manipulate these - types of devices as efficiently as possible, the - () - and bus_space_write_multi_N() families of functions - are provided.

-

-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-

The - () - family of functions reads count 1, 2, 4, or 8 byte - data items from bus space at byte offset offset in - the region specified by handle of the bus space - specified by space and writes them into the array - specified by datap. Each successive data item is - read from the same location in bus space. The location being read must - lie within the bus space region specified by - handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data items being read and the data array pointer should be - properly aligned. On some systems, not obeying these requirements may - cause incorrect data to be read, on others it may cause a system - crash.

-

Read operations done by the - () - functions may be executed out of order with respect to other read and - write operations if the latter are on prefetchable or cacheable mappings - unless order is enforced by use of the - bus_space_barrier() function. - bus_space_read_multi_N() makes no sense itself - on prefetchable or cacheable mappings.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-

-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-

The - () - family of functions reads count 1, 2, 4, or 8 byte - data items from the array specified by datap and - writes them into bus space at byte offset offset - in the region specified by handle of the bus space - specified by space. Each successive data item is - written to the same location in bus space. The location being written - must lie within the bus space region specified by - handle.

-

For portability, the starting address of the region specified - by handle plus the offset should be a multiple of - the size of data items being written and the data array pointer should - be properly aligned. On some systems, not obeying these requirements may - cause incorrect data to be written, on others it may cause a system - crash.

-

Write operations done by the - () - functions may be executed out of order with respect to other read and - write operations if the latter are on prefetchable or cacheable mappings - unless order is enforced by use of the - bus_space_barrier() function. - bus_space_write_multi_N() makes no sense itself - on prefetchable or cacheable mappings.

-

These functions will never fail. If they would fail (e.g., - because of an argument error), that indicates a software bug which - should cause a panic. In that case, they will never return.

-
-
-
-
-

-

Most of the bus_space functions imply a - host byte-order and a bus byte-order and take care of any translation for - the caller. In some cases, however, hardware may map a FIFO or some other - memory region for which the caller may want to use multi-word, yet - untranslated access. Access to these types of memory regions should be with - the - () - functions.

-

-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-
(space, - handle, offset)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - value)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
(space, - handle, offset, - datap, count)
-
-
-

These functions are defined just as their non-stream counterparts, - except that they provide no byte-order translation.

-
-
-

-
-
(obst, - present, extpresent, - ov, ctx, - bstp)
-
Create a copy of the tag obst at - *bstp. Except for the behavior overridden by - ov, *bstp inherits the - behavior of obst under - bus_space calls. -

ov contains function pointers - corresponding to bus_space routines. Each - function pointer has a corresponding bit in - present or extpresent, and - if that bit is 1, the function pointer overrides the corresponding - bus_space call for the new tag. Any combination - of these bits may be set in present:

-

-
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-
 
-
-

() - does not copy ov. After a new tag is created by - bus_space_tag_create(), ov - must not be destroyed until after the tag is destroyed by - bus_space_tag_destroy().

-

The first argument of every override-function is a - void *, and ctx is passed in - that argument.

-

Return 0 if the call succeeds. Return - EOPNOTSUPP if the architecture does not support - overrides. Return EINVAL if - present is 0, if ov is - NULL, or if present - indicates that an override is present, but the corresponding override in - ov is NULL.

-

If the call does not succeed, *bstp is - undefined.

-
-
(bst)
-
Destroy a tag, bst, created by a prior call to - bus_space_tag_create(). If - bst was not created by - bus_space_tag_create(), results are undefined. If - bst was already destroyed, results are - undefined.
-
-
-
-

-

The definition of the bus_space functions - should not yet be considered finalized. There are several changes and - improvements which should be explored, including:

-
    -
  • Exporting the bus_space functions to userland so - that applications (such as X servers) have easier, more portable access to - device space.
    • -
  • Redefining bus space tags and handles so that machine-independent bus - interface drivers (for example PCI to VME bridges) could define and - implement bus spaces without requiring machine-dependent code. If this is - done, it should be done in such a way that machine-dependent optimizations - should remain possible.
    • -
  • Converting bus spaces (such as PCI configuration space) which currently - use space-specific access methods to use the - bus_space functions where that is - appropriate.
    • -
  • Redefining the way bus space is mapped and allocated, so that mapping and - allocation are done with bus specific functions which return bus space - tags. This would allow further optimization than is currently possible, - and would also ease translation of the bus_space - functions into user space (since mapping in user space would look like it - just used a different bus-specific mapping function).
    • -
-
-
-

-

The current version of the bus_space - interface specification differs slightly from the original specification - that came into wide use. A few of the function names and arguments have - changed for consistency and increased functionality. Drivers that were - written to the old, deprecated specification can be compiled by defining the - __BUS_SPACE_COMPAT_OLDDEFS preprocessor symbol - before including - <sys/bus.h>.

-
-
-

-

membar_ops(3), bus_dma(9)

-
-
-

-

The bus_space functions were introduced in - a different form (memory and I/O spaces were accessed via different sets of - functions) in NetBSD 1.2. The functions were merged - to work on generic “spaces” early in the - NetBSD 1.3 development cycle, and many drivers were - converted to use them. This document was written later during the - NetBSD 1.3 development cycle and the specification - was updated to fix some consistency problems and to add some missing - functionality.

-
-
-

-

The bus_space interfaces were designed and - implemented by the NetBSD developer community. - Primary contributors and implementors were Chris - Demetriou, Jason Thorpe, and - Charles Hannum, but the rest of the - NetBSD developers and the user community played a - significant role in development.

-

Chris Demetriou wrote this manual - page.

-
-
- - - - - -
August 12, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/clock.9 3.html b/static/netbsd/man9/clock.9 3.html deleted file mode 100644 index 5bf14a78..00000000 --- a/static/netbsd/man9/clock.9 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
CLOCK(9)Kernel Developer's ManualCLOCK(9)
-
-
-

-

days_in_month, - is_leap_year, days_per_year - — handy time utilities

-
-
-

-

#include - <sys/clock.h>

-

#define SECS_PER_MINUTE 60 -
- #define SECS_PER_HOUR 3600 -
- #define SECS_PER_DAY 86400 -
- #define DAYS_PER_COMMON_YEAR 365 -
- #define DAYS_PER_LEAP_YEAR 366 -
- #define SECS_PER_COMMON_YEAR (SECS_PER_DAY * - DAYS_PER_COMMON_YEAR) -
- #define SECS_PER_LEAP_YEAR (SECS_PER_DAY * - DAYS_PER_LEAP_YEAR)

-

static inline int -
- days_in_month(int - m);

-

static inline int -
- is_leap_year(uint64_t - year);

-

static inline int -
- days_per_year(uint64_t - year);

-
-
-

-

The <sys/clock.h> - file provides handy time constants and static inline - functions.

-
-
-

-

The - () - function returns the number of days in the given month. - days_in_month() assumes 28 days for February. If the - input value is out of the valid range (1-12) then the function returns - -1.

-

The - () - and - () - functions take as the input parameter a value in the Gregorian year - format.

-
-
-

-

bintime(9), boottime(9), - time_second(9), time_uptime(9), - todr_gettime(9)

-
-
-

-

The <sys/clock.h> - header with handy utilities originated from - <dev/clock_subr.h>, which - originated from - <arch/hp300/hp300/clock.c>.

-

The - <arch/hp300/hp300/clock.c> - file first appeared in NetBSD 0.8 as a set of hp300 - time-converting functions. - <dev/clock_subr.h> first - appeared in NetBSD 1.3 as a shared list of functions - to convert between “year/month/day/hour/minute/second” and - seconds since 1970 (“POSIX time”). The - <sys/clock.h> file first - appeared in NetBSD 8.

-
-
-

-

Kamil Rytarowski

-
-
- - - - - -
December 26, 2014NetBSD 10.1
diff --git a/static/netbsd/man9/cnmagic.9 3.html b/static/netbsd/man9/cnmagic.9 3.html deleted file mode 100644 index ea61d72b..00000000 --- a/static/netbsd/man9/cnmagic.9 3.html +++ /dev/null @@ -1,164 +0,0 @@ - - - - - - -
CNMAGIC(9)Kernel Developer's ManualCNMAGIC(9)
-
-
-

-

cn_init_magic, - cn_trap, cn_isconsole, - cn_check_magic, - cn_destroy_magic, - cn_set_magic, cn_get_magic - — console magic key sequence management

-
-
-

-

#include - <sys/systm.h>

-

void -
- cn_init_magic(cnm_state_t - *cnms);

-

void -
- cn_trap();

-

int -
- cn_isconsole(dev_t - dev);

-

void -
- cn_check_magic(dev_t - dev, int k, - cnm_state_t *cnms);

-

void -
- cn_destroy_magic(cnm_state_t - *cnms);

-

int -
- cn_set_magic(char - *magic);

-

int -
- cn_get_magic(char - *magic, int - len);

-
-
-

-

The NetBSD console magic key sequence - management framework is designed to provide flexible methods to set, change, - and detect magic key sequences on console devices and break into the - debugger or ROM monitor with a minimum of interrupt latency.

-

Drivers that generate console input should make - use of these routines. A different cnm_state_t should - be used for each separate input stream. Multiple devices that share the same - input stream, such as USB keyboards, can share the same - cnm_state_t. Once a cnm_state_t - is allocated, it should be initialized with - () - so it can be used by - (). - If a driver thinks it might be the console input device it can set the magic - sequence with cn_set_magic() to any arbitrary - string. Whenever the driver receives input, it should call - cn_check_magic() to process the data and determine - whether the magic sequence has been hit.

-

The magic key sequence can be accessed through the - hw.cnmagic sysctl variable. - This is the raw data and may be keycodes rather than processed characters, - depending on the console device.

-
-
-

-

The following functions describe the console magic interface.

-
-
(cnm)
-
Initialize the console magic state pointed to by cnm - to a usable state.
-
()
-
Trap into the kernel debugger or ROM monitor. By default this routine is - defined to be - () - but can be overridden in MI header files.
-
(dev)
-
Determine whether a given dev is the system console. - This macro tests to see if dev is the same as - cn_tab->cn_dev but can be overridden in MI header - files.
-
cn_check_magic(dev, - k, cnms)
-
All input should be passed through - cn_check_magic() so the state machine remains in a - consistent state. cn_check_magic() calls - cn_isconsole() with dev to - determine if this is the console. If that returns true then it runs the - input value k through the state machine. If the - state machine completes a match of the current console magic sequence - cn_trap() is called. Some input may need to be - translated to state machine values such as the serial line - BREAK sequence.
-
(cnms)
-
This should be called once what cnms points to is no - longer needed.
-
cn_set_magic(magic)
-
cn_set_magic() encodes a - nul terminated arbitrary string into values that - can be used by the state machine and installs it as the global magic - sequence. The escape sequence is character value - 0x27 and can be used to encode special values: -

-
-
-
0x27
-
The literal value 0x27.
-
0x01
-
Serial BREAK sequence.
-
0x02
-
- character.
-
-
-

Returns 0 on success or a non-zero - error value.

-
-
(magic, - len)
-
Extract the current magic sequence from the state machine and return up to - len bytes of it in the buffer pointed to by - magic. It uses the same encoding accepted by - (). - Returns 0 on success or a non-zero error - value.
-
-
-
-

-

ddb(4), sysctl(8), - cons(9)

-
-
-

-

The NetBSD console magic key sequence - management framework first appeared in NetBSD - 1.6.

-
-
-

-

The NetBSD console magic key sequence - management framework was designed and implemented by - Eduardo Horvath ⟨eeh@NetBSD.org⟩.

-
-
- - - - - -
July 7, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/condvar.9 3.html b/static/netbsd/man9/condvar.9 3.html deleted file mode 100644 index 1def4ca5..00000000 --- a/static/netbsd/man9/condvar.9 3.html +++ /dev/null @@ -1,362 +0,0 @@ - - - - - - -
CONDVAR(9)Kernel Developer's ManualCONDVAR(9)
-
-
-

-

cv, condvar, - cv_init, cv_destroy, - cv_wait, cv_wait_sig, - cv_timedwait, - cv_timedwait_sig, - cv_timedwaitbt, - cv_timedwaitbt_sig, - cv_signal, cv_broadcast, - cv_has_waiters — condition - variables

-
-
-

-

#include - <sys/condvar.h>

-

void -
- cv_init(kcondvar_t - *cv, const char - *wmesg);

-

void -
- cv_destroy(kcondvar_t - *cv);

-

void -
- cv_wait(kcondvar_t - *cv, kmutex_t - *mtx);

-

int -
- cv_wait_sig(kcondvar_t - *cv, kmutex_t - *mtx);

-

int -
- cv_timedwait(kcondvar_t - *cv, kmutex_t *mtx, - int ticks);

-

int -
- cv_timedwait_sig(kcondvar_t - *cv, kmutex_t *mtx, - int ticks);

-

int -
- cv_timedwaitbt(kcondvar_t - *cv, kmutex_t *mtx, - struct bintime *bt, - const struct bintime - *epsilon);

-

int -
- cv_timedwaitbt_sig(kcondvar_t - *cv, kmutex_t *mtx, - struct bintime *bt, - const struct bintime - *epsilon);

-

void -
- cv_signal(kcondvar_t - *cv);

-

void -
- cv_broadcast(kcondvar_t - *cv);

-

bool -
- cv_has_waiters(kcondvar_t - *cv);

-

-
- options DIAGNOSTIC -
- options LOCKDEBUG

-
-
-

-

Condition variables (CVs) are used in the kernel to synchronize - access to resources that are limited (for example, memory) and to wait for - pending I/O operations to complete.

-

The kcondvar_t type provides storage for the - CV object. This should be treated as an opaque object and not examined - directly by consumers.

-
-
-

-
-
options DIAGNOSTIC
-
-

Kernels compiled with the DIAGNOSTIC - option perform basic sanity checks on CV operations.

-
-
options LOCKDEBUG
-
-

Kernels compiled with the LOCKDEBUG - option perform potentially CPU intensive sanity checks on CV - operations.

-
-
-
-
-

-
-
(cv, - wmesg)
-
-

Initialize a CV for use. No other operations can be performed - on the CV until it has been initialized.

-

The wmesg argument specifies a string of - no more than 8 characters that describes the resource or condition - associated with the CV. The kernel does not use this argument directly - but makes it available for utilities such as ps(1) to - display.

-
-
(cv)
-
-

Release resources used by a CV. If there - could be waiters, they should be awoken first with - (). - The CV must not be used afterwards.

-
-
cv_wait(cv, - mtx)
-
-

Cause the current LWP to wait non-interruptably - for access to a resource, or for an I/O operation to complete. The LWP - will resume execution when awoken by another thread using - () - or cv_broadcast().

-

mtx specifies a kernel - mutex to be used as an interlock, and must be held by the calling LWP on - entry to - (). - It will be released once the LWP has prepared to sleep, and will be - reacquired before cv_wait() returns.

-

A small window exists between testing for - availability of a resource and waiting for the resource with - (), - in which the resource may become available again. The interlock is used - to guarantee that the resource will not be signalled as available until - the calling LWP has begun to wait for it.

-

Non-interruptable waits have the potential to deadlock the - system, and so must be kept short (typically, under one second).

-

() - is typically used within a loop or restartable code sequence, because it - may awaken spuriously. The calling LWP should re-check the condition - that caused the wait. If necessary, the calling LWP may call - cv_wait() again to continue waiting.

-
-
cv_wait_sig(cv, - mtx)
-
-

As per - (), - but causes the current LWP to wait interruptably. If the LWP receives a - signal, or is interrupted by another condition such as its containing - process exiting, the wait is ended early and an error code returned.

-

If - () - returns as a result of a signal, the return value is - ERESTART if the signal has the - SA_RESTART property. If awoken normally, the - value is zero, and EINTR under all other - conditions.

-
-
cv_timedwait(cv, - mtx, ticks)
-
-

As per - (), - but will return early if a timeout specified by the - ticks argument expires.

-

ticks is an - architecture and system dependent value related to the number of clock - interrupts per second. See hz(9) for details. The - mstohz(9) macro can be used to convert a timeout - expressed in milliseconds to one suitable for - (). - If the ticks argument is zero, - cv_timedwait() behaves exactly like - cv_wait().

-

If the timeout expires before the LWP is awoken, the return - value is EWOULDBLOCK. If awoken normally, the - return value is zero.

-
-
(cv, - mtx, ticks)
-
-

As per - (), - but also accepts a timeout value and will return - EWOULDBLOCK if the timeout expires.

-
-
cv_timedwaitbt(cv, - mtx, bt, - epsilon)
-
 
-
cv_timedwaitbt_sig(cv, - mtx, bt, - epsilon)
-
-

As per - () - and cv_wait_sig(), but will return early if the - duration bt has elapsed, immediately if - bt is zero. On return, - cv_timedwaitbt() and - cv_timedwaitbt_sig() subtract the time elapsed - from bt in place, or set it to zero if there is no - time remaining.

-

Note that - () - and - () - may return zero indicating success, rather than - EWOULDBLOCK, even if they set the timeout to - zero; this means that the caller must re-check the condition in order to - avoid potentially losing a cv_signal(), but the - - wait will time out immediately.

-

The hint epsilon, which can be - DEFAULT_TIMEOUT_EPSILON if in doubt, requests - that the wakeup not be delayed more than bt - + epsilon, so that the - system can coalesce multiple wakeups within their respective epsilons - into a single high-resolution clock interrupt or choose to use cheaper - low-resolution clock interrupts instead.

-

However, the system is still limited by its best clock - interrupt resolution and by scheduling competition, which may delay the - wakeup by more than bt + - epsilon.

-
-
(cv)
-
-

Awaken one LWP waiting on the specified condition variable. - Where there are waiters sleeping non-interruptaby, more than one LWP may - be awoken. This can be used to avoid a "thundering herd" - problem, where a large number of LWPs are awoken following an event, but - only one LWP can process the event.

-

The mutex passed to the wait function - (mtx) should be held or have been released - immediately before - () - is called.

-

(Note that - () - is erroneously named in that it does not send a signal in the - traditional sense to LWPs waiting on a CV.)

-
-
cv_broadcast(cv)
-
-

Awaken all LWPs waiting on the specified condition - variable.

-

As with - (), - the mutex passed to the wait function (mtx) should - be held or have been released immediately before - cv_broadcast() is called.

-
-
cv_has_waiters(cv)
-
-

Return true if one or more LWPs are - waiting on the specified condition variable.

-

() - cannot test reliably for interruptable waits. It should only be used to - test for non-interruptable waits made using - cv_wait().

-

() - should only be used when making diagnostic assertions, and must be - called while holding the interlocking mutex passed to - cv_wait().

-
-
-
-
-

-

Consuming a resource:

-
-
	/*
-	 * Lock the resource.  Its mutex will also serve as the
-	 * interlock.
-	 */
-	mutex_enter(&res->mutex);
-
-	/*
-	 * Wait for the resource to become available.  Timeout after
-	 * five seconds.  If the resource is not available within the
-	 * allotted time, return an error.
-	 */
-	struct bintime timeout = { .sec = 5, .frac = 0 };
-	while (res->state == BUSY) {
-		error = cv_timedwaitbt(&res->condvar,
-		    &res->mutex, &timeout, DEFAULT_TIMEOUT_EPSILON);
-		if (error) {
-			KASSERT(error == EWOULDBLOCK);
-			mutex_exit(&res->mutex);
-			return ETIMEDOUT;
-		}
-	}
-
-	/*
-	 * It's now available to us.  Take ownership of the
-	 * resource, and consume it.
-	 */
-	res->state = BUSY;
-	mutex_exit(&res->mutex);
-	consume(res);
-
-

Releasing a resource for the next consumer to use:

-
-
	mutex_enter(&res->mutex);
-	res->state = IDLE;
-	cv_signal(&res->condvar);
-	mutex_exit(&res->mutex);
-
-
-
-

-

The core of the CV implementation is in - sys/kern/kern_condvar.c.

-

The header file sys/sys/condvar.h - describes the public interface.

-
-
-

-

sigaction(2), membar_ops(3), - errno(9), mstohz(9), - mutex(9), rwlock(9)

-

-

Jim Mauro and - Richard McDougall, Solaris - Internals: Core Kernel Architecture, Prentice - Hall, 2001, ISBN - 0-13-022496-0.

-
-
-

-

The CV primitives first appeared in NetBSD - 5.0. The cv_timedwaitbt() and - cv_timedwaitbt_sig() primitives first appeared in - NetBSD 9.0.

-
-
- - - - - -
September 7, 2023NetBSD 10.1
diff --git a/static/netbsd/man9/cons.9 3.html b/static/netbsd/man9/cons.9 3.html deleted file mode 100644 index 2983cb8d..00000000 --- a/static/netbsd/man9/cons.9 3.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - -
CONS(9)Kernel Developer's ManualCONS(9)
-
-
-

-

cnbell, cnflush, - cngetc, cngetsn, - cnhalt, cnpollc, - cnputc — console access - interface

-
-
-

-

#include - <dev/cons.h>

-

void -
- cnbell(u_int - pitch, u_int - period, u_int - volume);

-

void -
- cnflush(void);

-

int -
- cngetc(void);

-

int -
- cngetsn(char - *cp, int size);

-

void -
- cnhalt(void);

-

void -
- cnpollc(int - on);

-

void -
- cnputc(int - c);

-
-
-

-

These functions operate over the current console device. The - console must be initialized before these functions can be used.

-

Console input polling functions - (), - () - and - () - are only to be used during initial system boot, e.g., when asking for root - and dump device or to get necessary user input within mountroothooks. Once - the system boots, user input is read via standard tty(4) - facilities.

-

The following is a brief description of each function:

-
-
()
-
Ring a bell at appropriate pitch, for duration of - period milliseconds at given - volume. Note that the volume - value is ignored commonly.
-
()
-
Waits for all pending output to finish.
-
cngetc()
-
Poll (busy wait) for an input and return the input key. Returns 0 if there - is no console input device. cnpollc() - be called - before cngetc() could be used. - cngetc() should be used during kernel startup - only.
-
cngetsn()
-
Read one line of user input, stop reading once the newline key is input. - Input is echoed back. This uses cnpollc() and - cngetc(). Number of read characters is - size at maximum, user is notified by console bell - when the end of input buffer is reached. <Backspace> key works as - expected. <@> or <CTRL>-u make - cngetsn() discard input read so far, print newline - and wait for next input. cngetsn() returns number - of characters actually read, excluding the final newline. - cp is - zero-ended - before return. cngetsn() should be used during - kernel startup only.
-
()
-
Terminates the console device (i.e. cleanly shuts down the console - hardware.)
-
cnpollc()
-
Switch the console driver to polling mode if on is - nonzero, or back to interrupt driven mode if on is - zero. cnpollc() should be used during kernel - startup only.
-
()
-
Console kernel output character routine. Commonly, kernel code uses - printf(9) rather than using this low-level - interface.
-
-
-
-

-

This waits until a <Enter> key is pressed:

-
-
int c;
-
-cnpollc(1);
-for(;;) {
-	c = cngetc();
-	if ((c == '\r' || (c == '\n')) {
-		printf("\n");
-		break;
-	}
-}
-cnpollc(0);
-
-
-
-

-

pckbd(4), pcppi(4), - tty(4), wscons(4), - wskbd(4), printf(9), - spl(9), wscons(9)

-
-
- - - - - -
June 8, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/cprng.9 3.html b/static/netbsd/man9/cprng.9 3.html deleted file mode 100644 index 4949c78c..00000000 --- a/static/netbsd/man9/cprng.9 3.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - -
CPRNG(9)Kernel Developer's ManualCPRNG(9)
-
-
-

-

cprng, - cprng_strong_create, - cprng_strong_destroy, - cprng_strong, - cprng_strong32, - cprng_strong64, cprng_fast, - cprng_fast32, cprng_fast64 - — cryptographic pseudorandom number - generators

-
-
-

-

#include - <sys/cprng.h>

-

cprng_strong_t * -
- cprng_strong_create(const - char *name, int - ipl, int - flags);

-

void -
- cprng_strong_destroy(cprng_strong_t - *cprng);

-

size_t -
- cprng_strong(cprng_strong_t - *cprng, void *buf, - size_t len, - int flags);

-

uint32_t -
- cprng_strong32(void);

-

uint64_t -
- cprng_strong64(void);

-

size_t -
- cprng_fast(void - *buf, size_t - len);

-

uint32_t -
- cprng_fast32(void);

-

uint64_t -
- cprng_fast64(void);

-
-
#define CPRNG_MAX_LEN   524288
-
-
-
-

-

The cprng family of functions provide - cryptographic pseudorandom number generators automatically seeded from the - kernel entropy pool. All applications in the kernel requiring random data or - random choices should use the cprng_strong family of - functions, unless performance constraints demand otherwise.

-

The cprng_fast family of functions may be - used in applications that can tolerate exposure of past random data, such as - initialization vectors or transaction ids that are sent over the internet - anyway, if the applications require higher throughput or lower per-request - latency than the cprng_strong family of functions - provide. If in doubt, choose cprng_strong.

-

A single instance of the fast generator - serves the entire kernel. A well-known instance of the strong generator, - kern_cprng, may be used by any in-kernel caller, but - separately seeded instances of the strong generator can also be created by - calling - ().

-

The cprng - functions may be used in soft interrupt context, except for - () - and cprng_strong_destroy() which are allowed only at - IPL_NONE in thread context; see - spl(9).

-

The cprng functions replace the legacy - arc4random(9) and rnd_extract_data(9) - functions.

-
-
-

-
-
(name, - ipl, flags)
-
Create an instance of the cprng_strong generator. This generator currently - implements the NIST SP 800-90A Hash_DRBG with SHA-256 as the hash - function. -

The name argument is used to - “personalize” the Hash_DRBG according to the standard, so - that its initial state will depend both on seed material from the - entropy pool and also on the personalization string (name).

-

The ipl argument specifies the interrupt - priority level for the mutex which will serialize access to the new - instance of the generator (see spl(9)), and must be no - higher than IPL_SOFTSERIAL.

-

The flags argument must be zero.

-

Creation will succeed even if full entropy for the generator - is not available. In this case, the first request to read from the - generator may cause reseeding.

-

() - may sleep to allocate memory.

-
-
cprng_strong_destroy(cprng)
-
Destroy cprng. -

() - may sleep.

-
-
(cprng, - buf, len, - flags)
-
Fill memory location buf with up to - len bytes from the generator - cprng, and return the number of bytes. - len must be at most - CPRNG_MAX_LEN. flags must be - zero.
-
cprng_strong32()
-
Generate 32 bits using the kern_cprng strong - generator. -

() - does not sleep.

-
-
cprng_strong64()
-
Generate 64 bits using the kern_cprng strong - generator. -

() - does not sleep.

-
-
cprng_fast(buf, - len)
-
Fill memory location buf with - len bytes from the fast generator. -

() - does not sleep.

-
-
cprng_fast32()
-
Generate 32 bits using the fast generator. -

() - does not sleep.

-
-
cprng_fast64()
-
Generate 64 bits using the fast generator. -

() - does not sleep.

-
-
-
-
-

-

The cprng family of functions provide the - following security properties:

-
    -
  • An attacker who has seen some outputs of any of the - cprng functions cannot predict past or future - unseen outputs.
    • -
  • An attacker who has compromised kernel memory cannot predict past outputs - of the cprng_strong functions. However, such an - attacker may be able to predict past outputs of the - cprng_fast functions.
    • -
-

The second property is sometimes called “backtracking - resistance”, “forward secrecy”, or “key - erasure” in the cryptography literature. The - cprng_strong functions provide backtracking - resistance; the cprng_fast functions do not.

-
-
-

-

The cprng_strong functions are implemented - in sys/kern/subr_cprng.c, and use the NIST SP - 800-90A Hash_DRBG implementation in - sys/crypto/nist_hash_drbg. The - cprng_fast functions are implemented in - sys/crypto/cprng_fast/cprng_fast.c, and use the - ChaCha8 stream cipher.

-
-
-

-

condvar(9), rnd(9), - spl(9)

-

Elaine Barker and - John Kelsey, Recommendation for - Random Number Generation Using Deterministic Random Bit Generators - (Revised), National Institute of Standards and - Technology, 2011, NIST - Special Publication 800-90A, Rev 1.

-

Daniel J. Bernstein, - ChaCha, a variant of Salsa20, - http://cr.yp.to/papers.html#chacha, - 2008-01-28, Document ID: - 4027b5256e17b9796842e6d0f68b0b5e.

-
-
-

-

The cprng family of functions first appeared in - NetBSD 6.0.

-
-
- - - - - -
August 16, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/cpu_configure.9 3.html b/static/netbsd/man9/cpu_configure.9 3.html deleted file mode 100644 index 2a67aa1b..00000000 --- a/static/netbsd/man9/cpu_configure.9 3.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
CPU_CONFIGURE(9)Kernel Developer's ManualCPU_CONFIGURE(9)
-
-
-

-

cpu_configure — - machine-dependent device autoconfiguration

-
-
-

-

#include - <sys/systm.h>

-

void -
- cpu_configure(void);

-
-
-

-

The machine-dependent - () - is called during system bootstrap to perform the machine-dependent portion - of device autoconfiguration. It sets the configuration machinery in motion - by finding the root bus (“mainbus”). When this function - returns, interrupts must be enabled.

-

The following tasks are performed by - ():

- -
-
-

-

autoconf(9), - cpu_startup(9)

-
-
- - - - - -
April 13, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/cpu_dumpconf.9 3.html b/static/netbsd/man9/cpu_dumpconf.9 3.html deleted file mode 100644 index d7fabb54..00000000 --- a/static/netbsd/man9/cpu_dumpconf.9 3.html +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - -
CPU_DUMPCONF(9)Kernel Developer's ManualCPU_DUMPCONF(9)
-
-
-

-

cpu_dumpconf, - cpu_dump, cpu_dumpsize, - dumpsys — machine-dependent - kernel core dumps

-
-
-

-

#include - <sys/types.h> -
- #include <sys/systm.h>

-

void -
- cpu_dumpconf(void);

-

int -
- cpu_dump(int - (*dump)(dev_t, daddr_t, void *, size_t), - daddr_t *blknop);

-

int -
- cpu_dumpsize(void);

-

void -
- dumpsys(void);

-
-
-

-

() - is the machine-dependent interface invoked during system bootstrap to - determine the dump device and initialize machine-dependent kernel core dump - state. Internally, cpu_dumpconf() will invoke - cpu_dumpsize() to calculate the size of - machine-dependent kernel core dump headers.

-

() - is invoked by - () - to dump kernel physical memory onto the dump device. - dumpsys() invokes cpu_dump() - to write the machine-dependent header to the dump device at block number - *blknop using the dump device's PIO dump routine - specified by the dump argument.

-

(), - (), - and dumpsys() are parts of the machine-dependent - interface, however they are not exported to machine-independent code.

-
-
-

-

cpu_reboot(9)

-
-
- - - - - -
May 24, 2002NetBSD 10.1
diff --git a/static/netbsd/man9/cpu_need_resched.9 3.html b/static/netbsd/man9/cpu_need_resched.9 3.html deleted file mode 100644 index 4db08d3c..00000000 --- a/static/netbsd/man9/cpu_need_resched.9 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
CPU_NEED_RESCHED(9)Kernel Developer's ManualCPU_NEED_RESCHED(9)
-
-
-

-

cpu_need_resched — - context switch notification

-
-
-

-

#include - <sys/cpu.h>

-

void -
- cpu_need_resched(struct - cpu_info *ci, struct lwp - *l, int flags);

-
-
-

-

The - () - function is the machine-independent interface for the scheduler to notify - machine-dependent code that a context switch from the current LWP - l, on the cpu ci, is required. - This event may occur if a higher priority LWP appears on the run queue or if - the current LWP has exceeded its time slice. l is the - last LWP observed running on the CPU. It may no longer be running, as - cpu_need_resched() can be called without holding - scheduler locks.

-

If the RESCHED_KPREEMPT flag is specified - in flags and __HAVE_PREEMPTION - C pre-processor macro is defined in - <machine/intr.h>, - machine-dependent code should make a context switch happen as soon as - possible even if the CPU is running in kernel mode. If the - RESCHED_KPREEMPT flag is not specified, then - RESCHED_UPREEMPT is specified instead.

-

If the RESCHED_IDLE flag is specified in - flags, the last thread observed running on the CPU was - the idle LWP.

-

If RESCHED_REMOTE - flag is specified in flags, the request is not for the - current CPU. The opposite also holds true. If ci is - not the current processor, - () - typically issues an inter processor call to the processor to make it notice - the need of a context switch as soon as possible.

-

() - is always called with kernel preemption disabled.

-

Typically, the - () - function will perform the following operations:

-
    -
  • Set a per-processor flag which is checked by userret(9) - when returning to user-mode execution.
    • -
  • Post an asynchronous software trap (AST).
    • -
  • Send an inter processor interrupt to wake up - cpu_idle(9) and/or force an user process across the - user/kernel boundary, thus making a trip through - ().
    • -
-
-
-

-

sched_4bsd(9), userret(9)

-
-
- - - - - -
November 17, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/cpu_rootconf.9 3.html b/static/netbsd/man9/cpu_rootconf.9 3.html deleted file mode 100644 index fe371383..00000000 --- a/static/netbsd/man9/cpu_rootconf.9 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
CPU_ROOTCONF(9)Kernel Developer's ManualCPU_ROOTCONF(9)
-
-
-

-

cpu_rootconf, - rootconf, setroot — - root file system setup

-
-
-

-

#include - <sys/types.h> -
- #include <sys/systm.h>

-

void -
- cpu_rootconf(void);

-

void -
- rootconf(void);

-

void -
- setroot(device_t - bootdv, int - bootpartition);

-
-
-

-

The - () - is a machine-dependent interface invoked during system bootstrap to - determine the root file system device and initialize machine-dependent file - system state. cpu_rootconf() provides the global - variables booted_device, - booted_partition, - booted_startblk, booted_nblks, - and bootspec. cpu_rootconf - invokes the machine-independent function rootconf - which calls the function setroot to record the root - device and the root partition information for use in machine-independent - code.

-

rootconf may adjust the global variables and - determines the parameters for setroot. This is for example used to translate - a device and partition number provided by the bootloader into a disk wedge - device covering the same partition.

-

If the bootloader already identified a disk wedge, it passes a - non-zero value for booted_nblks, then - booted_startblk and booted_nblks - specify a disk wedge as the boot device.

-

setroot evaluates several sources to - identify the root device in the following order until a valid device is - selected:

-
    -
  1. The kernel configuration variable rootspec which is - set by config(1). The value is the name and unit of the - root device, e.g., "sd0" (disk) or "dk0" (wedge) or - "le0" (network) or the prefix "wedge:" followed by the - name of the disk wedge. For disk devices the partition passed as argument - to setroot is used.
    2. -
  2. The variable bootspec following the same - syntax.
    3. -
  3. The result of an interactive query of the root device if - boothowto has set the flag - RB_ASKNAME. The input uses the same syntax as the - previous sources. Here also the kernel dump device is queried.
    4. -
  4. The boot device and partition passed as arguments.
    5. -
-

If a root device cannot be selected, setroot - sets the RB_ASKNAME flag and loops.

-

Otherwise the kernel dump device is identified in a similar manner - from

-
    -
  1. The result of a previous interactive query. See above.
    2. -
  2. The kernel configuration variable dumpspec, if - set.
    3. -
  3. The second partition of the root device, if it is a regular disk.
    4. -
  4. The first disk wedge device of type DKW_PTYPE_SWAP.
    5. -
-
-
-

-

config(1), dk(4), - boot(8), boothowto(9)

-
-
- - - - - -
November 11, 2014NetBSD 10.1
diff --git a/static/netbsd/man9/csf.9 3.html b/static/netbsd/man9/csf.9 3.html deleted file mode 100644 index 4702e2dc..00000000 --- a/static/netbsd/man9/csf.9 3.html +++ /dev/null @@ -1,295 +0,0 @@ - - - - - - -
CSF(9)Kernel Developer's ManualCSF(9)
-
-
-

-

CSF — The - NetBSD common scheduler framework

-
-
-

-

#include - <sys/sched.h>

-

void -
- sched_rqinit(void);

-

void -
- sched_setup(void);

-

void -
- sched_cpuattach(struct - cpu_info *);

-

void -
- sched_tick(struct - cpu_info *);

-

void -
- sched_schedclock(lwp_t - *);

-

bool -
- sched_curcpu_runnable_p(void);

-

lwp_t * -
- sched_nextlwp(void);

-

void -
- sched_enqueue(lwp_t - *, bool);

-

void -
- sched_dequeue(lwp_t - *);

-

void -
- sched_nice(struct - proc *, int);

-

void -
- sched_proc_fork(struct - proc *, struct proc - *);

-

void -
- sched_proc_exit(struct - proc *, struct proc - *);

-

void -
- sched_lwp_fork(lwp_t - *);

-

void -
- sched_lwp_exit(lwp_t - *);

-

void -
- sched_setrunnable(lwp_t - *);

-

void -
- sched_print_runqueue(void - (*pr)(const char *, ...));

-

void -
- sched_pstats_hook(struct - proc *, int);

-

void -
- sched_pstats(void - *arg);

-

pri_t -
- sched_kpri(lwp_t - *);

-

void -
- resched_cpu(lwp_t - *);

-

void -
- setrunnable();

-

void -
- schedclock(lwp_t - *);

-

void -
- sched_init(void);

-
-
-

-

CSF provides a modular and self-contained - interface for implementing different thread scheduling algorithms. The - different schedulers can be selected at compile-time. Currently, the - schedulers available are sched_4bsd(9), the traditional - 4.4BSD thread scheduler, and sched_m2(9) which implements - a SVR4/Solaris like approach.

-

The interface is divided into two parts: A set of functions each - scheduler needs to implement and common functions used by all - schedulers.

-
-
-

-

The following functions have to be implemented by the individual - scheduler.

-
-

-
-
void - (struct - cpu_info *)
-
Per-CPU scheduler initialization routine.
-
void - (void)
-
Initialize the scheduler's runqueue data structures.
-
void - (void)
-
Setup initial scheduling parameters and kick off timeout driven - events.
-
-
-
-

-

Runqueue handling is completely internal to the scheduler. Other - parts of the kernel should access runqueues only through the following - functions:

-
-
void - (lwp_t - *, bool)
-
Place an LWP within the scheduler's runqueue structures.
-
void - (lwp_t - *)
-
Remove an LWP from the scheduler's runqueue structures.
-
lwp_t * - (void)
-
Return the LWP that should run the CPU next.
-
bool - (void)
-
Indicate if there is a runnable LWP for the current CPU.
-
void - (void - (*pr)(const char *, ...))
-
Print runqueues in DDB.
-
-
-
-

-
-
void - (struct - cpu_info *)
-
Periodically called from hardclock(9). Determines if a - reschedule is necessary, if the running LWP has used up its quantum.
-
void - (lwp_t - *)
-
Periodically called from - () - in order to handle priority adjustment.
-
-
-
-

-
-
void - (struct - proc *, int)
-
Recalculate the process priority according to its nice value.
-
-
-
-

-
-
void - (struct - proc *, struct proc *)
-
Inherit the scheduling history of the parent process after - ().
-
void - (struct - proc *, struct proc *)
-
Charge back a processes parent for its resource usage.
-
void - (lwp_t - *)
-
LWP-specific version of the above
-
void - (lwp_t - *)
-
LWP-specific version of the above
-
void - (lwp_t - *)
-
Scheduler-specific actions for - ().
-
void - (struct - proc *, int)
-
Scheduler-specific actions for - ().
-
-
-
-
-

-
-
pri_t - (lwp_t - *)
-
Scale a priority level to a kernel priority level, usually for an LWP that - is about to sleep.
-
void - sched_pstats(void *)
-
Update process statistics and check CPU resource allocation.
-
inline void - (lwp_t - *)
-
Arrange for a reschedule.
-
void - setrunnable(lwp_t *)
-
Change process state to be runnable, placing it on a runqueue if it is in - memory, awakening the swapper otherwise.
-
void - schedclock(lwp_t *)
-
Scheduler clock. Periodically called from - ().
-
void - (void)
-
Initialize callout for sched_pstats() and call - sched_setup() to initialize any other - scheduler-specific data.
-
-
-
-

-

The CSF programming interface is defined - within the file sys/sys/sched.h.

-

Functions common to all scheduler implementations are in - sys/kern/kern_synch.c.

-

The traditional 4.4BSD scheduler is implemented in - sys/kern/sched_4bsd.c.

-

The M2 scheduler is implemented in - sys/kern/sched_m2.c.

-
-
-

-

mi_switch(9), preempt(9), - sched_4bsd(9), sched_m2(9)

-
-
-

-

The CSF appeared in - NetBSD 5.0.

-
-
-

-

The CSF was written by - Daniel Sieger - ⟨dsieger@NetBSD.org⟩.

-
-
- - - - - -
October 27, 2014NetBSD 10.1
diff --git a/static/netbsd/man9/curproc.9 3.html b/static/netbsd/man9/curproc.9 3.html deleted file mode 100644 index 17d4ed8c..00000000 --- a/static/netbsd/man9/curproc.9 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
CURPROC(9)Kernel Developer's ManualCURPROC(9)
-
-
-

-

curcpu, curlwp, - curproc — current processor, - thread, and process

-
-
-

-

#include - <sys/proc.h>

-

struct cpu_info * -
- curcpu(void);

-

struct proc *curproc; -
- struct lwp *curlwp;

-

#include - <sys/cpu.h>

-

bool -
- curcpu_stable(void);

-
-
-

-

The following retrieve the current CPU, process, and thread - (lightweight process, or LWP), respectively:

-
-
()
-
Returns a pointer to the struct cpu_info structure - representing the CPU that the code calling it is running on. -

The value of - () - is unstable and may be stale as soon as it is read unless the caller - prevents preemption by raising the IPL (spl(9), - mutex(9)), by disabling preemption - (kpreempt_disable(9)), or by binding the thread to its - CPU (curlwp_bind(9)).

-

The function - () - can be used in assertions (KASSERT(9)) to verify that - curcpu() is stable in the current context. - curcpu_stable() MUST NOT be used to make dynamic - decisions about whether to query curcpu().

-
-
-
Yields a pointer to the struct proc structure - representing the currently running process. -

The value of curproc is stable and - does not change during execution except in machine-dependent logic to - perform context switches, so it works like a global constant, not like a - stateful procedure.

-
-
-
Yields a pointer to the struct lwp structure - representing the currently running thread. -

The value of curlwp is stable and does - not change during execution except in machine-dependent logic to perform - context switches, so it works like a global constant, not like a - stateful procedure.

-
-
-
-
-

-

The - () - macro is defined in the machine-independent - machine/cpu.h.

-

The curproc macro is defined in - sys/lwp.h.

-

The curlwp macro has a machine-independent - definition in sys/lwp.h, but it may be overridden by - machine/cpu.h, and must be overridden on - architectures supporting multiprocessing and kernel preemption.

-

The - () - function is defined in kern/subr_cpu.c.

-
-
-

-

cpu_number(9), - proc_find(9)

-
-
- - - - - -
July 8, 2023NetBSD 10.1
diff --git a/static/netbsd/man9/ddc.9 3.html b/static/netbsd/man9/ddc.9 3.html deleted file mode 100644 index 18a348e1..00000000 --- a/static/netbsd/man9/ddc.9 3.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - -
DDC(9)Kernel Developer's ManualDDC(9)
-
-
-

-

ddc — VESA Display - Data Channel V2

-
-
-

-

#include - <dev/i2c/ddcvar.h>

-

int -
- ddc_read_edid(i2c_tag_t tag, - uint8_t *dest, size_t len);

-
-
-

-

The - () - reads a VESA Extended Display Identification Data block (EDID) via VESA - Display Data Channel (DDCv2). DDCv2 is a protocol for data exchange between - display devices (such as monitors and flat panels) and host machines using - an I2C bus.

-

The tag argument is a machine-dependent tag - used to specify the I2C bus on which the DDCv2 device is located. The - dest argument is a pointer to a buffer where the EDID - data will be stored. The len argument is the amount of - data to read into the buffer. (The buffer must be large enough.) Typically, - this value will be 128, which is the size of a normal EDID data block.

-

Normally the EDID data block will be - post-processed with the - () - function.

-
-
-

-

The ddc_read_edid() function returns zero - on success, and non-zero otherwise.

-
-
-

-

The ddc_read_edid() function is part of - the ddc(4) driver, and is only included in the kernel if - that driver is also included.

-
-
-

-

The following code uses ddc_read_edid() to - retrieve and print information about a monitor:

-

-
-
	struct edid_info info;
-	i2c_tag_t        tag;
-	char		 buffer[128];
-
-	...
-	/* initialize i2c tag... */
-	...
-	if ((ddc_read_edid(tag, buffer, 128) == 0) &&
-	    (edid_parse(buffer, &info) == 0))
-		edid_print(info);
-	...
-
-

Note that this must be called before the PCI bus is attached - during autoconfiguration.

-
-
-

-

ddc(4), edid(9), - iic(9)

-
-
-

-

DDCv2 support was added in NetBSD 4.0.

-
-
-

-

Garrett D'Amore - <gdamore@NetBSD.org>

-
-
- - - - - -
May 11, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/delay.9 3.html b/static/netbsd/man9/delay.9 3.html deleted file mode 100644 index 8c4089bf..00000000 --- a/static/netbsd/man9/delay.9 3.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
DELAY(9)Kernel Developer's ManualDELAY(9)
-
-
-

-

delay, DELAY - — microsecond delay

-
-
-

-

#include - <sys/param.h>

-

void -
- delay(unsigned - int us);

-

void -
- DELAY(unsigned - int us);

-
-
-

-

Wait approximately us microseconds.

-

The delay is implemented as a machine loop, preventing - events other than interrupt handlers for unmasked interrupts to run. - () is - reentrant (doesn't modify any global kernel or machine state) and is safe to - use in interrupt or process context.

-

For long delays, condition variables should be considered, however - they can only be used from process context and their resolution is limited - by the system clock frequency.

-
-
-

-

condvar(9), hz(9), - kpause(9)

-
-
- - - - - -
July 20, 2011NetBSD 10.1
diff --git a/static/netbsd/man9/dksubr.9 3.html b/static/netbsd/man9/dksubr.9 3.html deleted file mode 100644 index 631fd210..00000000 --- a/static/netbsd/man9/dksubr.9 3.html +++ /dev/null @@ -1,300 +0,0 @@ - - - - - - -
DKSUBR(9)Kernel Developer's ManualDKSUBR(9)
-
-
-

-

dk_softc, dk_init, - dk_attach, dk_detach, - dk_open, dk_close, - dk_size, dk_dump, - dk_ioctl, dk_strategy, - dk_strategy_defer, - dk_strategy_pending, - dk_start, dk_done, - dk_drain, dk_discard, - dk_getdefaultlabel, - dk_getdisklabel — disk - driver subroutines

-
-
-

-

#include - <sys/bufq.h> -
- #include <sys/disk.h> -
- #include <dev/dkvar.h>

-

void -
- dk_init(struct - dk_softc *, - device_t, - int dtype);

-

void -
- dk_attach(struct - dk_softc *);

-

void -
- dk_detach(struct - dk_softc *);

-

int -
- dk_open(struct - dk_softc *, dev_t, - int flags, - int fmt, - struct lwp *);

-

int -
- dk_close(struct - dk_softc *, dev_t, - int flags, - int fmt, - struct lwp *);

-

int -
- dk_discard(struct - dk_softc *, dev_t, - off_t pos, - off_t len);

-

int -
- dk_size(struct - dk_softc *, - dev_t);

-

int -
- dk_dump(struct - dk_softc *, dev_t, - daddr_t blkno, - void *vav, - size_t size);

-

int -
- dk_ioctl(struct - dk_softc *, dev_t, - u_long cmd, - void *data, - int flag, - struct lwp *);

-

void -
- dk_strategy(struct - dk_softc *, struct buf - *);

-

int -
- dk_strategy_defer(struct - dk_softc *, struct buf - *);

-

int -
- dk_strategy_pending(struct - dk_softc *);

-

void -
- dk_start(struct - dk_softc *, struct buf - *);

-

void -
- dk_done(struct - dk_softc *, struct buf - *);

-

int -
- dk_drain(struct - dk_softc *);

-

void -
- dk_getdefaultlabel(struct - dk_softc *, struct - disklabel *);

-

void -
- dk_getdisklabel(struct - dk_softc *, - dev_t);

-
-
-

-

The disk driver subroutines provide common functionality for all - disk drivers to reduce the amount of replicated code. For many disk drivers, - their corresponding entry points can be made mostly stubs.

-

The subroutines encapsulate data structures found in a driver's - softc into

-
-
struct dk_softc {
-	device_t		sc_dev;
-	struct disk		sc_dkdev;
-	struct bufq_state	sc_bufq;
-	krndsource_t		sc_rnd_source;
-...
-}
-
-The dk_softc structure therefore replaces the - device_t member of the driver's softc struct. -

The following is a brief description of each function in the - framework:

-
-
()
-
Initialize the dk_softc structure.
-
()
-
Attach framework after driver has attached the disk(9) - subsystem, created a bufq(9) and is ready to handle - I/O.
-
()
-
Undo dk_attach.
-
()
-
Handles open steps for the disk(9) framework, acquires - the disklabel and validates open parameters. The driver may provide the - d_firstopen callback to handle initialization - steps.
-
()
-
Handles close steps for the disk(9) framework. The - driver may provide the d_lastclose callback to - handle finalization steps. dk_open and - dk_close are serialized by the openlock - mutex.
-
()
-
Validates parameters, computes raw block numbers and passes these to the - d_discard callback.
-
()
-
Returns dump size information from the disklabel(9) and - opens and closes the driver when necessary.
-
()
-
Validates parameters, computes raw block numbers and iterates over the - d_dumpblocks callback in appropriate chunks - determined by the d_iosize callback.
-
()
-
Handles the ioctls DIOCKLABEL, - DIOCWLABEL, DIOCGDEFLABEL, - DIOCGSTRATEGY, and - DIOCSSTRATEGY and passes other disk ioctls through - the disk(9) framework. Returns - ENOTTY when an ioctl isn't implemented. This - routine is run as a fallback to handle commands that are not specific to - the driver.
-
()
-
Validates parameters, computes raw block numbers, queues a buffer for I/O - and triggers queue processing by calling - dk_start.
-
()
-
Alternative to dk_strategy that only queues the - buffer. Drivers that implement a separate I/O thread can use - dk_strategy_defer within their own strategy - routine and signal the thread through a private interface.
-
()
-
This function is called by an I/O thread to determine if work has been - queued by dk_strategy_defer. The driver must then - call dk_start to trigger queue processing.
-
()
-
If bp != NULL put it into - the queue. Run the d_diskstart callback for every - buffer until the queue is empty or the callback returns - EAGAIN. In the latter case, the buffer is saved - and issued on the next queue run. This also calls - disk_busy accordingly to handle I/O metrics.
-
()
-
Called by the driver when an I/O operation completed. - dk_done logs errors, calls - disk_unbusy to handle I/O metrics and collects - entropy for the cprng(9).
-
()
-
Aborts all queued I/O. This function must be called instead of - () - to cooperate with dk_start.
-
()
-
Compute a common default disklabel for all disk drivers. Some drivers - provide device specific information or assign specific disk formats to - partitions. Such drivers may implement the d_label - callback that is called by dk_getdefaultlabel - after initializing the label with common values.
-
()
-
Read disklabel with machine dependent low-level function - readdisklabel and do sanity checks.
-
-
-
-

-

The driver needs to provide a common set of entry points that are - used by the disk driver subroutines and the disk(9) - framework.

-
-
struct dkdriver {
-        void    (*d_strategy)(struct buf *);
-        void    (*d_minphys)(struct buf *);
-        int     (*d_open)(dev_t, int, int, struct lwp *);
-        int     (*d_close)(dev_t, int, int, struct lwp *);
-        int     (*d_diskstart)(device_t, struct buf *);
-        void    (*d_iosize)(device_t, int *);
-        int     (*d_dumpblocks)(device_t, void *, daddr_t, int);
-        int     (*d_lastclose)(device_t);
-        int     (*d_discard)(device_t, off_t, off_t);
-        int     (*d_firstopen)(device_t, dev_t, int, int);
-        void    (*d_label)(device_t, struct disklabel *);
-};
-
-
-
()
-
The driver strategy routine queues a single buffer for I/O and starts - queue processing as appropriate.
-
()
-
The driver minphys routine limits the buffer - b_bcount to the maximum size for an I/O transfer - supported by the driver and hardware. It also calls - minphys to apply the platform limit.
-
()
-
The driver open routine.
-
()
-
The driver close routine.
-
()
-
Issues a single I/O request, called by - dk_start.
-
()
-
Truncate I/O size to the driver limit. This is similar to - minphys but operates on an integer value instead - of a buffer.
-
()
-
Issue a single I/O requests, called by - dk_dump.
-
()
-
Private cleanup after last user is finished. Often used to flush write - caches.
-
()
-
Issue a single I/O request to invalidate a disk region.
-
()
-
Private initialization when first user opens the driver.
-
-
-
-

-

cgd(4), ld(4), - cprng(9), disk(9), - driver(9)

-
-
-

-

The NetBSD common disk driver subroutines - appeared in NetBSD 2.0 as a base for the - cryptographic disk driver and was extended to handle disk wedges in - NetBSD 4.0. Most functionality provided by - ld(4) was included and extended in NetBSD - 8.0 to support other disk drivers. The callback interface used by the - disk(9) framework has been merged as well.

-
-
- - - - - -
November 28, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/dopowerhooks.9 3.html b/static/netbsd/man9/dopowerhooks.9 3.html deleted file mode 100644 index 30034aef..00000000 --- a/static/netbsd/man9/dopowerhooks.9 3.html +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - -
DOPOWERHOOKS(9)Kernel Developer's ManualDOPOWERHOOKS(9)
-
-
-

-

dopowerhooks — run - all power hooks

-
-
-

-

void -
- dopowerhooks(int - why);

-
-
-

-

- dopowerhooks - - - pmf_system_suspend(9) -

-

The - () - function invokes all power hooks established using the - powerhook_establish(9) function. When power is - disappearing the power hooks are called in reverse order, i.e., the power - hook established last will be called first. When power is restored they are - called normal order.

-

This function is called from the apm(4) driver - when a power change is detected.

-
-
-

-

powerhook_establish(9)

-
-
- - - - - -
February 11, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/doshutdownhooks.9 3.html b/static/netbsd/man9/doshutdownhooks.9 3.html deleted file mode 100644 index 4e531af1..00000000 --- a/static/netbsd/man9/doshutdownhooks.9 3.html +++ /dev/null @@ -1,53 +0,0 @@ - - - - - - -
DOSHUTDOWNHOOKS(9)Kernel Developer's ManualDOSHUTDOWNHOOKS(9)
-
-
-

-

doshutdownhooks — - run all shutdown hooks

-
-
-

-

void -
- doshutdownhooks(void);

-
-
-

-

- doshutdownhooks - - - pmf_system_shutdown(9) -

-

The - () - function invokes all shutdown hooks established using the - shutdownhook_establish(9) function. Shutdown hooks are - called in reverse order, i.e., the shutdown hook established last will be - called first.

-

This function is called from - () - with interrupts turned off. It is called immediately before the system is - halted or rebooted, after file systems have been unmounted, after the clock - has been updated, and after a system dump has been done (if necessary).

-
-
-

-

cpu_reboot(9), - shutdownhook_establish(9)

-
-
- - - - - -
February 11, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/driver.9 3.html b/static/netbsd/man9/driver.9 3.html deleted file mode 100644 index e33ab52e..00000000 --- a/static/netbsd/man9/driver.9 3.html +++ /dev/null @@ -1,249 +0,0 @@ - - - - - - -
DRIVER(9)Kernel Developer's ManualDRIVER(9)
-
-
-

-

driver — - description of a device driver

-
-
-

-

#include - <sys/param.h> -
- #include <sys/device.h> -
- #include <sys/errno.h>

-

static int -
- foo_match(device_t - parent, cfdata_t - match, void - *aux);

-

static void -
- foo_attach(device_t - parent, device_t - self, void - *aux);

-

static int -
- foo_detach(device_t - self, int - flags);

-

static int -
- foo_activate(device_t - self, enum devact - act);

-
-
-

-

This page briefly describes the basic - NetBSD autoconfiguration interface used by device - drivers. For a detailed overview of the autoconfiguration framework see - autoconf(9).

-

Each device driver must present to the system a standard - autoconfiguration interface. This interface is provided by the - cfattach structure. The interface to the driver is - constant and is defined statically inside the driver. For example, the - interface to driver ‘foo’ is defined - with:

-
-
CFATTACH_DECL_NEW(foo,                  /* driver name */
-        sizeof(struct foo_softc),       /* size of instance data */
-        foo_match,                      /* match/probe function */
-        foo_attach,                     /* attach function */
-        foo_detach,                     /* detach function */
-        foo_activate);                  /* activate function */
-
-

For each device instance controlled by the driver, the - autoconfiguration framework allocates a block of memory to record - device-instance-specific driver variables. The size of this memory block is - specified by the second argument in the - CFATTACH_DECL family of macros. The memory block is - referred to as the driver's softc structure. The - softc structure is only accessed within the driver, so - its definition is local to the driver. Nevertheless, the - softc structure should adopt the standard - NetBSD configuration and naming conventions. For - example, the softc structure for driver - ‘foo’ is defined with:

-
-
struct foo_softc {
-        device_t sc_dev;                /* generic device info */
-        /* device-specific state */
-};
-
-

If a driver has character device interfaces accessed from - userland, the driver must define the cdevsw structure. - The structure is constant and is defined inside the driver. For example, the - cdevsw structure for driver - ‘foo’ can be defined with:

-
-
const struct cdevsw foo_cdevsw {
-        .d_open = fooopen,
-        .d_close = nullclose,
-        .d_read = fooread,
-        .d_write = nowrite,
-        .d_ioctl = fooioctl,
-        .d_stop = nostop,
-        .d_tty = notty,
-        .d_poll = foopoll,
-        .d_mmap = nommap,
-        .d_kqfilter = nokqfilter,
-        .d_discard = nodiscard,
-        .d_flag = D_OTHER | D_MPSAFE,
-};
-
-

The structure variable must be named - foo_cdevsw by appending the letters - ‘_cdevsw’ to the driver's base name. - This convention is mandated by the autoconfiguration framework.

-

If the driver ‘foo’ has also - block device interfaces, the driver must define the - bdevsw structure. The structure is constant and is - defined inside the driver. For example, the bdevsw - structure for driver ‘foo’ is defined - with:

-
-
const struct bdevsw foo_bdevsw {
-        .d_open = fooopen,
-        .d_close = fooclose,
-        .d_strategy = foostrategy,
-        .d_ioctl = fooioctl,
-        .d_dump = nodump,
-        .d_psize = nosize,
-        .d_flag = D_DISK | D_MPSAFE,
-};
-
-

The structure variable must be named - foo_bdevsw by appending the letters - ‘_bdevsw’ to the driver's base name. - This convention is mandated by the autoconfiguration framework.

-

During system bootstrap, the autoconfiguration - framework searches the system for devices. For each device driver, its match - function is called (via its cfattach structure) to - match the driver with a device instance. The match function is called with - three arguments. This first argument parent is a - pointer to the driver's parent device structure. The second argument - match is a pointer to a data structure describing the - autoconfiguration framework's understanding of the driver. Both the - parent and match arguments are - ignored by most drivers. The third argument aux - contains a pointer to a structure describing a potential device-instance. It - is passed to the driver from the parent. The match function would type-cast - the aux argument to its appropriate attachment - structure and use its contents to determine whether it supports the device. - Depending on the device hardware, the contents of the attachment structure - may contain “locators” to locate the device instance so that - the driver can probe it for its identity. If the probe process identifies - additional device properties, it may modify the members of the attachment - structure. For these devices, the NetBSD convention - is to call the match routine - () - instead of - () - to make this distinction clear. Either way, the match function returns a - nonzero integer indicating the confidence of supporting this device and a - value of 0 if the driver doesn't support the device. Generally, only a - single driver exists for a device, so the match function returns 1 for a - positive match.

-

The autoconfiguration framework will call the - attach function (via its cfattach structure) of the - driver which returns the highest value from its match function. The attach - function is called with three arguments. The attach function performs the - necessary process to initialise the device for operation. The first argument - parent is a pointer to the driver's parent device - structure. The second argument self is a pointer to - the driver's device structure. The device's softc - structure can be obtained from it using the - () - function (see disk(9)). The third argument - aux is a pointer to the attachment structure. The - parent and aux arguments are the - same as passed to the match function.

-

The driver's attach function is called - before system interrupts are enabled. If interrupts are required during - initialisation, then the attach function should make use of - () - (see autoconf(9)).

-

Some devices can be removed from the system without requiring a - system reboot. The autoconfiguration framework calls the driver's detach - function (via its cfattach structure) during device - detachment. If the device does not support detachment, then the driver does - not have to provide a detach function. The detach function is used to - relinquish resources allocated to the driver which are no longer needed. The - first argument self is a pointer to the driver's - device structure. It is the same structure as passed to the attach function. - The second argument flags contains detachment flags. - Valid values are DETACH_FORCE (force detachment; - hardware gone) and DETACH_QUIET (do not print a - notice).

-

The activate function is used by some buses to notify drivers from - interrupt context when detachment is imminent, with - act set to DVACT_DEACTIVATE. - Currently only pcmcia(9) and cardbus(9) - use this. If the action is not supported the activate function should return - EOPNOTSUPP.

-

Most drivers will want to make use of interrupt facilities. - Interrupt locators provided through the attachment structure should be used - to establish interrupts within the system. Generally, an interrupt interface - is provided by the parent. The interface will require a handler and a - driver-specific argument to be specified. This argument is usually a pointer - to the device-instance-specific softc structure. When a hardware interrupt - for the device occurs the handler is called with the argument. Interrupt - handlers should return 0 for “interrupt not for me”, 1 for - “I took care of it”, or -1 for “I guess it was mine, - but I wasn't expecting it”.

-

For a driver to be compiled into the kernel, - config(1) must be aware of its existence. This is done by - including an entry in files.<bus> in the directory containing the - driver. For example, the driver foo attaching to bus - bar with dependency on kernel module - baz has the entry:

-
-
device foo: baz
-attach foo at bar
-file dev/bar/foo.c foo
-
-

An entry can now be added to the machine description file:

-
foo* - at - bar?
-

For device interfaces of a driver to be compiled into the kernel, - config(1) must be aware of its existence. This is done by - including an entry in - majors.⟨arch⟩. - For example, the driver foo with character device - interfaces, a character major device number cmaj, - block device interfaces, a block device major number - bmaj and dependency on kernel module - baz has the entry:

-
device-major - foo char - cmaj block - bmaj baz
-

For a detailed description of the machine description file and the - “device definition” language see - config(9).

-
-
-

-

config(1), autoconf(9), - config(9), devsw(9), - pmf(9)

-
-
- - - - - -
April 30, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/errno.9 3.html b/static/netbsd/man9/errno.9 3.html deleted file mode 100644 index 3942db0e..00000000 --- a/static/netbsd/man9/errno.9 3.html +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - -
ERRNO(9)Kernel Developer's ManualERRNO(9)
-
-
-

-

errno — kernel - internal error numbers

-
-
-

-

#include - <sys/errno.h>

-
-
-

-

This section provides an overview of the error numbers used - internally by the kernel and indicate neither success nor failure. These - error numbers are not returned to userland code.

-
-
-

-

Kernel functions that indicate success or failure by means of - either 0 or an errno(2) value sometimes have a need to - indicate that “special” handling is required at an upper layer - or, in the case of ioctl(2) processing, that - “nothing was wrong but the request was not handled”. To handle - these cases, some negative errno(2) values are defined - which are handled by the kernel before returning a different - errno(2) value to userland or simply zero.

-

The following is a list of the defined names and their - meanings as given in - <errno.h>. It is important - to note that the value -1 is - used, since it is - commonly used to indicate generic failure and leaves it up to the caller to - determine the action to take.

-
-
-2 EJUSTRETURN - .
-
No more work is required and the function should just return.
-
-3 ERESTART - .
-
The system call should be restarted. This typically means that the machine - dependent system call trap code will reposition the process's instruction - pointer or program counter to re-execute the current system call with no - other work required.
-
-4 EPASSTHROUGH - .
-
The operation was not handled and should be passed through to another - layer. This often occurs when processing ioctl(2) - requests since lower layer processing may not handle something that - subsequent code at a higher level will.
-
-5 EDUPFD -
-
This error is returned from the device open routine indicating that the - l_dupfd field contains the file descriptor - information to be returned to the caller, instead of the file descriptor - that has been opened already. This error is used by cloning device - multiplexors. Cloning device multiplexors open a new file descriptor and - associate that file descriptor with the appropriate cloned device. They - set l_dupfd to that new file descriptor and return - EDUPFD. vn_open(9) takes the - file descriptor pointed to by l_dupfd and arranges - for it to be copied to the file descriptor that the open call will - return.
-
-6 EMOVEFD -
-
This error is similar to EDUPFD except that the - file descriptor in l_dupfd is closed after it has - been copied.
-
-
-
-

-

errno(2), ioctl(9)

-
-
-

-

An errno manual page appeared in - Version 6 AT&T UNIX. This - errno manual page appeared in - NetBSD 3.0.

-
-
- - - - - -
December 3, 2004NetBSD 10.1
diff --git a/static/netbsd/man9/evcnt.9 3.html b/static/netbsd/man9/evcnt.9 3.html deleted file mode 100644 index 5fbf24af..00000000 --- a/static/netbsd/man9/evcnt.9 3.html +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - -
EVCNT(9)Kernel Developer's ManualEVCNT(9)
-
-
-

-

evcnt, - evcnt_attach_dynamic, - evcnt_attach_static, - evcnt_detach — generic event - counter framework

-
-
-

-

#include - <sys/evcnt.h>

-

void -
- evcnt_attach_dynamic(struct - evcnt *ev, int - type, const struct evcnt - *parent, const char - *group, const char - *name);

-

void -
- evcnt_attach_static(struct - evcnt *ev);

-

void -
- evcnt_detach(struct - evcnt *ev);

-
-
-

-

The NetBSD generic event counter framework - is designed to provide a flexible and hierarchical event counting facility, - which is useful for tracking system events (including device - interrupts).

-

The fundamental component of this framework is the - structure. - Its user-accessible fields are:

-
-
struct evcnt {
-	uint64_t	ev_count;	/* how many have occurred */
-	TAILQ_ENTRY(evcnt) ev_list;	/* entry on list of all counters */
-	unsigned char	ev_type;	/* counter type; see below */
-	unsigned char	ev_grouplen;	/* 'group' len, excluding NUL */
-	unsigned char	ev_namelen;	/* 'name' len, excluding NUL */
-	const struct evcnt *ev_parent;	/* parent, for hierarchical ctrs */
-	const char	*ev_group;	/* name of group */
-	const char	*ev_name;	/* name of specific event */
-};
-
-

The system maintains a global linked list of all active event - counters. This list, called allevents, may grow or - shrink over time as event counters are dynamically added to and removed from - the system.

-

Each event counter is marked (in the ev_type - field) with the type of event being counted. The following types are - currently defined:

-
-
-
-
Miscellaneous; doesn't fit into one of the other types.
-
-
Interrupt counter, reported by vmstat -i.
-
-
Processor trap style events.
-
-
-

Each event counter also has a group name - (ev_group) and an event name - (ev_name) which are used to identify the counter. The - group name may be shared by a set of counters. For example, device interrupt - counters would use the name of the device whose interrupts are being counted - as the group name. The counter name is meant to distinguish the counter from - others in its group (and need not be unique across groups). Both names - should be understandable by users, since they are printed by commands like - vmstat(1). The constant - EVCNT_STRING_MAX is defined to be the maximum group - or event name length in bytes (including the trailing - NUL). In the current implementation it is 256.

-

To support hierarchical tracking of events, each event counter can - name a “parent” event counter. For instance, interrupt - dispatch code could have an event counter per interrupt line, and devices - could each have counters for the number of interrupts that they were - responsible for causing. In that case, the counter for a device on a given - interrupt line would have the line's counter as its parent. The value - NULL is used to indicate that a counter has no - parent. A counter's parent must be attached before the counter is attached, - and detached after the counter is detached.

-

The - () - macro can be used to provide a static initializer for an event counter - structure. It is invoked as - EVCNT_INITIALIZER(type, - parent, group, - name), and its arguments will be placed into the - corresponding fields of the event counter structure it is initializing. The - group and name arguments must be - constant strings.

-
-
-

-

The following is a brief description of each function in the - framework:

-
-
(ev, - type, parent, - group, name)
-
Attach the event counter structure pointed to by ev - to the system event list. The event counter is cleared and its fields - initialized using the arguments to the function call. The contents of the - remaining elements in the structure (e.g., the name lengths) are - calculated, and the counter is added to the system event list. -

The strings specified as the group and counter names must - persist (with the same value) throughout the life of the event counter; - they are referenced by, not copied into, the counter.

-
-
(ev)
-
Attach the statically-initialized event counter structure pointed to by - ev to the system event list. The event counter is - assumed to be statically initialized using the - EVCNT_INITIALIZER() macro. This function simply - calculates structure elements' values as appropriate (e.g., the string - lengths), and adds the counter to the system event list.
-
(ev)
-
Detach the event counter structure pointed to by ev - from the system event list.
-
-

Note that no method is provided to increment the value of an event - counter. Code incrementing an event counter should do so by directly - accessing its ev_count field in a manner that is known - to be safe. For instance, additions to a device's event counters in the - interrupt handler for that device will often be safe without additional - protection (because interrupt handler entries for a given device have to be - serialized). However, for other uses of event counters, additional locking - or use of machine-dependent atomic operation may be appropriate. (The - overhead of using a mechanism that is guaranteed to be safe to increment - every counter, regardless of actual need for such a mechanism where the - counter is being incremented, would be too great. On some systems, it might - involve a global lock and several function calls.)

-
-
-

-

This section includes a description on basic use of the framework - and example usage of its functions.

-

Device drivers can use the - evcnt_attach_dynamic() and - evcnt_detach() functions to manage device-specific - event counters. Statically configured system modules can use - evcnt_attach_static() to configure global event - counters. Similarly, loadable modules can use - evcnt_attach_static() to configure their global - event counters, evcnt_attach_dynamic() to attach - device-specific event counters, and evcnt_detach() - to detach all counters when being unloaded.

-

Device drivers that wish to use the generic event counter - framework should place event counter structures in their - “softc” structures. For example, to keep track of the number - of interrupts for a given device (broken down further into “device - readable” and “device writable” interrupts) a device - driver might use:

-
-
struct foo_softc {
-	[ . . . ]
-	struct evcnt sc_ev_intr;	/* interrupt count */
-	struct evcnt sc_ev_intr_rd;	/* 'readable' interrupt count */
-	struct evcnt sc_ev_intr_wr;	/* 'writable' interrupt count */
-	[ . . . ]
-};
-
-

In the device attach function, those counters would be registered - with the system using the evcnt_attach_dynamic() - function, using code like:

-
-
void
-fooattach(device_t parent, device_t self, void *aux)
-{
-	struct foo_softc *sc = device_private(self);
-
-	[ . . . ]
-
-	/* Initialize and attach event counters. */
-	evcnt_attach_dynamic(&sc->sc_ev, EVCNT_TYPE_INTR,
-	    NULL, device_xname(self), "intr");
-	evcnt_attach_dynamic(&sc->sc_ev_rd, EVCNT_TYPE_INTR,
-	    &sc->sc_ev, device_xname(self), "intr rd");
-	evcnt_attach_dynamic(&sc->sc_ev_wr, EVCNT_TYPE_INTR,
-	    &sc->sc_ev, device_xname(self), "intr wr");
-
-	[ . . . ]
-}
-
-

If the device can be detached from the system, its detach function - should invoke evcnt_detach() on each attached - counter (making sure to detach any “parent” counters only - after detaching all children).

-

Code like the following might be used to initialize a static event - counter (in this example, one used to track CPU alignment traps):

-
-
	struct evcnt aligntrap_ev = EVCNT_INITIALIZER(EVCNT_TYPE_MISC,
-	    NULL, "cpu", "aligntrap")
-
-

To attach this event counter, code like the following could be - used:

-
-
	evcnt_attach_static(&aligntrap_ev);
-
-
-
-

-

The event counter framework itself is implemented within the file - sys/kern/subr_evcnt.c. Data structures and function - prototypes for the framework are located in - sys/sys/device.h.

-

Event counters are used throughout the system.

-

The vmstat(1) source file - usr.bin/vmstat/vmstat.c shows an example of how to - access event counters from user programs.

-
-
-

-

vmstat(1)

-
-
-

-

A set of interrupt counter interfaces with similar names to the - interfaces in the NetBSD generic event counter - framework appeared as part of the new autoconfiguration system in - 4.4BSD. Those interfaces were never widely adopted - in NetBSD because of limitations in their - applicability. (Their use was limited to non-hierarchical, dynamically - attached device interrupt counters.) The NetBSD - generic event counter framework first appeared in NetBSD - 1.5.

-
-
-

-

The NetBSD generic event counter framework - was designed and implemented by Chris Demetriou - ⟨cgd@NetBSD.org⟩.

-
-
- - - - - -
January 14, 2011NetBSD 10.1
diff --git a/static/netbsd/man9/fileassoc.9 3.html b/static/netbsd/man9/fileassoc.9 3.html deleted file mode 100644 index d4c28048..00000000 --- a/static/netbsd/man9/fileassoc.9 3.html +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - -
FILEASSOC(9)Kernel Developer's ManualFILEASSOC(9)
-
-
-

-

fileassoc — - in-kernel, file system independent, file meta-data - association

-
-
-

-

#include - <sys/fileassoc.h>

-

int -
- fileassoc_register(const - char *name, - fileassoc_cleanup_cb_t - cleanup_cb, fileassoc_t - *result);

-

int -
- fileassoc_deregister(fileassoc_t - id);

-

void * -
- fileassoc_lookup(struct - vnode *vp, fileassoc_t - id);

-

int -
- fileassoc_table_delete(struct - mount *mp);

-

int -
- fileassoc_table_clear(struct - mount *mp, fileassoc_t - id);

-

int -
- fileassoc_table_run(struct - mount *mp, fileassoc_t - id, fileassoc_cb_t - cb, void - *cookie);

-

int -
- fileassoc_file_delete(struct - vnode *vp);

-

int -
- fileassoc_add(struct - vnode *vp, fileassoc_t - id, void - *data);

-

int -
- fileassoc_clear(struct - vnode *vp, fileassoc_t - id);

-
-
-

-

The fileassoc KPI allows association of - meta-data with files independent of file system support for such elaborate - meta-data.

-

When plugging a new fileassoc to the system, a developer can - specify private data to be associated with every file, as well as - (potentially different) private data to be associated with every file system - mount.

-

For example, a developer might choose to associate a custom ACL - with every file, and a count of total files with ACLs with the mount.

-
-
-

-

Designed with simplicity in mind, the - fileassoc KPI usually accepts four different types - of parameters to the most commonly used routines:

-
-
struct mount * mp
-
Describing a mount on which to take action.
-
struct vnode * vp
-
Describing a file on which to take action.
-
fileassoc_t - id
-
Describing an id, as returned from a successful call to - ().
-
void * data
-
Describing a custom private data block, attached to either a file or a - mount.
-
-

Before using the fileassoc KPI it is - important to keep in mind that the interface provides memory management only - for fileassoc internal memory. Any additional memory - stored in the tables (such as private data structures used by custom - fileassocs) should be allocated and freed by the developer.

-

fileassoc - provides the ability to specify a “cleanup” routine to - () - (see below) to be called whenever an entry for a file or a mount is - deleted.

-
-

-

These routines allow a developer to allocate a - fileassoc slot to be used for private data.

-
-
fileassoc_register(name, - cleanup_cb, result)
-
Registers a new fileassoc as name, and returns a - fileassoc_t via result to be - used as identifier in subsequent calls to the - fileassoc subsystem. -

() - returns zero on success. Otherwise, an error number will be - returned.

-

If cleanup_cb is not - NULL, it will be called during delete/clear - operations (see routines below) with indication whether the passed data - is file- or mount-specific.

-

cleanup_cb should be a function - receiving a void * and returning - void. See the - EXAMPLES section for - illustration.

-
-
(id)
-
Deregisters a fileassoc whose id is - id. -

Note that calling - () - only frees the associated slot in the fileassoc - subsystem. It is up to the developer to take care of garbage - collection.

-
-
-
-
-

-

These routines allow lookup of fileassoc - mounts, files, and private data attached to them.

-
-
(vp, - id)
-
Returns the private data for the file/id combination or - NULL if not found.
-
-
-
-

-
-
(mp)
-
Deletes a fileassoc table for mp.
-
(mp, - id)
-
Clear all table entries for fileassoc from - mp. -

If specified, the fileassoc's “cleanup routine” - will be called with a pointer to the private data structure.

-
-
(mp, - id, cb, - cookie)
-
For each entry for id, call cb - with the entry being the first argument, and cookie - being the second argument. -

cb is a function returning - void and receiving two void - * parameters.

-
-
-
-
-

-
-
(vp)
-
Delete the fileassoc entries for vp. -

If specified, the “cleanup routines” of all - fileassoc types added will be called with a pointer to the corresponding - private data structure and indication of - FILEASSOC_CLEANUP_FILE.

-
-
-
-
-

-
-
(vp, - id, data)
-
Add private data in data for - vp, for the fileassoc specified by - id. -

If a table for the mount-point vp is on - doesn't exist, one will be created automatically. - fileassoc manages internally the optimal table - sizes as tables are modified.

-
-
(vp, - id)
-
Clear the private data for vp, for the fileassoc - specified by id. -

If specified, the fileassoc's “cleanup routine” - will be called with a pointer to the private data structure and - indication of FILEASSOC_CLEANUP_FILE.

-
-
-
-
-
-

-

The following code examples should give you a clue on using - fileassoc for your purposes.

-

First, we'll begin with registering a new id. We need to do that - to save a slot for private data storage with each mount and/or file:

-
-
fileassoc_t myhook_id;
-int error;
-
-error = fileassoc_register("my_hook", myhook_cleanup, &myhook_id);
-if (error != 0)
-	...handle error...
-
-

In the above example we pass a - myhook_cleanup() routine. It could look something - like this:

-
-
void
-myhook_cleanup(void *data)
-{
-
-	printf("Myhook: Removing entry for file.\n");
-	...handle file entry removal...
-	free(data, M_TEMP);
-}
-
-

Another useful thing would be to add our private data to a file. - For example, let's assume we keep a custom ACL with each file:

-
-
int
-myhook_acl_add(struct vnode *vp, struct myhook_acl *acl)
-{
-	int error;
-
-	error = fileassoc_add(vp, myhook_id, acl);
-	if (error) {
-		printf("Myhook: Could not add ACL.\n");
-		...handle error...
-	}
-
-	printf("Myhook: Added ACL.\n");
-
-	return (0);
-}
-
-

Adding an entry will override any entry that previously - exists.

-

Whatever your plug is, eventually you'll want to access the - private data you store with each file. To do that you can use the - following:

-
-
int
-myhook_acl_access(struct vnode *vp, int access_flags)
-{
-	struct myhook_acl *acl;
-
-	acl = fileassoc_lookup(vp, myhook_id);
-	if (acl == NULL)
-		return (0);
-
-	error = myhook_acl_eval(acl, access_flags);
-	if (error) {
-		printf("Myhook: Denying access based on ACL decision.\n");
-		return (error);
-	}
-
-	return (0);
-}
-
-

And, in some cases, it may be desired to remove private data - associated with an file:

-
-
int error;
-
-error = fileassoc_clear(vp, myhook_id);
-if (error) {
-	printf("Myhook: Error occurred during fileassoc removal.\n");
-	...handle error...
-}
-
-

As mentioned previously, the call to - fileassoc_clear() will result in a call to the - “cleanup routine” specified in the initial call to - fileassoc_register().

-

The above should be enough to get you started.

-

For example usage of fileassoc, see the - Veriexec code.

-
-
-

-

The fileassoc is implemented within - src/sys/kern/kern_fileassoc.c.

-
-
-

-

veriexec(9)

-
-
-

-

The fileassoc KPI first appeared in - NetBSD 4.0.

-
-
-

-

Elad Efrat - <elad@NetBSD.org> -
- Brett Lymn - <blymn@NetBSD.org>

-
-
- - - - - -
December 1, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/firmload.9 3.html b/static/netbsd/man9/firmload.9 3.html deleted file mode 100644 index b402b742..00000000 --- a/static/netbsd/man9/firmload.9 3.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - -
FIRMLOAD(9)Kernel Developer's ManualFIRMLOAD(9)
-
-
-

-

firmload — - Firmware loader API for device drivers

-
-
-

-

#include - <dev/firmload.h>

-

int -
- firmware_open(const - char *drvname, const char - *imgname, - firmware_handle_t - *fhp);

-

int -
- firmware_close(firmware_handle_t - fh);

-

off_t -
- firmware_get_size(firmware_handle_t - fh);

-

int -
- firmware_read(firmware_handle_t - fh, off_t offset, - void *buf, - size_t size);

-

void * -
- firmware_malloc(size_t - size);

-

void -
- firmware_free(void - *buf, size_t - size);

-
-
-

-

firmload provides a simple and convenient - API for device drivers to load firmware images from files residing in the - file system that are necessary for the devices that they control. Firmware - images reside in sub-directories, one for each driver, of a series of - colon-separated path prefixes specified by the sysctl variable - hw.firmware.path.

-
-
-

-

The following functions are provided by the - firmload API:

-
-
(drvname, - imgname, fhp)
-
-

Open the firmware image - imgname for the driver - drvname. The path to the firmware image file is - constructed by appending the string “/drvname/imgname” to - each configured path prefix until opening the firmware image file - succeeds. Upon success, - () - returns 0 and stores a firmware image handle in the location pointed to - by fhp. Otherwise, an error code is returned to - indicate the reason for failure.

-
-
(fh)
-
-

Close the firmware image file associated with the firmware - handle fh. Returns 0 upon success or an error code - to indicate the reason for failure.

-
-
(fh)
-
-

Returns the size of the image file associated with the - firmware handle fh.

-
-
(fh, - offset, buf, - size)
-
-

Reads from the image file associated with the firmware handle - fh beginning at offset - offset for length size. The - firmware image data is placed into the buffer specified by - buf. Returns 0 upon success or an error code to - indicate the reason for failure.

-
-
(size)
-
-

Allocates a region of wired kernel - memory of size size. Note: - () - may block.

-
-
(buf, - size)
-
-

Frees a region of memory previously - allocated by - ().

-
-
-
-
-

-

Default search path for firmware

-
-
/libdata/firmware
-
 
-
/usr/libdata/firmware
-
 
-
/usr/pkg/libdata/firmware
-
 
-
/usr/pkg/libdata
-
 
-
-
-
-

-

autoconf(9), malloc(9), - vnsubr(9)

-
-
-

-

The firmload framework first appeared in - NetBSD 4.0.

-
-
-

-

Jason Thorpe - <thorpej@NetBSD.org>

-
-
- - - - - -
March 16, 2018NetBSD 10.1
diff --git a/static/netbsd/man9/flash.9 3.html b/static/netbsd/man9/flash.9 3.html deleted file mode 100644 index 721e2898..00000000 --- a/static/netbsd/man9/flash.9 3.html +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - -
FLASH(9)Kernel Developer's ManualFLASH(9)
-
-
-

-

flash — subsystem - for flash-like memory devices

-
-
-

-

#include - <dev/flash/flash.h>

-

device_t -
- flash_attach_mi(const - struct flash_interface *fl, - device_t dev);

-
-
-

-

Flash-like devices can register themselves to the - flash layer with the - flash_hw_if structure. This structure has function - pointers and other fields.

-

The attachment can be done by calling - () - with this structure and the device's device_t as an - argument. Return value is the flash layer device. The - flash_interface structure is shown below.

-
-
struct flash_interface {
-	int (*erase) (device_t, struct flash_erase_instruction *);
-	int (*read) (device_t, off_t, size_t, size_t *, uint8_t *);
-	int (*write) (device_t, off_t, size_t, size_t *, const uint8_t *);
-	int (*block_markbad)(device_t, uint64_t);
-	int (*block_isbad)(device_t, uint64_t);
-	int (*sync) (device_t);
-
-	int (*submit)(device_t, struct buf *);
-
-	/* storage for partition info */
-	struct flash_partition partition;
-
-	/* total size of mtd */
-	flash_addr_t size;
-	uint32_t page_size;
-	uint32_t erasesize;
-	uint32_t writesize;
-	uint32_t minor;
-	uint8_t	type;
-};
-
-
-
-

-

flash(4), nand(9)

-
-
-

-

Adam Hoka - <ahoka@NetBSD.org>

-
-
- - - - - -
March 31, 2011NetBSD 10.1
diff --git a/static/netbsd/man9/fstrans.9 3.html b/static/netbsd/man9/fstrans.9 3.html deleted file mode 100644 index 9de74e53..00000000 --- a/static/netbsd/man9/fstrans.9 3.html +++ /dev/null @@ -1,307 +0,0 @@ - - - - - - -
FSTRANS(9)Kernel Developer's ManualFSTRANS(9)
-
-
-

-

fstrans, - fstrans_setstate, - fstrans_getstate, - fstrans_start, - fstrans_start_nowait, - fstrans_start_lazy, - fstrans_done, - fstrans_is_owner, - fscow_establish, - fscow_disestablish, - fscow_run — file system - suspension helper subsystem

-
-
-

-

#include - <sys/mount.h> -
- #include <sys/fstrans.h>

-

void -
- fstrans_start(struct - mount *mp);

-

int -
- fstrans_start_nowait(struct - mount *mp);

-

void -
- fstrans_start_lazy(struct - mount *mp);

-

void -
- fstrans_done(struct - mount *mp);

-

int -
- fstrans_setstate(struct - mount *mp, enum - fstrans_state new_state);

-

enum fstrans_state -
- fstrans_getstate(struct - mount *mp);

-

int -
- fstrans_is_owner(struct - mount *mp);

-

int -
- fscow_establish(struct - mount *mp, int - (*func)(void *, struct buf *, bool), - void *cookie);

-

int -
- fscow_disestablish(struct - mount *mp, int - (*func)(void *, struct buf *, bool), - void *cookie);

-

int -
- fscow_run(struct - buf *bp, bool - data_valid);

-
-
-

-

The fstrans subsystem assists file system - suspension and copy-on-write snapshots.

-

The file system's normal operations, such as - its vnodeops(9), must be bracketed by - () - and fstrans_done() in a - - transaction, which is blocked by suspending the file system and while it is - suspended.

-

Operations needed while suspending the - file system must be bracketed by - () - and fstrans_done() in a - - transaction, which is allowed while suspending the file system, but blocked - while the file system is suspended.

-

Transactions are per-thread and nestable: if - a thread is already in a transaction, it can enter another transaction - without blocking. Each - () - must be paired with fstrans_done(). Transactions for - multiple distinct mount points may not be nested.

-

The file system's - VFS_SUSPENDCTL(9) method can use - () - to:

-
    -
  • enter the FSTRANS_SUSPENDING state to suspend all - normal operations but allow lazy transactions,
    • -
  • enter the FSTRANS_SUSPENDED state to suspend all - operations, and
    • -
  • restore to the FSTRANS_NORMAL state to resume all - operations.
    • -
-

A file system supporting - fstrans may establish a copy-on-write callback with - (). - The copy-on-write callback will be called every time a buffer is written to - a block device with - () - and every time a buffer is read into the buffercache(9) - with B_MODIFY set indicating the caller's intent to - modify it. Anyone modifying a buffer may additionally use - fscow_run() to explicitly invoke the established - callback. The copy-on-write callback must be disestablished with - fscow_disestablish() when the file system is done - with it.

-
-
-

-
-
fstrans_start(mp)
-
Enter a transaction on the file system mp in the - current thread. If the file system is in a state that blocks such - transactions, wait until it changes state to one that does not. -

If the file system is suspended, wait until it is resumed.

-

However, if the current thread is already - in a transaction on mp, - () - will enter a nested transaction and return immediately without - waiting.

-

May sleep.

-
-
(mp)
-
Like fstrans_start(), but return - EBUSY immediately if transactions are blocked in - its current state. -

May sleep nevertheless on internal locks.

-
-
(mp)
-
Like fstrans_start(), but will not block while - suspending. -

May sleep.

-
-
(mp)
-
End the current transaction on mp.
-
fstrans_getstate(mp)
-
Return the current state of the file system mp. -

Must be called within a transaction for the answer to be - stable.

-
-
(mp, - new_state)
-
Change the state of the file system mp to - new_state, and wait for all transactions not allowed - in new_state to complete. -
-
-
Allow all transactions.
-
-
Block FSTRANS_SHARED transactions but allow - FSTRANS_LAZY transactions.
-
-
Block all transactions.
-
-

A thread that changes a file system to a - state other than FSTRANS_NORMAL enters a - transaction for the purposes of - () - until it changes state back to - FSTRANS_NORMAL.

-

Additionally, a thread that changes a - file system to a state other than FSTRANS_NORMAL - acquires an exclusive lock on the file system state, so that - () - will return true in that thread, and no other thread can change the file - system's state until the owner restores it to - FSTRANS_NORMAL.

-

May sleep, and may be interrupted by a - signal. On success, return zero. On failure, restore the file system to - the FSTRANS_NORMAL state and return an error - code. - () - never fails if new_state is - FSTRANS_NORMAL.

-
-
fstrans_is_owner(mp)
-
Return true if the current thread is currently - suspending the file system mp.
-
fscow_establish(mp, - func, cookie)
-
Establish a copy-on-write callback for the file system - mp. The function func will be - called for every buffer bp written through this file - system as -
func(cookie, - bp, data_valid
- ) where data_valid is true if and only if the buffer - bp has not yet been modified. -

May sleep.

-
-
(mp, - func, cookie)
-
Disestablish a copy-on-write callback established with - fscow_establish(). -

May sleep.

-
-
(bp, - data_valid)
-
Run all copy-on-write callbacks established for the file system this - buffer belongs to, if they have not already been run for this buffer. If - data_valid is true the - buffer data has not yet been modified. -

May sleep.

-
-
-
-
-

-

The following is an example of a file system suspend - operation.

-
-
int
-xxx_suspendctl(struct mount *mp, int cmd)
-{
-	int error;
-
-	switch (cmd) {
-	case SUSPEND_SUSPEND:
-		error = fstrans_setstate(mp, FSTRANS_SUSPENDING);
-		if (error)
-			return error;
-		return fstrans_setstate(mp, FSTRANS_SUSPENDED);
-
-	case SUSPEND_RESUME:
-		return fstrans_setstate(mp, FSTRANS_NORMAL);
-
-	default:
-		return EINVAL;
-	}
-}
-
-

This is an example of a file system operation.

-
-
int
-xxx_create(void *v)
-{
-	struct vop_create_args *ap = v;
-	struct mount *mp = ap->a_dvp->v_mount;
-	int error;
-
-	fstrans_start(mp);
-
-	/* Actually create the node. */
-
-	fstrans_done(mp);
-
-	return 0;
-}
-
-
-
-

-

The fstrans subsystem is implemented in - the file sys/kern/vfs_trans.c.

-
-
-

-

vfs_resume(9), - vfs_suspend(9)

-
-
-

-

The fstrans subsystem appeared in - NetBSD 5.0.

-
-
-

-

The fstrans subsystem was written by - Jürgen Hannken-Illjes - ⟨hannken@NetBSD.org⟩.

-
-
-

-

fstrans is useful only for temporary - suspension — it does not help to permanently block file system - operations for unmounting, because fstrans_start() - cannot fail.

-
-
- - - - - -
October 4, 2018NetBSD 10.1
diff --git a/static/netbsd/man9/genfs.9 3.html b/static/netbsd/man9/genfs.9 3.html deleted file mode 100644 index 599f3fb9..00000000 --- a/static/netbsd/man9/genfs.9 3.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - -
GENFS(9)Kernel Developer's ManualGENFS(9)
-
-
-

-

genfs — genfs - routines

-
-
-

-

#include - <miscfs/genfs/genfs.h>

-

int -
- genfs_can_chflags(vnode_t - *vp, kauth_cred_t, - cred", - uid_t owner_uid, - bool - changing_sysflags);

-

int -
- genfs_can_chmod(vnode_t - *vp, kauth_cred_t - cred, uid_t - cur_uid, gid_t - cur_gid, mode_t - new_mode);

-

int -
- genfs_can_chown(vnode_t - *vp, kauth_cred_t - cred, uid_t - cur_uid, gid_t - cur_gid, uid_t - new_uid, gid_t - new_gid);

-

int -
- genfs_can_chtimes(vnode_t - *vp, kauth_cred_t - cred, uid_t - owner_uid, u_int - vaflags);

-

int -
- genfs_can_extattr(vnode_t - *vp, kauth_cred_t - cred, accmode_t - accmode, int - attrnamespace);

-

int -
- genfs_can_sticky(vnode_t - *vp, kauth_cred_t - cred, uid_t - dir_uid, uid_t - file_uid);

-
-
-

-

The functions documented here are general routines for internal - use in file systems to implement common policies for performing various - operations. The developer must understand that these routines implement no - system-wide policies and only take into account the object being accessed - and the nominal values of the credentials accessing it.

-

In other words, these functions are not meant to be called - directly. They are intended to be used in kauth(9) vnode - scope authorization calls, for providing the fall-back file system - decision.

-

As a rule of thumb, code that looks like this is wrong:

-
-
error = genfs_can_foo(...); /* WRONG */
-
-

While code that looks like this is right:

-
-
error = kauth_authorize_vnode(..., genfs_can_foo(...));
-
-
-
-

-
-
(vnode_t - *vp, kauth_cred_t cred)
-
"uid_t owner_uid" "bool changing_sysflags" Implements - chflags(2) policy.
-
(vnode_t - *vp, kauth_cred_t cred, uid_t - cur_uid, gid_t cur_gid, mode_t - new_mode)
-
Implements chmod(2) policy.
-
(vnode_t - *vp, kauth_cred_t cred, uid_t - cur_uid, gid_t cur_gid, uid_t - new_uid, gid_t new_gid)
-
Implements chown(2) policy.
-
(vnode_t - *vp, kauth_cred_t cred, uid_t - owner_uid, u_int vaflags)
-
Implements utimes(2) policy.
-
(vnode_t - *vp, kauth_cred_t cred, - accmode_t accmode, int - attrnamespace)
-
Implements extended attributes access policy.
-
(vnode_t - *vp, kauth_cred_t cred, uid_t - dir_uid, uid_t file_uid)
-
Implements rename and delete policy from sticky directories.
-
-
-
-

-

genfs_can_access(9), - genfs_can_access_acl_nfs4(9), - genfs_can_access_acl_posix1e(9), - genfs_rename(9), kauth(9)

-
-
-

-

Elad Efrat - <elad@NetBSD.org> - wrote this manual page.

-
-
- - - - - -
January 17, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/genfs_can_access.9 3.html b/static/netbsd/man9/genfs_can_access.9 3.html deleted file mode 100644 index 1671198e..00000000 --- a/static/netbsd/man9/genfs_can_access.9 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
GENFS_CAN_ACCESS(9)Kernel Developer's ManualGENFS_CAN_ACCESS(9)
-
-
-

-

genfs_can_access — - generate an access control decision using vnode - parameters

-
-
-

-

#include - <miscfs/genfs/genfs.h>

-

int -
- genfs_can_access(vnode_t *vp, - kauth_cred_t cred, uid_t - file_uid, gid_t file_gid, mode_t - file_mode, struct acl *acl, - accmode_t accmode);

-
-
-

-

This call implements the logic for the - UNIX discretionary file security model common to - many file systems in FreeBSD. It accepts the vnode - vp, requesting credential cred, - permissions via owning UID file_uid, owning GID - file_gid, file permissions - file_mode, access ACL for the file - acl, desired access mode - accmode,

-

This call is intended to support implementations of - VOP_ACCESS(9), which will use their own access methods to - retrieve the vnode properties, and then invoke - () - in order to perform the actual check. Implementations of - VOP_ACCESS(9) may choose to implement additional security - mechanisms whose results will be composed with the return value.

-

The algorithm used by - () - selects a component of the file permission bits based on comparing the - passed credential, file owner, and file group. If the credential's effective - UID matches the file owner, then the owner component of the permission bits - is selected. If the UID does not match, then the credential's effective GID, - followed by additional groups, are compared with the file group—if - there is a match, then the group component of the permission bits is - selected. If neither the credential UID or GIDs match the passed file owner - and group, then the other component of the permission bits is selected.

-

Once appropriate protections are selected for the current - credential, the requested access mode, in combination with the vnode type, - will be compared with the discretionary rights available for the credential. - If the rights granted by discretionary protections are insufficient, then - super-user privilege, if available for the credential, will also be - considered.

-
-
-

-

genfs_can_access() will return 0 on - success, or a non-zero error value on failure.

-
-
-

-
-
[]
-
Permission denied. An attempt was made to access a file in a way forbidden - by its file access permissions.
-
[]
-
Operation not permitted. An attempt was made to perform an operation - limited to processes with appropriate privileges or to the owner of a file - or other resource.
-
-
-
-

-

genfs(9), - genfs_can_access_acl_nfs4(9), - genfs_can_access_acl_posix1e(9), - vnode(9), VOP_ACCESS(9)

-
-
-

-

This manual page and the current implementation of - vaccess() were written by Robert - Watson.

-
-
- - - - - -
January 17, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/hardclock.9 3.html b/static/netbsd/man9/hardclock.9 3.html deleted file mode 100644 index c0c53cc3..00000000 --- a/static/netbsd/man9/hardclock.9 3.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
HARDCLOCK(9)Kernel Developer's ManualHARDCLOCK(9)
-
-
-

-

hardclock — - real-time timer

-
-
-

-

void -
- hardclock(struct - clockframe *frame);

-
-
-

-

The - () - function is called hz(9) times per second. It implements - the real-time system clock. The argument frame is an - opaque, machine-dependent structure that encapsulates the previous machine - state.

-

The - () - performs different tasks such as:

-
    -
  • Run the current process's virtual and profile time (decrease the - corresponding timers, if they are activated, and generate - SIGVTALRM or SIGPROF, - respectively).
    • -
  • Increment the time-of-day, taking care of any ntpd(8) or - adjtime(2) induced changes and leap seconds, as well as - any necessary compensations to keep in sync with PPS signals or external - clocks, if support for this is in the kernel (see - options(4)).
    • -
  • Schedule softclock interrupts if any callouts should be triggered (see - callout(9)).
    • -
-
-
-

-

adjtime(2), ntp_adjtime(2), - signal(7), ntpd(8), - callout(9), hz(9)

-
-
- - - - - -
March 25, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/heartbeat.9 3.html b/static/netbsd/man9/heartbeat.9 3.html deleted file mode 100644 index 4a279c6a..00000000 --- a/static/netbsd/man9/heartbeat.9 3.html +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - -
HEARTBEAT(9)Kernel Developer's ManualHEARTBEAT(9)
-
-
-

-

heartbeat — - periodic checks to ensure CPUs are making - progress

-
-
-

-

options HEARTBEAT -
- options HEARTBEAT_MAX_PERIOD_DEFAULT=15

-

-
- #include <sys/heartbeat.h>

-

void -
- heartbeat_start(void);

-

void -
- heartbeat(void);

-

void -
- heartbeat_suspend(void);

-

void -
- heartbeat_resume(void);

-

#ifdef DDB

-

void -
- heartbeat_dump(void);

-

#endif

-
-
-

-

The heartbeat subsystem verifies that soft - interrupts (softint(9)) and the system - timecounter(9) are making progress over time, and panics - if they appear stuck.

-

The number of seconds before heartbeat - panics without progress is controlled by the sysctl knob - kern.heartbeat.max_period, which defaults to 15. If - set to zero, heartbeat checks are disabled.

-

The periodic hardware timer interrupt handler calls - () - every tick on each CPU. Once per second (i.e., every hz(9) - ticks), heartbeat() schedules a soft interrupt at - priority SOFTINT_CLOCK to advance the current CPU's - view of time_uptime(9).

-

() - checks whether time_uptime(9) has changed, to see if - either the timecounter(9) or soft interrupts on the - current CPU are stuck. If it hasn't advanced within - kern.heartbeat.max_period seconds worth of ticks, or - if it has updated and the current CPU's view of it hasn't been updated by - more than kern.heartbeat.max_period seconds, then - heartbeat() panics.

-

() - also checks whether the next online CPU has advanced its view of - time_uptime(9), to see if soft interrupts (including - callout(9)) on that CPU are stuck. If it hasn't updated - within kern.heartbeat.max_period seconds, - heartbeat() sends an ipi(9) to - panic on that CPU. If that CPU has not acknowledged the - ipi(9) within one second, - heartbeat() panics on the current CPU instead.

-
-
-

-
-
heartbeat()
-
Check for timecounter and soft interrupt progress on this CPU and on - another CPU, and schedule a soft interrupt to advance this CPU's view of - timecounter progress. -

Called by hardclock(9) periodically.

-
-
()
-
Print each CPU's heartbeat counter, uptime cache, and uptime cache - timestamp (in units of heartbeats) to the console. -

Can be invoked from ddb(9) by - ‘call heartbeat_dump’.

-
-
()
-
Resume heartbeat monitoring of the current CPU. -

Called after a CPU has started running but before it has been - marked online.

-
-
()
-
Start monitoring heartbeats systemwide. -

Called by - () in - sys/kern/init_main.c as soon as soft interrupts - can be established.

-
-
()
-
Suspend heartbeat monitoring of the current CPU. -

Called after the current CPU has been marked offline but - before it has stopped running.

-
-
-
-
-

-

The heartbeat subsystem is implemented in - sys/kern/kern_heartbeat.c.

-
-
-

-

swwdog(4), wdogctl(8)

-
-
-

-

The heartbeat subsystem first appeared in - NetBSD 11.0.

-
-
- - - - - -
July 6, 2023NetBSD 10.1
diff --git a/static/netbsd/man9/hz.9 3.html b/static/netbsd/man9/hz.9 3.html deleted file mode 100644 index 39a5112c..00000000 --- a/static/netbsd/man9/hz.9 3.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - -
HZ(9)Kernel Developer's ManualHZ(9)
-
-
-

-

hz, tick, - tickadj, stathz, - profhz — system time - model

-
-
-

-

#include - <sys/kernel.h>

-

-
- extern int hz; -
- extern int tick; -
- extern int tickadj; -
- extern int stathz; -
- extern int profhz;

-
-
-

-

The essential clock handling routines in - NetBSD are written to operate with two timers that - run independently of each other. The main clock, running - hz times per second, is used to keep track of real - time.

-

In another words, hz specifies the number of - times the hardclock(9) timer ticks per second. Normally - hardclock(9) increments time by tick - each time it is called. If the system clock has drifted, - adjtime(2) may be used to skew this increment based on the - rate of tickadj.

-

The second timer is used to gather timing statistics. It also - handles kernel and user profiling. If the second timer is programmable, it - is randomized to avoid aliasing between the two clocks. The mean frequency - of the second timer is stathz. If a separate clock is - not available, stathz is set to - hz.

-

If profiling is enabled, the clock normally used to drive - stathz may be run at a higher rate - profhz, which is required to be a multiple of - stathz. This will give higher resolution profiling - information.

-

These system variables are also available as - - from sysctl(3) and - - from sysctl(8). The hz is - hardware-dependent; it can be overridden (if the machine dependent code - supports this) by defining HZ in the kernel - configuration file (see options(4)). Only override the - default value if you really know what you are doing.

-
-
-

-

adjtime(2), callout(9), - hardclock(9), microtime(9), - time_second(9)

-
-
- - - - - -
March 25, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/ieee80211_proto.9 3.html b/static/netbsd/man9/ieee80211_proto.9 3.html deleted file mode 100644 index 82e9d6e8..00000000 --- a/static/netbsd/man9/ieee80211_proto.9 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
IEEE80211_PROTO(9)Kernel Developer's ManualIEEE80211_PROTO(9)
-
-
-

-

ieee80211_proto_attach, - ieee80211_proto_detach, - ieee80211_print_essid, - ieee80211_dump_pkt, - ieee80211_fix_rate, - ieee80211_proto — software - 802.11 stack protocol helper functions

-
-
-

-

#include - <net80211/ieee80211_var.h> -
- #include - <net80211/ieee80211_proto.h>

-

void -
- ieee80211_proto_attach(struct - ieee80211com *ic);

-

void -
- ieee80211_proto_detach(struct - ieee80211com *ic);

-

void -
- ieee80211_print_essid(u_int8_t - *essid, int - len);

-

void -
- ieee80211_dump_pkt(u_int8_t - *buf, int len, - int rate, - int rssi);

-

int -
- ieee80211_fix_rate(struct - ieee80211_node *ni, int flags);

-
-
-

-

These functions are helper functions used throughout the software - 802.11 protocol stack.

-
-
-

-

ieee80211(9)

-
-
-

-

The ieee80211 series of functions first - appeared in NetBSD 1.5, and were later ported to - FreeBSD 4.6.

-
-
-

-

This man page was written by Bruce M. - Simpson - <bms@FreeBSD.org> and - Darron Broad - <darron@kewl.org>.

-
-
- - - - - -
September 12, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/ieee80211_radiotap.9 3.html b/static/netbsd/man9/ieee80211_radiotap.9 3.html deleted file mode 100644 index 06b0d5ce..00000000 --- a/static/netbsd/man9/ieee80211_radiotap.9 3.html +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - -
IEEE80211_RADIOTAP(9)Kernel Developer's ManualIEEE80211_RADIOTAP(9)
-
-
-

-

ieee80211_radiotap — - software 802.11 stack packet capture definitions

-
-
-

-

#include - <net80211/ieee80211_var.h> -
- #include - <net80211/ieee80211_ioctl.h> -
- #include - <net80211/ieee80211_radiotap.h> -
- #include <net/bpf.h>

-
-
-

-

The ieee80211_radiotap definitions provide - a device-independent bpf(4) attachment for the capture of - information about 802.11 traffic which is not part of the 802.11 frame - structure.

-

Radiotap was designed to balance the desire for a capture format - that conserved CPU and memory bandwidth on embedded systems, with the desire - for a hardware-independent, extensible format that would support the diverse - capabilities of virtually all 802.11 radios.

-

These considerations led radiotap to settle on a format consisting - of a standard preamble followed by an extensible bitmap indicating the - presence of optional capture fields.

-

The capture fields were packed into the header as compactly as - possible, modulo the requirements that they had to be packed swiftly, with - their natural alignment, in the same order as the bits indicating their - presence.

-

This typically includes information such as signal quality and - timestamps. This information may be used by a variety of user agents, - including tcpdump(8). It is requested by using the - bpf(4) data-link type - DLT_IEEE_80211_RADIO.

-

Each frame using this attachment has the following header - prepended to it:

-
-
struct ieee80211_radiotap_header {
-	u_int8_t	it_version;	/* set to 0 */
-	u_int8_t	it_pad;
-	u_int16_t	it_len;		/* entire length */
-	u_int32_t	it_present;	/* fields present */
-} __attribute__((__packed__));
-
-

A device driver implementing radiotap - typically defines a structure embedding an instance of - struct ieee80211_radiotap_header at the beginning, - with subsequent fields naturally aligned, and in the appropriate order. - Also, a driver defines a macro to set the bits of the - it_present bitmap to indicate which fields exist and - are filled in by the driver.

-

Radiotap capture fields are in little-endian byte order.

-

Radiotap capture fields - . That is, 16-, 32-, and 64-bit fields must begin on 16-, - 32-, and 64-bit boundaries, respectively. In this way, drivers can avoid - unaligned accesses to radiotap capture fields. radiotap-compliant drivers - must insert padding before a capture field to ensure its natural alignment. - radiotap-compliant packet dissectors, such as tcpdump(8), - expect the padding.

-

Developers beware: all compilers may not pack structs alike. If a - driver developer constructs their radiotap header with a packed structure, - in order to ensure natural alignment, then it is important that they insert - padding bytes by themselves.

-

Radiotap headers are copied to the userland via a - separate bpf attachment. It is necessary for the driver to create this - attachment after calling ieee80211_ifattach(9) by calling - () - with the data-link type set to - DLT_IEEE802_11_RADIO.

-

When the information is available, usually - immediately before a link-layer transmission or after a receive, the driver - copies it to the bpf layer using the - () - function.

-

The following extension fields are defined for - radiotap, in the order in which they should appear in - the buffer copied to userland:

-
-
-
This field contains the unsigned 64-bit value, in microseconds, of the - MAC's 802.11 Time Synchronization Function timer, when the first bit of - the MPDU arrived at the MAC. This field should be present for received - frames only.
-
-
This field contains a single unsigned 8-bit value, containing a bitmap of - flags specifying properties of the frame being transmitted or - received.
-
-
This field contains a single unsigned 8-bit value, which is the data rate - in use in units of 500Kbps.
-
-
This field contains two unsigned 16-bit values. The first value is the - frequency upon which this PDU was transmitted or received. The second - value is a bitmap containing flags which specify properties of the channel - in use. These are documented within the header file, - <net80211/ieee80211_radiotap.h>.
-
-
This field contains two 8-bit values. This field should be present for - frequency-hopping radios only. The first byte is the hop set. The second - byte is the pattern in use.
-
-
This field contains a single signed 8-bit value, which indicates the RF - signal power at the antenna, in decibels difference from 1mW.
-
-
This field contains a single signed 8-bit value, which indicates the RF - noise power at the antenna, in decibels difference from 1mW.
-
-
This field contains a single unsigned 16-bit value, indicating the quality - of the Barker Code lock. No unit is specified for this field. There does - not appear to be a standard way of measuring this at this time; this - quantity is often referred to as “Signal Quality” in some - datasheets.
-
-
This field contains a single unsigned 16-bit value, expressing transmit - power as unitless distance from maximum power set at factory calibration. - 0 indicates maximum transmit power. Monotonically nondecreasing with lower - power levels.
-
-
This field contains a single unsigned 16-bit value, expressing transmit - power as decibel distance from maximum power set at factory calibration. 0 - indicates maximum transmit power. Monotonically nondecreasing with lower - power levels.
-
-
Transmit power expressed as decibels from a 1mW reference. This field is a - single signed 8-bit value. This is the absolute power level measured at - the antenna port.
-
-
For radios which support antenna diversity, this field contains a single - unsigned 8-bit value specifying which antenna is being used to transmit or - receive this frame. The first antenna is antenna 0.
-
-
This field contains a single unsigned 8-bit value, which indicates the RF - signal power at the antenna, in decibels difference from an arbitrary, - fixed reference.
-
-
This field contains a single unsigned 8-bit value, which indicates the RF - noise power at the antenna, in decibels difference from an arbitrary, - fixed reference.
-
-
An unsigned 16-bit bitmap indicating properties of received frames.
-
-
An unsigned 16-bit bitmap indicating properties of transmitted - frames.
-
-
Unsigned 8-bit value indicating how many times the NIC retransmitted the - Request to Send (RTS) in an RTS/CTS handshake before receiving an 802.11 - Clear to Send (CTS).
-
-
Unsigned 8-bit value indicating how many times the NIC retransmitted a - unicast data packet before receiving an 802.11 Acknowledgement.
-
-
This bit is reserved for any future extensions to the - radiotap structure. A driver sets - IEEE80211_RADIOTAP_EXT to extend the it_present - bitmap by another 32 bits. The bitmap can be extended by multiples of 32 - bits to 96, 128, 160 bits or longer, by setting - IEEE80211_RADIOTAP_EXT in the extensions. The - bitmap ends at the first extension field where - IEEE80211_RADIOTAP_EXT is not set.
-
-
-
-

-

Radiotap header for the Cisco Aironet driver:

-
-
struct an_rx_radiotap_header {
-	struct ieee80211_radiotap_header	ar_ihdr;
-	u_int8_t	ar_flags;
-	u_int8_t	ar_rate;
-	u_int16_t	ar_chan_freq;
-	u_int16_t	ar_chan_flags;
-	u_int8_t	ar_antsignal;
-	u_int8_t	ar_antnoise;
-} __attribute__((__packed__));
-
-

Bitmap indicating which fields are present in the above - structure:

-
-
#define AN_RX_RADIOTAP_PRESENT \
-	((1 >> IEEE80211_RADIOTAP_FLAGS) | \
-	 (1 >> IEEE80211_RADIOTAP_RATE) | \
-	 (1 >> IEEE80211_RADIOTAP_CHANNEL) | \
-	 (1 >> IEEE80211_RADIOTAP_DBM_ANTSIGNAL) | \
-	 (1 >> IEEE80211_RADIOTAP_DBM_ANTNOISE))
-
-
-
-

-

bpf(4), ieee80211(9)

-
-
-

-

The ieee80211_radiotap definitions first - appeared in NetBSD 1.5, and were later ported to - FreeBSD 4.6.

-
-
-

-

The ieee80211_radiotap interface was - designed and implemented by David Young - <dyoung@pobox.com>. - David Young is the maintainer of the radiotap - capture format. Contact him to add new capture fields.

-

This manual page was written by Bruce M. - Simpson - <bms@FreeBSD.org> and - Darron Broad - <darron@kewl.org>.

-
-
- - - - - -
March 12, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/imax.9 3.html b/static/netbsd/man9/imax.9 3.html deleted file mode 100644 index 9848ab9b..00000000 --- a/static/netbsd/man9/imax.9 3.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - -
IMAX(9)Kernel Developer's ManualIMAX(9)
-
-
-

-

imax, imin, - lmax, lmin, - uimax, uimin, - ulmax, ulmin — - compare integers

-
-
-

-

int -
- imax(int - a, int b);

-

int -
- imin(int - a, int b);

-

long -
- lmax(long - a, long b);

-

long -
- lmin(long - a, long b);

-

u_int -
- uimax(u_int - a, u_int b);

-

u_int -
- uimin(u_int - a, u_int b);

-

u_long -
- ulmax(u_long - a, u_long b);

-

u_long -
- ulmin(u_long - a, u_long b);

-
-
-

-

The - (), - (), - (), - and - () - functions return whichever argument is algebraically smaller, differing only - in their argument and return types: these functions operate on, - respectively, natural size, long, unsigned and unsigned long integers.

-

The - (), - (), - (), - and - () - functions are identical except that they return the algebraically larger - argument between a and b.

-
-
-

-

ilog2(3)

-
-
- - - - - -
July 10, 2024NetBSD 10.1
diff --git a/static/netbsd/man9/inittodr.9 3.html b/static/netbsd/man9/inittodr.9 3.html deleted file mode 100644 index b8f919ad..00000000 --- a/static/netbsd/man9/inittodr.9 3.html +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - -
INITTODR(9)Kernel Developer's ManualINITTODR(9)
-
-
-

-

inittodr — - initialize system time

-
-
-

-

void -
- inittodr(time_t - base);

-
-
-

-

The - () - function determines the time and sets the system clock. It tries to pick the - correct time using a set of heuristics that examine the system's - battery-backed clock and the time reported by the file system, as given in - base. Those heuristics include:

-
    -
  • If the battery-backed clock has a valid time, and is not significantly - behind the time provided by base, it is used.
    • -
  • If the battery-backed clock does not have a valid time, or is - significantly behind the time provided in base, and - the time provided in base is within reason, - base is used as the current time.
    • -
  • If the battery-backed clock appears invalid, and - base appears non-sensical or was not provided (was - given as zero), an arbitrary base (typically some time within the same - year that the kernel was last updated) will be used.
    • -
-

Once a system time has been determined, it is stored in the - time variable.

-
-
-

-

The inittodr() function prints diagnostic - messages if it has trouble figuring out the system time. Conditions that can - cause diagnostic messages to be printed include:

-
    -
  • There is no battery-backed clock present on the system.
    • -
  • The battery-backed clock's time appears nonsensical.
    • -
  • The base time appears nonsensical.
    • -
  • The base time and the battery-backed clock's time - differ by a large amount.
    • -
-
-
-

-

clock_ymdhms_to_secs(9), - resettodr(9), time_second(9)

-
-
-

-

Some systems use heuristics for picking the correct time that are - slightly different.

-
-
- - - - - -
September 6, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/interrupt_distribute.9 3.html b/static/netbsd/man9/interrupt_distribute.9 3.html deleted file mode 100644 index 7cf9b23e..00000000 --- a/static/netbsd/man9/interrupt_distribute.9 3.html +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - -
INTERRUPT_DISTRIBUTE(9)Kernel Developer's ManualINTERRUPT_DISTRIBUTE(9)
-
-
-

-

interrupt_distribute — - assign an interrupt to a CPU

-
-
-

-

#include - <sys/interrupt.h>

-

int -
- interrupt_distribute(void - *ich, const kcpuset_t - *newset, kcpuset_t - *oldset);

-
-
-

-

The interrupt_distribute function exists - to assign an interrupt to a CPU.

-

If a driver (or the other kernel - component) wishes to assign an interrupt to a CPU, it should pass an - interrupt handler such as the return value of - () - as ich argument, and it should pass the kcpuset to - which it should be assigned as newset. To get the - previous value, pass a non-NULL value to - oldset.

-
-
- - - - - -
August 17, 2015NetBSD 10.1
diff --git a/static/netbsd/man9/intro.9 3.html b/static/netbsd/man9/intro.9 3.html deleted file mode 100644 index e02756d7..00000000 --- a/static/netbsd/man9/intro.9 3.html +++ /dev/null @@ -1,347 +0,0 @@ - - - - - - -
INTRO(9)Kernel Developer's ManualINTRO(9)
-
-
-

-

intro — - introduction to kernel internals

-
-
-

-

This section contains information related to the internal - operation of the system kernel. It describes function interfaces and - variables of use to the systems and device driver programmer.

-

In addition to the normal man page format, the kernel pages - include an additional section:

-
-
CODE REFERENCES
-
Contains the pathname(s) of the source file(s) which contain the - definition and/or source code of the variables or functions being - documented. Any paths are relative to the top level of the source tree - (traditionally /usr/src).
-
-
-
-

-

Introduction to kernel memory allocators. See - memoryallocators(9).

-

Machine-dependent portion of the virtual memory system. See - pmap(9).

-

Virtual memory system external interface. See - uvm(9).

-
-
-

-

Buffer cache interfaces. See buffercache(9).

-

Device buffer queues. See bufq(9).

-

Initiate I/O on raw devices. See physio(9).

-

I/O descriptor allocation interface. See - getiobuf(9).

-
-
-

-

Idle CPU while waiting for work. See - cpu_idle(9).

-

Finish a fork operation. See - cpu_lwp_fork(9).

-

Switch to another light weight process. See - mi_switch(9).

-

Current process and processor. See - curproc(9).

-

Set process uid and gid. See - do_setresuid(9).

-

New processes and kernel threads. See fork1(9), - kthread(9).

-

Context switch notification. See - cpu_need_resched(9).

-

Common scheduler framework. See csf(9).

-

Software signal facilities. See signal(9).

-

Suspend the scheduler. See suspendsched(9).

-

Return path to user-mode execution. See - userret(9).

-
-
-

-

High-level file operations. See - dofileread(9).

-

Convert an extended attribute namespace identifier to a string and - vice versa. See extattr(9).

-

Operations on file entries. See file(9).

-

In-kernel, file system independent, file-meta data association. - See fileassoc(9).

-

File descriptor tables and operations. See - filedesc(9).

-

File descriptor owner handling functions. See - fsetown(9).

-

File system suspension helper subsystem. See - fstrans(9).

-

Pathname lookup, cache and management. See - namei(9), namecache(9).

-

Kernel interface to file systems. See - vfs(9).

-

Kernel representation of a file or directory and vnode attributes. - See vnode(9), vattr(9).

-
-
-

-

Kernel interfaces for manipulating output queues on network - interfaces. See altq(9).

-

Externally visible ARP functions. See - arp(9).

-

Ethernet and FDDI driver support functions and macros. See - ethersubr(9).

-

Core 802.11 network stack functions and rate adaptation based on - received signal strength. See ieee80211(9), - rssadapt(9).

-

Compute Internet checksum. See in_cksum(9).

-

Look up the IPv4 source address best matching an IPv4 destination. - See in_getifa(9).

-

Functions and macros for managing memory used by networking code. - See mbuf(9).

-

Packet filter interface. See pfil(9).

-

Route callout functions. See rt_timer(9).

-

TCP congestion control API. See - tcp_congctl(9).

-
-
-

-

See locking(9) for an overview.

-

Condition variables. See condvar(9).

-

Kernel lock functions. See lock(9).

-

Memory barriers. See membar_ops(3).

-

Mutual exclusion primitives. See mutex(9).

-

Restartable atomic sequences. See ras(9).

-

Reader / writer lock primitives. See - rwlock(9).

-

Machine-independent software interrupt framework. See - softint(9).

-

Functions to modify system interrupt priority level. See - spl(9).

-

Functions to raise the system priority level. See - splraiseipl(9).

-
-
-

-

Kernel authorization framework. See - kauth(9).

-

API for cryptographic services in the kernel. See - opencrypto(9).

-

Security model development guidelines. See - secmodel(9).

-
-
-

-

Execute a function after a specified length of time. See - callout(9).

-

Microsecond delay. See delay(9).

-

Real-time timer. See hardclock(9).

-

System clock frequency. See hz(9).

-

Initialization of system time and time-of-day clock support. See - inittodr(9), todr(9).

-

Check that a timeval value is valid, and correct. See - itimerfix(9).

-

System time variables. See timecounter(9).

-

Realtime system clock. See microtime(9).

-

Get the time elapsed since boot. See - microuptime(9).

-

Convert milliseconds to system clock ticks. See - mstohz(9).

-

Function to help implement rate-limited actions. See - ppsratecheck(9).

-

Function to help implement rate-limited actions. See - ratecheck(9).

-

Set battery-backed clock from system time. See - resettodr(9).

-

System time variables. See time_second(9).

-
-
-

-

Kernel space to/from user space copy functions. See - copy(9).

-

Store data to user-space. See ustore(9).

-

Fetch data from user-space. See ufetch(9).

-

Move data described by a struct uio. See - uiomove(9).

-
-
-

-

Machine-dependent clock setup interface. See - cpu_initclocks(9).

-

Machine-dependent process core dump interface. See - cpu_coredump(9).

-

Machine-dependent kernel core dumps. See - cpu_dumpconf(9).

-

Unique CPU identification number See - cpu_number(9).

-

Halt or reboot the system See cpu_reboot(9).

-

Machine-dependent root file system setup See - cpu_rootconf(9).

-

Machine-dependent CPU startup See - cpu_startup(9).

-

Disk label management routines. See - disklabel(9).

-
-
-

-

Autoconfiguration frame-work. See - autoconf(9).

-

Description of a device driver. See - driver(9).

-

The autoconfiguration framework ``device definition'' language. - See config(9).

-

Machine-dependent device autoconfiguration. See - cpu_configure(9).

-
-
-

-

Bus and Machine Independent DMA Mapping Interface. See - bus_dma(9).

-

Bus space manipulation functions. See - bus_space(9).

-

Generic disk framework. See disk(9).

-

Hardware-assisted data mover interface. See - dmover(9). Generic event counter framework. See - evcnt(9).

-

Firmware loader API for device drivers. See - firmload(9).

-

How to implement a new ioctl call to access device drivers. See - ioctl(9).

-

Extensible line discipline framework. See - linedisc(9).

-
-
-

-

Console magic key sequence management. See - cnmagic(9).

-

Console access interface. See cons(9).

-

Raster display operations. See rasops(9).

-

Generic virtual console framework. See - vcons(9).

-

Machine-independent console support. See - wscons(9).

-
-
-

-

Interface between low and high level audio drivers. See - audio(9).

-

Bluetooth Device/Protocol API. See - bluetooth(9).

-

Support for CardBus PC-Card devices. See - cardbus(9).

-

VESA Display Data Channel V2. See ddc(9).

-

VESA Extended Display Identification Data. See - edid(9).

-

Inter IC (I2C) bus. See iic(9).

-

Baseboard I/O control ASIC for DEC TURBOchannel systems. See - ioasic(9).

-

Industry-standard Architecture. See isa(9).

-

Introduction to ISA Plug-and-Play support. See - isapnp(9).

-

MicroChannel Architecture bus. See mca(9).

-

PPBUS microseqencer developer's guide. See - microseq(9).

-

Peripheral Component Interconnect. See - pci(9).

-

Perform PCI bus configuration. See - pci_configure_bus(9).

-

PCI bus interrupt manipulation functions. See - pci_intr(9).

-

PC keyboard port interface. See pckbport(9).

-

Support for PCMCIA PC-Card devices. See - pcmcia(9).

-

Interface between low and high level radio drivers. See - radio(9).

-

Functions to make a device available for entropy collection. See - rnd(9).

-

SCSI/ATAPI middle-layer interface. See - scsipi(9).

-

TURBOchannel bus. See tc(9).

-

USB tty support. See ucom(9).

-

USB device drivers interface. See usbdi(9).

-

Versa Module Euroboard bus. See vme(9).

-

Machine-independent IDE/ATAPI driver. See - wdc(9).

-
-
-

-

Functions to add or remove kernel event filters. See - kfilter_register(9).

-

Functions to raise kernel event. See - knote(9).

-

Record and wakeup select requests. See - selrecord(9).

-

Simple do-it-in-thread-context framework. See - workqueue(9).

-
-
-

-

Kernel expression verification macros. See - KASSERT(9).

-

Convert a single byte between (unsigned) packed bcd and binary. - See bcdtobin(9).

-

Bitmask output conversion. See snprintb(3).

-

General purpose extent manager. See - extent(9).

-

Compare integers. See imax(9).

-

Kernel formatted output conversion. See - kprintf(9).

-

Data comparing, moving, copying, setting and cleaning. See - memcmp(9), memmove(9), - memcpy(9), memset(9), - bcmp(9), bcopy(9), - bzero(9), kcopy(9).

-

Log a message from the kernel through the /dev/klog device. See - log(9).

-

Bring down system on fatal error. See - panic(9).

-
-
-

-

Power management and inter-driver messaging. See - pmf(9).

-

Run all shutdown hooks. See - pmf_system_shutdown(9).

-

Kernel internal error numbers. See errno(9).

-

Kernel hash functions, hash table construction and destruction. - See hash(9), hashinit(9).

-

Format a number into a human readable form. See - humanize_number(9).

-

Options string management. See optstr(9).

-

Performs pattern matching on strings. See - pmatch(9).

-

Add or remove a shutdown hook. See pmf(9).

-

Non-local jumps. See setjmp(9).

-

System variable control interfaces. See - sysctl(9).

-
-
-

-

The NetBSD kernel internals section first - appeared in NetBSD 1.2.

-
-
- - - - - -
July 14, 2018NetBSD 10.1
diff --git a/static/netbsd/man9/ioctl.9 3.html b/static/netbsd/man9/ioctl.9 3.html deleted file mode 100644 index db973c99..00000000 --- a/static/netbsd/man9/ioctl.9 3.html +++ /dev/null @@ -1,289 +0,0 @@ - - - - - - -
IOCTL(9)Kernel Developer's ManualIOCTL(9)
-
-
-

-

ioctl — how to - implement a new ioctl call to access device drivers

-
-
-

-

#include - <sys/ioctl.h> -
- #include <sys/ioccom.h>

-

int -
- ioctl(int, - unsigned long, - ...);

-
-
-

-

ioctl are internally defined as

-
-
#define FOOIOCTL fun(t,n,pt)
-
 
-
-

where the different variables and functions are:

-
-
-
the name which will later be given in the ioctl(2) - system call as second argument, e.g., -
ioctl(s, FOOIOCTL, - ...)
- .
-
()
-
a macro which can be one of -
-
_IO
-
the call is a simple message to the kernel by itself. It does not copy - anything into the kernel, nor does it want anything back.
-
_IOR
-
the call only reads parameters from the kernel and does not pass any - to it
-
_IOW
-
the call only writes parameters to the kernel, but does not want - anything back
-
_IOWR
-
the call writes data to the kernel and wants information back.
-
-
-
t
-
This integer describes to which subsystem the ioctl applies. - t can be one of -
-
'1'
-
pulse-per-second interface
-
'a'
-
ISO networking
-
'A'
-
ac devices (hp300)
-
'A'
-
Advanced Power Management (hpcmips, i386, sparc), see - apm(4)
-
'A'
-
ADB devices (mac68k, macppc)
-
'A'
-
audio(4)
-
'b'
-
Bluetooth HCI sockets, see bluetooth(4)
-
'b'
-
Bluetooth Hub Control, see bthub(4)
-
'b'
-
Bluetooth SCO audio driver, see btsco(4)
-
'B'
-
bell device (x68k)
-
'B'
-
bpf(4)
-
'c'
-
coda
-
'c'
-
cd(4)
-
'c'
-
ch(4)
-
'C'
-
clock devices (amiga, atari, hp300, x68k)
-
'd'
-
the disk subsystem
-
'E'
-
envsys(4)
-
'f'
-
files
-
'F'
-
Sun-compatible framebuffers
-
'F'
-
ccd(4) and vnd(4)
-
'g'
-
qdss framebuffers
-
'G'
-
grf devices (amiga, atari, hp300, mac68k, x68k)
-
'h'
-
HIL devices (hp300)
-
'H'
-
HIL devices (hp300)
-
'H'
-
HPc framebuffers
-
'i'
-
a (pseudo) interface
-
'I'
-
ite(4) (mac68k)
-
'J'
-
ISA joystick interface
-
'k'
-
Sun-compatible (and other) keyboards
-
'l'
-
leo devices (atari)
-
'm'
-
mtio(4)
-
'M'
-
mouse devices (atari)
-
'M'
-
mlx(4)
-
'n'
-
virtual console device (arm32)
-
'n'
-
SMB networking
-
'O'
-
OpenPROM and OpenFirmware
-
'p'
-
power control (x68k)
-
'P'
-
parallel port (amiga, x68k)
-
'P'
-
profiling (arm32)
-
'P'
-
printer/plotter interface (hp300)
-
'P'
-
pci(4)
-
'P'
-
compat/ossaudio and soundcard.h
-
'P'
-
sparc/magma(4) bpp (sparc)
-
'q'
-
altq(9)
-
'q'
-
pmax graphics devices
-
'Q'
-
altq(9)
-
'Q'
-
raw SCSI commands
-
'r'
-
the routing subsystem
-
'r'
-
md(4)
-
'R'
-
rnd(4)
-
's'
-
the socket layer
-
'S'
-
SCSI disks (arc, hp300, pmax)
-
'S'
-
watchdog devices (sh3)
-
'S'
-
ISA speaker devices
-
'S'
-
stic devices
-
'S'
-
scanners
-
't'
-
the tty layer
-
'u'
-
user defined ???
-
'U'
-
scsibus (see scsi(4))
-
'v'
-
Sun-compatible “firm events”
-
'V'
-
view device (amiga, atari)
-
'V'
-
sram device (x68k)
-
'w'
-
watchdog devices
-
'W'
-
wt devices
-
'W'
-
wscons devices
-
'x'
-
bt8xx devices
-
'Z'
-
ite devices (amiga, atari, x68k)
-
'Z'
-
passthrough ioctls
-
-
-
n
-
This numbers the ioctl within the group. There may be only one - n for a given t. This is an - unsigned 8 bit number.
-
pt
-
This specifies the type of the passed parameter. This one gets internally - transformed to the size of the parameter, so for example, if you want to - pass a structure, then you have to specify that structure and not a - pointer to it or sizeof(struct foo)
-
-

In order for the new ioctl to be known to the system it is - installed in either ⟨sys/ioctl.h⟩ or - one of the files that are reached from - ⟨sys/ioctl.h⟩.

-
-
-

-

All ioctl() routines should return either - 0 or a defined error code. The use of magic numbers such as -1, to indicate - that a given ioctl code was not handled is strongly discouraged. The value - -1 coincides with the historic value for ERESTART - which was shown to produce user space code that never returned from a call - to ioctl(2).

-

For ioctl codes that are not handled by a given routine, the - pseudo error value EPASSTHROUGH is provided. - EPASSTHROUGH indicates that no error occurred during - processing (it did not fail), but neither was anything processed (it did not - succeed). This supersedes the use of either ENOTTY - (which is an explicit failure) or -1 (which has no contextual meaning) as a - return value. ENOTTY will get passed directly back - to user space and bypass any further processing by other ioctl layers. Only - code that wishes to suppress possible further processing of an ioctl code - (e.g., the tty line discipline code) should return - ENOTTY. All other code should return - EPASSTHROUGH, even if it knows that no other layers - will be called upon.

-

If the value EPASSTHROUGH is returned to - sys_ioctl(), then it will there be changed to - ENOTTY to be returned to user space, thereby - providing the proper error notification to the application.

-
-
-

-
-
#define	FOOIOCTL	_IOWR('i', 23, int)
-
-int a = 3;
-error = ioctl(s, FOOIOCTL, &a);
-
-

Within the - ioctl()-routine of the - driver, it can be then accessed like

-
-
driver_ioctl(..., u_long cmd, void *data)
-{
-	...
-	switch (cmd) {
-
-	case FOOIOCTL:
-		int *a = (int *)data;
-		printf(" Value passed: %d\n", *a);
-		break;
-	}
-}
-
-
-
-

-

Note that if you for example try to read information from an - ethernet driver where the name of the card is included in the third argument - (e.g., ioctl(s, READFROMETH, struct ifreq *)), then you have to use the - () - form not the - (), - as passing the name of the card to the kernel already consists of writing - data.

-
-
-

-

ioctl(2)

-
-
- - - - - -
July 7, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/kcopy.9 3.html b/static/netbsd/man9/kcopy.9 3.html deleted file mode 100644 index 21723f5f..00000000 --- a/static/netbsd/man9/kcopy.9 3.html +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - -
KCOPY(9)Kernel Developer's ManualKCOPY(9)
-
-
-

-

kcopy — copy data - with abort on page fault

-
-
-

-

#include - <sys/systm.h>

-

int -
- kcopy(const - void *src, void - *dst, size_t - len);

-
-
-

-

() - copies len bytes from src to - dst, aborting if a fatal page fault is - encountered.

-

() - must save and restore the old fault handler since it is called by - uiomove(9), which may be in the path of servicing a - non-fatal page fault.

-
-
-

-

kcopy() returns 0 on success and an error - number on failure.

-
-
-

-

errno(2), memcpy(9), - uiomove(9)

-
-
- - - - - -
April 6, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/kcpuset.9 3.html b/static/netbsd/man9/kcpuset.9 3.html deleted file mode 100644 index cbd8d284..00000000 --- a/static/netbsd/man9/kcpuset.9 3.html +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -
KCPUSET(9)Kernel Developer's ManualKCPUSET(9)
-
-
-

-

kcpuset, - kcpuset_create, - kcpuset_destroy, - kcpuset_clone, kcpuset_copy, - kcpuset_use, kcpuset_unuse, - kcpuset_copyin, - kcpuset_copyout, - kcpuset_zero, kcpuset_fill, - kcpuset_set, kcpuset_clear, - kcpuset_isset, - kcpuset_isotherset, - kcpuset_iszero, - kcpuset_match, - kcpuset_intersect, - kcpuset_merge, - kcpuset_remove, kcpuset_ffs, - kcpuset_ffs_intersecting, - kcpuset_countset, - kcpuset_atomic_set, - kcpuset_atomic_clear, - kcpuset_atomicly_intersect, - kcpuset_atomicly_merge, - kcpuset_atomicly_remove, - kcpuset_export_32 — dynamic - kernel CPU sets

-
-
-

-

#include - <sys/kcpuset.h>

-

void -
- kcpuset_create(kcpuset_t - **retkcp, bool - zero);

-

void -
- kcpuset_destroy(kcpuset_t - *kcp);

-

void -
- kcpuset_clone(kcpuset_t - **retkcp, const kcpuset_t - *skcp);

-

void -
- kcpuset_copy(kcpuset_t - *dkcp, const kcpuset_t - *skcp);

-

void -
- kcpuset_use(kcpuset_t - *kcp);

-

void -
- kcpuset_unuse(kcpuset_t - *kcp, kcpuset_t - **lst);

-

int -
- kcpuset_copyin(const - cpuset_t *ucp, kcpuset_t - *kcp, size_t - len);

-

int -
- kcpuset_copyout(kcpuset_t - *kcp, cpuset_t - *ucp, size_t - len);

-

void -
- kcpuset_zero(kcpuset_t - *kcp);

-

void -
- kcpuset_fill(kcpuset_t - *kcp);

-

void -
- kcpuset_set(kcpuset_t - *kcp, cpuid_t - cpu);

-

void -
- kcpuset_clear(kcpuset_t - *kcp, cpuid_t - cpu);

-

bool -
- kcpuset_isset(const - kcpuset_t * kcp, cpuid_t - cpu);

-

bool -
- kcpuset_isotherset(const - kcpuset_t * kcp, cpuid_t - cpu);

-

bool -
- kcpuset_iszero(const - kcpuset_t *kcp);

-

bool -
- kcpuset_intersecting_p(const - kcpuset_t *kcp1, const - kcpuset_t *kcp2);

-

bool -
- kcpuset_match(const - kcpuset_t *kcp1, const - kcpuset_t *kcp2);

-

void -
- kcpuset_intersect(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

void -
- kcpuset_merge(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

void -
- kcpuset_remove(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

cpuid_t -
- kcpuset_ffs(const - kcpuset_t *kcp);

-

cpuid_t -
- kcpuset_ffs_intersecting(const - kcpuset_t *kcp1, const - kcpuset_t *kcp2);

-

int -
- kcpuset_countset(const - kcpuset_t *kcp);

-

void -
- kcpuset_atomic_set(kcpuset_t - *kcp, cpuid_t - cpu);

-

void -
- kcpuset_atomic_clear(kcpuset_t - *kcp, cpuid_t - cpu);

-

void -
- kcpuset_atomicly_intersect(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

void -
- kcpuset_atomicly_merge(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

void -
- kcpuset_atomicly_remove(kcpuset_t - *kcp1, const kcpuset_t - *kcp2);

-

void -
- kcpuset_export_u32(const - kcpuset_t *kcp, uint32_t - *bitfield, size_t - len);

-
-
-

-

The machine-independent kcpuset subsystem - provides support for dynamic processor sets. Conceptually - kcpuset can be understood to be the kernel - equivalent of the user space cpuset(3) interface.

-
-
-

-
-
(retkcp, - zero)
-
The kcpuset_create() function creates a dynamic - CPU set and stores the result to retkcp. If the - boolean zero is not false, the allocated set is also - initialized to zero.
-
(kcp)
-
Destroys the CPU set kcp and schedules any linked - CPU sets for deferred destruction.
-
(dkcp, - skcp)
-
Copies the CPU set pointed by skcp to - dkcp.
-
(retkcp, - skcp)
-
Creates a dynamic CPU set and stores the result to - retkcp and copies the CPU set pointed by - skcp to the new CPU set.
-
(kcp)
-
Marks kcp as being in use by increasing the - reference count of the object. Note that initially - kcpuset_create() sets the reference count to - 1.
-
(kcp, - lst)
-
Decreases the internal reference count of kcp, and - on the last reference (when the count reaches zero), destroys - kcp. If lst is not - NULL, then instead of destroying, - kcp will be added to the lst - list for a deferred destruction.
-
(ucp, - kcp, len)
-
Copies the len bytes long user-space CPU set - ucp to the kernel CPU set - kcp.
-
(kcp, - ucp, len)
-
Copies the kernel CPU set kcp to the user-space CPU - set ucp.
-
(kcp)
-
Clears the set kcp.
-
(kcp)
-
Fills the whole set kcp with ones.
-
(kcp, - cpu)
-
Adds cpu to the set kcp.
-
(kcp, - cpu)
-
Removes cpu from the set - kcp.
-
(kcp, - cpu)
-
Returns true if cpu is part of the CPU set - kcp.
-
(kcp, - cpu)
-
Returns true if there any CPUs other than cpu in the - CPU set kcp.
-
(kcp)
-
Returns true if the set kcp is empty.
-
(kcp1, - kcp2)
-
Compares the sets kcp1 and - kcp2, returning true if these are identical.
-
(kcp1, - kcp2)
-
Removes any CPU not set in kcp2 from the set - kcp1.
-
(kcp1, - kcp2)
-
Merges the set kcp2 to the set - kcp1.
-
(kcp1, - kcp2)
-
Removes any CPU present in kcp2 from the set - kcp1.
-
(kcp)
-
Returns the lowest numbered cpu present in - kcp plus 1. If kcp is empty, a - value of 0 is returned. kcp
-
(kcp1, - kcp2)
-
Returns the lowest numbered cpu present in the - intersection of kcp1 and kcp2 - plus 1. If the intersection is empty, a value of 0 is returned.
-
(kcp)
-
Counts how many CPUs are in the set kcp.
-
(kcp, - cpu)
-
The kcpuset_atomic_set() function operates as - kcpuset_set(), but the operation is atomic; see - atomic_ops(3) for more details.
-
(kcp, - cpu)
-
Removes cpu from the CPU set - kcp atomically.
-
(kcp1, - kcp2)
-
The kcpuset_atomicly_intersect() function operates - as kcpuset_intersect(), but the operation is - performed using atomic operations; see atomic_ops(3) for - more details.
-
(kcp1, - kcp2)
-
The kcpuset_atomicly_merge() function operates as - kcpuset_merge(), but the operation is performed - using atomic operations; see atomic_ops(3) for more - details.
-
(kcp1, - kcp2)
-
The kcpuset_atomicly_remove() function operates as - kcpuset_remove(), but the operation is performed - using atomic operations; see atomic_ops(3) for more - details.
-
(kcp, - bitfield, len)
-
Exports the CPU set kcp into a format of 32-bit - integer array, specified by bitfield and length in - bytes by len. An integers is in the host byte-order - and represents a bit field. The first bit at index zero represents CPU - number 0, and so on.
-
-
-
-

-

The kcpuset subsystem is implemented - within sys/kern/subr_kcpuset.c.

-
-
-

-

cpuset(3)

-
-
-

-

The kcpuset subsystem first appeared in - NetBSD 6.0.

-
-
- - - - - -
July 17, 2013NetBSD 10.1
diff --git a/static/netbsd/man9/kmem.9 3.html b/static/netbsd/man9/kmem.9 3.html deleted file mode 100644 index 1acd9611..00000000 --- a/static/netbsd/man9/kmem.9 3.html +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - -
KMEM(9)Kernel Developer's ManualKMEM(9)
-
-
-

-

kmem — kernel - wired memory allocator

-
-
-

-

#include - <sys/kmem.h>

-

void * -
- kmem_alloc(size_t - size, km_flag_t - kmflags);

-

void * -
- kmem_zalloc(size_t - size, km_flag_t - kmflags);

-

void -
- kmem_free(void - *p, size_t - size);

-

void * -
- kmem_intr_alloc(size_t - size, km_flag_t - kmflags);

-

void * -
- kmem_intr_zalloc(size_t - size, km_flag_t - kmflags);

-

void -
- kmem_intr_free(void - *p, size_t - size);

-

char * -
- kmem_asprintf(const - char *fmt, - ...);

-

char * -
- kmem_strdupsize(const - char *str, size_t - *size, km_flag_t - kmflags);

-

char * -
- kmem_strdup(const - char *str, km_flag_t - kmflags);

-

char * -
- kmem_strndup(const - char *str, size_t - manxlen, km_flag_t - kmflags);

-

void -
- kmem_strfree(char - *str);

-

void * -
- kmem_tmpbuf_alloc(size_t - size, void - *stackbuf, size_t - stackbufsize, km_flag_t - kmflags);

-

void -
- kmem_tmpbuf_free(void - *p, size_t size, - void *stackbuf);

-

-
- options KMEM_SIZE

-
-
-

-

() - allocates kernel wired memory. It takes the following arguments.

-
-
size
-
Specify the size of allocation in bytes.
-
kmflags
-
Either of the following: -
-
-
If the allocation cannot be satisfied immediately, sleep until enough - memory is available. If KM_SLEEP is specified, - then the allocation cannot fail.
-
-
Don't sleep. Immediately return NULL if there - is not enough memory available. It should only be used when failure to - allocate will not have harmful, user-visible effects. -

-
Use of KM_NOSLEEP is strongly - discouraged as it can create transient, hard to debug failures that - occur when the system is under memory pressure.
-

In situations where it is not possible to sleep, for - example because locks are held by the caller, the code path should - be restructured to allow the allocation to be made in another - place.

-
-
-
-
-

The contents of allocated memory are uninitialized.

-

Unlike Solaris, kmem_alloc(0, flags) is illegal.

-

() - is the equivalent of kmem_alloc(), except that it - initializes the memory to zero.

-

() - functions as the well known - () - function, but allocates memory using kmem_alloc(). - This routine can sleep during allocation. The size of the allocated area is - the length of the returned character string, plus one (for the NUL - terminator). This must be taken into consideration when freeing the returned - area with kmem_free().

-

() - frees kernel wired memory allocated by kmem_alloc() - or kmem_zalloc() so that it can be used for other - purposes. It takes the following arguments.

-
-
p
-
The pointer to the memory being freed. It must be the one returned by - kmem_alloc() or - kmem_zalloc().
-
size
-
The size of the memory being freed, in bytes. It must be the same as the - size argument used for - kmem_alloc() or - kmem_zalloc() when the memory was allocated.
-
-

Freeing NULL is illegal.

-

(), - () - and - () - are the equivalents of the above kmem routines which can be called from the - interrupt context. These routines are for the special cases. Normally, - pool_cache(9) should be used for memory allocation from - interrupt context.

-

The - () - function is a utility function that can be used to copy the string in the - str argument to a new buffer allocated using - kmem_alloc() and optionally return the size of the - allocation (the length of the string plus the trailing - NUL) in the size argument if - that is not NULL.

-

The - () - function is a simplified version of - kmem_strdupsize() that does not return the size of - the allocation.

-

The - () - function is variation of kmem_strdup() that copies - at most maxlen characters from the string - str always NUL terminating the copied string.

-

The - () - function can be used to free a NUL terminated string - computing the length of the string using strlen(3) and - adding one for the NUL and then using - kmem_free().

-

The - () - function is a utility function for allocating memory for temporary use, - where allocation on the stack is desirable, but only up to a certain size. - If the requested size fits within the specified stack buffer, the stack - buffer is returned. Otherwise, memory is allocated with - kmem_alloc(). The - () - function compares the result of a previous call to - kmem_tmpbuf_alloc() and frees the memory using - kmem_free() if it is not the specified stack - buffer.

-
-
-

-

Making KM_SLEEP allocations while holding - mutexes or reader/writer locks is discouraged, as the caller can sleep for - an unbounded amount of time in order to satisfy the allocation. This can in - turn block other threads that wish to acquire locks held by the caller. It - should be noted that kmem_free() may also block.

-

For some locks this is permissible or even unavoidable. For - others, particularly locks that may be taken from soft interrupt context, it - is a serious problem. As a general rule it is better not to allow this type - of situation to develop. One way to circumvent the problem is to make - allocations speculative and part of a retryable sequence. For example:

-
-
  retry:
-        /* speculative unlocked check */
-        if (need to allocate) {
-                new_item = kmem_alloc(sizeof(*new_item), KM_SLEEP);
-        } else {
-                new_item = NULL;
-        }
-        mutex_enter(lock);
-        /* check while holding lock for true status */
-        if (need to allocate) {
-                if (new_item == NULL) {
-                        mutex_exit(lock);
-                        goto retry;
-                }
-                consume(new_item);
-                new_item = NULL;
-        }
-        mutex_exit(lock);
-        if (new_item != NULL) {
-                /* did not use it after all */
-                kmem_free(new_item, sizeof(*new_item));
-        }
-
-
-
-

-
-

-

Kernels compiled with the KMEM_SIZE option - ensure the size given in - () - matches the actual allocated size. On kmem_alloc(), - the kernel will allocate an additional contiguous kmem page of eight bytes - in the buffer, will register the allocated size in the first kmem page of - that buffer, and will return a pointer to the second kmem page in that same - buffer. When freeing, the kernel reads the first page, and compares the size - registered with the one given in kmem_free(). Any - mismatch triggers a panic.

-

KMEM_SIZE is enabled by default on - DIAGNOSTIC.

-
-
-
-

-

On success, kmem_alloc(), - kmem_asprintf(), - kmem_intr_alloc(), - kmem_intr_zalloc(), - kmem_strdupsize(), and - kmem_zalloc() return a pointer to allocated memory. - Otherwise, NULL is returned.

-
-
-

-

The kmem subsystem is implemented within - the file sys/kern/subr_kmem.c.

-
-
-

-

intro(9), memoryallocators(9), - percpu(9), pool_cache(9), - uvm_km(9)

-
-
-

-

The kmem_alloc(), - kmem_asprintf(), - kmem_free(), - kmem_strdupsize(), - kmem_strfree(), and - kmem_zalloc() functions cannot be used from - interrupt context, from a soft interrupt, or from a callout. Use - pool_cache(9) in these situations.

-
-
-

-

As the memory allocated by kmem_alloc() is - uninitialized, it can contain security-sensitive data left by its previous - user. It is the caller's responsibility not to expose it to the world.

-
-
- - - - - -
January 24, 2021NetBSD 10.1
diff --git a/static/netbsd/man9/localcount.9 3.html b/static/netbsd/man9/localcount.9 3.html deleted file mode 100644 index d71eac71..00000000 --- a/static/netbsd/man9/localcount.9 3.html +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - -
LOCALCOUNT(9)Kernel Developer's ManualLOCALCOUNT(9)
-
-
-

-

localcount, - localcount_init, - localcount_fini, - localcount_acquire, - localcount_release, - localcount_drain — - reference-count primitives

-
-
-

-

#include - <sys/localcount.h>

-

void -
- localcount_init(struct - localcount *lc);

-

void -
- localcount_fini(struct - localcount *lc);

-

void -
- localcount_acquire(struct - localcount *lc);

-

void -
- localcount_release(struct - localcount *lc, struct - kcondvar *cv, struct - kmutex *mtx);

-

void -
- localcount_drain(struct - localcount *lc, struct - kcondvar *cv, struct - kmutex *mtx);

-
-
-

-

Localcounts are used in the kernel to implement a medium-weight - reference counting mechanism. During normal operations, localcounts do not - need the interprocessor synchronization associated with - atomic_ops(3) atomic memory operations, and (unlike - psref(9)) localcount references - can be held across sleeps and can migrate between CPUs. Draining a - localcount requires more expensive interprocessor - synchronization than atomic_ops(3) (similar to - psref(9)). And localcount - references require eight bytes of memory per object per-CPU, significantly - more than atomic_ops(3) and almost always more than - psref(9).

-

As a rough heuristic, localcount should be - used for classes of objects of which there are perhaps a few dozen instances - (such as autoconf(9) devices) but not thousands of - instances (such as network flows) and on which there may be a mixture of - long-term I/O waits, such as xyzread for a device xyz(4), and short-term - fast operations, such as - xyzioctl(IOC_READ_A_CPU_REG).

-
-
-

-
-
(lc)
-
Dynamically initialize localcount lc for use. -

No other operations can be performed on a localcount until it - has been initialized.

-
-
(lc)
-
Release resources used by localcount lc. The caller - must have already called localcount_drain(). The - localcount may not be used after localcount_fini() - has been called until it has been re-initialized by - localcount_init().
-
localcount_acquire(lc)
-
Acquire a reference to the localcount lc. -

The caller must ensure by some other - mechanism that the localcount will not be destroyed before the call to - (); - typically this will be via a pserialize(9) read - section.

-
-
(lc, - cv, mtx)
-
Release a reference to the localcount lc. If the - localcount is currently being drained, the mutex mtx - will be used to synchronize updates to the global reference count (i.e., - the total across all CPUs). If the reference count goes to zero, - localcount_release() will broadcast availability - of the condvar cv.
-
localcount_drain(lc, - cv, mtx)
-
Wait for all references to the localcount lc to be - released. The caller must hold the mutex mtx; the - mutex will be released during inter-CPU cross-calls (see - xcall(9)) and while waiting on the condvar - cv. The same cv and - mtx must be used with - localcount_release(). -

The caller must guarantee that no - new references can be acquired with - () - before calling localcount_drain(). For example, - any object that may be found in a list and acquired must be removed from - the list before calling localcount_drain(); - removal from the list would typically be protected by calling - pserialize_perform(9) to wait for any - pserialize(9) readers to complete.

-

Once the localcount object - lc is passed to - (), - it must be passed to localcount_fini() before - any other re-use.

-
-
-
-
-

-

The core of the localcount implementation is located in - sys/kern/subr_localcount.c.

-

The header file sys/sys/localcount.h - describes the public interface, and interfaces that machine-dependent code - must provide to support localcounts.

-
-
-

-

atomic_ops(3), condvar(9), - mutex(9), psref(9)

-
-
-

-

The localcount primitives first appeared in - NetBSD 8.0.

-
-
-

-

localcount was designed by - Taylor R. Campbell, who also provided a draft - implementation. The implementation was completed, tested, and integrated by - Paul Goyette.

-
-
-

-

The localcount facility does not provide - any way to examine the reference count without actually waiting for the - count to reach zero.

-

Waiting for a localcount reference count - to drain (reach zero) is a one-shot operation. Once the - localcount has been drained, no further operations - are allowed until the localcount has been - re-initialized.

-
-
- - - - - -
February 25, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/lock.9 3.html b/static/netbsd/man9/lock.9 3.html deleted file mode 100644 index 304547b0..00000000 --- a/static/netbsd/man9/lock.9 3.html +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - -
LOCK(9)Kernel Developer's ManualLOCK(9)
-
-
-

-

lock, - simple_lock_init, - simple_lock, - simple_lock_try, - simple_unlock, - simple_lock_freecheck, - simple_lock_dump, lockinit, - lockmgr, lockstatus, - lockmgr_printinfo, - spinlockinit, spinlockmgr - — kernel lock functions

-
-
-

-

These interfaces have been obsoleted and removed from the - system.

-

Please see the condvar(9), - mutex(9), and rwlock(9) manual pages for - information on kernel synchronisation primitives.

-
-
-

-

condvar(9), mutex(9), - rwlock(9)

-
-
-

-

The kernel locking API first appeared in - 4.4BSD-lite2, and was replaced in - NetBSD 5.0.

-
-
- - - - - -
January 30, 2008NetBSD 10.1
diff --git a/static/netbsd/man9/locking.9 3.html b/static/netbsd/man9/locking.9 3.html deleted file mode 100644 index 9704a7c1..00000000 --- a/static/netbsd/man9/locking.9 3.html +++ /dev/null @@ -1,333 +0,0 @@ - - - - - - -
LOCKING(9)Kernel Developer's ManualLOCKING(9)
-
-
-

-

locking — - introduction to kernel synchronization and interrupt - control

-
-
-

-

The NetBSD kernel provides several - synchronization and interrupt control primitives. This man page aims to give - an overview of these interfaces and their proper application. Also included - are basic kernel thread control primitives and a rough overview of the - NetBSD kernel design.

-
-
-

-

The aim of synchronization, threads and interrupt control in the - kernel is:

-
    -
  • To control concurrent access to shared resources (critical sections).
    • -
  • Spawn tasks from an interrupt in the thread context.
    • -
  • Mask interrupts from threads.
    • -
  • Scale on multiple CPU system.
    • -
-

There are three types of contexts in the - NetBSD kernel:

-
    -
  • - running processes (represented by - struct proc) and light-weight processes - (represented by struct lwp, also known as kernel - threads). Code in this context can sleep, block resources and own - address-space.
    • -
  • - limited by thread context. Code in this - context must be processed shortly. These interrupts don't own any address - space context. Software interrupts are a way of deferring hardware - interrupts to do more expensive processing at a lower interrupt - priority.
    • -
  • - Code in this context must be processed as quickly as - possible. It is forbidden for a piece of code to sleep or access - long-awaited resources here.
    • -
-

The main differences between processes and kernel threads are:

-
    -
  • A single process can own multiple kernel threads (LWPs).
    • -
  • A process owns address space context to map userland address space.
    • -
  • Processes are designed for userland executables and kernel threads for - in-kernel tasks. The only process running in the kernel-space is - proc0 (called swapper).
    • -
-
-
-

-
-

-

The atomic_ops family of functions provide - atomic memory operations. There are 7 classes of atomic memory operations - available: addition, logical “and”, compare-and-swap, - decrement, increment, logical “or”, swap.

-

See atomic_ops(3).

-
-
-

-

Condition variables (CVs) are used in the kernel to synchronize - access to resources that are limited (for example, memory) and to wait for - pending I/O operations to complete.

-

See condvar(9).

-
-
-

-

The membar_ops family of functions provide - memory access barrier operations necessary for synchronization in - multiprocessor execution environments that have relaxed load and store - order.

-

See membar_ops(3).

-
-
-

-

The memory barriers can be used to control the order in which - memory accesses occur, and thus the order in which those accesses become - visible to other processors. They can be used to implement - “lockless” access to data structures where the necessary - barrier conditions are well understood.

-
-
-

-

Thread-base adaptive mutexes. These are lightweight, exclusive - locks that use threads as the focus of synchronization activity. Adaptive - mutexes typically behave like spinlocks, but under specific conditions an - attempt to acquire an already held adaptive mutex may cause the acquiring - thread to sleep. Sleep activity occurs rarely. Busy-waiting is typically - more efficient because mutex hold times are most often short. In contrast to - pure spinlocks, a thread holding an adaptive mutex may be pre-empted in the - kernel, which can allow for reduced latency where soft real-time application - are in use on the system.

-

See mutex(9).

-
-
-

-

Restartable atomic sequences are user code only sequences which - are guaranteed to execute without preemption. This property is assured by - checking the set of restartable atomic sequences registered for a process - during cpu_switchto(9). If a process is found to have been - preempted during a restartable sequence, then its execution is rolled-back - to the start of the sequence by resetting its program counter which is saved - in its process control block (PCB).

-

See ras(9).

-
-
-

-

Reader / writer locks (RW locks) are used in the kernel to - synchronize access to an object among LWPs (lightweight processes) and soft - interrupt handlers. In addition to the capabilities provided by mutexes, RW - locks distinguish between read (shared) and write (exclusive) access.

-

See rwlock(9).

-
-
-

-

These functions raise and lower the interrupt priority level. They - are used by kernel code to block interrupts in critical sections, in order - to protect data structures.

-

See spl(9).

-
-
-

-

The software interrupt framework is designed to provide a generic - software interrupt mechanism which can be used any time a low-priority - callback is required. It allows dynamic registration of software interrupts - for loadable drivers, protocol stacks, software interrupt prioritization, - software interrupt fair queuing and allows machine-dependent optimizations - to reduce cost.

-

See softint(9).

-
-
-

-

The splraiseipl function raises the system - priority level to the level specified by icookie, - which should be a value returned by makeiplcookie(9). In - general, device drivers should not make use of this interface. To ensure - correct synchronization, device drivers should use the - condvar(9), mutex(9), and - rwlock(9) interfaces.

-

See splraiseipl(9).

-
-
-

-

Passive serialization is a reader / writer synchronization - mechanism designed for lock-less read operations. The read operations may - happen from software interrupt at IPL_SOFTCLOCK.

-

See pserialize(9).

-
-
-

-

Passive references allow CPUs to cheaply acquire and release - passive references to a resource, which guarantee the resource will not be - destroyed until the reference is released. Acquiring and releasing passive - references requires no interprocessor synchronization, except when the - resource is pending destruction.

-

See psref(9).

-
-
-

-

Localcounts are used in the kernel to implement a medium-weight - reference counting mechanism. During normal operations, localcounts do not - need the interprocessor synchronization associated with - atomic_ops(3) atomic memory operations, and (unlike - psref(9)) localcount references can be held across sleeps - and can migrate between CPUs. Draining a localcount requires more expensive - interprocessor synchronization than atomic_ops(3) (similar - to psref(9)). And localcount references require eight - bytes of memory per object per-CPU, significantly more than - atomic_ops(3) and almost always more than - psref(9).

-

See localcount(9).

-
-
-

-

The workqueue utility routines are provided to defer work which is - needed to be processed in a thread context.

-

See workqueue(9).

-
-
-
-

-

The following table describes in which contexts the use of the - NetBSD kernel interfaces are valid. Synchronization - primitives which are available in more than one context can be used to - protect shared resources between the contexts they overlap.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
atomic_ops(3)yesyesyes
condvar(9)yespartlyno
membar_ops(3)yesyesyes
mutex(9)yesdependsdepends
rwlock(9)yesyesno
softint(9)yesyesyes
spl(9)yesnono
splraiseipl(9)yesnono
pserialize(9)yesyesno
psref(9)yesyesno
localcount(9)yesyesno
workqueue(9)yesyesyes
-
-
-

-

atomic_ops(3), membar_ops(3), - condvar(9), mutex(9), - ras(9), rwlock(9), - softint(9), spl(9), - splraiseipl(9), workqueue(9)

-
-
-

-

Initial SMP support was introduced in NetBSD - 2.0 and was designed with a giant kernel lock. Through - NetBSD 4.0, the kernel used spinlocks and a per-CPU - interrupt priority level (the spl(9) system). These - mechanisms did not lend themselves well to a multiprocessor environment - supporting kernel preemption. The use of thread based (lock) synchronization - was limited and the available synchronization primitive (lockmgr) was - inefficient and slow to execute. NetBSD 5.0 - introduced massive performance improvements on multicore hardware by Andrew - Doran. This work was sponsored by The NetBSD - Foundation.

-

A locking manual first appeared in - NetBSD 8.0 and was inspired by the corresponding - locking manuals in FreeBSD - and DragonFly.

-
-
-

-

Kamil Rytarowski - <kamil@NetBSD.org>.

-
-
- - - - - -
August 23, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/ltsleep.9 3.html b/static/netbsd/man9/ltsleep.9 3.html deleted file mode 100644 index 852103ea..00000000 --- a/static/netbsd/man9/ltsleep.9 3.html +++ /dev/null @@ -1,203 +0,0 @@ - - - - - - -
LTSLEEP(9)Kernel Developer's ManualLTSLEEP(9)
-
-
-

-

ltsleep, mtsleep, - tsleep, wakeup — - process context sleep and wakeup

-
-
-

-

#include - <sys/proc.h>

-

int -
- mtsleep(wchan_t - ident, pri_t - priority, const char - *wmesg, int timo, - kmutex_t *mtx);

-

int -
- tsleep(wchan_t - ident, pri_t - priority, const char - *wmesg, int - timo);

-

void -
- wakeup(wchan_t - ident);

-
-
-

-

The interfaces described in this manual page are - obsolete and will be removed from a future version of the - system.

-

The - () -

-

condvar(9), mutex(9), - and rwlock(9) -

-

These functions implement voluntary context switching. - () and - mtsleep() are used throughout the kernel whenever - processing in the current context can not continue for any of the following - reasons:

-
    -
  • The current process needs to await the results of a pending I/O - operation.
    • -
  • The current process needs resources (e.g., memory) which are temporarily - unavailable.
    • -
-

The function - () is - used to notify sleeping processes of possible changes to the condition that - caused them to go to sleep. Typically, an awakened process will — - after it has acquired a context again — retry the action that blocked - its operation to see if the “blocking” condition has - cleared.

-

The - () - and mtsleep() functions take the following - arguments:

-
-
ident
-
An identifier of the “wait channel” representing the - resource for which the current process needs to wait. This typically is - the virtual address of some kernel data-structure related to the resource - for which the process is contending. The same identifier must be used in a - call to wakeup() to get the process going again. - ident should not be - NULL.
-
priority
-
The process priority to be used when the process is awakened and put on - the queue of runnable processes. This mechanism is used to optimize - “throughput” of processes executing in kernel mode. If the - flag PCATCH is OR'ed into - priority the process checks for posted signals - before and after sleeping.
-
wmesg
-
A pointer to a character string indicating the reason a process is - sleeping. The kernel does not use the string, but makes it available - (through the process structure field p_wmesg) for - user level utilities such as ps(1).
-
timo
-
If non-zero, the process will sleep for at most - timo/hz seconds. If this amount of time elapses - and no wakeup(ident) has - occurred, and no signal (if PCATCH - was set) was posted, - tsleep() will return - EWOULDBLOCK.
-
-

The - () - function takes an additional argument and flag:

-
-
mtx
-
A mutex(9) representing the lock protecting the - data-structures. On entry mtsleep() will release - the lock and re-acquire the lock on return.
-
priority
-
If the flag PNORELOCK is OR'ed into - priority then mtsleep() will - not re-acquire the lock.
-
-

The - () - function will mark all processes which are currently sleeping on the - identifier ident as runnable. Eventually, each of the - processes will resume execution in the kernel context, causing a return from - tsleep() or mtsleep(). Note - that processes returning from sleep should always re-evaluate the conditions - that blocked them, since a call to wakeup() merely - signals a - - change to the blocking conditions.

-
-
-

-

tsleep() and - mtsleep() return 0 if they return as a result of a - wakeup(). If a tsleep() and - mtsleep() return as a result of a signal, the return - value is ERESTART if the signal has the - SA_RESTART property (see - sigaction(2)), and EINTR - otherwise. If tsleep() and - mtsleep() return because of a timeout, the return - value is EWOULDBLOCK.

-
-
-

-

Note the conversion from tsleep/wakeup into - condvar(9) should not be done mechanically i.e. - “blindly”. Code logic should be understood before changing, - and it may also need to be revisited for the change. Please also read the - condvar(9) man page.

-

The - () - and mtsleep(), and wakeup() - pairs should generally be replaced by cv_wait(9) / - cv_wait_sig(9) / cv_timedwait(9) / - cv_timedwait_sig(9) and cv_signal(9) / - cv_broadcast(9) pairs. The - () - variant to use can be determined from looking at the corresponding - tsleep() usage.

-

There are two arguments of interest: timo - and priority. The priority value - may have OR'ed the flag PCATCH.

-

The PCATCH flag means that the blocking - thread should be awoken on signal, and the sleep call should be replaced - with cv_wait_sig(9).

-

The timo value, if it is not zero, indicates - how long to sleep, and the sleep call should be replaced with - cv_timedwait(9).

-

If both the PCATCH flag and a non-zero - timo value are specified, then - cv_timedwait_sig(9) should be used.

-

A mutex(9) (interlock) must be held - across - () - and - () - calls, in order to protect state. Most old code will require the addition of - locking, whereas some will require amending to remove - PNORELOCK.

-
-
-

-

sigaction(2), condvar(9), - hz(9), kpause(9), - mutex(9), rwlock(9)

-
-
-

-

The sleep/wakeup process synchronization mechanism is very old. It - appeared in a very early version of Unix. tsleep() - appeared in 4.4BSD. - ltsleep() appeared in NetBSD - 1.5.

-
-
- - - - - -
May 7, 2024NetBSD 10.1
diff --git a/static/netbsd/man9/man9.x86/rdmsr.9 3.html b/static/netbsd/man9/man9.x86/rdmsr.9 3.html deleted file mode 100644 index e964d37b..00000000 --- a/static/netbsd/man9/man9.x86/rdmsr.9 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
RDMSR(9)Kernel Developer's Manual (x86)RDMSR(9)
-
-
-

-

msr, rdmsr, - rdmsr_safe, wrmsr — - functions for x86 MSRs

-
-
-

-

#include - <x86/cpufunc.h>

-

uint64_t -
- rdmsr(u_int - msr);

-

int -
- rdmsr_safe(u_int - msr, uint64_t - *valp);

-

void -
- wrmsr(u_int - msr, uint64_t - val);

-
-
-

-

The RDMSR instruction reads from a x86 - model-specific register (MSR). Conversely, the - WRMSR instruction is used to write to a - MSR. In NetBSD the - (), - rdmsr_safe(), and - () - functions are used to access MSRs. The header - <x86/specialreg.h> includes - definitions for some of the commonly used MSRs, that is, control registers - that are present in some x86 processor models but unavailable in others.

-
-
-

-
-
rdmsr(msr)
-
Returns the value read from msr.
-
rdmsr_safe(msr, - valp)
-
The rdmsr_safe() function is a safer variant of - rdmsr(). Upon successful completion, the function - returns zero and the value read from the register - msr is returned in valp. If a - fault occurs while accessing msr, - rdmsr_safe() returns - EFAULT.
-
wrmsr(msr, - val)
-
The wrmsr() function writes - val to the register msr.
-
-

Note that even though - () - provides support for reading MSRs in a safe manner, - it is still a good practice to always verify that the given model-specific - register is present by using the CPUID instruction, - available in NetBSD via - ().

-
-
-

-

rdtsc(9), - x86/x86_msr_xcall(9)

-
-
- - - - - -
February 17, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/man9.x86/tsc.9 3.html b/static/netbsd/man9/man9.x86/tsc.9 3.html deleted file mode 100644 index cf839df4..00000000 --- a/static/netbsd/man9/man9.x86/tsc.9 3.html +++ /dev/null @@ -1,102 +0,0 @@ - - - - - - -
TSC(9)Kernel Developer's Manual (x86)TSC(9)
-
-
-

-

tsc — Time Stamp - Counter

-
-
-

-

#include - <x86/x86/tsc.h>

-

uint64_t -
- rdtsc(void);

-

void -
- tsc_tc_init(void);

-

void -
- tsc_sync_ap(struct - cpu_info *ci);

-

void -
- tsc_sync_bp(struct - cpu_info *ci);

-

void -
- tsc_sync_drift(int64_t - drift);

-
-
-

-

The time stamp counter (TSC) is a hardware counter found in all - contemporary x86 processors. The counter is implemented as a 64-bit - model-specific register (MSR) that is incremented at every clock cycle. The - RDTSC (“read time stamp counter”) register has been present - since the original Pentium.

-

Already because of the access method, TSC provides a low-overhead - and high-resolution way to obtain CPU timing information. This traditional - premise was violated when such factors as system sleep states, CPU - “hotplugging”, “hibernation”, and CPU frequency - scaling were introduced to the x86 lineage. This was however mainly a short - abruption: in many new x86 CPUs the time stamp counter is again invariant - with respect to the stability of the clock frequency. Care should be however - taken in implementations that rely on this assumption.

-
-
-

-
-
()
-
The rdtsc() function returns the value read from - RDTSC.
-
()
-
The tsc_tc_init() function initializes the TSC as - a timecounter(9). The function is called early in the - boot process when the processors attach.
-
tsc_sync_bp(ci)
-
The tsc_sync_bp() function synchronizes the - counter for the boot processor (BP). The supplied ci - must refer to the BP itself. The tsc interface - takes internally care of such issues as out-of-order execution, where - instructions are not necessarily performed in the order of execution, - possibly causing a misleading cycle count.
-
tsc_sync_ap(ci)
-
The tsc_sync_ap() function synchronize the counter - for the application processor ci. Interrupts must be - off at machine-level when the function is called. -

It is necessary to call both - () - and - () - during the boot, but additional synchronization may be required also - during runtime. As an example, the TSC needs to be synchronized for all - processors when the system resumes from an acpi(4) - sleep state.

-
-
(drift)
-
Finally, the tsc_sync_drift() function records - drift, measured in clock cycles. This is called when - the APs attach.
-
-
-
-

-

gettimeofday(2), hpet(4), - hz(9), timecounter(9), - x86/rdmsr(9)

-
-
- - - - - -
February 17, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/memcmp.9 3.html b/static/netbsd/man9/memcmp.9 3.html deleted file mode 100644 index 0d809b4b..00000000 --- a/static/netbsd/man9/memcmp.9 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
MEMCMP(9)Kernel Developer's ManualMEMCMP(9)
-
-
-

-

memcmp — compare - byte string

-
-
-

-

#include - <sys/systm.h>

-

int -
- memcmp(const - void *b1, const void - *b2, size_t - len);

-
-
-

-

The - () - function compares byte string b1 against byte string - b2. Both strings are assumed to be - len bytes long.

-
-
-

-

The memcmp() function returns zero if the - two strings are identical, otherwise returns the difference between the - first two differing bytes (treated as unsigned char values, so that - ‘\200’ is greater than - ‘\0’, for example). Zero-length - strings are always identical.

-
-
-

-

The memcmp() function conforms to - ANSI X3.159-1989 - (“ANSI C89”).

-
-
- - - - - -
July 7, 2001NetBSD 10.1
diff --git a/static/netbsd/man9/memset.9 3.html b/static/netbsd/man9/memset.9 3.html deleted file mode 100644 index 43b06ae0..00000000 --- a/static/netbsd/man9/memset.9 3.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - -
MEMSET(9)Kernel Developer's ManualMEMSET(9)
-
-
-

-

memset — write a - byte to byte string

-
-
-

-

#include - <sys/systm.h>

-

void * -
- memset(void - *b, int c, - size_t len);

-
-
-

-

The - () - function writes len bytes of value - c (converted to an unsigned char) to the string - b.

-
-
-

-

The memset() function returns the original - value of b.

-
-
-

-

The memset() function conforms to - ANSI X3.159-1989 - (“ANSI C89”).

-
-
- - - - - -
July 7, 2001NetBSD 10.1
diff --git a/static/netbsd/man9/microseq.9 3.html b/static/netbsd/man9/microseq.9 3.html deleted file mode 100644 index 88fba6fd..00000000 --- a/static/netbsd/man9/microseq.9 3.html +++ /dev/null @@ -1,531 +0,0 @@ - - - - - - -
MICROSEQ(9)Kernel Developer's ManualMICROSEQ(9)
-
-
-

-

microseq — ppbus - microseqencer developer's guide

-
-
-

-

#include - <sys/types.h> -
- #include - <dev/ppbus/ppbus_conf.h> -
- #include - <dev/ppbus/ppbus_msq.h>

-
-
-

-

See ppbus(4) for ppbus - description and general info about the microsequencer.

-

The purpose of this document is to encourage developers to use the - microsequencer mechanism in order to have:

-
    -
  1. a uniform programming model
    2. -
  2. efficient code
    3. -
-

Before using microsequences, you are encouraged to look at the - atppc(4) microsequencer implementation and an example of - how using it in vpo(4).

-
-

-
-
-

-

The parallel port model chosen for ppbus(4) is - the PC parallel port model. Thus, any register described later has the same - semantic than its counterpart in a PC parallel port. For more info about - ISA/ECP programming, get the Microsoft standard referenced “Extended - Capabilities Port Protocol and ISA interface Standard”. Registers - described later are standard parallel port registers.

-

Mask macros are defined in the standard ppbus(4) - include files for each valid bit of parallel port registers.

-
-
-

-

In compatible or nibble mode, writing to this register will drive - data to the parallel port data lines. In any other mode, drivers may be - tri-stated by setting the direction bit (PCD) in the control register. Reads - to this register return the value on the data lines.

-
-
-

-

This read-only register reflects the inputs on the parallel port - interface.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
7nBUSYinverted version of parallel port Busy signal
6nACKversion of parallel port nAck signal
5PERRORversion of parallel port PERROR signal
4SELECTversion of parallel port Select signal
3nFAULTversion of parallel port nFault signal
-

Others are reserved and return undefined result when read.

-
-
-

-

This register directly controls several output signals as well as - enabling some functions.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
5PCDdirection bit in extended modes
4IRQENABLE1 enables an interrupt on the rising edge of nAck
3SELECTINinverted and driven as parallel port nSelectin signal
2nINITdriven as parallel port nInit signal
1AUTOFEEDinverted and driven as parallel port nAutoFd signal
0STROBEinverted and driven as parallel port nStrobe signal
-
-
-
-

-
-

-

- are either parallel port accesses, program iterations, submicrosequence or C - calls. The parallel port must be considered as the logical model described - in ppbus(4).

-

Available microinstructions are:

-
-
#define MS_OP_GET       0	/* get <ptr>, <len>			*/
-#define MS_OP_PUT       1	/* put <ptr>, <len>			*/
-#define MS_OP_RFETCH	2	/* rfetch <reg>, <mask>, <ptr>		*/
-#define MS_OP_RSET	3	/* rset <reg>, <mask>, <mask>		*/
-#define MS_OP_RASSERT	4	/* rassert <reg>, <mask>		*/
-#define MS_OP_DELAY     5	/* delay <val>				*/
-#define MS_OP_SET       6	/* set <val>				*/
-#define MS_OP_DBRA      7	/* dbra <offset>			*/
-#define MS_OP_BRSET     8	/* brset <mask>, <offset>		*/
-#define MS_OP_BRCLEAR   9	/* brclear <mask>, <offset>		*/
-#define MS_OP_RET       10	/* ret <retcode>			*/
-#define MS_OP_C_CALL	11	/* c_call <function>, <parameter>	*/
-#define MS_OP_PTR	12	/* ptr <pointer>			*/
-#define MS_OP_ADELAY	13	/* adelay <val>				*/
-#define MS_OP_BRSTAT	14	/* brstat <mask>, <mask>, <offset>	*/
-#define MS_OP_SUBRET	15	/* subret <code>			*/
-#define MS_OP_CALL	16	/* call <microsequence>			*/
-#define MS_OP_RASSERT_P	17	/* rassert_p <iter>, <reg>		*/
-#define MS_OP_RFETCH_P	18	/* rfetch_p <iter>, <reg>, <mask>	*/
-#define MS_OP_TRIG	19	/* trigger <reg>, <len>, <array>	*/
-
-
-
-

-

The - of microinstructions is:

-
    -
  • the - - which points to the next microinstruction to execute either in the main - microsequence or in a subcall
    • -
  • the current value of - which points to - the next char to send/receive
    • -
  • the current value of the internal -
    • -
-

This data is modified by some of the microinstructions, not - all.

-
-
-

-

are microinstructions used to do either predefined standard - IEEE1284-1994 transfers or programmed non-standard I/O.

-
-
-

-

is used to retrieve the current value of a parallel port register, - apply a mask and save it in a buffer.

-

Parameters:

-
    -
  1. register
    2. -
  2. character mask
    3. -
  3. pointer to the buffer
    4. -
-

Predefined macro: MS_RFETCH(reg,mask,ptr)

-
-
-

-

is used to assert/clear some bits of a particular parallel port - register, two masks are applied.

-

Parameters:

-
    -
  1. register
    2. -
  2. mask of bits to assert
    3. -
  3. mask of bits to clear
    4. -
-

Predefined macro: MS_RSET(reg,assert,clear)

-
-
-

-

is used to assert all bits of a particular parallel port - register.

-

Parameters:

-
    -
  1. register
    2. -
  2. byte to assert
    3. -
-

Predefined macro: MS_RASSERT(reg,byte)

-
-
-

-

is used to delay the execution of the microsequence.

-

Parameter:

-
    -
  1. delay in microseconds
    2. -
-

Predefined macro: MS_DELAY(delay)

-
-
-

-

is used to set the value of the internal branch register.

-

Parameter:

-
    -
  1. integer value
    2. -
-

Predefined macro: MS_SET(accum)

-
-
-

-

is used to branch if internal branch register decremented by one - result value is positive.

-

Parameter:

-
    -
  1. integer offset in the current executed (sub)microsequence. Offset is added - to the index of the next microinstruction to execute.
    2. -
-

Predefined macro: MS_DBRA(offset)

-
-
-

-

is used to branch if some of the status register bits of the - parallel port are set.

-

Parameter:

-
    -
  1. bits of the status register
    2. -
  2. integer offset in the current executed (sub)microsequence. Offset is added - to the index of the next microinstruction to execute.
    3. -
-

Predefined macro: MS_BRSET(mask,offset)

-
-
-

-

is used to branch if some of the status register bits of the - parallel port are cleared.

-

Parameter:

-
    -
  1. bits of the status register
    2. -
  2. integer offset in the current executed (sub)microsequence. Offset is added - to the index of the next microinstruction to execute.
    3. -
-

Predefined macro: MS_BRCLEAR(mask,offset)

-
-
-

-

is used to return from a microsequence. This instruction is - mandatory. This is the only way for the microsequencer to detect the end of - the microsequence. The return code is returned in the integer pointed by the - (int *) parameter of the ppb_MS_microseq().

-

Parameter:

-
    -
  1. integer return code
    2. -
-

Predefined macro: MS_RET(code)

-
-
-

-

is used to call C functions from microsequence execution. This may - be useful when a non-standard I/O is performed to retrieve a data character - from the parallel port.

-

Parameter:

-
    -
  1. the C function to call
    2. -
  2. the parameter to pass to the function call
    3. -
-

The C function shall be declared as a int(*)(void - *p, char *ptr). The ptr parameter is the current position in the - buffer currently scanned.

-

Predefined macro: MS_C_CALL(func,param)

-
-
-

-

is used to initialize the internal pointer to the currently - scanned buffer. This pointer is passed to any C call (see above).

-

Parameter:

-
    -
  1. pointer to the buffer that shall be accessed by - () - microsequence calls. Note that this pointer is automatically incremented - during xxx_P() calls.
    2. -
-

Predefined macro: MS_PTR(ptr)

-
-
-

-

is used to make a cv_timedwait(9) during - microsequence execution.

-

Parameter:

-
    -
  1. delay in ms
    2. -
-

Predefined macro: MS_ADELAY(delay)

-
-
-

-

is used to branch on status register state condition.

-

Parameter:

-
    -
  1. mask of asserted bits. Bits that shall be asserted in the status register - are set in the mask
    2. -
  2. mask of cleared bits. Bits that shall be cleared in the status register - are set in the mask
    3. -
  3. integer offset in the current executed (sub)microsequence. Offset is added - to the index of the next microinstruction to execute.
    4. -
-

Predefined macro: MS_BRSTAT(asserted_bits,clear_bits,offset)

-
-
-

-

is used to return from the submicrosequence call. This action is - mandatory before a RET call. Some microinstructions (PUT, GET) may not be - callable within a submicrosequence.

-

No parameter.

-

Predefined macro: MS_SUBRET()

-
-
-

-

is used to call a submicrosequence. A submicrosequence is a - microsequence with a SUBRET call. Parameter:

-
    -
  1. the submicrosequence to execute
    2. -
-

Predefined macro: MS_CALL(microseq)

-
-
-

-

is used to assert a register with data currently pointed by the - internal PTR pointer. Parameter:

-
    -
  1. amount of data to write to the register
    2. -
  2. register
    3. -
-

Predefined macro: MS_RASSERT_P(iter,reg)

-
-
-

-

is used to fetch data from a register. Data is stored in the - buffer currently pointed by the internal PTR pointer. Parameter:

-
    -
  1. amount of data to read from the register
    2. -
  2. register
    3. -
  3. mask applied to fetched data
    4. -
-

Predefined macro: MS_RFETCH_P(iter,reg,mask)

-
-
-

-

is used to trigger the parallel port. This microinstruction is - intended to provide a very efficient control of the parallel port. - Triggering a register is writing data, wait a while, write data, wait a - while... This allows to write magic sequences to the port. Parameter:

-
    -
  1. amount of data to read from the register
    2. -
  2. register
    3. -
  3. size of the array
    4. -
  4. array of unsigned chars. Each couple of u_chars define the data to write - to the register and the delay in us to wait. The delay is limited to 255 - us to simplify and reduce the size of the array.
    5. -
-

Predefined macro: MS_TRIG(reg,len,array)

-
-
-
-

-
-

-
-
union ppb_insarg {
-     int     i;
-     char    c;
-     void    *p;
-     int     (* f)(void *, char *);
-};
-
-struct ppb_microseq {
-     int                     opcode;         /* microins. opcode */
-     union ppb_insarg        arg[PPB_MS_MAXARGS];    /* arguments */
-};
-
-
-
-

-

To instantiate a microsequence, just declare an array of - ppb_microseq structures and initialize it as needed. You may either use - predefined macros or code directly your microinstructions according to the - ppb_microseq definition. For example,

-
-
     struct ppb_microseq select_microseq[] = {
-
-	     /* parameter list
-	      */
-	     #define SELECT_TARGET    MS_PARAM(0, 1, MS_TYP_INT)
-	     #define SELECT_INITIATOR MS_PARAM(3, 1, MS_TYP_INT)
-
-	     /* send the select command to the drive */
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS(H_nAUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_CASS( H_AUTO | H_nSELIN |  H_INIT | H_STROBE),
-	     MS_DASS(MS_UNKNOWN),
-	     MS_CASS( H_AUTO | H_nSELIN | H_nINIT | H_STROBE),
-
-	     /* now, wait until the drive is ready */
-	     MS_SET(VP0_SELTMO),
-/* loop: */     MS_BRSET(H_ACK, 2 /* ready */),
-	     MS_DBRA(-2 /* loop */),
-/* error: */    MS_RET(1),
-/* ready: */    MS_RET(0)
-     };
-
-

Here, some parameters are undefined and must - be filled before executing the microsequence. In order to initialize each - microsequence, one should use the - () - function like this:

-
-
ppb_MS_init_msq(select_microseq, 2,
-		SELECT_TARGET, 1 << target,
-		SELECT_INITIATOR, 1 << initiator);
-
-

and then execute the microsequence.

-
-
-

-

The microsequencer is executed either at ppbus or adapter level - (see ppbus(4) for info about ppbus system layers). Most of - the microsequencer is executed at atppc(4) level to avoid - ppbus(4) to adapter function call overhead. But some - actions like deciding whereas the transfer is IEEE1284-1994 compliant are - executed at ppbus(4) layer.

-
-
-
-

-

atppc(4), ppbus(4), - vpo(4)

-
-
-

-

The microseq manual page first appeared in - FreeBSD 3.0.

-
-
-

-

This manual page is based on the FreeBSD - microseq manual page and was update for the - NetBSD port by Gary - Thorpe.

-
-
-

-

Only one level of submicrosequences is allowed.

-

When triggering the port, maximum delay allowed is 255 us.

-
-
- - - - - -
December 29, 2003NetBSD 10.1
diff --git a/static/netbsd/man9/microtime.9 3.html b/static/netbsd/man9/microtime.9 3.html deleted file mode 100644 index 0966aa13..00000000 --- a/static/netbsd/man9/microtime.9 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
MICROTIME(9)Kernel Developer's ManualMICROTIME(9)
-
-
-

-

bintime, - getbintime, microtime, - getmicrotime, nanotime, - getnanotime — get the - current time

-
-
-

-

#include - <sys/time.h>

-

void -
- bintime(struct bintime *bt);

-

void -
- getbintime(struct bintime - *bt);

-

void -
- microtime(struct timeval - *tv);

-

void -
- getmicrotime(struct timeval - *tv);

-

void -
- nanotime(struct timespec - *tsp);

-

void -
- getnanotime(struct timespec - *tsp);

-
-
-

-

The - () - and getbintime() functions store the system time as - a struct bintime at the addresses specified by - bt. The microtime() and - getmicrotime() functions perform the same utility, - but record the time as a struct timeval instead. - Similarly the nanotime() and - getnanotime() functions store the time as a - struct timespec. The structures are described in - timeval(3).

-

The - (), - microtime(), and - () - functions always query the timecounter to return the current time as - precisely as possible. Whereas getbintime(), - getmicrotime(), and - getnanotime() functions are abstractions which - return a less precise, but faster to obtain, time.

-

The intent of the - (), - (), - and - () - functions is to enforce the user's preference for timer accuracy versus - execution time. They should be used where a precision of - 1/HZ (e.g., 10 msec on a 100HZ machine, - see hz(9)) is acceptable or where performance is - priority.

-

The system realtime clock is guaranteed to be monotonically - increasing at all times. As such, all calls to these functions are - guaranteed to return a system time greater than or equal to the system time - returned in any previous calls. Comparable functions exist to retrieve the - time elapsed since boot; see microuptime(9).

-
-
-

-

The implementation of the - () - family of functions is in sys/kern/kern_tc.c as a - part of the timecounter(9) framework.

-

The implementation of the time counter sources used by the - timecounter(9) is machine dependent, hence its location in - the source code tree varies from architecture to architecture.

-
-
-

-

settimeofday(2), - bintime_add(9), inittodr(9), - time_second(9), tvtohz(9)

-
-
-

-

This manual page was written by Jeremy - Cooper and -
- Kelly Yancey - <kbyanc@posi.net>.

-
-
-

-

Despite the guarantee that the system realtime clock will always - be monotonically increasing, it is always possible for the system clock to - be manually reset by the system administrator to any date.

-
-
- - - - - -
May 13, 2013NetBSD 10.1
diff --git a/static/netbsd/man9/module.9 3.html b/static/netbsd/man9/module.9 3.html deleted file mode 100644 index f8cf2512..00000000 --- a/static/netbsd/man9/module.9 3.html +++ /dev/null @@ -1,539 +0,0 @@ - - - - - - -
MODULE(9)Kernel Developer's ManualMODULE(9)
-
-
-

-

module, - module_load, - module_autoload, - module_unload, - module_init_class, - module_hold, module_rele, - module_find_section, - module_kernel, module_name, - module_source, - module_register_callbacks, - module_unregister_callbacks, - module_specific_key_create, - module_specific_key_delete, - module_getspecific, - module_setspecific — kernel - module loader

-
-
-

-

#include - <sys/module.h>

-

MODULE(class, - name, - required);

-

int -
- module_load(const - char *name, int - flags, prop_dictionary_t - props, modclass_t - class);

-

int -
- module_autoload(const - char *name, modclass_t - class);

-

int -
- module_unload(const - char *name);

-

void -
- module_init_class(modclass_t - class);

-

void -
- module_hold(module_t - *module);

-

void -
- module_rele(module_t - *module);

-

int -
- module_find_section(const - char *, void **, - size_t *);

-

module_t * -
- module_kernel(void);

-

const char * -
- module_name(struct - module *module);

-

modsrc_t -
- module_source(struct - module *module);

-

void -
- module_init(void);

-

void -
- module_start_unload_thread(void);

-

void -
- module_builtin_require_force(void);

-

void -
- module_load_vfs_init(void);

-

void * -
- module_register_callbacks(void - (*)(struct module *), - void (*unload)(struct module - *));

-

void -
- module_unregister_callbacks(void - *);

-

specificdata_key_t -
- module_specific_key_create(specificdata_key_t - *keyp, - specificdata_dtor_t - dtor);

-

void -
- module_specific_key_delete(specificdata_key_t - key);

-

void * -
- module_getspecific(module_t - *mod, specificdata_key_t - key);

-

void * -
- module_setspecific(module_t - *mod, specificdata_key_t - key, void - *data);

-
-
-

-

Modules are sections of code that can be independently linked and - selectively loaded into or unloaded from a running kernel. This provides a - mechanism to update the module without having to relink the kernel and - reboot. Modules can be loaded from within the kernel image, provided by the - boot loader, or loaded from the file system.

-

The module subsystem includes two data - types:

-
    -
  1. The module_t type provides storage to describe a - module.
    2. -
  2. The modinfo_t type resides within - module_t and contains module header info.
    3. -
-

The module subsystem is protected by the global - kernconfig_mutex.

-
-
-

-
-
(class, - name, required)
-
The MODULE() macro creates and initializes a - modinfo_t structure. The class - argument identifies the class of module, and must be one of the following - (note that MODULE_CLASS_ANY should not be used - here): -
-
-
-
The module provide a virtual file system - see - vfs(9)
-
-
The module is a device driver - see driver(9)
-
-
The module provides an alternate execution environment - see the - various COMPAT_xxx options in - options(4)
-
-
The module provides a security model - see - secmodel(9)
-
-
The module provides a buffer queue strategy - see - bufq(9)
-
-
The module provides miscellaneous kernel services
-
-
-

The name argument provides the name of - the module. Loaded modules, including those that are built-in to the - kernel, must all have unique names.

-

The required argument is a quoted string - containing a comma-separated list of module names that are required by - this module. The list must not contain any white-space. When a module is - loaded, all of its required modules are auto-loaded and initialized - before the module itself is loaded. Loading of required modules is a - recursive operation.

-

If there are no required modules, this argument should be - specified as NULL.

-

In addition to the explicit arguments, the - () - macro creates a reference to the module's - modcmd() function. This function is defined - as:

-
-
-
int
-
(modcmd_t - cmd, void *data)
-
-
-

(where xxx is the name of the module, from the - MODULE macro).

-

The cmd argument requests one of the - following operations:

-
-
-
-
Perform module-specific initialization when the module is loaded.
-
-
Perform module-specific clean-up before the module is unloaded.
-
-
Notify the module that it is about to be unloaded.
-
-
Request the module to provide status information (not currently - implemented).
-
-
-

All modules' - () - functions must implement the MODULE_CMD_INIT and - MODULE_CMD_FINI commands. The other commands are - optional, and should return ENOTTY if not - implemented.

-

For the MODULE_CMD_INIT command, the - data argument is used to pass a pointer to the - module's prop_dictionary(3). For the - MODULE_CMD_STAT command, the - data argument points to a buffer where the status - information should be placed.

-

The __link_set mechanism is used to enable the - module subsystem to locate the - modinfo_t structure.

-
-
(name, - flags, props, - class)
-
Load a module, link it into the running kernel, and call the module's - modcmd() routine with a cmd - argument of MODULE_CMD_INIT. If the specified - module requires other modules, they are loaded first; if any required - module cannot be loaded or if any of their - modcmd() control routines returns a non-zero - status, loading of this module and the specific required module will fail. - The required modules are marked for automatic unloading. Thus, if the - loading of the module failed, the required modules will be automatically - unloaded after a short delay. -

The loader will look first for a built-in - module with the specified name that has not been - disabled (see - () - below). If a built-in module with that name is not - found, the list of modules prepared by the boot loader is searched. If - the named module is still not found, an attempt is made to locate the - module within the file system, provided it has been mounted by the - initialization code.

-

The flags argument can include:

-
-
-
-
When loading a module from the file system, do not attempt to locate a - corresponding prop_dictionary file.
-
-
Force loading of disabled built-in modules and modules built for a - different version of the operating system.
-
-
-

The props argument points - to an externalized property list which is passed to the module's - () - routine. If a module is being loaded from the file system, and the - MODCTL_NO_PROP flag is not set, the system - searches for a file with the same name as the module file, but with the - suffix “.plist”. If this file is - found, the prop_dictionary it contains is loaded and merged with the - prop_dictionary from the props argument.

-

The class argument can be any of:

-

-
-
-
-
 
-
-
Device driver
-
-
Executable image handler
-
-
Miscellaneous module
-
-
Security model (see secmodel(9) for more - details)
-
-
Virtual file system
-
-
-

If the class is not - MODULE_CLASS_ANY, the class of the module being - loaded must match the requested class. Except when - verifying a module's class when it is being loaded, module classes other - than MODULE_CLASS_SECMODEL are transparent to - the module subsystem. They are provided only for the benefit of the - subsystem's clients. Modules with class - MODULE_CLASS_SECMODEL are automatically - registered with - () - after being successfully loaded, and automatically deregistered with - () - when being unloaded.

-

The - () - routine is primarily intended as the implementation of the - MODCTL_LOAD option of the - modctl(2) system call.

-
-
module_autoload(name, - class)
-
Auto-load a module, making it available for automatic unloading. The - name and class arguments are - the same as for the module_load() routine. -

The module subsystem uses a kernel thread - to attempt to automatically unload modules a short time (currently, 10 - seconds) after being loaded by - (). - Before the module is unloaded by this thread, its - modcmd() is called with the - cmd argument specified as - MODULE_CMD_AUTOUNLOAD. A module can prevent - itself from being unloaded by returning a non-zero value. Exception: If - kern.module.autounload_unsafe is set, a module - that returns ENOTTY, meaning it does not - understand the command, may still be autounloaded.

-

The - () - function is intended for use by kernel components to locate and load - optional system components. The function is also used to load modules - that are required by other modules.

-

The directory from which the module is loaded - will be searched for a file with the same name as the module file, but - with the suffix “.plist”. If this - file is found, the prop_dictionary it contains will be loaded and passed - to the module's - () - routine. If this prop_dictionary contains a - “noautoload” property which is set - to “true” then the system will - refuse to load the module.

-
-
module_unload(name)
-
Unload a module. If the module's reference count is non-zero, the function - returns EBUSY. Otherwise, the module's - modcmd() routine is called with a - cmd argument of - MODULE_CMD_FINI. If the - modcmd() routine returns with an error, then the - error is returned to the caller otherwise the module is unloaded. -

The reference counts of all modules that - were required by this module are decremented, but the required modules - are not unloaded by the call to - (). - Instead, the required modules may be unloaded by subsequent calls to - module_unload().

-

Unloading a built-in module causes the - module to be marked as disabled. This prevents the module from being - re-loaded, except by the - () - function with the flags argument set to - MODULE_FORCE_LOAD.

-

The - () - function may be called by the modctl(2) system call, - by the module subsystem's internal auto-unload thread, or by other - kernel facilities. Generally, other kernel facilities should not be - calling this function.

-
-
(class)
-
Load and initialize all available modules of the specified - class. Any built-in modules that have not been - disabled, and any modules provided by the boot loader are loaded.
-
(module)
-
Increment the reference count of a module. A module cannot be unloaded if - its reference count is non-zero.
-
(module)
-
Decrement the reference count of a module.
-
(name, - addr, size)
-
Find the start address and size of linker section - name within a module. The miniroot module uses this - routine to find the address and size of the embedded file system image. - This routine can only examine the linker data for the module that is - currently being initialized; it cannot examine data for any other - module.
-
(void)
-
Returns a pointer to a module_t structure describing - the kernel module.
-
(module)
-
Returns a pointer to the module's name.
-
(module)
-
Returns the source of the module, one of - MODULE_SOURCE_KERNEL, - MODULE_SOURCE_BOOT, or - MODULE_SOURCE_FILESYS.
-
(void)
-
Initialize the module subsystem. Creates and initializes various data - structures, locates all built-in modules, and establishes the sub-system's - sysctl(8) tree. module_init() is - called early in system initialization to facilitate use of security model - modules.
-
(void)
-
Create the thread that attempts to automatically unload modules that were - loaded via the module_autoload() routine. The - function is called only once, after the scheduler and timer functions are - initialized.
-
(void)
-
Mark as "disabled" any built-in modules that have not been - successfully initialized. Modules marked "disabled" can only be - loaded if the MODCTL_LOAD_FORCE is specified. - module_builtin_require_force() is called near the - end of system initialization, after the init(8) process - is created.
-
(void)
-
The module subsystem is initialized early, long before any file systems - are available. After the root file system is mounted, - module_load_vfs_init(void) - is used to enable loading modules from the file system. Until this routine - is called, modules can only be loaded if they were built-in to the kernel - image or provided by the boot loader.
-
(void - (*load)(struct module *), void (*unload)(struct module - *))
-
Register a new set of callbacks. The load callback - is invoked after any module (including this module) is successfully - loaded; the unload callback is invoked before any - module is unloaded. Each load or unload event can result in multiple - invocations of the callback routines. An opaque cookie is returned which - can be passed to - ().
-
module_unregister_callbacks(void - *opaque)
-
Unregister a set of callback routines previously registered with - module_register_callbacks(). The - opaque argument should be the return value from the - previous module_register_callbacks() call.
-
(specificdata_key_t - *keyp, specificdata_dtor_t dtor)
-
Creates a new specificdata_key for use within the - module domain. The key identifier is returned in - keyp.
-
(specificdata_key_t - key)
-
Deletes the specified specificdata_key key from the - module domain.
-
(module_t - *mod, specificdata_key_t key)
-
Retrieves the value associated with key from module - mod.
-
(module_t - *mod, specificdata_key_t key, - void *data)
-
Stores data as the value associated with - key for module mod.
-
-
-
-

-

The module subsystem is designed to be called recursively, but - only within a single LWP. This permits one module's - modcmd() routine to load or unload other - modules.

-

Additional considerations:

-
    -
  • A module is not permitted to load or unload itself. Attempts - to load or unload a module from within its own - () - routine will fail with EEXIST or - EBUSY, respectively.
    • -
  • Although a module can be loaded by using either - module_load() or - module_autoload(), it is not possible for the - module's modcmd() routine to distinguish between - the two methods. Any module which needs to ensure that it does not get - auto-unloaded must either handle the - MODULE_CMD_AUTOUNLOAD command in its - modcmd() routine, or use - module_hold() to increment its reference count. - Note however that modules loaded manually with - modload(8) are never auto-unloaded.
    • -
-
-
-

-

A set of example modules is available in the - src/sys/modules/examples directory hierarchy.

-
-
-

-

The core of the kernel module implementation is in - sys/kern/kern_module.c and - sys/kern/kern_module_vfs.c.

-

The routines for linking the module are in - sys/kern/subr_kobj.c.

-

The routines for reading a module from the file system are in - sys/kern/subr_kobj_vfs.c.

-

The header file - <sys/sys/module.h> describes - the public interface.

-

In addition, each architecture is expected to - provide - (), - (), - and - (). - kobj_machdep() is for any machine dependent actions, - such as flushing caches, that are needed when a module is loaded or - unloaded. kobj_reloc() deals with resolution of - relocatable symbols. module_init_md() is for finding - modules passed in by the boot loader.

-
-
-

-

modctl(2), module(7), - specificdata(9), intro(9lua)

-
-
-

-

The kernel module subsystem first appeared in - NetBSD 5.0. It replaces the “LKM” - subsystem from earlier releases.

-
-
-

-

The module system was written by - Andrew Doran - <ad@NetBSD.org>. This - manual page was written by Paul Goyette - <pgoyette@NetBSD.org>.

-
-
- - - - - -
July 21, 2021NetBSD 10.1
diff --git a/static/netbsd/man9/namecache.9 3.html b/static/netbsd/man9/namecache.9 3.html deleted file mode 100644 index 39271d56..00000000 --- a/static/netbsd/man9/namecache.9 3.html +++ /dev/null @@ -1,223 +0,0 @@ - - - - - - -
NAMECACHE(9)Kernel Developer's ManualNAMECACHE(9)
-
-
-

-

namecache, - cache_lookup, - cache_revlookup, - cache_enter, cache_purge, - cache_purgevfs, - namecache_print — name - lookup cache

-
-
-

-

#include - <sys/namei.h> -
- #include <sys/proc.h> -
- #include <sys/uio.h> -
- #include <sys/vnode.h>

-

int -
- cache_lookup(struct - vnode *dvp, const char - *name, size_t - namelen, uint32_t - nameiop, uint32_t - nameiflags, int - *iswhiteout, struct vnode - **vpp);

-

int -
- cache_revlookup(struct - vnode *vp, struct vnode - *dvp, char **bpp, - char *bufp);

-

void -
- cache_enter(struct - vnode *dvp, struct vnode - *vp, const char - *name, size_t - namelen, uint32_t - nameiflags);

-

void -
- cache_purge(struct - vnode *vp);

-

void -
- cache_purgevfs(struct - mount *mp);

-

void -
- namecache_print(struct - vnode *vp, void - (*func)(const char *, ...));

-
-
-

-

The name lookup cache is the mechanism to allow the file system - type dependent algorithms to quickly resolve a file's vnode from its - pathname. The name lookup cache is generally accessed through the - higher-level namei(9) interface.

-

The name of the file is used to look up an entry associated with - the file in the name lookup cache. If no entry is found, one is created for - it. If an entry is found, the information obtained from the cache lookup - contains information about the file which is useful to the file system type - dependent functions.

-

The name lookup cache is managed by a least recently used (LRU) - algorithm so frequently used names will hang around. The cache itself is a - hash table called nchashtbl, containing - namecache entries that are allocated dynamically from a - kernel memory pool. Each entry has the following structure:

-
-
#define NCHNAMLEN	31	/* maximum name segment length */
-struct  namecache {
-        LIST_ENTRY(namecache) nc_hash;  /* hash chain */
-        TAILQ_ENTRY(namecache) nc_lru;  /* LRU chain */
-        LIST_ENTRY(namecache) nc_vhash; /* directory hash chain */
-        LIST_ENTRY(namecache) nc_dvlist;
-        struct  vnode *nc_dvp;          /* vnode of parent of name */
-        LIST_ENTRY(namecache) nc_vlist;
-        struct  vnode *nc_vp;           /* vnode the name refers to */
-        int     nc_flags;               /* copy of componentname's ISWHITEOUT */
-        char    nc_nlen;                /* length of name */
-        char    nc_name[NCHNAMLEN];     /* segment name */
-};
-
-

For simplicity (and economy of storage), names longer than a - maximum length of NCHNAMLEN are not cached; they occur infrequently in any - case, and are almost never of interest.

-

Each namecache entry can appear - on two hash chains in addition to nchashtbl: - - (the name cache directory hash chain), and - - (the name cache LRU chain). The hash chains are indexed by a hash value - obtained from the file's name and the address of its parent directory - vnode.

-

Functions which access to the name cache pass - arguments in the partially initialised - - structure. See vnodeops(9) for details on this - structure.

-
-
-

-
-
(dvp, - name, namelen, - nameiop, nameiflags, - iswhiteout, vpp)
-
Look for a name in the cache. cache_lookup() is - called with dvp pointing to the vnode of the - directory to search. The name and - namelen arguments specify the name to look for. The - nameiop and nameiflags should - be taken from the cn_nameiop and - cn_flags fields of struct componentname. -

The lookup can produce either a cache miss or a cache - hit, and a cache hit can either be a positive hit, where the name looked - up refers to some existing object, or a negative hit, where the name - looked up is known to refer to - existing - object. (The lookup cannot fail, in the sense of generating an error - condition that requires aborting the operation in progress.)

-

On a cache miss, - () - returns zero (false). On a positive hit, the unlocked vnode for the - object found is stored in vpp, and a nonzero - (true) value is returned. On a negative hit, vpp - is set to contain a null pointer and a nonzero value is returned. - Usually a negative hit will prompt the caller to fail with - ENOENT.

-

The iswhiteout - argument is a pointer to an integer result that will be set to nonzero - if the entry represents a whiteout, and zero if it does not. This - pointer may be NULL if the caller does not - support whiteouts. According to the current scheme for handling - whiteouts, if - () - sets iswhiteout the caller should add - ISWHITEOUT to the cn_flags - field of its struct componentname.

-
-
(vp, - dvp, bpp, - bufp)
-
Scan cache looking for name of directory entry pointing at - vp and fill in dvpp. If - bufp is non-NULL, also place - the name in the buffer which starts at bufp, - immediately before bpp, and move bpp backwards to - point at the start of it. If the lookup succeeds, the vnode is referenced. - Returns 0 on success, -1 on cache miss, positive errno on failure.
-
(dvp, - vp, name, - namelen, nameiflags)
-
Add an entry to the cache. The name and - namelen arguments specify the name to add to the - cache. The dvp argument specifies the directory the - name appears in. The vp argument specifies the - object to enter in the cache. The nameiflags - argument should come from the cn_flags member of - struct componentname. -

If vp is NULL, a - negative cache entry is created, specifying that the entry does not - exist in the file system.

-
-
(vp)
-
Flush the cache of a particular vnode vp. - cache_purge() is called when a vnode is renamed to - hide entries that would now be invalid.
-
(mp)
-
Flush cache of a whole file system mp. - cache_purgevfs() is called when file system is - unmounted to remove entries that would now be invalid.
-
(vp, - func)
-
Print all entries of the name cache. func is the - printf(9) format. - namecache_print() is only defined if the kernel - option DDB is compiled into the kernel.
-
-
-
-

-

The name lookup cache is implemented within the file - sys/kern/vfs_cache.c.

-
-
-

-

intro(9), namei(9), - vfs(9), vnode(9)

-
-
-

-

The name lookup cache first appeared in - 4.2BSD.

-
-
-

-

The original name lookup cache was written by - Robert Elz.

-
-
- - - - - -
February 7, 2014NetBSD 10.1
diff --git a/static/netbsd/man9/nullop.9 3.html b/static/netbsd/man9/nullop.9 3.html deleted file mode 100644 index 26154789..00000000 --- a/static/netbsd/man9/nullop.9 3.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - -
NULLOP(9)Kernel Developer's ManualNULLOP(9)
-
-
-

-

nullop — dummy - functions

-
-
-

-

#include - <sys/systm.h>

-

int -
- nullop(void - *v);

-

void -
- voidop(void);

-

int -
- enodev(void);

-

int -
- enxio(void);

-

int -
- enoioctl(void);

-

int -
- enosys(void);

-

int -
- eopnotsupp(void);

-
-
-

-

The - () - function provides a generic “null operation”. It always - returns the value 0. The - () - function takes no arguments and does nothing.

-

The - (), - (), - (), - (), - and - () - functions always fail, returning ENODEV, - ENXIO, ENOTTY, - ENOSYS, and EOPNOTSUPP, - respectively.

-
-
-

-

The following example demonstrates a case where - nullop() may be useful:

-
-
uint64_t xc;
-
-...
-
-xc = xc_broadcast(0, (xcfunc_t)nullop, NULL, NULL);
-xc_wait(xc);
-
-
-
- - - - - -
July 25, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/optstr.9 3.html b/static/netbsd/man9/optstr.9 3.html deleted file mode 100644 index c46e0389..00000000 --- a/static/netbsd/man9/optstr.9 3.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - -
OPTSTR(9)Kernel Developer's ManualOPTSTR(9)
-
-
-

-

optstr_get, - optstr_get_string, - optstr_get_number, - optstr_get_number_binary, - optstr_get_number_hex, - optstr_get_macaddr — Options - string management

-
-
-

-

#include - <sys/optstr.h>

-

bool -
- optstr_get(const char *optstr, - const char *key, char *buf, - size_t bufsize);

-

bool -
- optstr_get_string(const char - *optstr, const char *key, char - **result);

-

bool -
- optstr_get_number(const char - *optstr, const char *key, - unsigned long *result);

-

bool -
- optstr_get_number_binary(const char - *optstr, const char *key, - unsigned long *result);

-

bool -
- optstr_get_number_hex(const char - *optstr, const char *key, - unsigned long *result);

-

bool -
- optstr_get_macaddr(const char - *optstr, const char *key, - uint8_t result[ETHER_ADDR_LEN]);

-
-
-

-

An options string is a list of key/value pairs represented in - textual form. Each pair is expressed as - key=value - and is separated from other pairs by one or more spaces. For example:

-

-
key1=value1 key2=value2 - key3=value3
-

Options strings are used to pass information between userland - programs and the kernel in a binary-agnostic way. This makes them endianness - and ABI independent.

-
-
-

-

The following functions are provided to manage options - strings:

-
-
(optstr, - key, buf, - bufsize)
-
Scans the optstr options string looking for the key - key and stores its value in the buffer pointed to by - buf copying a maximum of - bufsize bytes. Returns - ‘true’ if the key was found or - ‘false’ otherwise, in which case - buf is left unmodified.
-
-

The optstr_get_item - family of functions provide the ability to scan for the key, and return the - value converted to an appropriate type.

-

-
-
(optstr, - key, result)
-
 
-
(optstr, - key, result)
-
 
-
(optstr, - key, result)
-
 
-
(optstr, - key, result)
-
 
-
(optstr, - key, result)
-
These functions scan the optstr options string - looking for the key key and returns the key value - converted as per the function name in result. All - functions return ‘true’ if the key - was found or ‘false’ otherwise, in - which case result is left unmodified.
-
-
-
-

-

The options string management functions are implemented within the - files sys/kern/subr_optstr.c and - sys/sys/optstr.h.

-
-
-

-

Options strings appeared in NetBSD - 4.0.

-
-
- - - - - -
May 20, 2023NetBSD 10.1
diff --git a/static/netbsd/man9/panic.9 3.html b/static/netbsd/man9/panic.9 3.html deleted file mode 100644 index 27a73f6c..00000000 --- a/static/netbsd/man9/panic.9 3.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - -
PANIC(9)Kernel Developer's ManualPANIC(9)
-
-
-

-

panic — bring down - system on fatal error

-
-
-

-

#include - <sys/types.h> -
- #include <sys/systm.h>

-

void -
- vpanic(const - char *fmt, va_list - ap);

-

void -
- panic(const - char *fmt, - ...);

-
-
-

-

The - () - and - () - functions terminate the NetBSD system. The message - fmt is a printf(3) style format - string which is printed to the console and saved in the variable - panicstr for later retrieval via core dump inspection. - A newline character is added at the end automatically, and is thus not - needed in the format string.

-

If a kernel debugger is installed, control is passed - to it after the message is printed. If the kernel debugger is - ddb(4), control may be passed to it, depending on the - value of ddb.onpanic. See options(4) for - more details on setting ddb.onpanic. If control is not - passed through to ddb(4), a - ddb(4)-specific function is used to print the kernel stack - trace, and then control returns to - ().

-

If control remains in - (), an - attempt is made to save an image of system memory on the configured dump - device.

-

If during the process of handling the panic, - () is - called again (from the filesystem synchronization routines, for example), - the system is rebooted immediately without synchronizing any - filesystems.

-

() - is meant to be used in situations where something unexpected has happened - and it is difficult to recover the system to a stable state, or in - situations where proceeding might make things worse, leading to data - corruption and/or loss. It is not meant to be used in scenarios where the - system could easily ignore and/or isolate the condition/subsystem and - proceed.

-

In general developers should try to reduce the number - of () - calls in the kernel to improve stability.

-
-
-

-

The panic() function never returns.

-
-
-

-

printf(3), sysctl(3), - ddb(4), options(4), - savecore(8), swapctl(8), - sysctl(8), printf(9)

-
-
- - - - - -
October 4, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/pci_configure_bus.9 3.html b/static/netbsd/man9/pci_configure_bus.9 3.html deleted file mode 100644 index de32dcfc..00000000 --- a/static/netbsd/man9/pci_configure_bus.9 3.html +++ /dev/null @@ -1,256 +0,0 @@ - - - - - - -
PCI_CONFIGURE_BUS(9)Kernel Developer's ManualPCI_CONFIGURE_BUS(9)
-
-
-

-

pci_configure_bus, - pci_conf_hook, - pci_conf_interrupt, - pciconf_resource_init, - pciconf_resource_add, - pciconf_resource_fini — - perform PCI bus configuration

-
-
-

-

#include - <dev/pci/pciconf.h>

-

int -
- pci_configure_bus(pci_chipset_tag_t - pc, struct - pciconf_resources *res, - int firstbus, - int cacheline_size);

-

struct pciconf_resources * -
- pciconf_resource_init(void);

-

void -
- pciconf_resource_add(struct - pciconf_resources *res, - int type, - bus_addr_t addr, - bus_size_t size);

-

void -
- pciconf_resource_fini(struct - pciconf_resources *res);

-
-
-

-

The - () - function configures a PCI bus for use. This involves:

-
    -
  • Defining bus numbers for all busses on the system,
    • -
  • Setting the Base Address Registers for all devices,
    • -
  • Setting up the interrupt line register for all devices,
    • -
  • Configuring bus latency timers for all devices, and
    • -
  • Configuring cacheline sizes for all devices.
    • -
-

In traditional PCs and Alpha systems, the - BIOS or firmware takes care of this task, but that is not the case for all - systems. - () - should be called prior to the autoconfiguration of the bus.

-

The pc argument is a - machine-dependent tag used to specify the PCI chipset to the system. This - should be the same value used with - (). - The res argument is a container for PCI bus resources - that will be used to configure the bus. The firstbus - argument indicates the number of the first bus to be configured. The - cacheline_size argument is used to configure the PCI - Cache Line Size Register; it should be the size, in bytes, of the largest - D-cache line on the system.

-

An implementation may choose to not have - full configuration performed by - () - on certain PCI devices, such as PCI host bridges or PCI bus analyzers which - are instantiated as devices on the bus. In order for this to take place, the - header - <machine/pci_machdep.h> must - define the __HAVE_PCI_CONF_HOOK symbol (without a - value), and a machine-dependent function - pci_conf_hook() (declared in the same header) must - be defined. The prototype for this function is:

-

int - (pci_chipset_tag_t - pc, int bus, int device, - int function, pcireg_t id);

-

In this function, bus, - device, and function uniquely - identify the item being configured; in addition to this, the value of the - device's PCI identification register is passed in id. - For each device - () - can then decide upon the amount of configuration to be performed by - returning a bitwise inclusive-or of the following flags:

-
-
-
-
Configure Base Address Registers that map I/O space
-
-
Configure Base Address Registers that map memory space
-
-
Configure Expansion ROM Base Address register
-
-
Enable I/O space accesses
-
-
Enable memory space accesses
-
-
Enable bus mastering
-
-
-

In addition, PCI_CONF_ALL specifies all of - the above.

-

One of the functions of - () - is to configure interrupt “line” information. This must be - done on a machine-dependent basis, so a machine-dependent function - pci_conf_interrupt() must be defined. The prototype - for this function is

-

void - (pci_chipset_tag_t - pc, int bus, int device, - int pin, int swiz, - int *iline)

-

In this function, bus, - device, and pin, uniquely - identify the item being configured. The swiz argument - is a “swizzle”, a sum of the device numbers of the primary - interface of the bridges between the host bridge and the current device. The - function is responsible for setting the value of - iline. See chapter 9 of the “PCI-to-PCI Bridge - Architecture Specification” for more information on swizzling (also - known as interrupt routing).

-

The resources used to configure the PCI - bus are encapsulated into a resource container. The - () - function allocates and initializes one of these containers, and the - () - function adds resources to the container, specifying the type, start - address, and size of the resource being added. The following resource types - are supported:

-
-
-
-
An address region used for PCI I/O accesses.
-
-
An address region used for PCI memory accesses where reads may have side - effects.
-
-
An address region used for PCI memory accesses where reads do not have - side effects (e.g. ROMs, frame buffers, other memory-like regions that are - marked as prefetchable in their BAR).
-
-
-

If an implementation does not distinguish between prefetchable and - non-prefetchable memory, then adding a - PCICONF_RESOURCE_PREFETCHABLE_MEM resource is not - required; PCICONF_RESOURCE_MEM resources will be - used for ROMs and BARs that are marked as prefetchable.

-

Once the bus has been successfully - configured, the resource container should be disposed of by calling - ().

-
-
-

-

If successful pci_configure_bus() returns - 0. A non-zero return value means that the bus was not completely configured - for some reason. A description of the failure will be displayed on the - console.

-
-
-

-

The pci_configure_bus() function is only - included in the kernel if the kernel is compiled with the - PCI_NETBSD_CONFIGURE option enabled.

-
-
-

-

The pci_conf_hook() function in evbppc's - walnut implementation looks like:

-

-
-
int
-pci_conf_hook(pci_chipset_tag_t pc, int bus, int dev, int func,
-    pcireg_t id)
-{
-
-	if ((PCI_VENDOR(id) == PCI_VENDOR_IBM &&
-	     PCI_PRODUCT(id) == PCI_PRODUCT_IBM_405GP) ||
-	    (PCI_VENDOR(id) == PCI_VENDOR_INTEL &&
-	     PCI_PRODUCT(id) == PCI_PRODUCT_INTEL_80960_RP)) {
-		/* Don't configure the bridge and PCI probe. */
-		return 0;
-	}
-	return (PCI_CONF_ALL & ~PCI_CONF_MAP_ROM);
-}
-
-

The pci_conf_interrupt() function in the - sandpoint implementation looks like:

-

-
-
void
-pci_conf_interrupt(pci_chipset_tag_t pc, int bus, int dev, int pin,
-    int swiz, int *iline)
-{
-	if (bus == 0) {
-		*iline = dev;
-	} else {
-		*iline = 13 + ((swiz + dev + 3) & 3);
-	}
-}
-
-

This configuration example is taken from the bebox port.

-

-
-
#define PCI_IO_START    0x00008000
-#define PCI_IO_END      0x0000ffff
-#define PCI_IO_SIZE     ((PCI_IO_END - PCI_IO_START) + 1)
-
-#define PCI_MEM_START   0x00000000
-#define PCI_MEM_END     0x0fffffff
-#define PCI_MEM_SIZE    ((PCI_MEM_END - PCI_MEM_START) + 1)
-	...
-	struct pciconf_resources *pcires;
-	...
-	pcires = pciconf_resource_init();
-	pciconf_resource_add(pcires, PCICONF_RESOURCE_IO,
-	    PCI_IO_START, PCI_IO_SIZE);
-	pciconf_resource_add(pcires, PCICONF_RESOURCE_MEM,
-	    PCI_MEM_START, PCI_MEM_SIZE);
-	...
-	pci_configure_bus(pc, pcires, 0, CACHELINESIZE);
-	...
-	pciconf_resource_fini(pcires);
-	...
-
-

Note that this must be called before the PCI bus is attached - during autoconfiguration.

-
-
-

-

pci(4)

-
-
-

-

pci_configure_bus() was added in - NetBSD 1.6.

-
-
- - - - - -
July 7, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/pci_intr.9 3.html b/static/netbsd/man9/pci_intr.9 3.html deleted file mode 100644 index b80bb699..00000000 --- a/static/netbsd/man9/pci_intr.9 3.html +++ /dev/null @@ -1,184 +0,0 @@ - - - - - - -
PCI_INTR(9)Kernel Developer's ManualPCI_INTR(9)
-
-
-

-

pci_intr, - pci_intr_map, - pci_intr_string, - pci_intr_evcnt, - pci_intr_establish, - pci_intr_establish_xname, - pci_intr_disestablish, - pci_intr_setattr — PCI bus - interrupt manipulation functions

-
-
-

-

#include - <dev/pci/pcivar.h>

-

int -
- pci_intr_map(const - struct pci_attach_args *pa, - pci_intr_handle_t - *ih);

-

const char * -
- pci_intr_string(pci_chipset_tag_t - pc, pci_intr_handle_t - ih, char *buf, - size_t len);

-

const struct evcnt * -
- pci_intr_evcnt(pci_chipset_tag_t - pc, pci_intr_handle_t - ih);

-

void * -
- pci_intr_establish(pci_chipset_tag_t - pc, pci_intr_handle_t - ih, int ipl, - int (*intrhand)(void *), - void *intrarg);

-

void * -
- pci_intr_establish_xname(pci_chipset_tag_t - pc, pci_intr_handle_t - ih, int ipl, - int (*intrhand)(void *), - void *intrarg, - const char *xname);

-

void -
- pci_intr_disestablish(pci_chipset_tag_t - pc, void *ih);

-

int -
- pci_intr_setattr(pci_chipset_tag_t - pc, pci_intr_handle_t - *ih, int attr, - uint64_t data);

-
-
-

-

The pci_intr functions exist to allow - device drivers machine-independent access to PCI bus interrupts. The - functions described in this page are typically declared in a port's - <machine/pci_machdep.h> - header file; however, drivers should generally include - <dev/pci/pcivar.h> to get - other PCI-specific declarations as well.

-

Each driver has an - () - function which has a bus-specific attach_args - structure. Each driver for a PCI device is passed a pointer to an object of - type struct pci_attach_args which contains, among - other things, information about the location of the device in the PCI bus - topology sufficient to allow interrupts from the device to be handled.

-

If a driver wishes to establish an interrupt - handler for the device, it should pass the struct - pci_attach_args * to the - () - function, which returns zero on success, and nonzero on failure. The - function sets the pci_intr_handle_t pointed at by its - second argument to a machine-dependent value which identifies a particular - interrupt source.

-

If the driver wishes to refer to the - interrupt source in an attach or error message, it should use the value - returned by - (). - The buffer passed to pci_intr_string() should be at - least PCI_INTRSTR_LEN bytes.

-

Subsequently, when the driver is prepared - to receive interrupts, it should call - () - to actually establish the handler; when the device interrupts, - intrhand will be called with a single argument - intrarg, and will run at the interrupt priority level - ipl.

-

The return value of - () - may be saved and passed to - () - to disable the interrupt handler when the driver is no longer interested in - interrupts from the device.

-

() - is almost the same as pci_intr_establish(). The - difference is only xname which is used by - intrctl(8) to show the device name(s) of the interrupt - id.

-

The - () - function sets an attribute attr of the interrupt - handler to data. Currently, only the following - attribute is supported:

-
-
-
If this attribute is set to true, it specifies - that the interrupt handler is multiprocessor safe and works its own - locking; otherwise the kernel lock will be held for the call to the - interrupt handler. The default is false.
-
-

The - () - function returns zero on success, and nonzero on failure.

-

The - () - function should return an evcnt structure pointer or - NULL if there is no evcnt associated with this - interrupt. See evcnt(9) for more details.

-
-

-

A port's implementation of pci_intr_map() - may use the following members of struct - pci_attach_args to determine how the device's interrupts are - routed.

-
-
	pci_chipset_tag_t pa_pc;
-	pcitag_t pa_tag;
-	pcitag_t pa_intrtag; /* intr. appears to come from here */
-	pci_intr_pin_t pa_intrpin; /* intr. appears on this pin */
-	pci_intr_line_t pa_intrline; /* intr. routing information */
-	pci_intr_pin_t pa_rawintrpin; /* unswizzled pin */
-
-

PCI-PCI bridges swizzle (permute) interrupt wiring. Depending on - implementation details, it may be more convenient to use either original or - the swizzled interrupt parameters. The original device tag and interrupt pin - can be found in pa_tag and - pa_rawintrpin respectively, while the swizzled tag and - pin can be found in pa_intrtag and - pa_intrpin.

-

When a device is attached to a primary bus, both pairs of fields - contain the same values. When a device is found behind one or more pci-pci - bridges, pa_intrpin contains the - “swizzled” interrupt pin number, while - pa_rawintrpin contains the original interrupt pin; - pa_tag contains the PCI tag of the device itself, and - pa_intrtag contains the PCI tag of the uppermost - bridge device.

-
-
-
-

-

evcnt(9), pci(9), - pci_msi(9)

-
-
-

-

pci_intr_establish_xname() was added in - NetBSD 8.0 as part of MSI/MSI-X support.

-
-
- - - - - -
September 20, 2018NetBSD 10.1
diff --git a/static/netbsd/man9/pci_msi.9 3.html b/static/netbsd/man9/pci_msi.9 3.html deleted file mode 100644 index 1c2d0d0e..00000000 --- a/static/netbsd/man9/pci_msi.9 3.html +++ /dev/null @@ -1,296 +0,0 @@ - - - - - - -
PCI_MSI(9)Kernel Developer's ManualPCI_MSI(9)
-
-
-

-

pci_msi, pci_msix, - pci_msi_count, - pci_msi_alloc, - pci_msi_alloc_exact, - pci_msix_count, - pci_msix_alloc, - pci_msix_alloc_exact, - pci_msix_alloc_map, - pci_intx_alloc, - pci_intr_alloc, - pci_intr_release, - pci_intr_type — PCI MSI{,-X} - manipulation functions

-
-
-

-

int -
- pci_msi_count(pci_chipset_tag_t - pc, pcitag_t - tag);

-

int -
- pci_msi_alloc(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihps, - int *count);

-

int -
- pci_msi_alloc_exact(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihps, - int count);

-

int -
- pci_msix_count(pci_chipset_tag_t - pc, pcitag_t - tag);

-

int -
- pci_msix_alloc(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihps, - int *count);

-

int -
- pci_msix_alloc_exact(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihps, - int count);

-

int -
- pci_msix_alloc_map(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihps, - u_int *table_indexes, - int count);

-

int -
- pci_intx_alloc(const - struct pci_attach_args *pa, - pci_intr_handle_t - **ihp);

-

int -
- pci_intr_alloc(const - struct pci_attach_args *pa, - pci_intr_handle_t **ihp, - int *counts, - pci_intr_type_t - max_type);

-

void -
- pci_intr_release(pci_chipset_tag_t - pc, pci_intr_handle_t - *pih, int - count);

-

pci_intr_type_t -
- pci_intr_type(pci_chipset_tag_t - pc, pci_intr_handle_t - ih);

-
-
-

-

The pci_msi functions exist to allow - device drivers to use MSI/MSI-X. When the system uses MSI/MSI-X, it must - define the __HAVE_PCI_MSI_MSIX build option.

-

Each driver has an - () - function which has a bus-specific attach_args - structure. Each driver for a PCI device is passed a pointer to an object of - type struct pci_attach_args which contains, among - other things, information about the location of the device in the PCI bus - topology sufficient to allow interrupts from the device to be handled.

-

() - returns the max number of the device's MSI. If the device can not use MSI, - pci_msi_count() returns zero. - () - works in the same manner for MSI-X.

-

If a driver wishes to establish an MSI handler - for the device, it should pass the struct pci_attach_args - * and count - () - or - () - functions, which return zero on success, and nonzero on failure. When the - functions are successful, they return the pointer to the allocated handle - array in pihs whose size is - count or less. The difference between - pci_msi_alloc() and - pci_msi_alloc_exact() is whether - count can be decremented or not. - pci_msi_alloc() can decrement - count, and which is similar to - FreeBSD's - (). - In contrast, pci_msi_alloc_exact() can not decrement - count.

-

If the driver wishes to refer to the MSI - source in an attach or error message, it should use the value returned by - () - the same as INTx. The buffer passed to - pci_intr_string() should be at least - PCI_INTRSTR_LEN bytes long.

-

Subsequently, when the driver is prepared - to receive MSIs, it should call - () - the same as INTx to actually establish the handler; when the device - interrupts, intrhand will be called with a single - argument intrarg, and will run at the interrupt - priority level ipl.

-

The return value of - () - may be saved and passed to - () - to disable the interrupt handler the same as INTx when the driver is no - longer interested in MSIs from the device. After that, the driver should - also call pci_intr_release() to free resources about - MSI as well as INTx and MSI-X. If pih is NULL, - pci_intr_release() does nothing.

-

If a driver wishes to establish an MSI-X - handler for the device, it is almost the same as MSI. The only differences - is - (). - This function can assign separate handlers for each MSI-X table entry. I.e., - if the driver wants to assign the handlers in the following way:

-
-
	msix_handler0 => MSI-X table index: 4
-	msix_handler1 => MSI-X table index: 5
-	msix_handler2 => MSI-X table index: 0
-
-the driver should set table_indexes this way: -
-
	table_indexes[0] = 4;
-	table_indexes[1] = 5;
-	table_indexes[2] = 0;
-
-

If the driver wants to fall back to INTx, the - driver should use - () - and - () - instead of - () - to resolve contradiction of the interrupt handler ownership. I.e., - pci_intr_map() does not have the ownership (the - function just calculates value), in contrast, - pci_msi_alloc() and - () - have (the functions allocate memory for interrupt handlers).

-

() - is wrapper function which select and automatically fallback allocation - functions according to the argument counts. The - elements of counts array means each required interrupt - count for INTx, MSI, and MSI-X. The index count of - counts must be - PCI_INTR_TYPE_SIZE. max_type - must be PCI_INTR_TYPE_MSIX, - PCI_INTR_TYPE_MSI, or - PCI_INTR_TYPE_INTX. The parameter does not mean - array index counts of counts. The parameter means the - interrupt type which pci_intr_alloc() tries to - allocate first. I.e., if the driver wants to allocate interrupts in the - following way:

-
-
	5 MSI-X
-	1 MSI (if MSI-X allocation failed)
-	INTx (if MSI allocation failed either)
-
-the driver should call pci_intr_alloc() in the following - way: -
-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = 5;
-	counts[PCI_INTR_TYPE_MSI] = 1;
-	counts[PCI_INTR_TYPE_INTX] = 1;
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSIX);
-
-If the driver wants to allocate interrupts in the following way: -
-
	hardware max number MSI-X
-	1 MSI (if MSI-X allocation failed)
-
-that is, the driver does not use INTx, the driver should call - pci_intr_alloc() in the following way: -
-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = -1; /* -1 means max */
-	counts[PCI_INTR_TYPE_MSI] = 1;
-	counts[PCI_INTR_TYPE_INTX] = 0; /* 0 means not use */
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSIX);
-
-If the driver wants to allocate interrupts in the following way: -
-
	3 MSI
-	INTx (if MSI allocation failed)
-
-that is, the driver does not use MSI-X, the driver should call - pci_intr_alloc() in the following way: -
-
	int counts[PCI_INTR_TYPE_SIZE];
-	counts[PCI_INTR_TYPE_MSIX] = 0; /* 0 means not use */
-	counts[PCI_INTR_TYPE_MSI] = 3;
-	counts[PCI_INTR_TYPE_INTX] = 1;
-	error = pci_intr_alloc(pa, ihps, counts,
-			       PCI_INTR_TYPE_MSI);
-
-If the driver wants to allocate interrupts in the following way: -
-
	1 MSI-X
-	1 MSI
-	INTx (if MSI/MSI-X allocation failed)
-
-that is, general usage, the driver should call simply - pci_intr_alloc() in the following way: -
-
	error = pci_intr_alloc(pa, ihps, NULL, 0);
-
-max_type is ignored in this case. - pci_intr_alloc() returns zero on any allocation - function success, and non-zero on all allocation function failures. On - success, counts is overwritten by a really allocated - count. I.e., if 5 MSI-X is allocated, counts is -
-
	counts[PCI_INTR_TYPE_MSIX] == 5
-	counts[PCI_INTR_TYPE_MSI] == 0
-	counts[PCI_INTR_TYPE_INTX] == 0
-
-on return. -

() - returns the interrupt type of ih. The return value is - PCI_INTR_TYPE_MSIX for MSI-X, - PCI_INTR_TYPE_MSI for MSI, and - PCI_INTR_TYPE_INTX for others.

-
-
-

-

pci_intr(9)

-
-
-

-

pci_msi support first appeared in - NetBSD 8.0. Support is present on - , - - and - - architectures.

-
-
-

-

The pci_msi interfaces were designed and - implemented by Kengo Nakahara - <knakahara@NetBSD.org>.

-
-
- - - - - -
January 12, 2021NetBSD 10.1
diff --git a/static/netbsd/man9/pckbport.9 3.html b/static/netbsd/man9/pckbport.9 3.html deleted file mode 100644 index d1920d32..00000000 --- a/static/netbsd/man9/pckbport.9 3.html +++ /dev/null @@ -1,319 +0,0 @@ - - - - - - -
PCKBPORT(9)Kernel Developer's ManualPCKBPORT(9)
-
-
-

-

pckbport, - pckbport_attach, - pckbport_attach_slot, - pckbport_cnattach, - pckbportintr, - pckbport_set_inputhandler, - pckbport_flush, - pckbport_poll_cmd, - pckbport_enqueue_cmd, - pckbport_poll_data, - pckbport_set_poll, - pckbport_xt_translation, - pckbport_slot_enable — PC - keyboard port interface

-
-
-

-

#include - <dev/pckbport/pckbportvar.h>

-

pckbport_tag_t -
- pckbport_attach(void - *, struct - pckbport_accessops const *);

-

struct device * -
- pckbport_attach_slot(struct - device *, - pckbport_tag_t, - pckbport_slot_t);

-

int -
- pckbport_cnattach(void - *, struct - pckbport_accessops const *, - pckbport_slot_t);

-

void -
- pckbportintr(pckbport_tag_t, - pckbport_slot_t, - int);

-

void -
- pckbport_set_inputhandler(pckbport_tag_t, - pckbport_slot_t, - pckbport_inputfcn, - void *, - char *);

-

void -
- pckbport_flush(pckbport_tag_t, - pckbport_slot_t);

-

int -
- pckbport_poll_cmd(pckbport_tag_t, - pckbport_slot_t, - u_char *, - int, - int, - u_char *, - int);

-

int -
- pckbport_enqueue_cmd(pckbport_tag_t, - pckbport_slot_t, - u_char *, - int, - int, - int, - u_char *);

-

int -
- pckbport_poll_data(pckbport_tag_t, - pckbport_slot_t);

-

void -
- pckbport_set_poll(pckbport_tag_t, - pckbport_slot_t, - int);

-

int -
- pckbport_xt_translation(pckbport_tag_t, - pckbport_slot_t, - int);

-

void -
- pckbport_slot_enable(pckbport_tag_t, - pckbport_slot_t, - int);

-
-
-

-

The machine-independent pckbport subsystem - provides an interface layer corresponding to the serial keyboard and mouse - interface used on the IBM PS/2 and many other machines. It interfaces a - controller driver such as pckbc(4) to device drivers such - as pckbd(4) and pms(4).

-

A single controller can have up to two ports (known as - “slots”), and these are identified by values of type - pckbport_slot_t. The values - PCKBPORT_KBD_SLOT and - PCKBPORT_AUX_SLOT should be used for keyboard and - mouse ports respectively. Each controller is identified by an opaque value - of type pckbport_tag_t.

-
-

-

A PC keyboard controller registers itself by calling - (cookie, - ops), with ops being a pointer - to a struct pckbport_accessops containing pointers to - functions for driving the controller, which will all be called with - cookie as their first argument. - pckbport_attach() returns the - pckbport_tag_t assigned to the controller. The - controller is then expected to call - () - for each slot with which it is equipped, passing the struct - device * corresponding to the controller. This function returns a - pointer to the child device attached to the slot, or - NULL if no such device was attached.

-

The elements of struct - pckbport_accessops each take as their first two arguments the - cookie passed to - () - and the slot in question. The elements are:

-
-
int - (*t_xt_translation)(void - *cookie, pckbport_slot_t slot, - int on)
-
If on is non-zero, enable, otherwise disable, - AT-to-XT keycode translation on the slot specified. Returns 1 on success, - 0 on failure (or if the controller does not support such - translation).
-
int - (*t_send_devcmd)(void *cookie, - pckbport_slot_t slot, u_char - byte)
-
Send a single byte to the device without waiting for - completion. Returns 1 on success, 0 on failure.
-
int - (*t_poll_data1)(void *cookie, - pckbport_slot_t slot)
-
Wait for and return one byte of data from the device, without using - interrupts. This function will only be called after - (*t_set_poll)() has been used to put the slot in - polling mode. If no data are forthcoming from the device after about - 100ms, return -1.
-
void - (*t_slot_enable)(void *cookie, - pckbport_slot_t slot, int - on)
-
If on is non-zero, enable, otherwise disable, the - slot. If a slot is disabled, it can be powered down, and is not expected - to generate any interrupts. When first attached, ports should be - disabled.
-
void - (*t_intr_establish)(void - *cookie, pckbport_slot_t slot)
-
Set up an interrupt handler for the slot. Called when a device gets - attached to it.
-
void - (*t_set_poll)(void *cookie, - pckbport_slot_t slot, int - on)
-
If on is non-zero, enable, otherwise disable, - polling mode on the slot. In polling mode, data received from the device - are provided to (*t_poll_data1)() and not passed - to - (), - whether or not interrupts are enabled. In non-polling mode, data from the - device are expected to cause interrupts. The controller interrupt handler - should call - pckbportintr(tag, - slot, byte) once for each - byte received from the device. When first attached, - a port should be in non-polling mode.
-
-
-
-

-

Devices that attach to pckbport - controllers do so using the normal autoconf(9) mechanism. - Their (*ca_match)() and - (*ca_attach)() functions get passed a - struct pckbport_attach_args which contains the - controller and slot number where the device was found. Device drivers can - use the following functions to communicate with the controller. Each takes - tag and slot arguments to - specify the slot to be acted on.

-
-
(tag, - slot, fn, - arg, name)
-
Arrange for fn to be called with argument - arg whenever an unsolicited byte is received from - the slot. The function will be called at - ().
-
(tag, - slot)
-
Ensure that there is no pending input from the slot.
-
(tag, - slot, cmd, - len, responselen, - respbuf, slow)
-
Issue a complete device command, cmd, - len bytes long, expecting a response - responselen bytes long, which will be placed in - respbuf. If slow is true, the - command is expected to take over a second to execute. - pckbport_poll_cmd() handles getting an - acknowledgement from the device and retrying the command if necessary. - Returns 0 on success, and an error value on failure. This function should - only be called during autoconfiguration or when the slot has been placed - into polling mode by - ().
-
(tag, - slot, cmd, - len, responselen, - sync, respbuf)
-
Issue a complete device command, cmd, - len bytes long, expecting a response - responselen bytes long, which will be places in - respbuf. If sync is true, - pckbport_enqueue_cmd() waits for the command to - complete before returning, otherwise it returns immediately. It is not - safe to set sync when calling from an interrupt - context. The pckbport layer handles getting an - acknowledgement from the device and retrying the command if necessary. - Returns 0 on success, and an error value on failure.
-
(tag, - slot)
-
Low-level command to poll for a single byte of data from the device, but - ignoring bytes that are part of the response to a command issued through - ().
-
pckbport_set_poll(tag, - slot, on)
-
If on is true, enable polling on the slot, otherwise - disable it. In polling mode, pckbport_poll_cmd() - can be used to issue commands and - pckbport_poll_data() to read unsolicited data, - without enabling interrupts. In non-polling mode, commands should be - issued using pckbport_enqueue_cmd(), unsolicited - data are handled by the input function, and disabling interrupts will - suspend pckbport operation.
-
(tag, - slot, on)
-
Passthrough of (*t_xt_translation)() (see - above).
-
(enable, - tag, slot, - on)
-
Passthrough of (*t_slot_enable)() (see - above).
-
-
-
-

-

On systems that can attach consoles through - pckbport, the controller's console attachment - function (called very early in autoconfiguration) calls - (cookie, - ops, slot). The first two - arguments are the same as for pckbport_attach(), - while the third indicates which slot the console keyboard is attached to. - pckbport_cnattach() either calls - (), - if it is available, or - (). - The latter allows machine-dependent keyboard drivers to attach themselves, - but it is only called if a device with the - ‘pckbport_machdep_cnattach’ attribute - is configured into the system. pckbport_cnattach() - returns 0 on success and an error value on failure. - pckbport_machdep_cnattach() is expected to do the - same.

-
-
-
-

-

The pckbport code, and the - pckbd(4) and pms(4) device drivers are - in sys/dev/pckbport.

-
-
-

-

pckbc(4), pckbd(4), - pms(4), autoconf(9), - spl(9)

-
-
-

-

The pckbport system appeared in - NetBSD 2.0. Before that, pckbd(4) - and pms(4) attached directly to pckbc(4) - without any sensible way of using a different controller.

-
-
- - - - - -
August 5, 2004NetBSD 10.1
diff --git a/static/netbsd/man9/pcq.9 3.html b/static/netbsd/man9/pcq.9 3.html deleted file mode 100644 index 0dc43915..00000000 --- a/static/netbsd/man9/pcq.9 3.html +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - -
PCQ(9)Kernel Developer's ManualPCQ(9)
-
-
-

-

pcq — - producer/consumer queue

-
-
-

-

#include - <sys/pcq.h>

-

pcq_t * -
- pcq_create(size_t - maxlen, km_flags_t - kmflags);

-

void -
- pcq_destroy(pcq_t - *pcq);

-

void * -
- pcq_get(pcq_t - *pcq);

-

size_t -
- pcq_maxitems(pcq_t - *pcq);

-

void * -
- pcq_peek(pcq_t - *pcq);

-

bool -
- pcq_put(pcq_t - *pcq, void - *item);

-
-
-

-

The machine-independent pcq interface - provides lockless producer/consumer queues. A queue - (pcq_t) allows multiple writers (producers), but only - a single reader (consumer). The consumer is expected to be protected by a - lock that covers the structure that the pcq_t is - embedded into (e.g., socket lock, ifnet hwlock). These queues operate in a - first-in, first-out (FIFO) manner. The act of inserting or removing an item - from a pcq_t does not modify the item in any way. - pcq does not prevent an item from being inserted - multiple times into a single pcq_t.

-
-
-

-
-
(maxlen, - kmflags)
-
Create a queue that can store at most maxlen items - at one time. kmflags should be either - KM_SLEEP, if pcq_create() - is allowed to sleep until resources are available, or - KM_NOSLEEP if it should return - NULL immediately, if resources are - unavailable.
-
(pcq)
-
Free the resources held by pcq.
-
pcq_get(pcq)
-
Remove the next item to be consumed from the queue and return it. If the - queue is empty, return NULL. The caller must - prevent concurrent gets from occurring.
-
(pcq)
-
Return the maximum number of items that the queue can store at any one - time.
-
pcq_peek(pcq)
-
Return the next item to be consumed from the queue but do not remove it - from the queue. If the queue is empty, return - NULL.
-
pcq_put(pcq, - item)
-
Place an item at the end of the queue. If there is no room in the queue - for the item, return false; otherwise, return - true. The item must not have the value of - NULL.
-
-
-

-

Any memory operations sequenced before - pcq_put() of an item in one thread happen before all - memory operations with data dependencies on the item returned by - pcq_get() or pcq_peek() in - another thread. For example:

-
-
int mumble;
-
-/* producer */
-mumble = 42;			// A
-foo->x = 123;			// B
-refcnt = foo->refcnt;		// C
-pcq_put(pcq, foo);
-KASSERT(refcnt == 0);
-
-/* consumer */
-foo = pcq_get(pcq);
-if (foo == NULL)
-	return;
-atomic_inc_uint(&foo->refcnt);	// D
-x = foo->x;			// E
-if (x == 123)
-	KASSERT(mumble == 42);	// F
-
-

In this example, memory operations B and C - happen-before D and E. However, no ordering is guaranteed for A or F - relative to any other memory operations, because the memory location of - mumble is independent of the pointer - foo returned by - ().

-

If you must guarantee A happens before F, then on - the consumer side, after - () - or - (), - you can call - () - to turn it into an acquire operation instead of a consume operation; - () - serves as the matching release operation. (This is a little dicey. Perhaps - there should be separate - () - and - () - operations if this semantics is necessary.)

-
-
-
-

-

The pcq interface is implemented within - the file sys/kern/subr_pcq.c.

-
-
-

-

atomic_ops(3), queue(3)

-
-
-

-

The pcq interface first appeared in - NetBSD 6.0.

-
-
- - - - - -
January 22, 2012NetBSD 10.1
diff --git a/static/netbsd/man9/pfil.9 3.html b/static/netbsd/man9/pfil.9 3.html deleted file mode 100644 index f140ca0d..00000000 --- a/static/netbsd/man9/pfil.9 3.html +++ /dev/null @@ -1,246 +0,0 @@ - - - - - - -
PFIL(9)Kernel Developer's ManualPFIL(9)
-
-
-

-

pfil, - pfil_head_create, - pfil_head_destroy, - pfil_head_get, - pfil_hook_get, - pfil_add_hook, - pfil_remove_hook, - pfil_run_hooks, - pfil_add_ihook, - pfil_remove_ihook, - pfil_run_addrhooks, - pfil_run_ifhooks — packet - filter interface

-
-
-

-

#include - <sys/param.h> -
- #include <sys/mbuf.h> -
- #include <net/if.h> -
- #include <net/pfil.h>

-

pfil_head_t * -
- pfil_head_create(int - type, void - *key);

-

int -
- pfil_head_destroy(pfil_head_t - *ph);

-

pfil_head_t * -
- pfil_head_get(int - type, void - *key);

-

struct packet_filter_hook * -
- pfil_hook_get(int - dir, pfil_head_t - *ph);

-

int -
- pfil_add_hook(pfil_func_t - func, void *arg, - int flags, - pfil_head_t *ph);

-

int -
- pfil_remove_hook(pfil_func_t - func, void *arg, - int flags, - pfil_head_t *ph);

-

int -
- (*func)(void - *arg, struct mbuf - **mp, struct ifnet - *, int dir);

-

int -
- pfil_run_hooks(pfil_head_t - *ph, struct mbuf - **mp, struct ifnet - *ifp, int dir);

-

int -
- pfil_add_ihook(pfil_ifunc_t - ifunc, void *arg, - int flags, - pfil_head_t *ph);

-

int -
- pfil_remove_ihook(pfil_ifunc_t - ifunc, void *arg, - int flags, - pfil_head_t *ph);

-

void -
- (*ifunc)(void - *arg, unsigned long - cmd, void - *ptr);

-

void -
- pfil_run_addrhooks(pfil_head_t - *ph, unsigned long, - struct ifaddr *ifa);

-

void -
- pfil_run_ifhooks(pfil_head_t - *ph, unsigned long, - struct ifnet *ifp);

-
-
-

-

The pfil framework allows for a specified - function to be invoked for every incoming or outgoing packet for a - particular network I/O stream. These hooks may be used to implement a - firewall or perform packet transformations.

-

Packet filtering points are created with - (). - Filtering points are identified by a data link (int) - type and a (void *) - key. If a packet filtering point already exists for - that data link type and key then - the pfil_head_create() function returns - NULL. Packet filters use the - () - function specifying the data link type and the - key to look up the filtering point with which they - register themselves. The key is unique to the - filtering point. The data link type is a - bpf(4) - DLT_type constant indicating - what kind of header is present on the packet at the filtering point. - Filtering points may be destroyed with the - () - function.

-

Packet filters register/unregister themselves - with a filtering point with the - () - and - () - functions, respectively. The head is looked up using the - () - function, which takes the data link type and the - key that the packet filter expects. Filters may - provide an argument to be passed to the filter when invoked on a packet.

-

When a filter is invoked, the packet appears just as if it - “came off the wire”. That is, all protocol fields are in - network byte order. The filter is called with its specified argument, the - pointer to the pointer to the mbuf containing the packet, the pointer to the - network interface that the packet is traversing, and the direction (either - PFIL_IN or PFIL_OUT, see - also below) that the packet is traveling. The filter may change which mbuf - the mbuf ** argument references. The filter returns an - errno if the packet processing is to stop, or 0 if the processing is to - continue. If the packet processing is to stop, it is the responsibility of - the filter to free the packet.

-

The flags parameter, - used in the - () - and - () - functions, indicates when the filter should be called. The flags are:

-

-
-
-
-
call me on incoming packets
-
-
call me on outgoing packets
-
-
call me on all of the above
-
-
-

By the same token, event handlers - register/unregister themselves with the - () - and - () - functions, respectively. The event handler is called with its specified - argument, the event id (either PFIL_IFNET_ATTACH or - PFIL_IFNET_DETACH, see also below) or ioctl number, - and the pointer to the network interface or the pointer to the ifaddr.

-

The flags parameter, - used in the - () - and - () - functions, indicates when the filter should be called. The flags are:

-

-
-
-
-
call me on interface reconfig (cmd is ioctl #)
-
-
call me on interface attach/detach (cmd is either - PFIL_IFNET_ATTACH or - PFIL_IFNET_DETACH)
-
-
-
-
-

-

bpf(4)

-
-
-

-

The pfil interface first appeared in - NetBSD 1.3. The pfil input - and output lists were originally implemented as - <sys/queue.h> - LIST structures; however this was changed in - NetBSD 1.4 to TAILQ - structures. This change was to allow the input and output filters to be - processed in reverse order, to allow the same path to be taken, in or out of - the kernel.

-

The pfil interface was changed in 1.4T to - accept a 3rd parameter to both pfil_add_hook() and - pfil_remove_hook(), introducing the capability of - per-protocol filtering. This was done primarily in order to support - filtering of IPv6.

-

In 1.5K, the pfil framework was changed to - work with an arbitrary number of filtering points, as well as be less - IP-centric.

-

pfil_add_ihook() and - pfil_remove_ihook() were added in - NetBSD 8.0.

-
-
-

-

The pfil interface was designed and - implemented by Matthew R. Green, with help from - Darren Reed, Jason R. - Thorpe, and Charles M. Hannum. - Darren Reed added support for IPv6 in addition to - IPv4. Jason R. Thorpe added support for multiple - hooks and other clean up.

-
-
-

-

The current pfil implementation will need - changes to suit a threaded kernel model.

-
-
- - - - - -
January 15, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/physio.9 3.html b/static/netbsd/man9/physio.9 3.html deleted file mode 100644 index 6f566d57..00000000 --- a/static/netbsd/man9/physio.9 3.html +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - -
PHYSIO(9)Kernel Developer's ManualPHYSIO(9)
-
-
-

-

physio — initiate - I/O on raw devices

-
-
-

-

int -
- physio(void (*strategy)(buf_t - *), buf_t *bp, dev_t dev, - int flags, void (*minphys)(buf_t - *), struct uio *uio);

-
-
-

-

The - () - is a helper function typically called from character device read and write - routines to start I/O on a user process buffer. It calls back on the - provided strategy routine one or more times to - complete the transfer described by uio. The maximum - amount of data to transfer with each call to strategy - is determined by the minphys routine.

-

Since uio normally describes - user space addresses, - () - needs to lock the appropriate data area into memory before each transaction - with strategy (see uvm_vslock(9) and - uvm_vsunlock(9)). The physio() - function always awaits the completion of the entire requested transfer - before returning, unless an error condition is detected earlier. In all - cases, the buffer passed in bp is locked (marked as - “busy”) for the duration of the entire transfer.

-

A break-down of the arguments follows:

-
-
strategy
-
The device strategy routine to call for each chunk of data to initiate - device I/O.
-
bp
-
The buffer to use with the strategy routine. The buffer flags will have - B_BUSY, B_PHYS, and - B_RAW set when passed to the strategy routine. If - NULL, a buffer is allocated from a system - pool.
-
dev
-
The device number identifying the device to interact with.
-
flags
-
Direction of transfer; the only valid settings are - B_READ or B_WRITE.
-
minphys
-
A device specific routine called to determine the maximum transfer size - that the device's strategy routine can handle.
-
uio
-
The description of the entire transfer as requested by the user process. - Currently, the results of passing a uio structure - with the ‘uio_segflg’ set to anything other than - UIO_USERSPACE, are undefined.
-
-
-
-

-

If successful physio() returns 0. - EFAULT is returned if the address range described by - uio is not accessible by the requesting process. - physio() will return any error resulting from calls - to the device strategy routine, by examining the - B_ERROR buffer flag and the ‘b_error’ - field. Note that the actual transfer size may be less than requested by - uio if the device signals an “end of - file” condition.

-
-
-

-

read(2), write(2)

-
-
- - - - - -
September 12, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/pmatch.9 3.html b/static/netbsd/man9/pmatch.9 3.html deleted file mode 100644 index 54a90803..00000000 --- a/static/netbsd/man9/pmatch.9 3.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
PMATCH(9)Kernel Developer's ManualPMATCH(9)
-
-
-

-

pmatch — performs - pattern matching on strings

-
-
-

-

#include - <sys/systm.h>

-

int -
- pmatch(const - char *string, const char - *pattern, const char - **estr);

-
-
-

-

Extract substring matching pattern from - string. If not NULL, - estr points to the end of the longest exact or - substring match.

-

() - uses the following metacharacters:

-
-
-
match any single character.
-
-
match any character 0 or more times.
-
-
define a range of characters that will match. The range is defined by 2 - characters separated by a ‘-’. The - range definition has to end with a - ‘]’. A - ‘^’ following the - ‘[’ will negate the range.
-
-
-
-

-

pmatch() will return 2 for an exact match, - 1 for a substring match, 0 for no match and -1 if an error occurs.

-
-
- - - - - -
October 12, 2003NetBSD 10.1
diff --git a/static/netbsd/man9/pmf.9 3.html b/static/netbsd/man9/pmf.9 3.html deleted file mode 100644 index d9e091dd..00000000 --- a/static/netbsd/man9/pmf.9 3.html +++ /dev/null @@ -1,320 +0,0 @@ - - - - - - -
PMF(9)Kernel Developer's ManualPMF(9)
-
-
-

-

PMF, - pmf_device_register, - pmf_device_register1, - pmf_device_deregister, - pmf_device_suspend, - pmf_device_resume, - pmf_device_recursive_suspend, - pmf_device_recursive_resume, - pmf_device_resume_subtree, - pmf_class_network_register, - pmf_class_input_register, - pmf_class_display_register, - pmf_system_suspend, - pmf_system_resume, - pmf_system_shutdown, - pmf_event_register, - pmf_event_deregister, - pmf_event_inject, - pmf_set_platform, - pmf_get_platform — power - management and inter-driver messaging framework

-
-
-

-

#include - <sys/device.h>

-

bool -
- pmf_device_register(device_t - dev, bool - (*suspend)(device_t dev, const pmf_qual_t *qual), - bool (*resume)(device_t dev, - const pmf_qual_t *qual));

-

bool -
- pmf_device_register1(device_t - dev, bool - (*suspend)(device_t dev, const pmf_qual_t *qual), - bool (*resume)(device_t dev, - const pmf_qual_t *qual), - bool (*shutdown)(device_t dev, - int how));

-

void -
- pmf_device_deregister(device_t - dev);

-

bool -
- pmf_device_suspend(device_t - dev, const pmf_qual_t - *qual);

-

bool -
- pmf_device_resume(device_t - dev, const pmf_qual_t - *qual);

-

bool -
- pmf_device_recursive_suspend(device_t - dev, const pmf_qual_t - *qual);

-

bool -
- pmf_device_recursive_resume(device_t - dev, const pmf_qual_t - *qual);

-

bool -
- pmf_device_subtree_resume(device_t - dev, const pmf_qual_t - *qual);

-

void -
- pmf_class_network_register(device_t - dev, struct ifnet - *ifp);

-

bool -
- pmf_class_input_register(device_t - dev);

-

bool -
- pmf_class_display_register(device_t - dev);

-

bool -
- pmf_system_suspend(const - pmf_qual_t *qual);

-

bool -
- pmf_system_resume(const - pmf_qual_t *qual);

-

void -
- pmf_system_shutdown(int);

-

bool -
- pmf_event_register(device_t - dev, pmf_generic_event_t - ev, void - (*handler)(device_t dev), - bool global);

-

void -
- pmf_event_deregister(device_t - dev, pmf_generic_event_t - ev, void - (*handler)(device_t dev), - bool global);

-

bool -
- pmf_event_inject(device_t - dev, pmf_generic_event_t - ev);

-

bool -
- pmf_set_platform(const - char *key, const char - *value);

-

const char * -
- pmf_get_platform(const - char *key);

-
-
-

-

The machine-independent PMF framework - provides power management and inter-driver messaging support for device - drivers.

-
-
-

-

Drivers for devices implementing PMF may - make use of the following data type:

-
-
pmf_qual_t
-
An opaque aggregate of qualifications on a PMF - suspend or resume call.
-
pmf_generic_event_t
-
A device driver can register as a listener for specific events, or inject - events into the message queue. The following message types are defined: - -
-
-
-
-

-
-
(dev, - suspend, resume)
-
Register a device with the power management framework. The - suspend and resume functions - are passed dev and a - pmf_qual_t, and will be called when the system state - changes; they should return true on success and - false on failure. If either - suspend or resume is - NULL then it is assumed that device state does not - need to be captured and resumed on a power transition. Bus and class-level - power management will still be performed. -

() - always returns true. Callers should ignore the return value.

-
-
pmf_device_register1(dev, - suspend, resume, - shutdown)
-
Like pmf_device_register(), but additionally - registers a shutdown handler. During system shutdown, - () - calls shutdown on dev with the - reboot(2) “howto” in the second argument. - shutdown should return true - on success and false on failure. -

() - always returns true. Callers should ignore the return value.

-
-
(dev)
-
Deregister a device with the power management framework.
-
(dev, - qual)
-
Suspend a device by first calling the class suspend handler, followed by - the driver suspend handler, and finally the bus suspend handler.
-
(dev, - qual)
-
Resume a device by first calling the bus resume handler, followed by the - driver resume handler, and finally the class resume handler.
-
(dev, - qual)
-
As pmf_device_suspend(), but ensures that all - child devices of dev are suspended.
-
(dev, - qual)
-
As pmf_device_resume(), but ensures that all - parent devices of dev are resumed.
-
(dev, - qual)
-
As pmf_device_resume(), but ensures that all child - devices of dev are resumed.
-
(dev, - ifp)
-
Register a device with the power management framework as a network-class - device.
-
(dev)
-
Register a device with the power management framework as an input-class - device.
-
(dev)
-
Register a device with the power management framework as a display-class - device.
-
(qual)
-
Suspend all attached devices. Devices are suspended by traversing the - autoconfiguration tree beginning with the leaf nodes. This function will - fail if any attached drivers do not support the power management - framework.
-
(qual)
-
Resume all attached devices. Devices are resumed by traversing the - autoconfiguration tree beginning with devices that do not have a parent. - This function will fail if any attached drivers do not support the power - management framework.
-
pmf_system_shutdown(int)
-
Shutdown all attached devices. Devices are shut down by traversing the - autoconfiguration tree beginning with the leaf nodes. The integer argument - is passed to the driver shutdown functions. It should contain the - reboot(2) “howto” argument. This function - ignores the presence of attached drivers that do not support the power - management framework.
-
(dev, - ev, handler, - global)
-
Register the callback handler to be called whenever - an ev event is triggered. If - global is true, - handler accepts anonymous events from - ().
-
(dev, - ev, handler, - global)
-
Deregister the callback previously registered with - pmf_event_register().
-
pmf_event_inject(dev, - ev)
-
Inject an inter-driver message into the message queue. If - dev is NULL, the event is - considered to be anonymous and one or more drivers may handle this event, - otherwise the event is delivered directly to the callback registered by - dev.
-
(key, - value)
-
Insert a name-value pair into the platform information database.
-
(key)
-
Retrieve the value for key from the platform - information database. Returns NULL if the key is - not present.
-
-
-
-

-

The power management framework is implemented within the files - sys/sys/pmf.h, - sys/sys/device.h, - sys/kern/kern_pmf.c, and - sys/kern/subr_autoconf.c.

-
-
-

-

autoconf(9), driver(9)

-
-
-

-

The PMF framework appeared in - NetBSD 5.0.

-
-
-

-

Jared D. McNeill - <jmcneill@NetBSD.org> -
- Joerg Sonnenberger - <joerg@NetBSD.org>

-
-
-

-

pmf_device_register() and - pmf_device_register1() never fail and should return - void, but until all callers are updated to ignore the return value, they - must continue to return bool: - PR kern/57575

-
-
- - - - - -
March 9, 2024NetBSD 10.1
diff --git a/static/netbsd/man9/proc_find.9 3.html b/static/netbsd/man9/proc_find.9 3.html deleted file mode 100644 index 7f11e854..00000000 --- a/static/netbsd/man9/proc_find.9 3.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - -
PROC_FIND(9)Kernel Developer's ManualPROC_FIND(9)
-
-
-

-

proc_find, - pgrp_find — find process or - process group

-
-
-

-

#include - <sys/proc.h>

-

struct proc * -
- proc_find(pid_t - pid);

-

struct pgrp * -
- pgrp_find(pid_t - pgid);

-

extern kmutex_t *proc_lock;

-
-
-

-

The - () - and - () - functions retrieve process and process group structures from process ID - pid and process group ID pgid. - Both functions must be called by holding a mutex(9) on - proc_lock.

-
-
-

-

Upon successful completion, the described functions return a - pointer to either struct proc or struct - pgrp. Otherwise, if the requested ID was not found, - NULL is returned.

-
-
-

-

curproc(9)

-
-
- - - - - -
July 1, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/pserialize.9 3.html b/static/netbsd/man9/pserialize.9 3.html deleted file mode 100644 index 151a711b..00000000 --- a/static/netbsd/man9/pserialize.9 3.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - -
PSERIALIZE(9)Kernel Developer's ManualPSERIALIZE(9)
-
-
-

-

pserialize — - passive serialization mechanism

-
-
-

-

#include - <sys/pserialize.h>

-

pserialize_t -
- pserialize_create(void);

-

void -
- pserialize_destroy(pserialize_t - psz);

-

int -
- pserialize_read_enter(void);

-

void -
- pserialize_read_exit(int - s);

-

void -
- pserialize_perform(pserialize_t - psz);

-
-
-

-

Passive serialization is a reader / writer synchronisation - mechanism designed for lock-less read operations. The read operations may - happen from software interrupt at IPL_SOFTCLOCK.

-
-
-

-
-
()
-
Allocate a new synchronisation object.
-
()
-
Destroy the synchronisation object. No synchronisation activity should - happen at this point.
-
()
-
Enter the critical path of the reader side. Returns an IPL value, which - must be passed to pserialize_read_exit(9). Protected - code path is not allowed to block.
-
()
-
Exit the critical path of the reader side. Takes the IPL value returned by - pserialize_read_enter(9).
-
()
-
Perform the passive serialization on the writer side. Passing of this - function ensures that no readers are in action. Writers are typically - additionally serialized with a separate mechanism, e.g. - mutex(9), to remove objects used by readers from a - published list. Operation blocks and it may only be performed from thread - context.
-
-
-
-

-

Given a global database of frotz records:

-
-
	struct frotz {
-		...
-		struct frotz	*f_next;
-	};
-
-	static struct {
-		kmutex_t	lock;
-		pserialize_t	psz;
-		struct frotz	*first;
-	} frobbotzim __cacheline_aligned;
-
-

Create a frotz and publish it, as a writer:

-
-
	struct frotz *f = pool_get(&frotz_pool, PR_WAITOK);
-
-	/* Initialize f.  */
-	...
-
-	mutex_enter(&frobbotzim.lock);
-	f->f_next = frobbotzim.first;
-	/*
-	 * Publish the contents of f->f_next before we publish the
-	 * pointer to f in frobbotzim.first.
-	 */
-	atomic_store_release(&frobbotzim.first, f);
-	mutex_exit(&frobbotzim.lock);
-
-

Find a frotz, as a reader:

-
-
	struct frotz *f;
-	int error = ENOENT;
-	int s;
-
-	s = pserialize_read_enter();
-	/* Fetch frobbotzim.first before we fetch anything it point to.  */
-	for (f = atomic_load_consume(&frobbotzim.first);
-	     f != NULL;
-	     f = f->f_next) {
-		if (f->f_... == key) {
-			/*
-			 * Grab whatever part of the frotz we need.
-			 * Note that we can't use the frotz after
-			 * pserialize_read_exit, without a stronger
-			 * kind of reference, say a reference count
-			 * managed by atomic_ops(3).
-			 */
-			*resultp = f->f_...;
-			error = 0;
-			break;
-		}
-	}
-	pserialize_read_exit(s);
-
-	return error;
-
-

Remove a frotz, as a writer, and free it once there are no more - readers:

-
-
	struct frotz **fp, *f;
-
-	mutex_enter(&frobbotzim.lock);
-	for (fp = &frobbotzim.first; (f = *fp) != NULL; fp = &f->f_next) {
-		if (f->f_... == key) {
-			/*
-			 * Unhook it from the list.  Readers may still
-			 * be traversing the list at this point, so
-			 * the next pointer must remain valid and
-			 * memory must remain allocated.
-			 */
-			*fp = f->f_next;
-			break;
-		}
-	}
-	mutex_exit(&frobbotzim.lock);
-
-	/*
-	 * Wait for all existing readers to complete.  New readers will
-	 * not see f because the list no longer points to it.
-	 */
-	pserialize_perform(frobbotzim.psz);
-
-	/* Now nobody else can be touching f, so it is safe to free.  */
-	if (f != NULL)
-		pool_put(&frotz_pool, f);
-
-
-
-

-

The pserialize is implemented within the - file sys/kern/subr_pserialize.c.

-
-
-

-

membar_ops(3), condvar(9), - mutex(9), rwlock(9)

-

Hennessy, et al., - Passive serialization in a multitasking - environment, US Patent and Trademark Office, - US Patent 4809168, February 28, - 1989.

-
-
-

-

Passive serialization mechanism first appeared in - NetBSD 6.0.

-
-
- - - - - -
January 26, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/pslist.9 3.html b/static/netbsd/man9/pslist.9 3.html deleted file mode 100644 index 9aa95f84..00000000 --- a/static/netbsd/man9/pslist.9 3.html +++ /dev/null @@ -1,386 +0,0 @@ - - - - - - -
PSLIST(9)Kernel Developer's ManualPSLIST(9)
-
-
-

-

pslist — - pserialize-safe linked lists

-
-
-

-

#include - <sys/pslist.h>

-

struct pslist_head head = - PSLIST_INITIALIZER; -
- struct pslist_entry entry = - PSLIST_ENTRY_INITIALIZER;

-

void -
- PSLIST_INIT(struct - pslist_head *head);

-

void -
- PSLIST_DESTROY(struct - pslist_head *head);

-

void -
- PSLIST_ENTRY_INIT(TYPE - *element, PSLIST_ENTRY - NAME);

-

void -
- PSLIST_ENTRY_DESTROY(TYPE - *element, PSLIST_ENTRY - NAME);

-

void -
- PSLIST_WRITER_INSERT_HEAD(struct - pslist_head *head, TYPE - *new, PSLIST_ENTRY - NAME);

-

void -
- PSLIST_WRITER_INSERT_BEFORE(TYPE - *element, TYPE - *new, PSLIST_ENTRY - NAME);

-

void -
- PSLIST_WRITER_INSERT_AFTER(TYPE - *element, TYPE - *new, PSLIST_ENTRY - NAME);

-

void -
- PSLIST_WRITER_REMOVE(TYPE - *element, PSLIST_ENTRY - NAME);

-

TYPE * -
- PSLIST_WRITER_FIRST(const - struct pslist *head, - TYPE, - PSLIST_ENTRY NAME);

-

TYPE * -
- PSLIST_WRITER_NEXT(const - TYPE *element, - TYPE, - PSLIST_ENTRY NAME);

-

PSLIST_WRITER_FOREACH(const - TYPE *element, const - struct pslist_head *head, - TYPE, - PSLIST_ENTRY NAME);

-

TYPE * -
- PSLIST_READER_FIRST(const - struct pslist *head, - TYPE, - PSLIST_ENTRY NAME);

-

TYPE * -
- PSLIST_READER_NEXT(const - TYPE *element, - TYPE, - PSLIST_ENTRY NAME);

-

PSLIST_READER_FOREACH(const - TYPE *element, const - struct pslist_head *head, - TYPE, - PSLIST_ENTRY NAME);

-
-
-

-

The pslist data structure is a linked list - like list in queue(3). It is - augmented with memory barriers so that any number of readers can safely run - in parallel with at most one writer, without needing any interprocessor - synchronization such as locks or atomics on the reader side.

-

The head of a linked list is represented by a - struct pslist_head object allocated by the caller, - e.g. by embedding it in another struct, which should be otherwise treated as - opaque. A linked list head must be initialized with - PSLIST_INITIALIZER or - () - before it may be used. When initialized, a list head represents an empty - list. A list should be empty and destroyed with - () - before the struct pslist_head object's memory is - reused.

-

Each entry in a linked list is represented by a - struct pslist_entry object, also opaque, and embedded - as a member in a caller-allocated structure called an - . A - struct pslist_entry object must be initialized with - PSLIST_ENTRY_INITIALIZER or - () - before it may be used.

-

When initialized, a list entry is - unassociated. Inserting an entry associates it with a particular list. - Removing it partially disassociates it from that list and prevents new - readers from finding it in the list, but allows extant parallel readers to - continue reading the next entry. The caller must then wait, e.g. with - pserialize_perform(9), for all extant parallel readers to - finish, before destroying the list entry with - () - and then freeing or reusing its memory.

-
-
-

-

The following operations may be performed on list heads and - entries when the caller has exclusive access to them — no parallel - writers or readers may have access to the same objects.

-
-
-
Constant initializer for a struct pslist_head - object.
-
PSLIST_INIT(head)
-
Initialize the list headed by head to be empty.
-
PSLIST_DESTROY(head)
-
Destroy the list headed by head, which must be - empty. -

This has an effect only with the - DIAGNOSTIC option, so it is not strictly - necessary, but it can help to detect bugs early; see - KASSERT(9).

-
-
-
Constant initializer for an unassociated struct - pslist_entry object.
-
(element, - NAME)
-
Initialize the struct pslist_entry object - element->NAME.
-
PSLIST_ENTRY_DESTROY(element, - NAME)
-
Destroy the struct pslist_entry object - element->NAME. - Either element must never have been inserted into a - list, or it must have been inserted and removed, and the caller must have - waited for all parallel readers to finish reading it first.
-
-
-
-

-

The following operations may be performed on list heads and - entries when the caller has exclusive - - access to them — parallel readers for the same objects are allowed, - but no parallel writers.

-
-
(head, - element, NAME)
-
Insert the element element at the beginning of the - list headed by head, before any existing elements in - the list. -

The object - element->NAME - must be a struct pslist_entry object which has - been initialized but not inserted.

-
-
(element, - new, NAME)
-
Insert the element new into a list before the - element element. -

The object - element->NAME - must be a struct pslist_entry object which has - been inserted into a list. The object - new->NAME - must be a struct pslist_entry

-
-
(element, - new, NAME)
-
Insert the element new into a list after the element - element. -

The object - element->NAME - must be a struct pslist_entry object which has - been inserted into a list. The object - new->NAME - must be a struct pslist_entry

-
-
(element, - NAME)
-
Remove the element element from the list into which - it has been inserted. -

The object - element->NAME - must be a struct pslist_entry object which has - been inserted into a list.

-
-
(head, - type, NAME)
-
Return a pointer to the first element o of type - type with a struct - pslist_entry member - o->NAME, - or NULL if the list is empty.
-
(element, - type, NAME)
-
Return a pointer to the next element o of type - type with a struct - pslist_entry member - o->NAME - after element in a list, or - NULL if there are no elements after - element.
-
(element, - head, type, - NAME)
-
Loop header for iterating over each element element - of type type with struct - pslist_entry member - element->NAME - starting at the list head head. -

The caller must not modify the list while iterating over - it.

-
-
-
-
-

-

The following operations may be performed on list heads and - entries when the caller is in a passively serialized read section — - see pserialize(9).

-
-
(head, - type, NAME)
-
Return a pointer to the first element o of type - type with a struct - pslist_entry member - o->NAME, - or NULL if the list is empty.
-
(element, - type, NAME)
-
Return a pointer to the next element o of type - type with a struct - pslist_entry member - o->NAME - after element in a list, or - NULL if there are no elements after - element.
-
(element, - head, type, - NAME)
-
Loop header for iterating over each element element - of type type with struct - pslist_entry member - element->NAME - starting at the list head head.
-
-
-
-

-

Example frotz structure and global state:

-
-
	struct frotz {
-		uint64_t		f_key;
-		uint64_t		f_datum;
-		struct pslist_entry	f_entry;
-	};
-
-	static struct {
-		kmutex_t		lock;
-		pserialize_t		psz;
-		struct pslist_head	list;
-		struct pool		pool;
-	} frobnitzem __cacheline_aligned;
-
-

Initialize the global state:

-
-
	mutex_init(&frobnitzem.lock, MUTEX_DEFAULT, IPL_NONE);
-	frobnitzem.psz = pserialize_create();
-	PSLIST_INIT(&frobnitzem.list);
-	pool_init(&frobnitzem.pool, sizeof(struct frotz), ...);
-
-

Create and publish a frotz:

-
-
	uint64_t key = ...;
-	uint64_t datum = ...;
-
-	struct frotz *f = pool_get(&frobnitzem.pool, PR_WAITOK);
-
-	/* Initialize f.  */
-	f->f_key = key;
-	f->f_datum = datum;
-	PSLIST_ENTRY_INIT(f, f_entry);
-
-	/* Publish it.  */
-	mutex_enter(&frobnitzem.lock);
-	PSLIST_WRITER_INSERT_HEAD(&frobnitzem.list, f, f_entry);
-	mutex_exit(&frobnitzem.lock);
-
-

Look up a frotz and return its associated datum:

-
-
	uint64_t key = ...;
-	struct frotz *f;
-	int error = ENOENT;
-	int s;
-
-	s = pserialize_read_enter();
-	PSLIST_READER_FOREACH(f, &frobnitzem.list, struct frotz, f_entry) {
-		if (f->f_key == key) {
-			*datump = f->f_datum;
-			error = 0;
-			break;
-		}
-	}
-	pserialize_read_exit(s);
-	return error;
-
-

Remove a frotz and wait for readers to finish using it before - reusing the memory allocated for it:

-
-
	struct frotz *f = ...;
-
-	mutex_enter(&frobnitzem.lock);
-	PSLIST_WRITER_REMOVE(f, f_entry);
-	mutex_exit(&frobnitzem.lock);
-
-	pserialize_perform(&frobnitzem.psz);
-
-	PSLIST_ENTRY_DESTROY(f, f_entry);
-	pool_put(&frobnitzem.pool, f);
-
-
-
-

-

The pslist data structure is implemented - by static inlines and macros in - sys/sys/pslist.h.

-
-
-

-

queue(3), pserialize(9), - psref(9)

-
-
-

-

The pslist data structure first appeared - in NetBSD 8.0.

-
-
-

-

Taylor R Campbell - <riastradh@NetBSD.org>

-
-
- - - - - -
July 7, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/ras.9 3.html b/static/netbsd/man9/ras.9 3.html deleted file mode 100644 index defc6050..00000000 --- a/static/netbsd/man9/ras.9 3.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - -
RAS(9)Kernel Developer's ManualRAS(9)
-
-
-

-

ras_lookup, - ras_fork, ras_purgeall - — restartable atomic sequences

-
-
-

-

#include - <sys/types.h> -
- #include <sys/proc.h> -
- #include <sys/ras.h>

-

void * -
- ras_lookup(struct - proc *p, void - *addr);

-

int -
- ras_fork(struct - proc *p1, struct proc - *p2);

-

int -
- ras_purgeall(struct - proc *p);

-
-
-

-

Restartable atomic sequences are user code sequences which are - guaranteed to execute without preemption. This property is assured by - checking the set of restartable atomic sequences registered for a process - during cpu_switchto(9). If a process is found to have been - preempted during a restartable sequence, then its execution is rolled-back - to the start of the sequence by resetting its program counter saved in its - process control block (PCB).

-

The RAS functionality is provided by a combination of the - machine-independent routines discussed in this page and a machine-dependent - component in cpu_switchto(9). A port which supports - restartable atomic sequences will define __HAVE_RAS - in <machine/types.h> for - machine-independent code to conditionally provide RAS support.

-

A complicated side-effect of restartable atomic sequences is their - interaction with the machine-dependent ptrace(2) support. - Specifically, single-step traps and/or the emulation of single-stepping must - carefully consider the effect on restartable atomic sequences. A general - solution is to ignore these traps or disable them within restartable atomic - sequences.

-
-
-

-

The functions which operate on restartable atomic sequences - are:

-
-
(p, - addr)
-
This function searches the registered restartable atomic sequences for - process p which contain the user address - addr. If the address addr is - found within a RAS, then the restart address of the RAS is returned, - otherwise -1 is returned.
-
(p1, - p2)
-
This function is used to copy all registered restartable atomic sequences - for process p1 to process p2. - It is primarily called from fork1(9) when the sequences - are inherited from the parent by the child.
-
(p)
-
This function is used to remove all registered restartable atomic - sequences for process p. It is primarily used to - remove all registered restartable atomic sequences for a process during - exec(3) and by rasctl(2).
-
-
-
-

-

The RAS framework itself is implemented within the file - sys/kern/kern_ras.c. Data structures and function - prototypes for the framework are located in - <sys/ras.h>. - Machine-dependent portions are implemented within - cpu_switchto(9) in the machine-dependent file - sys/arch/<arch>/<arch>/locore.S.

-
-
-

-

rasctl(2), cpu_switchto(9), - fork1(9)

-

Gregory McGarry, - An Implementation of User-level Restartable Atomic - Sequences on the NetBSD Operating System, Proceedings - of the FREENIX Track: 2003 USENIX Annual Technical Conference, - USENIX Association, - http://www.usenix.org/publications/library/proceedings/usenix03/tech/freenix03/full_papers/mcgarry/mcgarry.pdf, - 311-322, June 9-14, - 2003.

-
-
-

-

The RAS functionality first appeared in NetBSD - 2.0.

-
-
- - - - - -
April 17, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/roundup.9 3.html b/static/netbsd/man9/roundup.9 3.html deleted file mode 100644 index a0cfeb99..00000000 --- a/static/netbsd/man9/roundup.9 3.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - -
ROUNDUP(9)Kernel Developer's ManualROUNDUP(9)
-
-
-

-

roundup — macros - for counting and rounding

-
-
-

-

#include - <sys/param.h>

-

size -
- howmany(x, - size);

-

size -
- roundup(x, - size);

-

size -
- rounddown(x, - size);

-

size -
- roundup2(x, - size);

-

size -
- rounddown2(x, - size);

-

int -
- powerof2(x);

-
-
-

-

The - () - and - () - macros return an integer from rounding x up and down, - respectively, to the next size. The - () - macro in turn reveals how many times size fits into - x, rounding the residual up.

-

The - () - and - () - macros also round up and down, respectively, but with the assumption that - size is a power of two. If x is - indeed a power of two, - () - return 1.

-
-
-

-

The return value is an integer from the respective operation. If - x is 0, all macros except - powerof2() return 0. The behavior is undefined if - size is 0.

-
-
-

-

The following example rounds the variable rx - to a 32-bit boundary:

-
-
uint16_t rx;
-
-...
-
-rx = roundup2(rx, sizeof(uint32_t));
-
-
-
-

-

ilog2(3), param(3), - imax(9)

-
-
-

-

All described macros make no assumptions about the type of the - parameters. These are implicitly assumed to be unsigned integers.

-
-
- - - - - -
October 2, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/rwlock.9 3.html b/static/netbsd/man9/rwlock.9 3.html deleted file mode 100644 index 239ed9ad..00000000 --- a/static/netbsd/man9/rwlock.9 3.html +++ /dev/null @@ -1,256 +0,0 @@ - - - - - - -
RWLOCK(9)Kernel Developer's ManualRWLOCK(9)
-
-
-

-

rw, rw_init, - rw_destroy, rw_enter, - rw_exit, rw_tryenter, - rw_tryupgrade, rw_downgrade, - rw_read_held, rw_write_held, - rw_lock_held, rw_lock_op - — reader / writer lock primitives

-
-
-

-

#include - <sys/rwlock.h>

-

void -
- rw_init(krwlock_t - *rw);

-

void -
- rw_destroy(krwlock_t - *rw);

-

void -
- rw_enter(krwlock_t - *rw, const krw_t - op);

-

void -
- rw_exit(krwlock_t - *rw);

-

int -
- rw_tryenter(krwlock_t - *rw, const krw_t - op);

-

int -
- rw_tryupgrade(krwlock_t - *rw);

-

void -
- rw_downgrade(krwlock_t - *rw);

-

int -
- rw_read_held(krwlock_t - *rw);

-

int -
- rw_write_held(krwlock_t - *rw);

-

int -
- rw_lock_held(krwlock_t - *rw);

-

krw_t -
- rw_lock_op(krwlock_t - *rw);

-

-
- options DIAGNOSTIC -
- options LOCKDEBUG

-
-
-

-

Reader / writer locks (RW locks) are used in the kernel to - synchronize access to an object among LWPs (lightweight processes) and soft - interrupt handlers.

-

In addition to the capabilities provided by mutexes, RW locks - distinguish between read (shared) and write (exclusive) access.

-

RW locks are in one of three distinct states at any given - time:

-
-
-
The lock is not held.
-
-
The lock holders intend to read the protected object. Multiple callers may - hold a RW lock with “read intent” simultaneously.
-
-
The lock holder intends to update the protected object. Only one caller - may hold a RW lock with “write intent”.
-
-

The krwlock_t type provides storage for the - RW lock object. This should be treated as an opaque object and not examined - directly by consumers.

-

Note that these interfaces must not be used from a hardware - interrupt handler.

-
-
-

-
-
options DIAGNOSTIC
-
-

Kernels compiled with the DIAGNOSTIC - option perform basic sanity checks on RW lock operations.

-
-
options LOCKDEBUG
-
-

Kernels compiled with the LOCKDEBUG - option perform potentially CPU intensive sanity checks on RW lock - operations.

-
-
-
-
-

-
-
(rw)
-
-

Initialize a lock for use. No other operations can be - performed on the lock until it has been initialized.

-
-
(rw)
-
-

Release resources used by a lock. The lock may not be used - after it has been destroyed.

-
-
(rw, - op)
-
-

If RW_READER is specified as the - argument to op, acquire a read lock. The caller - may block and will not return until the hold is acquired. Callers must - not recursively acquire read locks.

-

If RW_WRITER is specified, acquire a - write lock. If the lock is already held, the caller will block and not - return until the hold is acquired.

-

RW locks and other types of locks must always be acquired in a - consistent order with respect to each other. Otherwise, the potential - for system deadlock exists.

-
-
(rw)
-
-

Release a lock. The lock must have been previously acquired by - the caller.

-
-
(rw, - op)
-
-

Try to acquire a lock, but do not block if the lock is already - held. If the lock is acquired successfully, return non-zero. Otherwise, - return zero.

-

Valid arguments to op are - RW_READER or - RW_WRITER.

-
-
(rw)
-
-

Try to upgrade a lock from one read hold to a write hold. If - the lock is upgraded successfully, returns non-zero. Otherwise, returns - zero.

-
-
(rw)
-
-

Downgrade a lock from a write hold to a read hold.

-
-
(rw)
-
-

Return non-zero if write lock is held by current lwp. - Otherwise, return zero.

-
-
(rw)
-
-

Returns non-zero if read lock is held by any lwp. Otherwise, - return zero.

-
-
(rw)
-
-

Returns non-zero if either read or write lock is held by any - lwp. Otherwise, return zero.

-

(), - rw_read_held(), and - rw_lock_held() should not generally be used to - make locking decisions at run time: they are provided for diagnostic - purposes, for example making assertions.

-

Negative assertions (lock not held) - should not be made due to atomicity issues, excepting - (), - which can safely be used to assert that a write lock is NOT held by the - current LWP.

-
-
(rw)
-
-

For a lock that is known to be held by the calling LWP, return - either RW_READER or - RW_WRITER to denote the type of hold. This is - useful when dropping and later re-acquiring a lock, if the type of hold - is not already known.

-
-
-
-
-

-

RW locks are subject to high cache contention on multiprocessor - systems, and scale poorly when the write:read ratio is not strongly in - favour of readers. Ideally, RW locks should only be used in settings when - the following three conditions are met:

-
    -
  • The data object(s) protected by the RW lock are read much more frequently - than written.
    • -
  • The read-side hold time for the RW lock is long (in the order of thousands - of processor clock cycles).
    • -
  • Strong synchronization semantics are required: there is no scope for - lockless, lazy or optimistic synchronization.
    • -
-

Generally speaking, it is better to organise code paths and/or - data flows such that fewer and weaker synchronization points are required to - ensure correct operation.

-
-
-

-

The core of the RW lock implementation is in - sys/kern/kern_rwlock.c.

-

The header file sys/sys/rwlock.h describes - the public interface, and interfaces that machine-dependent code must - provide to support RW locks.

-
-
-

-

membar_ops(3), lockstat(8), - condvar(9), mutex(9)

-

Jim Mauro and - Richard McDougall, Solaris - Internals: Core Kernel Architecture, Prentice - Hall, 2001, ISBN - 0-13-022496-0.

-
-
-

-

The RW lock primitives first appeared in NetBSD - 5.0.

-
-
- - - - - -
February 22, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/scanc.9 3.html b/static/netbsd/man9/scanc.9 3.html deleted file mode 100644 index 89cfb775..00000000 --- a/static/netbsd/man9/scanc.9 3.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - -
SCANC(9)Kernel Developer's ManualSCANC(9)
-
-
-

-

scanc — use byte - string as lookup table index

-
-
-

-

#include - <lib/libkern/libkern.h>

-

int -
- scanc(u_int - size, const u_char - *cp, const u_char - table[], int - mask);

-
-
-

-

The - () - function scans the byte string cp, whose length is - size. A character in the string is used as an index in - the 256-byte table. If a bitwise-AND of the byte from - the table and mask isn't zero or the string is - exhausted, the scan stops.

-
-
-

-

The scanc() function returns the length of - the rest of the string, including the character which made the scan stop. If - the scanc() function exhausted the string, it - returns 0.

-
-
-

-

The scanc() function emulates a VAX - instruction with the same name.

-
-
- - - - - -
April 24, 2013NetBSD 10.1
diff --git a/static/netbsd/man9/sched_4bsd.9 3.html b/static/netbsd/man9/sched_4bsd.9 3.html deleted file mode 100644 index d08d4b85..00000000 --- a/static/netbsd/man9/sched_4bsd.9 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
SCHED_4BSD(9)Kernel Developer's ManualSCHED_4BSD(9)
-
-
-

-

sched_4bsd — The - 4.4BSD thread scheduler

-
-
-

-

#include - <sys/sched.h>

-

void -
- resetpriority(lwp_t - *l);

-

void -
- sched_tick(struct - cpu_info *ci);

-

void -
- sched_schedclock(lwp_t - *l);

-

void -
- sched_pstats_hook(struct - proc *p, int - minslp);

-

void -
- sched_setrunnable(lwp_t - *l);

-

void -
- updatepri(lwp_t - *l);

-
-
-

-

The traditional 4.4BSD scheduler employs a - “multilevel feedback queues” algorithm, favouring interactive, - short-running threads to CPU-bound ones.

-

() - recomputes the priority of a thread running in user mode. If the resulting - priority is higher than that of the current thread, a reschedule is - arranged.

-

() - gets called from hardclock(9) every 100ms to force a - switch between equal priority threads.

-

The priority of the current thread is - adjusted through - (). - The priority of a thread gets worse as it accumulates CPU time.

-

() - gets called from - () - every Hz ticks in order to recompute the priorities of all threads.

-

() - checks if an LWP has slept for more than one second. If so, its priority is - updated by - ().

-
-
-

-

To determine the scheduler currently in use

-
-
$ sysctl kern.sched.name
-kern.sched.name = 4.4BSD
-
-
-
-

-

The 4.4BSD scheduler subsystem is - implemented within the file - sys/kern/sched_4bsd.c.

-
-
-

-

csf(9), hardclock(9), - mi_switch(9), sched_m2(9), - userret(9)

-

Marshall Kirk McKusick, - Keith Bostic, Michael J. - Karels, and John S. Quarterman, - The Design and Implementation of the 4.4BSD Operating - System, Addison Wesley, - 1996.

-
-
- - - - - -
April 9, 2019NetBSD 10.1
diff --git a/static/netbsd/man9/secmodel_extensions.9 3.html b/static/netbsd/man9/secmodel_extensions.9 3.html deleted file mode 100644 index e5aa5184..00000000 --- a/static/netbsd/man9/secmodel_extensions.9 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
SECMODEL_EXTENSIONS(9)Kernel Developer's ManualSECMODEL_EXTENSIONS(9)
-
-
-

-

secmodel_extensions — - extensions security model

-
-
-

-

secmodel_extensions implements extensions - to the traditional security model based on the original - 4.4BSD. They can be used to grant additional - privileges to ordinary users, or enable specific security measures like - curtain mode.

-

The extensions are described below.

-
-
-

-

When enabled, all returned objects will be filtered according to - the user-id requesting information about them, preventing users from - accessing objects they do not own.

-

It affects the output of many commands, including - fstat(1), netstat(1), - ps(1), sockstat(1), and - w(1).

-

This extension is enabled by setting - security.models.extensions.curtain or - security.curtain sysctl(7) to a - non-zero value.

-

It can be enabled at any time, but cannot be disabled anymore when - the securelevel of the system is above 0.

-
-
-

-

When enabled, it allows file-systems to be mounted by an ordinary - user who owns the point node and has at least read - access to the special device - mount(8) arguments. Note that the - nosuid and nodev flags must - be given for non-superuser mounts.

-

This extension is enabled by setting - security.models.extensions.usermount or - vfs.generic.usermount sysctl(7) to - a non-zero value.

-

It can be disabled at any time, but cannot be enabled anymore when - the securelevel of the system is above 0.

-
-
-

-

When enabled, an ordinary user is allowed to control the CPU - affinity(3) of the processes and threads they own.

-

This extension is enabled by setting - security.models.extensions.user_set_cpu_affinity - sysctl(7) to a non-zero value.

-

It can be disabled at any time, but cannot be enabled anymore when - the securelevel of the system is above 0.

-
-
-

-

Prevent hardlinks to files that the user does not own or has group - access to.

-

To enable user ownership checks, set the - sysctl(7) variable - security.models.extensions.hardlink_check_uid to a - non-zero value.

-

To enable group membership checks, set the - sysctl(7) variable - security.models.extensions.hardlink_check_gid to a - non-zero value.

-

These variables can be enabled anytime, but cannot be disabled - anymore when the securelevel of the system is above 0.

-
-
-

-

affinity(3), sched(3), - sysctl(7), kauth(9), - secmodel(9), secmodel_bsd44(9), - secmodel_securelevel(9), - secmodel_suser(9)

-
-
-

-

Elad Efrat - <elad@NetBSD.org>

-
-
- - - - - -
March 27, 2022NetBSD 10.1
diff --git a/static/netbsd/man9/signal.9 3.html b/static/netbsd/man9/signal.9 3.html deleted file mode 100644 index 6cfaf949..00000000 --- a/static/netbsd/man9/signal.9 3.html +++ /dev/null @@ -1,482 +0,0 @@ - - - - - - -
SIGNAL(9)Kernel Developer's ManualSIGNAL(9)
-
-
-

-

signal, siginit, - sigactsinit, sigactsunshare, - sigactsfree, execsigs, - sigaction1, sigprocmask1, - sigpending1, sigsuspend1, - sigaltstack1, pgsignal, - kpgsignal, psignal, - kpsignal, issignal, - postsig, killproc, - sigexit, trapsignal, - sendsig, sigcode, - sigtramp — software signal - facilities

-
-
-

-

#include - <sys/signal.h> -
- #include <sys/signalvar.h>

-

void -
- siginit(struct - proc *p);

-

void -
- sigactsinit(struct - proc *pp, int - share);

-

void -
- sigactsunshare(struct - proc *p);

-

void -
- sigactsfree(struct - proc *p);

-

void -
- execsigs(struct - proc *p);

-

int -
- sigaction1(struct - lwp *l, int signum, - const struct sigaction - *nsa, struct sigaction - *osa, void *tramp, - int vers);

-

int -
- sigprocmask1(struct - lwp *l, int how, - const sigset_t *nss, - sigset_t *oss);

-

void -
- sigpending1(struct - lwp *l, sigset_t - *ss);

-

int -
- sigsuspend1(struct - lwp *l, const sigset_t - *ss);

-

int -
- sigaltstack1(struct - lwp *l, const struct - sigaltstack *nss, struct - sigaltstack *oss);

-

void -
- pgsignal(struct - pgrp *pgrp, int - signum, int - checkctty);

-

void -
- kpgsignal(struct - pgrp *pgrp, ksiginfo_t - *ks, void *data, - int checkctty);

-

void -
- psignal(struct - proc *p, int - signum);

-

void -
- kpsignal(struct - proc *p, ksiginfo_t - *ks, void - *data);

-

int -
- issignal(struct - lwp *l);

-

void -
- postsig(int - signum);

-

void -
- killproc(struct - proc *p, const char - *why);

-

void -
- sigexit(struct - lwp *l, int - signum);

-

void -
- trapsignal(struct - lwp *l, const ksiginfo_t - *ks);

-

void -
- sendsig(const - ksiginfo_t *ks, const - sigset_t *mask);

-
-
-

-

The system defines a set of signals that may be delivered to a - process. These functions implement the kernel portion of the signal - facility.

-

Signal numbers used throughout the kernel signal facilities should - always be within the range of [1-NSIG].

-

Most of the kernel's signal infrastructure is implemented in - machine-independent code. Machine-dependent code provides support for - invoking a process's signal handler, restoring context when the signal - handler returns, generating signals when hardware traps occur, triggering - the delivery of signals when a process is about to return from the kernel to - userspace.

-

The signal state for a process is contained in - struct sigctx. This includes the list of signals with - delivery pending, information about the signal handler stack, the signal - mask, and the address of the signal trampoline.

-

The registered signal handlers for a process are recorded in - struct sigacts. This structure may be shared by - multiple processes.

-

The kernel's signal facilities are implemented by the following - functions:

-
-
(p)
-
-

This function initializes the signal state of - proc0 to the system default. This signal state is - then inherited by init(8) when it is started by the - kernel.

-
-
(pp, - share)
-
-

This function creates an initial struct - sigacts for the process pp. If the - share argument is non-zero, then - pp shares the struct sigacts - by holding a reference. Otherwise, pp receives a - new struct sigacts which is copied from the - parent.

-
-
(p)
-
-

This function causes the process p to no - longer share its struct sigacts The current state - of the signal actions is maintained in the new copy.

-
-
(p)
-
-

This function decrements the reference count on the - struct sigacts of process p. - If the reference count reaches zero, the struct - sigacts is freed.

-
-
(p)
-
-

This function is used to reset the signal state of the process - p to the system defaults when the process execs a - new program image.

-
-
(l, - signum, nsa, - osa, tramp, - vers)
-
-

This function implements the - sigaction(2) system call. The - tramp and vers arguments - provide support for userspace signal trampolines. Trampoline version 0 - is reserved for the legacy kernel-provided signal trampoline; - tramp must be NULL in this - case. Otherwise, vers specifies the ABI of the - trampoline specified by tramp. The signal - trampoline ABI is machine-dependent, and must be coordinated with the - () - function.

-
-
(l, - how, nss, - oss)
-
-

This function implements the sigprocmask(2) - system call.

-
-
(l, - ss)
-
-

This function implements the sigpending(2) - system call.

-
-
(l, - ss)
-
-

This function implements the sigsuspend(2) - system call.

-
-
(l, - nss, oss)
-
-

This function implements the sigaltstack(2) - system call.

-
-
(pgrp, - signum, checkctty)
-
-

This is a wrapper function for - () - which is described below.

-
-
kpgsignal(pgrp, - ks, data, - checkctty)
-
-

Schedule the signal - ks->ksi_signo to be delivered to all members of - the process group pgrp. If - checkctty is non-zero, the signal is only sent to - processes which have a controlling terminal. The - data argument and the complete signal scheduling - semantics are described in the - () - function below.

-
-
(l, - ks)
-
-

Sends the signal ks->ksi_signo caused - by a hardware trap to the current process.

-
-
(p, - signum)
-
-

This is a wrapper function for - () - which is described below.

-
-
kpsignal(p, - ks, data)
-
-

Schedule the signal ks->ksi_signo to - be delivered to the process p. The - data argument, if not - NULL, points to the file descriptor data that - caused the signal to be generated in the SIGIO - case.

-

With a few exceptions noted below, the target - process signal disposition is updated and is marked as runnable, so - further handling of the signal is done in the context of the target - process after a context switch; see - () - below. Note that kpsignal() does not by itself - cause a context switch to happen.

-

The target process is not marked as runnable in the following - cases:

-
    -
  • The target process is sleeping uninterruptibly. The signal will be - noticed when the process returns from the system call or trap.
    • -
  • The target process is currently ignoring the signal.
    • -
  • If a stop signal is sent to a sleeping process that takes the default - action (see sigaction(2)), the process is stopped - without awakening it.
    • -
  • SIGCONT restarts a stopped process (or puts them back to sleep) - regardless of the signal action (e.g., blocked or ignored).
    • -
-

If the target process is being traced, - () - behaves as if the target process were taking the default action for - signum. This allows the tracing process to be - notified of the signal.

-
-
issignal(l)
-
-

This function determines which signal, if any, is to be posted - to the current process. A signal is to be posted if:

-
    -
  • The signal has a handler provided by the program image.
    • -
  • The signal should cause the process to dump core and/or - terminate.
    • -
  • The signal should interrupt the current system call.
    • -
-

Signals which cause the process to be stopped - are handled within - () - directly.

-

() - should be called by machine-dependent code when returning to userspace - from a system call or other trap or interrupt by using the following - code:

-
- 
while (signum = CURSIG(curproc))
-	postsig(signum);
-
-
-
(signum)
-
-

The - () - function is used to invoke the action for the signal - signum in the current process. If the default - action of a signal is to terminate the process, and the signal does not - have a registered handler, the process exits using - sigexit(), dumping a core image if - necessary.

-
-
(p, - why)
-
-

This function sends a SIGKILL signal to the specified process. - The message provided by why is sent to the system - log and is also displayed on the process's controlling terminal.

-
-
(l, - signum)
-
-

This function forces the current process to exit with the - signal signum, generating a core file if - appropriate. No checks are made for masked or caught signals; the - process always exits.

-
-
(ks, - mask)
-
-

This function is provided by machine-dependent - code, and is used to invoke a signal handler for the current process. - () - must prepare the registers and stack of the current process to invoke - the signal handler stored in the process's struct - sigacts. This may include switching to an alternate signal stack - specified by the process. The previous register, stack, and signal state - are stored in a ucontext_t, which is then copied - out to the user's stack.

-

The registers and stack must be set up to invoke the signal - handler as follows:

-
- 
(*handler)(int signum, siginfo_t *info, void *ctx)
-
-

where signum is the signal number, - info contains additional signal specific - information when SA_SIGINFO is specified when - setting up the signal handler. ctx is the pointer - to ucontext_t on the user's stack. The registers - and stack must also arrange for the signal handler to return to the - signal trampoline. The trampoline is then used to return to the code - which was executing when the signal was delivered using the - setcontext(2) system call.

-

For performance reasons, it is recommended that - () - arrange for the signal handler to be invoked directly on architectures - where it is convenient to do so. In this case, the trampoline is used - only for the signal return path. If it is not feasible to directly - invoke the signal handler, the trampoline is also used to invoke the - handler, performing any final set up that was not possible for - sendsig() to perform.

-

() - must invoke the signal trampoline with the correct ABI. The ABI of the - signal trampoline is specified on a per-signal basis in the - () - structure for the process. Trampoline version 0 is reserved for the - legacy kernel-provided, on-stack signal trampoline. All other trampoline - versions indicate a specific trampoline ABI. This ABI is coordinated - with machine-dependent code in the system C library.

-
-
-
-

-

The signal trampoline is a special piece of code which provides - support for invoking the signal handlers for a process. The trampoline is - used to return from the signal handler back to the code which was executing - when the signal was delivered, and is also used to invoke the handler itself - on architectures where it is not feasible to have the kernel invoke the - handler directly.

-

In traditional UNIX systems, the signal - trampoline, also referred to as the “sigcode”, is provided by - the kernel and copied to the top of the user's stack when a new process is - created or a new program image is exec'd. Starting in - NetBSD 2.0, the signal trampoline is provided by the - system C library. This allows for more flexibility when the signal facility - is extended, makes dealing with signals easier in debuggers, such as - gdb(1), and may also enhance system security by allowing - the kernel to disallow execution of code on the stack.

-

The signal trampoline is specified on a per-signal basis. The - correct trampoline is selected automatically by the C library when a signal - handler is registered by a process.

-

Signal trampolines have a special naming convention which enables - debuggers to determine the characteristics of the signal handler and its - arguments. Trampoline functions are named like so:

-
-
__sigtramp_<flavor>_<version>
-
-

where:

-
-
⟨flavor⟩
-
The flavor of the signal handler. The following flavors are valid: -
-
sigcontext
-
Specifies a traditional BSD-style (deprecated) signal handler with the - following signature: -
- 
void (*handler)(int signum,
-	int code,
-	struct sigcontext *scp);
-
-
-
siginfo
-
Specifies a POSIX-style signal handler with the following signature: -
- 
void (*handler)(int signum,
-	siginfo_t *si,
-	void *uc);
-
-

Note: sigcontext style signal handlers are deprecated, and - retained only for compatibility with older binaries.

-
-
-
-
⟨version⟩
-
Specifies the ABI version of the signal trampoline. The trampoline ABI is - coordinated with the machine-dependent kernel - () - function. The trampoline version needs to be unique even across different - trampoline flavors, in order to simplify trampoline selection in the - kernel.
-
-

The following is an example if a signal trampoline name which - indicates that the trampoline is used for traditional BSD-style signal - handlers and implements version 1 of the signal trampoline ABI:

-
-
__sigtramp_sigcontext_1
-
-

The current signal trampoline is:

-
-
__sigtramp_siginfo_2
-
-
-
-
-

-

sigaction(2), signal(7), - condvar(9)

-
-
- - - - - -
April 29, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/sockopt.9 3.html b/static/netbsd/man9/sockopt.9 3.html deleted file mode 100644 index 75fa4080..00000000 --- a/static/netbsd/man9/sockopt.9 3.html +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - -
SOCKOPT(9)Kernel Developer's ManualSOCKOPT(9)
-
-
-

-

sockopt_init, - sockopt_destroy, - sockopt_get, sockopt_getint, - sockopt_set, sockopt_setint - — socket options handling

-
-
-

-

#include - <sys/socketvar.h>

-

void -
- sockopt_init(struct - sockopt *sopt, int - level, int name, - size_t size);

-

void -
- sockopt_destroy(struct - sockopt *sopt);

-

int -
- sockopt_get(struct - sockopt *sopt, void - *value, size_t - size);

-

int -
- sockopt_getint(struct - sockopt *sopt, int - *value);

-

int -
- sockopt_set(struct - sockopt *sopt, const void - *value, size_t - size);

-

int -
- sockopt_setint(struct - sockopt *sopt, int - value);

-
-
-

-

The sockopt structure is used to pass a - socket option and associated value:

-
-
struct sockopt {
-	int		sopt_level;		/* option level */
-	int		sopt_name;		/* option name */
-	size_t		sopt_size;		/* data length */
-	size_t		sopt_retsize;		/* returned data length */
-	void *		sopt_data;		/* data pointer */
-	uint8_t		sopt_buf[sizeof(int)];	/* internal storage */
-};
-
-

The internal storage is used for the common case of values up to - integer size so that memory allocation is not required and sopt_data will - point to this in that case.

-

Rather than provide accessor functions, the - sockopt structure is public and the contents are - expected to be internally consistent, but the normal practice would be to - use the appropriate methods for storage and retrieval of values where a - known datatype is expected, as the size will be verified.

-

Note: a sockopt structure may only be used for a single - level/name/size combination. If the structure is to be re-used, it must be - destroyed and re-initialized with the new values.

-
-
-

-
-
options DIAGNOSTIC
-
Kernels compiled with the DIAGNOSTIC option will - perform basic sanity checks on socket options operations.
-
-
-
-

-
-
(sopt, - level, name, - size)
-
Initialise sockopt storage. If size is given, - sockopt_init() will arrange for sopt_data to point - to a buffer of size bytes for the sockopt value. - Where memory needs to be allocated to satisfy this, - sockopt_init() may sleep.
-
(sopt)
-
Destroy sockopt storage, releasing any allocated memory.
-
(sopt, - value, size)
-
Copy out sockopt value. Will return EINVAL if an - incorrect data size is given.
-
(sopt, - value)
-
Common case of get sockopt integer value. Will return - EINVAL if sockopt does not contain an integer - sized value.
-
sockopt_set(sopt, - value, size)
-
Copy in sockopt value. The sockopt structure must contain a data field of - size bytes or be previously unset, in which case a - data buffer may be allocated using kmem_alloc(9) with - the KM_NOSLEEP flag which may cause - sockopt_set() to return - ENOMEM. -

Note: If you need to use - () - in a context where memory allocation may be required and you do not wish - to contemplate failure, the sockopt structure can be initialised in a - more suitable context using sockopt_init() which - will not fail.

-
-
(sopt, - value)
-
Common case of set sockopt integer value. The sockopt structure must - contain an int sized data field or be previously unset, in which case the - data pointer will be set to the internal storage.
-
-
-
-

-

The function prototypes and sockopt structure are defined in the - sys/sys/socketvar.h header file, and the socket - options implementation is in - sys/kern/uipc_socket.c.

-
-
-

-

errno(2), kmem(9)

-
-
-

-

The socket options KPI was inspired by a similar KPI in - FreeBSD and first appeared in - NetBSD 5.0.

-
-
- - - - - -
January 3, 2018NetBSD 10.1
diff --git a/static/netbsd/man9/strlist.9 3.html b/static/netbsd/man9/strlist.9 3.html deleted file mode 100644 index 8b78bd4c..00000000 --- a/static/netbsd/man9/strlist.9 3.html +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - -
OFSL(9)Kernel Developer's ManualOFSL(9)
-
-
-

-

strlist, - strlist_next, strlist_count, - strlist_string, - strlist_match, - strlist_index, - strlist_append — functions - to interact with OpenFirmware-style string lists

-
-
-

-

#include - <sys/systm.h>

-

const char * -
- strlist_next(const - char *sl, size_t - slsize, size_t - *cursorp);

-

void -
- strlist_count(const - char *sl, size_t - slsize);

-

const char * -
- strlist_string(const - char *sl, size_t - slsize, unsigned int - index);

-

int -
- strlist_match(const - char *sl, size_t - slsize, const char - *str);

-

int -
- strlist_pmatch(const - char *sl, size_t - slsize, const char - *pattern);

-

int -
- strlist_index(const - char *sl, size_t - slsize, const char - *str);

-

bool -
- strlist_append(char - **slp, size_t - *slsizep, const char - *str);

-
-
-

-

The strlist functions provide a simple way - to interact with OpenFirmware (IEEE 1275) string lists.

-

An OpenFirmware string list is simply a buffer containing one or - more NUL-terminated strings concatenated together. For example, a string - list containing the strings “foo”, “bar”, and - “baz” would be represented in memory as:

-
-
foo\0bar\0baz\0
-
-

The following functions are available:

-
-
(const - char *sl, size_t slsize, size_t - *cursorp)
-
This function provides a way to enumerate the strings in a string list. To - enumerate a string list, initialize cursor to 0 and - pass it by reference to strlist_next(). Each call - to strlist_next() returns the current string and - advances the cursor to the next string in the list. If all strings in the - list have been enumerated, strlist_next() will - return NULL.
-
(const - char *sl, size_t slsize)
-
Returns the number of strings in the string list.
-
(const - char *sl, size_t slsize, - unsigned int index)
-
Returns a pointer to the string in the string list at the specified index - or NULL if the index is out of range.
-
(const - char *sl, size_t slsize, const - char *str)
-
Returns a weighted match value if the specified string appears in the - string list. The value returned is the number of strings in the string - list minus the index of the matched string. For example, if a string list - contains the strings “foo”, “bar”, and - “baz”, a match against “foo” returns 3 and a - match against “baz” returns 1. If the string does not appear - in the string list, 0 is returned.
-
(const - char *sl, size_t slsize, const - char *pattern)
-
Like strlist_match(), but uses - () - to compare strings, allowing for wildcard characters to be specified in - pattern.
-
(const - char *sl, size_t slsize, const - char *str)
-
Returns the index of the specified string if it appears in the string - list, or -1 if the string does not appear in the string list.
-
(char - **slp, size_t *slsizep, const - char *str)
-
Appends a copy of the specified string to the stringlist. Begin by - initializing sl to NULL and - slsize to 0. Pass these by reference to - strlist_append(). New memory for the string list - will be allocated as needed. The resulting string list can be freed with - (). - Returns true if the string was successfully - appended to the string list or false if memory - allocation fails.
-
-
-
-

-

The following shows an example of string list enumeration using - strlist_next():

-
-
void
-print_stringlist(const char *sl, size_t slsize)
-{
-	const char *cp;
-	size_t cursor;
-
-	printf("There are %u strings in the string list:\n",
-	    strlist_count(sl, slsize));
-	for (cursor = 0;
-	     (cp = strlist_next(sl, slsize, &cursor) != NULL; ) {
-		printf("\t%s\n", cp);
-	}
-}
-
-

The following example shows a simple way to use - strlist_match():

-
-
bool
-is_compatible(int phandle, const char *compat_str)
-{
-	char buf[128];
-	int proplen;
-
-	proplen = OF_getprop(phandle, "compatible", buf, sizeof(buf));
-	return strlist_match(buf, proplen, compat_str) != 0;
-}
-
-

The following example shows a use of - strlist_pmatch():

-
-
bool
-is_pc_printer_port(const char *pnp_id_list, size_t list_size)
-{
-	return strlist_pmatch(pnp_id_list, list_size, "PNP04??") != 0;
-}
-
-

The following example converts an array of strings to a string - list using strlist_append():

-
-
char *
-string_array_to_string_list(const char **array, int count,
-    size_t *slsizep)
-{
-	char *sl;
-	size_t slsize;
-	int i;
-
-	for (i = 0, sl = NULL, slsize = 0; i < count; i++) {
-		if (!strlist_append(&sl, &slsize, array[i])) {
-			kmem_free(sl, slsize);
-			return NULL;
-		}
-	}
-
-	*slsizep = slsize;
-	return sl;
-}
-
-
-
-

-

kmem(9), pmatch(9)

-
-
-

-

The strlist functions first appeared in - NetBSD 10.0.

-
-
- - - - - -
January 20, 2021NetBSD 10.1
diff --git a/static/netbsd/man9/tc.9 3.html b/static/netbsd/man9/tc.9 3.html deleted file mode 100644 index ebfdfeed..00000000 --- a/static/netbsd/man9/tc.9 3.html +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - -
TC(9)Kernel Developer's ManualTC(9)
-
-
-

-

TC, - tc_intr_establish, - tc_intr_disestablish, - tc_intr_evcnt. tc_mb, - tc_wmb, tc_syncbus, - tc_badaddr, - TC_DENSE_TO_SPARSE, - TC_PHYS_TO_UNCACHED — - TURBOchannel bus

-
-
-

-

#include - <sys/bus.h> -
- #include <dev/tc/tcvar.h> -
- #include <dev/tc/tcdevs.h>

-

void -
- tc_intr_establish(struct - device *dev, void - *cookie, int level, - int (*handler)(void *), - void *arg);

-

void -
- tc_intr_disestablish(struct - device *dev, void - *cookie);

-

const struct evcnt * -
- tc_intr_evcnt(struct - device *dev, void - *cookie);

-

void -
- tc_mb();

-

void -
- tc_wmb();

-

void -
- tc_syncbus();

-

int -
- tc_badaddr(tc_addr_t - tcaddr);

-

tc_addr_t -
- TC_DENSE_TO_SPARSE(tc_addr_t - addr);

-

tc_addr_t -
- TC_PHYS_TO_UNCACHED(tc_addr_t - addr);

-
-
-

-

The TC device provides support for the DEC - TURBOchannel bus found on all DEC TURBOchannel machines with MIPS - (DECstation 5000 series, excluding the 5000/200) and Alpha (3000-series) - systems. TURBOchannel is a 32-bit wide synchronous DMA-capable bus, running - at 25 MHz on higher-end machines and at 12.5 MHz on lower-end machines.

-
-
-

-

Drivers for devices attached to the TURBOchannel bus will make use - of the following data types:

-
-
struct tc_attach_args
-
A structure use to inform the driver of TURBOchannel bus properties. It - contains the following members: -
- 
	bus_space_tag_t	ta_memt;
-	bus_dma_tag_t	ta_dmat;
-	char		ta_modname[TC_ROM_LLEN+1];
-	u_int		ta_slot;
-	tc_offset_t	ta_offset;
-	tc_addr_t	ta_addr;
-	void		*ta_cookie;
-	u_int		ta_busspeed;
-
-

The - - member specifies the TURBOchannel bus speed and is useful for - time-related functions. Values values are - - for the 12.5 MHz bus and - - for the 50 MHz bus.

-
-
-
-
-

-
-
(dev, - cookie, level, - handler, arg)
-
Establish an interrupt handler with device dev for - the interrupt described completely by cookie, the - value passed to the driver in the - - member of the tc_attach_args structure. The priority of - the interrupt is specified by level. When the - interrupt occurs the function handler is called with - argument arg.
-
(dev, - cookie)
-
Dis-establish the interrupt handler with device dev - for the interrupt described completely cookie.
-
(dev, - cookie)
-
Do interrupt event counting with device dev for the - event described completely by cookie.
-
()
-
A read/write memory barrier. Any CPU-to-memory reads/writes before the - barrier must complete before any CPU-to-memory reads/writes after it.
-
()
-
A write memory barrier. Any CPU-to-memory writes before the barrier must - complete before any CPU-to-memory writes after it.
-
()
-
Synchronise writes on the TURBOchannel bus by ensuring CPU writes are - propagated across the TURBOchannel bus.
-
(tcaddr)
-
Returns non-zero if the given address tcaddr is - invalid.
-
(addr)
-
Convert the given physical address addr in - TURBOchannel dense space to the corresponding address in TURBOchannel - sparse space.
-
(addr)
-
Convert the given system memory physical address - addr to the physical address of the corresponding - region that is not cached.
-
-
-
-

-

The TURBOchannel bus is a direct-connection bus. During - autoconfiguration, the parent specifies the name of the found TURBOchannel - module into the ta_modname member of the - tc_attach_args structure. Drivers should match on this - name.

-
-
-

-

The TURBOchannel bus supports 32-bit, bidirectional DMA transfers. - Support is provided by the standard bus_dma(9) - interface.

-
-
-

-

The TURBOchannel subsystem itself is implemented within the file - sys/dev/tc/tc_subr.c. Machine-dependent portions can - be found in sys/arch/<arch>/tc/tcbus.c.

-
-
-

-

tc(4), autoconf(9), - bus_dma(9), bus_space(9), - driver(9)

-
-
- - - - - -
October 7, 2001NetBSD 10.1
diff --git a/static/netbsd/man9/tcp_congctl.9 3.html b/static/netbsd/man9/tcp_congctl.9 3.html deleted file mode 100644 index 5342e324..00000000 --- a/static/netbsd/man9/tcp_congctl.9 3.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - -
TCP_CONGCTL(9)Kernel Developer's ManualTCP_CONGCTL(9)
-
-
-

-

tcp_congctl — TCP - congestion control API

-
-
-

-

#include - <netinet/tcp_congctl.h>

-

int -
- tcp_congctl_register(const - char *, struct - tcp_congctl *);

-

int -
- tcp_congctl_unregister(const - char *);

-
-
-

-

The tcp_congctrl API is used to add or - remove TCP congestion control algorithms on-the-fly and to modularize them. - It includes basically two functions:

-
-
(const - char *, struct tcp_congctl *)
-
Registers a new congestion control algorithm. The struct - tcp_congctl argument must contain a list of callbacks like the - following: -
- 
struct tcp_congctl {
-	int  (*fast_retransmit)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*slow_retransmit)(struct tcpcb *);
-	void (*fast_retransmit_newack)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*newack)(struct tcpcb *,
-	    struct tcphdr *);
-	void (*cong_exp)(struct tcpcb *);
-};
-
-
-
(const - char *)
-
If found, unregister the selected TCP congestion control algorithm.
-
-
-
-

-

tcp_congctl_register() and - tcp_congctl_unregister() both return - 0 when there is no error. If the name is already - registered, tcp_congctl_register() will return - EEXIST. - tcp_congctl_unregister() can return - ENOENT if there is no congestion control algorithm - by that name and can return EBUSY if the matched - algorithm is being used by userspace applications.

-
-
-

-

Implementation is in - sys/netinet/tcp_congctl.c and the interface is in - sys/netinet/tcp_congctl.h.

-
-
-

-

tcp(4)

-
-
- - - - - -
October 15, 2006NetBSD 10.1
diff --git a/static/netbsd/man9/ucom.9 3.html b/static/netbsd/man9/ucom.9 3.html deleted file mode 100644 index 774d39d3..00000000 --- a/static/netbsd/man9/ucom.9 3.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - -
UCOM(9)Kernel Developer's ManualUCOM(9)
-
-
-

-

ucom — interface - for USB tty like devices

-
-
-

-

The ucom driver is a (relatively) easy way - to make a USB device look like a tty(4). It basically - takes two bulk pipes, input and output, and makes a tty out of them. This is - useful for a number of device types, e.g., serial ports (see - uftdi(4)), modems (see umodem(4)), and - devices that traditionally look like a tty (see - uvisor(4)).

-

Communication between the real driver and the - ucom driver is via the attachment arguments (when - attached) and via the ucom_methods struct

-
-
-

-
-
struct ucom_attach_args {
-	int ucaa_portno;
-	int ucaa_bulkin;
-	int ucaa_bulkout;
-	u_int ucaa_ibufsize;
-	u_int ucaa_ibufsizepad;
-	u_int ucaa_obufsize;
-	u_int ucaa_opkthdrlen;
-	const char *ucaa_info;
-	struct usbd_device *ucaa_device;
-	struct usbd_interface *ucaa_iface;
-	const struct ucom_methods *ucaa_methods;
-	void *ucaa_arg;
-};
-
-
-
-
identifies the port if the devices should have more than one - ucom attached. Use the value - UCOM_UNK_PORTNO if there is only one port.
-
-
the number of the bulk input pipe.
-
-
the number of the bulk output pipe.
-
-
the size of the read requests on the bulk in pipe.
-
-
the size of the input buffer. This is usually the same as - ibufsize.
-
-
the size of the write requests on the bulk out pipe.
-
-
the size of the output buffer. This is usually the same as - ucaa_obufsize.
-
-
a handle to the device.
-
struct usbd_interface *ucaa_iface
-
a handle to the interface that should be used.
-
struct ucom_methods *ucaa_methods
-
a pointer to the methods that the ucom driver - should use for further communication with the driver.
-
void *ucaa_arg
-
the value that should be passed as first argument to each method.
-
-
-
-

-

The ucom_methods struct contains a number - of function pointers used by the ucom driver at - various stages. If the device is not interested in being called at a - particular point it should just use a NULL pointer - and the ucom driver will use a sensible default.

-
-
struct ucom_methods {
-	void (*ucom_get_status)(void *sc, int portno,
-	    u_char *lsr, u_char *msr);
-	void (*ucom_set)(void *sc, int portno, int reg, int onoff);
-#define UCOM_SET_DTR 1
-#define UCOM_SET_RTS 2
-#define UCOM_SET_BREAK 3
-	int (*ucom_param)(void *sc, int portno, struct termios *);
-	int (*ucom_ioctl)(void *sc, int portno, u_long cmd,
-	    void *data, int flag, proc_t *p);
-	int (*ucom_open)(void *sc, int portno);
-	void (*ucom_close)(void *sc, int portno);
-	void (*ucom_read)(void *sc, int portno, u_char **ptr,
-	    uint32_t *count);
-	void (*ucom_write)(void *sc, int portno, u_char *to,
-	    u_char *from, uint32_t *count);
-};
-
-
-
void - (*ucom_get_status)(void *sc, - int portno, u_char *lsr, - u_char *msr)
-
get the status of port portno. The status consists - of the line status, lsr, and the modem status - msr. The contents of these two bytes is exactly as - for a 16550 UART.
-
void - (*ucom_set)(void *sc, - int portno, int reg, - int onoff)
-
Set (or unset) a particular feature of a port.
-
int - (*ucom_param)(void *sc, - int portno, struct termios - *t)
-
Set the speed, number of data bit, stop bits, and parity of a port - according to the termios(4) struct.
-
int - (*ucom_ioctl)(void *sc, - int portno, u_long cmd, - void *data, int flag, - proc_t *p)
-
implements any non-standard ioctl(2) that a device - needs.
-
int - (*ucom_open)(void *sc, - int portno)
-
called just before the ucom driver opens the bulk - pipes for the port.
-
void - (*ucom_close)(void *sc, - int portno)
-
called just after the ucom driver closes the bulk - pipes for the port.
-
void - (*ucom_read)(void *sc, - int portno, u_char **ptr, - uint32_t *count)
-
if the data delivered on the bulk pipe is not just the raw input - characters this routine needs to increment ptr by as - many characters to skip from the start of the raw input and decrement - count by as many characters to truncate from the end - of the raw input.
-
void - (*ucom_write)(void *sc, - int portno, u_char *dst, - u_char *src, uint32_t - *count)
-
if the data written to the bulk pipe is not just the raw characters then - this routine needs to copy count raw characters from - src into the buffer at dst and - do the appropriate padding. The count should be - updated to the new size. The buffer at src is at - most ibufsize bytes and the buffer at - dst is ibufsizepad bytes.
-
-

Apart from these methods there is a function

-
-
-
void - (struct - ucom_softc *)
-
 
-
-
-

which should be called by the driver whenever it notices a status - change.

-
-
-

-

tty(4), u3g(4), - uark(4), ubsa(4), - uchcom(4), uftdi(4), - ugensa(4), uhmodem(4), - uipaq(4), ukyopon(4), - umct(4), umodem(4), - uplcom(4), usb(4), - uslsa(4), uvisor(4), - uvscom(4)

-
-
-

-

This ucom interface first appeared in - NetBSD 1.5.

-
-
- - - - - -
September 12, 2016NetBSD 10.1
diff --git a/static/netbsd/man9/usbd_status.9 3.html b/static/netbsd/man9/usbd_status.9 3.html deleted file mode 100644 index 9b3cad01..00000000 --- a/static/netbsd/man9/usbd_status.9 3.html +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - -
USBD_STATUS(9)Kernel Developer's ManualUSBD_STATUS(9)
-
-
-

-

usbd_status — USB - device drivers interface return status values

-
-
-

-

#include - <dev/usb/usbdi.h>

-
-
-

-

This documents the full list of return values used by the generic - USB code. Interface-specific definitions will be given with interface.

-
-
-

-

Return values are split into two main groups: expected values and - error values.

-

There are only two expected values:

-
-
-
The operation completed successfully.
-
-
The operation was successfully submitted, usually part of an asynchronous - operation.
-
-

These are the error values:

-
-
-
The requested operation could not be completed due to pending requests, - usually from a pipe close operation.
-
-
The initial status of a USB transfer. See usbdi(9) for - more details about USB transfers.
-
-
Invalid arguments were supplied for the requested operation.
-
-
No memory could be allocated.
-
-
The USB transfer has been cancelled, and not completed.
-
-
The requested USB pipe could not be found. See usbdi(9) - for more details about USB pipes.
-
-
The requested operation could not be performed due to the device having - active connections, such as USB audio device currently playing.
-
-
USB bus has reached its maximum limit of devices.
-
-
Call to usbd_set_address() failed during new USB - device discovery.
-
-
New device has requested more power than is available.
-
-
New USB Hub too deep from the root.
-
-
Non-specific error happened during IO.
-
-
USB device is not configured; it has no configuration descriptor.
-
-
Operation timed out.
-
-
USB transfer succeeded but not all requested data was returned.
-
-
USB controller has stalled (controller specific.)
-
-
Process was interrupted by external means (such as a signal) while waiting - for a transfer to complete.
-
-
-
-

-

usb(4), usbdi(9)

-
-
-

-

This usbd_status interface first appeared - in NetBSD 1.4.

-
-
- - - - - -
May 12, 2012NetBSD 10.1
diff --git a/static/netbsd/man9/usbnet.9 3.html b/static/netbsd/man9/usbnet.9 3.html deleted file mode 100644 index 39a68489..00000000 --- a/static/netbsd/man9/usbnet.9 3.html +++ /dev/null @@ -1,669 +0,0 @@ - - - - - - -
USBNET(9)Kernel Developer's ManualUSBNET(9)
-
-
-

-

usbnet — common - USB Ethernet driver framework

-
-
-

-

#include - <dev/usb/usbnet.h>

-
-

-

void -
- usbnet_set_link(struct - usbnet *un, bool - link);

-

struct ifnet * -
- usbnet_ifp(struct - usbnet *un);

-

struct ethercom * -
- usbnet_ec(struct - usbnet *un);

-

struct mii_data * -
- usbnet_mii(struct - usbnet *un);

-

krndsource_t * -
- usbnet_rndsrc(struct - usbnet *un);

-

void * -
- usbnet_softc(struct - usbnet *un);

-

bool -
- usbnet_havelink(struct - usbnet *un);

-

int -
- usbnet_ispromisc(struct - usbnet *un);

-

bool -
- usbnet_isdying(struct - usbnet *un);

-

void -
- usbnet_enqueue(struct - usbnet *un, uint8_t - *buf, size_t - buflen, int - csum_flags, uint32_t - csum_data, int - mbuf_flags);

-

void -
- usbnet_input(struct - usbnet *un, uint8_t - *buf, size_t - buflen);

-

void -
- usbnet_attach(struct - usbnet *un);

-

void -
- usbnet_attach_ifp(struct - usbnet *un, unsigned - if_flags, unsigned - if_extflags, const struct - usbnet_mii *unm);

-

int -
- usbnet_detach(device_t - dev, int - flags);

-

int -
- usbnet_activate(device_t - dev, devact_t - act);

-
-
-
-

-

The usbnet framework provides methods - usable for USB Ethernet drivers. The framework has support for these - features:

-
    -
  • Partial autoconf handling
    • -
  • USB endpoint pipe handling
    • -
  • Rx and Tx chain handling
    • -
  • Generic handlers or support for several struct ifnet callbacks
    • -
  • Network stack locking protocol
    • -
  • Interrupt handling
    • -
-

usbnet provides many or all of the - traditional “softc” members inside struct - usbnet, which can be used directly as the device softc structure if no - additional storage is required. A structure exists for receive and transmit - chain management, struct usbnet_chain, that tracks the - metadata for each transfer descriptor available, minimum of one each for Rx - and Tx slots, and will be passed to the Rx and Tx callbacks.

-

There is a struct usbnet_ops structure that - provides a number of optional and required callbacks that will be described - below.

-

For autoconfiguration the device attach routine - is expected to ensure that this device's struct usbnet - is the first member of the device softc, if it can not be used directly as - the device softc, as well as set up the necessary structure members, find - end-points, find the Ethernet address if relevant, call - (), - set up interface, Ethernet, and MII capabilities, and finally call - usbnet_attach_ifp(). The device detach routine - should free any resources allocated by attach and then call - usbnet_detach(), possibly directly using - usbnet_detach() as most consumers have no additional - resources not owned and released by the usbnet - framework itself. The device activate function should be set to - usbnet_activate().

-

When bringing an interface up from if_init(9), - which happens under IFNET_LOCK(9), - usbnet will:

-
    -
  1. call “uno_init” to initialize the hardware for sending and - receiving packets,
    2. -
  2. open the USB pipes,
    3. -
  3. allocate Rx and Tx buffers for transfers,
    4. -
  4. call “uno_mcast” to initially program the hardware multicast - filter, and finally
    5. -
  5. start the Rx transfers so packets can be received.
    6. -
-

See the RECEIVE AND - SEND section for details on using the chains.

-

When bringing an interface down from if_stop(9), - which happens under IFNET_LOCK(9), - usbnet will:

-
    -
  1. abort the USB pipes,
    2. -
  2. call “uno_stop” to stop the hardware from receiving packets - (unless the device is detaching),
    3. -
  3. free Rx and Tx buffers for transfers, and
    4. -
  4. close the USB pipes.
    5. -
-

For interface ioctl, most of the handling is in the framework. - While the interface is running, the optional “uno_mcast” - callback is invoked after handling the SIOCADDMULTI - and SIOCDELMULTI ioctl commands to update the - hardware's multicast filter from the ethersubr(9) lists. - The optional “uno_ioctl” callback, which is invoked under - IFNET_LOCK(9), can be used to program special settings - like offload handling.

-

If ioctl handling requires capturing - device-specific ioctls then the “uno_override_ioctl” callback - may be used instead to replace the framework's ioctl handler completely - (i.e., the replacement should call any generic ioctl handlers such as - () - as required). For sending packets, the “uno_tx_prepare” - callback must be used to convert an mbuf into a chain buffer ready for - transmission.

-

For devices requiring MII handling there are callbacks for reading - and writing registers, and for status change events. Access to all the MII - functions is serialized by usbnet.

-

As receive must handle the case of multiple - packets in one buffer, the support is split between the driver and the - framework. A “uno_rx_loop” callback must be provided that - loops over the incoming packet data found in a chain, performs necessary - checking, and passes the network frame up the stack via either - () - or - (). - Typically Ethernet devices prefer - usbnet_enqueue().

-

General accessor functions for struct - usbnet:

-
- -
Set the link status for this un to - link.
-
(un)
-
Returns pointer to this un's struct - ifnet.
-
(un)
-
Returns pointer to this un's struct - ethercom.
-
(un)
-
Returns pointer to this un's struct - mii_data.
-
(un)
-
Returns pointer to this un's - krndsource_t.
-
(un)
-
Returns pointer to this un's device softc.
- -
Returns true if link is active.
-
(un)
-
True if IFF_PROMISC is enabled, false if not. -

May be used only in “uno_init” and - “uno_mcast”.

-

Drivers must use this in “uno_mcast” instead of - reading ifp->if_flags.

-
-
(un)
-
Returns true if device is dying (has been pulled or deactivated, pending - detach). This should be used only to abort timeout loops early.
-
-

Buffer enqueue handling for struct - usbnet:

-
-
(un, - buf, buflen, - csum_flags, csum_data, - mbuf_flags)
-
Enqueue buffer buf for length - buflen with higher layers, using the provided - csum_flags, and csum_data, - which are written directly to the mbuf packet header, and - mbuf_flags, which is or-ed into the mbuf flags for - the created mbuf.
-
(un, - buf, buflen)
-
Enqueue buffer buf for length - buflen with higher layers.
-
-

Autoconfiguration handling for struct - usbnet. See the - AUTOCONFIGURATION section for - more details about these functions.

-
-
(un)
-
Initial stage attach of a USB network device. Performs internal - initialization and memory allocation only — nothing is published - yet.
-
usbnet_attach_ifp(un, - if_flags, if_extflags, - unm)
-
Final stage attach of a USB network device. Publishes the network - interface to the rest of the system. -

If the passed in unm is - non-NULL then an MII interface will be created - using the values provided in the struct usbnet_mii - structure, which has these members passed to - ():

-
-
un_mii_flags
-
Flags.
-
un_mii_capmask
-
Capability mask.
-
un_mii_phyloc
-
PHY location.
-
un_mii_offset
-
PHY offset.
-
-

A default - unm can be set using the - () - macro. The if_flags and - if_extflags will be or-ed into the interface flags - and extflags.

-
-
usbnet_detach(dev, - flags)
-
Device detach. Stops all activity and frees memory. Usable as - driver(9) detach method.
-
usbnet_activate(dev, - act)
-
Device activate (deactivate) method. Usable as driver(9) - activate method.
-
-
-
-

-

The framework expects the usbnet structure to have these members - filled in with valid values or functions:

-
-
un_sc
-
Real softc allocated by autoconf and provided to attach, should be set to - the usbnet structure if no device-specific softc is needed.
-
un_dev
-
device_t saved in attach, used for messages mostly.
-
un_iface
-
The USB iface handle for data interactions, see - () - for more details.
-
un_udev
-
The struct usbd_device for this device, provided as the usb_attach_arg's - uaa_device member.
-
un_ops
-
Points to a struct usbnet_ops structure which - contains these members: -
-
void - (*uno_stop)(struct ifnet - *ifp, int disable)
-
Stop hardware activity (optional). Called under - IFNET_LOCK(9) when bringing the interface down, but - skipped when the device is detaching.
-
int - (*uno_ioctl)(struct ifnet - *ifp, u_long cmd, void - *data)
-
Handle driver-specific ioctls (optional). Called under - IFNET_LOCK(9).
-
void - (*uno_mcast)(struct ifnet - *)
-
Program hardware multicast filters from ethersubr(9) - lists (optional). Called between, and not during, - “uno_init” and “uno_stop”.
-
int - (*uno_override_ioctl)(struct - ifnet *ifp, u_long cmd, void - *data)
-
Handle all ioctls, including standard ethernet ioctls normally handled - internally by usbnet (optional). May or may - not be called under IFNET_LOCK(9).
-
int - (*uno_init)(struct ifnet - *ifp)
-
Initialize hardware activity (optional). Called under - IFNET_LOCK(9) when bringing the interface up.
-
int - (*uno_read_reg)(struct usbnet - *un, int phy, int reg, - uint16_t *val)
-
Read MII register. Required with MII. Serialized with other MII - functions, and only called after “uno_init” and before - “uno_stop”.
-
int - (*uno_write_reg)(struct usbnet - *un, int phy, int reg, - uint16_t val)
-
Write MII register. Required with MII. Serialized with other MII - functions, and only called after “uno_init” and before - “uno_stop”.
-
usbd_status - (*uno_statchg)(struct ifnet - *ifp)
-
Handle MII status change. Required with MII. Serialized with other MII - functions, and only called after “uno_init” and before - “uno_stop”.
-
unsigned - (*uno_tx_prepare)(struct usbnet - *un, struct mbuf *m, struct - usbnet_chain *c)
-
Prepare an mbuf for transmit. Required. Called sequentially between, - and not during, “uno_init” and - “uno_stop”.
-
void - (*uno_rx_loop)(struct usbnet - *un, struct usbnet_chain *c, - uint32_t total_len)
-
Prepare one or more chain for enqueue. Required. Called sequentially - between, and not during, “uno_init” and - “uno_stop”.
-
void - (*uno_intr)(struct usbnet - *un, usbd_status status)
-
Process periodic interrupt (optional). Called sequentially between, - and not during, “uno_init” and - “uno_stop”.
-
void - (*uno_tick)(struct usbnet - *un)
-
Called every second with USB task thread context (optional). Called - sequentially between, and not during, “uno_init” and - “uno_stop”.
-
-
-
un_intr
-
Points to a struct usbnet_intr structure which - should have these members set: -
-
uni_buf
-
If non-NULL, points to a buffer passed to - usbd_open_pipe_intr() in the device init - callback, along with the size and interval.
-
uni_bufsz
-
Size of interrupt pipe buffer.
-
uni_interval
-
Frequency of the interrupt in milliseconds.
-
-
-
un_ed
-
Array of endpoint descriptors. There indexes are provided: - USBNET_ENDPT_RX, - USBNET_ENDPT_TX, and - USBNET_ENDPT_INTR. The Rx and Tx endpoints are - required.
-
un_phyno
-
MII phy number. Not used by usbnet.
-
un_eaddr
-
6 bytes of Ethernet address that must be provided before calling - usbnet_attach_ifp() if the device has - Ethernet.
-
un_flags
-
Device owned flags word. The usbnet framework will - not touch this value.
-
un_rx_xfer_flags
-
Passed to - () - for receiving packets.
-
un_tx_xfer_flags
-
Passed to usbd_setup_xfer() for sending - packets.
-
un_rx_list_cnt
-
Number of chain elements to allocate for Rx.
-
un_tx_list_cnt
-
Number of chain elements to allocate for Tx.
-
un_rx_bufsz
-
Rx buffer size.
-
un_tx_bufsz
-
Tx buffer size.
-
-

The device detach and activate callbacks can - typically be set to - () - and - () - unless device-specific handling is required, in which case, they can be - called before or after such handling.

-

The capabilities described in both - struct ifp and struct ethercom - must be set before calling - ().

-
-
-

-

Receive and send routines are structured around the - usbnet_cdata and usbnet_chain - structures, the un_ed, - un_rx_xfer_flags, and - un_tx_xfer_flags members, and the - uno_init(), - uno_tx_prepare(), - uno_rx_loop(), and - uno_stop() callbacks of - usbnet_ops.

-

Typically, the device attach routine will fill in members of the - usbnet structure, as listed in - AUTOCONFIGURATION. The - un_ed array should have the - USBNET_ENDPT_RX and - USBNET_ENDPT_TX array entries filled in, and - optionally the USBNET_ENDPT_INTR entry filled in if - applicable.

-

The - () - callback enables the hardware, and if necessary reprograms the hardware - multicast filter, before the framework initiates USB Tx/Rx transfers. All - USB transfer setup is handled by the framework. The driver callbacks merely - copy data in or out of a chain entry using what is typically a - device-specific method.

-

The - () - callback, called sequentially, converts the provided - usbnet_chain data and length into a series (one or - more) of packets that are enqueued with the higher layers using either - usbnet_enqueue() (for most devices) or - usbnet_input() for devices that use - (). - (This currently relies upon the struct ifnet having - the “_if_input” member set as well, which is true for current - consumers.)

-

The - () - callback must convert the provided struct mbuf into - the provided struct usbnet_chain performing any - device-specific padding, checksum, header or other. Note that this callback - must check that it is not attempting to copy more than the chain buffer - size, as set in the usbnet “un_tx_bufsz” - member. This callback is only called once per packet, sequentially.

-

The struct usbnet_chain structure which - contains a “unc_buf” member which has the chain buffer - allocated where data should be copied to or from for receive or transmit - operations. It also contains pointers back to the owning - struct usbnet, and the struct - usbd_xfer associated with this transfer.

-

After aborting all USB Tx/Rx transfers when bringing - an interface down, the framework calls the optional - () - callback to disable the hardware.

-
-
-

-

For devices that have MII support these callbacks in - struct usbnet_ops must be provided:

-
-
uno_read_reg
-
Read an MII register for a particular PHY. Returns standard - errno(2). Must initialize the result even on - failure.
-
uno_write_reg
-
Write an MII register for a particular PHY. Returns standard - errno(2).
-
uno_statchg
-
Handle a status change event for this interface.
-
-
-
-

-

The interrupt-specific callback, “uno_intr”, is an - optional callback that can be called periodically, registered by - usbnet using the - usbd_open_pipe_intr() function (instead of the - () - function). The usbnet framework provides most of the - interrupt handling and the callback simply inspects the returned buffer as - necessary. To enable this callback point the struct - usbnet member “un_intr” to a struct - usbnet_intr structure with these members set:

-
-
uni_buf
-
Data buffer for interrupt status replies.
-
uni_bufsz
-
Size of the above buffer.
-
uni_interval
-
Interval in millieconds.
-
-

These values will be passed to - ().

-
-
-

-

The porting of an older driver to the - usbnet framework is largely an effort in deleting - code. The process involves making these changes:

-
-
Headers
-
Many headers are included in usbnet.h and can be - removed from the driver, as well as headers no longer used, such as - callout.h and rndsource.h, - etc.
-
Device softc
-
The majority of the driver's existing “softc” structure can - likely be replaced with usage of struct usbnet and - its related functionality. This includes at least the device_t pointer, - Ethernet address, the ethercom and mii_data structures, end point - descriptors, usbd device, interface, and task and callout structures (both - these probably go away entirely) and all the associated watchdog handling, - timevals, list size, buffer size and xfer flags for both Rx, and Tx, and - interrupt notices, interface flags, device link, PHY number, chain data, - locks including Rx, Tx, and MII. There is a driver-only - “un_flags” in the usbnet structure - available for drivers to use. -

Many drivers can use the - usbnet structure as the device private storage - passed to CFATTACH_DECL_NEW. Many internal - functions to the driver may look better if switched to operate on the - device's usbnet as, for example, the - usbd_device value is now available (and must be - set by the driver) in the usbnet, which may be - needed for any call to - (). - The standard endpoint values must be stored in the - usbnet “un_ed[]” array.

-

As usbnet manages xfer chains all code - related to the opening, closing, aborting and transferring of data on - pipes is performed by the framework based upon the buffer size and more - provided in subnet, so all code related to them - should be deleted.

-
-
Interface setup
-
The vast majority of interface-specific code should be deleted. For - device-specific interface values, the ifnet flags - and exflags can be set, as well as the ethercom - “ec_capabilities” member, before calling - (). - All calls to - (), - mii_attach(), - (), - (), - (), - (), - (), - and - () - should be eliminated. The device “ioctl” routine can use the - default handling with a callback for additional device-specific - programming (multicast filters, etc.), which can be empty, or, the - override ioctl can be used for heavier requirements. The device - “stop” routine is replaced with a simple call that turns off - the device-specific transmitter and receiver if necessary, as the - framework handles pipes and transfers and buffers.
-
MII handling
-
For devices with MII support the three normal callbacks (read, write, and - status change) must be converted to usbnet. Local - “link” variables need to be replaced with accesses to - usbnet_set_link() and - usbnet_havelink(). Other ifmedia callbacks that - were passed to ifmedia_init() should be deleted - and any work moved into “uno_statchg”.
-
Receive and Transmit
-
The usbnet framework handles the majority of - handling of both network directions. The interface init routine should - keep all of the device-specific setup but replace all pipe management with - a call to - (). - The typical receive handling will normally be replaced with a receive loop - function that can accept one or more packets, “uno_rx_loop”, - which can use either usbnet_enqueue() or - usbnet_input() to pass the packets up to higher - layers. The typical interface “if_start” function and any - additional functions used will normally be replaced with a relatively - simple “uno_tx_prepare” function that simply converts an - mbuf into a usbnet_chain - useful for this device that will be passed onto - (). - The framework's handling of the Tx interrupt is all internal.
-
Interrupt pipe handling
-
For devices requiring special handling of the interrupt pipe (i.e., they - use the usbd_open_pipe_intr() method), most of the - interrupt handler should be deleted, leaving only code that inspects the - result of the interrupt transfer.
-
Common errors
-
It's common to forget to set link active on devices with MII. Be sure to - call usbnet_set_link() during any status change - event. -

Many locking issues are hidden without - LOCKDEBUG, including hard-hangs. It's highly - recommended to develop with LOCKDEBUG.

-

The usbnet “un_ed” array - is unsigned and should use “0” as the no-endpoint - value.

-
-
-
-
-

-

usb(4), driver(9), - usbd_status(9), usbdi(9)

-
-
-

-

This usbnet interface first appeared in - NetBSD 9.0. Portions of the original design are - based upon ideas from Nick Hudson - <skrll@NetBSD.org>.

-
-
-

-

Matthew R. Green - <mrg@eterna23.net>

-
-
- - - - - -
March 15, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/uvm.9 3.html b/static/netbsd/man9/uvm.9 3.html deleted file mode 100644 index 19108045..00000000 --- a/static/netbsd/man9/uvm.9 3.html +++ /dev/null @@ -1,580 +0,0 @@ - - - - - - -
UVM(9)Kernel Developer's ManualUVM(9)
-
-
-

-

uvm — virtual - memory system external interface

-
-
-

-

#include - <sys/param.h> -
- #include <uvm/uvm.h>

-
-
-

-

The UVM virtual memory system manages access to the computer's - memory resources. User processes and the kernel access these resources - through UVM's external interface. UVM's external interface includes - functions that:

-

-
    -
  • initialize UVM sub-systems
    • -
  • manage virtual address spaces
    • -
  • resolve page faults
    • -
  • memory map files and devices
    • -
  • perform uio-based I/O to virtual memory
    • -
  • allocate and free kernel virtual memory
    • -
  • allocate and free physical memory
    • -
-

In addition to exporting these services, UVM has two kernel-level - processes: pagedaemon and swapper. The pagedaemon process sleeps until - physical memory becomes scarce. When that happens, pagedaemon is awoken. It - scans physical memory, paging out and freeing memory that has not been - recently used. The swapper process swaps in runnable processes that are - currently swapped out, if there is room.

-

There are also several miscellaneous functions.

-
-
-

-
-
void
-
(void);
-
void
-
uvm_init_limits(struct lwp - *l);
-
void
-
uvm_setpagesize(void);
-
void
-
uvm_swap_init(void);
-
-

() - sets up the UVM system at system boot time, after the console has been - setup. It initializes global state, the page, map, kernel virtual memory - state, machine-dependent physical map, kernel memory allocator, pager and - anonymous memory sub-systems, and then enables paging of kernel objects.

-

() - initializes process limits for the named process. This is for use by the - system startup for process zero, before any other processes are created.

-

() - does early boot initialization. This currently includes: - () - which initializes the uvmexp members pagesize (if not already done by - machine-dependent code), pageshift and pagemask. - () - which initialises the uvm_hotplug(9) subsystem. It should - be called by machine-dependent code early in the - () - call (see pmap(9)).

-

() - initializes the swap sub-system.

-
-
-

-

See uvm_map(9).

-
-
-

-
-
int
-
uvm_fault(struct vm_map - *orig_map, vaddr_t vaddr, - vm_prot_t access_type);
-
-

() - is the main entry point for faults. It takes orig_map - as the map the fault originated in, a vaddr offset - into the map the fault occurred, and access_type - describing the type of access requested. uvm_fault() - returns a standard UVM return value.

-
-
-

-

See ubc(9).

-
-
-

-
-
int
-
uvm_io(struct vm_map *map, - struct uio *uio);
-
-

() - performs the I/O described in uio on the memory - described in map.

-
-
-

-

See uvm_km(9).

-
-
-

-
-
struct vm_page *
-
uvm_pagealloc(struct uvm_object - *uobj, voff_t off, struct - vm_anon *anon, int flags);
-
void
-
uvm_pagerealloc(struct vm_page - *pg, struct uvm_object *newobj, - voff_t newoff);
-
void
-
uvm_pagefree(struct vm_page - *pg);
-
int
-
uvm_pglistalloc(psize_t - size, paddr_t low, paddr_t - high, paddr_t alignment, - paddr_t boundary, struct pglist - *rlist, int nsegs, int - waitok);
-
void
-
uvm_pglistfree(struct pglist - *list);
-
void
-
uvm_page_physload(paddr_t - start, paddr_t end, paddr_t - avail_start, paddr_t avail_end, - int free_list);
-
-

() - allocates a page of memory at virtual address off in - either the object uobj or the anonymous memory - anon, which must be locked by the caller. Only one of - uobj and anon can be non - NULL. Returns NULL when no - page can be found. The flags can be any of

-
-
#define UVM_PGA_USERESERVE      0x0001  /* ok to use reserve pages */
-#define UVM_PGA_ZERO            0x0002  /* returned page must be zero'd */
-
-

UVM_PGA_USERESERVE means to allocate a - page even if that will result in the number of free pages being lower than - uvmexp.reserve_pagedaemon (if the current thread is - the pagedaemon) or uvmexp.reserve_kernel (if the - current thread is not the pagedaemon). UVM_PGA_ZERO - causes the returned page to be filled with zeroes, either by allocating it - from a pool of pre-zeroed pages or by zeroing it in-line as necessary.

-

() - reallocates page pg to a new object - newobj, at a new offset - newoff.

-

() - frees the physical page pg. If the content of the page - is known to be zero-filled, caller should set - PG_ZERO in pg->flags so that the page allocator - will use the page to serve future UVM_PGA_ZERO - requests efficiently.

-

() - allocates a list of pages for size size byte under - various constraints. low and - high describe the lowest and highest addresses - acceptable for the list. If alignment is non-zero, it - describes the required alignment of the list, in power-of-two notation. If - boundary is non-zero, no segment of the list may cross - this power-of-two boundary, relative to zero. nsegs is - the maximum number of physically contiguous segments. If - waitok is non-zero, the function may sleep until - enough memory is available. (It also may give up in some situations, so a - non-zero waitok does not imply that - uvm_pglistalloc() cannot return an error.) The - allocated memory is returned in the rlist list; the - caller has to provide storage only, the list is initialized by - uvm_pglistalloc().

-

() - frees the list of pages pointed to by list. If the - content of the page is known to be zero-filled, caller should set - PG_ZERO in pg->flags so that the page allocator - will use the page to serve future UVM_PGA_ZERO - requests efficiently.

-

() - loads physical memory segments into VM space on the specified - free_list. It must be called at system boot time to - set up physical memory management pages. The arguments describe the - start and end of the physical - addresses of the segment, and the available start and end addresses of pages - not already in use. If a system has memory banks of different speeds the - slower memory should be given a higher free_list - value.

-
-
-

-
-
void
-
uvm_pageout(void);
-
void
-
uvm_scheduler(void);
-
-

() - is the main loop for the page daemon.

-

() - is the process zero main loop, which is to be called after the system has - finished starting other processes. It handles the swapping in of runnable, - swapped out processes in priority order.

-
-
-

-
-
int
-
uvm_loan(struct vm_map *map, - vaddr_t start, vsize_t len, - void *v, int flags);
-
void
-
uvm_unloan(void *v, - int npages, int flags);
-
-

() - loans pages in a map out to anons or to the kernel. - map should be unlocked, start - and len should be multiples of - PAGE_SIZE. Argument flags - should be one of

-
-
#define UVM_LOAN_TOANON       0x01    /* loan to anons */
-#define UVM_LOAN_TOPAGE       0x02    /* loan to kernel */
-
-

v should be pointer to array - of pointers to struct anon or - struct vm_page, as appropriate. The caller has to - allocate memory for the array and ensure it's big enough to hold - len / PAGE_SIZE pointers. Returns 0 for success, or - appropriate error number otherwise. Note that wired pages can't be loaned - out and - () - will fail in that case.

-

() - kills loans on pages or anons. The v must point to the - array of pointers initialized by previous call to - uvm_loan(). npages should - match number of pages allocated for loan, this also matches number of items - in the array. Argument flags should be one of

-
-
#define UVM_LOAN_TOANON       0x01    /* loan to anons */
-#define UVM_LOAN_TOPAGE       0x02    /* loan to kernel */
-
-

and should match what was used for previous call - to - ().

-
-
-

-
-
struct uvm_object *
-
uao_create(vsize_t size, - int flags);
-
void
-
uao_detach(struct uvm_object - *uobj);
-
void
-
uao_reference(struct uvm_object - *uobj);
-
bool
-
uvm_chgkprot(void *addr, - size_t len, int rw);
-
void
-
uvm_kernacc(void *addr, - size_t len, int rw);
-
int
-
uvm_vslock(struct vmspace - *vs, void *addr, size_t - len, vm_prot_t prot);
-
void
-
uvm_vsunlock(struct vmspace - *vs, void *addr, size_t - len);
-
void
-
uvm_meter(void);
-
void
-
uvm_proc_fork(struct proc - *p1, struct proc *p2, bool - shared);
-
int
-
uvm_grow(struct proc *p, - vaddr_t sp);
-
void
-
uvn_findpages(struct uvm_object - *uobj, voff_t offset, int - *npagesp, struct vm_page **pps, - int flags);
-
void
-
uvm_vnp_setsize(struct vnode - *vp, voff_t newsize);
-
-

The - (), - (), - and uao_reference() functions operate on anonymous - memory objects, such as those used to support System V shared memory. - uao_create() returns an object of size - size with flags:

-
-
#define UAO_FLAG_KERNOBJ        0x1     /* create kernel object */
-#define UAO_FLAG_KERNSWAP       0x2     /* enable kernel swap */
-
-

which can only be used once each at system boot - time. - () - creates an additional reference to the named anonymous memory object. - () - removes a reference from the named anonymous memory object, destroying it if - removing the last reference.

-

() - changes the protection of kernel memory from addr to - addr + len to the value of rw. - This is primarily useful for debuggers, for setting breakpoints. This - function is only available with options KGDB.

-

() - checks the access at address addr to - addr + len for rw access in the - kernel address space.

-

() - and - () - control the wiring and unwiring of pages for process p - from addr to addr + len. These - functions are normally used to wire memory for I/O.

-

() - calculates the load average.

-

() - forks a virtual address space for process' (old) p1 - and (new) p2. If the shared - argument is non zero, p1 shares its address space with p2, otherwise a new - address space is created. This function currently has no return value, and - thus cannot fail. In the future, this function will be changed to allow it - to fail in low memory conditions.

-

() - increases the stack segment of process p to include - sp.

-

() - looks up or creates pages in uobj at offset - offset, marks them busy and returns them in the - pps array. Currently uobj must - be a vnode object. The number of pages requested is pointed to by - npagesp, and this value is updated with the actual - number of pages returned. The flags can be any bitwise inclusive-or of:

-

-
-
-
-
Zero pseudo-flag meaning return all pages.
-
-
Don't sleep — yield NULL for busy pages or - for uncached pages for which allocation would sleep.
-
-
Don't allocate — yield NULL for uncached - pages.
-
-
Don't use cached pages — yield NULL - instead.
-
-
Don't yield read-only pages — yield NULL - for pages marked PG_READONLY.
-
-
Don't yield clean pages — stop early at the first clean one. As a - side effect, mark yielded dirty pages clean. Caller must write them to - permanent storage before unbusying.
-
-
Traverse pages in reverse order. If - () - returns early, it will have filled - *npagesp entries at the end - of pps rather than the beginning.
-
-
-

() - sets the size of vnode vp to - newsize. Caller must hold a reference to the vnode. If - the vnode shrinks, pages no longer used are discarded.

-
-
-

-
-
paddr_t
-
atop(paddr_t pa);
-
paddr_t
-
ptoa(paddr_t pn);
-
paddr_t
-
round_page(address);
-
paddr_t
-
trunc_page(address);
-
-

The - () macro - converts a physical address pa into a page number. The - () - macro does the opposite by converting a page number pn - into a physical address.

-

() - and - () - macros return a page address boundary from rounding - address up and down, respectively, to the nearest page - boundary. These macros work for either addresses or byte counts.

-
-
-

-

UVM provides support for the CTL_VM domain - of the sysctl(3) hierarchy. It handles the - VM_LOADAVG, VM_METER, - VM_UVMEXP, and VM_UVMEXP2 - nodes, which return the current load averages, calculates current VM totals, - returns the uvmexp structure, and a kernel version independent view of the - uvmexp structure, respectively. It also exports a number of tunables that - control how much VM space is allowed to be consumed by various tasks. The - load averages are typically accessed from userland using the - getloadavg(3) function. The uvmexp structure has all - global state of the UVM system, and has the following members:

-
-
/* vm_page constants */
-int pagesize;   /* size of a page (PAGE_SIZE): must be power of 2 */
-int pagemask;   /* page mask */
-int pageshift;  /* page shift */
-
-/* vm_page counters */
-int npages;     /* number of pages we manage */
-int free;       /* number of free pages */
-int paging;     /* number of pages in the process of being paged out */
-int wired;      /* number of wired pages */
-int reserve_pagedaemon; /* number of pages reserved for pagedaemon */
-int reserve_kernel; /* number of pages reserved for kernel */
-
-/* pageout params */
-int freemin;    /* min number of free pages */
-int freetarg;   /* target number of free pages */
-int inactarg;   /* target number of inactive pages */
-int wiredmax;   /* max number of wired pages */
-
-/* swap */
-int nswapdev;   /* number of configured swap devices in system */
-int swpages;    /* number of PAGE_SIZE'ed swap pages */
-int swpginuse;  /* number of swap pages in use */
-int nswget;     /* number of times fault calls uvm_swap_get() */
-int nanon;      /* number total of anon's in system */
-int nfreeanon;  /* number of free anon's */
-
-/* stat counters */
-int faults;             /* page fault count */
-int traps;              /* trap count */
-int intrs;              /* interrupt count */
-int swtch;              /* context switch count */
-int softs;              /* software interrupt count */
-int syscalls;           /* system calls */
-int pageins;            /* pagein operation count */
-                        /* pageouts are in pdpageouts below */
-int pgswapin;           /* pages swapped in */
-int pgswapout;          /* pages swapped out */
-int forks;              /* forks */
-int forks_ppwait;       /* forks where parent waits */
-int forks_sharevm;      /* forks where vmspace is shared */
-
-/* fault subcounters */
-int fltnoram;   /* number of times fault was out of ram */
-int fltnoanon;  /* number of times fault was out of anons */
-int fltpgwait;  /* number of times fault had to wait on a page */
-int fltpgrele;  /* number of times fault found a released page */
-int fltrelck;   /* number of times fault relock called */
-int fltrelckok; /* number of times fault relock is a success */
-int fltanget;   /* number of times fault gets anon page */
-int fltanretry; /* number of times fault retrys an anon get */
-int fltamcopy;  /* number of times fault clears "needs copy" */
-int fltnamap;   /* number of times fault maps a neighbor anon page */
-int fltnomap;   /* number of times fault maps a neighbor obj page */
-int fltlget;    /* number of times fault does a locked pgo_get */
-int fltget;     /* number of times fault does an unlocked get */
-int flt_anon;   /* number of times fault anon (case 1a) */
-int flt_acow;   /* number of times fault anon cow (case 1b) */
-int flt_obj;    /* number of times fault is on object page (2a) */
-int flt_prcopy; /* number of times fault promotes with copy (2b) */
-int flt_przero; /* number of times fault promotes with zerofill (2b) */
-
-/* daemon counters */
-int pdwoke;     /* number of times daemon woke up */
-int pdrevs;     /* number of times daemon rev'd clock hand */
-int pdfreed;    /* number of pages daemon freed since boot */
-int pdscans;    /* number of pages daemon scanned since boot */
-int pdanscan;   /* number of anonymous pages scanned by daemon */
-int pdobscan;   /* number of object pages scanned by daemon */
-int pdreact;    /* number of pages daemon reactivated since boot */
-int pdbusy;     /* number of times daemon found a busy page */
-int pdpageouts; /* number of times daemon started a pageout */
-int pddeact;    /* number of pages daemon deactivates */
-
-
-
-

-

uvm_chgkprot() is only available if the - kernel has been compiled with options KGDB.

-

All structure and types whose names begin with “vm_” - will be renamed to “uvm_”.

-
-
-

-

swapctl(2), getloadavg(3), - kvm(3), sysctl(3), - ddb(4), options(4), - memoryallocators(9), pmap(9), - ubc(9), uvm_km(9), - uvm_map(9)

-

Charles D. Cranor and - Gurudatta M. Parulkar, The UVM - Virtual Memory System, Proceedings of the USENIX - Annual Technical Conference, USENIX Association, - http://www.usenix.org/event/usenix99/full_papers/cranor/cranor.pdf, - 117-130, June 6-11, - 1999.

-
-
-

-

UVM is a new VM system developed at Washington University in St. - Louis (Missouri). UVM's roots lie partly in the Mach-based - 4.4BSD VM system, the - FreeBSD VM system, and the SunOS 4 VM system. UVM's - basic structure is based on the 4.4BSD VM system. - UVM's new anonymous memory system is based on the anonymous memory system - found in the SunOS 4 VM (as described in papers published by Sun - Microsystems, Inc.). UVM also includes a number of features new to - BSD including page loanout, map entry passing, - simplified copy-on-write, and clustered anonymous memory pageout. UVM is - also further documented in an August 1998 dissertation by Charles D. - Cranor.

-

UVM appeared in NetBSD 1.4.

-
-
-

-

Charles D. Cranor - <chuck@ccrc.wustl.edu> - designed and implemented UVM.

-

Matthew Green - <mrg@eterna23.net> - wrote the swap-space management code and handled the logistical issues - involved with merging UVM into the NetBSD source - tree.

-

Chuck Silvers - <chuq@chuq.com> - implemented the aobj pager, thus allowing UVM to support System V shared - memory and process swapping.

-
-
- - - - - -
March 23, 2015NetBSD 10.1
diff --git a/static/netbsd/man9/uvm_hotplug.9 3.html b/static/netbsd/man9/uvm_hotplug.9 3.html deleted file mode 100644 index d42fe4b1..00000000 --- a/static/netbsd/man9/uvm_hotplug.9 3.html +++ /dev/null @@ -1,443 +0,0 @@ - - - - - - -
UVM_HOTPLUG(9)Kernel Developer's ManualUVM_HOTPLUG(9)
-
-
-

-

uvm_physseg_init, - uvm_physseg_valid_p, - uvm_physseg_get_start, - uvm_physseg_get_end, - uvm_physseg_get_avail_start, - uvm_physseg_get_avail_end, - uvm_physseg_get_pg, - uvm_physseg_get_pmseg, - uvm_physseg_get_free_list, - uvm_physseg_get_start_hint, - uvm_physseg_set_start_hint, - uvm_physseg_get_next, - uvm_physseg_get_prev, - uvm_physseg_get_first, - uvm_physseg_get_last, - uvm_physseg_get_highest_frame, - uvm_physseg_find, - uvm_page_physload, - uvm_page_physunload, - uvm_page_physunload_force, - uvm_physseg_plug, - uvm_physseg_unplug, - uvm_physseg_set_avail_start, - uvm_physseg_set_avail_end — - memory hotplug manager

-
-
-

-

#include - <uvm/uvm_physseg.h>

-

void -
- uvm_physseg_init(void);

-

uvm_physseg_t -
- uvm_page_physload(paddr_t - start, paddr_t end, - paddr_t avail_start, - paddr_t avail_end, - int free_list);

-

bool -
- uvm_page_physunload(uvm_physseg_t - upm, int free_list, - paddr_t *paddrp);

-

bool -
- uvm_page_physunload_force(uvm_physseg_t - upm, int free_list, - paddr_t *paddrp);

-

bool -
- uvm_physseg_plug(paddr_t - pfn, size_t npages, - uvm_physseg_t *upmp);

-

bool -
- uvm_physseg_unplug(paddr_t - pfn, size_t - npages);

-
-
-

-

These utility routines provide the ability to tell - uvm(9) about system memory segments. When the kernel is - compiled with 'options UVM_HOTPLUG', memory segments - are handled in a dynamic data structure (rbtree(3)) - compared to a static array when not. This enables kernel code to add or - remove information about memory segments at any point after boot - thus - "hotplug".

-

(), - uvm_page_physunload(), and - uvm_page_physunload_force() are legacy interfaces - which may be removed in the future. They must never be used after - uvm_init(9).

-

: - This is an experimental feature and should not be used in production - environments. Furthermore, attempting to "hotplug" without - 'options UVM_HOTPLUG' after boot will almost - certainly end in a panic(9).

-
-
-

-
-

-

The function - () - initializes the hotplug subsystem. This is expected to happen exactly once, - at boot time, and from MD code.

-
-
-

-

uvm_page_physload() registers - uvm(9) with a memory segment span, and on a specified - free_list. It must be called at system boot time as - part of setting up memory management. The arguments describe the start and - end of the physical addresses of the segment, and the available start and - end addresses of pages not already in use. If a system has memory banks of - different speeds the slower memory should be given a higher - free_list value.

-
-
-
start
-
Starting page frame number of the physical memory segments.
-
end
-
Ending page frame number of the physical memory segments.
-
avail_start
-
Available starting page frame number of the physical memory segments.
-
avail_end
-
Available ending page frame number of the physical memory segments.
-
free_list
-
The free list types are defined in the Machine Dependent code.
-
-
-

This function returns a valid - uvm_physseg_t handle when a successful plug occurs, - else it will return UVM_PHYSSEG_TYPE_INVALID when - the plug fails.

-

() - registers uvm(9) with a memory segment span. It can also - be called to initiate a hotplug and register a newly "hotplugged" - physical memory range into the VM. Unlike - uvm_page_physload() this function can, if - 'options UVM_HOTPLUG' is enabled at compile time, be - used after uvm_init(9). The arguments describe the start - page frame, the number of pages to plug starting from the start page frame - and an optional return variable, which points to a valid - uvm_physseg_t handle when a successful plug - occurs.

-
-
-
pfn
-
Starting page frame number of the physical memory segment.
-
npages
-
Total number of pages from the starting page frame number to plug in.
-
upmp
-
If upmp is not NULL, then on a successful plug, a - valid pointer to the uvm_physseg_t handle for the segment which was - plugged is returned.
-
-
-

This function returns true when a successful - plug occurs, false otherwise.

-
-
-

-

The functions - (), - uvm_page_physunload_force(), and - uvm_physseg_unplug() make uvm(9) - forget about previously registered memory segments or portions of such.

-

() - unloads pages from a segment (from the front or from the back) depending on - its availability. When the last page is removed, the segment handle is - invalidated and supporting metadata is freed.

-

Note: This function can only be used - during boot time. Pages, once unloaded, are unregistered from uvm and are - therefore assumed to be managed by the code which called - (9) - (usually boot time MD code, for boottime memory "allocation").

-

The arguments are:

-
-
-
upm
-
The handle identifying segment from which we are trying to unload - memory.
-
free_list
-
The free list types are defined in the Machine Dependent code.
-
paddrp
-
The pointer to the physical address that was unloaded.
-
-
-

If the unload was successful, true is - returned, false otherwise.

-

() - unconditionally unloads pages from a segment. When the last page is removed, - the segment handle is invalidated and supporting metadata is freed.

-

Note: This function can only be - used during boot time. Pages, once unloaded, are unregistered from uvm and - are therefore assumed to be managed by the code which called - (9) - (usually boot time MD code, for boottime memory "allocation").

-

The arguments are:

-
-
-
upm
-
The handle identifying segment from which we are trying to unload - memory.
-
free_list
-
The free list types are defined in the Machine Dependent code.
-
paddrp
-
The pointer to the physical address that was unloaded.
-
-
-

If the unload was successful true is - returned, false otherwise.

-

() - can be called to unplug an existing physical memory segment. Unlike - uvm_page_physunload() and - uvm_page_physunload_force(), it can be called after - uvm_init(9), if 'options - UVM_HOTPLUG' is enabled at compile time. - (9) - makes no effort to manage the state of the underlying physical memory. It is - up to the caller to ensure that it is not in use, either by - uvm(9), or by any other sub-system. Further, any hardware - quiescing that may be required is the responsibility of MD code. The - arguments describe the start page frame and the number of pages to unplug. - The arguments are:

-
-
-
pfn
-
Starting page frame number of the physical memory segment.
-
npages
-
Total number of pages from the starting page frame number to unplug.
-
-
-

Returns true or false - depending on success or failure respectively.

-
-
-
-

-
-
bool
-
(uvm_physseg_t - upm)
-
paddr_t
-
uvm_physseg_get_start(uvm_physseg_t - upm)
-
paddr_t
-
uvm_physseg_get_end(uvm_physseg_t - upm)
-
paddr_t
-
uvm_physseg_get_avail_start(uvm_physseg_t - upm)
-
paddr_t
-
uvm_physseg_get_avail_end(uvm_physseg_t - upm)
-
struct vm_page *
-
uvm_physseg_get_pg(uvm_physseg_t - upm, paddr_t index)
-
struct pmap_physseg - *
-
(uvm_physseg_t - upm)
-
int
-
uvm_physseg_get_free_list(uvm_physseg_t - upm)
-
u_int
-
uvm_physseg_get_start_hint(uvm_physseg_t - upm)
-
bool
-
uvm_physseg_set_start_hint(uvm_physseg_t - upm, u_int start_hint)
-
uvm_physseg_t
-
uvm_physseg_get_next(uvm_physseg_t - upm)
-
uvm_physseg_t
-
uvm_physseg_get_prev(uvm_physseg_t - upm)
-
uvm_physseg_t
-
uvm_physseg_get_first(void)
-
uvm_physseg_t
-
uvm_physseg_get_last(void)
-
paddr_t
-
uvm_physseg_get_highest_frame(void)
-
paddr_t
-
uvm_physseg_find(paddr - pframe, psize_t *offsetp)
-
void
-
uvm_physseg_set_avail_start(uvm_physseg_t - upm, paddr_t avail_start)
-
void
-
uvm_physseg_set_avail_end(uvm_physseg_t - upm, paddr_t avail_end)
-
-

() - validates a handle that is passed in, returns true if - the given handle is valid, false otherwise.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the starting physical address of the segment. The returned value is - of type paddr_t. In case the handle is invalid the - returned value will match (paddr_t) -1.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the ending physical address of the segment. The returned value is of - type paddr_t. In case the handle is invalid the - returned value will match (paddr_t) -1.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the available starting physical address of the segment. The returned - value is of type paddr_t. In case the handle is - invalid the returned value will match (paddr_t) - -1.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the available ending physical address of the segment. The returned - value is of type paddr_t. In case the handle is - invalid the returned value will match (paddr_t) - -1.

-

() - if a valid uvm_physseg_t handle along with an index - value is passed in, it returns the struct vm_page * - object contained in that location.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the struct pmap_physseg * object contained in - the handle.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the free_list type for which the current - segment is associated with. The returned value is of type - int.

-

() - if a valid uvm_physseg_t handle is passed in, it - returns the start_hint type for the current segment. - The returned value is of type u_int.

-

() - if a valid handle along with the start_hint is passed - in, the value is set in the segment. And a true is - returned to indicate a successful value setting. In case the handle is - invalid a false is returned.

-

() - if a valid handle is passed in, it returns the next valid - uvm_physseg_t handle in the sequence. However if the - handle passed is the last segment in the sequence the function returns - UVM_PHYSSEG_TYPE_INVALID_OVERFLOW. Passing an invalid - handle is not fatal, and returns - UVM_PHYSSEG_TYPE_INVALID.

-

() - if a valid handle is passed in, it returns the previous validh - uvm_physseg_t handle in the sequence. However if the - handle passed is the first segment in the sequence the function returns - UVM_PHYSSEG_TYPE_INVALID_EMPTY. Passing an invalid - handle is not fatal, and returns - UVM_PHYSSEG_TYPE_INVALID.

-

() - returns the first valid uvm_physseg_t handle in the - sequence. However if there are no valid handles in the sequence yet, the - function returns UVM_PHYSSEG_TYPE_INVALID_EMPTY.

-

() - returns the last valid uvm_physseg_t handle in the - sequence. However if there are no valid handles in the sequence yet, the - function returns UVM_PHYSSEG_TYPE_INVALID_EMPTY.

-

() - returns the frame number of the highest registered physical page frame which - is of type paddr_t. XXX: Searching on empty sequences - are not yet processed in the function.

-

() - searches for a given segment containing the page frame - (paddr_t) passed in. If a segment that falls between - starting and ending addresses is found, the corresponding - uvm_physseg_t handle is returned else a - UVM_PHYSSEG_TYPE_INVALID is returned. The second - parameter, if not set to NULL, the offset value of - the page frame passed in with respect to the starting address is set to the - appropriate psize_t value if the search was successful - in finding the segment.

-

() - if a valid uvm_physseg_t handle is passed in along - with the available starting physical address of the segment of type - paddr_t, the value is set in the segment.

-

() - if a valid uvm_physseg_t handle is passed in along - with the available ending physical address of the segment of type - paddr_t, the value is set in the segment.

-
-
-

-

uvm_physseg_plug() and - uvm_physseg_unplug() must never be used after - uvm_init(9) in a kernel build where - 'options UVM_HOTPLUG' is not enabled.

-
-
-

-

Tests for uvm_physseg_init are in - tests/sys/uvm.

-

Unit / functional tests are in - tests/sys/uvm/t_uvm_physseg.c. These tests focus on - the expected working of the uvm_physseg_init API and - its utility functions.

-

Load tests can be found in - tests/sys/uvm/t_uvm_physseg_load.c. These tests - focus on stressing the uvm_physseg_init - implementation in order to make performance comparisons between kernel - builds with and without 'options UVM_HOTPLUG'

-
-
-

-

The uvm hotplug feature is implemented in the file - sys/uvm/uvm_physseg.c. The uvm hotplug API is - exported via sys/uvm/uvm_physseg.h.

-
-
-

-

extent(9), free(9), - malloc(9), memoryallocators(9), - uvm(9)

-
-
-

-

This API emerged out of the need to insert new pages at runtime in - the Xen x86/balloon(4) driver.

-
-
-

-

Cherry G. Mathew - <cherry@NetBSD.org> - designed and integrated the API.

-

Santhosh N. Raju - <santhosh.raju@gmail.com> - implemented the dynamic segment handling code and all tests for this - API.

-

Nick Hudson - <skrll@NetBSD.org> - contributed bugfixes and testing on a wide range of hardware ports.

-
-
- - - - - -
January 17, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/uvm_map.9 3.html b/static/netbsd/man9/uvm_map.9 3.html deleted file mode 100644 index d50fc351..00000000 --- a/static/netbsd/man9/uvm_map.9 3.html +++ /dev/null @@ -1,318 +0,0 @@ - - - - - - -
UVM_MAP(9)Kernel Developer's ManualUVM_MAP(9)
-
-
-

-

uvm_map — virtual - address space management interface

-
-
-

-

#include - <sys/param.h> -
- #include <uvm/uvm.h>

-

int -
- uvm_map(struct - vm_map *map, vaddr_t - *startp, vsize_t - size, struct uvm_object - *uobj, voff_t - uoffset, vsize_t - align, uvm_flag_t - flags);

-

void -
- uvm_unmap(struct - vm_map *map, vaddr_t - start, vaddr_t - end);

-

int -
- uvm_map_pageable(struct - vm_map *map, vaddr_t - start, vaddr_t end, - bool new_pageable, - int lockflags);

-

bool -
- uvm_map_checkprot(struct - vm_map *map, vaddr_t - start, vaddr_t end, - vm_prot_t - protection);

-

int -
- uvm_map_protect(struct - vm_map *map, vaddr_t - start, vaddr_t end, - vm_prot_t new_prot, - bool set_max);

-

int -
- uvm_map_protect_user(struct - lwp *l, vaddr_t - start, vaddr_t end, - vm_prot_t new_prot);

-

int -
- uvm_deallocate(struct - vm_map *map, vaddr_t - start, vsize_t - size);

-

struct vmspace * -
- uvmspace_alloc(vaddr_t - min, vaddr_t - max);

-

void -
- uvmspace_exec(struct - lwp *l, vaddr_t - start, vaddr_t - end);

-

struct vmspace * -
- uvmspace_fork(struct - vmspace *vm);

-

void -
- uvmspace_free(struct - vmspace *vm);

-

void -
- uvmspace_share(struct - proc *p1, struct proc - *p2);

-

vaddr_t -
- uvm_uarea_alloc(void);

-

void -
- uvm_uarea_free(vaddr_t - uaddr);

-

vaddr_t -
- uvm_uarea_system_alloc(void);

-

void -
- uvm_uarea_system_free(vaddr_t - uaddr);

-
-
-

-

The UVM facility for virtual address space management.

-
-
-

-

() - establishes a valid mapping in map map, which must be - unlocked. The new mapping has size size, which must be - a multiple of PAGE_SIZE.

-

The uobj and uoffset - arguments can have four meanings:

-
    -
  • When uobj is - NULL and uoffset is - UVM_UNKNOWN_OFFSET, - () - does not use the machine-dependent PMAP_PREFER - function.
    • -
  • When uobj is NULL and - uoffset is any other value, it is used as the hint - to PMAP_PREFER.
    • -
  • When uobj is not NULL and - uoffset is - UVM_UNKNOWN_OFFSET, - uvm_map() finds the offset based upon the virtual - address, passed as startp.
    • -
  • When uobj is not NULL and - uoffset is any other value, then a regular mapping - is performed at this offset. The start address of the map will be returned - in startp.
    • -
-If uobj is supplied, then - uvm_map() - - the caller's reference to uobj on success; - uvm_unmap() will release it when removing this - mapping. On failure, uvm_map() leaves the reference - count of uobj unmodified. -

align specifies alignment of mapping unless - UVM_FLAG_FIXED is specified in - flags. align must be a power of - 2.

-

flags passed to - () - are typically created using the - (vm_prot_t - prot, vm_prot_t maxprot, - vm_inherit_t inh, int advice, - int flags) macro, which uses the following values.

-

The values that prot and - maxprot can take are:

-
-
-
UVM_PROT_NONE
-
No protection bits.
-
UVM_PROT_R
-
Read.
-
UVM_PROT_W
-
Write.
-
UVM_PROT_X
-
Exec.
-
UVM_PROT_MASK
-
Mask to extraction the protection bits.
-
-
-Additionally, the following constants for ORed values are available: - UVM_PROT_RW, UVM_PROT_RX, - UVM_PROT_WX and UVM_PROT_RWX. -

The values that inh can take are:

-
-
-
UVM_INH_SHARE
-
Share the map.
-
UVM_INH_COPY
-
Copy the map.
-
UVM_INH_NONE
-
No inheritance.
-
UVM_INH_MASK
-
Mask to extract inherit flags.
-
-
-

The values that advice can take are:

-
-
-
UVM_ADV_NORMAL
-
"Normal" use.
-
UVM_ADV_RANDOM
-
"Random" access likelihood.
-
UVM_ADV_SEQUENTIAL
-
"Sequential" access likelihood.
-
UVM_ADV_MASK
-
Mask to extract the advice flags.
-
-
-

The values that flags can take are:

-
-
-
UVM_FLAG_FIXED
-
Attempt to map on the address specified by startp. - Otherwise, it is used just as a hint.
-
UVM_FLAG_OVERLAY
-
Establish overlay.
-
UVM_FLAG_NOMERGE
-
Do not merge map entries, if such merge is possible.
-
UVM_FLAG_COPYONW
-
Use copy-on-write i.e. do not fault in the pages immediately.
-
UVM_FLAG_AMAPPAD
-
Used for BSS: allocate larger amap, if extending is likely.
-
UVM_FLAG_TRYLOCK
-
Fail if cannot acquire the lock immediately.
-
UVM_FLAG_NOWAIT
-
Not allowed to sleep. Fail, in such case.
-
UVM_FLAG_QUANTUM
-
Indicates that map entry cannot be split once mapped.
-
UVM_FLAG_WAITVA
-
Sleep until VA space is available, if it is not.
-
UVM_FLAG_VAONLY
-
Unmap only VA space. Used by - ().
-
UVM_FLAG_UNMAP
-
Any existing entries in the range for this mapping should be unmapped as - part of creating the new mapping. Use of this flag without also specifying - UVM_FLAG_FIXED is a bug.
-
-
-

The UVM_MAPFLAG macro - arguments can be combined with an or operator. There are several special - purpose macros for checking protection combinations, e.g., the - UVM_PROT_WX. There are also some additional macros - to extract bits from the flags. The UVM_PROTECTION, - UVM_INHERIT, - UVM_MAXPROTECTION and - UVM_ADVICE macros return the protection, - inheritance, maximum protection, and advice, respectively. - () - returns zero on success or error number otherwise.

-

() - removes a valid mapping, from start to - end, in map map, which must be - unlocked.

-

() - changes the pageability of the pages in the range from - start to end in map - map to new_pageable. - uvm_map_pageable() returns zero on success or error - number otherwise.

-

() - checks the protection of the range from start to - end in map map against - protection. This returns either - true or false.

-

() - changes the protection start to - end in map map to - new_prot, also setting the maximum protection to the - region to new_prot if set_max is - true. This function returns a standard UVM return value.

-

() - verifies that the new permissions honor PAX restrictions if applicable and - forwards to uvm_map_protect() on passing.

-

() - deallocates kernel memory in map map from address - start to start + size.

-

() - allocates and returns a new address space, with ranges from - min to max.

-

() - either reuses the address space of thread l (its - process) if there are no other references to it, or creates a new one with - uvmspace_alloc(). The range of valid addresses in - the address space is reset to start through - end.

-

() - creates and returns a new address space based upon the - vm address space, typically used when allocating an - address space for a child process.

-

() - lowers the reference count on the address space vm, - freeing the data structures if there are no other references.

-

() - causes process p2 to share the address space of - p1.

-

() - allocates memory for a u-area (i.e. kernel stack, PCB, etc) and returns the - address.

-

() - frees a u-area allocated with uvm_uarea_alloc().

-

() - and - () - are optimized routines, which are used for kernel threads.

-
-
-

-

pmap(9), uvm(9), - uvm_km(9), vmem(9)

-
-
-

-

UVM and uvm_map first appeared in - NetBSD 1.4.

-
-
- - - - - -
May 20, 2017NetBSD 10.1
diff --git a/static/netbsd/man9/vattr.9 3.html b/static/netbsd/man9/vattr.9 3.html deleted file mode 100644 index 3b467fc3..00000000 --- a/static/netbsd/man9/vattr.9 3.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - -
VATTR(9)Kernel Developer's ManualVATTR(9)
-
-
-

-

vattr, vattr_null - — vnode attributes

-
-
-

-

#include - <sys/param.h> -
- #include <sys/vnode.h>

-

void -
- vattr_null(struct - vattr *vap);

-
-
-

-

Vnode attributes describe attributes of a file or directory - including file permissions, owner, group, size, access time and modification - time.

-

A vnode attribute has the following structure:

-
-
struct vattr {
-        enum vtype      va_type;        /* vnode type (for create) */
-        mode_t          va_mode;        /* files access mode and type */
-        nlink_t         va_nlink;       /* number of references to file */
-        uid_t           va_uid;         /* owner user id */
-        gid_t           va_gid;         /* owner group id */
-        dev_t           va_fsid;        /* file system id (dev for now) */
-        ino_t           va_fileid;      /* file id */
-        u_quad_t        va_size;        /* file size in bytes */
-        long            va_blocksize;   /* blocksize preferred for i/o */
-        struct timespec va_atime;       /* time of last access */
-        struct timespec va_mtime;       /* time of last modification */
-        struct timespec va_ctime;       /* time file changed */
-        struct timespec va_birthtime;   /* time file created */
-        u_long          va_gen;         /* generation number of file */
-        u_long          va_flags;       /* flags defined for file */
-        dev_t           va_rdev;        /* device the special file represents */
-        u_quad_t        va_bytes;       /* bytes of disk space held by file */
-        u_quad_t        va_filerev;     /* file modification number */
-        u_int           va_vaflags;     /* operations flags, see below */
-        long            va_spare;       /* remain quad aligned */
-};
-
-

A field value of VNOVAL represents a field whose - value is unavailable or which is not to be changed. Valid flag values for - - are:

-

-
-
-
VA_UTIMES_NULL
-
utimes argument was NULL
-
VA_EXCLUSIVE
-
exclusive create request
-
-
-

Vnode attributes for a file are set by the vnode operation - VOP_SETATTR(9). Vnode attributes for a file are retrieved - by the vnode operation VOP_GETATTR(9). For more - information on vnode operations see vnodeops(9).

-
-
-

-
-
(vap)
-
Set vnode attributes in vap to VNOVAL.
-
-
-
-

-

vattr_null() is implemented in - sys/kern/vfs_subr.c.

-
-
-

-

intro(9), vfs(9), - vnode(9), vnodeops(9)

-
-
- - - - - -
January 8, 2010NetBSD 10.1
diff --git a/static/netbsd/man9/vfs.9 3.html b/static/netbsd/man9/vfs.9 3.html deleted file mode 100644 index f5ce15c7..00000000 --- a/static/netbsd/man9/vfs.9 3.html +++ /dev/null @@ -1,37 +0,0 @@ - - - - - - -
VFS(9)Kernel Developer's ManualVFS(9)
-
-
-

-

vfs — kernel - interface to file systems

-
-
-

-

The virtual file system, vfs, is the - kernel interface to file systems. The interface specifies the calls for the - kernel to access file systems. It also specifies the core functionality that - a file system must provide to the kernel.

-

The focus of vfs activity is - the and is - discussed in vnode(9). File system operations such as - mounting and syncing are discussed in vfsops(9).

-
-
-

-

intro(9), vfsops(9), - vnode(9), vnodeops(9)

-
-
- - - - - -
September 22, 2001NetBSD 10.1
diff --git a/static/netbsd/man9/vfsops.9 3.html b/static/netbsd/man9/vfsops.9 3.html deleted file mode 100644 index 0466fe6d..00000000 --- a/static/netbsd/man9/vfsops.9 3.html +++ /dev/null @@ -1,461 +0,0 @@ - - - - - - -
VFSOPS(9)Kernel Developer's ManualVFSOPS(9)
-
-
-

-

vfsops, VFS_MOUNT, - VFS_START, VFS_UNMOUNT, - VFS_ROOT, VFS_QUOTACTL, - VFS_STATVFS, VFS_SYNC, - VFS_VGET, VFS_LOADVNODE, - VFS_NEWVNODE, VFS_FHTOVP, - VFS_VPTOFH, VFS_SNAPSHOT, - VFS_SUSPENDCTL — kernel file - system interface

-
-
-

-

#include - <sys/param.h> -
- #include <sys/mount.h> -
- #include <sys/vnode.h>

-

int -
- VFS_MOUNT(struct mount *mp, - const char *path, void *data, - size_t *dlen);

-

int -
- VFS_START(struct - mount *mp, int - flags);

-

int -
- VFS_UNMOUNT(struct - mount *mp, int - mntflags);

-

int -
- VFS_ROOT(struct - mount *mp, int - lktype, struct vnode - **vpp);

-

int -
- VFS_QUOTACTL(struct - mount *mp, struct - quotactl_args *args);

-

int -
- VFS_STATVFS(struct - mount *mp, struct statvfs - *sbp);

-

int -
- VFS_SYNC(struct - mount *mp, int - waitfor, kauth_cred_t - cred);

-

int -
- VFS_VGET(struct - mount *mp, ino_t - ino, int lktype, - struct vnode **vpp);

-

int -
- VFS_LOADVNODE(struct - mount *mp, struct vnode - *vp, const void - *key, size_t - key_len, const void - **new_key);

-

int -
- VFS_NEWVNODE(struct - mount *mp, struct vnode - *dvp, struct vnode - *vp, struct vattr - *vap, kauth_cred_t - cred, void *extra, - size_t *key_len, - const void - **new_key);

-

int -
- VFS_FHTOVP(struct - mount *mp, struct fid - *fhp, int lktype, - struct vnode **vpp);

-

int -
- VFS_VPTOFH(struct - vnode *vp, struct fid - *fhp, size_t - *fh_size);

-

int -
- VFS_SNAPSHOT(struct - mount *mp, struct vnode - *vp, struct timespec - *ts);

-

int -
- VFS_SUSPENDCTL(struct - mount *mp, int - cmd);

-
-
-

-

In a similar fashion to the vnode(9) interface, - all operations that are done on a file system are conducted through a single - interface that allows the system to carry out operations on a file system - without knowing its construction or type.

-

All supported file systems in the kernel have an entry in the - vfs_list_initial table. This table is generated by - config(1) and is a - NULL-terminated list of - vfsops structures. The vfsops structure describes the - operations that can be done to a specific file system type. The following - table lists the elements of the vfsops vector, the corresponding invocation - macro, and a description of the element.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
int (*vfs_mount)()Mount a file system
int (*vfs_start)()Make operational
int (*vfs_unmount)()Unmount a file system
int (*vfs_root)()Get the file system root vnode
int (*vfs_quotactl)()Query/modify space quotas
int (*vfs_statvfs)()Get file system statistics
int (*vfs_sync)()Flush file system buffers
int (*vfs_vget)()Get vnode from file id
int (*vfs_loadvnode)()Initialize vnode with file
int (*vfs_newvnode)()Initialize vnode with new file
int (*vfs_fhtovp)()NFS file handle to vnode lookup
int (*vfs_vptofh)()Vnode to NFS file handle lookup
void (*vfs_init)()-Initialize file system
void (*vfs_reinit)()-Reinitialize file system
void (*vfs_done)()-Cleanup unmounted file system
int (*vfs_mountroot)()-Mount the root file system
int (*vfs_snapshot)()Take a snapshot
int (*vfs_suspendctl)()Suspend or resume
-

Some additional non-function members of the vfsops structure are - the file system name vfs_name and a reference count - vfs_refcount. It is not mandatory for a file system - type to support a particular operation, but it must assign each member - function pointer to a suitable function to do the minimum required of it. In - most cases, such functions either do nothing or return an error value to the - effect that it is not supported. vfs_reinit, - vfs_mountroot, vfs_fhtovp, and - vfs_vptofh may be NULL.

-

At system boot, each file system with an entry in - vfs_list_initial is established and initialized. Each - initialized file system is recorded by the kernel in the list - vfs_list and the file system specific initialization - function vfs_init in its vfsops vector is invoked. - When the file system is no longer needed vfs_done is - invoked to run file system specific cleanups and the file system is removed - from the kernel list.

-

At system boot, the root file system is mounted by invoking the - file system type specific vfs_mountroot function in - the vfsops vector. All file systems that can be mounted as a root file - system must define this function. It is responsible for initializing to list - of mount structures for all future mounted file systems.

-

Kernel state which affects a specific file system type can be - queried and modified using the sysctl(8) interface.

-
-
-

-
-
(mp, - path, data, - dlen)
-
Mount a file system specified by the mount structure - mp on the mount point described by - path. The argument data - contains file system type specific data, while the argument - dlen points to a location specifying the length of - the data. -

() - initializes the mount structure for the mounted file system. This - structure records mount-specific information for the file system and - records the list of vnodes associated with the file system. This - function is invoked both to mount new file systems and to change the - attributes of an existing file system. If the flag - MNT_UPDATE is set in - mp->mnt_flag, the file system should update its - state. This can be used, for instance, to convert a read-only file - system to read-write. The current attributes for a mounted file system - can be fetched by specifying MNT_GETARGS. If - neither MNT_UPDATE or - MNT_GETARGS are specified, a new file system - will attempted to be mounted.

-
-
VFS_START(mp, - flags)
-
Make the file system specified by the mount structure - mp operational. The argument - flags is a set of flags for controlling the - operation of VFS_START(). This function is invoked - after VFS_MOUNT() and before the first access to - the file system.
-
VFS_UNMOUNT(mp, - mntflags)
-
Unmount a file system specified by the mount structure - mp. VFS_UNMOUNT() performs - any file system type specific operations required before the file system - is unmounted, such are flushing buffers. If - MNT_FORCE is specified in the flags - mntflags then open files are forcibly closed. The - function also deallocates space associated with data structure that were - allocated for the file system when it was mounted.
-
VFS_ROOT(mp, - lktype, vpp)
-
Get the root vnode of the file system specified by the mount structure - mp. The vnode is returned in the address given by - vpp, with lock type lktype. - lktype can be LK_NONE, or - LK_SHARED, or - LK_EXCLUSIVE. This function is used by the - pathname translation algorithms when a vnode that has been covered by a - mounted file system is encountered. While resolving the pathname, the - pathname translation algorithm will have to go through the directory tree - in the file system associated with that mount point and therefore requires - the root vnode of the file system.
-
VFS_QUOTACTL(mp, - args)
-
Query/modify user space quotas for the file system specified by the mount - structure mp. The argument structure provides the - operation ID and arguments to perform. This is the same interface as - documented in __quotactl(2) except that the file system - argument has been resolved. All copyin(9) and - copyout(9) processing is handled by code above the file - system.
-
VFS_STATVFS(mp, - sbp)
-
Get file system statistics for the file system specified by the mount - structure mp. A statvfs structure filled with the - statistics is returned in sbp. - VFS_STATVFS() is the file system type specific - implementation of the statvfs(2) and - fstatvfs(2) system calls.
-
VFS_SYNC(mp, - waitfor, cred)
-
Flush file system I/O buffers for the file system specified by the mount - structure mp. The waitfor - argument indicates whether a partial flush or complete flush should be - performed. The argument cred specifies the calling - credentials. VFS_SYNC() does not provide any - return value since the operation can never fail.
-
VFS_VGET(mp, - ino, lktype, - vpp)
-
Get vnode for a file system type specific file id - ino for the file system specified by the mount - structure mp, with lock type - lktype. lktype can be - LK_NONE, or LK_SHARED, or - LK_EXCLUSIVE. The vnode is returned in the address - specified vpp. The function is optional for file - systems which have a unique id number for every file in the file system. - It is used internally by the UFS file system and also by the NFSv3 server - to implement the READDIRPLUS NFS call. If the file system does not support - this function, it should return EOPNOTSUPP.
-
VFS_LOADVNODE(mp, - vp, key, - key_len, new_key)
-
Initialise the vnode vp with the file identified by - the arguments key and key_len - for the file system specified by the mount structure - mp. -

The new key is returned in the address specified by - new_key.

-

Caller of this function assures no other thread will try to - load this file.

-
-
(mp, - dvp, vp, - vap, cred, - extra, key_len, - new_key)
-
Initialise the vnode vp with a new file for the file - system specified by the mount structure mp. -

The argument dvp points to the directory - to create the file in.

-

The argument vap points to the - attributes for the file to create.

-

The argument cred holds the credentials - for the file to create.

-

The argument extra allows the caller to - pass more information about the file to create.

-

The key for the file is returned in the addresses specified by - key_len and new_key.

-
-
(mp, - fhp, lktype, - vpp)
-
Get the vnode for the file handle fhp in the file - system specified by the mount structure mp, with - lock type lktype. lktype can - be LK_NONE, or LK_SHARED, - or LK_EXCLUSIVE. The locked vnode is returned in - vpp. -

When exporting, the call to - () - should follow a call to - (), - which checks if the file is accessible to the client.

-

If file handles are not supported by the file system, this - function must return EOPNOTSUPP.

-
-
(vp, - fhp, fh_size)
-
Get a file handle for the vnode specified by vp. The - file handle is returned in fhp. The contents of the - file handle are defined by the file system and are not examined by any - other subsystems. It should contain enough information to uniquely - identify a file within the file system as well as noticing when a file has - been removed and the file system resources have been recycled for a new - file. -

The parameter fh_size points to the - container size for the file handle. This parameter should be updated to - the size of the finished file handle. Note that it is legal to call this - function with fhp set to - NULL in case fh_size is - zero. In case fh_size indicates a storage space - too small, the storage space required for the file handle corresponding - to vp should be filled in and - E2BIG should be returned.

-

If file handles are not supported by the file system, this - function must return EOPNOTSUPP.

-
-
(mp, - vp, ts)
-
Take a snapshot of the file system specified by the mount structure - mp and make it accessible through the locked vnode - vp. If ts is not - NULL it will receive the time this snapshot was - taken. If the file system does not support this function, it should return - EOPNOTSUPP.
-
VFS_SUSPENDCTL(mp, - cmd)
-
Suspend or resume all operations on this file system. - cmd is either - SUSPEND_SUSPEND to suspend or - SUSPEND_RESUME to resume operations. If the file - system does not support this function, it should return - EOPNOTSUPP.
-
-
-
-

-

The vfs operations are implemented within the files - sys/kern/vfs_subr.c and - sys/kern/vfs_init.c.

-
-
-

-

intro(9), namei(9), - vfs(9), vfssubr(9), - vnode(9), vnodeops(9)

-
-
-

-

The vfs operations vector, its functions and the corresponding - macros appeared in 4.3BSD.

-
-
- - - - - -
August 7, 2020NetBSD 10.1
diff --git a/static/netbsd/man9/video.9 3.html b/static/netbsd/man9/video.9 3.html deleted file mode 100644 index 8177e9c8..00000000 --- a/static/netbsd/man9/video.9 3.html +++ /dev/null @@ -1,182 +0,0 @@ - - - - - - -
VIDEO(9)Kernel Developer's ManualVIDEO(9)
-
-
-

-

video — interface - between low and high level video drivers

-
-
-

-

#include - <dev/video_if.h>

-

device_t -
- video_attach_mi(const - struct video_hw_if *hw_if, - device_t hw_dev);

-

void -
- video_submit_payload(device_t - vl_dev, const struct - video_payload *payload);

-
-
-

-

The video device driver is divided into a high level, machine - independent layer, and a low level hardware dependent layer. The interface - between these is the video_hw_if structure function - pointers called by the video layer, and video layer functions called by the - hardware driver.

-

The high level video driver attaches to the low level driver when - the latter calls video_attach_mi. The - video_hw_if struct is as shown below. - dev is the device struct for the hardware device. - Return value is the video layer device.

-
-
struct video_hw_if {
-	int	(*open)(void *, int); /* open hardware */
-	void	(*close)(void *);     /* close hardware */
-
-	const char *	(*get_devname)(void *);
-
-	int	(*enum_format)(void *, uint32_t, struct video_format *);
-	int	(*get_format)(void *, struct video_format *);
-	int	(*set_format)(void *, struct video_format *);
-	int	(*try_format)(void *, struct video_format *);
-
-	int	(*start_transfer)(void *);
-	int	(*stop_transfer)(void *);
-
-	int	(*control_iter_init)(void *, struct video_control_iter *);
-	int	(*control_iter_next)(void *, struct video_control_iter *);
-	int	(*get_control_desc_group)(void *,
-					  struct video_control_desc_group *);
-	int	(*get_control_group)(void *, struct video_control_group *);
-	int	(*set_control_group)(void *, const struct video_control_group *);
-};
-
-

The upper layer of the video driver allocates buffers for video - samples. The hardware driver submits data to the video layer with - video_submit_payload. vl_dev is - the video layer device returned by - video_attach_mi.

-
-
struct video_payload {
-	const uint8_t	*data;
-	size_t		size;
-	int		frameno;
-	bool		end_of_frame;
-};
-
-
-
data
-
Pointer to the video data for this payload. This may only be a portion of - the data in one video sample or frame.
-
size
-
Size in bytes of the video data in this payload
-
frameno
-
Frame number to which this payload belongs. The hardware driver must - toggle the frame number between 0 and 1 so the video layer can detect - sample or frame boundaries.
-
end_of_frame
-
Optional end of frame marker. If the hardware layer sets this, the video - layer can immediately pass the completed sample or frame to userspace - rather than waiting for the next payload to toggle - frameno.
-
-
-
-

-

The fields of video_hw_if are described in - some more detail below. Some fields are optional and can be set to - NULL if not needed.

-
-
-
optional, is called when the video device is opened. It should initialize - the hardware for I/O. Every successful call to open - is matched by a call to close. Return 0 on success, - otherwise an error code.
-
-
optional, is called when the audio device is closed.
-
-
mandatory, returns a NUL-terminated string naming the device, e.g. a - vendor and product model name.
-
-
mandatory, called with an index from 0 to - max_index - 1. Fills format - with the format description at that index. Returns 0 on success, otherwise - an error code.
-
-
mandatory, fills format with the current video - format. There should be a default format so this function works before and - streaming has begun. Returns 0 on success, otherwise an error code.
-
-
mandatory, sets the format of the video stream based on - format. Fills format with the - actual format used which may not be the same as requested. Returns 0 on - success, otherwise an error code.
-
-
optional, like set_format but does not actually - change the stream format, just checks what is available. Returns 0 on - success, otherwise an error code.
-
-
mandatory, starts the capture of video frames. Incoming video data must be - submitted to the video layer with repeated calls to - ().
-
-
 
-
-
Does nothing at this time.
-
-
Does nothing at this time.
-
-
 
-
-
 
-
-
-
-

-

video(4)

-
-
-

-

Patrick Mahoney - <pat@polycrystal.org>

-
-
-

-

Incomplete. Only supports a single video capture stream. Does not - support output streams. Format handling may change in the future. Control - handling may change. Current design requires copying all incoming video - data.

-
-
- - - - - -
July 24, 2008NetBSD 10.1
diff --git a/static/netbsd/man9/vnodeops.9 3.html b/static/netbsd/man9/vnodeops.9 3.html deleted file mode 100644 index 17e8c6f5..00000000 --- a/static/netbsd/man9/vnodeops.9 3.html +++ /dev/null @@ -1,1441 +0,0 @@ - - - - - - -
VNODEOPS(9)Kernel Developer's ManualVNODEOPS(9)
-
-
-

-

vnodeops, - VOP_LOOKUP, VOP_CREATE, - VOP_MKNOD, VOP_OPEN, - VOP_CLOSE, VOP_ACCESS, - VOP_GETATTR, VOP_SETATTR, - VOP_READ, VOP_WRITE, - VOP_FALLOCATE, VOP_FDISCARD, - VOP_IOCTL, VOP_FCNTL, - VOP_POLL, VOP_KQFILTER, - VOP_REVOKE, VOP_MMAP, - VOP_FSYNC, VOP_SEEK, - VOP_REMOVE, VOP_LINK, - VOP_RENAME, VOP_MKDIR, - VOP_RMDIR, VOP_SYMLINK, - VOP_READDIR, VOP_READLINK, - VOP_ABORTOP, VOP_INACTIVE, - VOP_RECLAIM, VOP_LOCK, - VOP_UNLOCK, VOP_ISLOCKED, - VOP_BMAP, VOP_PRINT, - VOP_PATHCONF, VOP_ADVLOCK, - VOP_WHITEOUT, VOP_GETPAGES, - VOP_PUTPAGES, VOP_STRATEGY, - VOP_BWRITE, VOP_GETEXTATTR, - VOP_SETEXTATTR, - VOP_LISTEXTATTR, - VOP_DELETEEXTATTR — vnode - operations

-
-
-

-

#include - <sys/param.h> -
- #include <sys/buf.h> -
- #include <sys/dirent.h> -
- #include <sys/vnode.h> -
- #include <sys/mount.h> -
- #include <sys/namei.h> -
- #include <sys/unistd.h> -
- #include <sys/fcntl.h> -
- #include <sys/lockf.h> -
- #include <sys/extattr.h>

-

int -
- VOP_LOOKUP(struct - vnode *dvp, struct vnode - **vpp, struct - componentname *cnp);

-

int -
- VOP_CREATE(struct - vnode *dvp, struct vnode - **vpp, struct - componentname *cnp, - struct vattr *vap);

-

int -
- VOP_MKNOD(struct - vnode *dvp, struct vnode - **vpp, struct - componentname *cnp, - struct vattr *vap);

-

int -
- VOP_OPEN(struct - vnode *vp, int - mode, kauth_cred_t - cred);

-

int -
- VOP_CLOSE(struct - vnode *vp, int - fflag, kauth_cred_t - cred);

-

int -
- VOP_ACCESS(struct - vnode *vp, int - mode, kauth_cred_t - cred);

-

int -
- VOP_GETATTR(struct - vnode *vp, struct vattr - *vap, kauth_cred_t - cred);

-

int -
- VOP_SETATTR(struct - vnode *vp, struct vattr - *vap, kauth_cred_t - cred);

-

int -
- VOP_READ(struct - vnode *vp, struct uio - *uio, int ioflag, - kauth_cred_t cred);

-

int -
- VOP_WRITE(struct - vnode *vp, struct uio - *uio, int ioflag, - kauth_cred_t cred);

-

int -
- VOP_FALLOCATE(struct - vnode *vp, off_t - pos, off_t - len);

-

int -
- VOP_FDISCARD(struct - vnode *vp, off_t - pos, off_t - len);

-

int -
- VOP_IOCTL(struct - vnode *vp, u_long - command, void - *data, int fflag, - kauth_cred_t cred);

-

int -
- VOP_FCNTL(struct - vnode *vp, u_int - command, void - *data, int fflag, - kauth_cred_t cred);

-

int -
- VOP_POLL(struct - vnode *vp, int - events);

-

int -
- VOP_KQFILTER(struct - vnode *vp, struct knote - *kn);

-

int -
- VOP_REVOKE(struct - vnode *vp, int - flags);

-

int -
- VOP_MMAP(struct - vnode *vp, vm_prot_t - prot, kauth_cred_t - cred);

-

int -
- VOP_FSYNC(struct - vnode *vp, kauth_cred_t - cred, int flags, - off_t offlo, - off_t offhi);

-

int -
- VOP_SEEK(struct - vnode *vp, off_t - oldoff, off_t - newoff, kauth_cred_t - cred);

-

int -
- VOP_REMOVE(struct - vnode *dvp, struct vnode - *vp, struct componentname - *cnp);

-

int -
- VOP_LINK(struct - vnode *dvp, struct vnode - *vp, struct componentname - *cnp);

-

int -
- VOP_RENAME(struct - vnode *fdvp, struct vnode - *fvp, struct - componentname *fcnp, - struct vnode *tdvp, - struct vnode *tvp, - struct componentname - *tcnp);

-

int -
- VOP_MKDIR(struct - vnode *dvp, struct vnode - **vpp, struct - componentname *cnp, - struct vattr *vap);

-

int -
- VOP_RMDIR(struct - vnode *dvp, struct vnode - *vp, struct componentname - *cnp);

-

int -
- VOP_SYMLINK(struct - vnode *dvp, struct vnode - **vpp, struct - componentname *cnp, - struct vattr *vap, - char *target);

-

int -
- VOP_READDIR(struct - vnode *vp, struct uio - *uio, kauth_cred_t - cred, int *eofflag, - off_t **cookies, - int *ncookies);

-

int -
- VOP_READLINK(struct - vnode *vp, struct uio - *uio, kauth_cred_t - cred);

-

int -
- VOP_ABORTOP(struct - vnode *dvp, struct - componentname *cnp);

-

int -
- VOP_INACTIVE(struct - vnode *vp);

-

int -
- VOP_RECLAIM(struct - vnode *vp);

-

int -
- VOP_LOCK(struct - vnode *vp, int - flags);

-

int -
- VOP_UNLOCK(struct - vnode *vp);

-

int -
- VOP_ISLOCKED(struct - vnode *vp);

-

int -
- VOP_BMAP(struct - vnode *vp, daddr_t - bn, struct vnode - **vpp, daddr_t - *bnp, int - *runp);

-

int -
- VOP_PRINT(struct - vnode *vp);

-

int -
- VOP_PATHCONF(struct - vnode *vp, int - name, register_t - *retval);

-

int -
- VOP_ADVLOCK(struct - vnode *vp, void - *id, int op, - struct flock *fl, - int flags);

-

int -
- VOP_WHITEOUT(struct - vnode *dvp, struct - componentname *cnp, int - flags);

-

int -
- VOP_GETPAGES(struct - vnode *vp, voff_t - offset, struct vm_page - **m, int *count, - int centeridx, - vm_prot_t access_type, - int advice, - int flags);

-

int -
- VOP_PUTPAGES(struct - vnode *vp, voff_t - offlo, voff_t - offhi, int - flags);

-

int -
- VOP_STRATEGY(struct - vnode *vp, struct buf - *bp);

-

int -
- VOP_BWRITE(struct - vnode *vp, struct buf - *bp);

-

int -
- VOP_GETEXTATTR(struct - vnode *vp, int - attrnamespace, const char - *name, struct uio - *uio, size_t *size, - kauth_cred_t cred);

-

int -
- VOP_SETEXTATTR(struct - vnode *vp, int - attrnamespace, const char - *name, struct uio - *uio, kauth_cred_t - cred);

-

int -
- VOP_LISTEXTATTR(struct - vnode *vp, int - attrnamespace, struct uio - *uio, size_t *size, - kauth_cred_t cred);

-

int -
- VOP_DELETEEXTATTR(struct - vnode *vp, int - attrnamespace, const char - *name, kauth_cred_t - cred);

-

Not all header files are required for each function.

-
-
-

-

The vnode operations vector describes what operations can be done - to the file associated with the vnode. The system maintains one vnode - operations vector for each file system type configured into the kernel. The - vnode operations vector contains a pointer to a function for each operation - supported by the file system. Many of the functions described in the vnode - operations vector are closely related to their corresponding system calls. - In most cases, they are called as a result of the system call associated - with the operation being invoked.

-

Functions in the vnode operations vector are invoked using - specialized macros. The following table gives a summary of the - operations.

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VOP_LOOKUPLookup file name in name cache
VOP_CREATECreate a new file
VOP_MKNODMake a new device
VOP_OPENOpen a file
VOP_CLOSEClose a file
VOP_ACCESSDetermine file accessibility
VOP_GETATTRGet file attributes
VOP_SETATTRSet file attributes
VOP_READRead from a file
VOP_WRITEWrite to a file
VOP_FALLOCATEAllocate backing for a file
VOP_FDISCARDDiscard backing for a file
VOP_IOCTLPerform device-specific I/O
VOP_FCNTLPerform file control
VOP_POLLTest if poll event has occurred
VOP_KQFILTERRegister a knote
VOP_REVOKEEliminate vnode activity
VOP_MMAPMap file into user address space
VOP_FSYNCFlush pending data to disk
VOP_SEEKTest if file is seekable
VOP_REMOVERemove a file
VOP_LINKLink a file
VOP_RENAMERename a file
VOP_MKDIRMake a new directory
VOP_RMDIRRemove a directory
VOP_SYMLINKCreate a symbolic link
VOP_READDIRRead directory entry
VOP_READLINKRead contents of a symlink
VOP_ABORTOPAbort pending operation
VOP_INACTIVERelease the inactive vnode
VOP_RECLAIMReclaim vnode for another file
VOP_LOCKSleep until vnode lock is free
VOP_UNLOCKWake up process sleeping on lock
VOP_ISLOCKEDTest if vnode is locked
VOP_BMAPLogical block number conversion
VOP_PRINTPrint debugging information
VOP_PATHCONFReturn POSIX pathconf data
VOP_ADVLOCKAdvisory record locking
VOP_WHITEOUTWhiteout vnode
VOP_GETPAGESRead VM pages from file
VOP_PUTPAGESWrite VM pages to file
VOP_STRATEGYRead/write a file system buffer
VOP_BWRITEWrite a file system buffer
VOP_GETEXTATTRGet extended attribute
VOP_SETEXTATTRSet extended attribute
VOP_LISTEXTATTRList extended attributes
VOP_DELETEEXTATTRRemove extended attribute
-

The implementation details of the vnode operations vector are not - quite what is described here.

-

If the file system type does not support a specific operation, it - must nevertheless assign an appropriate stub in the vnode operations vector - to do the minimum required of it. In most cases, such functions either do - nothing or return an error value to the effect that it is not supported.

-

Many of the functions in the vnode operations vector take a - componentname structure. It is used to encapsulate many parameters into a - single function argument. It has the following structure:

-
-
struct componentname {
-        /*
-         * Arguments to lookup.
-         */
-        uint32_t cn_nameiop;    /* namei operation */
-        uint32_t cn_flags;      /* flags to namei */
-        kauth_cred_t cn_cred;   /* credentials */
-        /*
-         * Shared between lookup and commit routines.
-         */
-        const char *cn_nameptr; /* pointer to looked up name */
-        size_t  cn_namelen;     /* length of looked up component */
-        size_t  cn_consume;     /* chars to consume in lookup() */
-};
-
-

The top half of the structure is used exclusively - for the pathname lookups using - () - and is initialized by the caller. The semantics of the lookup are affected - by the lookup operation specified in - - and the flags specified in - . - Valid operations are:

-

-
-
-
LOOKUP
-
perform name lookup only
-
CREATE
-
set up for file creation
-
DELETE
-
set up for file deletion
-
RENAME
-
set up for file renaming
-
OPMASK
-
mask for operation
-
-
-

Valid values for - - are:

-

-
-
-
LOCKLEAF
-
lock inode on return
-
LOCKPARENT
-
want parent vnode returned locked
-
NOCACHE
-
name must not be left in name cache (see - namecache(9))
-
FOLLOW
-
follow symbolic links
-
NOFOLLOW
-
do not follow symbolic links (pseudo)
-
MODMASK
-
mask of operational modifiers
-
-
-

No vnode operations may be called from interrupt context. Most - operations also require the vnode to be locked on entry. To prevent - deadlocks, when acquiring locks on multiple vnodes, the lock of parent - directory must be acquired before the lock on the child directory.

-

Vnode operations for a file system type generally should not be - called directly from the kernel, but accessed indirectly through the - high-level convenience functions discussed in - vnsubr(9).

-
-
-

-
-
(dvp, - vpp, cnp)
-
Lookup a single pathname component in a given directory. The argument - dvp is the locked vnode of the directory to search - and cnp is the pathname component to be searched - for. If the pathname component is found, the address of the resulting - unlocked vnode is returned in vpp. The operation - specified in - - indicates VOP_LOOKUP() the reason for requesting - the lookup and uses it to cache file system type specific information in - the vnode for subsequent operations. -

There are three types of lookups: - ".", ".." (ISDOTDOT), and regular. If the pathname - component being searched for is ".", then - dvp has an extra reference added to it and it is - returned in *vpp. For other pathname components, - () - checks the accessibility of the directory and searches the name cache - for the pathname component. See namecache(9). If the - pathname is not found in the name cache, the directory is searched for - the pathname. The resulting unlocked vnode is returned in - vpp. dvp is always returned - locked.

-

On failure *vpp is - NULL, and *dvp is left - locked. If the operation is successful *vpp is - unlocked and zero is returned. Typically, if *vpp - and dvp are the same vnode the caller will need to - release twice (decrement the reference count) and unlock once.

-
-
(dvp, - vpp, cnp, - vap)
-
Create a new file in a given directory. The argument - dvp is the locked vnode of the directory to create - the new file in and cnp is the pathname component of - the new file. The argument vap specifies the - attributes that the new file should be created with. If the file is - successfully created, the address of the resulting unlocked vnode is - returned in vpp and zero is returned. -

This function is called after - () - when a file is being created. Normally, - VOP_LOOKUP() will have set the SAVENAME flag in - cnp->cn_flags to keep the memory pointed to by - cnp->cn_pnbuf valid. If an error is detected when - creating the file, this memory is released. If the file is created - successfully it will be released unless the SAVESTART flags in specified - in cnp->cn_flags.

-
-
(dvp, - vpp, cnp, - vap)
-
Make a new device-special file in a given directory. The argument - dvp is the locked vnode of the directory to create - the new device-special file in and cnp is the - pathname component of the new device-special file. The argument - vap specifies the attributes that the new - device-special file should be created with. If the file is successfully - created, the address of the resulting unlocked vnode is returned in - vpp and zero is returned. -

This function is called after - () - when a device-special file is being created. Normally, - VOP_LOOKUP() will have set the SAVENAME flag in - cnp->cn_flags to keep the memory pointed to by - cnp->cn_pnbuf valid. If an error is detected when - creating the device-special file, this memory is released. If the - device-special file is created successfully it will be released unless - the SAVESTART flags in specified in - cnp->cn_flags.

-
-
VOP_OPEN(vp, - mode, cred)
-
Open a file. The argument vp is the vnode of the - file to open and mode specifies the access mode - required by the calling process. The calling credentials are specified by - cred. The access mode is a set of flags, including - FREAD, FWRITE, O_NONBLOCK, O_APPEND, etc. - VOP_OPEN() must be called before a file can be - accessed by a thread. The vnode reference count is incremented. -

() - expects the vnode vp to be locked on entry and - will leave it locked on return. If the operation is successful zero is - returned, otherwise an appropriate error code is returned.

-
-
(vp, - fflag, cred)
-
Close a file. The argument vp is the vnode of the - file to close and fflag specifies the access mode by - the calling process. The possible flags are FREAD, - FWRITE and FNONBLOCK. The - calling credentials are specified by cred. - VOP_CLOSE() frees resources allocated by - VOP_OPEN(). -

The vnode vp will be locked on entry and - should remain locked on return.

-
-
(vp, - mode, cred)
-
Determine the accessibility (permissions) of the file against the - specified credentials. The argument vp is the vnode - of the file to check, mode is the type of access - required and cred contains the user credentials to - check. The argument mode is a mask which can contain - VREAD, VWRITE or VEXEC. If the file is accessible in the specified way, - zero is returned, otherwise an appropriate error code is returned. -

The vnode vp will be locked on entry and - should remain locked on return.

-
-
(vp, - vap, cred)
-
Get specific vnode attributes on a file. The argument - vp is the vnode of the file to get the attributes - for. The argument cred specifies the calling - credentials. VOP_GETATTR() uses the file system - type specific data object vp->v_data to reference the - underlying file attributes. The attributes are returned in - vap. Attributes which are not available are set to - the value VNOVAL. -

For more information on vnode attributes - see vattr(9). Historically it was considered - acceptable to call - () - without first locking the vnode. This usage is deprecated.

-

The vnode vp will be locked on entry and - should remain locked on return.

-
-
(vp, - vap, cred)
-
Set specific vnode attributes on a file. The argument - vp is the locked vnode of the file to set the - attributes for. The argument cred specifies the - calling credentials. VOP_SETATTR() uses the file - system type specific data object vp->v_data to - reference the underlying file attributes. The new attributes are defined - in vap. Attributes which are not being modified by - VOP_SETATTR() should be set to the value VNOVAL. - If the operation is successful zero is returned, otherwise an appropriate - error is returned. -

For more information on vnode attributes see - vattr(9).

-
-
(vp, - uio, ioflag, - cred)
-
Read the contents of a file. The argument vp is the - vnode of the file to read from, uio is the location - to read the data into, ioflag is a set of flags and - cred are the credentials of the calling process. -

The ioflag argument is used to give - directives and hints to the file system. When attempting a read, the - high 16 bits are used to provide a read-ahead hint (in unit of file - system blocks) that the file system should attempt. The low 16 bits are - a bit mask which can contain the following flags:

-

-
-
-
IO_UNIT
-
do I/O as atomic unit
-
IO_APPEND
-
append write to end
-
IO_SYNC
-
sync I/O file integrity completion
-
IO_NODELOCKED
-
underlying node already locked
-
IO_NDELAY
-
FNDELAY flag set in file table
-
IO_DSYNC
-
sync I/O data integrity completion
-
IO_ALTSEMANTICS
-
use alternate I/O semantics
-
IO_NORMAL
-
operate on regular data
-
IO_EXT
-
operate on extended attributes
-
IO_DIRECT
-
do not buffer data in the kernel
-
-
-

Zero is returned on success, otherwise an error is returned. - The vnode should be locked on entry and remains locked on exit.

-
-
(vp, - uio, ioflag, - cred)
-
Write to a file. The argument vp is the vnode of the - file to write to, uio is the location of the data to - write, ioflag is a set of flags and - cred are the credentials of the calling process. -

The ioflag argument is - used to give directives and hints to the file system. The low 16 bits - are a bit mask which can contain the same flags as - ().

-

Zero is returned on success, otherwise an error is returned. - The vnode should be locked on entry and remains locked on exit.

-
-
(vp, - pos, len)
-
Allocate backing store. The argument vp is the vnode - for the file. The pos and len - arguments (specified in bytes) name an extent within the file. The blocks - underlying this range, rounding up at the top and down at the bottom if - needed, are checked; if no physical storage is allocated, a physical block - is allocated and zeroed. This operation removes “holes” from - files.
-
(vp, - pos, len)
-
Discard backing store. The argument vp is the vnode - for the file. The pos and len - arguments (specified in bytes) name an extent within the file. The blocks - underlying this range, rounding down at the top and up at the bottom if - needed, are checked. If any physical storage is used, it is deallocated. - This operation creates “holes” in files. Discarded blocks of - regular files read back afterwards as zeroes. On devices, the underlying - discard-block operation if any (e.g. ATA TRIM) is issued. The device - handles this as it sees fit. In particular it is - - guaranteed that discarded blocks on devices will be zeroed; reading a - discarded block might produce zeros, or ones, or the previously existing - data, or some other data, or trash.
-
VOP_IOCTL(vp, - command, data, - fflag, cred)
-
Perform device-specific I/O. The argument vp is the - vnode of the file, normally representing a device. The argument - command specifies the device-specific operation to - perform and cnp provides extra data for the - specified operation. The argument fflags is a set of - flags. The argument cred is the caller's - credentials. If the operation is successful, zero is returned, otherwise - an appropriate error code is returned. -

Most file systems do not supply a function for - (). - This function implements the ioctl(2) system call.

-
-
(vp, - command, data, - fflag, cred)
-
Perform file control. The argument vp is the locked - vnode of the file. The argument command specifies - the operation to perform and cnp provides extra data - for the specified operation. The argument fflags is - a set of flags. The argument cred is the caller's - credentials. If the operation is successful, zero is returned, otherwise - an appropriate error code is returned.
-
(vp, - events)
-
Test if a poll event has occurred. The argument vp - is the vnode of the file to poll. It returns any events of interest as - specified by events that may have occurred for the - file. The argument events is a set of flags as - specified by poll(2). -

The vnode vp remains unlocked throughout - the whole operation.

-
-
(vp, - kn)
-
Register a knote kn with the vnode - vn. If the operation is successful zero is returned, - otherwise an appropriate error code is returned. -

The vnode vp remains unlocked throughout - the whole operation.

-
-
(vp, - flags)
-
Eliminate all activity associated with the vnode vp. - The argument flags is a set of flags. If REVOKEALL - is set in flags all vnodes aliased to the vnode - vp are also eliminated. If the operation is - successful zero is returned, otherwise an appropriate error is returned. -

The vnode vp remains unlocked throughout - the whole operation.

-
-
(vp, - prot, cred)
-
Inform file system that vp is in the process of - being memory mapped. The argument prot specifies the - vm access protection the vnode is going to be mapped with. The argument - cred is the caller's credentials. If the file system - allows the memory mapping, zero is returned, otherwise an appropriate - error code is returned. -

Most file systems do not supply a function for - () - and use - () - to default for success. Only file systems which do not integrate with - the page cache at all typically want to disallow memory mapping.

-
-
(vp, - cred, flags, - offlo, offhi)
-
Flush pending data buffers for a file to disk. The argument - vp is the locked vnode of the file for flush. The - argument cred is the caller's credentials. The - argument flags is a set of flags. If FSYNC_WAIT is - specified in flags, the function should wait for I/O - to complete before returning. The argument offlo and - offhi specify the range of file to flush. If the - operation is successful zero is returned, otherwise an appropriate error - code is returned. -

This function implements the sync(2) and - fsync(2) system calls.

-
-
(vp, - oldoff, newoff, - cred)
-
Test if the file is seekable for the specified offset - newoff. The argument vp is the - locked vnode of the file to test. For most file systems this function - simply tests if newoff is valid. If the specified - newoff is less than zero, the function returns error - code EINVAL.
-
(dvp, - vp, cnp)
-
Remove a file. The argument dvp is the locked vnode - of the directory to remove the file from and vp is - the locked vnode of the file to remove. The argument - cnp is the pathname component about the file to - remove. If the operation is successful zero is returned, otherwise an - appropriate error code is returned. Both dvp and - vp are locked on entry and are to be unlocked before - returning.
- -
Link to a file. The argument dvp is the locked node - of the directory to create the new link and vp is - the vnode of the file to be linked. The argument cnp - is the pathname component of the new link. If the operation is successful - zero is returned, otherwise an error code is returned. The directory vnode - dvp should be locked on entry and will be released - and unlocked on return. The vnode vp should not be - locked on entry and will remain unlocked on return.
-
VOP_RENAME(fdvp, - fvp, fcnp, - tdvp, tvp, - tcnp)
-
Rename a file. The argument fdvp is the vnode of the - old parent directory containing in the file to be renamed and - fvp is the vnode of the file to be renamed. The - argument fcnp is the pathname component about the - file to be renamed. The argument tdvp is the vnode - of the new directory of the target file and tvp is - the vnode of the target file (if it exists). The argument - tcnp is the pathname component about the file's new - name. If the operation is successful zero is returned, otherwise an error - code is returned. -

The caller must hold the target file system's - rename lock. The source directory and file vnodes should be unlocked and - their reference counts should be incremented before entry. The target - directory and file vnodes should both be locked on entry. - () - updates the reference counts prior to returning.

-

Because of the complexity and nastiness of - the interface, please do not write new code that calls - () - directly until such time as ongoing cleanup work reaches a point where - the interface has been rendered halfway sane.

-
-
(dvp, - vpp, cnp, - vap)
-
Make a new directory in a given directory. The argument - dvp is the locked vnode of the directory to create - the new directory in and cnp is the pathname - component of the new directory. The argument vap - specifies the attributes that the new directory should be created with. If - the file is successfully created, the address of the resulting unlocked - vnode is returned in vpp and zero is returned. -

This function is called after - () - when a directory is being created. Normally, - VOP_LOOKUP() will have set the SAVENAME flag in - cnp->cn_flags to keep the memory pointed to by - cnp->cn_pnbuf valid. If an error is detected when - creating the directory, this memory is released. If the directory is - created successfully it will be released unless the SAVESTART flags in - specified in cnp->cn_flags.

-
-
(dvp, - vp, cnp)
-
Remove a directory in a given directory. The argument - dvp is the locked vnode of the directory to remove - the directory from and vp is the locked vnode of the - directory to remove. The argument cnp is the - pathname component of the directory. Zero is returned on success, - otherwise an error code is returned. Both dvp and - vp should be locked on entry and will be released - and unlocked on return.
- -
Create a symbolic link in a given directory. The argument - dvp is the locked vnode of the directory to create - the symbolic link in and cnp is the pathname - component of the symbolic link. The argument vap - specifies the attributes that the symbolic link should be created with and - target specifies the pathname of the target of the - symbolic link. If the symbolic link is successfully created, the address - of the resulting unlocked vnode is returned in vpp - and zero is returned. -

This function is called after - () - when a symbolic link is being created. Normally, - VOP_LOOKUP() will have set the SAVENAME flag in - cnp->cn_flags to keep the memory pointed to by - cnp->cn_pnbuf valid. If an error is detected when - creating the symbolic link, this memory is released. If the symbolic - link is created successfully it will be released unless the SAVESTART - flags in specified in cnp->cn_flags.

-
-
VOP_READDIR(vp, - uio, cred, - eofflag, cookies, - ncookies)
-
Read directory entry. The argument vp is the vnode - of the directory to read the contents of and uio is - the destination location to read the contents into. The argument - cred is the caller's credentials. The argument - eofflag is the pointer to a flag which is set by - VOP_READDIR() to indicate an end-of-file - condition. If eofflag is - NULL, the end-of-file condition is not returned. - The arguments cookies and - ncookies specify the addresses for the list and - number of directory seek cookies generated for NFS. Both - cookies and ncookies should be - NULL if they aren't required to be returned by - VOP_READDIR(). The directory contents are read - into struct dirent structures and uio->uio_offset - is set to the offset of the next unread directory entry. This offset may - be used in a following invocation to continue a sequential read of the - directory contents. If the operation is successful zero is returned, - otherwise an appropriate error code is returned. -

The directory should be locked on entry and will remain locked - on return.

-

In case ncookies and - cookies are supplied, one cookie should be - returned per directory entry. The value of the cookie for each directory - entry should be the offset within the directory where the on-disk - version of the following directory entry starts. That is, for each - directory entry i, the corresponding cookie should - refer to the offset of directory entry i + 1.

-

Note that the cookies - array must be allocated by the callee using the M_TEMP malloc type as - callers of - () - must be able to free the allocation.

-
- -
Read the contents of a symbolic link. The argument - vp is the locked vnode of the symlink and - uio is the destination location to read the contents - into. The argument cred is the credentials of the - caller. If the operation is successful zero is returned, otherwise an - error code is returned. -

The vnode should be locked on entry and will remain locked on - return.

-
-
(dvp, - cnp)
-
Abort pending operation on vnode dvp and free - resources allocated in cnp. -

This operation is rarely implemented in - file systems and - () - is typically used instead.

-
-
(vp)
-
Release the inactive vnode. VOP_INACTIVE() is - called when the kernel is no longer using the vnode. This may be because - the reference count reaches zero or it may be that the file system is - being forcibly unmounted while there are open files. It can be used to - reclaim space for open but deleted files. The argument - vp is the locked vnode to be released. If the - operation is successful zero is returned, otherwise an appropriate error - code is returned. The vnode vp must be locked on - entry, and will remain locked on return.
-
(vp)
-
Reclaim the vnode for another file system. - VOP_RECLAIM() is called when a vnode is being - reused for a different file system. Any file system specific resources - associated with the vnode should be freed. The argument - vp is the vnode to be reclaimed. If the operation is - successful zero is returned, otherwise an appropriate error code is - returned. The vnode vp should be locked on entry, - and will be returned unlocked.
-
(vp, - flags)
-
Sleep until vnode lock is free. The argument vp is - the vnode of the file to be locked. The argument - flags is LK_EXCLUSIVE to - take the lock exclusively or LK_SHARED to take a - shared lock. If flags contains - LK_NOWAIT and the lock is busy, the operation will - return immediately with an error code. If flags - contains LK_RETRY this is a hint the caller wants - the lock on dead vnodes too. If the operation is successful zero is - returned, otherwise an appropriate error code is returned. - VOP_LOCK() is used to serialize access to the file - system such as to prevent two writes to the same file from happening at - the same time. Kernel code should use vn_lock(9) to lock - a vnode rather than calling VOP_LOCK() - directly.
-
(vp)
-
Wake up process sleeping on lock. The argument vp is - the vnode of the file to be unlocked. If the operation is successful zero - is returned, otherwise an appropriate error code is returned. - VOP_UNLOCK() is used to serialize access to the - file system such as to prevent two writes to the same file from happening - at the same time.
-
(vp)
-
Test if the vnode vp is locked. Possible return - values are LK_EXCLUSIVE, - LK_SHARED or 0 for lock held exclusively by the - calling thread, shared lock held by anyone or unlocked, respectively. -

This function must never be used to make locking decisions at - run time: it is provided only for diagnostic purposes.

-
-
(vp, - bn, vpp, - bnp, runp)
-
Convert the logical block number bn of a file - specified by vnode vp to its physical block number - on the disk. The physical block is returned in bnp. - In case the logical block is not allocated, -1 is used. -

If vpp is not - NULL, the vnode of the device vnode for the file - system is returned in the address specified by - vpp. If runp is not - NULL, the number of contiguous blocks starting - from the next block after the queried block will be returned in - runp.

-
-
(vp)
-
Print debugging information. The argument vp is the - vnode to print. If the operation is successful zero is returned, otherwise - an appropriate error code is returned.
-
(vp, - name, retval)
-
Implement POSIX pathconf(2) and - fpathconf(2) support. The argument - vp is the locked vnode to get information about. The - argument name specified the type of information to - return. The information is returned in the address specified by - retval. Valid values for name - are: -

-
-
-
_PC_LINK_MAX
-
return the maximum number of links to a file
-
_PC_NAME_MAX
-
return the maximum number of bytes in a file name
-
_PC_PATH_MAX
-
return the maximum number of bytes in a pathname
-
_PC_PIPE_BUF
-
return the maximum number of bytes which will be written atomically to - a pipe
-
_PC_CHOWN_RESTRICTED
-
return 1 if appropriate privileges are required for the - chown(2) system call, otherwise zero
-
_PC_NO_TRUNC
-
return 0 if file names longer than {NAME_MAX} - are silently truncated
-
-
-

If name is recognized, - *retval is set to the specified value and zero is - returned, otherwise an appropriate error is returned.

-
-
(vp, - id, op, - fl, flags)
-
Manipulate Advisory record locks on a vnode. The argument - vp is the vnode on which locks are manipulated. The - argument id is the id token which is changing the - lock and op is the fcntl(2) - operation to perform. Valid values are: -

-
-
-
F_SETLK
-
set lock
-
F_GETLK
-
get the first conflicted lock
-
F_UNLCK
-
clear lock
-
-
-

The argument fl is a - description of the lock. In the case of - SEEK_CUR, The caller should add the current file - offset to fl->l_start beforehand. - () - treats SEEK_CUR as - SEEK_SET.

-

The argument flags is the set of flags. - Valid values are:

-

-
-
-
F_WAIT
-
wait until lock is granted
-
F_FLOCK
-
use flock(2) semantics for lock
-
F_POSIX
-
use POSIX semantics for lock
-
-
-

If the operation is successful zero is returned, otherwise an - appropriate error is returned.

-
-
(dvp, - cnp, flags)
-
Whiteout pathname component in directory with vnode - dvp. The argument cnp - specifies the pathname component to whiteout. -

The vnode dvp should be locked on entry - and will remain locked on return.

-
-
(vp, - offset, m, - count, centeridx, - access_type, advice, - flags)
-
Read VM pages from file. The argument vp is the - locked vnode to read the VM pages from. The argument - offset is offset in the file to start accessing and - m is an array of VM pages. The argument - count points a variable that specifies the number of - pages to read. If the operation is successful zero is returned, otherwise - an appropriate error code is returned. If PGO_LOCKED is specified in - , - VOP_GETPAGES() might return less pages than - requested. In that case, the variable pointed to by - - will be updated. -

This function is primarily used by the page-fault handing - mechanism.

-
-
(vp, - offlo, offhi, - flags)
-
Write modified (dirty) VM pages to file. The argument - vp is the vnode to write the VM pages to. The - vnode's vm object lock (v_uobj.vmobjlock) must be - held by the caller and will be released upon return. The arguments - offlo and offhi specify the - range of VM pages to write. In case offhi is given - as 0, all pages at and after the start offset offlo - belonging the vnode vp will be written. The argument - flags controls the behavior of the routine and takes - the vm pager's flags (PGO_ -prefixed). If the - operation is successful zero is returned, otherwise an appropriate error - code is returned. -

The function is primarily used by the - pageout handling mechanism and is commonly implemented indirectly by - () - with the help of - () - and VOP_BMAP().

-
-
VOP_STRATEGY(vp, - bp)
-
Read/write a file system buffer. The argument vp is - the vnode to read/write to. The argument bp is the - buffer to be read or written. VOP_STRATEGY() will - either read or write data to the file depending on the value of - . - If the operation is successful zero is returned, otherwise an appropriate - error code is returned.
-
(vp, - bp)
-
Write a file system buffer. The argument vp is the - vnode to write to. The argument bp specifies the - buffer to be written. If the operation is successful zero is returned, - otherwise an appropriate error code is returned.
-
(vp, - attrnamespace, name, - uio, size, - cred)
-
Get an extended attribute. The argument vp is the - locked vnode of the file or directory from which to retrieve the - attribute. The argument attrnamespace specifies the - extended attribute namespace. The argument name is a - nul-terminated character string naming the attribute to retrieve. The - argument uio, if not NULL, - specifies where the extended attribute value is to be written. The - argument size, if not NULL, - will contain the number of bytes required to read all of the attribute - data upon return. In most cases, uio will be - NULL when size is not, and - vice versa. The argument cred specifies the user - credentials to use when authorizing the request.
-
(vp, - attrnamespace, name, - uio, cred)
-
Set an extended attribute. The argument vp is the - locked vnode of the file or directory to which to store the attribute. The - argument namespace specifies the extended attribute - namespace. The argument name is a nul-terminated - character string naming the attribute to store. The argument - uio specifies the source of the extended attribute - data. The argument cred specifies the user - credentials to use when authorizing the request.
-
(vp, - attrnamespace, uio, - size, cred)
-
Retrieve the list of extended attributes. The argument - vp is the locked vnode of the file or directory - whose attributes are to be listed. The argument - attrnamespace specifies the extended attribute - namespace. The argument uio, if not - NULL, specifies where the extended attribute list - is to be written. The argument size, if not - NULL, will contain the number of bytes required to - read all of the attribute names upon return. In most cases, - uio will be NULL when - size is not, and vice versa. The argument - cred specifies the user credentials to use when - authorizing the request.
-
(vp, - attrnamespace, name, - cred)
-
Remove attribute name from file associated with - vp. The argument attrnamespace - specifies the extended attribute namespace. If full removal is not - supported, the file system should return - EOPNOTSUPP to allow the caller to zero out the - value with VOP_SETEXTATTR(). -

The vnode vp should be locked on entry - and will remain locked on return.

-
-
-
-
-

-

src/sys/kern/vnode_if.src contains the - list of vnode functions, their definitions and an exact locking - protocol.

-
-
-

-
-
[]
-
Access for the specified operation is denied.
-
[]
-
Quota exceeded.
-
[]
-
attempt to read from an illegal offset in the directory; unrecognized - input
-
[]
-
a read error occurred while reading the directory or reading the contents - of a symbolic link
-
[]
-
A CREATE or RENAME operation would be successful.
-
[]
-
The requested attribute is not defined for this vnode.
-
[]
-
The component was not found in the directory.
-
[]
-
The file system is full.
-
[]
-
The vnode does not represent a directory.
-
[]
-
attempt to remove a directory which is not empty
-
[]
-
an attempt was made to change an immutable file
-
[]
-
the file system is read-only
-
-
-
-

-

extattr(9), intro(9), - namei(9), vattr(9), - vfs(9), vfsops(9), - vnode(9)

-
-
-

-

The vnode operations vector, its functions and the corresponding - macros appeared in 4.3BSD.

-
-
- - - - - -
June 15, 2023NetBSD 10.1
diff --git a/static/netbsd/man9/wapbl.9 3.html b/static/netbsd/man9/wapbl.9 3.html deleted file mode 100644 index 241ea757..00000000 --- a/static/netbsd/man9/wapbl.9 3.html +++ /dev/null @@ -1,424 +0,0 @@ - - - - - - -
WAPBL(9)Kernel Developer's ManualWAPBL(9)
-
-
-

-

WAPBL, - wapbl_start, wapbl_stop, - wapbl_begin, wapbl_end, - wapbl_flush, wapbl_discard, - wapbl_add_buf, - wapbl_remove_buf, - wapbl_resize_buf, - wapbl_register_inode, - wapbl_unregister_inode, - wapbl_register_deallocation, - wapbl_jlock_assert, - wapbl_junlock_assert — - write-ahead physical block logging for file - systems

-
-
-

-

#include - <sys/wapbl.h>

-

typedef void (*wapbl_flush_fn_t)(struct mount *, - daddr_t *, int *, int);

-

int -
- wapbl_start(struct - wapbl **wlp, struct mount - *mp, struct vnode - *devvp, daddr_t - off, size_t count, - size_t blksize, - struct wapbl_replay *wr, - wapbl_flush_fn_t flushfn, - wapbl_flush_fn_t - flushabortfn);

-

int -
- wapbl_stop(struct - wapbl *wl, int - force);

-

int -
- wapbl_begin(struct - wapbl *wl, const char - *file, int - line);

-

void -
- wapbl_end(struct - wapbl *wl);

-

int -
- wapbl_flush(struct - wapbl *wl, int - wait);

-

void -
- wapbl_discard(struct - wapbl *wl);

-

void -
- wapbl_add_buf(struct - wapbl *wl, struct buf - *bp);

-

void -
- wapbl_remove_buf(struct - wapbl *wl, struct buf - *bp);

-

void -
- wapbl_resize_buf(struct - wapbl *wl, struct buf - *bp, long oldsz, - long oldcnt);

-

void -
- wapbl_register_inode(struct - wapbl *wl, ino_t - ino, mode_t - mode);

-

void -
- wapbl_unregister_inode(struct - wapbl *wl, ino_t - ino, mode_t - mode);

-

void -
- wapbl_register_deallocation(struct - wapbl *wl, daddr_t - blk, int len);

-

void -
- wapbl_jlock_assert(struct - wapbl *wl);

-

void -
- wapbl_junlock_assert(struct - wapbl *wl);

-
-
-

-

WAPBL, or - , is an abstraction for file systems to write - physical blocks in the buffercache(9) to a bounded-size - log first before their real destinations on disk. The name means:

-
-
-
logging
-
batches of writes are issued atomically via a log
-
physical block
-
only physical blocks, not logical file system operations, are stored in - the log
-
write-ahead
-
before writing a block to disk, its new content, rather than its old - content for roll-back, is recorded in the log
-
-
-

When a file system using - WAPBL issues writes (as in - bwrite(9) or bdwrite(9)), they are - grouped in batches called - - in memory, which are serialized to be consistent with program order before - WAPBL submits them to disk atomically.

-

Thus, within a transaction, after one write, another write need - not wait for disk I/O, and if the system is interrupted, e.g. by a crash or - by power failure, either both writes will appear on disk, or neither - will.

-

When a transaction is full, it is written to a circular - buffer on disk called the - . When the - transaction has been written to disk, every write in the transaction is - submitted to disk asynchronously. Finally, the file system may issue new - writes via WAPBL once enough writes submitted to - disk have completed.

-

After interruption, such as a crash or power failure, some writes - issued by the file system may not have completed. However, the log is - written consistently with program order and before file system writes are - submitted to disk. Hence a consistent program-order view of the file system - can be attained by resubmitting the writes that were successfully stored in - the log using wapbl_replay(9). This may not be the same - state just before interruption — writes in transactions that did not - reach the disk will be excluded.

-

For a file system to use - WAPBL, its VFS_MOUNT(9) method - should first replay any journal on disk using - wapbl_replay(9), and then, if the mount is read/write, - initialize WAPBL for the mount by calling - (). - The VFS_UNMOUNT(9) method should call - ().

-

Before issuing any - buffercache(9) writes, the file system must acquire a - shared lock on the current WAPBL transaction with - (), - which may sleep until there is room in the transaction for new writes. After - issuing the writes, the file system must release its shared lock on the - transaction with wapbl_end(). Either all writes - issued between wapbl_begin() and - wapbl_end() will complete, or none of them will.

-

File systems may also witness an - lock - on the current transaction when WAPBL is flushing - the transaction to disk, or aborting a flush, and invokes a file system's - callback. File systems can assert that the transaction is locked with - (), - or not - - locked, with wapbl_junlock_assert().

-

If a file system requires multiple - transactions to initialize an inode, and needs to destroy partially - initialized inodes during replay, it can register them by - ino_t inode number before initialization with - () - and unregister them with - () - once initialization is complete. WAPBL does not - actually concern itself whether the objects identified by - ino_t values are ‘inodes’ or - ‘quaggas’ or anything else — file systems may use this - to list any objects keyed by ino_t value in the - log.

-

When a file system frees resources on disk and issues writes to - reflect the fact, it cannot then reuse the resources until the writes have - reached the disk. However, as far as the buffercache(9) is - concerned, as soon as the file system issues the writes, they will appear to - have been written. So the file system must not attempt to reuse the resource - until the current WAPBL transaction has been flushed - to disk.

-

The file system can defer freeing - a resource by calling - () - to record the disk address of the resource and length in bytes of the - resource. Then, when WAPBL next flushes the - transaction to disk, it will pass an array of the disk addresses and lengths - in bytes to a file-system-supplied callback. (Again, - WAPBL does not care whether the ‘disk - address’ or ‘length in bytes’ is actually that; it will - pass along daddr_t and int - values.)

-
-
-

-
-
wapbl_start(wlp, - mp, devvp, - off, count, - blksize, wr, - flushfn, flushabortfn)
-
Start using WAPBL for the file system mounted at - mp, storing a log of count - disk sectors at disk address off on the block device - devvp writing blocks in units of - blksize bytes. On success, stores an opaque - struct wapbl * cookie in - *wlp for use with the other - WAPBL routines and returns zero. On failure, - returns an error number. -

If the file system had replayed the log - with wapbl_replay(9), then wr - must be the struct wapbl_replay * cookie used to - replay it, and - () - will register any inodes that were in the log as if with - wapbl_register_inode(); otherwise - wr must be NULL.

-

flushfn is a callback - that WAPBL will invoke as - flushfn (mp, - deallocblks, dealloclens, - dealloccnt) just before it flushes a transaction - to disk, with the an exclusive lock held on the transaction, where - mp is the mount point passed to - (), - deallocblks is an array of - dealloccnt disk addresses, and - dealloclens is an array of - dealloccnt lengths, corresponding to the addresses - and lengths the file system passed to - wapbl_register_deallocation(). If flushing the - transaction to disk fails, WAPBL will call - flushabortfn with the same arguments to undo any - effects that flushfn had.

-
-
wapbl_stop(wl, - force)
-
Flush the current transaction to disk and stop using - WAPBL. If flushing the transaction fails and - force is zero, return error. If flushing the - transaction fails and force is nonzero, discard the - transaction, permanently losing any writes in it. If flushing the - transaction is successful or if force is nonzero, - free memory associated with wl and return zero.
-
wapbl_begin(wl, - file, line)
-
Wait for space in the current transaction for new writes, flushing it if - necessary, and acquire a shared lock on it. -

The lock is not exclusive: other threads may acquire shared - locks on the transaction too. The lock is not recursive: a thread may - not acquire it again without calling wapbl_end - first.

-

May sleep.

-

file and line are - the file name and line number of the caller for debugging purposes.

-
-
(wl)
-
Release a shared lock on the transaction acquired with - wapbl_begin().
-
(wl, - wait)
-
Flush the current transaction to disk. If wait is - nonzero, wait for all writes in the current transaction to complete. -

The current transaction must not be locked.

-
-
(wl)
-
Discard the current transaction, permanently losing any writes in it. -

The current transaction must not be locked.

-
-
(wl, - bp)
-
Add the buffer bp to the current transaction, which - must be locked, because someone has asked to write it. -

This is meant to be called from within - buffercache(9), not by file systems directly.

-
-
(wl, - bp)
-
Remove the buffer bp, which must have been added - using wapbl_add_buf, from the current transaction, - which must be locked, because it has been invalidated (or XXX ???). -

This is meant to be called from within - buffercache(9), not by file systems directly.

-
-
(wl, - bp, oldsz, - oldcnt)
-
Note that the buffer bp, which must have been added - using wapbl_add_buf, has changed size, where - oldsz is the previous allocated size in bytes and - oldcnt is the previous number of valid bytes in - bp. -

This is meant to be called from within - buffercache(9), not by file systems directly.

-
-
(wl, - ino, mode)
-
Register ino with the mode - mode as commencing initialization.
-
(wl, - ino, mode)
-
Unregister ino, which must have previously been - registered with wapbl_register_inode using the same - mode, now that its initialization has - completed.
-
wapbl_register_deallocation(wl, - blk, len)
-
Register len bytes at the disk address - blk as ready for deallocation, so that they will be - passed to the flushfn that was given to - wapbl_start().
-
wapbl_jlock_assert(wl)
-
Assert that the current transaction is locked. -

Note that it might not be locked by the current - thread: this assertion passes if - thread has it - locked.

-
-
(wl)
-
Assert that the current transaction is not exclusively locked by the - current thread. -

Users of WAPBL - observe exclusive locks only in the flushfn and - flushabortfn callbacks to - (). - Outside of such contexts, the transaction is never exclusively locked, - even between wapbl_begin() and - wapbl_end().

-

There is no way to assert that the current - transaction is not locked at all — i.e., that the caller may - acquire a shared lock on the transaction with - () - without danger of deadlock.

-
-
-
-
-

-

The WAPBL subsystem is implemented in - sys/kern/vfs_wapbl.c, with hooks in - sys/kern/vfs_bio.c.

-
-
-

-

buffercache(9), vfsops(9), - wapbl_replay(9)

-
-
-

-

WAPBL works only for file system metadata - managed via the buffercache(9), and provides no way to log - writes via the page cache, as in VOP_GETPAGES(9), - VOP_PUTPAGES(9), and ubc_uiomove(9), - which is normally used for file data.

-

Not only is WAPBL unable to log writes via - the page cache, it is also unable to defer buffercache(9) - writes until cached pages have been written. This manifests as the - well-known garbage-data-appended-after-crash bug in FFS: when appending to a - file, the pages containing new data may not reach the disk before the inode - update reporting its new size. After a crash, the inode update will be on - disk, but the new data will not be — instead, whatever garbage data - in the free space will appear to have been appended to the file. - WAPBL exacerbates the problem by increasing the - throughput of metadata writes, because it can issue many metadata writes - asynchronously that FFS without WAPBL would need to - issue synchronously in order for fsck(8) to work.

-

The criteria for when the transaction must be flushed to disk - before wapbl_begin() returns are heuristic, i.e. - wrong. There is no way for a file system to communicate to - wapbl_begin() how many buffers, inodes, and - deallocations it will issue via WAPBL in the - transaction.

-

WAPBL mainly supports write-ahead, and has - only limited support for rolling back operations, in the form of - wapbl_register_inode() and - wapbl_unregister_inode(). Consequently, for example, - large writes appending to a file, which requires multiple disk block - allocations and an inode update, must occur in a single transaction — - there is no way to roll back the disk block allocations if the write fails - in the middle, e.g. because of a fault in the middle of the user buffer.

-

wapbl_jlock_assert() does not guarantee - that the current thread has the current transaction locked. - wapbl_junlock_assert() does not guarantee that the - current thread does not have the current transaction locked at all.

-

There is only one WAPBL transaction for - each file system at any given time, and only one - WAPBL log on disk. Consequently, all writes are - serialized. Extending WAPBL to support multiple logs - per file system, partitioned according to an appropriate scheme, is left as - an exercise for the reader.

-

There is no reason for WAPBL to require - its own hooks in buffercache(9).

-

The on-disk format used by WAPBL is - undocumented.

-
-
- - - - - -
March 26, 2015NetBSD 10.1
diff --git a/static/netbsd/man9/wsbell.9 3.html b/static/netbsd/man9/wsbell.9 3.html deleted file mode 100644 index 05dad7f0..00000000 --- a/static/netbsd/man9/wsbell.9 3.html +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - -
WSBELL(9)Kernel Developer's ManualWSBELL(9)
-
-
-

-

wsbell, - wsbelldevprint — wscons - system bell support

-
-
-

-

#include - <dev/wscons/wsconsio.h> -
- #include - <dev/wscons/wsbellvar.h>

-

int -
- wsbelldevprint(void - *aux, const char - *pnp);

-
-
-

-

The wsbell module is a component of the - wscons(9) framework, providing keyboard-independent bell - support. All of the support is provided by the wsbell(4) - device driver, which must be a child of the hardware device driver. The only - hardware device drivers that can provide a wsbell - facility are speaker(4) devices.

-
-
-

-

Speaker drivers providing support for wscons bell devices will - make use of the following data types:

-
-
struct wsbelldev_attach_args
-
A structure used to attach the wsbell(4) child device. - It has the following members: -
- 
	void *accesscookie;
-
-
-
-
-
-

-
-
(aux, - pnp)
-
The default wsbell printing routine used by - (). - (see autoconf(9)).
-
-
-
-

-

Speaker drivers which want to use the wsbell module must be a - parent to the wsbell(4) device and provide an attachment - interface. To attach the wsbell(4) device, the speaker - driver must allocate and populate a - wsbelldev_attach_args structure with a pointer to the - parent's device structure as an access cookie and call - config_found() to perform the attach (see - autoconf(9)).

-
-
-

-

When a bell event is received on a wsdisplay(4) - device the system bell is sounded.

-
-
-

-

The wscons subsystem is implemented within the directory - sys/dev/wscons. The wsbell - module itself is implement within the file - sys/dev/wscons/wsbell.c. ioctl(2) - operations are listed in - sys/dev/wscons/wsconsio.h.

-
-
-

-

ioctl(2), wsbell(4), - wscons(4), wskbd(4), - autoconf(9), driver(9), - intro(9), wscons(9), - wsdisplay(9), wskbd(9)

-
-
- - - - - -
June 30, 2017NetBSD 10.1
-- cgit v1.2.3