WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add supp

To: Kathy Hadley <Kathy.Hadley@xxxxxxxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools)
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 16 Jun 2010 17:13:53 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Jun 2010 09:15:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D3E384327F5C6D48AADCEA84160B7D7301470F06@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsNa5+84uXbHyKoQpGogg/TaccDKQAALNvQAAClqPY=
Thread-topic: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools)
User-agent: Microsoft-Entourage/12.24.0.100205
On 16/06/2010 17:00, "Kathy Hadley" <Kathy.Hadley@xxxxxxxxxxxxxxx> wrote:

> George,
>   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?

You should modify the structure you are passed -- that is ops and your
private structure as pointed at via ops->sched_data. The latter should
always point at a private structure you previously initialised via your
.init hook.

 -- Keir

>   I can make the modifications you suggest for the other items.  Thanks for
> the comments.
> 
>   Regards,
> Kathy Hadley
> DornerWorks, Ltd.
> 
>> -----Original Message-----
>> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
>> Dunlap
>> Sent: Wednesday, June 16, 2010 11:50 AM
>> To: Kathy Hadley
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser
>> Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated
>> to add support for CPU pools)
>> 
>> On Wed, Jun 16, 2010 at 4:04 PM, Kathy Hadley
>> <Kathy.Hadley@xxxxxxxxxxxxxxx> wrote:
>>> 
>> +/*********************************************************************
>> *****
>>> + * Global
>> data                                                            *
>>> +
>>> 
>> ***********************************************************************
>> ***/
>>> +static arinc653_sched_private_t arinc653_schedule;
>> [snip]
>>> +    /* Allocate memory for ARINC 653 scheduler data structure */
>>> +    prv = &arinc653_schedule;
>> 
>> You didn't actually allocate memory, you just used the static
>> structure.  The point of cpupools is to allow multiple instances of a
>> scheduler to coexist -- if people create two pools, both using the
>> ARINC scheduler, there will be problems with this.  Is there any
>> reason not to actually call xmalloc() (as is done in
>> sched_credit.c:csched_init())?  (Perhaps this is a missed FIXME or a
>> merge-o?)
>> 
>> Some of the notices in headers seems a little excessive; if
>> sched_arinc653.c credits Dornerworks, surely people can infer who
>> added the control structure in xen/include/public/sysctl.h, and added
>> a link to it in scheduler.c?
>> 
>> Not NACK-worthy, but: In struct arin..._sched_private_s, the element
>> "arinc653_schedule" should probably be named something a bit more
>> descriptive.  Similarly, having arinc653 in ..._major_frame seems a
>> bit redundant, and inconsistent with naming for the other elements.
>> 
>> Looks fine to me otherwise.  (I haven't reviewed the algorithm itself.)
>> 
>>  -George



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>