The end of embedded Linux?

The end of embedded Linux?

[Gigi Duru]

Trivial experiment: configure out _ALL_ the options on
2.5.38 and build bzImage. My result? A totally useless
270KB kernel (compressed). 

Now try to put in some useful stuff and the
_compressed_ image will cheerfully approach 1MB. Where
are the days when a 200KB kernel would be fully
equipped?

I know you guys are struggling to bring "world class
VM & IO" to Linux, going for SMPs and other big toys,
but you are about to lose what you already have: the
embedded market.

As an embedded developer, I can't stand bloat. I think
an OS designer should feel the same, and develop in a
fully modular and configurable manner, going for both
speed and size. For a long time I've felt that Linux
has got it right, but lately I'm not that sure
anymore. 

Gigi Duru

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Francois Romieu]

Gigi Duru <giduru@yahoo.com> :
[...]
> As an embedded developer, I can't stand bloat. I think
> an OS designer should feel the same, and develop in a
> fully modular and configurable manner, going for both
> speed and size. For a long time I've felt that Linux
> has got it right, but lately I'm not that sure
> anymore. 

It has been stated many times that it would be nice to 
have an option dedicated to devices with few memory
(no big hashes etc.). You know what you have to do :o)

-- 
Ueimor

Re: The end of embedded Linux?

[Ben Greear]

Gigi Duru wrote:
> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed). 

Maybe you could explain the options you had to add to make
it useful to you?  That may help folks figure out where the
thing can be slimmed down.

> Now try to put in some useful stuff and the
> _compressed_ image will cheerfully approach 1MB. Where
> are the days when a 200KB kernel would be fully
> equipped?

Gone too are the days where you could easily buy something
as small as a 2MB flash chip :)

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: The end of embedded Linux?

[Andre Hedrick]

Well have a nice day and go pay for windriver licenses, or use the source
to adopt to your needs, or hire somebody who can do it for you.
Whinning will not help, doing will.

Regards,

On Sat, 5 Oct 2002, Gigi Duru wrote:

> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed). 
> 
> Now try to put in some useful stuff and the
> _compressed_ image will cheerfully approach 1MB. Where
> are the days when a 200KB kernel would be fully
> equipped?
> 
> I know you guys are struggling to bring "world class
> VM & IO" to Linux, going for SMPs and other big toys,
> but you are about to lose what you already have: the
> embedded market.
> 
> As an embedded developer, I can't stand bloat. I think
> an OS designer should feel the same, and develop in a
> fully modular and configurable manner, going for both
> speed and size. For a long time I've felt that Linux
> has got it right, but lately I'm not that sure
> anymore. 
> 
> Gigi Duru
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: The end of embedded Linux?

[Gigi Duru]

Now thats some advice from a kernel hacker... You
really don't seem to care too much about embedded, do
you? 

It's not about what I do not do, it's about what YOU
do (I'm not talking to you personally, but to the
hacker community as a whole). The kernel core didn't
jump to 270KB compressed because I didn't do
something.

Let me reformulate for you:
* some years ago, (2.2 era) I was more than happy
about embedding Linux.
* along came 2.4, and things got fuzzy (should we move
on, or stick to the good ol' stuff?)
* now, 2.6 (or whatever) seems like a very bad choice
for us.
* I wonder about the next one (2.8/whatever): will it
require a mainframe to run?

It's the trend, you see: you were on the right track
but now you're loosing it. From the embedded point of
view, YOU ARE GOING THE WRONG DIRECTION.

And don't give me the "use 2.2" advice. Stuff is being
back-ported, I know, but not all of it. 

Why are old versions being actively maintained anyway?
Isn't that a realization that those old versions are
better suited for some tasks than the new one? Why
would anyone choose to use 2.2? Because it serves him
better. 

Now, why is 2.2 serving someone better than 2.4?
That's something I'd like you to answer...

The beauty of Linux was it's scalability (I'm not
talking SMP here): you had the same kernel running on
the appliance, on the PC and on that mainframe. Things
were smooth, things were perfect. I would have loved
to preserve that...

Regards,
Gigi 

--- Andre Hedrick <andre@linux-ide.org> wrote:
> 
> Well have a nice day and go pay for windriver
> licenses, or use the source
> to adopt to your needs, or hire somebody who can do
> it for you.
> Whinning will not help, doing will.
> 
> Regards,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Mark Mielke]

You could always try examining the code for yourself and making a
suggestion regarding inappropriate dependencies, or bloated
dependencies. One of the problems you have here is... Linux 'hackers'
are not trying to sell you an embedded solution. If anything, you
are getting a freebie, and you should be gracious that you don't
have to pay full price for a commercial solution...

Other members of the 'hacker computer' who work for companies that use
Linux in their embedded product tend not to scream and complain. Instead,
they roll up their sleeves and get to it...

One of the methods described above has a better chance of being effective.

Which one do you think that might be? :-)

mark

P.S. Linux 2.5 is a development kernel - the fact that is isn't polished
     to your liking is not a surprise. It isn't polished to *many* peoples
     likings, which is the primary reason that people such as myself have
     not installed it.


On Sat, Oct 05, 2002 at 01:52:38PM -0700, Gigi Duru wrote:
> Now thats some advice from a kernel hacker... You
> really don't seem to care too much about embedded, do
> you? 
> 
> It's not about what I do not do, it's about what YOU
> do (I'm not talking to you personally, but to the
> hacker community as a whole). The kernel core didn't
> jump to 270KB compressed because I didn't do
> something.
> 
> Let me reformulate for you:
> * some years ago, (2.2 era) I was more than happy
> about embedding Linux.
> * along came 2.4, and things got fuzzy (should we move
> on, or stick to the good ol' stuff?)
> * now, 2.6 (or whatever) seems like a very bad choice
> for us.
> * I wonder about the next one (2.8/whatever): will it
> require a mainframe to run?
> 
> It's the trend, you see: you were on the right track
> but now you're loosing it. From the embedded point of
> view, YOU ARE GOING THE WRONG DIRECTION.
> 
> And don't give me the "use 2.2" advice. Stuff is being
> back-ported, I know, but not all of it. 
> 
> Why are old versions being actively maintained anyway?
> Isn't that a realization that those old versions are
> better suited for some tasks than the new one? Why
> would anyone choose to use 2.2? Because it serves him
> better. 
> 
> Now, why is 2.2 serving someone better than 2.4?
> That's something I'd like you to answer...
> 
> The beauty of Linux was it's scalability (I'm not
> talking SMP here): you had the same kernel running on
> the appliance, on the PC and on that mainframe. Things
> were smooth, things were perfect. I would have loved
> to preserve that...
> 
> Regards,
> Gigi 
> 
> --- Andre Hedrick <andre@linux-ide.org> wrote:
> > 
> > Well have a nice day and go pay for windriver
> > licenses, or use the source
> > to adopt to your needs, or hire somebody who can do
> > it for you.
> > Whinning will not help, doing will.
> > 
> > Regards,
> > 
> > Andre Hedrick
> > LAD Storage Consulting Group
> > 
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: The end of embedded Linux?

[Andre Hedrick]

WHOOPS! Amen!

Andre Hedrick
LAD Storage Consulting Group

On Sat, 5 Oct 2002, Mark Mielke wrote:

> You could always try examining the code for yourself and making a
> suggestion regarding inappropriate dependencies, or bloated
> dependencies. One of the problems you have here is... Linux 'hackers'
> are not trying to sell you an embedded solution. If anything, you
> are getting a freebie, and you should be gracious that you don't
> have to pay full price for a commercial solution...
> 
> Other members of the 'hacker computer' who work for companies that use
> Linux in their embedded product tend not to scream and complain. Instead,
> they roll up their sleeves and get to it...
> 
> One of the methods described above has a better chance of being effective.
> 
> Which one do you think that might be? :-)
> 
> mark
> 
> P.S. Linux 2.5 is a development kernel - the fact that is isn't polished
>      to your liking is not a surprise. It isn't polished to *many* peoples
>      likings, which is the primary reason that people such as myself have
>      not installed it.
> 
> 
> On Sat, Oct 05, 2002 at 01:52:38PM -0700, Gigi Duru wrote:
> > Now thats some advice from a kernel hacker... You
> > really don't seem to care too much about embedded, do
> > you? 
> > 
> > It's not about what I do not do, it's about what YOU
> > do (I'm not talking to you personally, but to the
> > hacker community as a whole). The kernel core didn't
> > jump to 270KB compressed because I didn't do
> > something.
> > 
> > Let me reformulate for you:
> > * some years ago, (2.2 era) I was more than happy
> > about embedding Linux.
> > * along came 2.4, and things got fuzzy (should we move
> > on, or stick to the good ol' stuff?)
> > * now, 2.6 (or whatever) seems like a very bad choice
> > for us.
> > * I wonder about the next one (2.8/whatever): will it
> > require a mainframe to run?
> > 
> > It's the trend, you see: you were on the right track
> > but now you're loosing it. From the embedded point of
> > view, YOU ARE GOING THE WRONG DIRECTION.
> > 
> > And don't give me the "use 2.2" advice. Stuff is being
> > back-ported, I know, but not all of it. 
> > 
> > Why are old versions being actively maintained anyway?
> > Isn't that a realization that those old versions are
> > better suited for some tasks than the new one? Why
> > would anyone choose to use 2.2? Because it serves him
> > better. 
> > 
> > Now, why is 2.2 serving someone better than 2.4?
> > That's something I'd like you to answer...
> > 
> > The beauty of Linux was it's scalability (I'm not
> > talking SMP here): you had the same kernel running on
> > the appliance, on the PC and on that mainframe. Things
> > were smooth, things were perfect. I would have loved
> > to preserve that...
> > 
> > Regards,
> > Gigi 
> > 
> > --- Andre Hedrick <andre@linux-ide.org> wrote:
> > > 
> > > Well have a nice day and go pay for windriver
> > > licenses, or use the source
> > > to adopt to your needs, or hire somebody who can do
> > > it for you.
> > > Whinning will not help, doing will.
> > > 
> > > Regards,
> > > 
> > > Andre Hedrick
> > > LAD Storage Consulting Group
> > > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Faith Hill - Exclusive Performances, Videos & More
> > http://faith.yahoo.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
> 
>   One ring to rule them all, one ring to find them, one ring to bring them all
>                        and in the darkness bind them...
> 
>                            http://mark.mielke.cc/
> 

Re: The end of embedded Linux?

[Gigi Duru]

this is a bug report, not a feature request ;)

--- Mark Mielke <mark@mark.mielke.cc> wrote:
> You could always try examining the code for yourself
> and making a
> suggestion regarding inappropriate dependencies, or
> bloated
> dependencies. One of the problems you have here
> is... Linux 'hackers'
> are not trying to sell you an embedded solution. If
> anything, you
> are getting a freebie, and you should be gracious
> that you don't
> have to pay full price for a commercial solution...
> 
> Other members of the 'hacker computer' who work for
> companies that use
> Linux in their embedded product tend not to scream
> and complain. Instead,
> they roll up their sleeves and get to it...
> 
> One of the methods described above has a better
> chance of being effective.
> 
> Which one do you think that might be? :-)
> 
> mark
> 
> P.S. Linux 2.5 is a development kernel - the fact
> that is isn't polished
>      to your liking is not a surprise. It isn't
> polished to *many* peoples
>      likings, which is the primary reason that
> people such as myself have
>      not installed it.
> 
> 
> On Sat, Oct 05, 2002 at 01:52:38PM -0700, Gigi Duru
> wrote:
> > Now thats some advice from a kernel hacker... You
> > really don't seem to care too much about embedded,
> do
> > you? 
> > 
> > It's not about what I do not do, it's about what
> YOU
> > do (I'm not talking to you personally, but to the
> > hacker community as a whole). The kernel core
> didn't
> > jump to 270KB compressed because I didn't do
> > something.
> > 
> > Let me reformulate for you:
> > * some years ago, (2.2 era) I was more than happy
> > about embedding Linux.
> > * along came 2.4, and things got fuzzy (should we
> move
> > on, or stick to the good ol' stuff?)
> > * now, 2.6 (or whatever) seems like a very bad
> choice
> > for us.
> > * I wonder about the next one (2.8/whatever): will
> it
> > require a mainframe to run?
> > 
> > It's the trend, you see: you were on the right
> track
> > but now you're loosing it. From the embedded point
> of
> > view, YOU ARE GOING THE WRONG DIRECTION.
> > 
> > And don't give me the "use 2.2" advice. Stuff is
> being
> > back-ported, I know, but not all of it. 
> > 
> > Why are old versions being actively maintained
> anyway?
> > Isn't that a realization that those old versions
> are
> > better suited for some tasks than the new one? Why
> > would anyone choose to use 2.2? Because it serves
> him
> > better. 
> > 
> > Now, why is 2.2 serving someone better than 2.4?
> > That's something I'd like you to answer...
> > 
> > The beauty of Linux was it's scalability (I'm not
> > talking SMP here): you had the same kernel running
> on
> > the appliance, on the PC and on that mainframe.
> Things
> > were smooth, things were perfect. I would have
> loved
> > to preserve that...
> > 
> > Regards,
> > Gigi 
> > 
> > --- Andre Hedrick <andre@linux-ide.org> wrote:
> > > 
> > > Well have a nice day and go pay for windriver
> > > licenses, or use the source
> > > to adopt to your needs, or hire somebody who can
> do
> > > it for you.
> > > Whinning will not help, doing will.
> > > 
> > > Regards,
> > > 
> > > Andre Hedrick
> > > LAD Storage Consulting Group
> > > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Faith Hill - Exclusive Performances, Videos & More
> > http://faith.yahoo.com
> > -
> > To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com
> __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__ 
> | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_  
> | 
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__ 
> | Ottawa, Ontario, Canada
> 
>   One ring to rule them all, one ring to find them,
> one ring to bring them all
>                        and in the darkness bind
> them...
> 
>                            http://mark.mielke.cc/
> 


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Rik van Riel]

On Sat, 5 Oct 2002, Gigi Duru wrote:

> It's not about what I do not do, it's about what YOU
> do (I'm not talking to you personally, but to the
> hacker community as a whole). The kernel core didn't
> jump to 270KB compressed because I didn't do
> something.

While that is true, you have to keep in mind that the
kernel size won't go back to 270 kB _unless_ you (or
other embedded people) do something.

Do you care enough about the problem to help working
on a solution, or do you only care enough to complain
but not to fix ? ;)

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org

Re: The end of embedded Linux?

[Andre Hedrick]

Well given that I get emails for "embedded" space nagging me about
supporting their stuff yet they will not reveal the alterations to the GPL
code they borrowed, and moan when the discuss of paying for consulting on
opensource they have illegally closed.  Yeah, I have zero compasion for
the embedded folks.

Gee every considered embedding somthing with a little horsepower?

So again, if you want change?  Submit it.
If you want a consultant?  Pay for it.

Next running around calling people "hackers" is not the best way to win
friends.  Do you think you could sell your embedded cruft if you told your
customer base, "Gee, I am just a hacker.  Please buy my product."

Dead thread for me now.

Cheers,


On Sat, 5 Oct 2002, Gigi Duru wrote:

