Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!amdahl!amdcad!BitBlocks.com!bvs From: bvs@BitBlocks.com (Bakul Shah) Subject: Re: Naming convention for tty-like devices Message-ID: <C6q296.3D9@BitBlocks.com> Organization: Bit Blocks, Inc. References: <1993May7.140046.1826@gmd.de> <C6pI6r.6AB@sugar.NeoSoft.COM> Date: Sat, 8 May 1993 19:03:05 GMT Lines: 108 veit@mururoa.gmd.de (Holger Veit) writes: > pseudo ttys: tty[pqrst][0-9a-f] > dialin serial: ttyd[0-9a-f] > dialout serial: cua[0-9a-f] This is pretty much what most commercial UNIXes do; which is one good reason to adapt this scheme. > non-bidirectional serial: com[0-9a-f] or ttyd[0-9a-f] Why do we need to distinguish non-bidir. ports? How about a simple tty[0-9a-f][0-a-f]? It is a good idea, though, to have a synonym that corresponds to the physical device/port name (for that reason I'd prefer COM1, COM2 as synonyms for tty00, tty01 respectively -- *all* h/w documentation refers to them as COM0 and COM1). > virtual consoles: tty[0-9][0-9] How about vcon[0-9a-f][0-9a-f]? One reason is that virtual consoles (as I understand them) are really alternate screens associated with the PC display and they are rarely if ever associated with tty lines. [`virtual console' is a misnomer but I guess we are stuck with the term]. peter@NeoSoft.com (Peter da Silva) writes: >I'd like to clean up /dev a bunch anyway... create /dev/dsk and /dev/rdsk >and /dev/rmt directories for the various drive/tape entry points. Perhaps >each multiple entry point driver should have a separate directory. That >would clean up the tty mess too: > /dev/com/tty[01] > /dev/com/cua[01] > /dev/ast/tty[0123] > /dev/ast/cua[0123] > /dev/pty/tty[0-9][0-9] > /dev/con/tty[0-9][0-9] IMHO, if we stick with relatively standard names, porting programs will be much easier. [Well, that is my boring, common sense opinion but read on!] [On second thoughts, what follows is only peripherally related to tty naming conventions, so hit `n' now, if you are not interested]. While I don't like the names Peter suggests, I do like the idea of one directory per ``device server'' (a driver happens to be one kind of device server) and I urge him to develop the idea further. I like it for a number of reasons. - The /dev dir is much too big now. In the new scheme only one new entry per device driver is added to /dev. - In this scheme there is at least one implementation that gets rid of the need to reserve major numbers. - Once we have loadable drivers, it is easy to see how to add their devices. You just `mount' a new device server on a dir in /dev. [This does mean that the new scheme is more than just a renaming scheme. This is okay by me. Renaming is not worth *unless* we gain significant new functionality] - We have logical (such as the `console') as well as physical devices. Association between the two can also be made by using a single operation (could be `mount'). This cleans up a whole bunch of things: mount COM1 on console and you have redirected the console output to COM1. Mount /dev/disk/scsi/aha/1 on /dev/root and you have just changed your root device to a SCSI disk. syslog() can be replaced by a simple write to the /dev/log device (which may be attached to a file). - With a proxy device you can access devices on another machine as if they were on the local machine. [If you don't want to allow this for some devices, control that by using file permissions. The other argument against this is what if someone creates a loop? Clearly, the mount mechanism will have to catch such attempts]. - With a T device you can log everything that goes on a serial line (one leg of T goes to a file, another to the serial line, the third leg is your connection). You can also build a bidirectional mux/demux device. Such devices can be built even without such a new scheme but using them transparently is well nigh impossible. For some of them you also need a local (i.e. process relative) mount mechanism like in Plan 9. Streams can be used in place of devices like the T device but streams are a local mechanism and I'd also want a global mechanism (for example, I may want to permanently log everything on a serial line or set up a remote device as if it is local). Also note that doing this right will require a lot more work; all I wanted to do here was to _explore_ the potential of what Peter is suggesting! And there is a lot more that can be done. Okay, what about implementation (assuming we can come up with a super clean design)? We either need to extend the VFS interface or create a virtual device interface that will map trivially to the bdev/cdev interfaces and allow mount/unmount operations. The way various logical and physical devices are hardwired together will have to change. Not too bad, I'd say (at least on paper). Bakul Shah <bvs@BitBlocks.com>