[ofa-general] RFC: "mlx4" drivers for Mellanox ConnectX HCAs

Roland Dreier rdreier at cisco.com
Mon Apr 16 09:34:25 PDT 2007


 > a. How will I know whether or not I've got the most recent version with
 >    all your changes -- does the commit ID change, for example?

Yes, commit ID will always be different, since it is in effect a SHA1
hash of the full tree state (and a collision is unlikely, to say the
least).

 > b. git fetch gives me problems, since the commits diverge -- my version
 >    of the connectx branch is not a strict descendent of yours with respect to
 >    the connectx changes, since the connectx commits themselves have changed.
 >    (I of course do not fetch directly into my working branch, but into
 >     an origin -- and this origin does not match the commits in your
 >     connectx branch).
 > 
 > c. I think we need to start working with regular commits, so that 
 >    each change can be documented, and git fetch/rebase can work smoothly.

Yes, I guess it is a pain now that we are collaborating actively.  OK,
I'll just check into the branch normally, and we can collapse the
patches down when I create a branch for Linus to pull.  I have one
more rebase pending, and then I'll leave the branch alone.

 > Tziporet has requested that I implement the write-combining support.
 > I'll be doing that first thing.

What is your plan for doing this?  I had the following vague idea:

 - Make pgprot_writecombine() a supported API for drivers that all
   architectures should provide (it can be defined to be the same as
   pgprot_noncached() for architectures where a write-combining
   mapping doesn't make sense).
 - Add an API ioremap_writecombine() that does the same thing for
   kernel space.
 - Add PAT-based implementations for x86-64 and i386 architectures.

Are you going to add inline send support for mlx4 (kernel and libmlx4) first?

 - R.



More information about the general mailing list