kern/52821: config(8) limitation with modules ioconf files

[uwe%NetBSD.org@localhost]

>Number:         52821
>Category:       kern
>Synopsis:       config(8) limitation with modules ioconf files
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 15 13:10:00 +0000 2017
>Originator:     Valery Ushakov
>Release:        NetBSD-8
>Organization:
>Environment:
>Description:
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.

>How-To-Repeat:

>Fix: