Re: UART question

[email protected] (Vincent DEFERT) writes:

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

There is no rationale, just history.

Drivers are identified by the major device number. The mapping originally
was machine specific because the possible numbers are limited and
many devices are machine specific.

Later common major numbers were assigned to new drivers that can be
shared between machine architectures.

MAKEDEV for a specific architecture just creates nodes in /dev for
these drivers (with a varying number of units for each).

To stretch the limits of such static number assignments, NetBSD
also allows to allocate major numbers dynamically when a driver
is loaded. This isn't really useful for a static /dev directory
and requires dynamic entries (aka a "devfs").

The person who implemented the meson uart driver (and the exynos uart
driver) is using such dynanmically assigned major numbers.

There is no consensus about a "devfs". There is the devpubd userland
daemon that serves a similar purpose, but which doesn't know about
mesonuart either.

The most simple way to support mesonuart is to add a MAKEDEV.local
script that handles that driver and use devpubd to call MAKEDEV
(that's a standard functionality in devpubd).


Greetings,