Since Harry Butterworth, who''s been working on the USB
virtualization couldn''t attend the Xen Summit, I sat in
for him and am providing this summary:
Here were the options under consideration:
1. Xen includes current patch Harry had put out, which
includes his IDC API.
2. Harry puts out a simpler USB driver without his IDC
API, written directly to the current Xen bus/store API,
and reducing to only features deemed needed for Xen,
see if that will be accepted into tree.
3. Examine USBoverIP patches (currently in -mm tree)
and see if those provide all the functionality we
need.
4. Throw away everything and have someone else rewrite
from scratch.
There was a brief discussion at the Client (Graphics,
USB...) session on USB. Ewan and several community folks
were present. Opinions expressed:
- Harry''s IDC code and current code will not make it
into tree as is [consensus]
- IDC piece very unlikely to be accepted into Linux mainline,
hence should not go into Xen tree
- API code is orthogonal to USB driver piece, should be
a seperate patch/discussion [consensus]
- Best option is (2), rewrite code to leaner, simpler
USB driver with minimal functionality, and get that into
tree
- Noone in session had looked at USBoverIp patches
- There were some good ideas in the IDC API that needed
to be discussed/incorporated in Xen
Other input/questions received:
- Need to get USB community input
- What were the issues that were left? Are they resolved?
If so, what''s the current working state of the patch?
- Keir: rewrite to a simpler driver without the IDC API
as the xenbus/store stuff is pretty baked into Xen now,
might want to do some cleanups in this area.
- Ian: look at USBoverIP, tried it and it seems to
work, but not sure if that''s the right solution
Current Issues/Design questions:
- Harry''s code supports back/front module load/unload
(useful during development, if nothing else).
- Harry''s code is not written to Ewan''s last common
code pullout API
- What other code functionality can be dropped in order
to make it smaller?
[All misrepresentations and errors are mine, I''m operating
from memory and on occasion what I heard over the crowd noise :)]
Hope that initiates the necessary conversation on this...
thanks,
Nivedita
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Hi Nivedita, Thanks for the summary, sounds good.> 2. Harry puts out a simpler USB driver without his IDC > API, written directly to the current Xen bus/store API, > and reducing to only features deemed needed for Xen, > see if that will be accepted into tree.This would be my preference, as a first step. We don''t want to lose the benefits of having a better abstraction layer, either, but it would be good to revisit that later.> 4. Throw away everything and have someone else rewrite > from scratch.Probably unnecessary, and we really ought to benefit from the debugging of interacting with USB subtleties that has gone into this code.> - IDC piece very unlikely to be accepted into Linux mainline, > hence should not go into Xen treeIf it were used more generally as an abstraction layer for Xen drivers it seems to me acceptance upstream shouldn''t be such a problem. Ideally, we''d probably want some way of converting old drivers to new and better abstractions without breaking ABIs - I guess this really comes under the heading of incorporating the concepts into the XenBus code. Harry has also mentioned the possibility of allowing networked implementations of driver interfaces: saves us from having to use 3rd party network protocols (like the USBoIP work) when migrating, etc. It''d be nice if we could at least maintain the backend in such a way that adding this wouldn''t be too painful. Local access is far more important though - we can always figure out ways to export stuff over the network based on this.> - API code is orthogonal to USB driver piece, should be > a seperate patch/discussion [consensus]Yes. It''s more work to do this, but good to be able to tackle stuff in smaller chunks.> - Best option is (2), rewrite code to leaner, simpler > USB driver with minimal functionality, and get that into > tree > - Noone in session had looked at USBoverIp patchesThe USBoIP patches seem to be rather full-featured, and they do support isochronous transfers (I don''t think the Xen USB driver supports this anymore, but it used to in the 2.4 days and there is code in the original patches that could be brought back). However, I don''t relying on IP for USB is a good idea, and rewriting the USBoIP driver to use local transfers doesn''t necessarily seem any easier than rewriting the other code.> - There were some good ideas in the IDC API that needed > to be discussed/incorporated in XenYep.> - Need to get USB community inputHarry has been doing this recently, I believe.> - Keir: rewrite to a simpler driver without the IDC API > as the xenbus/store stuff is pretty baked into Xen now, > might want to do some cleanups in this area.It seems to me that integration with XenStore will offer opportunities to improve XenStore / XenBus concurrently.> - Ian: look at USBoverIP, tried it and it seems to > work, but not sure if that''s the right solutionAgreed.> Current Issues/Design questions: > - Harry''s code supports back/front module load/unload > (useful during development, if nothing else).Would be nice to keep this functionality - and extend to other devices. But probably not critical, unless it really speeds up development a lot.> - What other code functionality can be dropped in order > to make it smaller?I don''t think having complete USB functionality is mutually exclusive with the driver being *reasonably* small, especially with the 2.6 kernel USB client API. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2006-02-01 at 08:28 -0800, Nivedita Singhvi wrote:> Since Harry Butterworth, who''s been working on the USB > virtualization couldn''t attend the Xen Summit, I sat in > for him and am providing this summary: > > Here were the options under consideration: > > 1. Xen includes current patch Harry had put out, which > includes his IDC API. > 2. Harry puts out a simpler USB driver without his IDC > API, written directly to the current Xen bus/store API, > and reducing to only features deemed needed for Xen, > see if that will be accepted into tree. > 3. Examine USBoverIP patches (currently in -mm tree) > and see if those provide all the functionality we > need. > 4. Throw away everything and have someone else rewrite > from scratch. > > There was a brief discussion at the Client (Graphics, > USB...) session on USB. Ewan and several community folks > were present. Opinions expressed: > > - Harry''s IDC code and current code will not make it > into tree as is [consensus] > - IDC piece very unlikely to be accepted into Linux mainline, > hence should not go into Xen treeWould someone please explain why people thought the xenidc code is unlikely to get accepted into mainline? It seems to me that Linux has a common network stack for the different network card drivers and a common USB stack for the different USB devices---I don''t see why Xen shouldn''t have a common inter-domain communication stack for the different virtual xen devices. Is it that there are style issues remaining? Or perhaps it''s the problem of better integrating the code with the current Xen infrastructure. I did spend a week or so trying to work out what the best way to integrate was and came to the conclusion that the best bet (with minimum impact to ongoing development) was to leave the existing xen drivers and API in place and write a new set of drivers to the new API on the side making the choice of old or new driver selectable in the Kconfig. After the new drivers were stable it would be possible to remove the old ones and then remove the old API and coalesce the infrastructure code. The other approach of attempting to make atomic incremental changes to the existing API and all the drivers is just going to destabilise the tree and impact out-of-tree development too much.> - API code is orthogonal to USB driver piece, should be > a seperate patch/discussion [consensus]I needed a stable API to code the driver to which is why I did both together. Now the native Xen API is more stable I''m doing a version of the USB driver with the xenidc code factored out.> - Best option is (2), rewrite code to leaner, simpler > USB driver with minimal functionality, and get that into > treeFactoring out the xenidc code just means duplicating the function it provided in the usbback and usbfront directories, replacing the xenidc channel code with a version constructed using the ring macros and making use of Ewan''s state change info to drive connect/disconnect. Whilst the sum of xenidc and the USB driver code will be reduced I''m not sure that the USB driver itself is actually going to get that much smaller with the low-level comms code put back into it.> - Noone in session had looked at USBoverIp patches > - There were some good ideas in the IDC API that needed > to be discussed/incorporated in Xen > > Other input/questions received: > - Need to get USB community inputI have had some input on the design which has been helpful. I posted a code snippet too which led to a discussion about changing Linux to make it possible to bind to devices rather than interfaces.> - What were the issues that were left? Are they resolved? > If so, what''s the current working state of the patch?No, I have wasted too much time on the Xen APIs to have got around to the remaining issues yet. In particular, a correct solution to the problem of stalling and retrying URBs during error recovery looks fairly tricky. Also changes are required in Linux to allow binding to a USB device rather than an interface so as to allow the correct handling of devices with multiple configurations. Having said this, I don''t think the remaining USB issues should be the thing that stops the driver from going into the tree. My intention was always just to get the basic function working and then let it get improved afterwards. The problem has been syncing up with the xen driver infrastructure. The current state of the patch is that when I last posted it it was working for my test USB devices (USB key, keyboard) against the then current unstable tree. Since then the unstable tree has moved on---the xenbus API has changed slightly, all the header files have been moved and the Kconfig file has been split up---the version of the driver that I''m factoring xenidc out of compiles but is currently untested.> - Keir: rewrite to a simpler driver without the IDC API > as the xenbus/store stuff is pretty baked into Xen now,The xenbus/xenstore APIs are pretty bad from the device driver side. It would be a shame to have to live with them indefinitely. In particular, I think that the following issues need to be addressed: 1) The RING macros and interrupt handlers for inter-domain messages are too difficult to use. The interrupt handler code to service the ring queue correctly is pretty subtle and it''s totally unnecessary to have this functionality duplicated in each driver. 2) The low-level memory manipulation in drivers is unnecessary. Linux has DMA APIs to do DMA. Xen should have equivalent high-level APIs for inter-domain bulk data transport. I pointed this out at the first Xen summit and Christian claimed it was impossible because each driver required specific performance optimisations but I think the xenidc code demonstrates that it is actually quite easy to achieve without having to sacrifice performance. 3) Marshalling parameters from xenstore. This wasn''t addressed by xenidc but it''s quite clear that the driver-side xenstore API is not a good match for the C programming language. On device create, it would be much easier to get parameters in a struct. If it''s necessary to register an XML definition of the struct expected that would be OK. 4) Sequencing operations using xenstore. This is a real problem because of the level-sensitive nature of watches on the store. From the driver''s perspective if there''s going to be a hot configuration change, the easiest interface to deal with is receiving the reconfiguration request and all the parameters in one operation in a struct. Again, having to marshall the parameters individually and then work out which ones have changed and what configuration request that implies is just too painful. 5) The xenbus otherend_changed state machine API. This API is largely a result of having half of the communication channel implementation in xenbus and the other half in the drivers. Xenidc demonstrates a better channel implementation and a better driver API here. 6) I''m not sure that the function in the xenbus state machine which drives a clean shutdown from the back-end closing is useful because the FE can just flush if it wants to do a clean shutdown. On the other hand, for multi-pathing device drivers it''s more normal for FE''s to have to deal cleanly with unclean termination of a channel BE which isn''t catered for in the xenbus state machine. 7) Exposing the implementation details of everything in xenstore isn''t good from the point of view of creating a well defined API for third parties. I get the impression this is being addressed by using XML-RPC to define a public interface to xend which I think is probably a good thing.> might want to do some cleanups in this area. > - Ian: look at USBoverIP, tried it and it seems to > work, but not sure if that''s the right solution > > Current Issues/Design questions: > - Harry''s code supports back/front module load/unload > (useful during development, if nothing else).Without working driver domains I was finding module unload of the back-end useful because it saves a 5 min reboot. Driver domains are not quite as useful as module unload because you have to reboot both the FE and BE domains whereas with module unload you can leave the FE set up.> - Harry''s code is not written to Ewan''s last common > code pullout API > - What other code functionality can be dropped in order > to make it smaller?A fair amount of code comes from doing pre-allocation of resources and resource management. This means that once the module is initialised it has all the resources required to guarantee progress is made with normal operation. If I drop all the resource management stuff and just do allocations on the I/O path and allow I/O failures due to ENOMEM then I can make the code simpler. I think the current bounded approach is better though.> > [All misrepresentations and errors are mine, I''m operating > from memory and on occasion what I heard over the crowd noise :)] > > Hope that initiates the necessary conversation on this...Thanks Niv, very useful.> > thanks, > Nivedita > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello, Forgive my ignorance : (I don''t know much about USB) what does IDC stand for in the contetx of Xen USB? is it some type of connector " ( (by gogoling I found many results , like: IDC connector, Internet Direct Connection and others) TIA M. On 2/1/06, Nivedita Singhvi <nsnix@comcast.net> wrote:> Since Harry Butterworth, who''s been working on the USB > virtualization couldn''t attend the Xen Summit, I sat in > for him and am providing this summary: > > Here were the options under consideration: > > 1. Xen includes current patch Harry had put out, which > includes his IDC API. > 2. Harry puts out a simpler USB driver without his IDC > API, written directly to the current Xen bus/store API, > and reducing to only features deemed needed for Xen, > see if that will be accepted into tree. > 3. Examine USBoverIP patches (currently in -mm tree) > and see if those provide all the functionality we > need. > 4. Throw away everything and have someone else rewrite > from scratch. > > There was a brief discussion at the Client (Graphics, > USB...) session on USB. Ewan and several community folks > were present. Opinions expressed: > > - Harry''s IDC code and current code will not make it > into tree as is [consensus] > - IDC piece very unlikely to be accepted into Linux mainline, > hence should not go into Xen tree > - API code is orthogonal to USB driver piece, should be > a seperate patch/discussion [consensus] > - Best option is (2), rewrite code to leaner, simpler > USB driver with minimal functionality, and get that into > tree > - Noone in session had looked at USBoverIp patches > - There were some good ideas in the IDC API that needed > to be discussed/incorporated in Xen > > Other input/questions received: > - Need to get USB community input > - What were the issues that were left? Are they resolved? > If so, what''s the current working state of the patch? > - Keir: rewrite to a simpler driver without the IDC API > as the xenbus/store stuff is pretty baked into Xen now, > might want to do some cleanups in this area. > - Ian: look at USBoverIP, tried it and it seems to > work, but not sure if that''s the right solution > > Current Issues/Design questions: > - Harry''s code supports back/front module load/unload > (useful during development, if nothing else). > - Harry''s code is not written to Ewan''s last common > code pullout API > - What other code functionality can be dropped in order > to make it smaller? > > [All misrepresentations and errors are mine, I''m operating > from memory and on occasion what I heard over the crowd noise :)] > > Hope that initiates the necessary conversation on this... > > thanks, > Nivedita > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Forgive my ignorance : (I don''t know much about USB) > what does IDC stand for in the contetx of Xen USB?Harry wrote a generic InterDomain Communication library (IDC); the existing USB code is a client of this. Part of the debate has been whether both should be merged, or whether USB support without IDC should be merged and then IDC features considered for gradual inclusion later. Cheers, Mark> is it some type of connector " ( > (by gogoling I found many results , like: IDC connector, > Internet Direct Connection and others) > > TIA > M. > > On 2/1/06, Nivedita Singhvi <nsnix@comcast.net> wrote: > > Since Harry Butterworth, who''s been working on the USB > > virtualization couldn''t attend the Xen Summit, I sat in > > for him and am providing this summary: > > > > Here were the options under consideration: > > > > 1. Xen includes current patch Harry had put out, which > > includes his IDC API. > > 2. Harry puts out a simpler USB driver without his IDC > > API, written directly to the current Xen bus/store API, > > and reducing to only features deemed needed for Xen, > > see if that will be accepted into tree. > > 3. Examine USBoverIP patches (currently in -mm tree) > > and see if those provide all the functionality we > > need. > > 4. Throw away everything and have someone else rewrite > > from scratch. > > > > There was a brief discussion at the Client (Graphics, > > USB...) session on USB. Ewan and several community folks > > were present. Opinions expressed: > > > > - Harry''s IDC code and current code will not make it > > into tree as is [consensus] > > - IDC piece very unlikely to be accepted into Linux mainline, > > hence should not go into Xen tree > > - API code is orthogonal to USB driver piece, should be > > a seperate patch/discussion [consensus] > > - Best option is (2), rewrite code to leaner, simpler > > USB driver with minimal functionality, and get that into > > tree > > - Noone in session had looked at USBoverIp patches > > - There were some good ideas in the IDC API that needed > > to be discussed/incorporated in Xen > > > > Other input/questions received: > > - Need to get USB community input > > - What were the issues that were left? Are they resolved? > > If so, what''s the current working state of the patch? > > - Keir: rewrite to a simpler driver without the IDC API > > as the xenbus/store stuff is pretty baked into Xen now, > > might want to do some cleanups in this area. > > - Ian: look at USBoverIP, tried it and it seems to > > work, but not sure if that''s the right solution > > > > Current Issues/Design questions: > > - Harry''s code supports back/front module load/unload > > (useful during development, if nothing else). > > - Harry''s code is not written to Ewan''s last common > > code pullout API > > - What other code functionality can be dropped in order > > to make it smaller? > > > > [All misrepresentations and errors are mine, I''m operating > > from memory and on occasion what I heard over the crowd noise :)] > > > > Hope that initiates the necessary conversation on this... > > > > thanks, > > Nivedita > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. Regards, Anthony Liguori> It seems to me that Linux has a >common network stack for the different network card drivers and a common >USB stack for the different USB devices---I don''t see why Xen shouldn''t >have a common inter-domain communication stack for the different virtual >xen devices. Is it that there are style issues remaining? Or perhaps >it''s the problem of better integrating the code with the current Xen >infrastructure. > >I did spend a week or so trying to work out what the best way to >integrate was and came to the conclusion that the best bet (with minimum >impact to ongoing development) was to leave the existing xen drivers and >API in place and write a new set of drivers to the new API on the side >making the choice of old or new driver selectable in the Kconfig. After >the new drivers were stable it would be possible to remove the old ones >and then remove the old API and coalesce the infrastructure code. The >other approach of attempting to make atomic incremental changes to the >existing API and all the drivers is just going to destabilise the tree >and impact out-of-tree development too much. > > > >>- API code is orthogonal to USB driver piece, should be >> a seperate patch/discussion [consensus] >> >> > >I needed a stable API to code the driver to which is why I did both >together. Now the native Xen API is more stable I''m doing a version of >the USB driver with the xenidc code factored out. > > > >>- Best option is (2), rewrite code to leaner, simpler >> USB driver with minimal functionality, and get that into >> tree >> >> > >Factoring out the xenidc code just means duplicating the function it >provided in the usbback and usbfront directories, replacing the xenidc >channel code with a version constructed using the ring macros and making >use of Ewan''s state change info to drive connect/disconnect. > >Whilst the sum of xenidc and the USB driver code will be reduced I''m not >sure that the USB driver itself is actually going to get that much >smaller with the low-level comms code put back into it. > > > >>- Noone in session had looked at USBoverIp patches >>- There were some good ideas in the IDC API that needed >> to be discussed/incorporated in Xen >> >>Other input/questions received: >>- Need to get USB community input >> >> > >I have had some input on the design which has been helpful. I posted a >code snippet too which led to a discussion about changing Linux to make >it possible to bind to devices rather than interfaces. > > > >>- What were the issues that were left? Are they resolved? >> If so, what''s the current working state of the patch? >> >> > >No, I have wasted too much time on the Xen APIs to have got around to >the remaining issues yet. In particular, a correct solution to the >problem of stalling and retrying URBs during error recovery looks fairly >tricky. Also changes are required in Linux to allow binding to a USB >device rather than an interface so as to allow the correct handling of >devices with multiple configurations. > >Having said this, I don''t think the remaining USB issues should be the >thing that stops the driver from going into the tree. My intention was >always just to get the basic function working and then let it get >improved afterwards. The problem has been syncing up with the xen >driver infrastructure. > >The current state of the patch is that when I last posted it it was >working for my test USB devices (USB key, keyboard) against the then >current unstable tree. Since then the unstable tree has moved on---the >xenbus API has changed slightly, all the header files have been moved >and the Kconfig file has been split up---the version of the driver that >I''m factoring xenidc out of compiles but is currently untested. > > > >>- Keir: rewrite to a simpler driver without the IDC API >> as the xenbus/store stuff is pretty baked into Xen now, >> >> > >The xenbus/xenstore APIs are pretty bad from the device driver side. It >would be a shame to have to live with them indefinitely. > >In particular, I think that the following issues need to be addressed: > >1) The RING macros and interrupt handlers for inter-domain messages are >too difficult to use. The interrupt handler code to service the ring >queue correctly is pretty subtle and it''s totally unnecessary to have >this functionality duplicated in each driver. > >2) The low-level memory manipulation in drivers is unnecessary. Linux >has DMA APIs to do DMA. Xen should have equivalent high-level APIs for >inter-domain bulk data transport. I pointed this out at the first Xen >summit and Christian claimed it was impossible because each driver >required specific performance optimisations but I think the xenidc code >demonstrates that it is actually quite easy to achieve without having to >sacrifice performance. > >3) Marshalling parameters from xenstore. This wasn''t addressed by >xenidc but it''s quite clear that the driver-side xenstore API is not a >good match for the C programming language. On device create, it would >be much easier to get parameters in a struct. If it''s necessary to >register an XML definition of the struct expected that would be OK. > >4) Sequencing operations using xenstore. This is a real problem because >of the level-sensitive nature of watches on the store. From the >driver''s perspective if there''s going to be a hot configuration change, >the easiest interface to deal with is receiving the reconfiguration >request and all the parameters in one operation in a struct. Again, >having to marshall the parameters individually and then work out which >ones have changed and what configuration request that implies is just >too painful. > >5) The xenbus otherend_changed state machine API. This API is largely a >result of having half of the communication channel implementation in >xenbus and the other half in the drivers. Xenidc demonstrates a better >channel implementation and a better driver API here. > >6) I''m not sure that the function in the xenbus state machine which >drives a clean shutdown from the back-end closing is useful because the >FE can just flush if it wants to do a clean shutdown. On the other >hand, for multi-pathing device drivers it''s more normal for FE''s to have >to deal cleanly with unclean termination of a channel BE which isn''t >catered for in the xenbus state machine. > >7) Exposing the implementation details of everything in xenstore isn''t >good from the point of view of creating a well defined API for third >parties. I get the impression this is being addressed by using XML-RPC >to define a public interface to xend which I think is probably a good >thing. > > > >> might want to do some cleanups in this area. >>- Ian: look at USBoverIP, tried it and it seems to >> work, but not sure if that''s the right solution >> >>Current Issues/Design questions: >>- Harry''s code supports back/front module load/unload >> (useful during development, if nothing else). >> >> > >Without working driver domains I was finding module unload of the >back-end useful because it saves a 5 min reboot. Driver domains are not >quite as useful as module unload because you have to reboot both the FE >and BE domains whereas with module unload you can leave the FE set up. > > > >>- Harry''s code is not written to Ewan''s last common >> code pullout API >>- What other code functionality can be dropped in order >> to make it smaller? >> >> > >A fair amount of code comes from doing pre-allocation of resources and >resource management. This means that once the module is initialised it >has all the resources required to guarantee progress is made with normal >operation. If I drop all the resource management stuff and just do >allocations on the I/O path and allow I/O failures due to ENOMEM then I >can make the code simpler. > >I think the current bounded approach is better though. > > > >>[All misrepresentations and errors are mine, I''m operating >> from memory and on occasion what I heard over the crowd noise :)] >> >>Hope that initiates the necessary conversation on this... >> >> > >Thanks Niv, very useful. > > > >>thanks, >>Nivedita >> >> >>_______________________________________________ >>Xen-devel mailing list >>Xen-devel@lists.xensource.com >>http://lists.xensource.com/xen-devel >> >> >> > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel