Lines Matching full:and
26 .b "Rethinking /dev and devices in the UNIX kernel"
38 of ``a file is a file is a file and even a device is a file.''
43 Starting from a high-level view of devices and the semantics that
46 to convey an overview of how it all fits together, and to explain why
47 things ended up as they did, how to use the new features and
58 The usual way and the UNIX way.
61 possibly several classes of things, and provide APIs tailored
64 with, it has to interact with disks one way, tapes another and
70 published on UNIX by Ritchie and Thompson [Ritchie74]:
74 Special files are read and written just like ordinary disk files,
83 Of course, the active disks and the memory special files are protected from indiscriminate access.
86 file and device I/O are as similar as possible;
87 file and device names have the same syntax and meaning,
99 disk-pack with a filesystem: selling pre-initialised and ``quality
102 In many cases some kind of API for reading and
112 device would be inode number 5, the paper-tape-punch number 6 and so on,
115 For reasons one can only too vividly imagine, this was changed and
118 describes how the implementation now used ``major and minor''
121 For all intents and purposes, this is the implementation which survives
123 Apart from the access control and timestamp information which is
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.
144 change while the system was up and running, so creating device nodes
148 the advent of TCP/IP and the telnet(1) program, or more precisely
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,
156 character if you wanted to and all the signals and all that stuff worked.
163 for system administrators, and part of this task was to create
168 just which special nodes they would need and how to create them were
181 configuration at any time: people plug USB, Firewire and PCCard
183 These devices can be anything from modems and disks to GPS receivers
189 types [Heidemann91a] and a ``device-pseudo-filesystem'' was a pretty
208 but each having their own access and timestamp attributes:
253 Other interesting details are chroot(2) and jail(2) [Kamp2000] which
258 where even the root privilege is isolated and restricted to the designated
260 Obviously chroot(2) and jail(2) may require access to a well-defined
261 subset of devices like /dev/null, /dev/zero and /dev/tty,
267 of devices, ``block'' and
269 devices would provide caching and alignment for disk device access.
277 Pick any old timer and he will be able to recite painful
285 Tapes, asynchronous ports, line printer ports and many other devices
291 \** Well, OK: and some 9-track tapes.
296 Caching and alignment modes should have been enabled by setting
302 reported to the writing process. For this reason, and since no
308 reference counts for disks and
311 .sh 1 "Files, sockets, pipes, SVID IPC and devices"
321 Sockets and pipes are also accessed via file handles but each has
325 which use the filesystem as their namespace and appear in directory
328 but you can read(2) and write(2) to it.
329 Sockets and pipes vector off at the file descriptor level and do
332 Devices land somewhere in the middle between pipes and sockets on
333 one side and normal files on the other.
335 namespace, are implemented with vnodes, and can be operated
349 illconceived 32 bit numeric namespace and a dedicated set of
353 mess, and have proposed and implemented more consistent operating systems
356 operating system when the one they have is pretty darn good, and
357 consequently research into better and more consistent ways is
365 responsible for filename translation and lookup.
371 chroot(2)/jail(2) about which devices are visible and
386 device driver, have a daemon read messages from it and create and
390 to the mix introducing new and interesting race conditions.
401 the root filesystem (and hence /dev) is read-only.
404 the architectural qualities further and certainly the KISS principle has
407 The final and in the end only satisfactory solution is to write a ``DEVFS''
410 The good news is that it does solve the problem with chroot(2) and jail(2):
415 The bad news is that it takes a lot of cleanup and care to implement
420 of corner cases in behaviour, and some of these choices have proved
435 should be supported and what should not.
444 This works as expected and with persistence in DEVFS, the link is
461 will find, and we can not know if the devices we do find
472 device ``/dev/sio0'', but we boot and do not find any sio devices?
477 want some old permissions changes to come back and haunt me,
482 five years ago, and the fact that nobody has been able to credibly
492 /dev shifts to the device drivers, and consequently the device
494 In addition an initial value for owner, group and mode bits are
501 Most device drivers know their own name and use it purposefully in
502 their debug and log messages to identify themselves.
518 to ``myprinter'', this has absolutely no effect in the kernel and can
522 device nodes since it would only lead to confusion and because the desired
527 Pseudo-devices like pty, tun and bpf,
532 physical disk to represent all possible slices and partitions.
541 example is probably ``/dev/mt0'' and ``/dev/nmt0'', where the node
551 it finds a free instance and through vnode and file descriptor mangling
563 sought first and if found, returned.
569 If one of the drivers succeeds in this, the lookup is started over and
585 user to listen to CNN, Napstered MP3 files and Quake sound effects at
597 .sh 2 "Deleting and recreating devices"
613 by matching the name and disregarding the major/minor arguments.
616 .sh 2 "Jail(2), chroot(2) and DEVFS"
618 The primary requirement from facilities like jail(2) and chroot(2)
630 mount options, and a new unlimited mount option implementation is
634 DEVFS mountpoint to the ``normal set'' of devices for a jail and
635 automatically hide all future devices and make it impossible
640 devices from appearing and will make it impossible to
648 When a device driver creates a device node, and a DEVFS mount adds it
650 control fields: mode, owner and group.
654 For one thing, embedding magic UIDs and GIDs in the kernel is simply
659 .sh 1 "Cleaning up before we build: struct specinfo and dev_t"
668 stat(2), fstat(2) and mknod(2).
670 the major# and minor# for the device.
672 as having no overlapping bits, the major# and minor#
678 but the high kernel does not (and should not!) have access to the
683 \** Basically, devices should have been moved up with sockets and
726 The device driver will extract the minor# from the dev_t and use
731 they have the same major# and minor#).
733 which vnode is the ``chosen one'' for this device, and to keep track of
736 which depending on the vnode reclamation rate and /dev directory lookup
743 and minor# combination) and all vnodes referencing this device point
767 In userland, a dev_t is still the logical OR of the major# and
773 hash table and consequently simplifying and speeding up a lot
774 of code dealing with vnode instantiation, retirement and
778 structure, removing the need for the devsw[] array and allowing
782 device for management and tuning. The control device, almost always
788 one of these, and unit number or mode information in the other.
791 indexing based on the minor#, and at the same time has obliviated
793 determined how many softc structures and therefore devices
802 the storage for specinfo early in the boot sequence and how to
805 .sh 2 "Creating and destroying devices"
807 Ideally, devices should only be created and
809 This is accomplished with the make_dev() and destroy_dev()
815 device nodes with no device driver backing in the filesystems and
820 of both ``named'' and ``anonymous'' specinfo structures.
822 The make_dev() call creates a specinfo structure and populates
824 (for instance ``lpt0''), UID, GID and access mode bits. The return
828 and the dev_t will be cleaned and converted to an anonymous dev_t.
831 is called by the driver. The driver can rely on this and keep state
844 This imposes some limitations on what can and should do be done:
847 second, to avoid deadlocks, vnodes and mountpoints should not be
857 the filesystem side of DEVFS and use atomically manipulated integer indices
862 question and do not even get near any mountpoints or vnodes.
865 dev_t and store the dev_t in the DEVFS-global inode-to-dev_t array.
876 in the dev_t and NULL the pointer in the devfs-global inode-to-dev_t
893 the make_dev() and destroy_dev() functions can be called from practically
897 or rely on the directory structure, VOP_LOOKUP and VOP_READDIR,
911 devfs-global inode-array and the directory tree of the mountpoint is
915 here because it has to deal with subdirectories and hidden entries.
929 with atomic instructions and failsafe retries to avoid the
933 DEVFS mountpoint is not updated until it needs to be, and then always by
934 a process belonging to the jail in question thus minimising and
947 This is because most device drivers (and texts on writing device
1008 NFOO is totally gone and so is the compile time allocation
1011 The foo_open (and foo_close, foo_ioctl &c) functions can now
1054 allocate memory for and we register the cdevsw structure per
1059 called through the cdevsw, and the cdevsw is only attached to
1074 facilities and functionality of DEVFS to FreeBSD.
1078 could configure and de-configure devices as they come and go.
1093 with and without their docking station. How do we want to present
1094 this to the users and what behaviour do the users expect?
1109 As it is now, device drivers propose the initial mode, owner and group
1114 points in jails and to determine other behaviour.
1128 may rename the disks, causing /etc/fstab and backup procedures
1132 disk name and allow access through this name, so that for instance
1137 To simplify this and to avoid a forest of symlinks, it will probably
1141 something like /dev/ad0/s2f and so on.
1153 correct properties and paper-handling facilities.
1157 including a powerful, simple and flexible solution supporting
1158 pseudo-devices and on-demand device node creation.
1177 quite made it to maturity and subsequently was abandoned.
1184 through their reviews and comments: Chris Demetriou, Paul Richards,
1185 Brian Somers, Nik Clayton, and Hanne Munkholm.
1192 ``The Design and Implementation of 4.4 BSD Operating System.''
1202 Poul-Henning Kamp and Robert N. M. Watson:
1225 directory and build a system using only the files, include files,
1232 \fI``I have not used block devices since I wrote FFS and that
1237 hardware and device drivers. Despite the importance of this
1250 Rob Pike, Dave Presotto, Ken Thompson and Howard Trickey:
1255 Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey and Phil Winterbottom:
1261 ``Baron M�nchhausen's Narrative of his marvellous Travels and Campaigns in Russia.''
1265 D.M. Ritchie and K. Thompson: