Don Y <blockedofcourse@foo.invalid> wrote:
> Can't you adjust the kernel configuration so that it forces
> certain probes to yield certain "devices"?
>
> E.g., instead of letting NetBSD probe disk drives in whatever order
> it encounters them -- and assigning device names in that order -- I
> build my kernels so certain device names are set aside for specific
> devices (which may or may not be present at any given boot).

That's what udev does. udev has a set of rules that indicate how devices
should be turned into device nodes, be it by physical location (PCI slot),
vendor/product ID, serial number, etc. It also sets ownership and
permissions of those device nodes (so only certain users can access a
device node). It handles creating and removing device nodes as devices are
hot plugged. It's all just some textual config files, no kernel compilation
needed.

The problem in this case is that PCI devices don't as standard support a
serial number in the way that USB or SATA does, and so this manufacturer has
done their own thing in the way the serial number is embedded. That is why
some helper code is needed to expose the serial number to udev to use in its
device naming.

(although I would have expected a rule that sets up device nodes named by
PCI slot to be equally predictable)

Theo

On 5/19/2021 1:30 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> Can't you adjust the kernel configuration so that it forces
>> certain probes to yield certain "devices"?
>>
>> E.g., instead of letting NetBSD probe disk drives in whatever order
>> it encounters them -- and assigning device names in that order -- I
>> build my kernels so certain device names are set aside for specific
>> devices (which may or may not be present at any given boot).
>
> That's what udev does. udev has a set of rules that indicate how devices
> should be turned into device nodes, be it by physical location (PCI slot),
> vendor/product ID, serial number, etc. It also sets ownership and
> permissions of those device nodes (so only certain users can access a
> device node).

OK. In NetBSD, that's part of the kernel configuration.
Things like permissions and device types (char vs block)
are handled in reasonably static files:

---------
device-major ccd char 300 block 300 ccd
device-major vnd char 301 block 301 vnd
device-major md char 302 block 302 md
device-major ld char 303 block 303 ld
device-major raid char 304 block 304 raid
device-major cgd char 305 block 305 cgd

# scsibus and its children
device-major scsibus char 310 scsibus
device-major sd char 311 block 311 sd
device-major st char 312 block 312 st
device-major cd char 313 block 313 cd
device-major ch char 314 ch
device-major ss char 315 ss
device-major uk char 316 uk
device-major ses char 317 ses
device-major se char 318 se

device-major fd char 320 block 320 fdc
....
device-major com char 260 com
device-major lpt char 261 lpt
....
-------

while the binding of device identifiers is part of the "config"
file:

------
# SCSI devices
sd* at scsibus? target ? lun ? # SCSI disk drives
st* at scsibus? target ? lun ? # SCSI tape drives
cd* at scsibus? target ? lun ? # SCSI CD-ROM drives
ch* at scsibus? target ? lun ? # SCSI autochangers
ses* at scsibus? target ? lun ? # SCSI Enclosure Services devices
ss* at scsibus? target ? lun ? # SCSI scanners
uk* at scsibus? target ? lun ? # SCSI unknown
----

E.g., in the above, I could ensure sd3 was always a particular
device on a particular scsibus at a particular SCSI ID by
creating an entry with the various wildcards (? *) replaced
by specific values. The probe will preallocate those so
they aren't assigned to some other device that happened
to be Nth in order of detection.

> It handles creating and removing device nodes as devices are
> hot plugged. It's all just some textual config files, no kernel compilation
> needed.
>
> The problem in this case is that PCI devices don't as standard support a
> serial number in the way that USB or SATA does, and so this manufacturer has
> done their own thing in the way the serial number is embedded. That is why
> some helper code is needed to expose the serial number to udev to use in its
> device naming.

Ah. I'd have thought an alternative would just be to ensure devices
of that specific *type* (manufacturer) were probed in an order that
could be enforced by the equivalent of the scheme I mentioned above.

