[uClinux-dev] A pervasive problem...

David McCullough davidm at snapgear.com
Fri Nov 16 20:29:18 EST 2001


Jivin Dave_Pfaltzgraff at patapsco.com lays it down ...
> 
> Dave Pfaltzgraff at PATAPSCO
> 11/16/2001 10:56 AM
> 
> This message is only food for thought. If the result is a flame war, then it
> means I have touched on some sensitive areas and so be it. You must remember
> that my position is not as a developer but as a user and occasional
> contributor.


I doubt you will get a flamewar from this,  but then you never know ;-)


> In a series of messages titled "Adding new board support [& other questions]",
> Bruce Patterson attempted to find direction in performing a specific task.
> Rather than a simple response that may have given him the direction he needed,
> he was chided and told to "read the source." I thoroughly understand his
> frustration as I have been there several times. The heritage of the *nix
> community is rich and steeped in history. Much of what is done is not
> intuitive.
> My most recent adventures resulted in a contribution to http://home.at/uldp
> in the form of sections 5 (Adding Device Drivers) and 6 (Adding
> Applications). This
> contribution was made only after I submitted it to this group and did not
> receive any corrections.
> 
> 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?


A lot of reasons:

* Support 2.0 and 2.4 kernels configs and app/vendors configs with
  'make config'
* support uClibc/uC-libc and possibly glibc,  again config selectable
* Get all the compiler/build info into one file (config.arch)
* Easily support processors other than m68k
* clean up the vendors area a little

and lastly but most importantly,  do what "we",  the people creating it,
need the tree to do :-)


>   2. Why was there no documentation to support this?


I can only speak for the colfire/uClinux-distribution,  but mostly,  we are
just too busy to write doco that the people here do not need.  We are not
charging for the distro and we help out when we can ;-)


>   3. Why didn't anyone correct me when I submitted my document to this list
>      a mere month ago?


I appologise,  I actually meant to make the point that this was based on the
old distribution back then,  but at the time a lot of people were still working
on that release,  and as such your document was correct ;-)


>   4. Etc...
> 
> 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 agree,  and I guess some of us get a little tired answering questions
that are in the mail archives several times already.  I think most people's
simple questions are answered quite well on the list.


[...]
> 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".
> 
> 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?
> 
> Enough said...

Hang in there,  I'm sure we'll get something happening on the doco front ;-)

Cheers,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
davidm at snapgear.com  Fx: +61 7 3891 3630  825 Stanley St., W'gabba QLD 4102, Oz
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list