[TUHS] Device special files

[TUHS] Device special files

[ron minnich]

these were in by the time I can along but I was wondering when they got it.

They've also always felt a bit like a thing that did not fit to me. I'm
pretty sure I was not alone, given that the Unix authors worked out a way
to get rid of them in later efforts. I know what came after, in Plan 9;
what came before, in Unix, that led to special files?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180206/8c63f9d7/attachment.html>

[TUHS] Device special files

[Larry McVoy]

Aren't the major numbers just an index into the device driver table?

On Tue, Feb 06, 2018 at 03:56:41PM +0000, ron minnich wrote:
> these were in by the time I can along but I was wondering when they got it.
> 
> They've also always felt a bit like a thing that did not fit to me. I'm
> pretty sure I was not alone, given that the Unix authors worked out a way
> to get rid of them in later efforts. I know what came after, in Plan 9;
> what came before, in Unix, that led to special files?

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Device special files

[ron minnich]

On Tue, Feb 6, 2018 at 9:56 AM Larry McVoy <lm at mcvoy.com> wrote:

> Aren't the major numbers just an index into the device driver table?
>
>
yes. But that's not my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180206/6d8b6ff8/attachment.html>

[TUHS] Device special files

[Random832]

On Tue, Feb 6, 2018, at 10:56, ron minnich wrote:
> these were in by the time I can along but I was wondering when they got it.
> 
> They've also always felt a bit like a thing that did not fit to me. I'm
> pretty sure I was not alone, given that the Unix authors worked out a way
> to get rid of them in later efforts. I know what came after, in Plan 9;
> what came before, in Unix, that led to special files?

V3 and earlier still *called* them special files, but it seems they were essentially just magic inode numbers (there was no physical file on disk, just any directory entry with the given inode would be the special file).

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man5/fs.5

[TUHS] Device special files

[Greg 'groggy' Lehey]

On Tuesday,  6 February 2018 at 14:48:19 -0500, Random832 wrote:
> On Tue, Feb 6, 2018, at 10:56, ron minnich wrote:
>> these were in by the time I can along but I was wondering when they got it.
>>
>> They've also always felt a bit like a thing that did not fit to me. I'm
>> pretty sure I was not alone, given that the Unix authors worked out a way
>> to get rid of them in later efforts. I know what came after, in Plan 9;
>> what came before, in Unix, that led to special files?
>
> V3 and earlier still *called* them special files, but it seems they
> were essentially just magic inode numbers (there was no physical file
> on disk, just any directory entry with the given inode would be the
> special file).

Isn't that still the case?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/671c68d9/attachment.sig>

[TUHS] Device special files

[Ron Natalie]

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?



	\

[TUHS] Device special files

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Are you refering to specdev when Solaris when file system crazy and
everything was it's own file system.
ᐧ

On Tue, Feb 6, 2018 at 8:36 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> 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?
>
>
>
>         \
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180206/37b018af/attachment.html>

[TUHS] Device special files

[Henry Bent]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On 6 February 2018 at 20:40, Clem Cole <clemc at ccc.com> wrote:

> Are you refering to specdev when Solaris when file system crazy and
> everything was it's own file system.
> ᐧ
>
> On Tue, Feb 6, 2018 at 8:36 PM, Ron Natalie <ron at ronnatalie.com> wrote:
>
>> 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?
>>
>>
Have you looked at an Android phone?
root at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180206/ec2e291c/attachment.html>

[TUHS] Device special files

[Dave Horsfall]

On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:

>> V3 and earlier still *called* them special files, but it seems they 
>> were essentially just magic inode numbers (there was no physical file 
>> on disk, just any directory entry with the given inode would be the 
>> special file).
>
> Isn't that still the case?

Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked 
that concept.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Device special files

[Dan Cross]

On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
>
>> V3 and earlier still *called* them special files, but it seems they were
>>> essentially just magic inode numbers (there was no physical file on disk,
>>> just any directory entry with the given inode would be the special file).
>>>
>>
>> Isn't that still the case?
>>
>
> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked
> that concept.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180206/172e229a/attachment.html>

[TUHS] Device special files

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

medusa# mount | egrep '^/dev'
/devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on 
Fri Jan 19 16:33:07 2018
/dev on /dev read/write/setuid/devices/rstchown/dev=9680000 on Fri Jan 
19 16:33:07 2018
/dev/fd on fd read/write/setuid/devices/rstchown/dev=9940001 on Fri Jan 
19 16:33:22 2018
medusa# ls -l /dev/rdsk/c1t*d0
lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t0d0 
-> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 0,0:wd,raw
lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t1d0 
-> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 1,0:wd,raw
medusa# uname -a
SunOS medusa 5.11 11.3 i86pc i386 i86pc


