Date: Mon, 4 Dec 2000 17:17:25 -0700 From: Mike Porter <mupi@mknet.org> To: Rich Morin <rdm@cfcl.com>, freebsd-doc@freebsd.org Subject: Re: documenting /dev/* Message-ID: <00120417172504.00662@mukappa.home.com> In-Reply-To: <p05001918b651b0ea46a9@[192.168.168.205]> References: <p05001918b651b0ea46a9@[192.168.168.205]>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 04 Dec 2000, Rich Morin wrote: > In documenting /dev/*, I came to some conclusions about it. Here they > are, along with a proposed remedy. > > -r > > devs_proposal, 2000.12 > ====================== > > /dev is a mess. It may work OK for programs, but it is a disaster for > humans. So, here is a modest proposal for a rework (DUCKING). > If I understand correctly, this will be moot Real Soon Now with the implementation of devfs (currently just on -current, but they seem to be makeing progress with it). > Because /dev is "wired in" to any number of programs, it must live on. > A "structured dev" directory (/sdev) can, however, be created and used > as a friendly alternative. /sdev will contain the same device names as > /dev does, but they will be organized by a set of subdirectories, as: > <snip> > The implementation of /sdev is simple in principle, but complicated > in practice. Each device node in /sdev is simply a hard link to a > node in /dev. The difficulty lies in knowing where the links should > go. I have a reasonable starting point on an index of /dev nodes, > but more work will be needed before it can drive a creation script. I think you are going the wrong direction here; it seems to me (IMHO) that it would be easier to put code into /dev/Makedev to create and link /sdev (or whatever you want to call it. So that Making all devices could automatically create your sdev directory as well (rather than have to parse you existing /dev and compare existing entries against a database of all possible entries (since there is already more or less this functionality in /dev/Makedev)). I'm not sure that is the answer either, necessarily, though it would clean things up from a Human Interface standpoint. Of course, *nixen have never been known for great UI <(}: IMHO I think a better approach would be a man page (though it can get tedious to scroll through a man page) or handbook chapter ( I just checked the online version and didn't see any mention of /dev) detailing the information; a lot of the stuff is redundant (rcd0 and cd0 point to the same device, one is enabled for "raw" and one is enabled for character mode, for example, and cd0, cd1, cd2, etc, may point to different devices, but the info would be the same. Also a man or handbook entry allow you to say "Device: cd(n)(rcd(n))" and then explain that mcd0, acd0, scd0 are just different versions of the same thing (for matsushita, atapi, and sony interfaces, respectively, in this case), without having to have a line for each of them, or the confusing ( |r)(m|s|a|?)cd? explaination. A handbook entry (or just a link to a database of sorts) could also be "reverse indexed" so searching for "scd0" would link to the "cd" entry mentioned above. It is still a terrbily ardous task, given that practically every device supported by *bsd has its own entry in /dev, or potentially "could have" and entry in /dev, which is why I think doing it as a "readme" style file is going to be out of the question. And having siad all that, I think I am going to bow to Nik's comment about perhaps this isn't entriely on-topic.... mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjosNBUACgkQZ7GovTQbIm6ksgCeMQX/fuYHdOoBcZDEcvRkJPi9 ZMwAmgKQUS9uCjpKKoRnbrHJ1TumMYHH =aZ7z -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00120417172504.00662>