devmatch(8) committed ....

[Warner Losh]

On Mon, Dec 25, 2017 at 2:44 PM, Emmanuel Vadot <manu at bidouilliste.com>
wrote:

>
>  Hello Warner,
>
> On Mon, 25 Dec 2017 11:57:10 -0700
> Warner Losh <imp at bsdimp.com> wrote:
>
> > I've committed devmatch(8) to the tree in r327176. It's a building block
> > for automating the loading of modules. While we can load modules today by
> > adding FOO_load=YES to loader.conf, there's no easy way to load only the
> > modules you need based on the hardware you have in the system.
> devmatch(8)
> > provides the base framework to allow one to do that. It does this my
> > looking at the PNP tables recorded in /boot/kernel/linker.hints.
> >
> > The version I've committed doesn't have the devd nor the rc.d
> integration.
> > I've committed it for people to play with and give me feedback while
> those
> > parts are finalized (and while other bugs are fixed). I don't intend to
> > commit them until the kinks are worked out.
> >
> > Some notes:
> >
> > (1) You'll need a newly built kernel. Older kernels have minor bugs that
> > allowed the terminating sentinel to be included in linker hints. All
> known
> > oens, at least for amd64, have been fixed.
> > (2) Lots and lots of drivers need to have their plug and play tables
> > decorated. This is where I need people's help. I'll be writing up
> something
> > for those that want to help. ISAPNP, PC Card and USB drivers already have
> > this data. A few PCI drivers have it, and almost no ACPI drivers. The
> data
> > is generally there, just not properly decorated for devmatch(8) and
> > kldxref(8) to do their thing.
> > (3) There's an issue with the USB pnp data. It's too long for the current
> > devinfo(3) interfaces. I have fixes in the works to correct this. I could
> > just bump the limits, but I want to do something more general and long
> term.
> > (4) The end game for this is a GENERIC with most of the drivers removed
> > that loads drivers automatically. Bootable storage drivers will have to
> > remain for now until the loader can make use of this code.This is why the
> > warning about hinted ISA devices went into the tree this week.
> > (5) modules will print more than once. also the if_em/if_igb driver is a
> > hard link so both of those will always print.
> >
> > Please send me your feedback. Happy Holidays!
> >
> > Warner
>
>  This is all excellent news I can't wait to try.
>
>  I've not currently started to look at the code but have you thought of
> fdt based system ? I would love a minimal GENERIC arm/arm64 kernel with
> everything else in modules.
>  I know we still have to do a lot of work in the arm world to make
> almost everything usable in module form.
>

It's completely bus agnostic. There's no code in devmatch() that knows
anything at all about any specific bus. fdt is easier than most because
it's just a simple string compare and several of the drivers are already
properly decorated.

Warner