[ANNOUNCE] New kernel tree for embedded linux

[ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

Hi!

Some days ago, I've started a -je [*] tree which will focus on memory
reduction for the linux kernel.

The RATIONALE is that on a ppc with some flash, memory, network and
nothing much else, I don't feel like parsing MS-DOS partitions,
offering IPX networking etc., but that junk is still included in
2.[45].current - unconditionally. And there is more...

My first GOAL is to add config options that rip the code out for any
platform that doesn't need, yet keeps it in for everyone that does. If
I don't know what the code is needed for, I'll just rip it out and
wait for bug reports - hopefully.

If I feel that any particular patch is clean enough for mainline, I'll
forward it to Linus/Marcello.

WHO should use this tree:
- Anyone concerned about memory footprint of the linux kernel, both of
the image and during runtime. This will mainly be embedded developers,
I guess.
- Anyone. :)
Bugreports of any kind will help me to clean up the patches and get
them included in mainline. I personally run them on my PIII notebook,
right now, and things didn't break. (Yet?)

HOW can you help:
- Any patch that reduces the memory footprint on _any_ platform is
welcome. Even the worst hacks should be cleaned up over time to work
for everyone.
- Test the patches and:
 - Send bugreports. They will help to clean up the patches.
 - Send works-for-me reports with a rough outline of the hardware
 used.  When things start to work for many people on many platforms,
 it may be time for mainline.
- Send any other patches and convince me that they help embedded
people by my definition (whichever that may be at that time).

WHAT patches will I ignore/reject:
- Anything that does not help embedded (my definition, see above).
That stuff should go into -ac, -dj, -mm, -aa or whereever.

Finallly, WHERE can you get it:
http://wh.fh-wedel.de/~joern/software/kernel/je/24/patch-2.4.20-je1
http://wh.fh-wedel.de/~joern/software/kernel/je/25/patch-2.5.66-je1

DISCLAIMER:
No, the server does not support directory browsing, there is no
mailing list and there are currently only three patches in the 2.4
tree and two in the 2.5 tree. 2.5 is untested, looks broken and I
should put some work in it.
These patches may cost you time, money and precious hardware, I don't
guarantee for anything and IANAL. Anything else?

Jörn

[*] Obviously, je stands for "just embedded", which means I only take
patches that help some embedded platform. What have you thought?

-- 
A surrounded army must be given a way out.
-- Sun Tzu

Re: [ANNOUNCE] New kernel tree for embedded linux

[Andi Kleen]

Jörn Engel <joern@wohnheim.fh-wedel.de> writes:

> The RATIONALE is that on a ppc with some flash, memory, network and
> nothing much else, I don't feel like parsing MS-DOS partitions,
> offering IPX networking etc., but that junk is still included in
> 2.[45].current - unconditionally. And there is more...

Both dos partitions and IPX are already CONFIG_* options. As "conditional" 
as you can get. 

If you want to reduce memory bloat I would start with shrinking the
dynamic sized hashtables. That will likely give you several hundred KB
depending on the memory size, much more than you could get from
code size reductions.

Another obvious candidate for memory reduction would be mem_map
(struct page). If you accept some total memory size limit (256MB
with 4k pages) you could replace next_hash and pprev_hash with an
16bit index into mem_map and save 8 bytes per 4k of memory. Possible even 
fold count into flags and save another 4 bytes per 4k of memory
For 256MB of memory this would be 768k. That's more than a stripped
down kernel has code in total.

Probably more could be saved by attacking other bloated data structures
in the kernel.

Really there are many targets that have bigger potential pay off 
than just code shrinking.

If you want to shrink code:

The TCP/IP stack could be also put on a diet. You likely don't need
an backbone router class routing table manager in your embedded
system. The code is already modularized enough that it could be 
replaced with a simple "client" implementation using linked 
lists for routing tables with minor changes.
Unfortunately developing it is still quite some work.

-Andi

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

X-posted to mtd. A lot of embedded people lurk there.

On Mon, 7 April 2003 21:06:16 +0200, Andi Kleen wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> 
> > The RATIONALE is that on a ppc with some flash, memory, network and
> > nothing much else, I don't feel like parsing MS-DOS partitions,
> > offering IPX networking etc., but that junk is still included in
> > 2.[45].current - unconditionally. And there is more...
> 
> Both dos partitions and IPX are already CONFIG_* options. As "conditional" 
> as you can get. 

DOS is always included, unless you are on a very short list (amiga,
atari, mac, sgi_this, sgi_that). Not a complicated fix, I agree.

You are correct about IPX, but 802.3 is always included, afaics never
used and the first comment in the code sais, only used by IPX. Again,
quite simple.

Some more partitioning code that only applies to spinning discs of
some sort (ide, scsi) or code that emulates spinning discs is always
included. No config option.

The list goes on, but these were the lowest hanging fruits I could
see.

> If you want to reduce memory bloat I would start with shrinking the
> dynamic sized hashtables. That will likely give you several hundred KB
> depending on the memory size, much more than you could get from
> code size reductions.

Ok, I will look into this. Do you have a quick pointer or two to start
with?

> Another obvious candidate for memory reduction would be mem_map
> (struct page). If you accept some total memory size limit (256MB
> with 4k pages) you could replace next_hash and pprev_hash with an
> 16bit index into mem_map and save 8 bytes per 4k of memory. Possible even 
> fold count into flags and save another 4 bytes per 4k of memory
> For 256MB of memory this would be 768k. That's more than a stripped
> down kernel has code in total.

1. Things matter less, if you already have 256MB. My focus is on
2-32MB machines, both flash and memory, where O(1) saving do make a
difference.
2. My kernels have little less than 2M uncompressed or 700k
compressed. The platform is not *that* embedded, bit things should
still go down.

3. Thanks for the pointer. I'll look into that.

> Probably more could be saved by attacking other bloated data structures
> in the kernel.
> 
> Really there are many targets that have bigger potential pay off 
> than just code shrinking.

Yes, I agree. See ps:.

> If you want to shrink code:
> 
> The TCP/IP stack could be also put on a diet. You likely don't need
> an backbone router class routing table manager in your embedded
> system. The code is already modularized enough that it could be 
> replaced with a simple "client" implementation using linked 
> lists for routing tables with minor changes.
> Unfortunately developing it is still quite some work.

Good hint. Thank you!

Another one is serial.c. In an ltp test run, plus serial console, some
90% were unused. And the code gave me some shivers. Volunteers?

Jörn

PS: The *real* rationale behind this is my view of embedded
development:
1. Take what's availlable.
2. Make things work.
3. Ship to customer.
4. nothing

Most other developers send patches and collaborate somehow. For
embedded this rarely happens. (It does a little, not all is black.)

So I wanted to create a focal point for the embedded developers and
see if I get something back for my work. I had to start with
something, three simple patches is not much. But if my hopes become
reality, it will grow. And I really suspect that a lot of the patches
done in step 2 could be generalized.

Your hints were already more valuable than my work investments so far.
Thank you!

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

X-posted to mtd. A lot of embedded people lurk there.

On Mon, 7 April 2003 21:06:16 +0200, Andi Kleen wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> 
> > The RATIONALE is that on a ppc with some flash, memory, network and
> > nothing much else, I don't feel like parsing MS-DOS partitions,
> > offering IPX networking etc., but that junk is still included in
> > 2.[45].current - unconditionally. And there is more...
> 
> Both dos partitions and IPX are already CONFIG_* options. As "conditional" 
> as you can get. 

DOS is always included, unless you are on a very short list (amiga,
atari, mac, sgi_this, sgi_that). Not a complicated fix, I agree.

You are correct about IPX, but 802.3 is always included, afaics never
used and the first comment in the code sais, only used by IPX. Again,
quite simple.

Some more partitioning code that only applies to spinning discs of
some sort (ide, scsi) or code that emulates spinning discs is always
included. No config option.

The list goes on, but these were the lowest hanging fruits I could
see.

> If you want to reduce memory bloat I would start with shrinking the
> dynamic sized hashtables. That will likely give you several hundred KB
> depending on the memory size, much more than you could get from
> code size reductions.

Ok, I will look into this. Do you have a quick pointer or two to start
with?

> Another obvious candidate for memory reduction would be mem_map
> (struct page). If you accept some total memory size limit (256MB
> with 4k pages) you could replace next_hash and pprev_hash with an
> 16bit index into mem_map and save 8 bytes per 4k of memory. Possible even 
> fold count into flags and save another 4 bytes per 4k of memory
> For 256MB of memory this would be 768k. That's more than a stripped
> down kernel has code in total.

1. Things matter less, if you already have 256MB. My focus is on
2-32MB machines, both flash and memory, where O(1) saving do make a
difference.
2. My kernels have little less than 2M uncompressed or 700k
compressed. The platform is not *that* embedded, bit things should
still go down.

