Date: Wed, 19 Apr 95 11:16:27 MDT From: terry@cs.weber.edu (Terry Lambert) To: julian@freefall.cdrom.com (Julian Elischer) Cc: fs@freefall.cdrom.com, hackers@freefall.cdrom.com, hardware@freefall.cdrom.com Subject: Re: [DEVFS] your opinions sought! Message-ID: <9504191716.AA18992@cs.weber.edu> In-Reply-To: <199504190519.WAA06359@freefall.cdrom.com> from "Julian Elischer" at Apr 18, 95 10:19:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I am about ready to let people hack at devfs. > but one thing I'm not sure about: > > what is a good way for the devfs to appear? /dev/dsk/... block disk /dev/rdsk/... raw disk /dev/tty/... tty device /dev/ttym/... modem control tty device /dev/ptm/... master pty /dev/pts/... slave pty /dev/con/... console (keyboard, mouse, display, sound) /dev/mem /dev/kmem /dev/null /dev/zero /dev/tty I'd suggest that there needs to be heirarchy at least to this point. Then there are compatability issues: /dev/icmp /dev/tcp /dev/udp /dev/spx /dev/ip /dev/ipx /dev/socksys /dev/fd096ds15 etc. These probably ought to be installed when the support modules for them are installed (either statically or dynmaically). For instance, the majority of the items in the immediately previous list are for IBCS2 support. The compatability devices that duplicate functionality (like /dev/fd096ds15) should be symbolic links to the "real" device. The ... entries should be handled on a case by case basis. Note that the heircy itself implies an additional selection mechanism that would have normally be handled by major # + minor # bits. The use of symbolic rather than hard links preserves this. Unless we want to change the lookup mechanism to include flags that can be modified by previous path component lookup mechanisms when it goes iterative, this limits the available heirarchy depth to 1 directory deep. As an aside, I *would* like to add the lookup recursion flags at some point to allow easy support of multiple name spaces for a single file (ie: DOS, MAC, OS/2, and UNIX names for each file) using the POSIX "//" escape mechanism, which can only be effective on subcomponents as a file system selector currently, and should be usable as a flag). I would suggest a secondary heirarchy on the disks of DOS partition; this should be an optional layer for non-DOS-aware platforms; this perhaps implies a seperate set of nodes for the floppy device, since on DOS boxes, the floppy does not have DOS partition tables. The console device as a seperate heirarchy is a nice abstraction. This is because it allows you to change directory ownership overall on login and the permissions on devices associated with the console "just change". It is likely that we will want symlinks from the /dev/tty directory into the console directory to unify the console/non-console name space. At this point, the two letter reporting limit is now a problem. It is likely that we will want a symlink for any device that does cannonical processing using the termios code into the tty directory. I suggest the following for a start: new old ----------------- ----------------- /dev/tty/00 /dev/tty00 /dev/tty/c0 /dev/cons0 etc. That's my first take on it anyway... Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504191716.AA18992>