From: "Randy.Dunlap" <rddunlap@osdl.org>
To: "Tillier, Fabian" <ftillier@infiniconsys.com>
Cc: greg@kroah.com, sean.hefty@intel.com,
linux-kernel@vger.kernel.org, hozer@hozed.org,
woody@co.intel.com, bill.magro@intel.com, woody@jf.intel.com,
infiniband-general@lists.sourceforge.net
Subject: Re: [Infiniband-general] Getting an Infiniband access layer in the Linux kernel
Date: Thu, 5 Feb 2004 10:53:26 -0800 [thread overview]
Message-ID: <20040205105326.02605043.rddunlap@osdl.org> (raw)
In-Reply-To: <08628CA53C6CBA4ABAFB9E808A5214CB01DB96A4@mercury.infiniconsys.com>
On Thu, 5 Feb 2004 13:31:45 -0500 "Tillier, Fabian" <ftillier@infiniconsys.com> wrote:
| 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.
Besides Greg's comments:
Can (will) you provide specific examples of these differences/problems?
They need to be quashed.
Thanks.
| 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@kroah.com]
| Sent: Thursday, February 05, 2004 10:10 AM
| To: Hefty, Sean; linux-kernel@vger.kernel.org
| Cc: Troy Benjegerdes; Woodruff, Robert J; Magro, Bill; Woodruff, Robert
| J; infiniband-general@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
--
~Randy
kernel-janitors project: http://janitor.kernelnewbies.org/
next prev parent reply other threads:[~2004-02-05 18:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-05 18:31 Tillier, Fabian
2004-02-05 18:40 ` Greg KH
2004-02-05 18:53 ` Randy.Dunlap [this message]
2004-02-07 2:54 ` Jamie Lokier
-- strict thread matches above, loose matches on Subject: below --
2004-02-05 20:16 [Infiniband-general] Getting an Infiniband access layer in the linux kernel Woodruff, Robert J
2004-02-05 21:54 ` Greg KH
2004-02-06 23:20 ` Jamie Lokier
2004-02-05 19:44 [Infiniband-general] Getting an Infiniband access layer in the Linux kernel Tillier, Fabian
2004-02-05 20:16 ` Greg KH
2004-02-05 19:38 [Infiniband-general] Getting an Infiniband access layer in the linux kernel King, Steven R
2004-02-05 21:51 ` Greg KH
2004-02-05 19:31 Raj, Ashok
[not found] <33561BB7A415E04FBDC339D5E149C6E26C38FA@orsmsx405.jf.intel.com>
2004-02-05 18:55 ` Greg KH
2004-02-05 18:34 Raj, Ashok
[not found] <C1B7430B33A4B14F80D29B5126C5E94703262582@orsmsx401.jf.intel.com>
2004-02-05 18:09 ` Greg KH
2004-02-04 4:53 Woodruff, Robert J
2004-02-04 2:01 Woodruff, Robert J
2004-02-04 4:08 ` Troy Benjegerdes
2004-02-04 0:17 Woodruff, Robert J
2004-02-04 1:03 ` Greg KH
2004-02-03 16:45 Woodruff, Robert J
2004-02-04 11:26 ` Masanori ITOH
2004-02-02 23:58 Woodruff, Robert J
2004-02-03 0:56 ` Greg KH
2004-02-03 1:38 ` Masanori ITOH
2004-02-03 22:37 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040205105326.02605043.rddunlap@osdl.org \
--to=rddunlap@osdl.org \
--cc=bill.magro@intel.com \
--cc=ftillier@infiniconsys.com \
--cc=greg@kroah.com \
--cc=hozer@hozed.org \
--cc=infiniband-general@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sean.hefty@intel.com \
--cc=woody@co.intel.com \
--cc=woody@jf.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®