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"
# 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
> 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