On Thu, Oct 7, 2010 at 8:10 AM, Charles Landau <[email protected]> wrote:
> On 10/7/10 1:22 AM, Jonathan S. Shapiro wrote:
> > As we did this, we also introduced a
> > hardware abstraction layer that more clearly delineates the line between
> > arch-dependent and arch-independent dependencies.
>
> Do you mean, the HAL defines the *interface* between
> architecture-dependent and architecture-independent *code*?
>
More or less. See:
http://dev.eros-os.com/hg/coyotos/trunk/file/tip/src/sys/hal
this simultaneously specifies what the arch-dependent code must supply and
arranges to include that code. The corresponding code from a given
architecture is supplied by the target-specific "target-hal/" directory, for
example:
http://dev.eros-os.com/hg/coyotos/trunk/file/tip/src/sys/arch/i386/kernel/target-hal
I won't claim that it's complete, but it's a start, and it's headed in the
right direction. The interface between the BSP and the arch code is more
private and more prone to arch-specific adaptation. Ours isn't cleanly
stated, which is a bug.
I'ld add a very small quibble about the term "interface". For performance
reasons, it is strongly desirable that some of the things provided by the
arch-dependent code be supplied in the form of inlinable code. As such, it's
a layering construct rather than an interface - which is why this type of
thing is customarily referred to as the hardware abstraction layer.
> > I haven't looked to see if Charlie has introduced a BSP distinction into
> > CapROS, but if that hasn't been done, perhaps now is the time.
>
> Indeed. I see a few models for doing that.
>
Pragmatically, the biggest nuisance for us was that the GNU configure model
doesn't adequately distinguish the target BSP in the so-called "target
triple".
The one place where this is now done in CapROS is in
> src/base/domain/drivers/lwip which has:
>
> arch/arm/edb9315/
>
> or more generally
>
> arch/<architecture>/<board>/
>
That was our initial structure as well. We switched to
arch/<arch>/BSP/<board> for two reasons:
1. Putting the BSP subdirs under <arch> made it harder to manage the kernel
code.
2. We wanted the ability to selectively disclose BSP implementations,
anticipating that some clients wouldn't want their boards disclosed prior to
release. Considerations like this, regrettably, can have a lot of influence
on build structures. For the same reasons, we had planned to move the kernel
binary output to being generated in the BSP subdir, allowing the BSP subdir
to exist completely outside the primary kernel tree for clients doing
private ports.
> Files and/or directories common to more than one board are in the directory
>
> arch/<architecture>/
>
We didn't observe much of that. Perhaps we will in time. The main common
files in our case are the chip descriptions, and we have a domain-specific
language for that. Those are elsewhere in the tree.
> I think I prefer the CapROS lwip design. Compared to Coyotos it
> eliminates the BSP directory. I don't know that this extra level of
> directory serves a useful purpose, and it seems unlikely that a board
> name would conflict with any other file or directory name in
> arch/<architecture>/.
Since CapROS is your tree, it seems a good thing that you like it. :-)
Hopefully the motivation for our choice is clarified by my comments above. I
would add that at five BSPs your strategy is manageable, but by 20 its
pretty painful. The right choice probably depends on the kind of engagements
you are doing.
shap
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
CapROS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/capros-devel