> Now thats some advice from a kernel hacker... You
> really don't seem to care too much about embedded, do
> you? 
> 
> It's not about what I do not do, it's about what YOU
> do (I'm not talking to you personally, but to the
> hacker community as a whole). The kernel core didn't
> jump to 270KB compressed because I didn't do
> something.
> 
> Let me reformulate for you:
> * some years ago, (2.2 era) I was more than happy
> about embedding Linux.
> * along came 2.4, and things got fuzzy (should we move
> on, or stick to the good ol' stuff?)
> * now, 2.6 (or whatever) seems like a very bad choice
> for us.
> * I wonder about the next one (2.8/whatever): will it
> require a mainframe to run?
> 
> It's the trend, you see: you were on the right track
> but now you're loosing it. From the embedded point of
> view, YOU ARE GOING THE WRONG DIRECTION.
> 
> And don't give me the "use 2.2" advice. Stuff is being
> back-ported, I know, but not all of it. 
> 
> Why are old versions being actively maintained anyway?
> Isn't that a realization that those old versions are
> better suited for some tasks than the new one? Why
> would anyone choose to use 2.2? Because it serves him
> better. 
> 
> Now, why is 2.2 serving someone better than 2.4?
> That's something I'd like you to answer...
> 
> The beauty of Linux was it's scalability (I'm not
> talking SMP here): you had the same kernel running on
> the appliance, on the PC and on that mainframe. Things
> were smooth, things were perfect. I would have loved
> to preserve that...
> 
> Regards,
> Gigi 
> 
> --- Andre Hedrick <andre@linux-ide.org> wrote:
> > 
> > Well have a nice day and go pay for windriver
> > licenses, or use the source
> > to adopt to your needs, or hire somebody who can do
> > it for you.
> > Whinning will not help, doing will.
> > 
> > Regards,
> > 
> > Andre Hedrick
> > LAD Storage Consulting Group
> > 
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> 

Andre Hedrick
LAD Storage Consulting Group

Re: The end of embedded Linux?

[Gigi Duru]

We obviously have a very different perception of the
term "hacker". I wonder if anyone here shares yours...

It was not my intention to offend anyone, but to get
your attention on what seems to be a forgotten detail:
kernel size. 

It has nothing to do with who I am or what platform am
I working on or those annoying emails nagging you. It
is about making Linux better. "Better" may have
different meanings for different people. For most
"faster" is the closest. You optimize for speed.
Adding a second criterion (size) would only increase
the value of the code. 

Keep up the good work, and your ego down,
Gigi
 
--- Andre Hedrick <andre@linux-ide.org> wrote:
> 
> Well given that I get emails for "embedded" space
> nagging me about
> supporting their stuff yet they will not reveal the
> alterations to the GPL
> code they borrowed, and moan when the discuss of
> paying for consulting on
> opensource they have illegally closed.  Yeah, I have
> zero compasion for
> the embedded folks.
> 
> Gee every considered embedding somthing with a
> little horsepower?
> 
> So again, if you want change?  Submit it.
> If you want a consultant?  Pay for it.
> 
> Next running around calling people "hackers" is not
> the best way to win
> friends.  Do you think you could sell your embedded
> cruft if you told your
> customer base, "Gee, I am just a hacker.  Please buy
> my product."
> 
> Dead thread for me now.
> 
> Cheers,
> Andre Hedrick
> LAD Storage Consulting Group
> 

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Andre Hedrick]

On Sun, 6 Oct 2002, Gigi Duru wrote:

> We obviously have a very different perception of the
> term "hacker". I wonder if anyone here shares yours...

Well the obvious goal is to promote addressing the true talent in the list
of developers and contributors as something better than a "hacker".  Sure
most joke in context within the community, but outside all deserve the
respect of a quality "developer" on one scale or another.

> It was not my intention to offend anyone, but to get
> your attention on what seems to be a forgotten detail:
> kernel size. 

Remember the ramping up of features in the beginning is always followed by
a slash and burn near the close.

> It has nothing to do with who I am or what platform am
> I working on or those annoying emails nagging you. It
> is about making Linux better. "Better" may have
> different meanings for different people. For most
> "faster" is the closest. You optimize for speed.
> Adding a second criterion (size) would only increase
> the value of the code. 

In the case of current IDE, we bloated to standardize callers and once
they were comman to all HBA's they were condensed to a single export
function (de-bloat).  Then we bloated some more to allow for modular
chipsets, the end result may be more bulk if everything is compiled into
the kernel, but now the option to deflate the basic kernel and load
modules is on the threshold.

> Keep up the good work, and your ego down,
> Gigi

EGO where, that was blown out the sky at the beginning of 2.5 during the
foot in acehole process, Linus performed on me as the door whopped me in
the backside.

The object is to get you to stop complaining and start doing.
If you put as much effort into coding as wasted in replies, I be you could
be done?

The water is warm, just watch out for fins! :-)

Cheers,

Andre Hedrick
LAD Storage Consulting Group


> --- Andre Hedrick <andre@linux-ide.org> wrote:
> > 
> > Well given that I get emails for "embedded" space
> > nagging me about
> > supporting their stuff yet they will not reveal the
> > alterations to the GPL
> > code they borrowed, and moan when the discuss of
> > paying for consulting on
> > opensource they have illegally closed.  Yeah, I have
> > zero compasion for
> > the embedded folks.
> > 
> > Gee every considered embedding somthing with a
> > little horsepower?
> > 
> > So again, if you want change?  Submit it.
> > If you want a consultant?  Pay for it.
> > 
> > Next running around calling people "hackers" is not
> > the best way to win
> > friends.  Do you think you could sell your embedded
> > cruft if you told your
> > customer base, "Gee, I am just a hacker.  Please buy
> > my product."
> > 
> > Dead thread for me now.
> > 
> > Cheers,
> > Andre Hedrick
> > LAD Storage Consulting Group
> > 
> 
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> 

Re: The end of embedded Linux?

[David S. Miller]

   From: Gigi Duru <giduru@yahoo.com>
   Date: Sat, 5 Oct 2002 13:52:38 -0700 (PDT)

   Now thats some advice from a kernel hacker... You
   really don't seem to care too much about embedded, do
   you? 
   
   It's not about what I do not do, it's about what YOU
   do (I'm not talking to you personally, but to the
   hacker community as a whole). The kernel core didn't
   jump to 270KB compressed because I didn't do
   something.

Actually, Andre is quite right.  I can't name too many embedded Linux
folks who haven't customized their kernel in one way or another.  And
in many respects I think that is going to be difficult to avoid
regardless of which free OS you're talking about.

Embedded applications tend to have issues which are entirely specific
to that embedded project.  As such, those are things that do not
belong in a general purpose OS.

The common areas, like smaller hashtables or whatever, sure put a
CONFIG_SMALL_KERNEL option in there and start submitting the
one-liners here and there that do it.

Re: The end of embedded Linux?

[Alan Cox]

On Sun, 2002-10-06 at 05:28, David S. Miller wrote:
> Embedded applications tend to have issues which are entirely specific
> to that embedded project.  As such, those are things that do not
> belong in a general purpose OS.

90% of the embedded Linux problem is not this. Its actually easy to get
most of the embedded needs into the base kernel - in fact they overlap
the other worlds a lot.

Need low power consumption/resource usage - thats S/390 mainframe
instances and ibm wristwatches.

Need good cpu control - thats desktop/laptop and embedded

Need good irq behaviour (pre-empt/low latency) - thats desktop/embedded

and it carries on like that.

No the big problem is that each embedded vendor is desperately trying to
keep their changes out of the mainstream so they can screw each other.
In doing so the main people they screw are all their customers.

So if the embedded people want 2.6 to be good at embedded they need to
get their heads out of their arses and contribute to the mainstream.
Otherwise they'll always be chasing a moving ball, and a ball most
people are kicking the other way down the field. Its a simple fact of
line, if you stick you head up your backside all you get to do is eat
shit

(and yes there are some embedded people who do contribute but they are
sadly a real minority)

Alan

Re: The end of embedded Linux?

[george anzinger]

Alan Cox wrote:
> 
> On Sun, 2002-10-06 at 05:28, David S. Miller wrote:
> > Embedded applications tend to have issues which are entirely specific
> > to that embedded project.  As such, those are things that do not
> > belong in a general purpose OS.
> 
> 90% of the embedded Linux problem is not this. Its actually easy to get
> most of the embedded needs into the base kernel - in fact they overlap
> the other worlds a lot.
> 
> Need low power consumption/resource usage - thats S/390 mainframe
> instances and ibm wristwatches.
> 
> Need good cpu control - thats desktop/laptop and embedded
> 
> Need good irq behaviour (pre-empt/low latency) - thats desktop/embedded
> 
> and it carries on like that.
> 
> No the big problem is that each embedded vendor is desperately trying to
> keep their changes out of the mainstream so they can screw each other.
> In doing so the main people they screw are all their customers.
> 
> So if the embedded people want 2.6 to be good at embedded they need to
> get their heads out of their arses and contribute to the mainstream.
> Otherwise they'll always be chasing a moving ball, and a ball most
> people are kicking the other way down the field. Its a simple fact of
> line, if you stick you head up your backside all you get to do is eat
> shit
> 
> (and yes there are some embedded people who do contribute but they are
> sadly a real minority)

Uh, thanks, I think.

-g
> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: The end of embedded Linux?

[simon]

Following this thread I am even more disturbed about the 
embedded Linux world. I do not have any problem with code size, 
and I would have no problem in paying for some kernel development 
should I require it. I would ask questions via this mailing list but I 
would not expect kernel developers to fix problems specific to my 
environment. 

I agree that  the embedded projects are in need of cpu control, irq 
behaviour etc. I can also accept that this is the case for a large 
percentage of embedded projects. I have no real perception of what 
hardware people use their embedded projects but in my case the 
hardware is dedicated to the specific task in hand. To get Linux 
running on the hardware I had to make changes to kernel/lilo code. 
The hardware has it's own type of interrupt controller, no RTC, it's 
own type of serial port, no vga etc. These changes are specific to 
this hardware and are not likely to exist anywhere else. I do not 
expect kernel developers to maintain this and maybe I am missing 
the point completely, but why would anyone want me to distribute 
this code ? More to the point what about the drivers more specific 
to the task of the hardware ?   No one else can run these drivers so 
how could I expect someone else to maintain them ?

The real point of all this is that the kernel developers seem really 
upset about embedded code which is not released under the GPL.
I can understand the desire to keep all of the code free and open. I 
can also understand how upsetting Linux developers must be in 
seeing their code being used for other peoples gain, who do not 
wish to participate in the open source arena. However I can not 
understand how it would be practical for many organizations  to 
release code under the GPL for specific hardware. The only use I 
could see for this is other people taking a look to see how the 
hardware works. This to some companies is too much to give 
away. Perhaps someone could educate me on this point ?

I thought that this was the main problem for embedded projects. If 
this is no the case I would like to know. So I see the end of 
embedded Linux not in the code size or speed sense but in the 
constant battle between organizations wanting to keep their ideas 
to themselves and the kernel developers wanting these 
organizations to distribute GPL code. 


Many Thanks


Simon.










On 6 Oct 2002, at 17:53, Alan Cox wrote:

> On Sun, 2002-10-06 at 05:28, David S. Miller wrote:
> > Embedded applications tend to have issues which are entirely specific
> > to that embedded project.  As such, those are things that do not
> > belong in a general purpose OS.
> 
> 90% of the embedded Linux problem is not this. Its actually easy to get
> most of the embedded needs into the base kernel - in fact they overlap
> the other worlds a lot.
> 
> Need low power consumption/resource usage - thats S/390 mainframe
> instances and ibm wristwatches.
> 
> Need good cpu control - thats desktop/laptop and embedded
> 
> Need good irq behaviour (pre-empt/low latency) - thats desktop/embedded
> 
> and it carries on like that.
> 
> No the big problem is that each embedded vendor is desperately trying to
> keep their changes out of the mainstream so they can screw each other.
> In doing so the main people they screw are all their customers.
> 
> So if the embedded people want 2.6 to be good at embedded they need to
> get their heads out of their arses and contribute to the mainstream.
> Otherwise they'll always be chasing a moving ball, and a ball most
> people are kicking the other way down the field. Its a simple fact of
> line, if you stick you head up your backside all you get to do is eat
> shit
> 
> (and yes there are some embedded people who do contribute but they are
> sadly a real minority)
> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: The end of embedded Linux?

[David S. Miller]

   From: "" <simon@baydel.com>
   Date: Mon, 7 Oct 2002 11:06:03 +0100

   No one else can run these drivers so 
   how could I expect someone else to maintain them ?

This is a common misconception.  When sweeping API changes
are made to fix some bug or whatever, if your driver is in
the tree the person making the API change will update your
driver or add a comment saying "the new API does this, I
couldn't figure out how to do that with your driver, please
update" in a comment.

You get free work like this just as a side effect of being
in the tree.

It will also be sanity build checked by lots of people who
run the current kernels through a "enable everything" configuration.
   
   However I can not understand how it would be practical for many
   organizations  to  release code under the GPL for specific hardware.

See above.

   This to some companies is too much to give 
   away. Perhaps someone could educate me on this point ?
   
You talked about an interrupt controller, a serial port, lack of VGA,
and lack of RTC on your system... doesn't sound like any ground
breaking hardware to me.

Franks a lot,
David S. Miller
davem@redhat.com

Re: The end of embedded Linux?

[Russell King]

On Mon, Oct 07, 2002 at 03:36:44AM -0700, David S. Miller wrote:
>    No one else can run these drivers so 
>    how could I expect someone else to maintain them ?
> 
> This is a common misconception.

Double that.  There are lots of drivers for embedded ARM stuff that
should probably be in the tree, but because they typically add
architecture specific crap to drivers to modify the IO support
the weird and wonderful way the hardware designer has come up with
to connect the device.  Examples of this are cs89x0.c and smc9192.c.

I've tried to coerce people in Alans suggested direction (hiding
the architecture specific stuff behind inb and friends) but That
Doesn't Work because embedded people will not do this.

They'd rather keep their changes external.  And thus, they stay
external.

The conventional "you will do it this way or else your patch will
not be merged" approach taken by Alan and others just doesn't bite
in the embedded world I'm afraid.  Experience has proven this over
and over again.

And as final proof, the solution taken by two embedded companies is
to develop two completely separate cs89x0 driver from the existing one
(and then pick one/merge them) rather than fixing stuff in the way
suggested by Alan.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: The end of embedded Linux?

[Abraham vd Merwe]

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

Hi Russell!

> And as final proof, the solution taken by two embedded companies is
> to develop two completely separate cs89x0 driver from the existing one
> (and then pick one/merge them) rather than fixing stuff in the way
> suggested by Alan.

Hey, the original cs89x0 driver were just too ugly to actually work on -
It was much more productive to just start from scratch (;

-- 

Regards
 Abraham

To kick or not to kick...
	-- Somewhere on IRC, inspired by Shakespeare

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


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

Re: The end of embedded Linux?

[Alan Cox]

On Mon, 2002-10-07 at 13:10, Abraham vd Merwe wrote:
> Hi Russell!
> 
> > And as final proof, the solution taken by two embedded companies is
> > to develop two completely separate cs89x0 driver from the existing one
> > (and then pick one/merge them) rather than fixing stuff in the way
> > suggested by Alan.
> 
> Hey, the original cs89x0 driver were just too ugly to actually work on -
> It was much more productive to just start from scratch (;

But in that case if you have a better cs89x0 driver that works well and
works on multiple platforms, 2.5 is the right time to throw it at the
tree and bury the current one

Re: The end of embedded Linux?

[Nicolas Pitre]

On Mon, 7 Oct 2002, Russell King wrote:

> On Mon, Oct 07, 2002 at 03:36:44AM -0700, David S. Miller wrote:
> >    No one else can run these drivers so 
> >    how could I expect someone else to maintain them ?
> > 
> > This is a common misconception.
> 
> Double that.  There are lots of drivers for embedded ARM stuff that
> should probably be in the tree, but because they typically add
> architecture specific crap to drivers to modify the IO support
> the weird and wonderful way the hardware designer has come up with
> to connect the device.  Examples of this are cs89x0.c and smc9192.c.
> 
> I've tried to coerce people in Alans suggested direction (hiding
> the architecture specific stuff behind inb and friends) but That
> Doesn't Work because embedded people will not do this.

And embedded people won't do that for many reasons:

1) It's unwise to bloat every use of inb() and friends through out the 
   kernel just because a single driver needs a special fixup.

2) Not inlining inb() and friend reduce the bloat but then you further 
   impact performances on CPUs which are generally many order of magnitude 
   slower than current desktop machines.

3) Getting the best code efficiency out of inb() and friends is therefore 
   premordial on those platforms which are sensitive to code performance to 
   achieve maximum bandwidth and power efficiency.  Remember that most of 
   embedded platforms where the SMC91C96 is used to pick up that example 
   aren't able to accomodate any form of DMA à la PCI most of the time.

So even with the current situation where inb() and friends are tweaked 
directly in each individual drivers I often see over 50% CPU usage in kernel 
space just by copying files over NFS.  Going with Alan's suggestion as you 
mentioned many times on linux-arm-kernel is just not acceptable.

There really should be a way to abstract things so the proper fixup is done
once at compilation time rather than across the board for every inb() access
at run time.

I'm sure those who take care of abstracting the code for SMP capabilities so 
it nicely becomes a no op on UP at compilation time understand this issue 
pretty well.  This should be the same for IO macros with embedded systems.


Nicolas

Re: The end of embedded Linux?

[David S. Miller]

   From: Nicolas Pitre <nico@cam.org>
   Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)

   2) Not inlining inb() and friend reduce the bloat but then you further 
      impact performances on CPUs which are generally many order of magnitude 
      slower than current desktop machines.
   
I don't buy this one.  You are saying that the overhead of a procedure
call is larger than the overhead of going out over the I/O bus to
touch a device?

Re: The end of embedded Linux?

[Benjamin LaHaise]

On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> I don't buy this one.  You are saying that the overhead of a procedure
> call is larger than the overhead of going out over the I/O bus to
> touch a device?

On slow CPUs like embedded 386es, yup.  Remember, they don't always have a 
cache.

		-ben
-- 
GMS rules.

Re: The end of embedded Linux?

[Nicolas Pitre]

On Mon, 7 Oct 2002, David S. Miller wrote:

>    From: Nicolas Pitre <nico@cam.org>
>    Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
> 
>    2) Not inlining inb() and friend reduce the bloat but then you further 
>       impact performances on CPUs which are generally many order of magnitude 
>       slower than current desktop machines.
>    
> I don't buy this one.  You are saying that the overhead of a procedure
> call is larger than the overhead of going out over the I/O bus to
> touch a device?

Of course it is!  Not only the procedure call prevents code optimisations
like immediate constants for opcode arguments and pushes more registers to
the stack, but you're then wasting many CPU cycles that would have been much
useful to fetch data from the peripheral's fifo.

Remember we are talking about "embedded" platforms which the majority are
using small CPUs where the IO bus is often on a clock which is tightly 
coupled to the CPU core clock.  Extra CPU cycles wasted on function call 
prologs is often enough to affect throughput significantly.


Nicolas

Re: The end of embedded Linux?

[Mark Mielke]

On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
>    From: Nicolas Pitre <nico@cam.org>
>    Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
>    2) Not inlining inb() and friend reduce the bloat but then you further 
>       impact performances on CPUs which are generally many order of
>       magnitude slower than current desktop machines.
> I don't buy this one.  You are saying that the overhead of a procedure
> call is larger than the overhead of going out over the I/O bus to
> touch a device?

I think the key phrase is 'further impact'.

If anything, the procedure call increases latency.

Although... I don't see why CONFIG_TINY wouldn't be able to decide whether
inb() should be inlined or not...

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: The end of embedded Linux?

[Nicolas Pitre]

On Mon, 7 Oct 2002, Mark Mielke wrote:

> On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> >    From: Nicolas Pitre <nico@cam.org>
> >    Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
> >    2) Not inlining inb() and friend reduce the bloat but then you further 
> >       impact performances on CPUs which are generally many order of
> >       magnitude slower than current desktop machines.
> > I don't buy this one.  You are saying that the overhead of a procedure
> > call is larger than the overhead of going out over the I/O bus to
> > touch a device?
> 
> I think the key phrase is 'further impact'.
> 
> If anything, the procedure call increases latency.
> 
> Although... I don't see why CONFIG_TINY wouldn't be able to decide whether
> inb() should be inlined or not...

Please don't mix up the issues.

The problems with inb() and friends as it stands in the embedded world right
now as to do with code cleanness not kernel image bloat.  Nothing to be 
solved with CONFIG_TINY.  Please let's keep those issues separate.

Here's the IO macro issue:  On some embedded platforms the IO bus is only 8
bit wide or only 16 bit wide, or address lines are shifted so registers
offsets are not the same, etc.  All this because embedded platforms are
often using standard ISA peripheral chipsets since they can be easily glued
to any kind of bare buses or static memory banks.

The nice thing here is the fact that only by modifying inb() and friends you
can reuse most current kernel drivers without further modifications.  
However the modifs to inb() are often different whether the peripheral in
question is wired to a static memory bank, to the PCMCIA space or onto some
expansion board via a CPLD or other weirdness some hardware designers are
pleased to come with.  Hence no global inb() and friend tweaking is possible
without some performance hit by using a runtime fixup based on the address
passed to them.

We therefore end up with something that looks like this in each drivers for 
which a fixup is needed:

#ifdef CONFIG_ASSABET_NEPONSET

/*
 * These functions allow us to handle IO addressing as we wish - this
 * ethernet controller can be connected to a variety of busses.  Some
 * busses do not support 16 bit or 32 bit transfers.  --rmk
 */
static inline u8 smc_inb(u_int base, u_int reg)
{
        u_int port = base + reg * 4;

        return readb(port);
}

static inline u16 smc_inw(u_int base, u_int reg)
{
        u_int port = base + reg * 4;

        return readb(port) | readb(port + 4) << 8;
}

static inline void smc_outb(u8 val, u_int base, u_int reg)
{
        u_int port = base + reg * 4;

        writeb(val, port);
}

static inline void smc_outw(u16 val, u_int base, u_int reg)
{
        u_int port = base + reg * 4;

        writeb(val, port);
        writeb(val >> 8, port + 4);
}

#endif

As you can see such code duplicated multiple times for all bus arrangements
in existence out there is just not pretty and was refused by Alan.  We lack
a global lightweight IO abstraction to nicely override the default IO macros
for individual drivers at compile time to fix that problem optimally and
keep the driver proper clean.


Nicolas

Re: The end of embedded Linux?

[Richard B. Johnson]

On Mon, 7 Oct 2002, Nicolas Pitre wrote:

> On Mon, 7 Oct 2002, Mark Mielke wrote:
> 
> > On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> > >    From: Nicolas Pitre <nico@cam.org>
> > >    Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
> > >    2) Not inlining inb() and friend reduce the bloat but then you further 
> > >       impact performances on CPUs which are generally many order of
> > >       magnitude slower than current desktop machines.
> > > I don't buy this one.  You are saying that the overhead of a procedure
> > > call is larger than the overhead of going out over the I/O bus to
> > > touch a device?
> > 
> > I think the key phrase is 'further impact'.
> > 
> > If anything, the procedure call increases latency.
> > 
> > Although... I don't see why CONFIG_TINY wouldn't be able to decide whether
> > inb() should be inlined or not...
> 
> Please don't mix up the issues.
> 
> The problems with inb() and friends as it stands in the embedded world right
> now as to do with code cleanness not kernel image bloat.  Nothing to be 
> solved with CONFIG_TINY.  Please let's keep those issues separate.
> 
> Here's the IO macro issue:  On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc.  All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
> 
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.  
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with.  Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.
> 
> We therefore end up with something that looks like this in each drivers for 
> which a fixup is needed:
> 
> #ifdef CONFIG_ASSABET_NEPONSET
> 
> /*
>  * These functions allow us to handle IO addressing as we wish - this
>  * ethernet controller can be connected to a variety of busses.  Some
>  * busses do not support 16 bit or 32 bit transfers.  --rmk
>  */
> static inline u8 smc_inb(u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         return readb(port);
> }
> 
> static inline u16 smc_inw(u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         return readb(port) | readb(port + 4) << 8;
> }
> 
> static inline void smc_outb(u8 val, u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         writeb(val, port);
> }
> 
> static inline void smc_outw(u16 val, u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         writeb(val, port);
>         writeb(val >> 8, port + 4);
> }
> 
> #endif
> 
> As you can see such code duplicated multiple times for all bus arrangements
> in existence out there is just not pretty and was refused by Alan.  We lack
> a global lightweight IO abstraction to nicely override the default IO macros
> for individual drivers at compile time to fix that problem optimally and
> keep the driver proper clean.
> 
> 
> Nicolas

If linux, with no modifications, can be booted on your hardware, then
you don't need any kernel modifications. You can do all your special
I/O through your own modules using whatever techniques you want since
your modules are for your system, therefore by definition, not portable.

This is the method we used here. Also, since any modules are designed
to interface with our proprietary hardware, any customer can get
the source-code because its pretty worthless without the proprietary
hardware. So, we don't have a problem with GPL or anything like that.
If you buy the box, you get anything you want without an NDA.

The only thing we keep under our belt is the BIOS that we wrote. Since
this effectively builds a pretty dumb hunk of coal into an AT Class
machine, we don't give that away as a freebee. We don't waste any
I/O space, the NVRAM used as the data-source of a virtual floppy drive
is accessed through a very small 0x1000 window. We use this window to
burn new PROMS and even to upgrade the BIOS. That virtual floppy
drive 'boots' Linux using LILO and friends.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: The end of embedded Linux?

[george anzinger]

Nicolas Pitre wrote:
> 
> On Mon, 7 Oct 2002, Mark Mielke wrote:
> 
> > On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> > >    From: Nicolas Pitre <nico@cam.org>
> > >    Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
> > >    2) Not inlining inb() and friend reduce the bloat but then you further
> > >       impact performances on CPUs which are generally many order of
> > >       magnitude slower than current desktop machines.
> > > I don't buy this one.  You are saying that the overhead of a procedure
> > > call is larger than the overhead of going out over the I/O bus to
> > > touch a device?
> >
> > I think the key phrase is 'further impact'.
> >
> > If anything, the procedure call increases latency.
> >
> > Although... I don't see why CONFIG_TINY wouldn't be able to decide whether
> > inb() should be inlined or not...
> 
> Please don't mix up the issues.
> 
> The problems with inb() and friends as it stands in the embedded world right
> now as to do with code cleanness not kernel image bloat.  Nothing to be
> solved with CONFIG_TINY.  Please let's keep those issues separate.
> 
> Here's the IO macro issue:  On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc.  All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
> 
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with.  Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.
> 
> We therefore end up with something that looks like this in each drivers for
> which a fixup is needed:
> 
> #ifdef CONFIG_ASSABET_NEPONSET
> 
> /*
>  * These functions allow us to handle IO addressing as we wish - this
>  * ethernet controller can be connected to a variety of busses.  Some
>  * busses do not support 16 bit or 32 bit transfers.  --rmk
>  */
> static inline u8 smc_inb(u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         return readb(port);
> }
> 
> static inline u16 smc_inw(u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         return readb(port) | readb(port + 4) << 8;
> }
> 
> static inline void smc_outb(u8 val, u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         writeb(val, port);
> }
> 
> static inline void smc_outw(u16 val, u_int base, u_int reg)
> {
>         u_int port = base + reg * 4;
> 
>         writeb(val, port);
>         writeb(val >> 8, port + 4);
> }
> 
> #endif
> 
> As you can see such code duplicated multiple times for all bus arrangements
> in existence out there is just not pretty and was refused by Alan.  We lack
> a global lightweight IO abstraction to nicely override the default IO macros
> for individual drivers at compile time to fix that problem optimally and
> keep the driver proper clean.

Uh, what about stuff like this (from tulip.h):
 
#ifndef USE_IO_OPS
#undef inb
#undef inw
#undef inl
#undef outb
#undef outw
#undef outl
#define inb(addr) readb((void*)(addr))
#define inw(addr) readw((void*)(addr))
#define inl(addr) readl((void*)(addr))
#define outb(val,addr) writeb((val), (void*)(addr))
#define outw(val,addr) writew((val), (void*)(addr))
#define outl(val,addr) writel((val), (void*)(addr))
#endif /* !USE_IO_OPS */


-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: The end of embedded Linux?

[Russell King]

On Mon, Oct 07, 2002 at 11:54:54AM -0700, george anzinger wrote:
> Nicolas Pitre wrote:
> > #ifdef CONFIG_ASSABET_NEPONSET
> > 
> > /*
> >  * These functions allow us to handle IO addressing as we wish - this
> >  * ethernet controller can be connected to a variety of busses.  Some
> >  * busses do not support 16 bit or 32 bit transfers.  --rmk
> >  */
> > static inline u8 smc_inb(u_int base, u_int reg)
> > {
> >         u_int port = base + reg * 4;
> > 
> >         return readb(port);
> > }
> > 
> > static inline u16 smc_inw(u_int base, u_int reg)
> > {
> >         u_int port = base + reg * 4;
> > 
> >         return readb(port) | readb(port + 4) << 8;
> > }
> > 
> > static inline void smc_outb(u8 val, u_int base, u_int reg)
> > {
> >         u_int port = base + reg * 4;
> > 
> >         writeb(val, port);
> > }
> > 
> > static inline void smc_outw(u16 val, u_int base, u_int reg)
> > {
> >         u_int port = base + reg * 4;
> > 
> >         writeb(val, port);
> >         writeb(val >> 8, port + 4);
> > }
> > 
> > #endif
> > 
> > As you can see such code duplicated multiple times for all bus arrangements
> > in existence out there is just not pretty and was refused by Alan.  We lack
> > a global lightweight IO abstraction to nicely override the default IO macros
> > for individual drivers at compile time to fix that problem optimally and
> > keep the driver proper clean.
> 
> Uh, what about stuff like this (from tulip.h):
>  
> #ifndef USE_IO_OPS
> #undef inb
> #undef inw
> #undef inl
> #undef outb
> #undef outw
> #undef outl
> #define inb(addr) readb((void*)(addr))
> #define inw(addr) readw((void*)(addr))
> #define inl(addr) readl((void*)(addr))
> #define outb(val,addr) writeb((val), (void*)(addr))
> #define outw(val,addr) writew((val), (void*)(addr))
> #define outl(val,addr) writel((val), (void*)(addr))
> #endif /* !USE_IO_OPS */

No, you don't quite get it.  The above code Nico pasted supports _one_
ARM machine type only (the one I have here, hence why its in my tree)
where the SMC chip is configured to be in 8-bit mode.

We also have the same device connected in 16-bit mode on other machines,
with different ways to set it up:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=734/1

Now imagine the case when you have 100 different machine types, all
different, using this device where each hardware designer has decided to
connect the chip up differently.

Is putting this crud into drivers going to be maintainable?  No.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: The end of embedded Linux?

[Ben Greear]

Russell King wrote:

> Now imagine the case when you have 100 different machine types, all
> different, using this device where each hardware designer has decided to
> connect the chip up differently.
> 
> Is putting this crud into drivers going to be maintainable?  No.

I'm not sure which is worse:  A driver that is hard to maintain, or
one that is completely broken on some architectures, even though
numerous people keep re-inventing the fix.

Personally, I'd rather have a hacked up driver that works, but I'm
sure others have other opinions!

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: The end of embedded Linux?

[Richard Zidlicky]

On Mon, Oct 07, 2002 at 01:45:35PM -0400, Nicolas Pitre wrote:
 
> Here's the IO macro issue:  On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc.  All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
> 
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.  
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with.  Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.

