From owner-freebsd-arch@FreeBSD.ORG Tue Mar 5 15:15:35 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C2BFD28 for ; Tue, 5 Mar 2013 15:15:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id D2AD27E8 for ; Tue, 5 Mar 2013 15:15:34 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id w33so6125475iag.26 for ; Tue, 05 Mar 2013 07:15:34 -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=2R2iy9VFpJlsj//chxxvJUHDCvgLhy71RJ8JX3yP4zg=; b=OLSw1n3hpe7go5cK97evjZmAPGI3Nyzx3Cbh12wn99TGfwXaOHBT0p7FXJkiXPvYAw IDFYb5IXhF6ZA+/p7PYJ7oY7WTVcmFtPBnnPQdRHAM7ySEVNRFlxnApeZJFaqN3H600C /lR8ch9gkqcfeUOmY6KsxflE/eZTSjAjtKKufBod34p9pRc4yi5APl0/JUi/igxBlcK8 /tMUMTAiuHr5f8f+XTBQ5MZ2STiL0wrO0HLfraVdR9SAsNU+PiQK8iCkEtrvdPGY57MM +Fc5iEvAJOpaWSienihVnsPE4ylePuQQE73+Mn2rYlbojZzIKFOvnKYnEP+aaXZGi2aC zX0Q== X-Received: by 10.50.88.199 with SMTP id bi7mr6481723igb.70.1362496534344; Tue, 05 Mar 2013 07:15:34 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id s8sm17840429igs.0.2013.03.05.07.15.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 07:15:33 -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: <20130305083817.GD13187@onelab2.iet.unipi.it> Date: Tue, 5 Mar 2013 08:15:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <112844CF-69C3-49A3-8581-8EF2A7DA8E8A@bsdimp.com> References: <20130305083817.GD13187@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkDdOwPwOwTcjElMmEJE6KOAldaZgC2MFePnswKlBWZCQEWWSSP2vqEsVAGiV1PqzWU2fZl 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 15:15:35 -0000 On Mar 5, 2013, at 1:38 AM, Luigi Rizzo wrote: > 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'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. > 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. 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. > Probably the only case where the "AND" form makes sense is when two > "device ..." entries in the kernel config also need to bring in > some additional files. Examples (perhaps) are drivers which support > multiple buses, such as >=20 > dev/an/if_an.c optional an > dev/an/if_an_isa.c optional an isa > dev/an/if_an_pccard.c optional an pccard > dev/an/if_an_pci.c optional an pci >=20 > but this does not seem the main usage. Yea. One problem with your suggestion though. Some busses, like pccard, = are totally loadable. you won't get an error if you don't have pccard in = the kernel, but if you stick a an card into the system it won't probe = either. In at least the case of pccard, that's intentional so that you = can load/unload pccard at runtime if you were debugging it :) > It would be really good if we could force dependencies, e.g. >=20 > "device da" implies "device scbus" >=20 > but there is no good way to specify this in sys/conf/files* without > horribly cluttering the entries for a bus with all the devices > that use it. Yes. > Probably one could extract this information from the MODULE_DEPEND() = macros Probably not. there are many conventions, but they are violated often = enough to not be automateable. > within the source tree, but i am unclear on what is the most > efficient way to process the information without having to change > config(8) -- which being written in C is a bit error-prone. Well, hacking config is error prone not because it is written in 'C', = but because it is in a style that people stopped writing in sometime in = the late 1980's because it was error-prone. > comments ? >=20 > cheers > luigi > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"