config vs. modules iconf files

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

[torn off of the original thread]

On Fri, Dec 08, 2017 at 04:40:01 +0300, Valery Ushakov wrote:

> Date: Fri, 8 Dec 2017 04:40:01 +0300
> From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> Subject: Re: Attaching to an attribute
> To: tech-kern%netbsd.org@localhost
> Mail-Followup-To: tech-kern%netbsd.org@localhost
> 
> On Fri, Dec 08, 2017 at 04:29:49 +0300, Valery Ushakov wrote:
> 
> > On Thu, Dec 07, 2017 at 23:07:47 +0300, Valery Ushakov wrote:
> > 
> > > However config(1) instead of providing single wildcard parent spec
> > > seems to instantiate parent specs for all parents it's seen that carry
> > > the attribute.
> > 
> > Bah, my emacs has too many buffers.  Apparently I was looking at the
> > kernel config from a different architecture.
> > 
> > Astonishingly, i386 and amd64 GENERIC do _not_ have
> > 
> >   wsmouse* at wsmousedev?
> > 
> > wildcard attachment and instead use separate attachments for each
> > parent.  I'm overcome with nostalgy, but this probably should be
> > fixed, it's not 1990s anymore.
> 
> This, however, still highlights a problem.  How can a module device
> driver attach wsmouse as a child regardless of how the kernel is
> configured.

I have filed http://gnats.netbsd.org/52821 for this so that it's not
lost in the proverbial cracks.

Since most people don't read all of netbsd-bugs@ I'm also duplicating
it here.  Separately, so that the PR is not spammed with every reply
(should there be any :).

----8<--------8<----

config(8) supports generating autoconf glue for modules with (still
undocumented!) "ioconf" keyword.  Multiple examples can be found under
sys/modules.  Unfortunately in certain circumstances it generates
ioconf.c structures that are not directly usable.

Consider the ioconf file for VirtualBox Guest Addtions driver:

  ioconf vboxguest

  include "conf/files"

  include "dev/i2o/files.i2o"     # XXX: pci needs device iop
  include "dev/pci/files.pci"

  device  vboxguest: wsmousedev
  attach  vboxguest at pci

  pseudo-root     pci*
  vboxguest0      at pci? dev ? function ?

  wsmouse*        at vboxguest?

wsmouse(4) attachment is necessary here because generally speaking we
cannot rely on the kernel that loads the module to have

  wsmouse*    at wsmousedev?

and in fact until very recently i386 and amd64 kernels didn't, they
only had attachments to specific parents.

Unfortunately config(8) is overzealous and seeing that wsmouse
attachment causes it to emit

  CFDRIVER_DECL(wsmouse, ...)

and it also includes wsmouse into cfdriver_ioconf_vboxguest[] and
cfattach_ioconf_vboxguest[] arrays that are to be passed to
config_init_component(9).  That obviously causes the modload to fail
as the wsmouse driver is already registered with autoconf.

My guess is that config(8) emits these because it sees the
attachments.  This probably made sense for the in-tree modules, where
the actual "device" command comes from the relevnat "files.*" file, so
the only way for config to infer what to emit is to look at the
attachments.  Also all in-tree modules only ever attach single driver,
so they never run into this problem with config (though I think uatp
module should fail to attach wsmouse when loaded).

We need a way to tell config which definitions it should emit.

Just off the top of my head, may be can just mark the attachments, e.g:

  module vboxguest* at pci? dev ? function ?

or even

  module vboxguest

where config can see that vboxguest has single possible parent and
infer the wildcard attachment.  While here, it can also infer
necessary pseudo-root so that the user doesn't have to specifiy it.

-uwe