[uClinux-dev] A pervasive problem...

Tom Walsh tom at cyberiansoftware.com
Sat Nov 17 12:40:49 EST 2001

Dave_Pfaltzgraff at patapsco.com wrote:
> Now, I find that John Jeffers is on a similar quest. I am very pleased that he
> found my contribution. However, I find that the basic structure of the make
> system has changed making my contribution (5) obsolete. I guess the mistake I
> made was in not fully identifying the distribution (20010529) that I based my
> studies on. However, I see that his distribution (20010622) is only a month
> newer. All this can be learned after a post to this group brings the message "
> Frankly, this has changed :-)"
> >from my viewpoint, I can only ask questions:
>   1. Why was such a radical (apparently) change made in such a short time?

You left out one word there, it should have read: "Why was such an
important, radical (apparently) change made".  Those distros that Greg
have been making are signifigantly more usefull than the hodge-podge
that we had before!  We actually have apps that compile under both
kernels, we have uClibc libs that actually link to applications!

>   2. Why was there no documentation to support this?
>   3. Why didn't anyone correct me when I submitted my document to this list a
> mere month ago?
>   4. Etc...

Basically it comes down to this, most of us here on the list volunteer
our time to answer whatever questions we can.  To my knowledge, there
are no formal support personell here.  We do this because we love it!  I
live to code, this is relaxation for me and it is fun for me to do.  I
am not a hobbyist, I tend to dive into code, start hacking it apart, and
eventually I begin to see how it flows.  I have worked this way for
years, mainly as the documentation I did get was usually suspect anyhow.

Believe me when I tell you this, there have been a lot of private
discussions regarding what you point out here..  Not everyone is happy
with the state of affairs with uClinux, at this point, there is not much
that we are able to do..

> I'm not asking these questions to say that the changes are wrong or that anyone
> is in the wrong for doing what they did. In fact the first question arises
> because the evolution of software methodologies is a personal interest. The key
> issue here can be summarized in the following issues which I consider to be
> important points:
>   1. The Linux community claims that they want "Linux everywhere"
>   2. There are many of us who like Linux for a myriad of reasons
>   3. Most of us are new to the *nix environment
>   4. Without any introductory documentation, it's only natural that we have
> seemingly simple questions.
>   5. To be rebuffed and told to "read the source" without direction as to where
> the introduction (much less chapter 1) can be found, only alienates us.

I don't care about "the linux community", I am a systems engineer and
enjoy helping other engineers in getting their "toys" up and running. 
As for myself, I encountered linux a little over four years ago, no
prior experience with un*x.  I spent a solid two years working at un*x
until I felt comfortable with the progress I made understanding it.

I had spent 8 months learning how uClinux operates.  This I did by
designing a "throw away" to implement uClinux on it.  That design had no
commercial value, but it did teach me: ethernet controllers, Touch
Panels, and how to modify uClinux to run on my hardware.

Why did I spend all that time learning linux?  Because I realized the
profound implications of having the source code the o/s and sharing with
other people like myself!  If linux disappears next week, there *will*
be something to replace it, "it" is not going away.  The basic structure
of linux (internals) is going to be there in the next generation o/s. 
So, my advice to you is to start reading the source, gain knowledge in
how this thing works, it will be time well spent.

> If this attitude perpetuates, we will fall back on other O/Ss that do provide
> reasonable documentation and then where will Linux be?
> If we are to grow as a community, we must take the time to document what we do.
> This is not meant to imply that we need full module by module flowcharts, etc.
> Look at how useful Rubini's book is without that level of detail. His book
> provides the fundamentals that give the reader direction in his pursuit of
> understanding. Without some very basic documentation, we will find, as Bruce
> did, that history repeats itself in that any newbie must repeat what all the
> others before him have done. Namely, stumble through seemingly arcane code until
> the pieces start to fall together. (Anyone who does not consider 'make' arcane
> must be intimately familiar with it!) How many potential members have we lost
> because they were never able to find this connection?

Look.  from my 24+ years of experience in the electronics industry, I
have come to understand that almost anyone can get an engineering
degree.  Mainly they do it because they don't want to milk cows for a
living, or turn wrenches, or...  I find that few "engineers" do any
actual engineering, most of these people just go through the motions
without any passion for the work that they do:  they are mediocre

I cannot recall just how many hours I have spent reverse engineering the
Apple Pascal P-Code interpreter, just so I could put Apple Pascal on a
Commodore 64.  I did it because it was a cool thing to do, AND, I
learned a tremendous amount about P-Code systems.

Apparently you are looking for a commodity here, there is none.  uClinux
is being crafted into systems that consumers will use, and this is being
done by people who love to code.  Wading through arcane code is what we
do, it is part of the job description (like it or not)!

> In the case of uClinux, if someone were able to put a text together that
> provided a fundamental understanding, not of the kernel but of the directory
> structure and the build process, I would purchase it. Yes, even if an on-line
> copy was available! Properly done, this would be an excellent resource to give
> me initial direction and to serve as a refresher as time goes on. Sure, anything
> in development is, by definition, in a state of flux, but, as somone on this
> list pointed out, old documentation is btter than no documentation. Linux
> (kernel and all that) is a great thing, but my key interest is in the
> applications and it is the applications that will give life to Linux and ensure
> its success "everywhere".

I don't care if uClinux is "everywhere", I have it here, it works for

> Another way to look at this, after reviewing the uldp site, is to ask: How many
> of the FAQs would be answered by having a basic overall text to give direction?
> Alternately: How much traffic on this list would be eliminated by enabling the
> newbies to ask more specific questions?

Part of the problem is that many "newbies" (as well as those that should
know better) cannot formulate a question!  I cannot tell you how many
times I have started to post to a list and in the process of writing the
question down, discovered my own answer.  Too many people seem to want
to not think and just go ask someone else.  That is tiring.



Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/

More information about the uClinux-dev mailing list