3. Thanks for the pointer. I'll look into that.

> Probably more could be saved by attacking other bloated data structures
> in the kernel.
> 
> Really there are many targets that have bigger potential pay off 
> than just code shrinking.

Yes, I agree. See ps:.

> If you want to shrink code:
> 
> The TCP/IP stack could be also put on a diet. You likely don't need
> an backbone router class routing table manager in your embedded
> system. The code is already modularized enough that it could be 
> replaced with a simple "client" implementation using linked 
> lists for routing tables with minor changes.
> Unfortunately developing it is still quite some work.

Good hint. Thank you!

Another one is serial.c. In an ltp test run, plus serial console, some
90% were unused. And the code gave me some shivers. Volunteers?

Jörn

PS: The *real* rationale behind this is my view of embedded
development:
1. Take what's availlable.
2. Make things work.
3. Ship to customer.
4. nothing

Most other developers send patches and collaborate somehow. For
embedded this rarely happens. (It does a little, not all is black.)

So I wanted to create a focal point for the embedded developers and
see if I get something back for my work. I had to start with
something, three simple patches is not much. But if my hopes become
reality, it will grow. And I really suspect that a lot of the patches
done in step 2 could be generalized.

Your hints were already more valuable than my work investments so far.
Thank you!

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

Re: [ANNOUNCE] New kernel tree for embedded linux

[Tom Rini]

On Mon, Apr 07, 2003 at 07:10:37PM +0200, J?rn Engel wrote:

> Some days ago, I've started a -je [*] tree which will focus on memory
> reduction for the linux kernel.

First, I'd like to say please, no, everyone can benefit from _every
change_ you want to make in your tree, and it's not just an 'embedded'
issue.

Second, please look up the archives (this past June -> August maybe?)
for the CONFIG_TINY thread.  Under that was my TWEAKS idea.  If this
sounds useful to you, I can try and dig up the last patch I had that got
all of the dependancy stuff correct, except that you had to run a
command if you changed a TWEAK value.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [ANNOUNCE] New kernel tree for embedded linux

[Miles Bader]

Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> So I wanted to create a focal point for the embedded developers and
> see if I get something back for my work. I had to start with
> something, three simple patches is not much. But if my hopes become
> reality, it will grow. And I really suspect that a lot of the patches
> done in step 2 could be generalized.

How about dealing with uClinux?  That's almost entirely embedded
systems.

-miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: [ANNOUNCE] New kernel tree for embedded linux

[Miles Bader]

Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> So I wanted to create a focal point for the embedded developers and
> see if I get something back for my work. I had to start with
> something, three simple patches is not much. But if my hopes become
> reality, it will grow. And I really suspect that a lot of the patches
> done in step 2 could be generalized.

How about dealing with uClinux?  That's almost entirely embedded
systems.

-miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: [ANNOUNCE] New kernel tree for embedded linux

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

Am Die, 2003-04-08 um 06.38 schrieb Miles Bader:

> How about dealing with uClinux?  That's almost entirely embedded
> systems.

... without MMU. If you have one you better use it.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] New kernel tree for embedded linux

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

Am Die, 2003-04-08 um 06.38 schrieb Miles Bader:

> How about dealing with uClinux?  That's almost entirely embedded
> systems.

... without MMU. If you have one you better use it.

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] New kernel tree for embedded linux

[Bernd Petrovitsch]

Daniel Egger <degger@fhm.edu> wrote:
>Am Die, 2003-04-08 um 06.38 schrieb Miles Bader:
>
>> How about dealing with uClinux?  That's almost entirely embedded
>> systems.

IMHO uClinux is a workaround the problem that the standard kernel 
needs a 32bit CPU and a MMU.

>... without MMU. If you have one you better use it.

Absolutely ACK. Especially since "embedded systems" nowadays may come 
with integrated (net-)snmp agents, a web server+CGI scripts or some 
pseudo-shell for configuration, image download via tftp/ftp/http/
[xyz]modem, etc.
Then you want to use a MMU and try to convince product mgmt/whoever
to get a MMU on the device.

	Bernd
-- 
Bernd Petrovitsch                              Email : bernd@gams.at
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at

Re: [ANNOUNCE] New kernel tree for embedded linux

[Bernd Petrovitsch]

Daniel Egger <degger@fhm.edu> wrote:
>Am Die, 2003-04-08 um 06.38 schrieb Miles Bader:
>
>> How about dealing with uClinux?  That's almost entirely embedded
>> systems.

IMHO uClinux is a workaround the problem that the standard kernel 
needs a 32bit CPU and a MMU.

>... without MMU. If you have one you better use it.

Absolutely ACK. Especially since "embedded systems" nowadays may come 
with integrated (net-)snmp agents, a web server+CGI scripts or some 
pseudo-shell for configuration, image download via tftp/ftp/http/
[xyz]modem, etc.
Then you want to use a MMU and try to convince product mgmt/whoever
to get a MMU on the device.

	Bernd
-- 
Bernd Petrovitsch                              Email : bernd@gams.at
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at

Re: [ANNOUNCE] New kernel tree for embedded linux

[David Woodhouse]

On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> Some more partitioning code that only applies to spinning discs of
> some sort (ide, scsi) or code that emulates spinning discs is always
> included. No config option.

We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.

> Another one is serial.c. In an ltp test run, plus serial console, some
> 90% were unused. And the code gave me some shivers. Volunteers?

The new serial code is somewhat nicer. Still contains unconditional
support for a lot of bizarre 8250 variations, but I don't think that's
really taking up much space though.

-- 
dwmw2

Re: [ANNOUNCE] New kernel tree for embedded linux

[David Woodhouse]

On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> Some more partitioning code that only applies to spinning discs of
> some sort (ide, scsi) or code that emulates spinning discs is always
> included. No config option.

We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.

> Another one is serial.c. In an ltp test run, plus serial console, some
> 90% were unused. And the code gave me some shivers. Volunteers?

The new serial code is somewhat nicer. Still contains unconditional
support for a lot of bizarre 8250 variations, but I don't think that's
really taking up much space though.

-- 
dwmw2

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Mon, 2003-04-07 19:10:37 +0200, Jörn Engel <joern@wohnheim.fh-wedel.de>
wrote in message <20030407171037.GB8178@wohnheim.fh-wedel.de>:
> Hi!
> 
> Some days ago, I've started a -je [*] tree which will focus on memory
> reduction for the linux kernel.

If you can live with being blind, substiture printk with a macro (doing
nothing but eventually evaluating the parameters). That'll easily give
you another 100K or even more.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] New kernel tree for embedded linux

[Miles Bader]

Daniel Egger <degger@fhm.edu> writes:
> > How about dealing with uClinux?  That's almost entirely embedded
> > systems.
> 
> ... without MMU. If you have one you better use it.

