Date: Wed, 18 May 2005 10:35:44 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Warner Losh <imp@bsdimp.com> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-queue.c Message-ID: <20050518103544.18i8c5w3ok8oscgw@netchild.homeip.net> In-Reply-To: <20050517.123715.74710629.imp@bsdimp.com> References: <20050517150415.cy3vhgx864kk8w8c@netchild.homeip.net> <86ekc5ubez.fsf@xps.des.no> <20050517180454.brq1tjzo2s88g8ow@netchild.homeip.net> <20050517.123715.74710629.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@bsdimp.com> wrote: > From: Alexander Leidinger <Alexander@Leidinger.net> >> And I haven't seen a technical reason why the classic way of doing >> it is bad. >> Did I missed it or do I have to say "I don't get it"? > > It is better because it uses tools in your build tree, rather than > what's installed on the system. For development, the classic way is > as good as the new way. But for upgrades and such, you can get into > lots of trouble when config or binutils, etc change. Users of -current are supposed to read current@. And they are supposed to /usr/src/UPDATING. Major changes to binutils at least provoke a HEADS-UP message in current@ (at least they did in the past). And major changes to config result in a message about mismatching versions if you run an old config binary. Changes to other subsystems which make the old or new userland incompatible with the new or old kernel are typically announced too. So typically (updating from a not too old previos version of current) it doesn't matter which way you use as long as you carefully use the offered resources. And we've survived with this procedure for a long time (I survive since ELF-day, and even when I had some hickups I always got it working again with kernel.old, loader.old and so on). This is like "the telnet problem". Alot of people yell at you that you have to use ssh and telnet is evil. But telnet is an useful tool and there are situations where it is ok to use telnet because it can't hurt you in those situations. I generally object to badmouthing tools in every situation, when there are valid uses for this tool. I favour teaching the people where it is ok and where it isn't ok to use such tools, and I show allergic reactions when someone exhibits this "everything is evil" behavior. I hope this lets you understand why I "promote" the old behavior here. >> >> If you just change one file and you want to recompile the kernel, which >> >> procedure is faster? >> > >> > They're equally fast, though 'buildkernel' normally does 'make clean' >> > and 'make depend' every time. Use NO_KERNELCLEAN when you can get >> > away with it (which is most of the time; I have it in make.conf) and >> > NO_KERNELDEPEND when you know you haven't changed the dependency tree >> > (i.e. when you haven't changed any #include statements). All the >> > usual tricks (KODIR, NO_MODULES, MODULES_OVERRIDE) also work. >> >> The "equally fast, though ..." part is funny (at least to me, YMMV)... >> >> So I have to type "make buildkernel -DNO_KERNELDEPEND" (while having >> NO_KERNELCLEAN=yes in make.conf) instead of "make"... sorry, but I'm too >> lazy to do this (at least as long as I don't get a benefit out of using the >> new way). > > alias a "make buildkernel -DNO_KERNELDEPEND" You're cheating! ;-) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 A baby is an alimentary canal with a loud voice at one end and no responsibility at the other.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050518103544.18i8c5w3ok8oscgw>