Re: UART question

> Ok, so NetBSD:

> - creates tons of nodes for devices that are NOT physically present
>    in the machine (i.e. most of /dev)

> - does NOT create nodes for devices that are physically present (e.g.
>    UART)

> - though sometimes, it does, for some reason (e.g. I2C)

> I'm lost.  I can't find any rationale behind those behaviours. :(
> Could someone explain, please?

Well, I'm hardly authoritative.  But my take on it can be summed up
very briefly: history.

Historically, /dev was an ordinary directory, special in only two ways:
(1) it contains device special files and little-to-nothing else, and
(2) lots of code assumes "/dev/" is a path prefix for device nodes (for
example, "fdisk wd0" will, among other things, stick "/dev/" onto the
beginning of that "wd0" argument).

This is where the first property you give comes from.  Historical /dev
doesn't _have_ to contain device nodes for devices not present, but it
normally does because the cost of having unused nodes in /dev is low
compared to the cost of having to create and destroy nodes in /dev to
keep it to just what's actually present, especially since in some cases
that can change from boot to boot.p

No nodes in /dev for devices that are present is more recent, but still
of respectable antiquity.  For example, I think network interfaces
haven't existed in BSD /dev ever (though I haven't used BSD before 4.1c
and my memory of anything before I started using NetBSD is pretty
fuzzy).

Not creating nodes in /dev for devices that need them and are newly
present is, again, historical behaviour, since there was no mechanism
in place to update /dev at boot - and, to be fair, there are reasonable
arguments against such automatic creation and destruction of device
special files.

More modern systems - my impression is that Linux led the charge, but I
don't actually know - have created special-purpose filesystems to be
mounted over /dev (sometimes as a union mount or something like it,
sometimes not, depending on the design implemented by the OS in
question) which do provide exactly and only what's present (and,
usually, a few others - for example, on many systems, /dev/null is
critical even though you won't find any "null0 at ..." during
autoconfiguration).

Personally, I prefer the historical way.  devfses usually break some
properties which are occasionally useful, such as giving unusual
ownership to a device node so that a special-purpose user or group can
access it in ways not normally allowed; some devfs implementations have
some support for such things, but many don't.  Renaming /dev nodes is
another operation not always supported by devfses.  (This is one reason
I dislike the nonexistence of network interfaces in /dev; there is no
way short of hacking on the kernel code to do many of those things for
network interfaces.)  There are also chroots (and in some cases
stronger things which can include the effect of a chroot, such as Linux
namespaces); it can be useful to have a chroot's /dev include none,
some, or all of the available devices, sometimes with some of the stock
devices (eg, usually including /dev/null); devfses tend to support such
things poorly at best.

So, in summary, what you're seeing is a historical mechanism in the
process of evolving, and, as such, it's a partially inconsistent
patchwork.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B