[prev in list] [next in list] [prev in thread] [next in thread] 

List:       etux
Subject:    RE: FW: GNU/Linux source code tree for arch's
From:       David Woodhouse <dwmw2 () infradead ! org>
Date:       2003-11-07 8:10:22
Message-ID: 1068192622.16437.55.camel () imladris ! demon ! co ! uk
[Download RAW message or body]

On Thu, 2003-11-06 at 13:35 -0500, Andre Ancelin wrote:
>   As currently designed and organized, the kernel has no readily apparent
> provisions to allow a developer to create a BSP without touching far too
> much of the other platform BSP code.

This is intentional. Code should be shared to as large an extent as
possible to avoid duplication and reduce maintenance effort. If three
different platforms are very similar, which is often the case, then you
don't want them all duplicating large amounts of code in their
board-specific parts. You _want_ them to make it more generic.

>   You both mention that the barrier is purposefully high, so as to require
> an individual to become so intimate with the kernel that it all becomes
> second nature (I paraphrase). Well, they have succeeded- it is quite high.
> If Linus's statement concerning "world domination" is to become true, then
> one effective means of helping to achieve that goal is to allow as many
> different processors and platforms to be ported as easily as possible.

No. That would cause the code base to turn to crap. We don't want
monkeys contributing code.

>  It is
> my assertion that anyone who would like to create a BSP should have to know
> as LITTLE about the kernel as possible, not as MUCH. I think most, if not
> all, of my professional associates (read closely- "professional associates",
> not "kernel hackers"- no disrespect intended) would agree. Most of us have
> far too many work opportunities already, so passing on gut wrenching kernel
> internals would be welcome.

I don't want anyone writing board support code without understanding
kernel internals. Not if I'm ever going to have to see or use it, at
least. We get enough code already which clearly shows how little the
author knew about the kernel; we don't want to make the situation worse.

I was deadly serious when I spoke of doubling estimates if the customer
thinks they wrote it already; just like a plumber will probably charge
you double if you tried to fix it yourself and your kitchen is already
six feet under water...


>  It's a pity that the simple desire to create a GNU/Linux
> based embedded platform for a product requires a developer to either fork
> over lots of $$$ to a third party (MontaVista, DENX, etc.) or spend an
> inordinate amount of time and effort becoming 'one' with the kernel. In that
> light, the arguments of MS and Wind River, not to mention the #1 market
> share "grow your own RTOS" option, become much more persuasive to the
> newcomer -AND- (even more importantly) management.

You compare a one-off cost of familiarisation with a fairly ubiquitous
piece of software, with per-project costs of outsourced or inhouse
development. Your comparison is only really valid for a company
developing _one_ product and thinking of using Linux on it, and never
intending to make another product.

Once you start developing multiple products, the initial cost of
learning is amortised. 

>   The reason I made my inquiry is because I thought that many in the
> embedded community- not necessarily the kernel community- may also share my
> view. I also thought, having written 2 proprietary RTOS's from the ground up
> and ported them to several architectures and platforms, that I might have
> something of value to offer. To date, all feedback has either politely
> informed -OR- scolded me on the correct way to do things within the lkml.

Isn't that what you wanted? If you want to make improvements, go ahead
and do so; I thought I'd tried to outline the easiest way to actually
get them merged. 

> And that's fine- I'm plenty secure in my 20++ year professional career to
> take such critiques. Unfortunately, NONE has addressed the essence of my
> inquiry- should processor and platform modularity be improved.

There have been improvements in the 2.6 kernel, as you observed. I'm
sure there's scope for more, yes.  

>  So, being a man of science, I have to say that it appears there is little
>  to no interest in the subject on this list. Which is also fine. 

I didn't see any _actual_ proposed changes, or even a specific plan,
which caught my interest. The rest, with respect, was waffle.

> On the other hand, commentary on lkml etiquette seems to be plenty abundant.

That was the bit where we tried to explain why we weren't paying any
attention since you hadn't yet provided any specifics, right?

Too many people turn up, witter about their pet plan for a while, and
disappear without ever actually _doing_ anything. I'm not talking about
etiquette; I'm talking about why people don't seem interested. It's not
a sensible use of time, to debate with everyone who turns up and wants
to discuss their pet idea. Now you may be different, and I suspect you
are -- I welcome that, and that's why I'd even bothered to respond. But
still, without a specific plan we're still just urinating into the
atmospheric disturbance. 

>  Unless additional inquiries convince me that this is deemed a problem -AND-
>  there is interest in addressing it, I will most likely not pursue it any 
> further.

That would be a shame. I suspect that you'd have some useful ideas to
offer. Don't be put off by people not wanting to talk about it; that's
just the way things are, because so many people don't ever actually _do_
what they talk about.

-- 
dwmw2



[prev in list] [next in list] [prev in thread] [next in thread]