[okl4-developer] How to get rid of IRQ conflicts between two OK linux cells ?
Hugues Balp
hugues.balp at free.fr
Sat Dec 6 01:15:19 EST 2008
Geoffrey Lee wrote:
> On Fri, Dec 05, 2008 at 12:40:51PM +0100, Hugues Balp wrote:
>
>>>> The compilation is ok but elfweaver crashes because of an *out of
>>>> memory* error
>>>> detected by the memory allocator when trying to allocate the memory
>>>> for the second
>>>> ok_linux cell....
>>>>
>>> Hugues -
>>>
>>> Maybe you have run out of physical memory. The amount of memory
>>> available to OK Linux is configured statically at build time via the
>>> heap = argument in the OK Linux Sconscript. If you run out of physical
>>> memory to back the heap then elfweaver will refuse to output the image.
>>>
>>>
>>> The amount of physical memory is specified in the machine
>>> description file in platform/<platform>/tools/machines.py.
>>>
>>> -gl
>>>
>>>
>> Thanks Geoffrey,
>>
>
> Hugues - specifying the add_device is equivalent to granting
> access, you cannot grant access to two OK Linux instances
> at the same time.
>
> -gl
>
If I well understand you, it would be impossible to boot and run two ok
linux cells on the same okl4 micro-kernel ?
Nevertheless we can imagine to grant access to devices dynamically, in
order for example for the different cells to boot
sequentially, each one accessing the one after the other to the required
serial device etc...
Then the accesses to devices could be updated each time the scheduler
switch from one cell to the other ?
Is this totally impossible ?
When looking at the thread "does ig_serial support more than one client"
in the forum Ben Leslie wrote
"Multiple OK Linux support can be made available for customers with
support contracts. Public release is not currently locked in, but is
likely to be Q3 this year. "
So I suppose you have already an idea of what is required to support
multiple wombat cells on okl4. Isn' t it ?
Sorry if I don't understand you.
Perhaps can you explain me what is your vision for supporting multiple
ok linux cells ?
Thanks,
Hugues Balp.
More information about the Developer
mailing list