On 2/6/2018 9:06 PM, Dan Cross wrote:
> On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave at horsfall.org 
> <mailto:dave at horsfall.org>> wrote:
>
>     On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
>
>             V3 and earlier still *called* them special files, but it
>             seems they were essentially just magic inode numbers
>             (there was no physical file on disk, just any directory
>             entry with the given inode would be the special file).
>
>
>         Isn't that still the case?
>
>
>     Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never
>     grokked that concept.
>
>
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/cb25da3a/attachment.html>

[TUHS] Device special files

[Dan Cross]

On Wed, Feb 7, 2018 at 11:24 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> medusa# mount | egrep '^/dev'
> /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on
> Fri Jan 19 16:33:07 2018
> /dev on /dev read/write/setuid/devices/rstchown/dev=9680000 on Fri Jan 19
> 16:33:07 2018
> /dev/fd on fd read/write/setuid/devices/rstchown/dev=9940001 on Fri Jan
> 19 16:33:22 2018
> medusa# ls -l /dev/rdsk/c1t*d0
> lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t0d0 ->
> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 0,0:wd,raw
> lrwxrwxrwx   1 root     root          65 Jan  2  2015 /dev/rdsk/c1t1d0 ->
> ../../devices/pci at 0,0/pci8086,340b at 4/pci1028,1f10 at 0/sd at 1,0:wd,raw
> medusa# uname -a
> SunOS medusa 5.11 11.3 i86pc i386 i86pc
>

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:
>
> On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
>>
>>> V3 and earlier still *called* them special files, but it seems they were
>>>> essentially just magic inode numbers (there was no physical file on disk,
>>>> just any directory entry with the given inode would be the special file).
>>>>
>>>
>>> Isn't that still the case?
>>>
>>
>> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked
>> that concept.
>>
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/1cc5d6c7/attachment-0001.html>

[TUHS] Device special files

[Nemo]

[top-post righted]
> On 2/6/2018 9:06 PM, Dan Cross wrote:
>
> On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave at horsfall.org> wrote:
>>
>> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
>>>>
>>>> V3 and earlier still *called* them special files, but it seems they were
>>>> essentially just magic inode numbers (there was no physical file on disk,
>>>> just any directory entry with the given inode would be the special file).
>>>
>>> Isn't that still the case?
>>
>> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked
>> that concept.
>
> 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).
[...]
>         - Dan C.
>
>
On 7 February 2018 at 11:24, Arthur Krewat <krewat at kilonet.net> wrote:
> medusa# mount | egrep '^/dev'
> /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on Fri
> Jan 19 16:33:07 2018
[...]
> SunOS medusa 5.11 11.3 i86pc i386 i86pc

Further more (5.10 sun4u):

File Systems                                           devfs(7FS)

NAME
     devfs - Devices file system

DESCRIPTION
     The devfs filesystem manages a name  space  of  all  devices
     under  the Solaris operating environment and is mounted dur-
     ing boot on the /devices name space.

     The /devices name space is dynamic and reflects the  current
     state  of  accessible  devices  under  the Solaris operating
     environment. The names of all attached device instances  are
     present under /devices.

     The content under /devices is under the exclusive control of
     the devfs filesystem and cannot be changed.

N.

[TUHS] Device special files

[ron minnich]

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 at gmail.com> wrote:

> [top-post righted]
> > On 2/6/2018 9:06 PM, Dan Cross wrote:
> >
> > On Tue, Feb 6, 2018 at 8:48 PM, Dave Horsfall <dave at horsfall.org> wrote:
> >>
> >> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
> >>>>
> >>>> V3 and earlier still *called* them special files, but it seems they
> were
> >>>> essentially just magic inode numbers (there was no physical file on
> disk,
> >>>> just any directory entry with the given inode would be the special
> file).
> >>>
> >>> Isn't that still the case?
> >>
> >> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked
> >> that concept.
> >
> > 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).
> [...]
> >         - Dan C.
> >
> >
> On 7 February 2018 at 11:24, Arthur Krewat <krewat at kilonet.net> wrote:
> > medusa# mount | egrep '^/dev'
> > /devices on /devices read/write/setuid/devices/rstchown/dev=9640000 on
> Fri
> > Jan 19 16:33:07 2018
> [...]
> > SunOS medusa 5.11 11.3 i86pc i386 i86pc
>
> Further more (5.10 sun4u):
>
> File Systems                                           devfs(7FS)
>
> NAME
>      devfs - Devices file system
>
> DESCRIPTION
>      The devfs filesystem manages a name  space  of  all  devices
>      under  the Solaris operating environment and is mounted dur-
>      ing boot on the /devices name space.
>
>      The /devices name space is dynamic and reflects the  current
>      state  of  accessible  devices  under  the Solaris operating
>      environment. The names of all attached device instances  are
>      present under /devices.
>
>      The content under /devices is under the exclusive control of
>      the devfs filesystem and cannot be changed.
>
> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/bcc9f30d/attachment.html>

[TUHS] Device special files

[Dave Horsfall]

On Wed, 7 Feb 2018, Arthur Krewat wrote:

> 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. [...]

Thanks for that; I only have the Penguin for porting porpoises, not for 
daily use.  I write stuff on the Mac (because the USB ports are right in 
front of me), test it on a known reliable server like FreeBSD, then go and 
see what the penguins have broken this time...[*]

[*]
Yes, I do have a certain amount of contempt for a userbase that blithely 
ignores and rewrites history to the utter exclusion of Unix, such as over 
on Wikipedia where they claimed that they were the first to use "/dev/fb" 
to access the frame buffer; I've since corrected that arrant nonsense.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Device special files

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

LOL - I did not write that ;)


On 2/7/2018 7:39 PM, Dave Horsfall wrote:
> On Wed, 7 Feb 2018, Arthur Krewat wrote:
>
>> 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. [...]
>
> Thanks for that; I only have the Penguin for porting porpoises, not 
> for daily use.  I write stuff on the Mac (because the USB ports are 
> right in front of me), test it on a known reliable server like 
> FreeBSD, then go and see what the penguins have broken this time...[*]
>
> [*]
> Yes, I do have a certain amount of contempt for a userbase that 
> blithely ignores and rewrites history to the utter exclusion of Unix, 
> such as over on Wikipedia where they claimed that they were the first 
> to use "/dev/fb" to access the frame buffer; I've since corrected that 
> arrant nonsense.
>

[TUHS] Device special files

[Dave Horsfall]

On Thu, 8 Feb 2018, Arthur Krewat wrote:

> LOL - I did not write that ;)

Yeah, I've just replied to Dan.  The References: line of my reply as 
received was:

     References:
 	<CAP6exYLTp1bOBAaewKuv0VGTAckvR86bjROUic10u64rd3u+DA at mail.gmail.com>
      <1517946499.3717582.1261737872.3DC598F2 at webmail.messagingengine.com>
      <20180207012556.GL30690 at eureka.lemis.com>
      <alpine.BSF.2.21.1802071239090.50080 at aneurin.horsfall.org>
      <CAEoi9W4YORBdVT1OgGobNqtjhGexT05uSqTOGL22q1D0pvpTsw at mail.gmail.com>
      <ec74c580-34f7-794b-815c-d3a5949a7f5a at kilonet.net>

so I dunno what happened...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Device special files

[Bakul Shah]

On Wed, 07 Feb 2018 12:48:35 +1100 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Wed, 7 Feb 2018, Greg 'groggy' Lehey wrote:
> 
> >> V3 and earlier still *called* them special files, but it seems they 
> >> were essentially just magic inode numbers (there was no physical file 
> >> on disk, just any directory entry with the given inode would be the 
> >> special file).
> >
> > Isn't that still the case?
> 
> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never grokked 
> that concept.

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.

[TUHS] Device special files

[Dave Horsfall]

On Tue, 6 Feb 2018, Bakul Shah wrote:

>> Wasn't that "devfs" (which Penguin/OS calls "udev")?  I've never 
>> grokked that concept.
>
> 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>

[...]

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 
> you can also use it for programs that run in their own sandbox or for 
> jails and require access to a device.

That makes sense; bit of a pain when a USB device suddenly disappears just 
I unplugged it, though...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Device special files

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> 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)

[TUHS] Device special files

[Ian Zimmerman]

On 2018-02-07 19:36, Steffen Nurpmeso wrote:

> 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

Well, if you don't try to connect your toaster to the computer, you
don't have this problem :-)

I had a self-maintained Linux system (ie. no distribution) until about
2000.  I had no problem understanding what the two dozen /dev/ entries
were for.  I even wrote a better (table driven) makedev implementation
and I tried to get it into Debian, but by that time rumors of devfs were
already on the way so it wasn't worth a transition to them.

The real problem with static /dev is on the development side IMO -
managing the namespace of device names and major/minor numbers.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[TUHS] Device special files

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Wed, Feb 7, 2018 at 2:07 PM, Ian Zimmerman <itz at very.loosely.org> wrote:

