[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.