Date: Sat, 9 Jul 2011 16:28:32 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Peter Wemm <peter@wemm.org> Cc: Attilio Rao <attilio@freebsd.org>, Sergey Kandaurov <pluknet@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [PATCH] Add MAXCPU as a kernel config option and quality discussion on this Message-ID: <20110709155856.D1090@besplex.bde.org> In-Reply-To: <CAGE5yCrmaPciAr0jtr1C978C0SPcqM5=xGJ1yovGauEY3NUjRg@mail.gmail.com> References: <CAJ-FndDZu0cBrVbH3W%2B8Tj86T5h%2BwwWqUVnjJO1rtXopKodNOA@mail.gmail.com> <CAGE5yCrmaPciAr0jtr1C978C0SPcqM5=xGJ1yovGauEY3NUjRg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Jul 2011, Peter Wemm wrote: > On Fri, Jul 8, 2011 at 8:37 AM, Attilio Rao <attilio@freebsd.org> wrote: >> In my case, I think that including opt_maxcpu is a viable panacea, but >> in general, after discussing with peter@, probabilly the better idea >> would be having a centralized script that does pre-processing before >> to start compiling and set with the right values all those constants >> (something like genassym.c, but of course with a different purpose). > > At the risk of fragmenting the thread, I wanted to clarify the goals > of what I was talking about last night. > > What makes me happy is when I can change a value in my config file, > and after running 'config FOO; make depend; make', the 6 files > affected by the value get recompiled and that's it. > > That's the point of keeping the dependencies limited. Putting stuff > in opt_global.h defeats this. Putting opt_maxcpu.h into a widely > included file also defeats this. The genassym/centralized script > approach also defeats it. Unless the centralized script is smarter about dependencies than mkdep (or make, or we) are. > I think the issue you're mainly worried about is correctly detecting > when the config override value failed to be pulled in for something > that is important. What I suggested earlier will do that and will > keep me happy by not adding false dependencies. In another thread, someone wanted to move networking options from properly implemented headers like opt_device_polling.h to omnibus headers like opt_net.h. That would expand dependencies significantly. The dependencies on opt_net.h alone might grow larger than all the global dependencies were when the kernel was smaller and before you moved the -D's from global command line to options files. I consider having multiple options per options file to be a style bug at best. Having 1 option per file allows automatic detection of certain errors. E.g., if a .c source file has an ifdef involving option FOO, then it is easy to check that it includes the correct options header for defining FOO, and vice versa, iff the correct options header is named opt_foo.h. Otherwise, or if the ifdef of the options header is included nested in another header, then there is a maze of dependencies to untangle. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110709155856.D1090>