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

Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.



Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: 
Extensive updates to API documentation."):
> I'm currently intending to write something very similar for each of the
> xen*_open (gntshr, gnttab, foreignmemory, evtchn and probably call too)
> functions. I don't really like repeating the same thing like this, but I
> also don't really like API documentation which makes you play follow the
> piece of string to the docs of other libraries to find out what is going
> on.

That would be fine by me.  But do these other functions suffer from
the same problem ?

Ie, can we for gntshr et al, tell the user that they should call
blah_unmap ?  This is not practical in a multithreaded program for
hypercall memory but it might well be practical for other kinds of
borrowed memory.

> I'm also considering whether on the _close function I should write
> something to the effect that in non-forked contexts the application should
> call the associated _unmap() on any active mappings before calling _close()
> in order to ensure all resources have been freed. And reiterate that
> calling _unmap after fork() is not safe.

Yes.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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