we have all this problems on m68k as well (except that our speed
constraints aren't so terribly strict), don't give up too quickly.

A possible solution is to generate multiple object file from the
same source using a different set of defines for each one. The kbuild
system can already handle it using the CFLAGS_$@ rule and asm/io.h
can then select the appropriate macros for inb etc.

Where it starts to be more interesting is when there are module 
interdependecies (like ne.c and e8390.c) or all the object files 
are to be be linked into kernel. Perhaps EXPORT_SYMBOL() and 
INIT_MODULE() could be tweaked to mangle the names according to 
some special define.

Richard

Re: The end of embedded Linux?

[Richard Zidlicky]

On Mon, Oct 07, 2002 at 01:45:35PM -0400, Nicolas Pitre wrote:
 
> Here's the IO macro issue:  On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc.  All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
> 
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.  
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with.  Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.

we have all this problems on m68k as well (except that our speed
constraints aren't so terribly strict), don't give up too quickly.

A possible solution is to generate multiple object file from the
same source using a different set of defines for each one. The kbuild
system can already handle it using the CFLAGS_$@ rule and asm/io.h
can then select the appropriate macros for inb etc.

Where it starts to be more interesting is when there are module 
interdependecies (like ne.c and e8390.c) or all the object files 
are to be be linked into kernel. Perhaps EXPORT_SYMBOL() and 
INIT_MODULE() could be tweaked to mangle the names according to 
some special define.

Richard

Re: The end of embedded Linux?

[simon]

David, 


Thanks for the reply. I sense as in many emails regarding this a 
sense of frustration and this is a concern. I am writing to the list to 
try and learn and because I value the experiences of other people. 


As far as my hardware is concerned there is much more to it than 
a serial port and an interupt controller. What I was trying to explain 
was that I would not mind making my code available for these 
kernel changes. Although I don't understand why anyone would 
want it. Apart from API changes, why do this ? The kernel is not 
easily or frequently changed on this type of system. It would bloat 
the kernel and I would expect to have to address problems of this 
nature myself.  However I would not like to make code available for 
the more specialised hardware. 

   

Thanks


Simon.


<color><param>0100,0100,0100</param>On 7 Oct 2002, at 3:36, David S. Miller wrote:


<color><param>7F00,0000,0000</param>>    From: "" <<simon@baydel.com>

>    Date: Mon, 7 Oct 2002 11:06:03 +0100

> 

>    No one else can run these drivers so 

>    how could I expect someone else to maintain them ?

> 

> This is a common misconception.  When sweeping API changes

> are made to fix some bug or whatever, if your driver is in

> the tree the person making the API change will update your

> driver or add a comment saying "the new API does this, I

> couldn't figure out how to do that with your driver, please

> update" in a comment.

> 

> You get free work like this just as a side effect of being

> in the tree.

> 

> It will also be sanity build checked by lots of people who

> run the current kernels through a "enable everything" configuration.

>    

>    However I can not understand how it would be practical for many

>    organizations  to  release code under the GPL for specific hardware.

> 

> See above.

> 

>    This to some companies is too much to give 

>    away. Perhaps someone could educate me on this point ?

>    

> You talked about an interrupt controller, a serial port, lack of VGA,

> and lack of RTC on your system... doesn't sound like any ground

> breaking hardware to me.

> 

> Franks a lot,

> David S. Miller

> davem@redhat.com



<nofill>
__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: The end of embedded Linux?

[David S. Miller]

   From: "" <simon@baydel.com>
   Date: Mon, 7 Oct 2002 18:15:18 +0100
   
   Although I don't understand why anyone would want it. Apart
   from API changes, why do this ?

Let's say your driver is the only one that takes advantage
of argument X in some major API, and we decided to delete
that argument.

If your driver is in the tree we wouldn't delete the argument
and therefore your driver wouldn't break.

You may not have any desire to upgrade kernels today.
But 6 months, or a year or two down the road you may
and the accumulated ABI changes that you have to cope with
in each and every one of your drivers will be large.
Why not get this maintainence done for you for free instead
of losing a week or two of trying to do it yourself?

Perhaps for job security? :-)  At least that would be an honest
reason.

Re: The end of embedded Linux?

[Alan Cox]

On Mon, 2002-10-07 at 18:15, simon@baydel.com wrote:
> a serial port and an interupt controller. What I was trying to explain 
> was that I would not mind making my code available for these 
> kernel changes. Although I don't understand why anyone would 
> want it. Apart from API changes, why do this ? The kernel is not 
> easily or frequently changed on this type of system. It would bloat 
> the kernel and I would expect to have to address problems of this 
> nature myself.  However I would not like to make code available for 
> the more specialised hardware. 

That depends how specialized the hardware actually is. I think I've see
six different non free implementations of 68360 sync serial code around
all proprietary for example.

Also my original comments were much more aimed at the core stuff. People
who made existing and especially core stuff smaller could send the stuff
out. Several of us want to compile a CONFIG_TINY option, and suprisingly
enough small is good on high end boxes. My L1 cache is 8 times faster
than my L2 cache is 7 times faster than my memory. Or to put it another
way, going to main memory costs me maybe 100 instructions.

My Athlon thinks small is good too!

Re: The end of embedded Linux?

[Christer Weinigel]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Also my original comments were much more aimed at the core stuff. People
> who made existing and especially core stuff smaller could send the stuff
> out. Several of us want to compile a CONFIG_TINY option, and suprisingly
> enough small is good on high end boxes. My L1 cache is 8 times faster
> than my L2 cache is 7 times faster than my memory. Or to put it another
> way, going to main memory costs me maybe 100 instructions.
> 
> My Athlon thinks small is good too!

Regarding this, has anyone been thinking of splitting printk into a
bunch of macros such as:

#ifndef CONFIG_TINY
#define printk_debug(xxx...) printk(KERN_DEBUG, xxx...)
#define printk_info(xxx...) printk(KERN_INFO, xx...)
#else
#define printk_debug(xxx...) do { } while (0)
#define printk_info(xxx...) do { } while (0)
#endif

and so on?  This way debug messages could very simply be compiled to
oblivion when CONFIG_TINY is enabled.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

Re: The end of embedded Linux?

[Alan Cox]

On Mon, 2002-10-07 at 23:22, Christer Weinigel wrote:
> #define printk_debug(xxx...) printk(KERN_DEBUG, xxx...)
> #define printk_info(xxx...) printk(KERN_INFO, xx...)
> #else
> #define printk_debug(xxx...) do { } while (0)
> #define printk_info(xxx...) do { } while (0)

That might make a lot of sense. The macros in question would need a bit
of hand checking for side effects in calls but yes this is the kind of
thing that can be good

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Mon, Oct 07, 2002 at 11:52:18PM +0100, Alan Cox escreveu:
> On Mon, 2002-10-07 at 23:22, Christer Weinigel wrote:
> > #define printk_debug(xxx...) printk(KERN_DEBUG, xxx...)
> > #define printk_info(xxx...) printk(KERN_INFO, xx...)
> > #else
> > #define printk_debug(xxx...) do { } while (0)
> > #define printk_info(xxx...) do { } while (0)
> 
> That might make a lot of sense. The macros in question would need a bit
> of hand checking for side effects in calls but yes this is the kind of
> thing that can be good

Humm, dprintk is perhaps the most widely used of this kind of stuff,
i.e. debug only printks that should be disabled when in production,
standardising on what is common practice and adding a iprintk could be
something we should consider.

- Arnaldo

Re: The end of embedded Linux?

[Jamie Lokier]

Alan Cox wrote:
> On Mon, 2002-10-07 at 23:22, Christer Weinigel wrote:
> > #define printk_debug(xxx...) printk(KERN_DEBUG, xxx...)
> > #define printk_info(xxx...) printk(KERN_INFO, xx...)
> > #else
> > #define printk_debug(xxx...) do { } while (0)
> > #define printk_info(xxx...) do { } while (0)
> 
> That might make a lot of sense. The macros in question would need a bit
> of hand checking for side effects in calls but yes this is the kind of
> thing that can be good

You can write the macros so the side effects are still executed if you
prefer.  Untested:

#define printk_debug(xxx...) do { (void) (xxx ## , 0); } while (0)

-- Jamie

Re: The end of embedded Linux?

[simon]

On 7 Oct 2002, at 21:22, Alan Cox wrote:

> On Mon, 2002-10-07 at 18:15, simon@baydel.com wrote:
> > a serial port and an interupt controller. What I was trying to explain 
> > was that I would not mind making my code available for these 
> > kernel changes. Although I don't understand why anyone would 
> > want it. Apart from API changes, why do this ? The kernel is not 
> > easily or frequently changed on this type of system. It would bloat 
> > the kernel and I would expect to have to address problems of this 
> > nature myself.  However I would not like to make code available for 
> > the more specialised hardware. 
> 
> That depends how specialized the hardware actually is. I think I've see
> six different non free implementations of 68360 sync serial code around
> all proprietary for example.
> 

The UART and Interrupt controllers in question are built into a gate 
array. I can't see how any external or parts from other vendors 
would be compatible. To get the board to boot Linux I have to 
modify the kernel and lilo. I understand that under the GPL rules I 
would have to make this code available. I am willing to do this but I 
don't see the point. 

There is also more specialized hardware for which I have written 
modules. Although there appears to be some unwritten rule about 
releasing objects, I believe that the GPL rules state that these 
modules must conform to the GPL also, as they contain header 
files. I cannot see how any module can not contain Linux headers 
or headers derived from Linux headers if it is to be loaded on a 
Linux kernel. 

These modules again drive gate array hardware for which nobody 
else will ever have a compatible. Although I would dearly love to 
use Linux as the platform for my project I feel I cannot release this 
code under the GPL.

This is my dilemma and I am sure it is shared by others. For this 
reason I cannot see how anything but an embedded PC with 
applications or a perhaps a very simple hardware device could be 
considered as an opportunity for  embedded Linux. 

I have based these thoughts on my experiences so far. If you feel I 
have drawn an incorrect conclusion I would be grateful for your 
input.


Many Thanks

Simon.



> Also my original comments were much more aimed at the core stuff. People
> who made existing and especially core stuff smaller could send the stuff
> out. Several of us want to compile a CONFIG_TINY option, and suprisingly
> enough small is good on high end boxes. My L1 cache is 8 times faster
> than my L2 cache is 7 times faster than my memory. Or to put it another
> way, going to main memory costs me maybe 100 instructions.
> 
> My Athlon thinks small is good too!
> 


__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: The end of embedded Linux?

[jbradford]

> These modules again drive gate array hardware for which nobody 
> else will ever have a compatible. Although I would dearly love to 
> use Linux as the platform for my project I feel I cannot release this 
> code under the GPL.

That just doesn't make sense.  If nobody else will ever have a
compatible piece of hardware, I don't see why you wouldn't want to
release the driver code under the GPL.

_Unless_ you fear that somebody will derive your hardware design from
the code.  Is that what you're worried about?

John.

Re: The end of embedded Linux?

[Richard B. Johnson]

On Tue, 8 Oct 2002 jbradford@dial.pipex.com wrote:

> > These modules again drive gate array hardware for which nobody 
> > else will ever have a compatible. Although I would dearly love to 
> > use Linux as the platform for my project I feel I cannot release this 
> > code under the GPL.
> 
> That just doesn't make sense.  If nobody else will ever have a
> compatible piece of hardware, I don't see why you wouldn't want to
> release the driver code under the GPL.
> 
> _Unless_ you fear that somebody will derive your hardware design from
> the code.  Is that what you're worried about?
> 
> John.

Maybe he's afraid that customers will see that the hardware design is
absolute garbage with thousands of defective-hardware-work-arounds in
software. If so, don't worry! I don't think there is a piece of digital
hardware remaining on the planet that doesn't require software playing
nurse-maid. And everybody knows that if a decision has to be made to
re-do a PWB at $150,000 a pop, or to invent some software work-arounds,
the work-arounds will always win. Besides, software is "free". Once it's
done and the software engineers laid-off, you just clone in over-and-over
again. Ask any production manager.

I know of a company that has WOM (Write Only Memory) right in the
middle of some RAM address space. Guess what? It's memory-mapped and
'owned' by some sleeping giant!


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: The end of embedded Linux?

[jbradford]

> > > These modules again drive gate array hardware for which nobody 
> > > else will ever have a compatible. Although I would dearly love to 
> > > use Linux as the platform for my project I feel I cannot release this 
> > > code under the GPL.
> > 
> > That just doesn't make sense.  If nobody else will ever have a
> > compatible piece of hardware, I don't see why you wouldn't want to
> > release the driver code under the GPL.
> > 
> > _Unless_ you fear that somebody will derive your hardware design from
> > the code.  Is that what you're worried about?
> > 
> > John.
> 
> Maybe he's afraid that customers will see that the hardware design is
> absolute garbage with thousands of defective-hardware-work-arounds in
> software. If so, don't worry!

Exactly, the customers are not going to read the source code and
refuse to buy his product.  After all, people buy software modems :-).

> I know of a company that has WOM (Write Only Memory) right in the
> middle of some RAM address space. Guess what? It's memory-mapped and
> 'owned' by some sleeping giant!

Have you seen the spec sheet for a WOM that was published, (I think on
1st April), a long time ago?  It had specs like VDD 0v +/- 2% :-)

John.

Re: The end of embedded Linux?

[Vojtech Pavlik]

On Tue, Oct 08, 2002 at 11:11:44AM +0100, simon@baydel.com wrote:

> The UART and Interrupt controllers in question are built into a gate 
> array. I can't see how any external or parts from other vendors 
> would be compatible. To get the board to boot Linux I have to 
> modify the kernel and lilo. I understand that under the GPL rules I 
> would have to make this code available. I am willing to do this but I 
> don't see the point. 
> 
> There is also more specialized hardware for which I have written 
> modules. Although there appears to be some unwritten rule about 
> releasing objects, I believe that the GPL rules state that these 
> modules must conform to the GPL also, as they contain header 
> files. I cannot see how any module can not contain Linux headers 
> or headers derived from Linux headers if it is to be loaded on a 
> Linux kernel. 
> 
> These modules again drive gate array hardware for which nobody 
> else will ever have a compatible. Although I would dearly love to 
> use Linux as the platform for my project I feel I cannot release this 
> code under the GPL.
> 
> This is my dilemma and I am sure it is shared by others. For this 
> reason I cannot see how anything but an embedded PC with 
> applications or a perhaps a very simple hardware device could be 
> considered as an opportunity for  embedded Linux. 
> 
> I have based these thoughts on my experiences so far. If you feel I 
> have drawn an incorrect conclusion I would be grateful for your 
> input.

Its as easy as: If you want to distribute the binaries, you have to
distribute the source freely. If you don't want to distribute the
binaries nor the code and keep your project private, you don't have to,
under the GPL.

Regarding binary-only kernel modules - well, it's possible, but don't do
that.

-- 
Vojtech Pavlik
SuSE Labs

Re: The end of embedded Linux?

[Alan Cox]

On Tue, 2002-10-08 at 11:11, simon@baydel.com wrote:
> This is my dilemma and I am sure it is shared by others. For this 
> reason I cannot see how anything but an embedded PC with 
> applications or a perhaps a very simple hardware device could be 
> considered as an opportunity for  embedded Linux. 

Certainly the sort of things I was talking about didnt extend to unique
gate arrays for one internal board. [BTW that also came up in the large
computing world too - we never merged a driver for the AP-1000+ fddi
because there were only two cards on the planet 8)]

Alan

Re: The end of embedded Linux?

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: 08 Oct 2002 12:25:14 +0100
   
   [BTW that also came up in the large
   computing world too - we never merged a driver for the AP-1000+ fddi
   because there were only two cards on the planet 8)]

Actually, that driver was in the tree for a long time.

Re: The end of embedded Linux?

[Alan Cox]

On Tue, 2002-10-08 at 21:04, David S. Miller wrote:
>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    Date: 08 Oct 2002 12:25:14 +0100
>    
>    [BTW that also came up in the large
>    computing world too - we never merged a driver for the AP-1000+ fddi
>    because there were only two cards on the planet 8)]
> 
> Actually, that driver was in the tree for a long time.

Are you sure - the drivers for many things were, but not afaik the fddi
one

Re: The end of embedded Linux?

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: 08 Oct 2002 23:53:01 +0100

   On Tue, 2002-10-08 at 21:04, David S. Miller wrote:
   > Actually, that driver was in the tree for a long time.
   
   Are you sure - the drivers for many things were, but not afaik the
   fddi one
   
I am absolutely sure, because I had this weirdo SBUS fddi card
using the AMD SUPERNET chipset just like the ap1000+ one did
and I was going to use their driver as a reference since it
was in the tree already.

Re: The end of embedded Linux?

[jw schultz]

On Tue, Oct 08, 2002 at 11:11:44AM +0100, simon@baydel.com wrote:
> The UART and Interrupt controllers in question are built into a gate 
> array. I can't see how any external or parts from other vendors 
> would be compatible. To get the board to boot Linux I have to 
> modify the kernel and lilo. I understand that under the GPL rules I 
> would have to make this code available. I am willing to do this but I 
> don't see the point. 

The point is that is the license fee.  Under the BSD
license the fee is giving credit.  For Microsoft and other
closed-source/propietary licenses the fee is in money.
With the GPL the consideration (legal term under contract
law) or fee that you pay is to make the source of your
modifications and derivitave works available.
Most of the time that is a fairly inexpensive fee.

If you wish to negotiate a different fee all you have to do
is get every contributor to agree to a seperate license for
you.  You are free (libre) to try but i think it would be
cheaper to go elsewhere.

> There is also more specialized hardware for which I have written 
> modules. Although there appears to be some unwritten rule about 
> releasing objects, I believe that the GPL rules state that these 
> modules must conform to the GPL also, as they contain header 
> files. I cannot see how any module can not contain Linux headers 
> or headers derived from Linux headers if it is to be loaded on a 
> Linux kernel. 

Leave headers aside for the moment.  There is a tolerance
(barely) of binary modules distributed largely because they
suit the purposes of linux (world domination, haha).  Using binary
only modules that don't benefit that will draw the ire (if
not prosecution) of the community.

> These modules again drive gate array hardware for which nobody 
> else will ever have a compatible. Although I would dearly love to 
> use Linux as the platform for my project I feel I cannot release this 
> code under the GPL.

The fact that may be custom hardware that no-one else will
every have access to isn't relevant to the licence.  The
general concensus is that very few embedded projects are
really all that dependant on such specialized hardware.

> This is my dilemma and I am sure it is shared by others. For this 
> reason I cannot see how anything but an embedded PC with 
> applications or a perhaps a very simple hardware device could be 
> considered as an opportunity for  embedded Linux. 

It isn't much of a dilema.  It is just a simple choice you
have to make.  Do you create your own OS?  Or if you choose
to buy one, which license terms are best for you.

Of course you are free to use linux for prototyping and
product developement.  The publication requirements only
come into play when you distribute.  If you choose to use
linux to help develop your product and then distribute with
a different OS then linux has helped to enlarge the GGP
(Gross Global Product) and that is still good.

> I have based these thoughts on my experiences so far. If you feel I 
> have drawn an incorrect conclusion I would be grateful for your 
> input.

They may be correct conclusions for yourself.  Only you can
judge that.  I doubt that they are correct generalizations.

There are some things i would think about before rejecting
linux on such a basis.  Nothing prevents you from putting a
firmware layer underneath linux or putting a bit more
intelegence in your device and then providing a free driver
that can interface with it.  You may be able to put the
intellegence of your hardware control in a user-space
process with elevated priority.  You might look into
something like using the adeos nano-kernel to host linux and
the device controll software as seperate contexts with a
communications interface between them.  There are so many
ways to get linux and proprietary software and hardware to
talk to each other it seems silly to reject it just because
one of way bears license terms you don't like.

If you wish to use linux and contribute good.  If you wish
to go away that is your choice.  If you wish to whine, see
option two.  In either case good luck with your project.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: The end of embedded Linux?

[Alexander Kellett]

On Tue, Oct 08, 2002 at 04:27:19AM -0700, jw schultz wrote:
<mid-sentence snip>
> You might look into something like using the adeos 
> nano-kernel to host linux and the device controll 
> software as seperate contexts with a communications 
> interface between them. 
<snip>

This talk of adeos reminds me of something that i'd
"dreamed" of a while back. Whats the feasability of
having a 70kb kernel that barely even provides support 
for user space apps and is basically just an hardware 
abstraction layer for "applications" that can be 
written as kernel modules?

mvg,
Alex

Re: The end of embedded Linux?

[Alan Cox]

On Wed, 2002-10-09 at 08:37, Alexander Kellett wrote: 
> This talk of adeos reminds me of something that i'd
> "dreamed" of a while back. Whats the feasability of
> having a 70kb kernel that barely even provides support 
> for user space apps and is basically just an hardware 
> abstraction layer for "applications" that can be 
> written as kernel modules?

Its called FreeDOS,

Re: The end of embedded Linux?

[Richard B. Johnson]

On 9 Oct 2002, Alan Cox wrote:

> On Wed, 2002-10-09 at 08:37, Alexander Kellett wrote: 
> > This talk of adeos reminds me of something that i'd
> > "dreamed" of a while back. Whats the feasability of
> > having a 70kb kernel that barely even provides support 
> > for user space apps and is basically just an hardware 
> > abstraction layer for "applications" that can be 
> > written as kernel modules?
> 
> Its called FreeDOS,
> 

-emm. Maybe he needs just a bit more. There's s book by Richard A.
Burgess, "Developing your own 32-bit Operating System". Howard W Sams.
ISBN 0-672-30655-7. It comes with a CDROM and a small OS that works.

In fact, it seems that a well-known, expensive 32-bit OS used by a
lot of the embedded companies is is DIRECT COPY of this! In many
procedures they didn't even change the variable names. The only thing
they did was... oh well I don't want to get sued ... 


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

Re: The end of embedded Linux?

[jbradford]

> 
> On 9 Oct 2002, Alan Cox wrote:
> 
> > On Wed, 2002-10-09 at 08:37, Alexander Kellett wrote: 
> > > This talk of adeos reminds me of something that i'd
> > > "dreamed" of a while back. Whats the feasability of
> > > having a 70kb kernel that barely even provides support 
> > > for user space apps and is basically just an hardware 
> > > abstraction layer for "applications" that can be 
> > > written as kernel modules?
> > 
> > Its called FreeDOS,
> > 
> 
> -emm. Maybe he needs just a bit more.

Minix, maybe?

John.

Re: The end of embedded Linux?

[jw schultz]

On Wed, Oct 09, 2002 at 08:17:45PM +0100, jbradford@dial.pipex.com wrote:
> > 
> > On 9 Oct 2002, Alan Cox wrote:
> > 
> > > On Wed, 2002-10-09 at 08:37, Alexander Kellett wrote: 
> > > > This talk of adeos reminds me of something that i'd
> > > > "dreamed" of a while back. Whats the feasability of
> > > > having a 70kb kernel that barely even provides support 
> > > > for user space apps and is basically just an hardware 
> > > > abstraction layer for "applications" that can be 
> > > > written as kernel modules?
> > > 
> > > Its called FreeDOS,
> > > 
> > 
> > -emm. Maybe he needs just a bit more.
> 
> Minix, maybe?

Now, be realistic.  What he asks here isn't that
farfeteched.  Tell me one other OS that has drivers of the
same quality.  I'll be the first to say (oops, Alan beat me
to it) that a Linux stripped down that much wouldn't be
Linux.

However, it wouldn't be an unreasonable project to create
sort of fork that strips Linux down to the bare minimum
while still keeping the driver API.  I don't say that it can
be done just that it might make a reasonable public project
if enough embedded people wanted such a beast^Winsect.  The
dificulty would be excising/replacing core code without
breaking it, side-porting driver patches, and the periodic
resyncing with Linux so new drivers and driver patches would
still apply.  Painful indeed.

Of course it wouldn't be Linux.  Maybe call it Minux or Minlin.
And give it its own mailing list instead of linux-kernel.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: The end of embedded Linux?

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> On Wed, 2002-10-09 at 08:37, Alexander Kellett wrote: 
> > This talk of adeos reminds me of something that i'd
> > "dreamed" of a while back. Whats the feasability of
> > having a 70kb kernel that barely even provides support 
> > for user space apps and is basically just an hardware 
> > abstraction layer for "applications" that can be 
> > written as kernel modules?
> 
> Its called FreeDOS,

A 70KB kernel without device drivers, or anything much compiled
in is a reasonable target.   The whole "applications as modules"
thing is an entirely different animal.

The initial complaint about the size growth of the 
Anything is better that 200+KB compressed as a minimal size.

Eric

Re: The end of embedded Linux?

[Ian Molton]

On Wed, 9 Oct 2002 09:37:25 +0200
Alexander Kellett <lypanov@kde.org> wrote:

> This talk of adeos reminds me of something that i'd
> "dreamed" of a while back. Whats the feasability of
> having a 70kb kernel that barely even provides support 
> for user space apps and is basically just an hardware 
> abstraction layer for "applications" that can be 
> written as kernel modules?

Isnt that a microkernel? ;-) <ducks>

Re: The end of embedded Linux?

[Shane Nay]

On Wednesday 09 October 2002 00:37, Alexander Kellett wrote:
> On Tue, Oct 08, 2002 at 04:27:19AM -0700, jw schultz wrote:
> <mid-sentence snip>
>
> > You might look into something like using the adeos
> > nano-kernel to host linux and the device controll
> > software as seperate contexts with a communications
> > interface between them.
>
> <snip>
>
> This talk of adeos reminds me of something that i'd
> "dreamed" of a while back. Whats the feasability of
> having a 70kb kernel that barely even provides support
> for user space apps and is basically just an hardware
> abstraction layer for "applications" that can be
> written as kernel modules?

eCos maybe?, vxworks, nucleus, but the first one is easiest to get 
ahold of sourcewise.  A redboot type build is nearish 70kB if memory 
serves.  (I've only played around with it once on a StrongARM chip 
for kicks)

Thanks,
Shane Nay.

Re: The end of embedded Linux?

[David Lang]

note that you are allowed to distribute a binary-only module as long as
you don't use the GPL-only kernel symbols. Linus has stated that he
doesn't view use of the header files as enough to make a module a
dirivitive work (others disagree, but there are a number of binary modules
out there)

check the archives for the various flame wars over this issue.

David Lang

On Tue, 8 Oct 2002 simon@baydel.com wrote:

> Date: Tue, 8 Oct 2002 11:11:44 +0100
> From: simon@baydel.com
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: The end of embedded Linux?
>
> On 7 Oct 2002, at 21:22, Alan Cox wrote:
>
> > On Mon, 2002-10-07 at 18:15, simon@baydel.com wrote:
> > > a serial port and an interupt controller. What I was trying to explain
> > > was that I would not mind making my code available for these
> > > kernel changes. Although I don't understand why anyone would
> > > want it. Apart from API changes, why do this ? The kernel is not
> > > easily or frequently changed on this type of system. It would bloat
> > > the kernel and I would expect to have to address problems of this
> > > nature myself.  However I would not like to make code available for
> > > the more specialised hardware.
> >
> > That depends how specialized the hardware actually is. I think I've see
> > six different non free implementations of 68360 sync serial code around
> > all proprietary for example.
> >
>
> The UART and Interrupt controllers in question are built into a gate
> array. I can't see how any external or parts from other vendors
> would be compatible. To get the board to boot Linux I have to
> modify the kernel and lilo. I understand that under the GPL rules I
> would have to make this code available. I am willing to do this but I
> don't see the point.
>
> There is also more specialized hardware for which I have written
> modules. Although there appears to be some unwritten rule about
> releasing objects, I believe that the GPL rules state that these
> modules must conform to the GPL also, as they contain header
> files. I cannot see how any module can not contain Linux headers
> or headers derived from Linux headers if it is to be loaded on a
> Linux kernel.
>
> These modules again drive gate array hardware for which nobody
> else will ever have a compatible. Although I would dearly love to
> use Linux as the platform for my project I feel I cannot release this
> code under the GPL.
>
> This is my dilemma and I am sure it is shared by others. For this
> reason I cannot see how anything but an embedded PC with
> applications or a perhaps a very simple hardware device could be
> considered as an opportunity for  embedded Linux.
>
> I have based these thoughts on my experiences so far. If you feel I
> have drawn an incorrect conclusion I would be grateful for your
> input.
>
>
> Many Thanks
>
> Simon.
>
>
>
> > Also my original comments were much more aimed at the core stuff. People
> > who made existing and especially core stuff smaller could send the stuff
> > out. Several of us want to compile a CONFIG_TINY option, and suprisingly
> > enough small is good on high end boxes. My L1 cache is 8 times faster
> > than my L2 cache is 7 times faster than my memory. Or to put it another
> > way, going to main memory costs me maybe 100 instructions.
> >
> > My Athlon thinks small is good too!
> >
>
>
> __________________________
>
> Simon Haynes - Baydel
> Phone : 44 (0) 1372 378811
> Email : simon@baydel.com
> __________________________
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: The end of embedded Linux?

[David Woodhouse]

david.lang@digitalinsight.com said:
> note that you are allowed to distribute a binary-only module as long
> as you don't use the GPL-only kernel symbols. 

Is this formal legal advice?

> Linus has stated that he doesn't view use of the header files as enough
> to make a module a dirivitive work

Linus explicitly refused to collect copyright assignments from contributors.
Therefore he doesn't have the authority to make that kind of variation in
the licence. And variation it is, in the opinion of many people who own 
copyright on parts of the Linux kernel.

> (others disagree, but there are a number of binary modules out there) 

Indeed others do disagree. And the fact that existing vendors of 
binary-only modules haven't _yet_ been sued for it is not a guarantee that 
it will not happen. Unlike trademarks, copyright does not become void if 
you fail to protect it for a while.

Anyone releasing binary only modules does run a non-zero risk of being sued
for it. Opinion varies on the likelihood of them actually losing the case if
that happens.

Anyone considering releasing a non-GPL kernel module should consult their
own lawyers at their own expense, and make their own decision as to whether
the risk is acceptable.

--
dwmw2

Re: The end of embedded Linux?

[Xavier Bestel]

Le lun 07/10/2002 à 12:06, simon@baydel.com a écrit :

> The real point of all this is that the kernel developers seem really 
> upset about embedded code which is not released under the GPL.

Err ... but you *can't* get away with the GPL if you distribute the
kernel you modified, e.g. by selling your appliances. Unless you live in
a country without copyright law, you are allowed to distribute
linux-based software only if you enable source distribution too.

Trying to actively fold your modifications into the mainline is another
matter.

	Xav

Re: The end of embedded Linux?

[simon]

It is likley that this project will not go to the market with Linux as 
the OS. The original intention was to make available all kernel 
changes and ship object modules for the specialised hardware. 

Reading the GPL tells me that really it is not correct to ship 
modules either, athough I know people do it.

For these reasons I feel I will have to use some other OS.
What I don't understand is how people in the embedded world live 
with this and the reason for embedded Linux unless you are 
effectively running a PC with some apps.

Cheers

Simon.


On 7 Oct 2002, at 12:55, Xavier Bestel wrote:

> Le lun 07/10/2002 à 12:06, simon@baydel.com a écrit :
> 
> > The real point of all this is that the kernel developers seem really 
> > upset about embedded code which is not released under the GPL.
> 
> Err ... but you *can't* get away with the GPL if you distribute the
> kernel you modified, e.g. by selling your appliances. Unless you live in
> a country without copyright law, you are allowed to distribute
> linux-based software only if you enable source distribution too.
> 
> Trying to actively fold your modifications into the mainline is another
> matter.
> 
> 	Xav
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Mon, Oct 07, 2002 at 06:20:46PM +0100, simon@baydel.com escreveu:
> It is likley that this project will not go to the market with Linux as 
> the OS. The original intention was to make available all kernel 
> changes and ship object modules for the specialised hardware. 
> 
> Reading the GPL tells me that really it is not correct to ship 
> modules either, athough I know people do it.

Well, ask a lawyer, but Linux is licensed under the GPL _plus_ some
extra clauses, for instance it is ok, AFAIK, to ship a binary only module
that restrains itself to using non EXPORT_SYMBOL_GPL exported symbols.

Think NVidia, vmware, etc.

And yes, IANAL.

- Arnaldo

Re: The end of embedded Linux?

[Alan Cox]

On Mon, 2002-10-07 at 23:59, Arnaldo Carvalho de Melo wrote:

> Well, ask a lawyer, but Linux is licensed under the GPL _plus_ some
> extra clauses, for instance it is ok, AFAIK, to ship a binary only module
> that restrains itself to using non EXPORT_SYMBOL_GPL exported symbols.

Nope its GPL, barring the rules for user apps - check the COPYING file.
Nvidia would claim their driver is a seperate work, and as such since
its not a derivative work is none of our business

Re: The end of embedded Linux?

[Matt Porter]

On Sun, Oct 06, 2002 at 05:53:26PM +0100, Alan Cox wrote:
> On Sun, 2002-10-06 at 05:28, David S. Miller wrote:
> > Embedded applications tend to have issues which are entirely specific
> > to that embedded project.  As such, those are things that do not
> > belong in a general purpose OS.
> 
> 90% of the embedded Linux problem is not this. Its actually easy to get
> most of the embedded needs into the base kernel - in fact they overlap
> the other worlds a lot.
 
No argument there.

<snip>

> No the big problem is that each embedded vendor is desperately trying to
> keep their changes out of the mainstream so they can screw each other.
> In doing so the main people they screw are all their customers.

I just don't see much of this at the embedded linux vendor that
brings my check.  Everything gets pushed out somewhere.  I know
with some of the smaller embedded linux players I don't see any
participation, but I'm not sure where you've developed this
viewpoint ... oh perhaps it is from lkml participation?

Let's think about that...many embedded developers have been around
for years, some may have been more active in core kernel discussions
on lkml (RMK) but others have been extremely active in arch-specific
development.  You don't hear from them because there is such a huge
amount of work masked out by blobs of merges from the arch maintainers.
For example, we have a very strong group of people working on Linux/PPC
many of which have been around for years making the tree organized
for the many board ports that need to be done, reacting to breakage
from ia32-oriented development, etc.  The issues are a little different
in that we keep getting new sub-families of PPC processors and new
boards everyday that don't follow a semi-standard PC architecture.
Most of our time is spent just enabling these systems and working
out arch-specific issues.

That said, I have a laundry list of "mainstream" things like
>32-bit phys remap_page_range, 64-bit resources, and PCI MSI
support I'd like to work on.  It just takes time and it's more
important to fix fundamentals like our PPC 4xx SoC
infrastructure. :)

> So if the embedded people want 2.6 to be good at embedded they need to
> get their heads out of their arses and contribute to the mainstream.
> Otherwise they'll always be chasing a moving ball, and a ball most
> people are kicking the other way down the field. Its a simple fact of
> line, if you stick you head up your backside all you get to do is eat
> shit
> 
> (and yes there are some embedded people who do contribute but they are
> sadly a real minority)

Thanks for not completely diminishing our work. 

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: The end of embedded Linux?

[Matt Porter]

On Sat, Oct 05, 2002 at 09:28:32PM -0700, David S. Miller wrote:
> Embedded applications tend to have issues which are entirely specific
> to that embedded project.  As such, those are things that do not
> belong in a general purpose OS.

Exactly, every application wants some of the finer details of
kernel operation tuned to their task.

> The common areas, like smaller hashtables or whatever, sure put a
> CONFIG_SMALL_KERNEL option in there and start submitting the
> one-liners here and there that do it.

Ahhh, but you just defeated the ideal of being able to customize
to task.  This is where the hallowed "the user is dumb" theory
bites us in the ass.  A single option to control all these sizing
issues reduces flexibility and that is what the embedded system
designer is looking for.  The ideal situation is if as we work
on all these areas where we can reduce size, we provide fine
grained options to tweak them (with a default desktop/server value
and a default "tiny" value).  You can have this CONFIG_TINY or
whatever, but then we should also provide the ability to tweak
the values exactly how we want in a specific application.  The
tweaking options can be buried under advanced kernel options
with the appropriate disclaimers about shooting yourself in
the foot.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: The end of embedded Linux?

[Rob Landley]

On Monday 07 October 2002 12:22 pm, Matt Porter wrote:
> On Sat, Oct 05, 2002 at 09:28:32PM -0700, David S. Miller wrote:

> > The common areas, like smaller hashtables or whatever, sure put a
> > CONFIG_SMALL_KERNEL option in there and start submitting the
> > one-liners here and there that do it.
>
> Ahhh, but you just defeated the ideal of being able to customize
> to task.  This is where the hallowed "the user is dumb" theory
> bites us in the ass.  A single option to control all these sizing
> issues reduces flexibility and that is what the embedded system
> designer is looking for.

Or it the Great Big Lever gives them something to grep for if they want to do 
fine-tuned tweaking and need to find all the places it might pay to give a 
closer look to.

> The ideal situation is if as we work
> on all these areas where we can reduce size, we provide fine
> grained options to tweak them (with a default desktop/server value
> and a default "tiny" value).

8000 controls you have to individually tweak to do anything is not 
necessarily an improvement over a single "do what I want" button.  (User 
Interface Design 101.)

The doorknob is a wonderful user interface...

> You can have this CONFIG_TINY or
> whatever, but then we should also provide the ability to tweak
> the values exactly how we want in a specific application.  The
> tweaking options can be buried under advanced kernel options
> with the appropriate disclaimers about shooting yourself in
> the foot.

Or they could play in the source code if their needs are sufficiently 
unusual, which more or less by definition they will be in this case.  No 
matter how thorough you are here, there will be things they want to tweak (or 
would if they knew about them) that there is no config option for.  "make 
menuconfig" is not a complete replacement for knowing C in all cases.

> Regards,

Rob

Re: The end of embedded Linux?

[Gigi Duru]

--- Rob Landley <landley@trommello.org> wrote:
> 8000 controls you have to individually tweak to do
> anything is not 
> necessarily an improvement over a single "do what I
> want" button.  (User 
> Interface Design 101.)
> 
> The doorknob is a wonderful user interface...
> 

try driving your car using a doorknob ;)

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Rob Landley]

On Monday 07 October 2002 05:56 pm, Gigi Duru wrote:
> --- Rob Landley <landley@trommello.org> wrote:
> > 8000 controls you have to individually tweak to do
> > anything is not
> > necessarily an improvement over a single "do what I
> > want" button.  (User
> > Interface Design 101.)
> >
> > The doorknob is a wonderful user interface...
>
> try driving your car using a doorknob ;)

The steering wheel is fundamentally different?  (It's certainly BIGGER...)

Rob

Re: The end of embedded Linux?

[Thomas Molina]

On Mon, 7 Oct 2002, Rob Landley wrote:

> On Monday 07 October 2002 05:56 pm, Gigi Duru wrote:
> > --- Rob Landley <landley@trommello.org> wrote:
> > > 8000 controls you have to individually tweak to do
> > > anything is not
> > > necessarily an improvement over a single "do what I
> > > want" button.  (User
> > > Interface Design 101.)
> > >
> > > The doorknob is a wonderful user interface...
> >
> > try driving your car using a doorknob ;)
> 
> The steering wheel is fundamentally different?  (It's certainly BIGGER...)

Actually, I believe the wheel, and the rest of the user interface for an 
auto (gas pedal, brake) are a fine metaphor for this discussion.  The user 
interface for a car hasn't changed in how many years?  That is despite 
quite a number of technological devleopments under the hood.  Having a 
simple user interface for the "novice" doesn't prevent all kinds of weird 
shifting, throttle control, etc. additions for the "expert".  Having a 
single doorknob which controls, in a gross way, the action of a large 
number of "sub-knobs" is good.  Giving access to the "sub-knobs" for the 
expert is even better.

Re: The end of embedded Linux?

[Rob Landley]

On Tuesday 08 October 2002 09:22 am, Thomas Molina wrote:
> On Mon, 7 Oct 2002, Rob Landley wrote:
> > On Monday 07 October 2002 05:56 pm, Gigi Duru wrote:
> > > --- Rob Landley <landley@trommello.org> wrote:
> > > > The doorknob is a wonderful user interface...
> > >
> > > try driving your car using a doorknob ;)
> >
> > The steering wheel is fundamentally different?  (It's certainly
> > BIGGER...)
>
> Actually, I believe the wheel, and the rest of the user interface for an
> auto (gas pedal, brake) are a fine metaphor for this discussion.  The user
> interface for a car hasn't changed in how many years?  That is despite
> quite a number of technological devleopments under the hood.  Having a
> simple user interface for the "novice" doesn't prevent all kinds of weird
> shifting, throttle control, etc. additions for the "expert".  Having a
> single doorknob which controls, in a gross way, the action of a large
> number of "sub-knobs" is good.  Giving access to the "sub-knobs" for the
> expert is even better.

And extending the metaphor, even racecar drivers use a steering wheel and gas 
pedal.  (They almost always prefer manual transmission over auto, and like to 
have a tachometer in their display, but those are options for regular drivers 
in normal cars too.)

There are 8 zillion strange adjustable things in a racecar, but that's for 
the pit crew to deal with, not the driver.

The linux kernel is the same.  Going into the source is definitely something 
the pit crew is responsible for, or your friendly neighborhood garage 
mechanic, or the guy who likes to change his own oil on the weekends.

"make menuconfig" isn't anywhere near steering wheel simplicity, but the last 
time we had this discussion "aunt tillie" wandered through, which effectively 
ended rational debate if you ask me.  (She's like that, I suppose. :)  Still, 
cluttering it up any more than strictly necessary probably isn't a good thing.

90% of learning to deal with the linux kernel is learning to separate out the 
stuff you're interested in from the bits you can safely ignore at the moment, 
so you can tackle things one piece at a time.  (For some value of "safely", 
anyway... :)

Rob

Re: The end of embedded Linux?

[Matt Porter]

On Mon, Oct 07, 2002 at 12:41:08PM -0400, Rob Landley wrote:
> On Monday 07 October 2002 12:22 pm, Matt Porter wrote:
> > On Sat, Oct 05, 2002 at 09:28:32PM -0700, David S. Miller wrote:
> 
> > > The common areas, like smaller hashtables or whatever, sure put a
> > > CONFIG_SMALL_KERNEL option in there and start submitting the
> > > one-liners here and there that do it.
> >
> > Ahhh, but you just defeated the ideal of being able to customize
> > to task.  This is where the hallowed "the user is dumb" theory
> > bites us in the ass.  A single option to control all these sizing
> > issues reduces flexibility and that is what the embedded system
> > designer is looking for.
> 
> Or it the Great Big Lever gives them something to grep for if they want to do 
> fine-tuned tweaking and need to find all the places it might pay to give a 
> closer look to.

I can buy that too.  It would be a great improvement over instructing
people to grok all one bazillion lines of kernel code to understand
how to tweak an area that might need to be massaged in three places.
 
> > The ideal situation is if as we work
> > on all these areas where we can reduce size, we provide fine
> > grained options to tweak them (with a default desktop/server value
> > and a default "tiny" value).
> 
> 8000 controls you have to individually tweak to do anything is not 
> necessarily an improvement over a single "do what I want" button.  (User 
> Interface Design 101.)

Well, now you are at the other end of the spectrum.  I'm not suggesting
we head over that far.  Some popular "high impact" areas could be
provided the finer grained controls and the others could just be
lumped together.  I think there can be a middle ground that's
beneficial.
 
> The doorknob is a wonderful user interface...

Yes. :)
 
> > You can have this CONFIG_TINY or
> > whatever, but then we should also provide the ability to tweak
> > the values exactly how we want in a specific application.  The
> > tweaking options can be buried under advanced kernel options
> > with the appropriate disclaimers about shooting yourself in
> > the foot.
> 
> Or they could play in the source code if their needs are sufficiently 
> unusual, which more or less by definition they will be in this case.  No 
> matter how thorough you are here, there will be things they want to tweak (or 
> would if they knew about them) that there is no config option for.  "make 
> menuconfig" is not a complete replacement for knowing C in all cases.

True, but there are a number of people out there who want to do say
a kernel port to XYZ custom board.  They learn some basic kernel
knowledge, but we can't expect them to be a guru of everything to
get some work done.

One thing that happens with even a little more flexibility is that
the amount of traffic about tweaking things go down a bit.  Not a
"sizing" type tweak, but I often get questions about optimizing
kernel VM space on high-end PPC systems. We put in some options
so that TASK_SIZE, PAGE_OFFSET, and PKMAP_BASE can be easily
tweaked...now it's easy to tell somebody where to look to make
a change.  Before that, it was necessary to explain both places
that mod needed to be made to move KERNELBASE to a smarter value.

Now, one thing I consider at this point is that if we do think
about even a *little* more fine-grained settings, config options
may not be the place to collect them.  We could just have a common
include to catch all these things.  That would hide it away from
the "dumb users" a bit and even provide a basis for a mechanism
to have some different system "profiles" perhaps.  CONFIG_TINY,
CONFIG_DESKTOP, CONFIG_SERVER..who knows.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: The end of embedded Linux?

[Rob Landley]

On Monday 07 October 2002 07:20 pm, Matt Porter wrote:
>
> > Or they could play in the source code if their needs are sufficiently
> > unusual, which more or less by definition they will be in this case.  No
> > matter how thorough you are here, there will be things they want to tweak
> > (or would if they knew about them) that there is no config option for. 
> > "make menuconfig" is not a complete replacement for knowing C in all
> > cases.
>
> True, but there are a number of people out there who want to do say
> a kernel port to XYZ custom board.  They learn some basic kernel
> knowledge, but we can't expect them to be a guru of everything to
> get some work done.

Another very real option here is Documentation/tinykernel.txt.  (Possibly 
even going so far as a brief mention of uclibc and busybox/tinylogin, but 
mostly just about choping down the kernel for embedding in nosehair trimmers 
and electric toothbrushes and such.)

Rob "waiting for the linux i-button" Landley.

Re: The end of embedded Linux?

[Matt Porter]

On Mon, Oct 07, 2002 at 03:50:43PM -0400, Rob Landley wrote:
> On Monday 07 October 2002 07:20 pm, Matt Porter wrote:
> >
> > > Or they could play in the source code if their needs are sufficiently
> > > unusual, which more or less by definition they will be in this case.  No
> > > matter how thorough you are here, there will be things they want to tweak
> > > (or would if they knew about them) that there is no config option for. 
> > > "make menuconfig" is not a complete replacement for knowing C in all
> > > cases.
> >
> > True, but there are a number of people out there who want to do say
> > a kernel port to XYZ custom board.  They learn some basic kernel
> > knowledge, but we can't expect them to be a guru of everything to
> > get some work done.
> 
> Another very real option here is Documentation/tinykernel.txt.  (Possibly 
> even going so far as a brief mention of uclibc and busybox/tinylogin, but 
> mostly just about choping down the kernel for embedding in nosehair trimmers 
> and electric toothbrushes and such.)

I don't see these as mutually exclusive.  Documentation falls out of
date because it is often not maintained with the code.  This would
certainly be the case of a file detailing means to tweak a wide
array of settings in the kernel.

Having the settings controlled somewhere in the kernel forces the
settings to not be broken as we move forward.  This is the same
simple reason we all try to get our drivers and board ports in
the kernel proper (as being discussed elsewhere in this thread).
I believe some finer grained controls (less than 8000 hopefully)
coupled with some basic docs pointing out where they can be configured,
a description of some of the more interesting ones, and mentioning some
non-kernel tools would be quite appropriate.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: The end of embedded Linux?

[Rob Landley]

On Tuesday 08 October 2002 11:04 am, Matt Porter wrote:
> On Mon, Oct 07, 2002 at 03:50:43PM -0400, Rob Landley wrote:
>
> > Another very real option here is Documentation/tinykernel.txt.  (Possibly
> > even going so far as a brief mention of uclibc and busybox/tinylogin, but
> > mostly just about choping down the kernel for embedding in nosehair
> > trimmers and electric toothbrushes and such.)
>
> I don't see these as mutually exclusive.

Neither do I, but an "incredible shrinking kernel HOWTO" is less intrusive 
than marking up the source code with #ifdefs..

> Documentation falls out of
> date because it is often not maintained with the code.  This would
> certainly be the case of a file detailing means to tweak a wide
> array of settings in the kernel.
>
> Having the settings controlled somewhere in the kernel forces the
> settings to not be broken as we move forward.

Really?  Since when?

Go into make menuconfig in 2.4.19.  Switch off "scsi support".  Back to the 
main menu, try to descend into "fusion mpt device support".  The menu still 
shows up (at the top level, I might add), but you can't go into it.

That's been broken for over a year now.  It's in the top level of menuconfig. 
 I first reported it back around 2.4.6 or so.  It just doesn't get in 
anybody's way, and that area of code is a mess, and not fixing it isn't 
embarassing anybody specific.

Putting stuff into the mainstream kernel doesn't force it to be maintained by 
pixies.  It's just that stuff that stays broken long enough, which nobody 
steps up to fix, gets removed.

The main difference between code in the tree and Documentation/ in the tree 
is that if something is broken, you have to fix your copyof the code to get 
it to work for you, so it's not much more work to send in a patch.  At that 
point, the work of updating your tree is already done, and if you don't send 
in the patch you've got to fix it again next release..

If the documentation is broken, and you sit down and figure out how to do it, 
you haven't already written up a howto.  You won't get anything out of the 
howto at that point, but there's significant extra work in getting the docs 
updated that comes AFTER the bit you can't help but do.

So there are advantages to having code in the tree, but it's not a magic 
bullet...

> I believe some finer grained controls (less than 8000 hopefully)
> coupled with some basic docs pointing out where they can be configured,
> a description of some of the more interesting ones, and mentioning some
> non-kernel tools would be quite appropriate.

A hybrid approach does sound best...

> Regards,

Rob

Re: The end of embedded Linux?

[Adrian Bunk]

On Tue, 8 Oct 2002, Rob Landley wrote:

>...
> Go into make menuconfig in 2.4.19.  Switch off "scsi support".  Back to the
> main menu, try to descend into "fusion mpt device support".  The menu still
> shows up (at the top level, I might add), but you can't go into it.
>
> That's been broken for over a year now.  It's in the top level of menuconfig.
>  I first reported it back around 2.4.6 or so.  It just doesn't get in
> anybody's way, and that area of code is a mess, and not fixing it isn't
> embarassing anybody specific.
>...

I assume the patch below fixes this for i386 (similar patches are needed
for at most four other architectures)?

> Rob

cu
Adrian

--- l/arch/i386/config.in.old	2002-10-09 13:28:59.000000000 +0200
+++ l/arch/i386/config.in	2002-10-09 13:31:44.000000000 +0200
@@ -357,7 +357,11 @@
 fi
 endmenu

-source drivers/message/fusion/Config.in
+if [ "$CONFIG_SCSI" != "n" ]; then
+   if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then
+      source drivers/message/fusion/Config.in
+   fi
+fi

 source drivers/ieee1394/Config.in

[patch] show Fusion MPT dialog only when CONFIG_BLK_DEV_SD is set

[Adrian Bunk]

On Wed, 9 Oct 2002, Adrian Bunk wrote:

> On Tue, 8 Oct 2002, Rob Landley wrote:
>
> >...
> > Go into make menuconfig in 2.4.19.  Switch off "scsi support".  Back to the
> > main menu, try to descend into "fusion mpt device support".  The menu still
> > shows up (at the top level, I might add), but you can't go into it.
> >
> > That's been broken for over a year now.  It's in the top level of menuconfig.
> >  I first reported it back around 2.4.6 or so.  It just doesn't get in
> > anybody's way, and that area of code is a mess, and not fixing it isn't
> > embarassing anybody specific.
> >...
>
> I assume the patch below fixes this for i386 (similar patches are needed
> for at most four other architectures)?
>...

Thinking about it the following is perhaps a better solution since the
fix is now in the arch-independent part.

This patch includes the following changes:
- offer the menu only when CONFIG_SCSI and CONFIG_BLK_DEV_SD are set
- remove an obsolete comment (the force to module or nothing was already
  implemented)
- remove a workaround for pre-linux-2.2.15 kernels
- indentation

It applys against 2.4.20-pre9 and 2.5.41.

Tested with "make menuconfig" and "make xconfig" in 2.4.20-pre9.

cu
Adrian


--- linux-2.4.19/drivers/message/fusion/Config.in.old	2002-10-09 13:52:33.000000000 +0200
+++ linux-2.4.19/drivers/message/fusion/Config.in	2002-10-09 14:09:28.000000000 +0200
@@ -1,37 +1,37 @@
-mainmenu_option next_comment
-comment 'Fusion MPT device support'
+if [ "$CONFIG_SCSI" != "n" ]; then
+   if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then
+      mainmenu_option next_comment
+      comment 'Fusion MPT device support'
+
+      dep_tristate "Fusion MPT (base + ScsiHost) drivers" CONFIG_FUSION $CONFIG_SCSI $CONFIG_BLK_DEV_SD
+
+      if [ "$CONFIG_FUSION" = "y" -o "$CONFIG_FUSION" = "m" ]; then
+
+        if [ "$CONFIG_BLK_DEV_SD" = "y" -a "$CONFIG_FUSION" = "y" ]; then
+          define_bool CONFIG_FUSION_BOOT y
+        else
+          define_bool CONFIG_FUSION_BOOT n
+        fi
+
+        if [ "$CONFIG_MODULES" = "y" ]; then
+          dep_tristate "  Enhanced SCSI error reporting" CONFIG_FUSION_ISENSE $CONFIG_FUSION m
+          dep_tristate "  Fusion MPT misc device (ioctl) driver" CONFIG_FUSION_CTL $CONFIG_FUSION m
+        fi
+
+        dep_tristate "  Fusion MPT LAN driver" CONFIG_FUSION_LAN $CONFIG_FUSION $CONFIG_NET
+        if [ "$CONFIG_FUSION_LAN" != "n" ]; then
+          define_bool CONFIG_NET_FC y
+        fi
+
+      else
+
+        define_bool CONFIG_FUSION_BOOT n
+        define_tristate CONFIG_FUSION_ISENSE n
+        define_tristate CONFIG_FUSION_CTL n
+        define_tristate CONFIG_FUSION_LAN n

-dep_tristate "Fusion MPT (base + ScsiHost) drivers" CONFIG_FUSION $CONFIG_SCSI $CONFIG_BLK_DEV_SD
-
-if [ "$CONFIG_FUSION" = "y" -o "$CONFIG_FUSION" = "m" ]; then
-
-  if [ "$CONFIG_BLK_DEV_SD" = "y" -a "$CONFIG_FUSION" = "y" ]; then
-    define_bool CONFIG_FUSION_BOOT y
-  else
-    define_bool CONFIG_FUSION_BOOT n
-  fi
-
-  if [ "$CONFIG_MODULES" = "y" ]; then
-    #  How can we force these options to module or nothing?
-    dep_tristate "  Enhanced SCSI error reporting" CONFIG_FUSION_ISENSE $CONFIG_FUSION m
-    dep_tristate "  Fusion MPT misc device (ioctl) driver" CONFIG_FUSION_CTL $CONFIG_FUSION m
-  fi
-
-  dep_tristate "  Fusion MPT LAN driver" CONFIG_FUSION_LAN $CONFIG_FUSION $CONFIG_NET
-  if [ "$CONFIG_FUSION_LAN" != "n" ]; then
-    define_bool CONFIG_NET_FC y
-  fi
-
-else
-
-  define_bool CONFIG_FUSION_BOOT n
-  # These <should> be define_tristate, but we leave them define_bool
-  # for backward compatibility with pre-linux-2.2.15 kernels.
-  # (Bugzilla:fibrebugs, #384)
-  define_bool CONFIG_FUSION_ISENSE n
-  define_bool CONFIG_FUSION_CTL n
-  define_bool CONFIG_FUSION_LAN n
+      fi

+      endmenu
+   fi
 fi
-
-endmenu

Re: [patch] show Fusion MPT dialog only when CONFIG_BLK_DEV_SD is set

[Rob Landley]

On Wednesday 09 October 2002 08:15 am, Adrian Bunk wrote:

> Thinking about it the following is perhaps a better solution since the
> fix is now in the arch-independent part.

That's good too, but it still belongs in the scsi low-level driver menu
since it's a scsi low level driver.  (I just sent a much less ambitius 
patch...)

Rob

[PATCH]: Move Fusion MPT config menu into scsi driver support (was Re: The end of embedded Linux?)

[Rob Landley]

On Wednesday 09 October 2002 07:38 am, Adrian Bunk wrote:
> On Tue, 8 Oct 2002, Rob Landley wrote:
> >...
> > Go into make menuconfig in 2.4.19.  Switch off "scsi support".  Back to
> > the main menu, try to descend into "fusion mpt device support".  The menu
> > still shows up (at the top level, I might add), but you can't go into it.
> >
> > That's been broken for over a year now.  It's in the top level of
> > menuconfig. I first reported it back around 2.4.6 or so.  It just doesn't
> > get in anybody's way, and that area of code is a mess, and not fixing it
> > isn't embarassing anybody specific.
> >...
>
> I assume the patch below fixes this for i386 (similar patches are needed
> for at most four other architectures)?
>
> > Rob
>
> cu
> Adrian
>
> --- l/arch/i386/config.in.old	2002-10-09 13:28:59.000000000 +0200
> +++ l/arch/i386/config.in	2002-10-09 13:31:44.000000000 +0200
> @@ -357,7 +357,11 @@
>  fi
>  endmenu
>
> -source drivers/message/fusion/Config.in
> +if [ "$CONFIG_SCSI" != "n" ]; then
> +   if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then
> +      source drivers/message/fusion/Config.in
> +   fi
> +fi
>
>  source drivers/ieee1394/Config.in

Ah, is that how you do it?  (Where were you eight months ago? :)

The bigger problem is that the sucker belongs in the SCSI menu, not in the top
level menu, so something more like...  (Patch against 2.4.19)

--- linuxold/arch/i386/config.in        Wed Oct  9 15:35:43 2002
+++ linux-2.4.19/arch/i386/config.in    Wed Oct  9 15:41:03 2002
@@ -332,8 +332,6 @@
 fi
 endmenu

-source drivers/message/fusion/Config.in
-
 source drivers/ieee1394/Config.in

 source drivers/message/i2o/Config.in
--- linuxold/drivers/scsi/Config.in     Wed Oct  9 15:39:42 2002
+++ linux-2.4.19/drivers/scsi/Config.in Wed Oct  9 15:41:52 2002
@@ -117,6 +117,7 @@
       bool  '  ppa/imm option - Assume slow parport control register' CONFIG_SCSI_IZIP_SLOW_CTR
    fi
 fi
+source drivers/message/fusion/Config.in
 dep_tristate 'NCR53c406a SCSI support' CONFIG_SCSI_NCR53C406A $CONFIG_SCSI
 if [ "$CONFIG_MCA" = "y" ]; then
    dep_tristate 'NCR Dual 700 MCA SCSI support' CONFIG_SCSI_NCR_D700 $CONFIG_SCSI

The above "Works for me."  Not that I have a fusion MPT controller, but the config
menu looks right now. :)  And help says it's a specific brand of fiber channel
controller, so life is good...

Rob

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Mon, Oct 07, 2002 at 09:22:12AM -0700, Matt Porter escreveu:

> The ideal situation is if as we work on all these areas where we can reduce
> size, we provide fine grained options to tweak them (with a default
> desktop/server value and a default "tiny" value).  You can have this
> CONFIG_TINY or whatever, but then we should also provide the ability to tweak
> the values exactly how we want in a specific application.  The tweaking
> options can be buried under advanced kernel options with the appropriate
> disclaimers about shooting yourself in the foot.
 
That is how I think it should be done, yes.

- Arnaldo

Re: The end of embedded Linux?

[Alan Cox]

On Tue, 2002-10-08 at 00:01, Arnaldo Carvalho de Melo wrote:
to tweak
> > the values exactly how we want in a specific application.  The tweaking
> > options can be buried under advanced kernel options with the appropriate
> > disclaimers about shooting yourself in the foot.
>  
> That is how I think it should be done, yes.

Submitting dprintk() seems like a great starting point. I've also got
some patches in the archive someone sent that allows you to configure
out the #! exec stuff

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Tue, Oct 08, 2002 at 12:23:27AM +0100, Alan Cox escreveu:
> On Tue, 2002-10-08 at 00:01, Arnaldo Carvalho de Melo wrote:
> to tweak
> > > the values exactly how we want in a specific application.  The tweaking
> > > options can be buried under advanced kernel options with the appropriate
> > > disclaimers about shooting yourself in the foot.
> >  
> > That is how I think it should be done, yes.
> 
> Submitting dprintk() seems like a great starting point. I've also got
> some patches in the archive someone sent that allows you to configure
> out the #! exec stuff

Ok, will do that in the next days.

- Arnaldo (buried alive in cleanups)

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Mon, Oct 07, 2002 at 08:47:33PM -0300, Arnaldo C. Melo escreveu:
> Em Tue, Oct 08, 2002 at 12:23:27AM +0100, Alan Cox escreveu:
> > On Tue, 2002-10-08 at 00:01, Arnaldo Carvalho de Melo wrote:
> > to tweak
> > > > the values exactly how we want in a specific application.  The tweaking
> > > > options can be buried under advanced kernel options with the appropriate
> > > > disclaimers about shooting yourself in the foot.
 
> > > That is how I think it should be done, yes.
 
> > Submitting dprintk() seems like a great starting point. I've also got
> > some patches in the archive someone sent that allows you to configure
> > out the #! exec stuff
 
> Ok, will do that in the next days.
 

Ok, so what do you think of a include/linux/debug.h

and a CONFIG_DEBUG_MESSAGES

and in debug.h:

#ifdef CONFIG_DEBUG_MESSAGES
#define dprintk printk(KERN_DEBUG.....) /* find the best of the 1001 variants
                                          already in the tree */
#else
#define dprintk(.....)
#endif

and in drivers currently using dprintk (and in others that want to start using
it instead of homebrew equivalent macros):

#include <linux/debug.h>

...happily use dprintk...

and the default kernel config would just disable (or other sane default agreed
here) so, assuming it is disabled it'd be easy to enable it on a per source
code file, doing this:

#include <other_includes>
#define CONFIG_DEBUG_MESSAGES
#include <linux/debug.h>

Would this be acceptable? Ah, all of the above is quickly hacked pseudocode 8)

- Arnaldo

Re: The end of embedded Linux?

[Xcytame@yahoo.es]

