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, 0 insertions, 164 deletions
diff --git a/static/freebsd/man4/intro.4 3.html b/static/freebsd/man4/intro.4 3.html deleted file mode 100644 index d9e2e6a9..00000000 --- a/static/freebsd/man4/intro.4 3.html +++ /dev/null @@ -1,164 +0,0 @@ -<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> |