From: David A. Panariti (davep@who.net)
Date: Wed Jun 13 2001 - 11:37:30 EDT
Hi,
I agree whole-heartedly that the bootldr needs reorganization.
(I'd like to do it, but too many other things have priority)
[Please forgive the pedantic nature of this email. I thought it best
to cover too much of what I think is important vs too little. If too
much is obvious, sorry.]
But think fairly hard about the abstractions.
I've done some portability work in the past, and thinking up front
really helps. We made a file system core portable across 3 or 4
Unices, DOS, Windwoes (3.1 and NT) and Macintosh. With *NO* ifdefs in
the main line code.
We thought hard about primitive abstraction vs meta-abstraction vs
both.
For example, for console IO, you could just say each platform defines,
getc().
Or you could say a generic getc() is made up of a bunch of primitive
functions like:
SERIAL_CHAR_READY()
SERIAL_READ_CHAR()
(I did an incomplete job of this for getc in the current bootldr. I
was too time constrained and too paranoid about breaking every other
port to do it correctly)
Don't underestimate the value of having common logic in one
place. Note the goofy timeout and pushed char logic. If getc was
impletemted entirely in platform specific logic, it would have to be
re-implemented N times (possibly introducing bugs). Also, one would
tend to clone some implementation and if bugs were found in the
original , the fix would need to be propagated and TESTED on N
platorms.
Of course, this isn't the only way. We could have a primitive,
platform specific getc with a generic, fancy_getc() in front of it.
The nature of the code can help. There are many right/good answers.
The other side of this is efficiency. Things should be structured such
that getc() can be overridden by a complete platform specific getc().
And *PLEASE* avoid lots of mainline arch type ifdefs. They make
understanding and maintenance much harder. If it is ifdef'd in one
place, it'll likely be in another. Hide it in a macro, inline or
function. I've rarely been burned by putting something in macro
when I didn't need to vs the number of times something looked like
"it'll never change", sticking the code inline and having it change.
So for your dir structure, I would suggest an addition like services:
> > bootldr
> >
> > +--> arch
> > | +--> arm
> > | +--> sa11xx
> > | | +--> bitsy
> > | | +--> assabet
> > | | +--> jornada
> > | |
> > | +--> 21285
> > | +--> skiff
> > |
+--> services
+--> io
+--> serial
+--> touch-screen
+--> LCD
+--> mm[u] (may want to abstract mem management vs MMU device)
+--> ports/control regs
.
.
.
> > +--> config (all config files)
> > +--> include (all board/cpu independent headers)
> > +--> libs (things like string conversion oer helper functions)
> > +--> tools (tools nessesary for building, but not part of the
>
In services would go interfaces/implelemtations of the services that
change across platorms (or ALL services).
The services implementations can then call arch specific routines to
get the work done. arch specific code can call back to services if
needed.
Platform specific implementations need not be code. I've found that
often macros (or inlines) are best. Often giving total abstraction
with no performance difference. And simple defines. Sometimes all
that differs between implementation is the value of a flag. Don't
count on it, tho ;->
Sorry, this is quite long winded. But I think that porability and
abstraction is a tremendously important thing for code
comprehensibility, maintenance, flexibility and correctness. Other
than that, it's worthless :->
It is very hard to to right, and very easy to do wrong. While it is
harder to do initially, it saves tons of time in the long run. There
are enough platforms supported now so that abstractions are easier to
see. I would suggest as complete a reorg/rewrite as possible. For
something like this, it would not be worth it to do it way/2.
regards,
davep
random, but appropriate, fortune:
--
"I have made this letter longer than usual because I lack the time to
make it shorter."
-- Blaise Pascal
This archive was generated by hypermail 2.1.5 : Fri Jan 17 2003 - 17:47:02 EST