From: Bill Davidsen <davidsen@tmr.com>
To: Alexy Khrabrov <deliverable@gmail.com>
Cc: Linux Kernel mailing List <linux-kernel@vger.kernel.org>
Subject: Re: installing only the newly (re)built modules
Date: Wed, 10 Jan 2007 18:05:09 -0500 [thread overview]
Message-ID: <45A57125.3070406@tmr.com> (raw)
In-Reply-To: <7c737f300701101402q21ee4a8dr1ef32771d8cd78a2@mail.gmail.com>
Alexy Khrabrov wrote:
> Well, fast -- it depends! :) My Crusoe tablet, Compaq TC1000, can
> use any break it gets... And generally, the beauty of a make system
> is not to do any extra moves. Since it already knows what to build,
> why not let it install just that?
The answer just came to me, because you may have deleted creation of a
module, and make doesn't know how to get it out of the directory. So the
modules file is rebuilt from zero, rather than put in a lot of logic
which might result in problems.
Think moving a driver from module to built in, what happens if you
modprobe the module? Or if you delete a module totally because some
other module does your hardware better. Think network and sound on that,
particularly. You do NOT want the old "works-badly" module around ready
to jump in when something you overlooked loads it.
Just a case of preventing problems all at once rather than trying to be
clever. I would think building a kernel on that hardware would take
longer than the useful life of the release. I used to build 1.2.13 on a
slow machine, and that took days.
In any case you have an answer, it's because being clever is hard.
>
> Cheers,
> Alexy
>
> On 1/10/07, Bill Davidsen <davidsen@tmr.com> wrote:
>> Alexy Khrabrov wrote:
>> > The 2.6 build system compiles only those modules whose config
>> > changed. However, the install still installs all modules.
>> >
>> > Is there a way to entice make modules_install to install only those
>> > new modules we've actually just changed/built?
>>
>> Out of curiosity, why? I've noticed this, but the copy runs so fast I
>> never really thought about it as an issue.
>>
>> --
>> bill davidsen <davidsen@tmr.com>
>> CTO TMR Associates, Inc
>> Doing interesting things with small computers since 1979
>>
>
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2007-01-10 23:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-09 4:29 installing only the newly (re)built modules Alexy Khrabrov
2007-01-10 21:54 ` Bill Davidsen
2007-01-10 22:02 ` Alexy Khrabrov
2007-01-10 23:05 ` Bill Davidsen [this message]
2007-01-11 10:24 ` Tilman Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45A57125.3070406@tmr.com \
--to=davidsen@tmr.com \
--cc=deliverable@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.