cy PCI driver - possible device id's

[Warner Losh]

--------
In message <

We already have exactly this =E2=80=94 a precise convention
("MODULE_PNP_INFO") and tool ("kldxref" for extracting the data, and
"devmatch" for suggesting matches), initiated by Warner. This work
has been ongoing, in stops and starts, for years. Lakhan is
converting non-compliant drivers to the convention.

Yes, and that's good and great, but it only works if you have
the modules installed on the machine to examine.
For scenarios like NanoBSD it would be nice if devmatch had a
built-in "fall-back" table (created at compile time) to suggest
modules not present in the local filesystem.

Devmatch can operate on an arbitrary loader.hints file. Just do a GENERIC
buildkernel, install it somewhere. Loader.hints gets created. Copy that
file to the target system and run devmatch...

Warner

[Slawa Olhovchenkov]

--------

I am working on converting PCI drivers attachments to be table driven.

Can we please invent some kind of "typographic" convention which
allows these tables to be extracted from the kernel source code,
so that we can have an utility which suggests which drivers to
load, by consulting such an extracted table ?

... and from /boot/loader too?..

[Warner Losh]

Post by Slawa Olhovchenkov

--------
In message <

I am working on converting PCI drivers attachments to be table driven.

Can we please invent some kind of "typographic" convention which
allows these tables to be extracted from the kernel source code,
so that we can have an utility which suggests which drivers to
load, by consulting such an extracted table ?

... and from /boot/loader

Yes.

Warner

[Warner Losh]

--------
In message <

I am working on converting PCI drivers attachments to be table driven.

Can we please invent some kind of "typographic" convention which
allows these tables to be extracted from the kernel source code,
so that we can have an utility which suggests which drivers to
load, by consulting such an extracted table ?

That's exactly what Lakhan is working on. We have the utility (devmatch),
just need to mark the drivers.

Warner

Poul-Henning Kamp | UNIX since Zilog Zeus 3.20

FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

[Poul-Henning Kamp]

--------

Post by Warner Losh
Devmatch can operate on an arbitrary loader.hints file. Just do a GENERIC
buildkernel, install it somewhere. Loader.hints gets created. Copy that
file to the target system and run devmatch...

Ahh, that was the bit I was missing...

Cool and Thanks a LOT for doing this.

[Lakhan Shiva]

At present we have devmatch infrastructure, which looks at all unattached
devices on the system and compares their plug and play data to that which
has been recorded by kldxref in linker hints and suggests modules to load.

Now, this work is to support this project achieve this in the case of PCI
drivers.

Ref: https://wiki.freebsd.org/AutoLoad

Thanks,
Lakhan

On Jun 5, 2018 11:49 PM, "Poul-Henning Kamp" <***@phk.freebsd.dk> wrote:

--------

I am working on converting PCI drivers attachments to be table driven.

Can we please invent some kind of "typographic" convention which
allows these tables to be extracted from the kernel source code,
so that we can have an utility which suggests which drivers to
load, by consulting such an extracted table ?