Xen devel - Mar 2010 - first attempt of pvscai backend driver port to pvops

Attached is my first attempt at getting the backend pvscsi driver
(scsiback) working under the latest pvops kernel. I have tested it with
the scsi frontend driver in gplpv, and have restored about 20GB of data
from a HP LTO3 tape drive successfully, so it appears to be working
fine.

There are quite a few changes compared to the version in 2.6.18. The
main change is that I get the vaddr for each sg element and use the
regular dma calls to make it work instead of all the magic that the
2.6.18 version used to use that isn''t exported anymore.

I created a new branch in a local git repo, what git magic do I need to
weave to make the patch look a bit neater?

Thanks

James



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 03/11/2010 03:29 PM, James Harper wrote:
> Attached is my first attempt at getting the backend pvscsi driver
> (scsiback) working under the latest pvops kernel. I have tested it with
> the scsi frontend driver in gplpv, and have restored about 20GB of data
> from a HP LTO3 tape drive successfully, so it appears to be working
> fine.
>
> There are quite a few changes compared to the version in 2.6.18. The
> main change is that I get the vaddr for each sg element and use the
> regular dma calls to make it work instead of all the magic that the
> 2.6.18 version used to use that isn''t exported anymore.
>
> I created a new branch in a local git repo, what git magic do I need to
> weave to make the patch look a bit neater?
>    
It does need some cleaning up.  Run it through 
linux/scripts/checkpatch.pl and iterate until its fairly clean (as clean 
as possible without making it barbarous).  Most obvious is that kernel 
code uses 8-width hard tabs.

The patch also seems to contain usbback.  Did you mean to include it?  
Either way it shouldn''t be part of the scsi patches.

If possible and sensible, split the patch into logically separate parts 
(like introduce infrastructure, use infrastructure for a, for b, for 
c).  However for these kinds of "new subsystem" patches, it often
makes
most sense to just have one large patch adding the new code.

Please base the patches on (ideally) 2.6.31 or .32.  If you need some 
Xen infrastructure (which is likely), then base the patch on the 
xen/dom0/backend/common branch.

Mail your patches to the list for review (but, please, inlined plain 
text).  But the easiest way for me to include the patches is if I can 
pull them from your git server.  If you can''t make your own machine 
accessible, you can set up an account on github.com, or ask for an 
account on kernel.org.

I haven''t actually looked at the substance of the patch yet.

Thanks,
     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> It does need some cleaning up.  Run it through
> linux/scripts/checkpatch.pl and iterate until its fairly clean (as
clean
> as possible without making it barbarous).  Most obvious is that kernel
> code uses 8-width hard tabs.
> 
> The patch also seems to contain usbback.  Did you mean to include it?
I sure didn''t. Not sure how that got there...
 
> If possible and sensible, split the patch into logically separate
parts
> (like introduce infrastructure, use infrastructure for a, for b, for
> c).  However for these kinds of "new subsystem" patches, it often
makes
> most sense to just have one large patch adding the new code.
> 
> Please base the patches on (ideally) 2.6.31 or .32.  If you need some
> Xen infrastructure (which is likely), then base the patch on the
> xen/dom0/backend/common branch.
They are based on xen/master at the moment.
> Mail your patches to the list for review (but, please, inlined plain
> text).  But the easiest way for me to include the patches is if I can
> pull them from your git server.  If you can''t make your own
machine
> accessible, you can set up an account on github.com, or ask for an
> account on kernel.org.
I''ll look at doing that.
> 
> I haven''t actually looked at the substance of the patch yet.
> 
Probably best not to bother until I''ve cleaned up some of the above.

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Mar 12, 2010 at 11:37:05AM +1100, James Harper
wrote:
> > 
> > It does need some cleaning up.  Run it through
> > linux/scripts/checkpatch.pl and iterate until its fairly clean (as
> clean
> > as possible without making it barbarous).  Most obvious is that kernel
> > code uses 8-width hard tabs.
> > 
> > The patch also seems to contain usbback.  Did you mean to include it?
> 
> I sure didn''t. Not sure how that got there...
>  
> > If possible and sensible, split the patch into logically separate
> parts
> > (like introduce infrastructure, use infrastructure for a, for b, for
> > c).  However for these kinds of "new subsystem" patches, it
often
> makes
> > most sense to just have one large patch adding the new code.
> > 
> > Please base the patches on (ideally) 2.6.31 or .32.  If you need some
> > Xen infrastructure (which is likely), then base the patch on the
> > xen/dom0/backend/common branch.
> 
> They are based on xen/master at the moment.
> 
> > Mail your patches to the list for review (but, please, inlined plain
> > text).  But the easiest way for me to include the patches is if I can
> > pull them from your git server.  If you can''t make your own
machine
> > accessible, you can set up an account on github.com, or ask for an
> > account on kernel.org.
> 
> I''ll look at doing that.
> 
> > 
> > I haven''t actually looked at the substance of the patch yet.
> > 
> 
> Probably best not to bother until I''ve cleaned up some of the
above.
> 
Did you get it working? :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel