coding standards

coding standards

[Linda]

Hi Wei,
     I have a few questions before we chat Tuesday.  Per your 
instructions, I read the coding standards, which referred me to libxl.h 
for memory management.  They are contradictory, in that the coding 
standards imply that I should be using internal libxl_*alloc functions, 
but the memory management section says to do a malloc. I thought someone 
should know.
     I assume I should look for and use the appropriate libxl_*alloc 
function.
     Also, you mentioned that all libxl functions should take a ctx 
(context?) as the first argument.  I had looked at several libxl_bitmap* 
functions (init, test, set, and dispose) which don't, but looking at the 
alloc code you sent me, I'm not clear on the purpose of the ctx.  
Perhaps we can go over that in our chat.

Thanks.

Linda

Re: coding standards

[Wei Liu]

On Mon, Mar 30, 2015 at 12:29:41PM -0600, Linda wrote:
> Hi Wei,
>     I have a few questions before we chat Tuesday.  Per your instructions, I
> read the coding standards, which referred me to libxl.h for memory
> management.  They are contradictory, in that the coding standards imply that
> I should be using internal libxl_*alloc functions, but the memory management
> section says to do a malloc. I thought someone should know.

They are not contradictory. libxl_*alloc are wrappers to libc's *alloc
functions.

I think that section is mostly material for external callers (i.e. from
the libxl user's point of view). You're going to work on the library
itself so your point of view is a bit different.

>     I assume I should look for and use the appropriate libxl_*alloc
> function.

Yes.

>     Also, you mentioned that all libxl functions should take a ctx
> (context?) as the first argument.  I had looked at several libxl_bitmap*
> functions (init, test, set, and dispose) which don't, but looking at the
> alloc code you sent me, I'm not clear on the purpose of the ctx.  Perhaps we
> can go over that in our chat.
> 

I think I said "usually". There are exceptions. :-) 

Yes, ctx means context. The application (libxl user) is going to
initialise that context and pass that to libxl public API. Then your
public API (the functions that you're going to implement are public
APIs) can use that context to do various stuff.

There are many things wrapped in context, but I don't think you really
need to care about what they are unless you really need them.

For the time being, you can use the code snippet (libxl_bitmap_alloc) I
sent you as skeleton to implement your own functions.

Wei.

> Thanks.
> 
> Linda

Re: coding standards

[Linda Jacobson]

Will do.   Thanks for all the info.   L

Sent from my iPhone

> On Mar 30, 2015, at 12:52 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> 
>> On Mon, Mar 30, 2015 at 12:29:41PM -0600, Linda wrote:
>> Hi Wei,
>>    I have a few questions before we chat Tuesday.  Per your instructions, I
>> read the coding standards, which referred me to libxl.h for memory
>> management.  They are contradictory, in that the coding standards imply that
>> I should be using internal libxl_*alloc functions, but the memory management
>> section says to do a malloc. I thought someone should know.
> 
> They are not contradictory. libxl_*alloc are wrappers to libc's *alloc
> functions.
> 
> I think that section is mostly material for external callers (i.e. from
> the libxl user's point of view). You're going to work on the library
> itself so your point of view is a bit different.
> 
>>    I assume I should look for and use the appropriate libxl_*alloc
>> function.
> 
> Yes.
> 
>>    Also, you mentioned that all libxl functions should take a ctx
>> (context?) as the first argument.  I had looked at several libxl_bitmap*
>> functions (init, test, set, and dispose) which don't, but looking at the
>> alloc code you sent me, I'm not clear on the purpose of the ctx.  Perhaps we
>> can go over that in our chat.
> 
> I think I said "usually". There are exceptions. :-) 
> 
> Yes, ctx means context. The application (libxl user) is going to
> initialise that context and pass that to libxl public API. Then your
> public API (the functions that you're going to implement are public
> APIs) can use that context to do various stuff.
> 
> There are many things wrapped in context, but I don't think you really
> need to care about what they are unless you really need them.
> 
> For the time being, you can use the code snippet (libxl_bitmap_alloc) I
> sent you as skeleton to implement your own functions.
> 
> Wei.
> 
>> Thanks.
>> 
>> Linda

