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
Gigi Duru <[email protected]> :
[...]
> 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
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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 [email protected]
> 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
> 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.
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 <[email protected]> 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
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
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.."
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
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: [email protected] [email protected]
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
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
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: [email protected] [email protected]
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
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
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 <[email protected]> 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
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 <[email protected]> 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> [email protected]/[email protected]/[email protected] __________________________
> . . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
From: Gigi Duru <[email protected]>
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.
On Sat, 5 Oct 2002 13:52:38 -0700 (PDT)
Gigi Duru <[email protected]> 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.
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
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 <[email protected]> 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
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.
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
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
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 <[email protected]> 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
>
--- Mark Hahn <[email protected]> wrote:
> > * now, 2.6 (or whatever) seems like a very bad
> choice
> > for us.
>
> have you actually tried?
didn't need to. already told you what size the bare
bones 2.5 is, and I doubt it will get any smaller. au
contraire...
>
> > Why are old versions being actively maintained
> anyway?
>
> because there are old systems where it makes sense
> to avoid upgrades.
>
> > Isn't that a realization that those old versions
> are
> > better suited for some tasks than the new one? Why
>
> no, it's not.
>
oh, but it is! even using your own explanation: why
does it make sense to avoid upgrades on those old
systems? because those are better without, otherwise
it would make sense to upgrade. so the old stuff
performs better (whatever that means) on those old
systems than the new one. q.e.d.
not to mention that "active maintenance" of the old
kernels doesn't really save you from upgrades... just
upgrades to the "new and improved" kernel...
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
On Sun, 6 Oct 2002, Gigi Duru wrote:
> --- Mark Hahn <[email protected]> wrote:
> > have you actually tried?
>
> didn't need to. already told you what size the bare
> bones 2.5 is, and I doubt it will get any smaller. au
> contraire...
Are you, or are you not willing to help improve 2.5 to
satisfy your goals ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: [email protected] [email protected]
Em Mon, Oct 07, 2002 at 02:42:20AM -0300, Rik van Riel escreveu:
> On Sun, 6 Oct 2002, Gigi Duru wrote:
> > --- Mark Hahn <[email protected]> wrote:
> > > have you actually tried?
> > didn't need to. already told you what size the bare bones 2.5 is, and I
> > doubt it will get any smaller. au contraire...
> Are you, or are you not willing to help improve 2.5 to
> satisfy your goals ?
Frankly, talking like he is talking it seems that he is baiting somebody else
to do the work, nevermind, I'll try in the next days to do some work on that,
I expect that he reports the results here, at least 8)
- Arnaldo
On Sat, 2002-10-05 12:36:50 -0700, Gigi Duru <[email protected]>
wrote in message <[email protected]>:
> 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 . [email protected] . +49-172-7608481
-- New APT-Proxy written in shell script --
http://lug-owl.de/~jbglaw/software/ap2/
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 [email protected]
> 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 : [email protected]
__________________________
From: "" <[email protected]>
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
[email protected]
Le lun 07/10/2002 ? 12:06, [email protected] 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
He probably means that some features are unnecesary and, are threatening to turn the kernel into bloatware, I cant talk though, I use IE 3 under wine...
Cheers, Dean.
On Sun, 6 Oct 2002 18:33:10 -0700 (PDT) Andre Hedrick <[email protected]> wrote:
On Sun, 6 Oct 2002, Gigi Duru wrote:
> --- Mark Hahn <[email protected]> wrote:
> > > * now, 2.6 (or whatever) seems like a very bad
> > choice
> > > for us.
> >
> > have you actually tried?
>
> didn't need to. already told you what size the bare
> bones 2.5 is, and I doubt it will get any smaller. au
> contraire...
>
> >
> > > Why are old versions being actively maintained
> > anyway?
> >
> > because there are old systems where it makes sense
> > to avoid upgrades.
> >
> > > Isn't that a realization that those old versions
> > are
> > > better suited for some tasks than the new one? Why
> >
> > no, it's not.
> >
>
> oh, but it is! even using your own explanation: why
> does it make sense to avoid upgrades on those old
> systems? because those are better without, otherwise
> it would make sense to upgrade. so the old stuff
> performs better (whatever that means) on those old
> systems than the new one. q.e.d.
>
> not to mention that "active maintenance" of the old
> kernels doesn't really save you from upgrades... just
> upgrades to the "new and improved" kernel...
>
We use 2.4.18 on embedded systems. 2.4.19 has some new
problems (The reported select() on network I/O, being
one of them). If 2.5 becomes "stable", I should be able
to use it as long as it can be booted off a 1.2 MB floppy.
Our embedded systems don't boot off floppies, but my
BIOS NVRAM-virtual disk emulates a floppy so I don't
have any problems with compatibility. We don't do any
"execute-in-place" stuff. Linux "thinks" it was booted
off a floppy and the executables run off a RAM Disk. This
makes development and maintenance easy and allows untouched
kernels to be used.
There are absolutely no changes to the kernel. We use a
lot of modules, many (most) of which would never exist in
a Linux distribution so we are not witholding anything to,
as some say, screw, anybody.
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.
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
From: "Richard B. Johnson" <[email protected]>
Date: Mon, 7 Oct 2002 08:04:06 -0400 (EDT)
We use 2.4.18 on embedded systems. 2.4.19 has some new
problems (The reported select() on network I/O, being
one of them).
Could you report this bug to linux-net and netdev?
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: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
On Mon, 7 Oct 2002, David S. Miller wrote:
> From: "Richard B. Johnson" <[email protected]>
> Date: Mon, 7 Oct 2002 08:04:06 -0400 (EDT)
>
> We use 2.4.18 on embedded systems. 2.4.19 has some new
> problems (The reported select() on network I/O, being
> one of them).
>
> Could you report this bug to linux-net and netdev?
Okay. I just forwarded the last bug-report to linux-net. I don't
know what netdev is???
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.
From: "Richard B. Johnson" <[email protected]>
Date: Mon, 7 Oct 2002 08:32:55 -0400 (EDT)
On Mon, 7 Oct 2002, David S. Miller wrote:
> Could you report this bug to linux-net and netdev?
Okay. I just forwarded the last bug-report to linux-net. I don't
know what netdev is???
[email protected]
On Mon, 2002-10-07 at 01:38, Gigi Duru wrote:
> --- Mark Hahn <[email protected]> wrote:
> > have you actually tried?
> didn't need to. already told you what size the bare
> bones 2.5 is, and I doubt it will get any smaller. au
> contraire...
But you didn't post your .config file, what options you
had enabled or disabled, what your hardwsre platform is,
an analysis of where the bloat is taking place, or any
other thing that would allow for anyone here to help you.
You've also been told that the VM is in that kernel (and
from what I understand it can't be removed) so you're using
a kernel which almost definitely isn't configured properly
for your hardware platform.
The GPL issue is important, but that's not the issue here :
LKML helps those who help themselves. All you're doing is
whining and complaining, so I'm left with no reason NOT to
killfile you.
Dana Lacoste
Ottawa, Canada
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
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
From: Nicolas Pitre <[email protected]>
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?
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
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
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
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
Suggesting a entire new sub config option seems wise, in this way not only arm ipaqs could benefit, so could 386s , whole series of rejuvinated computers, become useful.
Cheers, Dean.
On Mon, 7 Oct 2002 09:22:12 -0700 Matt Porter <[email protected]> wrote:
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.
On Mon, 7 Oct 2002, David S. Miller wrote:
> From: Nicolas Pitre <[email protected]>
> 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
On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> From: Nicolas Pitre <[email protected]>
> 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
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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/
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, [email protected] 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 [email protected]
> 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 : [email protected]
__________________________
From: "" <[email protected]>
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.
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 <[email protected]>
> > 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
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 <[email protected]>
> > > 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.
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 <[email protected]>
> > > 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 [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
On Mon, 2002-10-07 at 18:15, [email protected] 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!
Then shouldn't the thing thats different from the norm be programmed into a header file which contains how certain functions should be handled differently, which can be dynamically switched by a config option?
Cheers, Dean.
On Mon, 7 Oct 2002 20:11:11 +0100 Russell King <[email protected]> wrote:
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 <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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
--- Rob Landley <[email protected]> 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
Alan Cox <[email protected]> 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 <[email protected]> http://www.weinigel.se
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
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
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
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
this is a bug report, not a feature request ;)
--- Mark Mielke <[email protected]> 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 <[email protected]> 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 [email protected]
> > More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> [email protected]/[email protected]/[email protected]
> __________________________
> . . _ ._ . . .__ . . ._. .__ . . . .__
> | 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
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
From: <[email protected]>
Date: Mon, 7 Oct 2002 21:04:29 +0100
Then shouldn't the thing thats different from the norm be programmed into a header file which contains how certain functions should be handled differently, which can be dynamically switched by a config option?
If I gave you a dollar, would you go out and buy some newlines
to use in future emails?
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
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
Em Mon, Oct 07, 2002 at 06:20:46PM +0100, [email protected] 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
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
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
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)
On Mon, Oct 07, 2002 at 04:01:46PM -0700, David S. Miller wrote:
> From: <[email protected]>
> Date: Mon, 7 Oct 2002 21:04:29 +0100
>
> Then shouldn't the thing thats different from the norm be programmed into a header file which contains how certain functions should be handled differently, which can be dynamically switched by a config option?
>
> If I gave you a dollar, would you go out and buy some newlines
> to use in future emails?
Maybe he could exchange the mime headers for newlines if he
put his comments at the end where they belong.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
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 [email protected]
> 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
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.
On Monday 07 October 2002 05:56 pm, Gigi Duru wrote:
> --- Rob Landley <[email protected]> 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
Integral support for TinyX would be nice(http://www.handhelds.org).
Cheers, Dean.
On Mon, 7 Oct 2002 15:50:43 -0400 Rob Landley <[email protected]> wrote:
limitation of mailer.
Cheers, Dean.
On Mon, 7 Oct 2002 17:10:50 -0700 jw schultz <[email protected]> wrote:
On 7 Oct 2002, at 21:22, Alan Cox wrote:
> On Mon, 2002-10-07 at 18:15, [email protected] 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 : [email protected]
__________________________
On Tue, 2002-10-08 at 11:11, [email protected] 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
On Tue, Oct 08, 2002 at 11:11:44AM +0100, [email protected] 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
On Tue, Oct 08, 2002 at 11:11:44AM +0100, [email protected] 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: [email protected]
Remember Cernan and Schmitt
> 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.
On Tue, 8 Oct 2002 [email protected] 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.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, October 08, 2002 5:36 AM
> To: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: The end of embedded Linux?
>
>
> Integral support for TinyX would be nice(http://www.handhelds.org).
The tiny xserver is maintained on http://www.xfree86.org. It does not require any particular kernel support.
-Jamey
> > > 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.
If its a personal project, use nothing, not even RMS would care[probably].
Cheers, Dean.
On Tue, 8 Oct 2002 04:27:19 -0700 jw schultz <[email protected]> wrote:
On Mon, 7 Oct 2002, Rob Landley wrote:
> On Monday 07 October 2002 05:56 pm, Gigi Duru wrote:
> > --- Rob Landley <[email protected]> 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.
On Tue, 8 Oct 2002 [email protected] wrote:
> limitation of mailer.
Are you emailing from your TV set top box!?
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
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
[email protected]
This is Linux Country. On a quiet night, you can hear Windows reboot.
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 [email protected] wrote:
> Date: Tue, 8 Oct 2002 11:11:44 +0100
> From: [email protected]
> To: Alan Cox <[email protected]>
> Cc: [email protected]
> 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, [email protected] 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 : [email protected]
> __________________________
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Nobody said if you GPL it they would have to put it in the kernel...
Cheers, Dean.
On Tue, 8 Oct 2002 08:52:49 -0700 (PDT) David Lang <[email protected]> wrote:
correct, also nobody said it would be accepted in the kernel even they GPL
it, but the in message I responded to Simon commented that he didn't see
how it was possible to make a module that wasn't GPL, and therefor he was
looking at having to use a different OS becouse he didn't want to GPL his
modules. I was just pointing out that modules that don't use the GPL-only
symbols don't have to be GPL (much as we would like them to be)
David Lang
On Tue, 8 Oct 2002 [email protected] wrote:
> Date: Tue, 8 Oct 2002 17:32:25 +0100
> From: [email protected]
> To: [email protected], [email protected], [email protected],
> [email protected]
> Subject: RE:Re: The end of embedded Linux?
>
> Nobody said if you GPL it they would have to put it in the kernel...
>
> Cheers, Dean.
>
> On Tue, 8 Oct 2002 08:52:49 -0700 (PDT) David Lang <[email protected]> wrote:
>
>
From: <[email protected]>
Date: Tue, 8 Oct 2002 10:51:40 +0100
limitation of mailer.
I know, it must be really hard to type carriage return
occaisionally.
From: Alan Cox <[email protected]>
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.
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 <[email protected]> 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
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
yep. i prefer pressing enter though. lol.
Cheers, Dean.
On Tue, 08 Oct 2002 13:00:14 -0700 (PDT) "David S. Miller" <[email protected]> wrote:
yeah!
Cheers, Dean.
On Tue, 8 Oct 2002 10:22:03 -0400 (EDT) Gerhard Mack <[email protected]> wrote:
On Tue, 2002-10-08 at 21:04, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> 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
From: Alan Cox <[email protected]>
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.
I dunno what you have but here in the uk, we like to be arseholes[joke], no then... My bandwidth bills are kept low, and I prefer the sofa to that seat thing I have, I go online to download/send patches, and its ?728 cheaper.
Cheers, Dean.
On Tue, 8 Oct 2002 19:55:20 -0300 (BRT) Rik van Riel <[email protected]> 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?
mvg,
Alex
[email protected] 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
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
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,
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
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.
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
On Wed, 9 Oct 2002 09:37:25 +0200
Alexander Kellett <[email protected]> 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>
you might as well install freedos. lol
Cheers, Dean.
On Wed, 9 Oct 2002 13:42:07 +0100 Ian Molton <[email protected]> wrote:
oops didnt see that..
Cheers, Dean.
On 09 Oct 2002 12:49:48 +0100 Alan Cox <[email protected]> wrote:
On Wed, Oct 09, 2002 at 03:28:32PM +0100, [email protected] wrote:
> With-the-way-your-email-client-doesn't-quote-I've-got-no-clue-who wrote:
>>
>> Its called FreeDOS,
>
> oops didnt see that..
Pretty useless to reply to such post when you break threading entirely.
Only through reordering by author and by date and figuring out what your
previous post said I've got an idea what you're meaning to say with this
answer.
Regards,
Filip
--
Win32 has many known work arounds. For example, Linux.
>
> 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.
On Wed, Oct 09, 2002 at 05:14:27PM +0200, Filip Van Raemdonck wrote:
> On Wed, Oct 09, 2002 at 03:28:32PM +0100, [email protected] wrote:
> > With-the-way-your-email-client-doesn't-quote-I've-got-no-clue-who wrote:
> >>
> >> Its called FreeDOS,
> >
> > oops didnt see that..
>
> Pretty useless to reply to such post when you break threading entirely.
> Only through reordering by author and by date and figuring out what your
> previous post said I've got an idea what you're meaning to say with this
> answer.
>
>
> Regards,
>
> Filip
>
We are supposed to blame Liberate TVMail 2.6 for all the bad
practices of Hell.Surfers. It isn't his fault he uses a
product that breaks threads, replies by attachment nor the
fact that he doesn't press the carriage return (enter key).
After all this way he can read his email on TV while reclining on
plush cushions.
</sarcasm>
Actually i had no trouble telling that it was Alan he quoted.
If you turn off header filtering you will see that the
complete mail header (including delivery routing info) is
included in the attachment.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Wed, Oct 09, 2002 at 08:17:45PM +0100, [email protected] 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: [email protected]
Remember Cernan and Schmitt
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
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
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.
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
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.
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
such projects already exist, RULE for instance.
Cheers, Dean.
On Wed, 9 Oct 2002 16:49:21 -0700 jw schultz <[email protected]> wrote:
brilliantly this summerises every problem, theres no enter.. am i really replying by attachment...?
Cheers, Dean.
On Wed, 9 Oct 2002 16:32:57 -0700 jw schultz <[email protected]> wrote:
On Sat, 12 Oct 2002 [email protected] wrote:
> brilliantly this summerises every problem, theres no enter.. am i really
> replying by attachment...?
Yes. The output of your mail program is so bad that I'm
seriously pondering killfiling all of cwctv.net, preferably
at the SMTP level.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
> On Sat, 12 Oct 2002 [email protected] wrote:
>
> > brilliantly this summerises every problem, theres no enter.. am i really
> > replying by attachment...?
>
> Yes. The output of your mail program is so bad that I'm
> seriously pondering killfiling all of cwctv.net, preferably
> at the SMTP level.
However bad the output of his mail program is, what is even more
irritating is the constant discussion of it on this list.
Dean, couldn't you just delete the superflous headers that it
generates when you reply? I don't personally care about the quoting
style.
Please, everybody, read the FAQ. This is supposed to be a technical
discussion list. The odd funny comment, or discussion related to
kernel development is appropriate, but flamewars about Bitkeeper
licensing, or the mail application that somebody uses are not.
Please _don't_ post to the list just to get 'street cred', and make
yourself look like a 1337 k3rn37 h@x0r. It doesn't.
For example, I take the time to mail people who send a vague bug
report to the list and don't direct it to a particular developer, to
tell them:
* Who they should address it to
* What info they should include
I _don't_ CC the list on every one of them, just so that people will
think, "Aha! John is cool.".
John.
Alan Cox <[email protected]> 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
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