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?
Cheers,
Alexy
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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
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?
Cheers,
Alexy
On 1/10/07, Bill Davidsen <[email protected]> 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 <[email protected]>
> CTO TMR Associates, Inc
> Doing interesting things with small computers since 1979
>
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 <[email protected]> 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 <[email protected]>
>> CTO TMR Associates, Inc
>> Doing interesting things with small computers since 1979
>>
>
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Bill Davidsen schrieb:
> 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.
Not here. On the 933 MHz P3 machine I use for driver development,
"make modules_install" takes so much time that I always copy my
modules by hand instead after recompiling them.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)