As you said in a e-mail before, and also mentioned in the very
interesting book "Linux Device Drivers"  By Alessandro Rubini & Jonathan
Corbet , things should be done in the most simplest way. The reasons are
both avoid rewriting of code in order to optimize it, and also when
things are small you can control them  better and therefore your
hardware is better accesed.

Sorry about this little note from a kernel newbie to all the developers
out there if it makes you feel offended in some way.

> Submitting dprintk() seems like a great starting point. I've also got
> some patches in the archive someone sent that allows you to configure
> out the #! exec stuff
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

Re: The end of embedded Linux?

[Ian Molton]

On Sat, 5 Oct 2002 13:52:38 -0700 (PDT)
Gigi Duru <giduru@yahoo.com> wrote:

> 
> Now thats some advice from a kernel hacker... You
> really don't seem to care too much about embedded, do
> you? 

I do. I have to. Im porting the Linux kernel to the arm26 architecture
(repairing the long dead port by Russell King).

Even on these tiny, 15 year old machines, the kernel will EASILY fit
into their ROMs, with bags of room to spare.

The biggest machine EVER of this type has only 16 MB of RAM. most have
2-4MB. Some even have MFM harddiscs.

Re: The end of embedded Linux?

[jbradford]

> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed). 
> 
> Now try to put in some useful stuff and the
> _compressed_ image will cheerfully approach 1MB. Where
> are the days when a 200KB kernel would be fully
> equipped?

That is completely wrong.  I run 2.5.40 on a swapless 8MB 486, and can happily use BASH, Apache with PHP support, Lynx, and JED, all at a useful speed.  I also happily run 2.5.40 on another 4MB RAM 486, with 20MB of swap, and do useful work on it.  If you don't believe me, come to Linux Expo UK next week and see for yourself.

> I know you guys are struggling to bring "world class
> VM & IO" to Linux, going for SMPs and other big toys,
> but you are about to lose what you already have: the
> embedded market.

No, the 2.0.x and 2.2.x kernels are actively maintained.

> As an embedded developer, I can't stand bloat. I think
> an OS designer should feel the same, and develop in a
> fully modular and configurable manner, going for both
> speed and size. For a long time I've felt that Linux
> has got it right, but lately I'm not that sure
> anymore. 

Nobody is forcing you to move to 2.4.x from older versions - current code is being actively backported to them.

John.

Re: The end of embedded Linux?

[Oliver Xymoron]

On Sat, Oct 05, 2002 at 12:36:50PM -0700, Gigi Duru wrote:
> 
> I know you guys are struggling to bring "world class
> VM & IO" to Linux, going for SMPs and other big toys,
> but you are about to lose what you already have: the
> embedded market.

It's still plenty small enough for many many embedded uses and most
people are more than happy with it. The reason that it's not even smaller
is no one has stepped forward to do the trimming. It's easy enough to
do, but we can only assume from the fact that no one's done so is that
it's really not that important.

If you think it's important, either make it happen or pay someone else
to make it happen. 

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Re: The end of embedded Linux?

[Arnaldo Carvalho de Melo]

Em Sat, Oct 05, 2002 at 05:23:06PM -0500, Oliver Xymoron escreveu:
> On Sat, Oct 05, 2002 at 12:36:50PM -0700, Gigi Duru wrote:

> > I know you guys are struggling to bring "world class VM & IO" to Linux,
> > going for SMPs and other big toys, but you are about to lose what you
> > already have: the embedded market.
 
> It's still plenty small enough for many many embedded uses and most people
> are more than happy with it. The reason that it's not even smaller is no one
> has stepped forward to do the trimming. It's easy enough to do, but we can
> only assume from the fact that no one's done so is that it's really not that
> important.
 
> If you think it's important, either make it happen or pay someone else to
> make it happen. 

I've been thinking about working on a CONFIG_TINY for ages and would love to
have somebody else beat me to do this, as currently I'm too busy saving old
network protocols and with a backlog of patches for general network
infrastructure (clean up include/linux/skbuff.h so that it doesn't have any
reference to specific protocols, in the same way that I did for
include/net/sock.h) and macroising access to stats in tcp/ip so that we can
be preempt friendly.

I have also __initstr patches to free more memory after boot by moving the
strings in __init functions to .data.init section that will help with
embedded stuff as well. Some of the strings are passed to things like
register_chrdev and would require changes in those register functions to
copy the string passed as it will be freed after boot, etc.

- Arnaldo

Re: The end of embedded Linux?

[Andre Hedrick]

Gigi Duru,

You just found your consultant, Arnaldo Carvalho de Melo!
Now issue a contract for deliverables on an opensource solution and become
a hero for embedded.

Andre Hedrick
LAD Storage Consulting Group

On Sat, 5 Oct 2002, Arnaldo Carvalho de Melo wrote:

> Em Sat, Oct 05, 2002 at 05:23:06PM -0500, Oliver Xymoron escreveu:
> > On Sat, Oct 05, 2002 at 12:36:50PM -0700, Gigi Duru wrote:
> 
> > > I know you guys are struggling to bring "world class VM & IO" to Linux,
> > > going for SMPs and other big toys, but you are about to lose what you
> > > already have: the embedded market.
>  
> > It's still plenty small enough for many many embedded uses and most people
> > are more than happy with it. The reason that it's not even smaller is no one
> > has stepped forward to do the trimming. It's easy enough to do, but we can
> > only assume from the fact that no one's done so is that it's really not that
> > important.
>  
> > If you think it's important, either make it happen or pay someone else to
> > make it happen. 
> 
> I've been thinking about working on a CONFIG_TINY for ages and would love to
> have somebody else beat me to do this, as currently I'm too busy saving old
> network protocols and with a backlog of patches for general network
> infrastructure (clean up include/linux/skbuff.h so that it doesn't have any
> reference to specific protocols, in the same way that I did for
> include/net/sock.h) and macroising access to stats in tcp/ip so that we can
> be preempt friendly.
> 
> I have also __initstr patches to free more memory after boot by moving the
> strings in __init functions to .data.init section that will help with
> embedded stuff as well. Some of the strings are passed to things like
> register_chrdev and would require changes in those register functions to
> copy the string passed as it will be freed after boot, etc.
> 
> - Arnaldo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: The end of embedded Linux?

[Daniel Phillips]

On Sunday 06 October 2002 00:23, Oliver Xymoron wrote:
> On Sat, Oct 05, 2002 at 12:36:50PM -0700, Gigi Duru wrote:
> > 
> > I know you guys are struggling to bring "world class
> > VM & IO" to Linux, going for SMPs and other big toys,
> > but you are about to lose what you already have: the
> > embedded market.
> 
> It's still plenty small enough for many many embedded uses and most
> people are more than happy with it. The reason that it's not even smaller
> is no one has stepped forward to do the trimming. It's easy enough to
> do, but we can only assume from the fact that no one's done so is that
> it's really not that important.

It has more to do with the fact that nobody has been using 2.5 until
recently, because of bio and ide breakage.  It's a big mistake to
dismiss his request as unimportant.  However, I strongly agree with the
idea that interested people/companies should put up hard cash to get
this work done.

-- 
Daniel

Re: The end of embedded Linux?

[William Lee Irwin III]

On Sat, Oct 12, 2002 at 06:01:42AM +0200, Daniel Phillips wrote:
> It has more to do with the fact that nobody has been using 2.5 until
> recently, because of bio and ide breakage.  It's a big mistake to
> dismiss his request as unimportant.  However, I strongly agree with the
> idea that interested people/companies should put up hard cash to get
> this work done.

This hard cash is already being spent, here and now, and it is being
spent on programmer salaries and the equipment for them to work on.

Believe it or not, the businesses shelling out paychecks in our
directions are not charities and as such the work we do for them must
be directed to meet their needs. The reality is that the technical
knowledge programmers have of kernel (and hardware, and app) mechanics
is relayed in some form, no matter how dumbed down, up the food chain,
and if concerns are expressed and action taken by those working in the
field they will either be heeded by the effective organizations or
dismissed by those doomed to failure.

This is work, even if we ourselves would play in the same manner. If
effort, contributions, and visible benefits are not provided,
demonstrated, and delivered in a timely fashion, you -will- lose out,
and your own needs and those of your organization will not be addressed.

Bill

P.S.: This is not a flame.

Re: The end of embedded Linux?

[Rik van Riel]

On Sat, 5 Oct 2002, Gigi Duru wrote:

> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed).
>
> Now try to put in some useful stuff and the
> _compressed_ image will cheerfully approach 1MB.

> I know you guys are struggling to bring "world class
> VM & IO" to Linux,

The 270 kB kernel image still includes the VM, so it's
probably something else that is bloating your kernel.

It would be useful to figure out exactly what so we can
fix it before 2.6 is released.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org

Re: The end of embedded Linux?

[Zwane Mwaikambo]

On Sat, 5 Oct 2002, Gigi Duru wrote:

> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed). 

You didn't configure it properly...

http://function.linuxpower.ca/dmesg-386-2.4.txt

	Zwane
-- 
function.linuxpower.ca

Re: The end of embedded Linux?

[William Lee Irwin III]

On Sat, 5 Oct 2002, Gigi Duru wrote:
>> Trivial experiment: configure out _ALL_ the options on
>> 2.5.38 and build bzImage. My result? A totally useless
>> 270KB kernel (compressed). 

On Sat, Oct 05, 2002 at 08:41:25PM -0400, Zwane Mwaikambo wrote:
> You didn't configure it properly...
> http://function.linuxpower.ca/dmesg-386-2.4.txt
> 	Zwane

I actually find this relatively disturbing:

Memory: 2584k/4352k available (881k kernel code, 1380k reserved, 171k data, 56k
init, 0k hi)

To truly scale this far downward finding ways to use less than 40% of
RAM on things allocated at or before boot-time seems necessary,
especially trimming down that 881KB.

I'll have to apologize that it's unlikely I'll be able to take any
direct action toward addressing this problem as my focus is elsewhere,
but I consider this a valid and even important concern.


Bill

Re: The end of embedded Linux?

[Zwane Mwaikambo]

On Sat, 5 Oct 2002, William Lee Irwin III wrote:

> I actually find this relatively disturbing:
> 
> Memory: 2584k/4352k available (881k kernel code, 1380k reserved, 171k data, 56k
> init, 0k hi)
> 
> To truly scale this far downward finding ways to use less than 40% of
> RAM on things allocated at or before boot-time seems necessary,
> especially trimming down that 881KB.
> 
> I'll have to apologize that it's unlikely I'll be able to take any
> direct action toward addressing this problem as my focus is elsewhere,
> but I consider this a valid and even important concern.

Indeed, the box in question didn't require any more memory for its 
application so that somewhat bloated kernel was sufficient. I could have 
saved a bit more by removing a lot of drivers, e.g. IDE

	Zwane

-- 
function.linuxpower.ca

Re: The end of embedded Linux?

[William Lee Irwin III]

On Sat, Oct 05, 2002 at 12:36:50PM -0700, Gigi Duru wrote:
> As an embedded developer, I can't stand bloat. I think
> an OS designer should feel the same, and develop in a
> fully modular and configurable manner, going for both
> speed and size. For a long time I've felt that Linux
> has got it right, but lately I'm not that sure
> anymore. 

Identifying the portions of the kernel with the largest codesize and/or
static data size would help other developers accommodate your needs.
Similarly for dynamic boot-time and runtime allocations.

Even better, if you yourself took action to correct this regression it
would be as welcome as any other Linux development activity.


Bill

Re: The end of embedded Linux?

[Aaron Lehmann]

On Sat, Oct 05, 2002 at 05:44:38PM -0700, William Lee Irwin III wrote:
> Even better, if you yourself took action to correct this regression it
> would be as welcome as any other Linux development activity.

It seems to me that what would be even better than patches is a
general awareness of bloat and an attitude discouraging adding any
bloat whatsoever to the base kernel. Proactive bloat prevention is a
much better solution than asking embedded developers to send fixes
whenever someone increases the size of the core kernel unnecessarily.
Let's prevent a Mozilla here.

Re: The end of embedded Linux?

[William Lee Irwin III]

On Sun, Oct 06, 2002 at 03:24:33PM -0700, Aaron Lehmann wrote:
> It seems to me that what would be even better than patches is a
> general awareness of bloat and an attitude discouraging adding any
> bloat whatsoever to the base kernel. Proactive bloat prevention is a
> much better solution than asking embedded developers to send fixes
> whenever someone increases the size of the core kernel unnecessarily.
> Let's prevent a Mozilla here.

Beware here. The kinds of time/space tradeoffs important to you are
absolutely *not* apparent from "normal" testing. -You- are the embedded
developers and users. The onus is on you to find space consumption
problems visible in embedded environments.

Yes, I am highly concerned about space. But that is not enough to
address your needs. My space consumption concerns are largely
ZONE_NORMAL consumption and data structure proliferation. This is a
very different matter from boottime and absolute space consumption.

You will not be serviced by my own efforts to combat space consumption.
You must take action yourselves to provide both problem reports and
code to address these needs. But this is a valid activity and a
worthwhile direction to pursue. If you take action, it will be heeded.

Bill

Re: The end of embedded Linux?

[Andre Hedrick]

On Sun, 6 Oct 2002, Aaron Lehmann wrote:

> On Sat, Oct 05, 2002 at 05:44:38PM -0700, William Lee Irwin III wrote:
> > Even better, if you yourself took action to correct this regression it
> > would be as welcome as any other Linux development activity.
> 
> It seems to me that what would be even better than patches is a
> general awareness of bloat and an attitude discouraging adding any
> bloat whatsoever to the base kernel. Proactive bloat prevention is a
> much better solution than asking embedded developers to send fixes
> whenever someone increases the size of the core kernel unnecessarily.
> Let's prevent a Mozilla here.

So lemme guess, you calling "embedded" == "Mozilla" ?
This is the reason those developers do not submit patches and fixes?
Under that rational, why not unplug the support for the embedded archs?
This follows your line of reasoning perfectly?
So you are proposing to unbloat the kernel by not fixing and patch archs
which embedded people depend on?
Thus letting then rot and die then final removal of baggage?

Sarcasim and Humor,

Andre Hedrick
LAD Storage Consulting Group

Re: The end of embedded Linux?

[Andre Hedrick]

Aaron,

Erik A (code-poet) just informed me that I misread the to/from line and so
I mistakenly replyed to you with the "sarcasim and humor".  I apologize
for my dyslexia and for shooting off the hip to quick thinking it was
"Gigi Duru" making the comments.  Again, apology for not maintaining
site-lock on humor-cannon.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: The end of embedded Linux?

[Jan-Benedict Glaw]

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

On Sat, 2002-10-05 12:36:50 -0700, Gigi Duru <giduru@yahoo.com>
wrote in message <20021005193650.17795.qmail@web13202.mail.yahoo.com>:
> Trivial experiment: configure out _ALL_ the options on
> 2.5.38 and build bzImage. My result? A totally useless
> 270KB kernel (compressed). 

Well, from time to time, there are patches/suggestions on how to get the
footprint smaller. If you do embedded work, you're oftenly not
interestes in all the kernel's printk() messages. I have sent around
some patch some time ago which (in kernel.h) simply #define's a printk
to do nothing. Then, rename original printk() to your_real_printk() and
convert _really_ important printk() calls to your_real_printk(), eg.
Oops messages:-)

On a small kernel, you can save 50..100 KB (in the bzImage)! That's a
lot; think about uncompressed size!

And - there are other options as well. Just _look_ at the code, _think_
about it and (possibly) _change_ it if needed (and publish the changes
so that they're available to others).

MfG, JBG

-- 
   - Eine Freie Meinung in einem Freien Kopf für
   - einen Freien Staat voll Freier Bürger
   						Gegen Zensur im Internet
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

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