Marvell microkernel

[Alex Belits]

Edward Cherlin wrote:
> On Sun, May 4, 2008 at 10:20 PM, Alex Gibson <agibson at eng.uts.edu.au> wrote:
>> Edward Cherlin wrote:
>>
>>> How is everybody doing? and how is progress on the microkernel?
>>>
>>> Has anybody else gotten involved?
>>>
>>> Now that rms has actually switched to an XO, we ought to get on with this.
>>>
>>> Who has e-mail addresses for bobkeyes, palfrey, or ido? They listed
>>> themselves on our Wiki page, but I don't see any way to contact them.
>>>
>>  We (UTS) are no longer involved after we couldn't get access to the Marvell
>> source code.
> 
> You don't mean this source code, then? What have I missed?
> 
> Driver source code: 8388 "libertas" driver from our kernel tree:
> git://git.infradead.org/users/marcelo/libertas managed by Marcelo
> Tosatti, discussion

The driver source code (the only relevant source code that I am aware of 
being available) is a client to Marvell ARM code that runs on the chip 
and currently requires closed microkernel. The design of this chip 
places most of networking and hardware control functionality not into 
Linux driver but into ARM code, what is good from standpoint of 
efficient hardware use but allows entirely closed implementation despite 
open drivers on the Linux side.

> Gabor, what happened to the effort you talked about in late 2006?
> 
> http://lists.laptop.org/pipermail/devel/2006-December/003423.html
> "...In parallel we are working with Marvell to release the 802.11s
> source code under GPL.
> 
> "Who is going to ravel out the 802.11s code from the tangled source ?
> I'd help if needed."

If Marvell can release "tangled source" for ARM code that depends on 
proprietary microkernel, it would be an ordinary porting effort to make 
it work without that microkernel. Most likely a large piece of 
microkernel's functionality is unused or unnecessary, so it's not even a 
matter of making or finding an exact equivalent of microkernel that this 
code uses now. I have seen embedded code running on no or little 
infrastructure, and there is no reason to expect that this particular 
adapter's hardware requires anything more than serving interrupts and 
performing DMA transfers -- the rest is wireless radio control and 
protocols implementation that is independent from any infrastructure.

-- 
Alex