Lines Matching +full:on +full:- +full:device
1 .\" format with ditroff -me
19 .ip \0\s-2\(bu\s+2
29 .i "Poul-Henning Kamp"
38 of ``a file is a file is a file and even a device is a file.''
40 to ``my toaster has USB'' has put serious strain on the rather crude
43 Starting from a high-level view of devices and the semantics that
44 have grown around them over the years, this paper takes the audience on a
45 grand tour of the redesigned FreeBSD device-I/O system,
70 published on UNIX by Ritchie and Thompson [Ritchie74]:
73 Each supported I/O device is associated with at least one such file.
75 but requests to read or write result in activation of the associated device.
79 Thus, for example, to write on a magnetic tape one may write on the file /dev/mt.
86 file and device I/O are as similar as possible;
87 file and device names have the same syntax and meaning,
88 so that a program expecting a file name as a parameter can be passed a device name;
99 disk-pack with a filesystem: selling pre-initialised and ``quality
100 tested'' disk-packs was quite a profitable business.
103 writing individual sectors on a disk pack
109 .\" (Explain how opening /dev/lpt0 lands you in the right device driver)
112 device would be inode number 5, the paper-tape-punch number 6 and so on,
119 device numbers to index though the devsw array to the correct device driver.
122 in most UNIX-like systems even to this day.
125 one piece of information: the major and minor device numbers, often
129 to find the entry points in the device driver, and passes the combined
130 major and minor numbers as a parameter to the device driver.
141 \** Unless your assigned field engineer was present on site.
144 change while the system was up and running, so creating device nodes
150 In order to support remote login a ``pseudo-tty'' device driver was implemented,
151 basically as tty driver which instead of hardware had another device which
153 The telnetd(8) daemon would read and write data on the ``master'' side of
154 the pseudo-tty and the user would be running on the ``slave'' side,
158 Obviously with a device requiring no hardware, you can compile as many
170 and pre-populated /dev with every conceivable device node, resulting
171 in a predictable slowdown on access to filenames in /dev.
173 System V UNIX provided a band-aid solution:
178 based on an intricate system of per device driver configuration files.
189 types [Heidemann91a] and a ``device-pseudo-filesystem'' was a pretty
191 The device drivers have a pretty good idea which
200 ``device special file'' in UNIX.
207 exist in the filename namespace all pointing to the same device
211 .vs -3
212 \fC\s-3guest# ls -l /dev/fd0 /tmp/fd0
213 crw-r----- 1 root operator 9, 0 Sep 27 19:21 /dev/fd0
214 crw-rw-rw- 1 root wheel 9, 0 Sep 27 19:24 /tmp/fd0\fP\s+3
217 Obviously, the administrator needs to be on top of this:
227 People may have root privilege on one machine but not another.
228 Since device nodes are not interpreted on the NFS server
229 but rather on the local computer,
230 a user with root privilege on a NFS client
231 computer can create a device node to his liking on a filesystem
233 This device node can in turn be used to
236 trusting any device entries on untrusted filesystem by mounting such
237 filesystems with the \fCnodev\fP mount-option.
239 The fact that the device itself does not actually exist inside the
241 to perform boot-strapping stunts in the spirit
244 device vnodes:
246 .vs -3
247 \fC\s-2guest# mount -o ro /dev/fd0 /mnt
249 guest# mount -u -o rw /mnt/dev/fd0 /mnt\fP\s+2
254 provide filesystem isolation for process-trees.
260 Obviously chroot(2) and jail(2) may require access to a well-defined
266 For a long time FreeBSD, like almost all UNIX-like systems had two kinds
269 devices would provide caching and alignment for disk device access.
282 important data on a multi-file 9-track tape to remote locations.
291 \** Well, OK: and some 9-track tapes.
294 a minor device mode.
297 some bit in the minor device number on the disk special file,
304 were found to be in existence which relied on block devices
309 removed much magic special-case code throughout.
314 various types of ``things'' a process can access in UNIX-like
332 Devices land somewhere in the middle between pipes and sockets on
333 one side and normal files on the other.
338 Devices are in fact special-cased all the way through the vnode system.
339 For one thing devices break the ``one file-one vnode''
341 device together in
342 order to be able to find ``the canonical vnode for this device node'',
346 For true inconsistency, consider the SVID IPC mechanisms - not
367 add code to special-case any lookup which ends up in ``/dev''.
377 entry which may or may not actually be present on the filesystem
380 must be special-cased throughout the vnode layer of the kernel.
386 device driver, have a daemon read messages from it and create and
399 read-write at boot until we have a device node for the root device,
401 the root filesystem (and hence /dev) is read-only.
402 Adding a read-write memory-filesystem mount /dev to solve this problem
408 which mounts on ``/dev''.
411 just mount a DEVFS instance on the ``dev'' directory inside the filesystem
419 Before implementing a DEVFS, it is necessary to decide on a range
431 a device node, they want that mode to survive across reboots.
442 \fC\s-2ln /dev/fd0 /dev/fd1\fP\s+2
452 ``/dev/fd2''? Nobody can agree on anything but the ugliness of the
455 Given that we are no longer dependent on DEC Field engineers to
466 ``/dev/da0'', but so does the RAID-5 array attached to the PCI SCSI controller
468 on the Zip drive, do I want that mode to apply to the RAID-5 as well?
472 device ``/dev/sio0'', but we boot and do not find any sio devices?
473 Do we keep the information in our device-persistence registry?
475 set the permissions to some non-standard value like 0666,
476 and then attach some other serial device a year from now - do I
489 .sh 2 "Who decides on the names?"
491 In a DEVFS-enabled system, the responsibility for creating nodes in
492 /dev shifts to the device drivers, and consequently the device
493 drivers get to choose the names of the device files.
495 provided by the device driver.
501 Most device drivers know their own name and use it purposefully in
504 which ties hardware to device drivers, identifies things by name
509 .vs -3
510 \fC\s-2#define LPT_NAME "lpt" /* our official name */
517 So despite the user renaming the device node pointing to the printer
522 device nodes since it would only lead to confusion and because the desired
525 .sh 2 "On-demand device creation"
527 Pseudo-devices like pty, tun and bpf,
528 but also some real devices, may not pre-emptively create entries for all
529 possible device nodes. It would be a pointless waste of resources
531 and in the worst case more than 1800 device nodes would be needed per
534 For pseudo-devices the task at hand is to make a magic device node,
538 Device submodes, on the other hand, work by having multiple
540 the device driver in aspects of its operation. The most widespread
543 instructs the tape device driver to not rewind on close.\**
548 Some UNIX systems have solved the problem for pseudo-devices by
550 When a cloning device is opened,
552 return this new device to the opening process.
555 in midstream is non-trivial, but even worse is the fact that it
557 submodes for a device because it only reacts to one particular /dev entry.
559 The solution for both needs is a more flexible on-demand device
560 creation, implemented in FreeBSD as a two-level lookup.
562 filename is looked up in DEVFS, a match in the existing device nodes is
564 If no match is found, device drivers are polled in turn to ask if
565 they would be able to synthesise a device node of the given name.
567 The device driver gets a chance to modify the name
568 and create a device with make_dev().
570 the newly found device node is returned:
572 .vs -3
573 \fC\s-2pty_clone()
578 name = dev->name;
583 An interesting mixed use of this mechanism is with the sound device drivers.
589 The sound device drivers use the cloning facility to direct ``/dev/dsp''
594 that ``ls /dev'' now errs on the sparse side instead of the rich when used
595 as a system device inventory, a practice which has always been
599 Deleting device nodes is no problem to implement, but as likely as not,
601 Since only the device driver know how to create a given device,
602 recreation cannot be performed solely on the basis of the parameters
614 Recreating the device with mknod(2) will simply remove the DE_WHITEOUT
626 device nodes which the real root has removed.
636 for a jailed root to un-hide hidden entries while letting an un-jailed
639 Mounting or remounting read-only, will prevent all future
641 hide or un-hide entries in the mountpoint.
648 When a device driver creates a device node, and a DEVFS mount adds it
652 Currently, the device driver specifies the initial values in the
656 More seriously, they represent compile-time defaults which in these
657 enlightened days is rather old-fashioned.
664 4.4BSD-Lite as well.
666 POSIX has defined a type called ``dev_t'' which is the identity of a device.
670 the major# and minor# for the device.
675 Although the kernel had a well-defined concept of any particular
676 device it did not have a data structure to represent "a device".
677 The device driver has such a structure, traditionally called ``softc''
679 device driver's private data structures.
702 D: box "device" "driver"
715 Fig. 1 - Data structures in 4.4BSD
720 we find the dev_t which is used to reference the device driver.
722 Access to the device driver happens by extracting the major# from
724 the device driver's entry point.
726 The device driver will extract the minor# from the dev_t and use
727 that as the index into the softc array of private data per device.
730 and is used to find all vnodes which reference the same device (i.e.
733 which vnode is the ``chosen one'' for this device, and to keep track of
734 open(2)/close(2) against this device.
736 which depending on the vnode reclamation rate and /dev directory lookup
742 device (i.e. unique major#
743 and minor# combination) and all vnodes referencing this device point
761 D: box "device" "driver"
764 Fig. 2 - The new FreeBSD data structures.
771 All vnodes referencing a device are linked to a list hanging
775 name-caching.
777 The entry points to the device driver are stored in the specinfo
779 device drivers to use separate entrypoints for various minor numbers.
782 device for management and tuning. The control device, almost always
786 structure but ``owned'' by the device driver. Typically the
787 device driver will store a pointer to the softc structure in
791 indexing based on the minor#, and at the same time has obliviated
792 the need for the compiled-in ``NFOO'' constants which traditionally
797 because they forgot to perform bounds checking on the index before
798 using it on their softc arrays.
808 destroyed by the device drivers which know what devices are present.
815 device nodes with no device driver backing in the filesystems and
823 it with driver entry points, major#, minor#, device node name
826 If the device driver determines that the device is no longer
831 is called by the driver. The driver can rely on this and keep state
835 By now we have all the relevant information about each device node
837 solve before we can add the DEVFS filesystem on top of it.
840 Some device drivers, notably the CAM/SCSI subsystem in FreeBSD
841 will discover changes in the device configuration inside an interrupt
844 This imposes some limitations on what can and should do be done:
852 for a jail(8) based virtual-machine web-server several hundred instances
856 The solution to this problem is to do all the filesystem work on
860 The functions called from the device drivers, make_dev(), destroy_dev()
865 dev_t and store the dev_t in the DEVFS-global inode-to-dev_t array.
867 .vs -3
868 \fC\s-2make_dev(...)
876 in the dev_t and NULL the pointer in the devfs-global inode-to-dev_t
879 .vs -3
880 \fC\s-2destroy_dev(...)
897 or rely on the directory structure, VOP_LOOKUP and VOP_READDIR,
899 of the device hierarchy to match current reality before doing any work.
901 .vs -3
902 \fC\s-2devfs_readdir(...)
911 devfs-global inode-array and the directory tree of the mountpoint is
914 The actual code is slightly more complicated than shown in the pseudo-code
917 .vs -3
918 \fC\s-2devfs_populate(...)
919 while (mount->generation != devfs_generation)
936 .sh 1 "Device-driver impact"
938 All these changes have had a significant impact on how device drivers
943 the NFOO define which imposes a firm upper limit on the number of
947 This is because most device drivers (and texts on writing device
952 .vs -3
953 \fC\s-2
985 return (-1);
995 Fig. 3 - Device-driver, old style.
1000 minor# is inside range. This code gets more complex if device-numbering
1005 the cdevsw structure (not shown) when the first device is found.
1016 .vs -3
1017 \fC\s-2
1026 struct foo_softc *sc = dev->si_drv1;
1039 return (-1);
1041 sc->dev = make_dev(&cdevsw, nfoo,
1045 sc->dev->si_drv1 = sc;
1049 Fig. 4 - Device-driver, new style.
1066 device driver is shown.
1067 In real device drivers it is not uncommon to save 50 or more lines
1073 and future work therefore is likely concentrate on applying the
1077 It would be logical to complement DEVFS with a ``device-daemon'' which
1078 could configure and de-configure devices as they come and go.
1083 flash-based media from a camera, &c.
1088 automatically continue the print job on this new printer?
1089 When a disk-like device arrives, should we always mount it? Should
1090 we have a database of known disk-like devices to tell us where to
1109 As it is now, device drivers propose the initial mode, owner and group
1110 for the device nodes, but it would be more flexible if it were possible
1119 .sh 2 "Applications of on-demand device creation"
1121 The facility for on-demand creation of devices has some very interesting
1124 One planned use is to enable user-controlled labelling
1131 The current idea is to store on the media of the disk a user-chosen
1138 be decided to move all the sub-divisions of a disk into one subdirectory
1141 something like /dev/ad0/s2f and so on.
1152 and behind the scenes a search would be made for a device with the
1153 correct properties and paper-handling facilities.
1158 pseudo-devices and on-demand device node creation.
1162 primarily because of the improved API seen from device drivers point of view.
1169 I first got started on DEVFS in 1989 because the abysmal performance
1170 of the Olivetti M250 computer forced me to implement a network-disk-device
1193 Addison Wesley, 1996, ISBN 0-201-54979-4.
1199 Available as UCLA technical report CSD-910056.
1202 Poul-Henning Kamp and Robert N. M. Watson:
1208 Poul-Henning Kamp et al:
1214 ``Design of a General Purpose Memory Allocator for the 4.3BSD UNIX-Kernel''
1215 Proceedings of the San Francisco USENIX Conference, pp. 295-303, June 1988.
1237 hardware and device drivers. Despite the importance of this
1242 \fC\s-2http://www.daemonnews.org/200007/newbus-intro.html\fP\s+2
1247 \fC\s-2http://www.cs.bell\-labs.com/who/rob/utah2000.pdf\fP\s+2
1266 ``The UNIX Time-Sharing System''