Date: Fri, 14 Nov 2003 10:35:43 -0700 (MST) From: Scott Long <scottl@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/conf kern.post.mk kmod.mk Message-ID: <20031114103425.J11888@pooker.samsco.home> In-Reply-To: <20031114.095339.121107822.imp@bsdimp.com> References: <imp@bsdimp.com> <200311141635.hAEGZqiT031464@green.bikeshed.org> <20031114.095339.121107822.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Nov 2003, M. Warner Losh wrote: > In message: <200311141635.hAEGZqiT031464@green.bikeshed.org> > "Brian F. Feldman" <green@FreeBSD.org> writes: > : "M. Warner Losh" <imp@bsdimp.com> wrote: > : > In message: <200311141604.hAEG4BCg041862@repoman.freebsd.org> > : > Brian Feldman <green@FreeBSD.org> writes: > : > : Include opt_global.h in the modules build, when building from a normal > : > : kernel build. This makes it possible for me not to get pissed off that > : > : random.ko crashes the system trying to rdtsc() when the i386/cpu.h > : > : support code decides it's okay to call that op when neither I386_CPU or > : > : I486_CPU is defined. I guess it also makes WITNESS/INVARIANTS defines > : > : get picked up by the modules. > : > > : > I've been polishing similar things that I'd hoped to get into this > : > release. I'll try to finish them up today. You should really talk to > : > people before doing these things. > : > : I know that you have been working on that, and I'm very happy to see that. > : If this makes things difficult of course there's no reason not to remove it > : other than being an interim solution for crashes people might see now. If I > : didn't know you were working on the smarter module build, I would have just > : gone through all the headers and tried to remove all the "harmful" uses of > : constants defined by opt_global.h (which I feel is very much not a > : "solution", but either way... getting rid of the problem is important, and I > : don't think that the importance is particularly diminished just because the > : bugs have existed for a while, IMHO). > > This actually is a good part of the 'first step' that I've been > wanting to get done. It just suprised me, that's all, to see it > committed the day we're trying to freeze for 5.2. > > Warner > > 5.2 code freeze does not happen until Monday. http://www.freebsd.org/releases/5.2R/schedule.html I've announced the schedule on a regular basis for the last 2+ weeks. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114103425.J11888>