Lines Matching full:would

112 device would be inode number 5, the paper-tape-punch number 6 and so on,
147 The first sign that this would not hold up as a solution came with
152 would allow a process to ``act as hardware'' for the tty.
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,
155 which would act just like any other tty: you could change the erase 
168 just which special nodes they would need and how to create them were
174 a special boot sequence would take effect if the kernel or
176 This boot procedure would
269 devices would provide caching and alignment for disk device access.
301 which would be of any use, since any write errors would never be
394 and running a daemon per jail would become an administrative
448 This drive would naturally have the name ``/dev/fd1'',
483 propose where a persistent DEVFS would actually store the 
522 device nodes since it would only lead to confusion and because the desired
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 
565 they would be able to synthesise a device node of the given name.
609 Otherwise a separate list would be needed for inodes which we had
610 deleted so that they would not be mistaken for new inodes.
622 Obviously, it would not be desirable for dynamic devices to pop
1002 would also be needed in foo_read(), foo_write(), foo_ioctl() &c.
1077 It would be logical to complement DEVFS with a ``device-daemon'' which
1110 for the device nodes, but it would be more flexible if it were possible
1134 would be a symlink to whatever topological name the disk might have
1146 It would be quite trivial to make it possible to access all the media
1147 in the library using /dev/lib/$LABEL which would be a remarkable
1152 and behind the scenes a search would be made for a device with the
1165 would probably benefit from adopting the dev_t/specinfo related