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: [XenPPC] RFC: xencomm - linux side

Le Jeudi 24 Août 2006 17:43, Hollis Blanchard a écrit :
> On Thu, 2006-08-24 at 09:51 +0200, Tristan Gingold wrote:
> > > My suggestion: have xencomm_create() test IS_KERNEL_ADDR() (in whatever
> > > way is best for portability) and if it is, do the "inline" stuff. On
> > > the free side, if the descriptor was inline, free can just return. That
> > > would also make me happy because it removes the need to think about
> > > whether callers can/should call "create_inline" or not; the code just
> > > does the right thing.
> >
> > We definitly disagree here.  One whole point of xencomm_create_inline is
> > it doesn't allocate memory and can't fail.  Because of that we don't need
> > to worry about failure and freeing memory.  This makes the code a lot
> > easier to write and to read.
>
> It would simplify the code even more to fold xencomm_create_inline()
> into xencomm_create(), as I suggest above. That way, the developer never
> needs to consider if the particular hypercall could ever be called
> before the page allocator works. Proving that assumption for some
> hypercall, and guaranteeing it will remain true in the future no matter
> what Linux changes occur, is a lot more difficult than remembering to
> call free() after create().
Could you modify the ppc code, I will be happy to fetch directly the code for 
this new idea.

> The goal of any API should be to make it impossible to use it
> incorrectly, and I think my (firm) suggestion makes that true here.
What about possible errors ?

Tristan.

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