NetBSD Problem Report #52821

From www@NetBSD.org  Fri Dec 15 13:06:46 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id DF6827A17D
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 15 Dec 2017 13:06:46 +0000 (UTC)
Message-Id: <20171215130646.084947A262@mollari.NetBSD.org>
Date: Fri, 15 Dec 2017 13:06:46 +0000 (UTC)
From: uwe@NetBSD.org
Reply-To: uwe@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: config(8) limitation with modules ioconf files
X-Send-Pr-Version: www-1.0

>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
>Last-Modified:  Fri Dec 15 22:00: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:

>Audit-Trail:
From: "Paul Goyette" <pgoyette@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52821 CVS commit: src/doc
Date: Fri, 15 Dec 2017 21:57:09 +0000

 Module Name:	src
 Committed By:	pgoyette
 Date:		Fri Dec 15 21:57:09 UTC 2017

 Modified Files:
 	src/doc: TODO.modules

 Log Message:
 Add reference to uwe's PR kern/52821


 To generate a diff of this commit:
 cvs rdiff -u -r1.13 -r1.14 src/doc/TODO.modules

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.