Re: coding standards

[Lars Kurth]

Linda,
I do want to remind you that you need to start communicating on the public list and submit some patches. Also some of us are away before the application deadline on the 7th. So things may get tight
Regards
Lars

> On 30 Mar 2015, at 20:26, Linda Jacobson <lindaj@jma3.com> wrote:
> 
> Will do.   Thanks for all the info.   L
> 
> Sent from my iPhone
> 
>> On Mar 30, 2015, at 12:52 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>> 
>>> On Mon, Mar 30, 2015 at 12:29:41PM -0600, Linda wrote:
>>> Hi Wei,
>>>   I have a few questions before we chat Tuesday.  Per your instructions, I
>>> read the coding standards, which referred me to libxl.h for memory
>>> management.  They are contradictory, in that the coding standards imply that
>>> I should be using internal libxl_*alloc functions, but the memory management
>>> section says to do a malloc. I thought someone should know.
>> 
>> They are not contradictory. libxl_*alloc are wrappers to libc's *alloc
>> functions.
>> 
>> I think that section is mostly material for external callers (i.e. from
>> the libxl user's point of view). You're going to work on the library
>> itself so your point of view is a bit different.
>> 
>>>   I assume I should look for and use the appropriate libxl_*alloc
>>> function.
>> 
>> Yes.
>> 
>>>   Also, you mentioned that all libxl functions should take a ctx
>>> (context?) as the first argument.  I had looked at several libxl_bitmap*
>>> functions (init, test, set, and dispose) which don't, but looking at the
>>> alloc code you sent me, I'm not clear on the purpose of the ctx.  Perhaps we
>>> can go over that in our chat.
>> 
>> I think I said "usually". There are exceptions. :-) 
>> 
>> Yes, ctx means context. The application (libxl user) is going to
>> initialise that context and pass that to libxl public API. Then your
>> public API (the functions that you're going to implement are public
>> APIs) can use that context to do various stuff.
>> 
>> There are many things wrapped in context, but I don't think you really
>> need to care about what they are unless you really need them.
>> 
>> For the time being, you can use the code snippet (libxl_bitmap_alloc) I
>> sent you as skeleton to implement your own functions.
>> 
>> Wei.
>> 
>>> Thanks.
>>> 
>>> Linda

Xen Outreachy application

[Linda]

Hi Lars,
     I am aware of it.  Thank you.  I've been having trouble with builds 
and git send-emails.  The code is written and minimally unit tested.  I 
would love to have it reviewed.
     I'm waiting on answers/suggestions from Julien and Wei, who have 
been very responsive.  They deserve gold stars for their patience with me.
     BTW, I hope you don't mind I changed the subject line, so the 
developers on the list understand the circumstances.

Thanks,

Linda Jacobson


On 4/2/2015 7:15 AM, Lars Kurth wrote:
> Linda,
> I do want to remind you that you need to start communicating on the public list and submit some patches. Also some of us are away before the application deadline on the 7th. So things may get tight
> Regards
> Lars
>
>> On 30 Mar 2015, at 20:26, Linda Jacobson <lindaj@jma3.com> wrote:
>>
>> Will do.   Thanks for all the info.   L
>>
>> Sent from my iPhone
>>
>>> On Mar 30, 2015, at 12:52 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>>>
>>>> On Mon, Mar 30, 2015 at 12:29:41PM -0600, Linda wrote:
>>>> Hi Wei,
>>>>    I have a few questions before we chat Tuesday.  Per your instructions, I
>>>> read the coding standards, which referred me to libxl.h for memory
>>>> management.  They are contradictory, in that the coding standards imply that
>>>> I should be using internal libxl_*alloc functions, but the memory management
>>>> section says to do a malloc. I thought someone should know.
>>> They are not contradictory. libxl_*alloc are wrappers to libc's *alloc
>>> functions.
>>>
>>> I think that section is mostly material for external callers (i.e. from
>>> the libxl user's point of view). You're going to work on the library
>>> itself so your point of view is a bit different.
>>>
>>>>    I assume I should look for and use the appropriate libxl_*alloc
>>>> function.
>>> Yes.
>>>
>>>>    Also, you mentioned that all libxl functions should take a ctx
>>>> (context?) as the first argument.  I had looked at several libxl_bitmap*
>>>> functions (init, test, set, and dispose) which don't, but looking at the
>>>> alloc code you sent me, I'm not clear on the purpose of the ctx.  Perhaps we
>>>> can go over that in our chat.
>>> I think I said "usually". There are exceptions. :-)
>>>
>>> Yes, ctx means context. The application (libxl user) is going to
>>> initialise that context and pass that to libxl public API. Then your
>>> public API (the functions that you're going to implement are public
>>> APIs) can use that context to do various stuff.
>>>
>>> There are many things wrapped in context, but I don't think you really
>>> need to care about what they are unless you really need them.
>>>
>>> For the time being, you can use the code snippet (libxl_bitmap_alloc) I
>>> sent you as skeleton to implement your own functions.
>>>
>>> Wei.
>>>
>>>> Thanks.
>>>>
>>>> Linda
>

