|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add sup
It applied pretty cleanly for me. I didn't try to build it though. :-)
-George
On Wed, Jun 16, 2010 at 5:20 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 16/06/2010 17:14, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:
>
>>> I actually tried the xmalloc() method first. I found that when the
>>> .adjust_global function was called, the address of the "ops" data structure
>>> passed to that function was different from the address of the "ops" data
>>> structure when the .init function was called. I wanted to use
>>> .adjust_global
>>> to modify the data structure that was created when the .init function was
>>> called, but I could not figure out a way to get the address of the second
>>> data structure. Suggestions?
>>
>> It's been a month or two since I trawled through the cpupools code;
>> but I seem to recall that .init is called twice -- once for the
>> "default pool" (cpupool0), and once for an actually in-use pool.
>> (Juergen, can you correct me if I'm wrong?) Is it possible that
>> that's the difference in the pointers that you're seeing?
>
> Oh yes, that was the old behaviour. I took a hatchet to the
> scheduler/cpupool interfaces a few weeks ago and now we should only
> initialise the scheduler once, unless extra cpupools are manually created.
> The fact that Kathy is seeing two different ops structures probably
> indicates that her xen-unstable tree is very out of date. Which may also
> mean that the patch will not apply to current tip.
>
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|