Lines Matching +full:2 +full:- +full:way
1 .\" format with ditroff -me
11 . nr sp \n(pp+2 \" section heading point size
16 .nr fm 2v
19 .ip \0\s-2\(bu\s+2
29 .i "Poul-Henning Kamp"
43 Starting from a high-level view of devices and the semantics that
45 grand tour of the redesigned FreeBSD device-I/O system,
51 .2c
58 The usual way and the UNIX way.
60 The usual way is to treat I/O devices as their own class of things,
64 with, it has to interact with disks one way, tapes another and
65 rodents yet a third way, all of which are different from how it
68 The UNIX way has never been described better than in the very first
85 There is a threefold advantage in treating I/O devices this way:
99 disk-pack with a filesystem: selling pre-initialised and ``quality
100 tested'' disk-packs was quite a profitable business.
107 .sh 2 "The traditional implementation"
112 device would be inode number 5, the paper-tape-punch number 6 and so on,
122 in most UNIX-like systems even to this day.
136 mknod(2) system call, usually through the mknod(8) program.
150 In order to support remote login a ``pseudo-tty'' device driver was implemented,
154 the pseudo-tty and the user would be running on the ``slave'' side,
170 and pre-populated /dev with every conceivable device node, resulting
173 System V UNIX provided a band-aid solution:
188 Along the way, UNIX kernels had learned to deal with multiple filesystem
189 types [Heidemann91a] and a ``device-pseudo-filesystem'' was a pretty
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
218 one popular way to exploit an unguarded root prompt is
237 filesystems with the \fCnodev\fP mount-option.
241 to perform boot-strapping stunts in the spirit
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
253 Other interesting details are chroot(2) and jail(2) [Kamp2000] which
254 provide filesystem isolation for process-trees.
255 Whereas chroot(2) was not implemented as a security tool [Mckusick1999]
256 (although it has been widely used as such), the jail(2) security
260 Obviously chroot(2) and jail(2) may require access to a well-defined
263 or any disks could be used to compromise the integrity of the jail(2)
266 For a long time FreeBSD, like almost all UNIX-like systems had two kinds
282 important data on a multi-file 9-track tape to remote locations.
291 \** Well, OK: and some 9-track tapes.
307 This greatly simlified the task of keeping track of open(2)
309 removed much magic special-case code throughout.
314 various types of ``things'' a process can access in UNIX-like
318 they are accessed with open(2), read(2), write(2), mmap(2), close(2)
322 its own namespace. That means you cannot open(2) a socket,\**
328 but you can read(2) and write(2) to it.
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''
346 For true inconsistency, consider the SVID IPC mechanisms - not
364 The very straightforward way is to hack the namei() kernel function
367 add code to special-case any lookup which ends up in ``/dev''.
368 But this leads to problems: in the case of chroot(2) or jail(2), the
371 chroot(2)/jail(2) about which devices are visible and
380 must be special-cased throughout the vnode layer of the kernel.
393 but chroot(2)/jail(2) requirements prevents a simple implementation
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
410 The good news is that it does solve the problem with chroot(2) and jail(2):
422 .sh 2 "The ``persistence'' issue"
442 \fC\s-2ln /dev/fd0 /dev/fd1\fP\s+2
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?
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
507 A very common way to report errors in fact:
509 .vs -3
510 \fC\s-2#define LPT_NAME "lpt" /* our official name */
513 ": cannot alloc ppbus (%d)!", error);\fP\s+2
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
534 For pseudo-devices the task at hand is to make a magic device node,
539 entries in /dev, each with a different minor number, as a way to instruct
545 \** This is the answer to the question in footnote number 2.
548 Some UNIX systems have solved the problem for pseudo-devices by
555 in midstream is non-trivial, but even worse is the fact that it
559 The solution for both needs is a more flexible on-demand device
560 creation, implemented in FreeBSD as a two-level lookup.
572 .vs -3
573 \fC\s-2pty_clone()
578 name = dev->name;
579 return(dev);\fP\s+2
597 .sh 2 "Deleting and recreating devices"
612 The obvious way to recreate deleted devices is to let mknod(2) do it
614 Recreating the device with mknod(2) will simply remove the DE_WHITEOUT
616 .sh 2 "Jail(2), chroot(2) and DEVFS"
618 The primary requirement from facilities like jail(2) and chroot(2)
625 And in the same way, the jailed root should not be able to recreate
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.
646 .sh 2 "Default mode, owner & group"
656 More seriously, they represent compile-time defaults which in these
657 enlightened days is rather old-fashioned.
664 4.4BSD-Lite as well.
668 stat(2), fstat(2) and mknod(2).
675 Although the kernel had a well-defined concept of any particular
681 It is an interesting tale how things got to be this way,\**
715 Fig. 1 - Data structures in 4.4BSD
734 open(2)/close(2) against this device.
738 .sh 2 "The new vnode/inode/dev_t layout"
740 In the new layout (Fig. 2) the specinfo structure takes a central
764 Fig. 2 - The new FreeBSD data structures.
775 name-caching.
792 the need for the compiled-in ``NFOO'' constants which traditionally
796 \** Not to mention all the drivers which implemented panic(2)
805 .sh 2 "Creating and destroying devices"
838 .sh 2 "The interrupt problem"
852 for a jail(8) based virtual-machine web-server several hundred instances
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(...)
871 atomically insert dev_t into inode_array\fP\s+2
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(...)
883 atomically clear entry in inode_array\fP\s+2
901 .vs -3
902 \fC\s-2devfs_readdir(...)
904 ...\fP\s+2
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"
952 .vs -3
953 \fC\s-2
985 return (-1);
994 \fP\s+2
995 Fig. 3 - Device-driver, old style.
1000 minor# is inside range. This code gets more complex if device-numbering
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;
1048 \fP\s+2
1049 Fig. 4 - Device-driver, new style.
1061 There is no way to end
1075 .sh 2 "devd"
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.
1081 And in some configurable way allow the user to customise the action,
1083 flash-based media from a camera, &c.
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
1095 .sh 2 "Pathname length limitations"
1107 .sh 2 "Initial access parameter selection"
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
1142 Obviously, in the same way, disks could also be accessed by their
1153 correct properties and paper-handling facilities.
1158 pseudo-devices and on-demand device node creation.
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.
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''
1276 The Bell System Technical Journal, vol 57, 1978, number 6 (part 2) p. 1931ff.