>
>
> The real problem with static /dev is on the development side IMO -
> managing the namespace of device names and major/minor numbers.

​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
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/f48125ec/attachment-0001.html>

[TUHS] Device special files

[ron minnich]

On Wed, Feb 7, 2018 at 2:06 PM Clem Cole <clemc at ccc.com> wrote:

>  One might suggest it was pretty damned elegant for the time.
>

yes, it was quite fine then.

Getting distributed systems right is not simple. There have been lots of
efforts to get it right by larding more and more software over what's
already there. It can be made to work but it's never very nice. I tend to
prefer the take stuff away approach myself, but to each his own.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/1ca4d2fa/attachment.html>

[TUHS] Device special files

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180207/89336ddf/attachment.html>

[TUHS] Device special files

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On Wed, Feb 7, 2018, at 17:48, Ron Natalie wrote:
> 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.

Would a mknod (in the new /dev or anywhere else) to "recreate" the device file have worked? Requiring an empty directory seems a bit overkill vs simply requiring an absolute path (perhaps one that does not begin with /dev) or having the mount command calculate the absolute path.

(I'm mildly surprised that if this was in the era where . and .. were simply hardlinks created by mkdir(1), mounting on /dev/. didn't simply literally mount on /dev/. leaving /dev alone, which would have been an interesting state but wouldn't have prevented unmounting)

Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway? This seems to have been fixed in NFSv2, 4.3BSD-Uwisc, and Linux, but why was it like that in the first place? It *seems* like in the V6 era code the system could have just as well checked m_inodp for a match to the directory as m_dev for the device.

[TUHS] Device special files

[Bakul Shah]

On Wed, 07 Feb 2018 17:05:05 -0500 Clem Cole <clemc at ccc.com> wrote:
> 
> 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

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.

[TUHS] Device special files

[Steffen Nurpmeso]

Ian Zimmerman <itz at very.loosely.org> wrote:
 |On 2018-02-07 19:36, Steffen Nurpmeso wrote:
 |> 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
 |
 |Well, if you don't try to connect your toaster to the computer, you
 |don't have this problem :-)

A killer argument.

 |I had a self-maintained Linux system (ie. no distribution) until about
 |2000.  I had no problem understanding what the two dozen /dev/ entries
 |were for.  I even wrote a better (table driven) makedev implementation
 |and I tried to get it into Debian, but by that time rumors of devfs were
 |already on the way so it wasn't worth a transition to them.
 |
 |The real problem with static /dev is on the development side IMO -
 |managing the namespace of device names and major/minor numbers.

If you have grown up with this and are experienced, or have
a small system, or have a system with good documentation, then you
might be right.  (You are definitely right with the latter, say.)
I was lost in a jungle of things i did not understand including
lots of frightening but anyway apparantly dead Z(ombie) processes
(SuSE debug distribution offered for very few money and bought as
side-effect on 1999-01-11).  And then it is indeed true that
having a device file does not mean there is actually a driver
behind it.  No magic springs-into-existence, if i recall
correctly.

--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)

[TUHS] Device special files

[Dave Horsfall]

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.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Device special files

[Rafael R Obelheiro]

On Wed, Feb 7, 2018 at 8:04 PM, Dave Horsfall <dave at horsfall.org> 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.
>

FWIW, it's available in other formats at
https://www.usenix.org/legacy/publications/library/proceedings/bsdcon02/kamp.html

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180208/de5eeeda/attachment.html>

[TUHS] Device special files

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> 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.

[TUHS] Device special files

[Noel Chiappa]

    > From: Greg Lehey

    >> V3 and earlier still *called* them special files, but it seems they
    >> were essentially just magic inode numbers (there was no physical file
    >> on disk, just any directory entry with the given inode would be the
    >> special file).

    > Isn't that still the case?

From reading the manual page (URL sent earlier), in V3 and before it really
was just an inode _number_ (less than 50, IIRC). The first inode, in the
first disk block after the super-block, was inode #51. This is of course
different from later Versions, where there is an _inode_ for devices, but
still no actual _file_.

	Noel

[TUHS] Device special files

[Doug McIlroy]

> Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway?

Symmetry. You unmount what you mount.

A competing model is that of links. Link makes an old file available
under a new name. But you unlink by the new name. Necessarily so,
because there may be many new names for one old file.

This is reminiscent of Don Norman's screed about the unnaturalness
of Unix. He didn't like strcpy because the arguments come in the
opposite order to those of cp. But stcpy is part of C, and in
C the destination of assignment comes before the source. But Norman
didn't rail at C. You pays your money and takes your choice.

Doug