From owner-freebsd-arch@FreeBSD.ORG Wed Jul 6 16:25:50 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD74106564A; Wed, 6 Jul 2011 16:25:49 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1C38FC0C; Wed, 6 Jul 2011 16:25:49 +0000 (UTC) Received: by qyk30 with SMTP id 30so2386781qyk.13 for ; Wed, 06 Jul 2011 09:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HOc3I48gWqmpZ5jB559QLKTjrNIGlt/wVMmdGsKHNa8=; b=Sffag20koqqSop6AOLDebGRKMfQtZAsvtuA5MEFjC8afeBqdXWoAWGpm3Pow52cwA1 hjkpbYBR/dEykjFq8kowpTovqacJ1QM34tfVWFUocQHs0Zyv9n4Ac/Hi5nk8+YNvtLRc xqUpUEmfL/X47gfGzibYoLLKZO/w9r17b5xUI= MIME-Version: 1.0 Received: by 10.229.67.16 with SMTP id p16mr6509719qci.99.1309968182478; Wed, 06 Jul 2011 09:03:02 -0700 (PDT) Received: by 10.229.62.80 with HTTP; Wed, 6 Jul 2011 09:03:02 -0700 (PDT) In-Reply-To: <20110704090912.GA18578@onelab2.iet.unipi.it> References: <20110704090912.GA18578@onelab2.iet.unipi.it> Date: Thu, 7 Jul 2011 01:03:02 +0900 Message-ID: From: Masao Uebayashi To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, src-committers@freebsd.org Subject: Re: RFC: Correct location for SUBsystem-wide options ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 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 Jul 2011 16:25:50 -0000 I think that conditional build switches belong to modules. If FreeBSD designs kernel carefully so that it can run without network support at all, "network" can be said a module, and network interfaces are modules depending on "network". Then network related build switches don't need to be global. On Mon, Jul 4, 2011 at 6:09 PM, Luigi Rizzo wrote: > Hi, > in the process of deciding where to put the kernel option for NETMAP, > i have looked at the current practice, and i see a bit of confusion > on how things are done. > > Looking at the comment at the top of sys/conf/options we have > * opt_foo.h =A0 =A0 =A0 =A0 =A0 =A0 for options affecting a single source= file foo.[cs] > * opt_some_name.h =A0 =A0 =A0 for option SOME_NAME affecting only a few f= iles. > =A0 =A0 =A0 =A0 =A0 =A0 =A0for options affecting many but not a= ll files > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(e.g. all network interfac= es) > * opt_global.h =A0 =A0 =A0 =A0 =A0for system-wide options > > So, we have no standard place for options affecting all network > interfaces, which are exactly the thing i am looking at, and I > see all possible varieties in our sys/conf/options: > > INET, INET6 =A0 =A0 go into their own headers (opt_inet.h and opt_inet6.h= ) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In my view these are system wide in the se= nse that > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0INET support may use some specific code al= so in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device drivers, e.g. all the checksum and = tcp offloading > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support > > DEVICE_POLLING =A0goes into opt_device_polling.h > NETGRAPH =A0 =A0 =A0 =A0goes into opt_netgraph.h > > ALTQ, VIMAGE =A0 =A0go into opt_global.h > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(note that internal ALTQ_* options are in = opt_altq.h) > > > Missing a specific header opt_network.h, in my opinion the correct > approach is the one used for ALTQ and VIMAGE: they properly go > into opt_global.h, and we should move there also INET, INET6, > DEVICE_POLLING and NETGRAPH (and DEV_NETMAP). > > This way we reduce the clutter in all the if_*.c files, and > also avoid the risk that one of these files forgets to include > a required opt_something.h > > In any case, it is not my intention to modify the status quo, > but at least add a proper suggestion in sys/conf/options > to deal with these cases. > > Comments ? > > =A0 =A0 =A0 =A0cheers > =A0 =A0 =A0 =A0luigi > _______________________________________________ > 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" >