Driver Update Disk discussion

[M. Warner Losh]

In message: <421E7867.9060101 at samsco.org>
            Scott Long <scottl at samsco.org> writes:
: - runtime support.  Where will modules be put, how will they be ensured
: to not collide with the base system modules, and how will the system
: ensure that they get loaded on every boot.  Most of the pieces are in
: place right now via the loader knowing about /boot/modules, and
: /boot/loader.conf able to be modified to point to modules in there.
: What is missing is a formal definition of how these pieces work, and
: tools to automate and manage it for the user and vendor.

Right now /boot/modules is preserved on all kernel installs.  What
else is necessary?  If we have a working packaging system, then
installation is taken care of in a manner similar to
/usr/local/bin/emacs.

A bigger issue is that most of the probe routines return 0 now.  This
means that only devices that have no support at all in the base kernel
can be overridden.  I'm working to fix this and hope to get that done
before 5.4 at least for PCI and maybe usb and firewire (those probe
routines which can be called multiple times), but maybe not for ISA
and some PC Card drivers.  This likely will be sufficient for any
vendor that will want to provide drivers for any modern system.

: - kernel option support.  How do we support vendor modules in a kernel
: that might be compiled with PAE (rather common these days), SMP, MAC,
: etc.  The loader and /boot infrastructure has no concept of this.  It's
: highly important, though.

The answer in the past is that 'there shall be only one'.  SMP doesn't
change the module ABI (you can use modules on SMP and non-SMP
kernels), but PAE does (since it changes a few key data types).  Right
now I believe that it is the only option that does change the ABI.
Last time I looked, MAC didn't change the ABI at all, but so much has
happened there that this may have changed things.  The discussions at
the time when all this was hashed out for kld(9) and /boot stuff was
that it was undesirable to be able to have options that affect the ABI
since that would quickly lead into a combinatoric nightmare.  Nothing
has really changed here: we want to have as few ABIs as possible,
ideally 1.

I believe that PAE support really should be a seprate kernel
architecture and branded as such.

Clearly, we can revisit the decisions of the past on this issue.

: - source code support.  A vendor might want to distribute source code
: for the module that would be picked up in a kernel re-compile.  Patching
: the src/ tree is the only way to do that now, and that creates problems
: when interacting with cvsup.  Solving this would tie into the problem of
: compiling drivers out of ports/.  In fact, a vendor driver, both in
: source and in binary form, should probably be treated as a port/package,
: and I describe below.

One does not need to patch the source tree at to pick up ports modules
for a kernel rebuild.  One can build the ports modules as part of the
kernel by simply defining PORTS_MODULES in a kernel config file.  In
addition, one can specify absolute paths with MODULES_OVERRIDE.  One
can also build modules outside the tree against a specific kernel (if
they somehow depend on the config files).

There is one bug with PORTS_MODULES, I'll grant, but that is easy to
fix (install should be translated into deinstall/reinstall, but
isn't).  This bug is easy to work around right now by defining
FORCE_PACKAGE_REGISTER, but it should be fixed.

: - kernel api/abi.  We are trying to keep the kernel api/abi stable now,
: which helps a lot.  However, there is a chance that these could change
: for legitimate reasons.  How do we protect binary-only modules from
: this?  Linux has a fairly draconian system of hashing all of the
: exported kernel symbols with the kernel options and the kernel
: major/minor/subminor versions, and making the linker reject modules that
: don't have the right hash.  Should we follow with something similar, or
: should we have runtime checks that check symbol/structure signatures?
: Or should we say that we make no guarantees about a binary-only module
: working on anything but a -RELEASE kernel?

Until we have a well defined API that's well documented, I think that
any pretense of a guarantee overstates what we'll be able to deliver.
Many of the APIs are documented, and most drivers can be written using
just these APIs.  However, the fussiness needs to change.  We also
need to have some sort of regression tests

There was some work done to make all 5.x drivers depend on a kernel
module version 5, but that didn't make it into 5.x due to time
constraints on my part (and no one else seemed to be motivated to pick
things up).  We might want to revisit this.

As a practical matter, we can make no guarantees about anything but
-RELEASE.  In fact, given the total lack of regression tests, it would
be hard to tell vendors that we can be sure that their drivers will
work.  The documentation for the API we have is weak, but we manage to
do a pretty good job of not making major changes to its core.  I'll
point out that most minor releases historically have changed something
in the interfaces, but it has usually been so minor that no one
noticed...

: - kernel namespace.  Devclass collisions seem to already be handled
: gracefully.  devfs collisions aren't, and maybe some seatbelts here
: would be good.  Linker symbol collisions are what I really worry about,
: since they will prevent a vendor from installing an updated driver on
: top of an existing driver with a overlapping set of non-static symbols.
: I know that we do some sort of magic symbol hiding while compiling the
: kernel, but does that apply to modules also?

All the module symbols are completely hidden from everybody who does
not profess a dependency on a module, unless the module goes out of
its way to export symbols.  So this works well for us.

devfs isn't handled at all, you are right.

: These are the big things I can think of right now.  Solving it is a big
: task, but it's something that we need to do if we want vendor support to
: continue and to grow.  If anyone is interested in helping with the
: design and engineering of this (this isn't a call for testers!), please
: let me know.

Yes.  There's a lot of issues to work through...

Warner