Clear OS / HAL separation

Clear OS / HAL separation

[M Ptich]

I am porting 2.6 kernel from Freescale onto our PPC platform. This is my 
first experience with Linux, and I was unpleasantly surprised how poorly OS 
and platform code are separated. So I have a question: is there a project 
underway, somewhere, that is trying to separate OS and HAL (or Board Support 
Package) for the next Linux kernel ?

Would highly appreciate any relevant pointers.

_________________________________________________________________
Stay in touch with old friends and meet new ones with Windows Live Spaces 
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Re: Clear OS / HAL separation

[Grant Likely]

On 11/2/06, M Ptich <ptich@hotmail.com> wrote:
> I am porting 2.6 kernel from Freescale onto our PPC platform. This is my
> first experience with Linux, and I was unpleasantly surprised how poorly OS
> and platform code are separated.  So I have a question: is there a project
> underway, somewhere, that is trying to separate OS and HAL (or Board Support
> Package) for the next Linux kernel ?

Can you elaborate on what you mean?  From my perspective there is
quite well defined separation between the kernel proper, the device
drivers, and the board setup code.

However, there is no stable kernel API for you to program against, and
this is by design.  For details, read the following file in the kernel
source tree:  Documentation/stable_api_nonsense.txt

Now, all that being said, there is separation between bootloader and
kernel responsibilities that is currently evolving.  Linux 32 bit PPC
support is slowly being migrated from the arch/ppc directory into
arch/powerpc where it is merging with 64 bit ppc support.  The
arch/powerpc tree also uses a device tree (binary data structure) to
pass board configuration information from the bootloader to the
kernel.  The bootloader is responsible for initializing the board (ie.
SDRAM and certain devices).  Since the device tree informs the kernel
what devices are present, most of the kernel code can be generic and
the kernel will only setup device drivers for devices that are
actually present.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Clear OS / HAL separation

[Grant Likely]

On 11/3/06, M Ptich <ptich@hotmail.com> wrote:
> Hi Grant,
>
> Thanks a lot for your kind reply. What I meant is inordinate amount of
> sometimes ifdefs, sometimes call redirection (like ppc_md), pretty messy.
> But it is mostly in already machine-dependent code, so does not count as bad
> separation, you're right.
>
> But I am wondering about your remark that "there is separation between
> bootloader and
> kernel responsibilities". I think that on PPC Kernel depends very little on
> the bootloader - bootloader just needs to set up 5 input parameters (one of
> them is a pointer to initialized bd_t), and have initial Kernel TLB with
> IPROT=1. That's it, all the devices (including internal CPU stuff) are
> initialized in the Kernel. Am I correct ?

If you're looking in arch/ppc, you are 100% correct.  If you are
looking in arch/powerpc, which is where new development is occuring, a
device tree is used to pass information about available devices to the
kernel.  Also, your boot loader *should* (but you don't need to do it
this way) setup your SOC configuration (gpio, etc).  By doing it this
way, the device tree can encapsulate most of the differences between
different boards using the same processor (or SOC).  Board specific
code is kept to a minimum; or in some cases is non-existent.
Everything you need can be covered by device drivers and processor
specific code.

However, unless you've got real openfirmware, it is still just a
handoff from the bootloader to the kernel.  Once the kernel is booted,
it won't make any calls back to the bootloader.

Cheers,
g.

BTW, please make sure you include the mailing list when replying

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195