From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Andrew Kane <Andrew.Kane@dornerworks.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Steve VanderLeest <Steve.VanderLeest@dornerworks.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH] libxl: libxl_domain_sched_params_set case for ARINC 653 scheduler
Date: Wed, 25 Jul 2012 10:15:21 +0100 [thread overview]
Message-ID: <500FB929.6070501@eu.citrix.com> (raw)
In-Reply-To: <1343170114.13198.49.camel@Abyss>
On 24/07/12 23:48, Dario Faggioli wrote:
> On Tue, 2012-07-24 at 15:09 -0400, Andrew Kane wrote:
>>>> +static int sched_arinc653_domain_set(libxl__gc *gc, uint32_t domid,
>>>> + const libxl_domain_sched_params *scinfo)
>>>> +{
>>>> + // Currently, the ARINC 653 scheduler does not take any domain-specific
>>>> + // configuration, so we simply return success.
>>>>
>>> I think using C (/* */) style for comment is highly recommended, if not
>>> required. :-)
>> Oops. That's what I get for trusting the editor with comments. =)
>>
> :-)
>
>> Our thought was to define this following the structure that exists for the
>> other schedulers, both for consistency and to facilitate future work
>> on the ARINC 653 scheduler.
>>
> Yeah, I got that, and it's not bad thinking actually.
>
> Thinking a bit more about this, right below
> libxl_domain_sched_params_set() (in libxl.c) there is another function
> called libxl_domain_sched_params_get(), doing pretty much the same
> thing, although of course it retrieves instead of setting.
>
> Shouldn't you be doing something similar to that too?
>
>> If/when we actually need domain-specific configuration like this,
>> it would only involve changes in the sched_arinc653_domain_set
>> function, and wouldn't require any changes to
>> libxl_domain_sched_params_set.
>>
>> If the preference is to hold off on implementing a
>> sched_arinc653_domain_set function until there's actually something
>> to put in it, I'm happy to change it. =)
>>
> It's mostly a matter of taste I guess.
>
> The way I pointed is my preference, but I really don't care that much.
> If you send a patch with proper commenting (and perhaps dealing with the
> *_get() path), I'll ack it no matter if you have those empty functions
> or not... Which will then mean it'll be up to Goerge and Ian (added to
> the Cc list) to decide what they like better. :-)
Yeah, the comment needs to be changed to C-style, but I don't think
calling a function or not is worth the trouble of talking about. :-)
-George
prev parent reply other threads:[~2012-07-25 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 16:59 [PATCH] libxl: libxl_domain_sched_params_set case for ARINC 653 scheduler Andrew Kane
2012-07-24 18:31 ` Dario Faggioli
2012-07-24 19:09 ` Andrew Kane
2012-07-24 22:48 ` Dario Faggioli
2012-07-25 8:59 ` Ian Campbell
2012-07-25 9:15 ` George Dunlap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500FB929.6070501@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Andrew.Kane@dornerworks.com \
--cc=Ian.Campbell@citrix.com \
--cc=Steve.VanderLeest@dornerworks.com \
--cc=raistlin@linux.it \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).