uClinux runs fine on systems with an MMU (why wouldn't it?).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: [ANNOUNCE] New kernel tree for embedded linux

[Miles Bader]

Daniel Egger <degger@fhm.edu> writes:
> > How about dealing with uClinux?  That's almost entirely embedded
> > systems.
> 
> ... without MMU. If you have one you better use it.

uClinux runs fine on systems with an MMU (why wouldn't it?).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: [ANNOUNCE] New kernel tree for embedded linux

[Thomas Gleixner]

On Tuesday 08 April 2003 10:34, David Woodhouse wrote:
> On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> > Some more partitioning code that only applies to spinning discs of
> > some sort (ide, scsi) or code that emulates spinning discs is always
> > included. No config option.
>
> We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.
>
> > Another one is serial.c. In an ltp test run, plus serial console, some
> > 90% were unused. And the code gave me some shivers. Volunteers?
>
> The new serial code is somewhat nicer. Still contains unconditional
> support for a lot of bizarre 8250 variations, but I don't think that's
> really taking up much space though.
This driver should really supersede the ugly drivers/char/serial.c. And its 
definitly usefull for all embedded systems, not only for x86 based stuff.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: [ANNOUNCE] New kernel tree for embedded linux

[Thomas Gleixner]

On Tuesday 08 April 2003 10:34, David Woodhouse wrote:
> On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> > Some more partitioning code that only applies to spinning discs of
> > some sort (ide, scsi) or code that emulates spinning discs is always
> > included. No config option.
>
> We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.
>
> > Another one is serial.c. In an ltp test run, plus serial console, some
> > 90% were unused. And the code gave me some shivers. Volunteers?
>
> The new serial code is somewhat nicer. Still contains unconditional
> support for a lot of bizarre 8250 variations, but I don't think that's
> really taking up much space though.
This driver should really supersede the ugly drivers/char/serial.c. And its 
definitly usefull for all embedded systems, not only for x86 based stuff.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

On Mon, 7 April 2003 13:48:12 -0700, Tom Rini wrote:
> On Mon, Apr 07, 2003 at 07:10:37PM +0200, J?rn Engel wrote:
> 
> > Some days ago, I've started a -je [*] tree which will focus on memory
> > reduction for the linux kernel.
> 
> First, I'd like to say please, no, everyone can benefit from _every
> change_ you want to make in your tree, and it's not just an 'embedded'
> issue.

Right. The purpose of this tree is not to keep changes out of
mainline, but to test and enhance some of the uglier ones before they
go in.
In a perfect world, my tree would contain exactly zero patches. :)

> Second, please look up the archives (this past June -> August maybe?)
> for the CONFIG_TINY thread.  Under that was my TWEAKS idea.  If this
> sounds useful to you, I can try and dig up the last patch I had that got
> all of the dependancy stuff correct, except that you had to run a
> command if you changed a TWEAK value.

Will do. Just give me a little time.

Jörn

-- 
There's nothing better for promoting creativity in a medium than
making an audience feel "Hmm ­ I could do better than that!"
-- Douglas Adams in a slashdot interview

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

On Tue, 8 April 2003 09:34:52 +0100, David Woodhouse wrote:
> On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> > Some more partitioning code that only applies to spinning discs of
> > some sort (ide, scsi) or code that emulates spinning discs is always
> > included. No config option.
> 
> We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.

The child has a different name, currently, but yes. It will also be
interesting to see, what all should be covered by that option.

> > Another one is serial.c. In an ltp test run, plus serial console, some
> > 90% were unused. And the code gave me some shivers. Volunteers?
> 
> The new serial code is somewhat nicer. Still contains unconditional
> support for a lot of bizarre 8250 variations, but I don't think that's
> really taking up much space though.

You don't refer to your effort to support higher bitrates on some
chips, I guess. Do you have a URL or something?

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham

Re: [ANNOUNCE] New kernel tree for embedded linux

[Jörn Engel]

On Tue, 8 April 2003 09:34:52 +0100, David Woodhouse wrote:
> On Mon, 2003-04-07 at 20:40, Jörn Engel wrote:
> > Some more partitioning code that only applies to spinning discs of
> > some sort (ide, scsi) or code that emulates spinning discs is always
> > included. No config option.
> 
> We definitely want CONFIG_BLK_DEV. CONFIG_SWAP is a good start.

The child has a different name, currently, but yes. It will also be
interesting to see, what all should be covered by that option.

> > Another one is serial.c. In an ltp test run, plus serial console, some
> > 90% were unused. And the code gave me some shivers. Volunteers?
> 
> The new serial code is somewhat nicer. Still contains unconditional
> support for a lot of bizarre 8250 variations, but I don't think that's
> really taking up much space though.

You don't refer to your effort to support higher bitrates on some
chips, I guess. Do you have a URL or something?

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham

Re: [ANNOUNCE] New kernel tree for embedded linux

[David Woodhouse]

On Tue, 2003-04-08 at 13:54, Jörn Engel wrote:
> You don't refer to your effort to support higher bitrates on some
> chips, I guess. Do you have a URL or something?

I mean the contents of drivers/serial/ in current 2.5. The old serial.c
is already obsolete.

-- 
dwmw2

Re: [ANNOUNCE] New kernel tree for embedded linux

[David Woodhouse]

On Tue, 2003-04-08 at 13:54, Jörn Engel wrote:
> You don't refer to your effort to support higher bitrates on some
> chips, I guess. Do you have a URL or something?

I mean the contents of drivers/serial/ in current 2.5. The old serial.c
is already obsolete.

-- 
dwmw2

Re: [ANNOUNCE] New kernel tree for embedded linux

[Ville Herva]

On Tue, Apr 08, 2003 at 11:33:30AM +0200, you [Jan-Benedict Glaw] wrote:
> On Mon, 2003-04-07 19:10:37 +0200, Jörn Engel <joern@wohnheim.fh-wedel.de>
> wrote in message <20030407171037.GB8178@wohnheim.fh-wedel.de>:
> > Hi!
> > 
> > Some days ago, I've started a -je [*] tree which will focus on memory
> > reduction for the linux kernel.
> 
> If you can live with being blind, substiture printk with a macro (doing
> nothing but eventually evaluating the parameters). That'll easily give
> you another 100K or even more.

There was a quite flexible solution proposed sometime ago...

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=20021024030143.GA13661%40eskimo.com&rnum=4&prev=/groups%3Fq%3Dprintk%2BCONFIG_TINY%26num%3D50%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26sa%3DN%26tab%3Dwg



-- v --

v@iki.fi