cvs commit: src/sys/dev/ata ata-queue.c

[Alexander Leidinger]

Warner Losh <imp at bsdimp.com> wrote:

> From: Alexander Leidinger <Alexander at 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 at . 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.