From owner-cvs-all Thu Mar 25 2:43: 5 1999 Delivered-To: cvs-all@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 83E2414C25; Thu, 25 Mar 1999 02:42:55 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA12488; Thu, 25 Mar 1999 09:28:23 +0100 From: Luigi Rizzo Message-Id: <199903250828.JAA12488@labinfo.iet.unipi.it> Subject: Re: cvs commit: src/sys/netinet ip_dummynet.c To: eivind@FreeBSD.org (Eivind Eklund) Date: Thu, 25 Mar 1999 09:28:22 +0100 (MET) Cc: bde@zeta.org.au, mike@smith.net.au, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, luigi@FreeBSD.org In-Reply-To: <19990325111540.B57330@bitbox.follo.net> from "Eivind Eklund" at Mar 25, 99 11:15:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2202 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > There is another thing: having to explicitly include "opt_foo.h" in all > > files related to "foo" opens the door to subtle bugs that might not be > > detected at compile time or might even cause inconsistent behaviour at > > run time. > > ... just like having the keys '1' and '2' next to each other on the > keyboard opens for typing a number incorrectly, which can lead to > subtle bugs and inconsistent behaviour at run time ;-) > WRT options: You are either going to be doing large-scale mods to lots > of stuff you can't test (e.g, device driver mods for bridge), in which > case correct inclusion of opt_xxx.h should be on your checklist before in this case the problem was the following: on 2.2.x i wrote the code, did not register the option in /sys/conf/options, and as a result i had -DBRIDGE automagically included when compiling every file. When porting things to 3.x/4.x unregistered options were not allowed anymore (i think, in any case this is a good thing) and so somehow i missed a few includes. Because nobody used this code until recently, this was undetected. With dummynet, i think i would have got instant feedback :) > > of having all "opt_*" included in "opt_global.h" unless we standardize names > > in a way that reduces conflicts... So should we go for that, e.g. having > > > > OPT_* for generic options > > DEV_* for devices > > > > and so on ? > > I'll oppose any change that removes individual dependency tracking for > options. Cleaning up to option names would be nice, of course, but it > seems unlikely. Besides, it is better to eliminate an option than to > rename it :-) i agree with you, i just took the chance to mention that cleaning option names would be a nice thing and since i might have to do it for BRIDGE, i was looking for suggestions. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: luigi@iet.unipi.it . Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message