* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-05 23:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: H. Peter Anvin, linux-embedded
In-Reply-To: <20080605004630.GA26259@linux-sh.org>
On Wednesday 04 June 2008 19:46:30 Paul Mundt wrote:
> On Wed, Jun 04, 2008 at 12:36:11PM -0500, Rob Landley wrote:
> > Actually if you ever need to diagnose early boot stuff on _any_ platform,
> > you do need a console. But it can be serial or netconsole, as long as
> > that works...
>
> Except for the minor fact that most early boot debugging happens long
> before the console subsystem is even available..
Isn't that why CONFIG_EARLY_PRINTK was written? (And I mentioned Linus's hack
using the RTC to see how far the _really_ early stuff got.)
> At the risk of perpetuating the stupidity of this thread..
I plead the fifth.
> If you ship a
> device to a customer expecting them to debug it for you, you are likewise
> not likely to be very commercially successful, either.
There are such things as field servicable devices where companies either send
people out into the wild or get hardware brought in for service.
However, looking at the message you're replying to, I was talking about during
development. (Remember how the early linksys boxes didn't have the serial
port physically wired up to the outside, but if you busted out a soldering
iron you got a shell prompt on it without even installing new software? They
didn't change it after they got it working because they didn't want to
re-validate their image? Yeah, that kind of stuff gets shipped.)
Sure if the device in the field doesn't boot, it's cheaper to just replace it,
unless you need to get data off the sucker (in which case they bring it in).
But the defective units returned to the factory sometimes get diagnosed so
they can reduce the future return rate (or resell 'em used if it was pilot
error), so once again it helps if it's possible to service 'em after the
fact. Depends on the company.
> Devices are not shipping with consoles, period.
Earlier I was trying to distinguish between /dev/console (no controlling tty),
virtual terminals (tied to old VGA hardware although possibly usable through
the framebuffer, I'm unclear on this), the tty layer (which is what I
initially thought the patch was aimed at, but it seems to be the vga VT
stuff), and having a bitmapped display (may be GUI only). Four separate
things, I've lost track of which we're talking about here.
When you imply it's stupid to think anyone will ever have a console on an
embedded system (because we all know the embedded world is far more uniform
than crazy diverse things like the desktop space), which of these are _you_
referring to?
My cable modem has a serial port that gives me a login prompt if I plug into
it, and I watched the guy at sprint bring one up last time I broke my cell
phone so he could get my number list off it. That kind of console may be
useful out in the real world, and that's the kind of console I was talking
about in the message you replied to.
I've learned that "I don't do that, therefore nobody ever will" is not always
the world's greatest assumption. Somebody out there may want a console, and
they may not want the overhead of internationalizing it because although
their customers speak mandarin, their field service people do not.
Somebody out there may also want to do something I consider a bad idea.
(Compared to shipping a device with Windows CE on it, any quibble I have
about Linux configuration is a rounding error.)
> If you disagree with this, you've
> obviously never shipped a device.
Since I haven't shipped only _one_ device, and since I used to own a tuxscreen
phone which may actually meet _all_ the above definitions of "console", I
guess it's ok for me to disagree with this?
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Uwe Klein @ 2008-06-05 7:18 UTC (permalink / raw)
Cc: Tim Bird, linux-tiny, Sam Ravnborg, linux kernel, linux-embedded
In-Reply-To: <20080604202314.GG4189@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> I'm coming more from the point that drivers/media/ might be the area
> in the kernel that currently offers the biggest flexibility - and this
> stuff breaks multiple times for each kernel release, and sorting this
> out is often nontrivial.
Only partially connected:
I have run into trouble in conjunction with the rtai patches
and the no_console option regularly over a couple of years.
compiling is ok linking breaks on afair on ?*pcspeaker*?
and some other symbols. reported it as a bug with rtai.
Due to time constraints I reactivated the console and moved on.
Imho TINY setup and RT patches go together on a regular basis.
so some breakage goes beyond the kernel.
uwe
--
Uwe Klein [mailto:uwe.klein@cruise.de]
KLEIN MESSGERAETE Habertwedt 1
D-24376 Groedersby b. Kappeln, GERMANY
phone: +49 4642 920 123 FAX: +49 4642 920 125
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Jörn Engel @ 2008-06-05 6:55 UTC (permalink / raw)
To: Tim Bird
Cc: Adrian Bunk, Sam Ravnborg, linux-tiny, linux-embedded,
linux kernel
In-Reply-To: <4846FE3E.4020508@am.sony.com>
On Wed, 4 June 2008 13:42:38 -0700, Tim Bird wrote:
> Adrian Bunk wrote:
> > I might be wrong, but although monitoring the size makes a lot of sense
> > I don't believe "fully automate the testing ... and send notifications"
> > will work.
>
> "fully automate" was sloppy wording on my part. "automate enough
> to not be a burden to maintain" is what I should have said.
Even that blows. People all too easily forget about the end-to-end
principle. If you want a system that scales well, you have to push as
much work as possible to the ends and do as little as possible in the
center. Applies here as well as in networking.
If CELF funds 20 people to do such tests, they may be able to cope
today. But the stream of developers keeps swelling, so even those 20
won't be able to cope long-term. Instead we have to enable everyone in
the stream of developers to easily check for themselves. If then stream
keeps swelling, the amount of bloat-checking swells along.
What scales well is the "make check*" targets in the source. Some even
claim it scales too well and attracts too many clueless janitors. I'd
be happy if we ever get into the same trouble with bloat checking. ;)
Jörn
--
Das Aufregende am Schreiben ist es, eine Ordnung zu schaffen, wo
vorher keine existiert hat.
-- Doris Lessing
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Paul Mundt @ 2008-06-05 0:46 UTC (permalink / raw)
To: Rob Landley; +Cc: H. Peter Anvin, linux-embedded
In-Reply-To: <200806041236.12349.rob@landley.net>
On Wed, Jun 04, 2008 at 12:36:11PM -0500, Rob Landley wrote:
> Actually if you ever need to diagnose early boot stuff on _any_ platform, you
> do need a console. But it can be serial or netconsole, as long as that
> works...
>
Except for the minor fact that most early boot debugging happens long
before the console subsystem is even available..
At the risk of perpetuating the stupidity of this thread.. If you ship a
device to a customer expecting them to debug it for you, you are likewise
not likely to be very commercially successful, either. Devices are not
shipping with consoles, period. If you disagree with this, you've
obviously never shipped a device.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Tim Bird @ 2008-06-04 20:42 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Sam Ravnborg, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604202314.GG4189@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> I might be wrong, but although monitoring the size makes a lot of sense
> I don't believe "fully automate the testing ... and send notifications"
> will work.
"fully automate" was sloppy wording on my part. "automate enough
to not be a burden to maintain" is what I should have said.
> But if CELF has resources then doing this kind of stuff IMHO makes
> more sense than adding a config option for each 5kB of code
> (and also has better long-term effects).
Good point about the better long-term effects.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Jörn Engel @ 2008-06-04 20:24 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Tim Bird, Adrian Bunk, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604191522.GA18873@uranus.ravnborg.org>
On Wed, 4 June 2008 21:15:22 +0200, Sam Ravnborg wrote:
>
> What would be really useful would be to do some king of automated
> monitoring of the size of individual parts of the kernel in
> a few controlled configs.
> And then as son as somethings grows with > 1% for example then to
> bring this to lkml.
> Doing this based on linux-next would allow us to catch the bloaters
> while they are still or just have been doing certain changes.
>
> It would be nice to tell someone that just enabled som new gcc option
> that this had a cost of 163.432 bytes with a certain config.
> This would get attraction and be dealt with.
I've tried that for one evening without immediate results, then got
distracted again. My basic idea was to compile a kernel, measure the
size, apply a patch, recompile and measure the new size. One could even
do something similar to git-bisect that way, each time ignoring the half
that causes less bloat.
The main disadvantage I see is with the overwhelming number of new
config options being added. Going from 2.6.x to 2.6.x+1 will add so
many new options that I usually just 'yes "" | make oldconfig'.
If someone can translate my description into a few lines of bash or
perl, we could turn it into a "make bloatcheck" and require^W hope that
at least some people use it, get ashamed and fix their mess before it
even hits the list.
Jörn
--
If System.PrivateProfileString("",
"HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <>
"" Then CommandBars("Macro").Controls("Security...").Enabled = False
-- from the Melissa-source
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Adrian Bunk @ 2008-06-04 20:23 UTC (permalink / raw)
To: Tim Bird; +Cc: Sam Ravnborg, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <4846EBAE.2000604@am.sony.com>
On Wed, Jun 04, 2008 at 12:23:26PM -0700, Tim Bird wrote:
> Sam Ravnborg wrote:
> >> I can do a more controlled comparison if you're interested.
> >
> > What would be really useful would be to do some king of automated
> > monitoring of the size of individual parts of the kernel in
> > a few controlled configs.
> > And then as son as somethings grows with > 1% for example then to
> > bring this to lkml.
> > Doing this based on linux-next would allow us to catch the bloaters
> > while they are still or just have been doing certain changes.
> >
> > It would be nice to tell someone that just enabled som new gcc option
> > that this had a cost of 163.432 bytes with a certain config.
> > This would get attraction and be dealt with.
>
> This is something I've wanted to get done for the last few
> years. We've crept towards it slowly with things like bloatwatch
> and some of the automated testing CELF did for it's (currently
> temporarily defunct) test lab.
>
> But we've never gotten to the last bit, which is to fully automate
> the testing at the top of tree, and send notifications. I won't
> make any promises, but this is something CELF is very interested in,
> and we have parts of the required software already written.
I might be wrong, but although monitoring the size makes a lot of sense
I don't believe "fully automate the testing ... and send notifications"
will work.
Like the CONFIG_LOG_BUF_SHIFT example from my last email you can easily
get huge differences in a defconfig that do not indicate any problem at
all, and I'd expect you'll need frequent finetuning of the .config's
used. And if there's a problem you'll have to identify what exactly
causes the problem.
But if CELF has resources then doing this kind of stuff IMHO makes
more sense than adding a config option for each 5kB of code
(and also has better long-term effects).
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Bernhard Fischer @ 2008-06-04 19:42 UTC (permalink / raw)
To: Tim Bird; +Cc: Adrian Bunk, linux-tiny, linux kernel, linux-embedded
In-Reply-To: <4846E44A.1010601@am.sony.com>
On Wed, Jun 04, 2008 at 11:51:54AM -0700, Tim Bird wrote:
>There are diminishing returns here, and at some point it doesn't make
>sense to continue. I have a nagging feeling, though, that there
>are a few more things where the bloat is pronounced (glances at
>procfs and sysfs).
A decision on what to favour would certainly help: sysfs or ioctl or
something else.
While i have missed that in this particular case¹) you apparently shall
read via sysfs and write via ioctl -- i thought that most could already
be written via sysfs which doesn't seem to be true -- it would be nice
to get rid of the devilish ioctl mid-term iff there is consensus about
it. The bridge is admittedly a vicarious corner case and probably
seldomly used anyway.
¹)
https://lists.linux-foundation.org/pipermail/bridge/2008-May/005839.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Adrian Bunk @ 2008-06-04 19:40 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <4846E44A.1010601@am.sony.com>
On Wed, Jun 04, 2008 at 11:51:54AM -0700, Tim Bird wrote:
> Adrian Bunk wrote:
> > It seems to be always me who asks the controversial questions...:
> >
> > Does the linux-tiny approach of adding a kconfig variable for each 5kB
> > of code actually make sense? I'm asking since an exploding amount of
> > kconfig variables and their interdependencies have a not so small
> > maintainance impact in the long term.
>
> Others have expressed similar concerns. Andi Kleen has brought this
> up in the past, and highlighted another aspect of this that I think
> is important - fragmenting the configuration space for testing.
>
> That is, if different combinations of options are used, then the
> testing results from different users may not be directly comparable.
> This makes it harder to track down bugs.
>
> In practice, I think these types of switches tend to get turned
> on/off together. This tends to ameliorate the testing and maintenance
> issues. It might be worthwhile to coalesce these into fewer
> options. I'd be fine with overloading this particular
> onto CONFIG_BASE_FULL, but I don't know what other people think.
> Keeping the option separate means you have more flexibility - so
> that you can, for example, turn off all but one feature that's
> important to you. (This seems like a pretty common
I'm coming more from the point that drivers/media/ might be the area
in the kernel that currently offers the biggest flexibility - and this
stuff breaks multiple times for each kernel release, and sorting this
out is often nontrivial.
I'm not claiming it was impossible to maintain, but it is a maintainance
burden if too much is configurable.
> > And I'm wondering whether it's the best approach for reaching
> > measurable results. E.g. my small patch that removed
> > -maccumulate-outgoing-args on 32-bit x86 reduced the kernel size
> > there for the CONFIG_CC_OPTIMIZE_FOR_SIZE=y case by at about 2.5% (sic)
> > without adding any kconfig variables or #ifdef's.
>
> These are certainly nice, but there's a limited number of whole-kernel
> reduction options. Kernel size accumulates by both wasteful
> compiler output, and by the introduction or preservation of individual
> features that are useless for embedded devices. I think it's worthwhile
> to attack both problems.
There are still several (although not that trivial) global reductions
each worth 2% or more in code size possible, and I would say they should
be attacked before starting a config options jungle.
As a bonus, such stuff brings benefit to everyone, not only to people
creating hand-optimized kernels for devices with very limited features.
And it also addresses the point that someone trying to get a very small
kernel might hit completely untested codepaths.
> > Can you take a reasonable (best-case) .config for an existing device and
> > get the following numbers:
> > - Ignoring patches that came from linux-tiny, by how many percent did
> > the size of the kernel increase or decrease between 2.6.16 and 2.6.26?
>
> Well, an initial comparison is at:
> http://www.selenic.com/bloatwatch/?cmd=compare&part=%2F&v1=2.6.16&v2=2.6.25-rc2
>
> This shows a size difference of 1.8 meg, but I'm pretty sure this
> is with a default config (not optimized) and is not controlled very well
> for changes in the config.
It seems to be comparing i386 defconfigs.
E.g. the increase of CONFIG_LOG_BUF_SHIFT in the i386 defconfig in
2.6.19 does alone increase the size of a defconfig kernel by a
quarter Megabyte - but that's both expected and not relevant for
embedded systems.
> I can do a more controlled comparison if you're interested.
I think the only serious numbers would come from taking some hardware
and feature set (file systems, network options, etc.), and then
optimizing by hand the smallest .config possible for both cases.
Do you have anything in this direction?
> > - By how many percent did the kernel size decrease due to patches from
> > the linux-tiny project that added such kconfig options for a few kB
> > of code in the same timeframe?
>
> I'm not sure that's a good comparison, since Linux-tiny hasn't been
> very active in that time period. I would guess only about 3 or 4
> Linux-tiny patches have made it into the kernel since 2.6.16.
> The big wins for Linux-tiny were in the 2.6.10/11 kernels, where
> most of the low-hanging fruit (size-wise) was gleaned.
>
> But to address your point, you're right that no existing Linux-tiny
> patch gets 2.5% reduction for the kernel.
> In my own testing at Sony, the 30 or so Linux-tiny patches that
> I use get me about 110k of reductions. For me, this is about 5% of
> my kernel size. Note that my choice of options to achieve
> reductions is pretty conservative.
OK, that's a visible difference.
Are these 30 patches each gaining 4kB or are there a few patches that
bring most gain?
And are you only measuring the kernel image size or also theruntime
memory usage?
> There are diminishing returns here, and at some point it doesn't make
> sense to continue. I have a nagging feeling, though, that there
> are a few more things where the bloat is pronounced (glances at
> procfs and sysfs).
>
> > My gut feeling is that the influence of this kind of linux-tiny patches
> > is hardly noticably compared to the overall code size development, but
> > if you have numbers that prove me wrong just point me to them and I'll
> > stand corrected.
>
> It *does* feel a bit like fighting the tide with a teaspoon.
Besides reducing the kernel size it might also make sense if you'd
regularly monitored -rc and -next kernels for size increases
(AFAIK noone currently does this) and bring them up early.
If you'd do this with kernels for real devices you might also test the
kernels on the devices, en passant improving the problem that embedded
architectures currently have nearly zero coverage at the times when
functional regressions have a reasonable chance of being fixed before
they reach stable kernels. ;-)
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Tim Bird @ 2008-06-04 19:23 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Adrian Bunk, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604191522.GA18873@uranus.ravnborg.org>
Sam Ravnborg wrote:
>> I can do a more controlled comparison if you're interested.
>
> What would be really useful would be to do some king of automated
> monitoring of the size of individual parts of the kernel in
> a few controlled configs.
> And then as son as somethings grows with > 1% for example then to
> bring this to lkml.
> Doing this based on linux-next would allow us to catch the bloaters
> while they are still or just have been doing certain changes.
>
> It would be nice to tell someone that just enabled som new gcc option
> that this had a cost of 163.432 bytes with a certain config.
> This would get attraction and be dealt with.
This is something I've wanted to get done for the last few
years. We've crept towards it slowly with things like bloatwatch
and some of the automated testing CELF did for it's (currently
temporarily defunct) test lab.
But we've never gotten to the last bit, which is to fully automate
the testing at the top of tree, and send notifications. I won't
make any promises, but this is something CELF is very interested in,
and we have parts of the required software already written.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Bernhard Fischer @ 2008-06-04 19:21 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tim Bird, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604190146.GE4189@cs181133002.pp.htv.fi>
On Wed, Jun 04, 2008 at 10:01:46PM +0300, Adrian Bunk wrote:
>On Wed, Jun 04, 2008 at 08:34:32PM +0200, Bernhard Fischer wrote:
>> Current kernels are too big, they tend to be about 1MB (ignoring lzma or
>> gz compression), a couple of years back an ide- and network-enabled
>> kernel with 8139too (or whatever -nic you use in qemu nowadays) was at
>> least 30% smaller.
>
>No disagreement that the kernel could (and should) become smaller for
>situations where the kernel size matters.
>
>My question is only about whether *this kind of patches* is the correct
>approach.
Every dozend of bytes less helps to some degree. I can boot a smallish
testsystem in qemu with 4MB ram and have a useable userspace in 120k or
up to 1.2MB diskspace to play with.
The kernel ultimately needs the vast majority of resources in such a
system; most of the RAM and most of the diskspace (assuming a
comfortable userspace with 500k). Booting with 2MB didn't work last time
i tried. This imbalance is something we should fix.
So yes, 5k help, several 5k help more. I can see how it's problematic to
represent that in menuconfig without adding too much clutter but still
letting the user decide whether or not to include certain families of
features, but that should not turn out to be a real problem.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Alan Cox @ 2008-06-04 19:20 UTC (permalink / raw)
To: Bernhard Fischer
Cc: Adrian Bunk, Tim Bird, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604192137.GD27768@mx.loc>
> So yes, 5k help, several 5k help more. I can see how it's problematic to
> represent that in menuconfig without adding too much clutter but still
> letting the user decide whether or not to include certain families of
> features, but that should not turn out to be a real problem.
Combinatorial explosions, ugly messes, maintenance.
Far better would be target the actual sizes and get stuff down in size
without removing feaures. There is some obvious 'easy reward' stuff here
- such as being able to build an output only console.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Sam Ravnborg @ 2008-06-04 19:15 UTC (permalink / raw)
To: Tim Bird; +Cc: Adrian Bunk, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <4846E44A.1010601@am.sony.com>
>
> I can do a more controlled comparison if you're interested.
What would be really useful would be to do some king of automated
monitoring of the size of individual parts of the kernel in
a few controlled configs.
And then as son as somethings grows with > 1% for example then to
bring this to lkml.
Doing this based on linux-next would allow us to catch the bloaters
while they are still or just have been doing certain changes.
It would be nice to tell someone that just enabled som new gcc option
that this had a cost of 163.432 bytes with a certain config.
This would get attraction and be dealt with.
Doing so three months later or maybe one year later would often
get less focus (if the individual commit ever got identified).
Now how to do so I dunno - that would require a bit of tweaking
before working reliable. But the value of being quick here would
pay of this soon I think.
Sam
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Bill Gatliff @ 2008-06-04 19:05 UTC (permalink / raw)
To: Rob Landley; +Cc: Paul Mundt, H. Peter Anvin, linux-embedded
In-Reply-To: <200806041355.38322.rob@landley.net>
Rob Landley wrote:
> Now I'm waiting for the communicator badges. It's only a matter of time...)
Working on it... :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Adrian Bunk @ 2008-06-04 19:01 UTC (permalink / raw)
To: Bernhard Fischer; +Cc: Tim Bird, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604183432.GC27768@mx.loc>
On Wed, Jun 04, 2008 at 08:34:32PM +0200, Bernhard Fischer wrote:
> On Wed, Jun 04, 2008 at 01:33:53PM +0300, Adrian Bunk wrote:
>
> >My gut feeling is that the influence of this kind of linux-tiny patches
> >is hardly noticably compared to the overall code size development, but
> >if you have numbers that prove me wrong just point me to them and I'll
> >stand corrected.
> >
> >cu
> >Adrian
> >
> >BTW: I'm not insisting on "between 2.6.16 and 2.6.26", that's just some
> > timeframe big enough for showing general trends.
>
> Current kernels are too big, they tend to be about 1MB (ignoring lzma or
> gz compression), a couple of years back an ide- and network-enabled
> kernel with 8139too (or whatever -nic you use in qemu nowadays) was at
> least 30% smaller.
No disagreement that the kernel could (and should) become smaller for
situations where the kernel size matters.
My question is only about whether *this kind of patches* is the correct
approach.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-04 18:55 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Paul Mundt, H. Peter Anvin, linux-embedded
In-Reply-To: <4846D3EE.1070802@billgatliff.com>
On Wednesday 04 June 2008 12:42:06 Bill Gatliff wrote:
> Rob Landley wrote:
> > On Tuesday 03 June 2008 21:56:48 Paul Mundt wrote:
> >> On Tue, Jun 03, 2008 at 03:37:23PM -0700, H. Peter Anvin wrote:
> >>> Rob Landley wrote:
> >>>>> Actually, lots have frame buffers these days.
> >>>>
> >>>> Cell phones, for instance.
> >>>
> >>> Sure, but do you want to use them as consoles?
> >>
> >> Unless your name is Pavel, no one actually wants a console on their
> >> phone. So no, just framebuffers, as is to be expected :-)
> >
> > Actually if you ever need to diagnose early boot stuff on _any_ platform,
> > you do need a console. But it can be serial or netconsole, as long as
> > that works...
>
> ... who says I _always_ want it to look and feel like a "cell phone"?
With the little bluetooth earpieces, cellphone "look and feel" is decidedly
mutable these days.
(Ok, cell phones started out with the star-tac flip open phone, a fairly
obvious rip-off from Star Trek TOS. We now have the banana in Uhura's ear,
running off of bluetooth. Now I'm waiting for the communicator badges. It's
only a matter of time...)
That said, the cell phone and PDA spaces are converging, and thingies like the
iPhone and Nokia 810 are the next logical step beyond laptops. (If you want
to hook them up to a big screen and keyboard, your "docking station" can just
be USB. If it wasn't for the need to provide power to the suckers, it could
be bluetooth.)
You only need to carry around one pack of electronics with you, and everybody
has a cell phone these days. The rest is a question of user interface and
letting Moore's Law crank long enough...
Rob
P.S. I agree with what Peter seems to be saying, that the old "vga console"
code is a side issue. /dev/console doesn't even provide a controlling tty,
and the PTY code shouldn't really have anything in commonwith the old virtual
console stuff except an API. (Honestly it just attaches a cursor position,
screen size, and some signals to a pipe. The rest of the stuff it does like
setting serial port hardware rates and beeping the speaker probably should
have been done via ioctl on /dev nodes or something.)
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Tim Bird @ 2008-06-04 18:51 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604103353.GC27335@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> It seems to be always me who asks the controversial questions...:
>
> Does the linux-tiny approach of adding a kconfig variable for each 5kB
> of code actually make sense? I'm asking since an exploding amount of
> kconfig variables and their interdependencies have a not so small
> maintainance impact in the long term.
Others have expressed similar concerns. Andi Kleen has brought this
up in the past, and highlighted another aspect of this that I think
is important - fragmenting the configuration space for testing.
That is, if different combinations of options are used, then the
testing results from different users may not be directly comparable.
This makes it harder to track down bugs.
In practice, I think these types of switches tend to get turned
on/off together. This tends to ameliorate the testing and maintenance
issues. It might be worthwhile to coalesce these into fewer
options. I'd be fine with overloading this particular
onto CONFIG_BASE_FULL, but I don't know what other people think.
Keeping the option separate means you have more flexibility - so
that you can, for example, turn off all but one feature that's
important to you. (This seems like a pretty common
> And I'm wondering whether it's the best approach for reaching
> measurable results. E.g. my small patch that removed
> -maccumulate-outgoing-args on 32-bit x86 reduced the kernel size
> there for the CONFIG_CC_OPTIMIZE_FOR_SIZE=y case by at about 2.5% (sic)
> without adding any kconfig variables or #ifdef's.
These are certainly nice, but there's a limited number of whole-kernel
reduction options. Kernel size accumulates by both wasteful
compiler output, and by the introduction or preservation of individual
features that are useless for embedded devices. I think it's worthwhile
to attack both problems.
> Can you take a reasonable (best-case) .config for an existing device and
> get the following numbers:
> - Ignoring patches that came from linux-tiny, by how many percent did
> the size of the kernel increase or decrease between 2.6.16 and 2.6.26?
Well, an initial comparison is at:
http://www.selenic.com/bloatwatch/?cmd=compare&part=%2F&v1=2.6.16&v2=2.6.25-rc2
This shows a size difference of 1.8 meg, but I'm pretty sure this
is with a default config (not optimized) and is not controlled very well
for changes in the config.
I can do a more controlled comparison if you're interested.
> - By how many percent did the kernel size decrease due to patches from
> the linux-tiny project that added such kconfig options for a few kB
> of code in the same timeframe?
I'm not sure that's a good comparison, since Linux-tiny hasn't been
very active in that time period. I would guess only about 3 or 4
Linux-tiny patches have made it into the kernel since 2.6.16.
The big wins for Linux-tiny were in the 2.6.10/11 kernels, where
most of the low-hanging fruit (size-wise) was gleaned.
But to address your point, you're right that no existing Linux-tiny
patch gets 2.5% reduction for the kernel.
In my own testing at Sony, the 30 or so Linux-tiny patches that
I use get me about 110k of reductions. For me, this is about 5% of
my kernel size. Note that my choice of options to achieve
reductions is pretty conservative.
There are diminishing returns here, and at some point it doesn't make
sense to continue. I have a nagging feeling, though, that there
are a few more things where the bloat is pronounced (glances at
procfs and sysfs).
> My gut feeling is that the influence of this kind of linux-tiny patches
> is hardly noticably compared to the overall code size development, but
> if you have numbers that prove me wrong just point me to them and I'll
> stand corrected.
It *does* feel a bit like fighting the tide with a teaspoon.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Bernhard Fischer @ 2008-06-04 18:34 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tim Bird, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604103353.GC27335@cs181133002.pp.htv.fi>
On Wed, Jun 04, 2008 at 01:33:53PM +0300, Adrian Bunk wrote:
>My gut feeling is that the influence of this kind of linux-tiny patches
>is hardly noticably compared to the overall code size development, but
>if you have numbers that prove me wrong just point me to them and I'll
>stand corrected.
>
>cu
>Adrian
>
>BTW: I'm not insisting on "between 2.6.16 and 2.6.26", that's just some
> timeframe big enough for showing general trends.
Current kernels are too big, they tend to be about 1MB (ignoring lzma or
gz compression), a couple of years back an ide- and network-enabled
kernel with 8139too (or whatever -nic you use in qemu nowadays) was at
least 30% smaller.
^ permalink raw reply
* Re: linux-embedded archives [was Re: [PATCH] console - Add configurable support for console charset translation]
From: Rob Landley @ 2008-06-04 18:08 UTC (permalink / raw)
To: T Ziomek; +Cc: Holger Schurig, linux-tiny, Matt Mackall, linux-embedded
In-Reply-To: <20080604172617.GD26333@email.mot.com>
On Wednesday 04 June 2008 12:26:17 T Ziomek wrote:
> On Wed, Jun 04, 2008 at 12:19:53PM -0500, Rob Landley wrote:
> > On Wednesday 04 June 2008 02:04:13 Holger Schurig wrote:
> > > > Linux-embedded is the place to be, folks.
> > >
> > > Another thing that I just noticed: According to
> > >
> > > http://vger.kernel.org/vger-lists.html#linux-embedded
> > >
> > > there is no mailing list archive for this list.
> >
> > Yes, but according to the comments on http://lwn.net/Articles/283749/
> > there is. Unfortunately, there seems to be no way to beat a threaded
> > user interface out of it.
>
> Somebody updated the http://vger.kernel.org/ today; it now lists 3 archives
> (mail-archive.com, gmane.org and marc.info).
So mail-archive.com has no obvious way to browse historical messages by date,
gmane's interface is a mix of frames and javascript, and marc can't show an
index with nested replies to threads.
Well, at least they're broken in different ways...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-04 17:51 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tim Bird, linux-embedded, linux kernel
In-Reply-To: <20080604103353.GC27335@cs181133002.pp.htv.fi>
On Wednesday 04 June 2008 05:33:53 Adrian Bunk wrote:
> Does the linux-tiny approach of adding a kconfig variable for each 5kB
> of code actually make sense? I'm asking since an exploding amount of
> kconfig variables and their interdependencies have a not so small
> maintainance impact in the long term.
Complexity is a cost, you have to get good bang for the buck when you spend
it.
> And I'm wondering whether it's the best approach for reaching
> measurable results.
When I first started stripping down systems to make embedded masquerading
routers back in the late 90's (before linksys came out), I started with a Red
Hat install and removed lots and lots of packages. That's the approach we're
taking today, and I can say from experience that it's not sustainable.
I then wandered to a Linux From Scratch approach, building a system that had
nothing in it but what I wanted. Starting from zero and adding stuff, rather
than starting from Mt. Crapmore and removing things until the shovel broke.
Someday I want to do the same for the Linux kernel. When I started building
systems instead of carving them out of blocks of distro, I started with
a "hello world" root filesystem, and I want to make a "hello world" kernel.
Start with just the boot code that does the jump to C code, only instead of
start_kernel() in init/main.c have it call a hello_world() function that
prints "hello world" to the console using the early_printk logic, then calls
HLT. And does _nothing_else_. Then add stuff back one chunk at a time,
sstarting with memory management, then the scheduler and process stuff, then
the vfs, and so on. So I know what all the bits do, and how big and
complicated they are. And I can document the lot of it as I go.
Unfortunately, as a learning experience, I estimate this would take me about a
year. And I haven't got a spare year on me at the moment. But it remains
prominently on my todo list, if I decide to start another major project.
(Maybe after I get a 1.0 release of FWL out.)
> My gut feeling is that the influence of this kind of linux-tiny patches
> is hardly noticably compared to the overall code size development, but
> if you have numbers that prove me wrong just point me to them and I'll
> stand corrected.
The whackamole approach is never going to turn Ubuntu into Damn Small Linux,
and it ignores the needs of the people who don't want the /proc hairball but
_do_ want a ps that works.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Bill Gatliff @ 2008-06-04 17:42 UTC (permalink / raw)
To: Rob Landley; +Cc: Paul Mundt, H. Peter Anvin, linux-embedded
In-Reply-To: <200806041236.12349.rob@landley.net>
Rob Landley wrote:
> On Tuesday 03 June 2008 21:56:48 Paul Mundt wrote:
>> On Tue, Jun 03, 2008 at 03:37:23PM -0700, H. Peter Anvin wrote:
>>> Rob Landley wrote:
>>>>> Actually, lots have frame buffers these days.
>>>> Cell phones, for instance.
>>> Sure, but do you want to use them as consoles?
>> Unless your name is Pavel, no one actually wants a console on their
>> phone. So no, just framebuffers, as is to be expected :-)
>
> Actually if you ever need to diagnose early boot stuff on _any_ platform, you
> do need a console. But it can be serial or netconsole, as long as that
> works...
... who says I _always_ want it to look and feel like a "cell phone"?
Some days, I'd prefer that my cell phone look like something else. Anything
else. Especially something that will actually work _for_ me instead of the
other way around.
But barring that, something throw-able. Like a chair. :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-04 17:36 UTC (permalink / raw)
To: Paul Mundt; +Cc: H. Peter Anvin, linux-embedded
In-Reply-To: <20080604025648.GA17524@linux-sh.org>
On Tuesday 03 June 2008 21:56:48 Paul Mundt wrote:
> On Tue, Jun 03, 2008 at 03:37:23PM -0700, H. Peter Anvin wrote:
> > Rob Landley wrote:
> > >>Actually, lots have frame buffers these days.
> > >
> > >Cell phones, for instance.
> >
> > Sure, but do you want to use them as consoles?
>
> Unless your name is Pavel, no one actually wants a console on their
> phone. So no, just framebuffers, as is to be expected :-)
Actually if you ever need to diagnose early boot stuff on _any_ platform, you
do need a console. But it can be serial or netconsole, as long as that
works...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-04 17:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matt Mackall, Tim Bird, linux-embedded
In-Reply-To: <4845C7A3.1020607@zytor.com>
On Tuesday 03 June 2008 17:37:23 H. Peter Anvin wrote:
> Rob Landley wrote:
> >> Actually, lots have frame buffers these days.
> >
> > Cell phones, for instance.
>
> Sure, but do you want to use them as consoles?
A friend of mine hacked his iPhone and got shell prompt on it, and it's quite
usable with the touchscreen keyboard. (I very much want a linux box with
that form factor, battery life, connectivity, at least that much memory...)
And hooking a set top box up to an HDTV gives you better potential resolution
than my laptop currently has, on a biiiiiig screen. They already display
text for program listings and recorded program menus and such, plus you can
add a mouse and keyboard via bluetooth or usb if you like...
> -hpa
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* linux-embedded archives [was Re: [PATCH] console - Add configurable support for console charset translation]
From: T Ziomek @ 2008-06-04 17:26 UTC (permalink / raw)
To: Rob Landley; +Cc: Holger Schurig, linux-tiny, Matt Mackall, linux-embedded
In-Reply-To: <200806041219.54775.rob@landley.net>
On Wed, Jun 04, 2008 at 12:19:53PM -0500, Rob Landley wrote:
> On Wednesday 04 June 2008 02:04:13 Holger Schurig wrote:
> > > Linux-embedded is the place to be, folks.
> >
> > Another thing that I just noticed: According to
> >
> > http://vger.kernel.org/vger-lists.html#linux-embedded
> >
> > there is no mailing list archive for this list.
>
> Yes, but according to the comments on http://lwn.net/Articles/283749/ there
> is. Unfortunately, there seems to be no way to beat a threaded user
> interface out of it.
Somebody updated the http://vger.kernel.org/ today; it now lists 3 archives
(mail-archive.com, gmane.org and marc.info).
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: initramfs size limitation
From: Rob Landley @ 2008-06-04 17:24 UTC (permalink / raw)
To: Mike Frysinger; +Cc: pwilshire, linux-embedded
In-Reply-To: <8bd0f97a0806031454g6d8fe57ahca942b2a81b737aa@mail.gmail.com>
On Tuesday 03 June 2008 16:54:38 Mike Frysinger wrote:
> > but they just ripped out the old code
> > generator in favor of a new one
> > (See http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00011.html )
> > so there's not much point in going there right now. (Hopefully they'll
> > have a 1.0 release within our lifetimes.)
>
> i'm aware the tcg stuff exists, but that's about it. only hope for
> new ports atm is to contract a qemu guy. not that the qemu guys would
> mind. thanks for the link.
I have once again allowed myself to get buried in dayjob, but this one only
lasts until the end of the month and _then_ I plan to get
http://landley.net/qemu caught up to the present.
I'm the meantime, I'm still trying to extend my FWL scripts to create a cross
compiler and bootable filesystem for every target qemu supports. Mips
regressed in 2.6.25 because they yanked out the specific qemu target
(http://www.kernel.org/hg/index.cgi/linux-2.6/rev/79936) so I'm migrating the
sucker to use a malta kernel .config, and then I can do a 0.4.0 release with
the distcc trick working out of the box.
(QEMU remains a _marvelous_ toy for doing embedded development, to the point
it's now kind of hard for me to take seriously a platform that doesn't have a
decent emulator I can run on my laptop.)
> -mike
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox