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

[Xen-ia64-devel] Re: [XenPPC] RFC: xencomm - linux side



Le Mercredi 23 AoÃt 2006 18:35, Hollis Blanchard a Ãcrit :
> On Wed, 2006-08-23 at 09:59 +0200, Tristan Gingold wrote:
> > Le Mardi 22 AoÃt 2006 21:03, Hollis Blanchard a Ãcrit :
> > > I don't understand the point of all these routines if they just call
> > > arch_foo anyways.
> >
> > Sorry I have not explained the principle.
> > xencomm_arch_hypercall_XXX are the raw hypercalls.  They must be defined
> > by architecture code. The xencomm_hypercall_XXX are the xencomm wrapper
> > and are shared.
>
> That much is clear. :) My question is what is being done in those "raw
> hypercalls" that can't be done here? You didn't include them in your
> patch, so I can't tell.
>
> It seems there are a few missing pieces to your patch. Next time please
> include the whole thing, including arch-specific parts, so we can see
> what's going on.
>
> > > > +       if (ret)
> > > > +               goto out; /* error mapping the nested pointer */
> > > > +
> > > > +       ret = xencomm_arch_hypercall_dom0_op (op_desc);
> > > > +
> > > > +       /* FIXME: should we restore the handle?  */
> > > > +       if (copy_to_user(user_op, &kern_op, sizeof(dom0_op_t)))
> > > > +               ret = -EFAULT;
> > > > +
> > > > +       if (desc)
> > > > +               xencomm_free(desc);
> > > > +out:
> > > > +       return ret;
> > > > +}
> > >
> > > You misplaced the out label; it needs to go before xencomm_free(desc);
> >
> > ??? This was copied from your work.
>
> You've made changes here, and that's what I'm pointing out.
>
> > The code branches to out iff xencomm allocation failed.  It is safe to
> > call xencomm_free but useless.
>
> There are multiple descriptors being created: one for the dom0_op
> top-level structure, and possibly one for a sub-structure. In fact, in
> your patch you never free 'op_desc' inside xencomm_privcmd_dom0_op().
> OK, reading closer, I don't like that at *all*. The trick is that
> xencomm_create_inline() doesn't actually create anything, and therefore
> you don't need to free it. That needs to change.
>
> 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.

Tristan.

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


 


Rackspace

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