RE: [Infiniband-general] Getting an Infiniband access layer in the Linux kernel

["Tillier, Fabian" <ftillier _at_ xxxxxxxxxxxxxxxx>]

Greg,

The atomic operation abstraction is there because atomic support has
different prototypes between x86 and IA64 (at least it did when it was
written), with some of the x86 functions not returning values while the
IA64 ones did.  Further, comments in the x86 code base indicated that
only 24-bits are actually valid (probably from some i386 limitation that
is no longer relevant).  Thus, the implementation of atomic operations
for the x86 processor architecture fails a build (via #error) if you're
targeting an i386 processor, and provides the same semantics independent
of processor architecture.

To answer your broader question, the reason to have abstraction is to
facilitate portability.  I'm not just talking about portability between
different operating systems, but even portability between different
versions of Linux distributions and kernels.  Differences between Linux
distributions and kernel versions can be handled in a single place,
avoiding the need to pepper the rest of the code base with #ifdefs.
This results in more readable and maintainable code for the rest of the
project by concentrating platform specific issues to the abstraction
layer.

Are you suggesting that if there is any abstraction, the code will never
be accepted?  Or rather that the abstraction better be correct?  I'm
hoping for the latter, however please clarify.

- Fab

-----Original Message-----
From: Greg KH [mailto:greg _at_ kroah.com] 
Sent: Thursday, February 05, 2004 10:10 AM
To: Hefty, Sean; linux-kernel _at_ vger.kernel.org
Cc: Troy Benjegerdes; Woodruff, Robert J; Magro, Bill; Woodruff, Robert
J; infiniband-general _at_ lists.sourceforge.net
Subject: Re: [Infiniband-general] Getting an Infiniband access layer in
the linux kernel

On Thu, Feb 05, 2004 at 10:01:13AM -0800, Hefty, Sean wrote:
> As an FYI, the code is available for download on bitkeeper at
> http://infiniband.bkbits.net/iba.  We're still working on providing a
> tarball and patch for 2.6, but if you would like to see the code now,
it
> is available.

Oh, I've seen that code, and still feel ill after looking at some of
it...

Come on, implementing your own spinlocks (and getting it wrong) and
atomit_t?  Why in the world would you _ever_ want to do that.

That code needs a _lot_ of cleanup to make it into the kernel tree.

Good luck,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Infiniband-general mailing list
Infiniband-general _at_ lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/infiniband-general
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/