Coding Standards

[Marc-André Laverdière]

Hello,

I was reading an article long ago where Mr Reiser was saying that he was 
using military grade coding standards. And that it is also the reason 
why Reiser4 is not integrated by default in the Linux kernel.

My experience at looking at GNU code is that it is sloppy and I want to 
start a high-assurance project with the best of the best of coding 
practices... something making me feel that the GNU coding guidelines are 
not the best of options.

Your input would be very appreciated!

-- 
Marc-André LAVERDIÈRE, B. Eng., M. A. Sc. (in progress)
Research Assistant - Computer Security Laboratory
CIISE, Université Concordia University, Montréal, Québec, Canada
www.ciise.concordia.ca

/"\
\ /    ASCII Ribbon Campaign
  X      against HTML e-mail
/ \

"Perseverance must finish its work so that you may be mature and 
complete, not lacking anything." -James 1:4

Re: Coding Standards

[Hans Reiser]

Marc-André Laverdière wrote:

> Hello,
>
> I was reading an article long ago where Mr Reiser was saying that he
> was using military grade coding standards. And that it is also the
> reason why Reiser4 is not integrated by default in the Linux kernel.

I think that was a minor issue.  The major issues are political.

>
> My experience at looking at GNU code is that it is sloppy and I want
> to start a high-assurance project with the best of the best of coding
> practices... something making me feel that the GNU coding guidelines
> are not the best of options.

I would really look into the various security and secure coding papers
and articles that have been funded by DARPA and others over the years. 
Pick through them, read them, and code that way.  The guys writing the
articles are much more expert than I am on it.

>
> Your input would be very appreciated!
>

Re: Coding Standards

[Giovanni A. Orlando]

>>Hello,
>>
>>I was reading an article long ago where Mr Reiser was saying that he
>>was using military grade coding standards. And that it is also the
>>reason why Reiser4 is not integrated by default in the Linux kernel.
>>    
>>
>
>I think that was a minor issue.  The major issues are political.
>
>  
>
So ... what the hell happens? Why is not included yet?

Thanks,
Giovanni.

>>My experience at looking at GNU code is that it is sloppy and I want
>>to start a high-assurance project with the best of the best of coding
>>practices... something making me feel that the GNU coding guidelines
>>are not the best of options.
>>    
>>
>
>I would really look into the various security and secure coding papers
>and articles that have been funded by DARPA and others over the years. 
>Pick through them, read them, and code that way.  The guys writing the
>articles are much more expert than I am on it.
>
>  
>
>>Your input would be very appreciated!
>>
>>    
>>
>
>  
>


-- 

--
--
http://www.FutureTG.com      - The Main Website.
http://www.FTLinuxCourse.com - The Website for Linux Training.
http://www.RPMParadaise.com  - The Website for RPM Packages.

Phone: +58 412 55 41 338 (I am in Caracas, actually)

FT Addresses are located at: http://www.futuretg.com/FT/contact.html