[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 <u...@stderr.spb.ru> > Subject: Re: Attaching to an attribute > To: tech-kern@netbsd.org > Mail-Followup-To: tech-kern@netbsd.org > > 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
