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