diff options
Diffstat (limited to 'static/freebsd/man4/intro.4 3.html')
| -rw-r--r-- | static/freebsd/man4/intro.4 3.html | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/static/freebsd/man4/intro.4 3.html b/static/freebsd/man4/intro.4 3.html new file mode 100644 index 00000000..d9e2e6a9 --- /dev/null +++ b/static/freebsd/man4/intro.4 3.html @@ -0,0 +1,164 @@ +<table class="head"> + <tr> + <td class="head-ltitle">INTRO(4)</td> + <td class="head-vol">Device Drivers Manual</td> + <td class="head-rtitle">INTRO(4)</td> + </tr> +</table> +<div class="manual-text"> +<section class="Sh"> +<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> +<p class="Pp"><code class="Nm">intro</code> — + <span class="Nd">introduction to devices and device drivers</span></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> +<p class="Pp">This section contains information related to devices, device + drivers and miscellaneous hardware.</p> +<section class="Ss"> +<h2 class="Ss" id="The_device_abstraction"><a class="permalink" href="#The_device_abstraction">The + device abstraction</a></h2> +<p class="Pp">Device is a term used mostly for hardware-related stuff that + belongs to the system, like disks, printers, or a graphics display with its + keyboard. There are also so-called + <a class="permalink" href="#pseudo-devices"><i class="Em" id="pseudo-devices">pseudo-devices</i></a> + where a device driver emulates the behaviour of a device in software without + any particular underlying hardware. A typical example for the latter class + is <span class="Pa">/dev/mem</span>, a mechanism whereby the physical memory + can be accessed using file access semantics.</p> +<p class="Pp">The device abstraction generally provides a common set of system + calls, which are dispatched to the corresponding device driver by the upper + layers of the kernel. The set of system calls available for devices is + chosen from <a class="Xr">open(2)</a>, <a class="Xr">close(2)</a>, + <a class="Xr">read(2)</a>, <a class="Xr">write(2)</a>, + <a class="Xr">ioctl(2)</a>, <a class="Xr">select(2)</a>, and + <a class="Xr">mmap(2)</a>. Not all drivers implement all system calls; for + example, calling <a class="Xr">mmap(2)</a> on a keyboard device is not + likely to be useful.</p> +<p class="Pp">Aspects of the device abstraction have changed significantly in + <span class="Ux">FreeBSD</span> over the past two decades. The section + <a class="Sx" href="#Historical_Notes">Historical Notes</a> describes some + of the more important differences.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Accessing_Devices"><a class="permalink" href="#Accessing_Devices">Accessing + Devices</a></h2> +<p class="Pp">Most of the devices in <span class="Ux">FreeBSD</span> are + accessed through + <a class="permalink" href="#device"><i class="Em" id="device">device + nodes</i></a>, sometimes also called + <a class="permalink" href="#special"><i class="Em" id="special">special + files</i></a>. They are located within instances of the + <a class="Xr">devfs(4)</a> filesystem, which is conventionally mounted on + the directory <span class="Pa">/dev</span> in the file system hierarchy (see + also <a class="Xr">hier(7)</a>).</p> +<p class="Pp">The <a class="Xr">devfs(4)</a> filesystem creates or removes + device nodes automatically according to the physical hardware recognized as + present at any given time. For pseudo-devices, device nodes may be created + and removed dynamically as required, depending on the nature of the + device.</p> +<p class="Pp">Access restrictions to device nodes are usually subject to the + regular file permissions of the device node entry, instead of being enforced + directly by the drivers in the kernel. But since device nodes are not stored + persistently between reboots, those file permissions are set at boot time + from rules specified in <a class="Xr">devfs.conf(5)</a>, or dynamically + according to rules defined in <a class="Xr">devfs.rules(5)</a> or set using + the <a class="Xr">devfs(8)</a> command. In the latter case, different rules + may be used to make different sets of devices visible within different + instances of the <a class="Xr">devfs(4)</a> filesystem, which may be used, + for example, to prevent jailed subsystems from accessing unsafe devices. + Manual changes to device node permissions may still be made, but will not + persist.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Drivers_without_device_nodes"><a class="permalink" href="#Drivers_without_device_nodes">Drivers + without device nodes</a></h2> +<p class="Pp">Drivers for network devices do not use device nodes in order to be + accessed. Their selection is based on other decisions inside the kernel, and + instead of calling <a class="Xr">open(2)</a>, use of a network device is + generally introduced by using the system call + <a class="Xr">socket(2)</a>.</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Configuring_a_driver_into_the_kernel"><a class="permalink" href="#Configuring_a_driver_into_the_kernel">Configuring + a driver into the kernel</a></h2> +<p class="Pp">For each kernel, there is a configuration file that is used as a + base to select the facilities and drivers for that kernel, and to tune + several options. See <a class="Xr">config(8)</a> for a detailed description + of the files involved. The individual manual pages in this section provide a + sample line for the configuration file in their synopsis portions. See also + the files <span class="Pa">/usr/src/sys/conf/NOTES</span> and + <span class="Pa">/usr/src/sys/${ARCH}/conf/NOTES</span>.</p> +<p class="Pp">Drivers need not be statically compiled into the kernel; they may + also be loaded as modules, in which case any device nodes they provide will + appear only after the module is loaded (and has attached to suitable + hardware, if applicable).</p> +</section> +<section class="Ss"> +<h2 class="Ss" id="Historical_Notes"><a class="permalink" href="#Historical_Notes">Historical + Notes</a></h2> +<p class="Pp">Prior to <span class="Ux">FreeBSD 6.0</span>, device nodes could + be created in the traditional way as persistent entries in the file system. + While such entries can still be created, they no longer function to access + devices.</p> +<p class="Pp" id="block">Prior to <span class="Ux">FreeBSD 5.0</span>, devices + for disk and tape drives existed in two variants, known as + <a class="permalink" href="#block"><i class="Em">block</i></a> and + <a class="permalink" href="#character"><i class="Em" id="character">character</i></a> + devices, or to use better terms, buffered and unbuffered (raw) devices. The + traditional names are reflected by the letters + “<code class="Li">b</code>” and + “<code class="Li">c</code>” as the file type identification in + the output of “<code class="Li">ls -l</code>”. Raw devices + were traditionally named with a prefix of + “<code class="Li">r</code>”, for example + <span class="Pa">/dev/rda0</span> would denote the raw version of the disk + whose buffered device was <span class="Pa">/dev/da0</span>. + <a class="permalink" href="#This"><i class="Em" id="This">This is no longer + the case</i></a>; all disk devices are now “raw” in the + traditional sense, even though they are not given + “<code class="Li">r</code>” prefixes, and + “buffered” devices no longer exist at all.</p> +<p class="Pp" id="synchronous">Buffered devices were accessed through a buffer + cache maintained by the operating system; historically this was the system's + primary disk cache, but in <span class="Ux">FreeBSD</span> this was rendered + obsolete by the introduction of unified virtual memory management. Buffered + devices could be read or written at any byte position, with the buffer + mechanism handling the reading and writing of disk blocks. In contrast, raw + disk devices can be read or written only at positions and lengths that are + multiples of the underlying device block size, and + <a class="Xr">write(2)</a> calls are + <a class="permalink" href="#synchronous"><i class="Em">synchronous</i></a>, + not returning to the caller until the data has been handed off to the + device.</p> +</section> +</section> +<section class="Sh"> +<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE + ALSO</a></h1> +<p class="Pp"><a class="Xr">close(2)</a>, <a class="Xr">ioctl(2)</a>, + <a class="Xr">mmap(2)</a>, <a class="Xr">open(2)</a>, + <a class="Xr">read(2)</a>, <a class="Xr">select(2)</a>, + <a class="Xr">socket(2)</a>, <a class="Xr">write(2)</a>, + <a class="Xr">devfs(4)</a>, <a class="Xr">hier(7)</a>, + <a class="Xr">config(8)</a></p> +</section> +<section class="Sh"> +<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> +<p class="Pp">This manual page first appeared in <span class="Ux">FreeBSD + 2.1</span>.</p> +</section> +<section class="Sh"> +<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1> +<p class="Pp">This man page has been rewritten by <span class="An">Andrew + Gierth</span> from an earlier version written by + <span class="An">Jörg Wunsch</span> with initial input by + <span class="An">David E. O'Brien</span>.</p> +</section> +</div> +<table class="foot"> + <tr> + <td class="foot-date">April 3, 2019</td> + <td class="foot-os">FreeBSD 15.0</td> + </tr> +</table> |