From owner-freebsd-arch@FreeBSD.ORG Wed Mar 6 17:07:18 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2299866 for ; Wed, 6 Mar 2013 17:07:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 72112831 for ; Wed, 6 Mar 2013 17:07:18 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id i10so13089377oag.14 for ; Wed, 06 Mar 2013 09:07:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=I6bd4oPZw78f9ZricNvF7yqGsI5N7XaCsqfEnSafaRw=; b=KssWorrN5OfBbsCA08lf0mMWwNidROWEfGj3F5oZYLfp+ZNWdda7S51DlT/x3CZSCT 1f+L2X3lyUjvV58PYcE3eUmlhnDKAV+n5FDHGwACMqHGcVnWysafjG6VymRP3bhWOOuS ivAznmusUXNmBvswg3J7yWDCDx7iNZ8gjIsrUayQJ8Y1XLxy1Xam9nXHzcaSOVaF5Cjl mkK53qB9w3g3jeRrz/ePf5npkyQLBPlBaMzAZdNrX1fM6ML1Cu9m5XPLuAtgThpQjQ9G 3y7a7YOVq3TaKBAX/MkFoXdZvGouQY/aNTGel3cPiFF9ZOjX9drLYynAJ0Xq4GLsJNQa dLTA== X-Received: by 10.182.98.44 with SMTP id ef12mr23372264obb.25.1362589637776; Wed, 06 Mar 2013 09:07:17 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id t9sm38351388obk.13.2013.03.06.09.07.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:07:16 -0800 (PST) Sender: Warner Losh Subject: Re: revising sys/conf/files* dependencies Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130306061119.GA77841@onelab2.iet.unipi.it> Date: Wed, 6 Mar 2013 10:07:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9043EE12-24DA-4A7C-A067-D5813A082AA6@bsdimp.com> References: <20130305083817.GD13187@onelab2.iet.unipi.it> <112844CF-69C3-49A3-8581-8EF2A7DA8E8A@bsdimp.com> <20130305211953.GA51357@onelab2.iet.unipi.it> <6A93AA58-713D-4C25-A512-6927E27C5DE1@bsdimp.com> <20130306010720.GA68018@alchemy.franken.de> <20130306061119.GA77841@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQksIzBh5o9yBHlSlMk4qk+OhQ2MRLub6loNsRE/x7uEdhbccDDSv9ncaZCmNu2OTLGFycpV Cc: arch@freebsd.org, Marius Strobl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:07:18 -0000 On Mar 5, 2013, at 11:11 PM, Luigi Rizzo wrote: > On Wed, Mar 06, 2013 at 02:07:20AM +0100, Marius Strobl wrote: >> On Tue, Mar 05, 2013 at 02:33:41PM -0700, Warner Losh wrote: >>>=20 >>> On Mar 5, 2013, at 2:19 PM, Luigi Rizzo wrote: >>>=20 >>>> On Tue, Mar 05, 2013 at 08:15:30AM -0700, Warner Losh wrote: >>>>>=20 >>>>> On Mar 5, 2013, at 1:38 AM, Luigi Rizzo wrote: >>>>>=20 >>>>>> Short Summary: >>>>>>=20 >>>>>> I would like to revise sys/conf/files* and fix many erroneous = usages of >>>>>>=20 >>>>>> some/file.c optional foo_dev bar_bus >>>>>>=20 >>>>>> changing them into one of the following >>>>>>=20 >>>>>> some/file.c optional foo_dev # link error if bar_bus = is missing >>>>>> some/file.cxi optional foo_dev | bar_bus # logical OR >>>>>>=20 >>>>>> ---------- >>>>>> Full description: >>>>>>=20 >>>>>> I always thought (wrongly) that a line of the form >>>>>>=20 >>>>>> some/file.c optional foo bar baz # 1 >>>>>>=20 >>>>>> in sys/conf/files* meant that file.c is compiled in if _any_ of = the >>>>>> options is specified in the kernel config. But i was wrong, the >>>>>> above means that _all_ options are require, and the correct = syntax >>>>>> for alternative options is >>>>>>=20 >>>>>> some/file.c optional foo | bar | baz # 2 >>>>>>=20 >>>>>> I believe that i am not alone in this misunderstanding, and that >>>>>> most entries in sys/conf/files* use form #1 in a wrong way, e.g.: >>>>>>=20 >>>>>> dev/hptiop/hptiop.c optional hptiop scbus >>>>>> dev/iscsi/initiator/iscsi.c optional iscsi_initiator scbus >>>>>> dev/mfi/mfi_cam.c optional mfip scbus >>>>>> pci/viapm.c optional viapm pci >>>>>> pci/intpm.c optional intpm pci >>>>>> pci/if_rl.c optional rl pci >>>>>> (there are many many more) >>>>>>=20 >>>>>> In all these cases, if you forget the scbus or pci in the kernel >>>>>> config, the driver is not compiled in but you only detect it at >>>>>> compile time. I'd rather be notified of the error at kernel link = time. >>>> ^^^^^^^^^^^^ i meant "run time", and this is the main problem: >>>> if you forget the bus in the kernel config, the build will silently >>>> discard the entry, but you will only realize it when you actually >>>> run the kernel. Yet, having "rl" alone is surely an error, and it >>>> should be flagged as such at build time. >>>=20 >>> Yea... You are wanting dependency checking that does not exist = today, and for which the meta-data does not exist today. >>>=20 >>> Like I said, the intent of the original feature was to disable large = classes of things quickly. Nobody really does that, so that feature can = go... It is likely half broken these days. >>>=20 >>=20 >> Uhm, according to a quick test I'd say there definitely are drivers >> missing dependencies on pci in sys/conf/files, but it certainly seems >> way better than "half broken". >=20 > Marius, just to clarify: >=20 > sys/conf/files has no reasonable way to express dependencies. >=20 > Take as an example the common case (more later) > of a bus b with sources in sys/dev/b/... > and devices d1, d2, ... dn with sources in sys/dev/d*/... > All d* require b to be present in order to load. > In the modules, you express this as MODULE_DEPEND(). >=20 > Say you want to build a kernel with "device d1" but forget > to include "device b". >=20 > For sys/conf/files you have the following options: >=20 > (1) silently ignore devices with missing dependencies. > You will discover the misconfiguration at run time > (or, you can consider this a feature to quickly > remove all drivers that depend on a given bus) >=20 > sys/dev/b/b_foo.c optional b > sys/dev/b/b_bar.c optional b > ... > sys/dev/d1/d1_foo.c optional d1 b > sys/dev/d1/d1_bar.c optional d1 b > ... > sys/dev/dn/dn_foo.c optional dn b > sys/dev/dn/dn_bar_b.c optional dn b > ... >=20 > (2) omit the dependency, causing an error at link time >=20 > sys/dev/b/b_foo.c optional b > sys/dev/b/b_bar.c optional b > ... > sys/dev/d1/d1_foo.c optional d1 > sys/dev/d1/d1_bar.c optional d1 > ... > sys/dev/dn/dn_foo.c optional dn > sys/dev/dn/dn_bar_b.c optional dn > ... >=20 >=20 > (3) enforce the dependency >=20 > sys/dev/b/b_foo.c optional b | d1 | d2 | ... | dn > sys/dev/b/b_bar.c optional b | d1 | d2 | ... | dn > ... > sys/dev/d1/d1_foo.c optional d1 > sys/dev/d1/d1_bar.c optional d1 > ... > sys/dev/dn/dn_foo.c optional dn > sys/dev/dn/dn_bar_b.c optional dn > ... >=20 > Right now, some buses (e.g. pci) use #1; others (e.g. scbus) use = #2; > very few use #3 (which as you can see becomes unmanageable > when the number of customers grows, or we have a chain of > dependencies). >=20 > Warner gave an explanation why #1 can be useful. > Personally i prefer #2 so i can be notified sooner if my kernel > config file has a missing dependency. > My feeling is that many people (including myself up to a few > weeks ago) believe #1 behaves as #3. >=20 > As Warren mentioned, a proper solution requires replacing config = (8) > with something that is better suited to the task; > but i am not suggesting to do this now, I just wanted to get > opinions on whether #2 is considered significantly more useful than = #1 > to deserve a change. Marius gets all that, I'm sure. >> I'd say the proposed "fix" is only a bad kludge as it doesn't even >> solve the problem for drivers only having a PCI front-end. This is >> due to the fact that removing pci for these will only cause a link >> error iff these drivers use methods only compiled in when device pci >> is present, f.e. pci_enable_busmaster(9). However, one of the nice >> things about newbus is that the bus front-ends actually are rather >> bus-agnostic (and thus a single front-end may attach to different >> busses) and even using pci_get_{device,vendor}(9) doesn't cause a >> link error in case device pci isn't present. One example of such a >> PCI device driver compiling without device pci is sym(4). Yep, >> that example is a bit bad as sym_hipd.c actually misses the pci >> dependency in sys/conf/files. It's just the first driver I found >> and all "simple enough" drivers for PCI devices should fall in the >> same category. >=20 > as you say this does not seem to be a relevant example :) > And it uses #2 so it already in the form that i prefer... The relevant point is that the dependencies in files.* are *LINK* = dependencies. They are not *MODULE* dependencies. The difference being = exactly what Marius is talking about: the former go through a link-time = symbol. The latter is dependent only on newbus interfaces. pccard = drivers are an example of the latter, while pci drivers are an example = of the former. Warner