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/
Home Products Support Community News


Re: [XenPPC] RFC: xencomm - linux side

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().

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.

Hollis Blanchard
IBM Linux Technology Center

Xen-ppc-devel mailing list