On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
> Better just write less bloated code. Perhaps mandatory bloatometer
> runs during -rc*s for kernels with minimal config with public code pig shame
> lists
> similar to the regression lists are useful. Anyone volunteering?
>
> I suspect there is
On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
Better just write less bloated code. Perhaps mandatory bloatometer
runs during -rc*s for kernels with minimal config with public code pig shame
lists
similar to the regression lists are useful. Anyone volunteering?
I suspect there is also
On 7/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
> On 7/24/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
>> Andi Kleen wrote:
>> >> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip)
>> when
>> >> using LinuxBIOS
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
> On 7/24/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
>> Andi Kleen wrote:
>> >> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip)
>> when
>> >> using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >> Already with these patches I can compile a zImage kernel that is 450kb
> >> large (890kb decompressed)
> >
> > The important part is not how big the vmlinux is, but how much
> > memory is actually used
On 7/24/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Andi Kleen wrote:
>> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip) when
>> using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
>> there how big the kernel is. At the moment you can't do that with
>>
Andi Kleen wrote:
Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip) when
using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
there how big the kernel is. At the moment you can't do that with
anything smaller than a 1 MB chip. But if people could use 512 KB
Andi Kleen wrote:
Some people are putting Linux kernels in the BIOS (i.e. ROM chip) when
using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
there how big the kernel is. At the moment you can't do that with
anything smaller than a 1 MB chip. But if people could use 512 KB
On 7/24/07, Helge Hafting [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
Some people are putting Linux kernels in the BIOS (i.e. ROM chip) when
using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
there how big the kernel is. At the moment you can't do that with
anything
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after boot.
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
On 7/24/07, Helge Hafting [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
Some people are putting Linux kernels in the BIOS (i.e. ROM chip)
when
using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
there how big
On 7/24/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Tue, Jul 24, 2007 at 01:50:35PM -0700, Yinghai Lu wrote:
On 7/24/07, Helge Hafting [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
Some people are putting Linux kernels in the BIOS (i.e. ROM chip)
when
using LinuxBIOS (www.linuxbios.org). It
* Date: Wed, 18 Jul 2007 12:00:05 -0700
>> If this is an issue, then changing i386 back to discarding __exit code
>> and data at linktime instead of runtime might make a bigger difference.
>
> What would really make a big difference would be to unspool the
> initramfs in such a way that it only
* Date: Wed, 18 Jul 2007 12:00:05 -0700
If this is an issue, then changing i386 back to discarding __exit code
and data at linktime instead of runtime might make a bigger difference.
What would really make a big difference would be to unspool the
initramfs in such a way that it only
On Wed, Jul 18, 2007 at 03:41:02PM -0500, Matt Mackall wrote:
> On Wed, Jul 18, 2007 at 10:10:43PM +0200, Andi Kleen wrote:
> >
> > I was waiting for someone to make that "point" ...
> >
> > >
> > > Every byte you can shave off the compressed kernel image is another
> > > byte you can use for
> Some people are putting Linux kernels in the "BIOS" (i.e. ROM chip) when
> using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
> there how big the kernel is. At the moment you can't do that with
> anything smaller than a 1 MB chip. But if people could use 512 KB chips
>
Some people are putting Linux kernels in the BIOS (i.e. ROM chip) when
using LinuxBIOS (www.linuxbios.org). It _does_ make a lot of difference
there how big the kernel is. At the moment you can't do that with
anything smaller than a 1 MB chip. But if people could use 512 KB chips
because the
On Wed, Jul 18, 2007 at 03:41:02PM -0500, Matt Mackall wrote:
On Wed, Jul 18, 2007 at 10:10:43PM +0200, Andi Kleen wrote:
I was waiting for someone to make that point ...
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your
Andi Kleen wrote:
>>
>> However, compressed size reductions as an abstract thing is useful for
>> this market. Just not these particular ones. The first thing to get
>> there is probably an LZMA-based compressor instead of gzip.
>
> That would need more memory again.
>
Actually, even with a
On Wed, Jul 18, 2007 at 01:24:41PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> > I was waiting for someone to make that "point" ...
> >
> >> Every byte you can shave off the compressed kernel image is another
> >> byte you can use for userspace on your FLASH.
> >
> > Now let's see if that
On Wed, Jul 18, 2007 at 10:10:43PM +0200, Andi Kleen wrote:
>
> I was waiting for someone to make that "point" ...
>
> >
> > Every byte you can shave off the compressed kernel image is another
> > byte you can use for userspace on your FLASH.
>
> Now let's see if that 1MB 386 contains any
Andi Kleen wrote:
> I was waiting for someone to make that "point" ...
>
>> Every byte you can shave off the compressed kernel image is another
>> byte you can use for userspace on your FLASH.
>
> Now let's see if that 1MB 386 contains any flash at all. Guesses?
>
CPUID is hardly something
> "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
Jan> On Jul 18 2007 20:20, Andi Kleen wrote:
>>>
>>> Well, how big the vmlinux file is matters if it doesn't fit in memory
>>> with enough time to get to the phase where it is dumping the init
>>> sections.
>>
>> If you don't have
I was waiting for someone to make that "point" ...
>
> Every byte you can shave off the compressed kernel image is another
> byte you can use for userspace on your FLASH.
Now let's see if that 1MB 386 contains any flash at all. Guesses?
-Andi
-
To unsubscribe from this list: send the line
Matt Mackall wrote:
>
> That's not the point at all.
>
> Every byte you can shave off the compressed kernel image is another
> byte you can use for userspace on your FLASH.
>
That wasn't the original poster's point, but yes, that is a real issue.
-hpa
-
To unsubscribe from this list:
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >> Already with these patches I can compile a zImage kernel that is 450kb
> >> large (890kb decompressed)
> >
> > The important part is not how big the vmlinux is, but how much
> > memory is actually used
Adrian Bunk wrote:
> On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
>> Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
>>> The important part is not how big the vmlinux is, but how much
>>> memory is
> And the hypothetical case where RAM is hotplugged and/or recognized after the
> kernel has been loaded by the bootloader? I do not claim to be an expert, but
RAM hotadd needs working user space to trigger it.
Besides it typically comes with cpuhotplug too, so you couldn't even
discard
On Jul 18 2007 20:38, Andi Kleen wrote:
>> >>
>> >> Well, how big the vmlinux file is matters if it doesn't fit in memory
>> >> with enough time to get to the phase where it is dumping the init
>> >> sections.
>> >
>> >If you don't have enough memory for a few tens of KB of init sections
>>
On Wed, Jul 18, 2007 at 08:33:59PM +0200, Adrian Bunk wrote:
> On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> > Andi Kleen wrote:
> > >
> > >> Already with these patches I can compile a zImage kernel that is 450kb
> > >> large (890kb decompressed)
> > >
> > > The important
On Jul 18 2007 20:33, Adrian Bunk wrote:
>> Well, how big the vmlinux file is matters if it doesn't fit in memory
>> with enough time to get to the phase where it is dumping the init
>> sections. *If that is not the issue*, then axing stuff like CPUID is a
>> major lose in terms of code
On Wed, Jul 18, 2007 at 08:29:27PM +0200, Jan Engelhardt wrote:
>
> On Jul 18 2007 20:20, Andi Kleen wrote:
> >>
> >> Well, how big the vmlinux file is matters if it doesn't fit in memory
> >> with enough time to get to the phase where it is dumping the init
> >> sections.
> >
> >If you don't
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >> Already with these patches I can compile a zImage kernel that is 450kb
> >> large (890kb decompressed)
> >
> > The important part is not how big the vmlinux is, but how much
> > memory is actually used
On Jul 18 2007 20:20, Andi Kleen wrote:
>>
>> Well, how big the vmlinux file is matters if it doesn't fit in memory
>> with enough time to get to the phase where it is dumping the init
>> sections.
>
>If you don't have enough memory for a few tens of KB of init sections
>you're very unlikely
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> >> Already with these patches I can compile a zImage kernel that is 450kb
> >> large (890kb decompressed)
> >
> > The important part is not how big the vmlinux is, but how much
> > memory is actually used
Andi Kleen wrote:
>
>> Already with these patches I can compile a zImage kernel that is 450kb
>> large (890kb decompressed)
>
> The important part is not how big the vmlinux is, but how much
> memory is actually used after boot.
>
> I expect concentrating some of the dynamic data structures
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after boot.
I expect concentrating some of the dynamic data structures would
be
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after boot.
On Jul 18 2007 20:20, Andi Kleen wrote:
Well, how big the vmlinux file is matters if it doesn't fit in memory
with enough time to get to the phase where it is dumping the init
sections.
If you don't have enough memory for a few tens of KB of init sections
you're very unlikely to have
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after boot.
On Wed, Jul 18, 2007 at 08:29:27PM +0200, Jan Engelhardt wrote:
On Jul 18 2007 20:20, Andi Kleen wrote:
Well, how big the vmlinux file is matters if it doesn't fit in memory
with enough time to get to the phase where it is dumping the init
sections.
If you don't have enough memory
On Jul 18 2007 20:33, Adrian Bunk wrote:
Well, how big the vmlinux file is matters if it doesn't fit in memory
with enough time to get to the phase where it is dumping the init
sections. *If that is not the issue*, then axing stuff like CPUID is a
major lose in terms of code maintainability
On Wed, Jul 18, 2007 at 08:33:59PM +0200, Adrian Bunk wrote:
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the
On Jul 18 2007 20:38, Andi Kleen wrote:
Well, how big the vmlinux file is matters if it doesn't fit in memory
with enough time to get to the phase where it is dumping the init
sections.
If you don't have enough memory for a few tens of KB of init sections
you're very unlikely to
And the hypothetical case where RAM is hotplugged and/or recognized after the
kernel has been loaded by the bootloader? I do not claim to be an expert, but
RAM hotadd needs working user space to trigger it.
Besides it typically comes with cpuhotplug too, so you couldn't even
discard __cpuinit.
Adrian Bunk wrote:
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after
On Wed, Jul 18, 2007 at 08:55:50AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
Already with these patches I can compile a zImage kernel that is 450kb
large (890kb decompressed)
The important part is not how big the vmlinux is, but how much
memory is actually used after boot.
Matt Mackall wrote:
That's not the point at all.
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your FLASH.
That wasn't the original poster's point, but yes, that is a real issue.
-hpa
-
To unsubscribe from this list: send
I was waiting for someone to make that point ...
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your FLASH.
Now let's see if that 1MB 386 contains any flash at all. Guesses?
-Andi
-
To unsubscribe from this list: send the line
Jan == Jan Engelhardt [EMAIL PROTECTED] writes:
Jan On Jul 18 2007 20:20, Andi Kleen wrote:
Well, how big the vmlinux file is matters if it doesn't fit in memory
with enough time to get to the phase where it is dumping the init
sections.
If you don't have enough memory for a few tens
Andi Kleen wrote:
I was waiting for someone to make that point ...
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your FLASH.
Now let's see if that 1MB 386 contains any flash at all. Guesses?
CPUID is hardly something you want to
On Wed, Jul 18, 2007 at 10:10:43PM +0200, Andi Kleen wrote:
I was waiting for someone to make that point ...
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your FLASH.
Now let's see if that 1MB 386 contains any flash at all.
On Wed, Jul 18, 2007 at 01:24:41PM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
I was waiting for someone to make that point ...
Every byte you can shave off the compressed kernel image is another
byte you can use for userspace on your FLASH.
Now let's see if that 1MB 386 contains
Andi Kleen wrote:
However, compressed size reductions as an abstract thing is useful for
this market. Just not these particular ones. The first thing to get
there is probably an LZMA-based compressor instead of gzip.
That would need more memory again.
Actually, even with a 64K
Jonathan Campbell <[EMAIL PROTECTED]> writes:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still
> remains. Things like the Pentium TSC register, DMI information, ESCD
> parsing, and the use of CPUID do not apply to
On Tue, Jul 17, 2007 at 12:59:03PM +0200, Jan Engelhardt wrote:
>
> On Jul 15 2007 14:00, Jonathan Campbell wrote:
> >
> > These patches were written against the vanilla 2.6.21.1 kernel. They will
> > have
> > no effect UNLESS you make menuconfig and explicitly enable them there.
> >
> >
>
On Mon, 16 Jul 2007, Al Boldi wrote:
> Satyam Sharma wrote:
> > Or just "cp -al" to create multiple trees at (almost) no disk cost
> > that won't interfere with each other in any way, and makes the
> > development process / generating patchsets trifle easier as well ...
>
> That would be correct
On Jul 15 2007 14:00, Jonathan Campbell wrote:
>
> These patches were written against the vanilla 2.6.21.1 kernel. They will have
> no effect UNLESS you make menuconfig and explicitly enable them there.
>
>
inline patches...
>+config X86_DONT_CPUID
>+ bool "Disable CPUID support"
>+
On Jul 15 2007 14:00, Jonathan Campbell wrote:
These patches were written against the vanilla 2.6.21.1 kernel. They will have
no effect UNLESS you make menuconfig and explicitly enable them there.
inline patches...
+config X86_DONT_CPUID
+ bool Disable CPUID support
+ depends on
On Mon, 16 Jul 2007, Al Boldi wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating patchsets trifle easier as well ...
That would be correct if
On Tue, Jul 17, 2007 at 12:59:03PM +0200, Jan Engelhardt wrote:
On Jul 15 2007 14:00, Jonathan Campbell wrote:
These patches were written against the vanilla 2.6.21.1 kernel. They will
have
no effect UNLESS you make menuconfig and explicitly enable them there.
inline patches...
Jonathan Campbell [EMAIL PROTECTED] writes:
I wrote a set of patches out of concern that even if you compile a 386
kernel a lot of code irrelevent to legacy machines still
remains. Things like the Pentium TSC register, DMI information, ESCD
parsing, and the use of CPUID do not apply to these
On Mon, 16 July 2007 20:23:04 +0300, Al Boldi wrote:
> Jörn Engel wrote:
>
> > The only place that can ensure to always break the
> > link is the kernel. Which is why I wrote the cowlink patches some years
> > back.
>
> Can you post a patch against 2.6.22?
I can and probably will.
> > The
Jörn Engel wrote:
> On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
> > On 7/16/07, Al Boldi <[EMAIL PROTECTED]> wrote:
> > >Satyam Sharma wrote:
> > >> Or just "cp -al" to create multiple trees at (almost) no disk cost
> > >> that won't interfere with each other in any way, and makes
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
> On 7/16/07, Al Boldi <[EMAIL PROTECTED]> wrote:
> >Satyam Sharma wrote:
> >> Or just "cp -al" to create multiple trees at (almost) no disk cost
> >> that won't interfere with each other in any way, and makes the
> >> development process /
On 7/16/07, Al Boldi <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> Or just "cp -al" to create multiple trees at (almost) no disk cost
> that won't interfere with each other in any way, and makes the
> development process / generating patchsets trifle easier as well ...
That would be correct
Satyam Sharma wrote:
> Or just "cp -al" to create multiple trees at (almost) no disk cost
> that won't interfere with each other in any way, and makes the
> development process / generating patchsets trifle easier as well ...
That would be correct if hardlinks would actually do a CoW on modify,
Satyam Sharma <[EMAIL PROTECTED]> wrote:
[zillions of ways to do -X dontdiff]
> Or just "cp -al" to create multiple trees at (almost) no disk cost
> that won't interfere with each other in any way, and makes the
> development process / generating patchsets trifle easier as well ...
Beware, some
Satyam Sharma [EMAIL PROTECTED] wrote:
[zillions of ways to do -X dontdiff]
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating patchsets trifle easier as well ...
Beware, some
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating patchsets trifle easier as well ...
That would be correct if hardlinks would actually do a CoW on modify,
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating patchsets trifle easier as well ...
That would be correct if
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development process / generating
Jörn Engel wrote:
On Mon, 16 July 2007 22:14:41 +0530, Satyam Sharma wrote:
On 7/16/07, Al Boldi [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
Or just cp -al to create multiple trees at (almost) no disk cost
that won't interfere with each other in any way, and makes the
development
On Mon, 16 July 2007 20:23:04 +0300, Al Boldi wrote:
Jörn Engel wrote:
The only place that can ensure to always break the
link is the kernel. Which is why I wrote the cowlink patches some years
back.
Can you post a patch against 2.6.22?
I can and probably will.
The still need a
[ the off-topic zillion-ways-to-do-same-thing-in-*nix sub-thread ]
On 7/16/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
On Monday 16 July 2007, Satyam Sharma wrote:
> > Yeah. I was going for the general principle :)
>
> Even simpler to add --exclude-from=.gitignore to diff
>
Or build in a
On Monday 16 July 2007, Satyam Sharma wrote:
> > Yeah. I was going for the general principle :)
>
> Even simpler to add --exclude-from=.gitignore to diff
>
Or build in a separate object directory, using the O=$my_objdir
Kbuild option. That has a number of addition advantages, e.g.
you can easily
On 7/16/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote:
On Monday 16 July 2007 08:45:26 Alan Cox wrote:
> > > These patches were written against the vanilla 2.6.21.1 kernel. They
> > > will have no effect UNLESS you make menuconfig and explicitly enable
> > > them there.
> >
> > Would you please
On Monday 16 July 2007 08:45:26 Alan Cox wrote:
> > > These patches were written against the vanilla 2.6.21.1 kernel. They
> > > will have no effect UNLESS you make menuconfig and explicitly enable
> > > them there.
> >
> > Would you please make mrproper before preparing the patch? It's harder
Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
> use of CPUID do not apply to these machines, but
On Sun, Jul 15, 2007 at 02:00:29PM -0700, Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the use
> of
> > These patches were written against the vanilla 2.6.21.1 kernel. They
> > will have no effect UNLESS you make menuconfig and explicitly enable
> > them there.
>
> Would you please make mrproper before preparing the patch? It's harder to
> read
> with all the "Only in..." lines.
A lot
Hi Jonathan.
On Monday 16 July 2007 07:00:29 Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
>
Hi Jonathan.
On Monday 16 July 2007 07:00:29 Jonathan Campbell wrote:
I wrote a set of patches out of concern that even if you compile a 386
kernel a lot of code irrelevent to legacy machines still remains. Things
like the Pentium TSC register, DMI information, ESCD parsing, and the
use of
These patches were written against the vanilla 2.6.21.1 kernel. They
will have no effect UNLESS you make menuconfig and explicitly enable
them there.
Would you please make mrproper before preparing the patch? It's harder to
read
with all the Only in... lines.
A lot simpler is to
On Sun, Jul 15, 2007 at 02:00:29PM -0700, Jonathan Campbell wrote:
I wrote a set of patches out of concern that even if you compile a 386
kernel a lot of code irrelevent to legacy machines still remains. Things
like the Pentium TSC register, DMI information, ESCD parsing, and the use
of
Jonathan Campbell wrote:
I wrote a set of patches out of concern that even if you compile a 386
kernel a lot of code irrelevent to legacy machines still remains. Things
like the Pentium TSC register, DMI information, ESCD parsing, and the
use of CPUID do not apply to these machines, but
On Monday 16 July 2007 08:45:26 Alan Cox wrote:
These patches were written against the vanilla 2.6.21.1 kernel. They
will have no effect UNLESS you make menuconfig and explicitly enable
them there.
Would you please make mrproper before preparing the patch? It's harder to
read
On 7/16/07, Nigel Cunningham [EMAIL PROTECTED] wrote:
On Monday 16 July 2007 08:45:26 Alan Cox wrote:
These patches were written against the vanilla 2.6.21.1 kernel. They
will have no effect UNLESS you make menuconfig and explicitly enable
them there.
Would you please make mrproper
On Monday 16 July 2007, Satyam Sharma wrote:
Yeah. I was going for the general principle :)
Even simpler to add --exclude-from=.gitignore to diff
Or build in a separate object directory, using the O=$my_objdir
Kbuild option. That has a number of addition advantages, e.g.
you can easily
[ the off-topic zillion-ways-to-do-same-thing-in-*nix sub-thread ]
On 7/16/07, Arnd Bergmann [EMAIL PROTECTED] wrote:
On Monday 16 July 2007, Satyam Sharma wrote:
Yeah. I was going for the general principle :)
Even simpler to add --exclude-from=.gitignore to diff
Or build in a separate
90 matches
Mail list logo
