I count this as the third recent attempt to add an abstraction layer for interdomain page mapping/communication/transport. (YAIDTL = yet another interdomain transport layer) In addition, the ia64 port and the ppc port are struggling (in some ways) with removing the x86-isms from the existing blkif and netif backends. Surely this is relevant to the core Xen developers? And surely when it is time to push the Xen drivers upstream, the Linux driver community reviewers will notice the issue? Inquiring minds want to know :-)> Message: 2 > Date: Thu, 16 Feb 2006 16:56:31 -0500 > From: Ryan <hap9@epoch.ncsc.mil> > Subject: [Xen-devel] [PATCH][1/4] PCI Driver Domains: Xenbus > Convenience Functions > To: xen-devel <xen-devel@lists.xensource.com> > Message-ID: <1140126991.21373.17.camel@moss-tarheels.epoch.ncsc.mil> > Content-Type: text/plain; charset="us-ascii" > > Resubmitting the driver domain patches against the latest > xen-unstable. > These should apply cleanly to 8857:40d7eef7d3f5. > > In my digging through the existing backend/frontend drivers to plan my > own, I found several places where code is duplicated to share and map > pages via the grant tables. I added some convenience functions to > xenbus_client.c to hide the details of the virtual address allocation > and hypercall. My intent was to provide a simpler, higher-level > interface for mapping in pages from another domain. While I believe > these convenience functions simplify some typical uses of interdomain > communication, they could easily be removed by expanding their uses in > the PCI backend and frontend if there is opposition to their > inclusion. > > I also added a one-liner that causes xenbus_dev_(error|fatal) > to output > to the kernel log buffer (and thus syslog) which was invaluable to me > while debugging (by default, error messages only appear in xenstore). > > No significant changes since last submission. > > Signed-off-by: Ryan Wilson <hap9@epoch.ncsc.mil> > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: xenbus-util.patch > Type: text/x-patch > Size: 7752 bytes > Desc: not available > Url : > http://lists.xensource.com/archives/html/xen-devel/attachments/20060216/a695ce5b/xenbus-util.bin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-02-16 at 16:06 -0800, Magenheimer, Dan (HP Labs Fort Collins) wrote:> I count this as the third recent attempt to add an abstraction > layer for interdomain page mapping/communication/transport. > (YAIDTL = yet another interdomain transport layer)Yes. I think there''s a consensus that the current code is patchy, to say the least. It''s an open question how drastic the surgury needs to be. For my part, I''m not in a particular hurry: I''m aiming for xen 4.0, and there''s lots of work to be done between here and there. Incremental improvements to the existing code will no doubt continue in shorter timeframes. My issue with Xen continues to be that it is too complex, hence my attempts to implement a minimal efficient interface. We will see what it looks like once it''s feature-complete, portable, etc.> Surely this is relevant to the core Xen developers? And > surely when it is time to push the Xen drivers upstream, > the Linux driver community reviewers will notice the issue?I''m fairly sure kernel people will gag on the current xenbus and driver code, yes. They might not consider it their problem, however, since they don''t have to support it. Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel