Speaking of all this. .. Didn't Solaris symlink the device files into some magic file system path rather than using the older major/minor special of the traditional UNIX? \

On 6 February 2018 at 20:40, Clem Cole <clemc(a)ccc.com> wrote: Have you looked at an Android phone? root@quark:/ #mount | wc -l 27 What they are isn't really important. Why on earth does my phone need 27 mounted devices, or pseudo-devices? -Henry

On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave(a)horsfall.org> wrote: No. devfs was (is?) a pseudo-filesystem where only special files corresponding to the devices enumerated by the kernel during autoconfiguration are present. The contents are synthesized at boot time and the filesystem is mounted at some canonical location (like /dev), but is otherwise ephemeral. This is in contrast to the older /dev, which is usually just a directory on the root filesystem, wherein one created a number of device files that may (or may not) correspond to an actual hardware device in the system (remember the old dance of, "cd /dev && ./MAKEDEV foo" when you added a "foo" onto your system?). The inodes and directory entries for those files actually exist in the disk-resident filesystem structures (though of course data blocks aren't allocated to those files and the inode doesn't refer to any data blocks). My understanding is that udev is an elaboration on devfs on Linux that includes a rules engine that supports things like assigning set names to specific devices, setting permissions, group/user ownership and the like. For example, one can configure a rule so that when USB UART device with serial number 0xdeadbeef gets attached to the system, it appears as /dev/console_for_foo, owned by group "fooadmin" and mod 660. Presumably whoever configured that knows that that serial device is physically connected to the serial console for "foo". - Dan C.

On Wed, Feb 7, 2018 at 11:24 AM, Arthur Krewat <krewat(a)kilonet.net> wrote: Some more commentary would be useful here, but yeah: Solaris went pretty crazy with the cheez-whiz on this stuff. /devices was the "this is what we found from autoconfiguration at boot time" thingy, and /dev was the "and here are a bunch of symlinks to those things." I don't really remember why they chose to do it that way.... Linux and BSD's devfs (as in 4.4 and its descendants) was rather simpler (pretty much what I described until udev came around and elaborated on the theme). - Dan C. On 2/6/2018 9:06 PM, Dan Cross wrote:

Well, those are surprising responses for me anyway I guess. Here's the thing about special files. They have an integer 'x' attached to them which basically means "this file represents an index into an internal kernel struct'. Now if you are comfortable with the idea that a file, with a number attached to its metadata, said number representing an index into an array of structs, which has to work for all time and all kernels: then we're just comfortable with different things. 'nuf said. moving right along, when did /dev first appear? On Wed, Feb 7, 2018 at 8:40 AM Nemo <cym224(a)gmail.com> wrote:

LOL - I did not write that ;) On 2/7/2018 7:39 PM, Dave Horsfall wrote:

On Wed, 07 Feb 2018 12:48:35 +1100 Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: Dave Horsfall writes: In the old days where a limited types of devices were available for a particular kind of machine, they could be statically assigned a major dev number (matching their index in the {b,c}devsw table). To make them accessible to users you did mknod <name> <b or c> <major> <minor> Usually via /dev/MAKEDEV. But this soon fell apart on PCs where you any number of devices can be attached. Even on Fortune Systems (pre PC) the system had an IO bus and static assignments listing out every possible device would've needed a lot of inodes. Recall that on a floppy space taken by each inode matters so we had to find a way! IIRC, the kernel essentially returned a list of mknod commands which was then run at boot time. So the point of devfs is to avoid having to do mknod manually and yet provide access to all found devices from the userland. As a side effect you can also use it for programs that run in their own sandbox or for jails and require access to a device.

Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: |On Tue, 6 Feb 2018, Bakul Shah wrote: |>> Wasn't that "devfs" (which Penguin/OS calls "udev")? I've never |>> grokked that concept. ... |> mknod <name> <b or c> <major> <minor> ... |Umm, I've known that since Edition 5; I'm not exactly new to Unix, you |know... ... |> So the point of devfs is to avoid having to do mknod manually and yet |> provide access to all found devices from the userland. As a side effect ... |That makes sense; bit of a pain when a USB device suddenly disappears just |I unplugged it, though... That was indeed one of my a-ha! moments with FreeBSD, coming from Linux! All those files in /dev and i did not know anything about anything -- which of all those many hundreds of files is actually for real? And then FreeBSD came over with the devfs and there even was a really enlightening paper, which is still shipped with FreeBSD (share/doc/papers/devfs/paper.me). From Linux which back then had the GNU LibC info file and something almost exclusively for kernel hackers in the kernel documentation directory and otherwise almost nil, to FreeBSD and a document which starts An outstanding novelty in UNIX at its introduction was the notion of ``a file is a file is a file and even a device is a file.'' Going from ``hardware only changes when the DEC Field engineer is here'' to ``my toaster has USB'' has put serious strain on the rather crude implementation of the ``devices as files'' concept, an implementation which has survived practically unchanged for 30 years in most UNIX variants. Starting from a high-level view of devices and the semantics that have grown around them over the years, this paper takes the audience on a grand tour of the redesigned FreeBSD device-I/O system, to convey an overview of how it all fits together, and to explain why things ended up as they did, how to use the new features and in particular how not to. That was fantastic, that was enlightening, and that actually seemed as such a brave move of entire FreeBSD (and it was, right)! It is still a good read. And so: suddenly i had so few files in /dev, so few that i even could start looking around a bit! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Wed, Feb 7, 2018 at 2:07 PM, Ian Zimmerman &lt;itz(a)very.loosely.org&gt; wrote: ​And that is the issue I think that Ron is reacting too. One of the lines I have had about UNIX development is the number if namespaces its has. If you try to develop something like Single System Image Clusters (check out OpenSSI.org) you'll hit all of the namespaces. Let me see how many I can remember quickly.. 1. file system 2. per device inumbers for storage 3. device major numbers 4. per device minor numbers 5. pid 6. gid 7. sockets 8. port numbers within sockets per protocol 9. system V semaphores 10. system V shared memory​ I'll stop here, you get the idea... Ron is right managing the major/minor number externally which have internal meaning to the kernel can be quite an issue. Although, in fairness, it has worked amazing well for over 40 years. It was a simple solution and did not take take up a lot of space in the kernel to implement. I'm not sure for the PDP-11, I would have wanted much more. One might suggest it was pretty damned elegant for the time. Clem ᐧ

Even notwithstanding distributed systems, dev nodes have some interesting problems. At Johns Hopkins we allowed users to mount removable disks (RK05 packs). There were hacks made to the mount program to allow no privileged users to run it. We had to disable dev nodes and setuid/setuid files from working on other than the root filesystem. Amusingly, we still found bugs. I was griping that people would mount on just any directory on the system, the mtab wouldn’t show the absolute path. I suggested we chdir to / early on or better yet, cd to /dev. That way I wouldn’t have to type /dev/ on to the device name. I say the user would have to give an absolute path anyhow since there’s nothing on /dev to mount on. Well my roommate immediately tries to prove me wrong. He tries passing various devnodes and regular files that happen to sit in /dev. Then he gets the great idea of mounting on /dev/. It works, but now we have no way to unmount it. We had to reboot the machine. I quickly modified mount to require an EMPTY directory owned by the user to be required for mounting.

On Wed, 07 Feb 2018 17:05:05 -0500 Clem Cole &lt;clemc(a)ccc.com&gt; wrote: Most all of these are intrinsic or unavoidable. You can use strings instead of table indices but still the same. And some of these have sub-namespaces. This is why plan9's mountable namespaces is such a neat solution. Too bad Unix just stole /proc & /dev/fd.... And this can be added devfs is too big a sledgehammer (+ it needs /etc/devfs.conf for permissions and ownership using its own DSL). For example, names of devices not accessible in a jail still show up there.

On Wed, 7 Feb 2018, Steffen Nurpmeso wrote: Hmmm... My box (10.4-RELEASE-p3) only has papers/devfs.ascii.gz, but yeah, it's a good read; thanks. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: |On Wed, 7 Feb 2018, Steffen Nurpmeso wrote: |> And then FreeBSD came over with the devfs and there even was a really |> enlightening paper, which is still shipped with FreeBSD |> (share/doc/papers/devfs/paper.me). | |Hmmm... My box (10.4-RELEASE-p3) only has papers/devfs.ascii.gz, but yeah, |it's a good read; thanks. From the sources; FreeBSD 11.1 unfortunately does not survive resume on this old VM so i only boot it for testing here at the moment. I am currently running only a very small OpenRC based Linux that provides binary packages; the same that i use on the server since February 2016. It will surely change again, though. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)