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 a
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.l
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 af
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
>> any
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 ch
* 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 r
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 us
> 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
> becaus
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 64
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 flash
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 yo
> "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 enoug
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 "u
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: s
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 af
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 actu
> 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
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
>> >yo
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
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 maintaina
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 h
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 af
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
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 af
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 wou
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 t
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
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"
>+ dep
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
[ 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 separa
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 t
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 loo
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 simpl
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
39 matches
Mail list logo
