From owner-freebsd-arch@FreeBSD.ORG Tue Mar 5 21:33:47 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 A6137BC2 for ; Tue, 5 Mar 2013 21:33:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 45F27E63 for ; Tue, 5 Mar 2013 21:33:47 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so2963186obc.40 for ; Tue, 05 Mar 2013 13:33:47 -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=LQ95MY+gfIJnmAGt9OunrZJxie/NwbsUYbvnkZHgvUE=; b=OG+hRsDd0Ph7o75hp/EcOs4f4fMNQicC4Gnq8e6aJsRQBaTl7qhTUF1Po5r1y0FCtc gnEuxKG2DWEoBiKZSEm+c6mrr/hi2NHfFr/AWHfNfve1ApOmUI5pXnKUE7wsdJ37EN3U QuLiTuoqubiEb3zdaLeqi33/ddqg0Iw8FGgANDS+CjL4zGHs9Oax+9W+MZlIMXWuAavW oMnNc7ojf6S6AqvxP9qodqyOQ9/kBIknjBJNx3AMeoW4GKlVin0qTeN4x7xW5lVrH+C8 hmFgVdRkq/DJv/4cVTq3ugqlJSX8ScciI6E59uKhQ+KZqLzwODizVABVG2glRkp88GKf 0Jhg== X-Received: by 10.60.10.34 with SMTP id f2mr20183140oeb.104.1362519226836; Tue, 05 Mar 2013 13:33:46 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id d10sm35952157oeh.7.2013.03.05.13.33.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 13:33:44 -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: <20130305211953.GA51357@onelab2.iet.unipi.it> Date: Tue, 5 Mar 2013 14:33:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A93AA58-713D-4C25-A512-6927E27C5DE1@bsdimp.com> References: <20130305083817.GD13187@onelab2.iet.unipi.it> <112844CF-69C3-49A3-8581-8EF2A7DA8E8A@bsdimp.com> <20130305211953.GA51357@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkJc3BhFtqtUS/QWSE0Jx3X95aJW8j0kQ988CvNmAnAj+XimTy6/jZOiO4OJ2Ux1Y6PFdw8 Cc: arch@freebsd.org 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: Tue, 05 Mar 2013 21:33:47 -0000 On Mar 5, 2013, at 2:19 PM, Luigi Rizzo wrote: > 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. Yea... You are wanting dependency checking that does not exist today, = and for which the meta-data does not exist today. 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. >> I'd say those are correct: don't compile if_rl unless you have both = rl and pci in the kernel.... There's no misunderstanding here: people = know what it means. >=20 >>> So, as said in the summary, I'd like to modify these and similar >>> lines so that the error notification comes early; normally >>> this is achieved by removing the bus name. >>=20 >> That might be OK. The original intent for this form was to allow one = to remove all pci drivers from the kernel by just removing the device = pci line from the config file. This is at best a dubious feature, = experience has shown. I'm worried that "fixing" it will produce a worse = problem than the one you are fixing. >=20 > if that is the intent, at the very least we should explain it > in the file so it is clear why "pci" and "scbus" are handled > differently. But apart form the convenience for developers > (and given we have "include", this can be easily overcome), > the "fix" i propose should only point out broken config files. They aren't handled differently. You've always had to have all the = dependencies to make things work. The fix you propose moves the problem around, and won't solve the = problem for those devices that have multiple attachments. Since that has = gone rare, that might be an OK problem exchange. However, it would be better to have required dependencies be codified = somewhere in the files.*. Not having that, your solution sucks the least = to accomplish the goals that conflict with the original design that = happened to be a bad design point in the first place.... So yea, it's fine, but the real solution isn't to solve these problems = by hacking the current system, but rather by finishing the module system = that has always been totally half-assed. To finish the system, you = likely have to ditch config(8) as we know it. Warner