From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andres Lagar-Cavilla Subject: libxenlight or libxenheavy? Date: Mon, 30 Nov 2009 14:08:47 -0500 Message-ID: <4B14183F.3070801@lagarcavilla.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Aside of the tongue in cheek title, I'd like to get a feel for where is libxenlight going. I love having a library that gives me three straight-forward C calls to create a domain, and I think it's an excellent vehicle to writing control stacks. But some of the latest patches have grown/bloated the library in directions I don't think are useful. This an obviously subjective take on the matter, but here are two examples: - Managing tapdisk2 devices in libxenlight: why at all? An upper-level control stack can (will have to) vet the configuration stanza of the tapdisk2 process, and it can then launch it and manage its life-cycle (i.e. echo appropriate commands to the sysfs interface). One of the great advantages of tapdisk2 is that it looks like a regular block device: /dev/xen/blktap-2/tapdev0. Libxenlight doesn't need to know this is any different from a regular block device ... - Asynchronous notifications via xenstore watches: I've seen at least two locations (device deletion during destroy and waiting for domain death) where a watch on a xenstore path is placed by the library, and later xs_read_watch is called. According to my limited understanding, this could read *any* firing watch placed by the same process, and the code will discard it unless it's the one we are looking for. Thus destroying information useful to someone else. I cannot have two concurrent (or even interleaved) calls to libxenlight on these code paths, because they could read each other's watches. Why not leave these to an upper-level stack, which in all likelihood will have to deal with lots of asynchronous events? As it stands, I have to write my code *around* libxenlight, which kind of defeats the purpose. Anyway, these are two observations. Libxenlight is great. And to buy back some of the love I spent ranting, I'll follow this with 14 patches. These are all based off20522: abc6183f486e . Some are more RFC-ish in nature, but there a fair bit of fixes. They apply -p1 (sorry). Just let me know if you need a rebasing or whatever. Andres