[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |