Re: [ANNOUNCE] New kernel tree for embedded linux

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

[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

[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

[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

[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