> (although I would have expected a rule that sets up device nodes named by
> PCI slot to be equally predictable)

I guess one unanswered question is whether Wojciech is bolting his solution
onto an existing system *or* designing a system from scratch (in which case,
you would assume he could exercise some control over how the hardware is
"built"/pieced together)

środa, 19 maja 2021 o 10:52:06 UTC+2 Don Y napisał(a):
> On 5/19/2021 1:30 AM, Theo wrote:
> > Don Y <blocked...@foo.invalid> wrote:
> >> Can't you adjust the kernel configuration so that it forces
> >> certain probes to yield certain "devices"?
> >>
> >> E.g., instead of letting NetBSD probe disk drives in whatever order
> >> it encounters them -- and assigning device names in that order -- I
> >> build my kernels so certain device names are set aside for specific
> >> devices (which may or may not be present at any given boot).
> >
> > That's what udev does. udev has a set of rules that indicate how devices
> > should be turned into device nodes, be it by physical location (PCI slot),
> > vendor/product ID, serial number, etc. It also sets ownership and
> > permissions of those device nodes (so only certain users can access a
> > device node).
> OK. In NetBSD, that's part of the kernel configuration.
> Things like permissions and device types (char vs block)
> are handled in reasonably static files:
>
> ---------
> device-major ccd char 300 block 300 ccd
> device-major vnd char 301 block 301 vnd
> device-major md char 302 block 302 md
> device-major ld char 303 block 303 ld
> device-major raid char 304 block 304 raid
> device-major cgd char 305 block 305 cgd
>
> # scsibus and its children
> device-major scsibus char 310 scsibus
> device-major sd char 311 block 311 sd
> device-major st char 312 block 312 st
> device-major cd char 313 block 313 cd
> device-major ch char 314 ch
> device-major ss char 315 ss
> device-major uk char 316 uk
> device-major ses char 317 ses
> device-major se char 318 se
>
> device-major fd char 320 block 320 fdc
> ...
> device-major com char 260 com
> device-major lpt char 261 lpt
> ...
> -------
>
> while the binding of device identifiers is part of the "config"
> file:
>
> ------
> # SCSI devices
> sd* at scsibus? target ? lun ? # SCSI disk drives
> st* at scsibus? target ? lun ? # SCSI tape drives
> cd* at scsibus? target ? lun ? # SCSI CD-ROM drives
> ch* at scsibus? target ? lun ? # SCSI autochangers
> ses* at scsibus? target ? lun ? # SCSI Enclosure Services devices
> ss* at scsibus? target ? lun ? # SCSI scanners
> uk* at scsibus? target ? lun ? # SCSI unknown
> ----
>
> E.g., in the above, I could ensure sd3 was always a particular
> device on a particular scsibus at a particular SCSI ID by
> creating an entry with the various wildcards (? *) replaced
> by specific values. The probe will preallocate those so
> they aren't assigned to some other device that happened
> to be Nth in order of detection.
> > It handles creating and removing device nodes as devices are
> > hot plugged. It's all just some textual config files, no kernel compilation
> > needed.
> >
> > The problem in this case is that PCI devices don't as standard support a
> > serial number in the way that USB or SATA does, and so this manufacturer has
> > done their own thing in the way the serial number is embedded. That is why
> > some helper code is needed to expose the serial number to udev to use in its
> > device naming.
> Ah. I'd have thought an alternative would just be to ensure devices
> of that specific *type* (manufacturer) were probed in an order that
> could be enforced by the equivalent of the scheme I mentioned above.
> > (although I would have expected a rule that sets up device nodes named by
> > PCI slot to be equally predictable)
> I guess one unanswered question is whether Wojciech is bolting his solution
> onto an existing system *or* designing a system from scratch (in which case,
> you would assume he could exercise some control over how the hardware is
> "built"/pieced together)

The end user wants to be able to run it on standard Debian GNU/Linux OS.

BR,
Wojtek