[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] USB Xen Summit status summary
On Thu, 2006-02-02 at 08:51 -0600, Anthony Liguori wrote: > Harry Butterworth wrote: > > >Would someone please explain why people thought the xenidc code is > >unlikely to get accepted into mainline? > > > It's the sheer volume of code. The size of your xenidc patch is on par > with early versions of the hypervisor in terms of SLOCs. > > Abstractions without a clear need for the abstraction is heavily frowned > upon in Linux. It's just way too much code without a compelling > justification for what it's needed. Ignoring the current xenidc implementation for the time being, I think the justification for a high level IDC API is that it should... o - allow you to express the drivers more simply, with less code and independent of the memory management architecture. o - allow you to have one instance of the code for the low-level operations that are common between drivers and likely to need changing in the future. o - provide you with a framework to help write drivers that correctly handle the domain and driver module lifecycles and the resource management issues of inter-domain communication. o - allow you to express the device protocols independent of the memory management architecture of any particular OS. o - allow for future network transparent split-drivers. Comparing the old blkback with the version I did against xenidc shows that... o - the xenidc version is smaller and independent of the memory management architecture. o - the xenidc version contains no low-level memory management operations. o - the xenidc version handles the domain and module lifecycles and implements a robust resource management strategy (except where I didn't bother to finish it). o - the xenidc version has a protocol expressed independent of the scatter gather form used by the linux block driver stack. o - the xenidc version is compatible with a future network transparent xenidc implementation. There is quite a lot to get right to do a split driver well. If we want high quality split drivers we should invest the effort required to provide a good API that is easy to use and encourages driver authors to write good code. I'm done arguing for xenidc. As my first bit of Linux code I didn't really expect to come up with something that people would actually like anyway. Hopefully I'll see some of the concepts get factored into the xen driver infrastructure in the future. Easy come. Easy go. Harry. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |