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

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

[Woodruff, Robert J]

I think that we tried to isolate a lot of these kernel calls into
one library, the component library, so that when the kernel APIs change,
which seems to happen every release, we only have to change the code 
in one spot. 

This actually helps porting to new kernels. For example, I think that
it only took a week to get the IBAL code to compile on 2.6 since all or
most 
of the kernel dependencies were isolated to one module. 

It also then allows most of the code to remain very readable, since we
don't have to put #ifdefs all over the place when an API or kernel data
structure changes. 

Are there any other examples of drivers that isolate kernel specific
calls
to one module or file of their code to ease portability between
different revisions
of the kernel ? If not, maybe they should look at what we have done,
it might save them some headaches in the future. 



-----Original Message-----
From: infiniband-general-admin@lists.sourceforge.net
[mailto:infiniband-general-admin@lists.sourceforge.net] On Behalf Of
King, Steven R
Sent: Thursday, February 05, 2004 11:39 AM
To: Greg KH; linux-kernel@vger.kernel.org
Cc: infiniband-general@lists.sourceforge.net
Subject: RE: [Infiniband-general] Getting an Infiniband access layer in
the linux kernel


We just use the kernel's spin_lock_irqsave(), so I don't know what
you're talking about.

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com] 
Sent: Thursday, February 05, 2004 10:55 AM
To: King, Steven R; linux-kernel@vger.kernel.org
Cc: 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:27:54AM -0800, King, Steven R wrote:
> Hi Greg,
> What exactly is wrong with spinlock?  Far as I know, it's been working

> bug-free on a variety of platforms for quite some time now.  The other

> abstractions such as atomic_t are for platform portability.

Again, compare them to the current kernel spinlocks and try to realize
why your implementation of spinlock_irqsave() will not work on all
platforms.

Come on, just use the kernel versions, there is no need to reinvent the
wheel all of the time, it just wastes everyones time (including mine...)

thanks,

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/infiniband-general

Re: [Infiniband-general] Getting an Infiniband access layer in the linux kernel

[Greg KH]

On Thu, Feb 05, 2004 at 12:16:17PM -0800, Woodruff, Robert J wrote:
> I think that we tried to isolate a lot of these kernel calls into
> one library, the component library, so that when the kernel APIs change,
> which seems to happen every release, we only have to change the code 
> in one spot. 

Then get your code into the kernel tree, and you will not have to worry
about this "problem".  Remember, that is what we are talking about here.
If you want to keep your "compatibility" library in your out-of-tree
code, that's fine with me, I don't care.

It's when you try to push that into the main kernel tree that I start to
care.

> Are there any other examples of drivers that isolate kernel specific
> calls to one module or file of their code to ease portability between
> different revisions of the kernel ? If not, maybe they should look at
> what we have done, it might save them some headaches in the future. 

No, that is not how Linux kernel development is done.  Come on people,
do your research...

greg k-h

Infiniband thread(s) and etiquette.

[David Woodhouse]

I had killed this thread because I was not particularly interested in
it. I have not looked at the code in question, and
QuiteFranklyIDontReallyWantToBecause I can imagine what kind of WORDs I
would end up using if I tried :)

However, people keep starting _new_ threads on the same subject.

Please, be polite. Do not top-post upside-down messages, and do not use
a mailer which is so broken it omits 'References:' and 'In-Reply-To:'
headers from replies, and hence breaks threading. It is simply not
acceptable. 

I think it's time the list started to automatically bounce messages with
'Re: ' in the subject line but lacking any form of references. There are
enough non-broken mail programs in the world; we don't have to let
inconsiderate people use broken ones just because they happen to like
it. The signal-to-noise ratio is low enough without that kind of
rudeness.

-- 
dwmw2

Re: [Infiniband-general] Getting an Infiniband access layer in the linux kernel

[Jamie Lokier]

Greg KH wrote:
> > Are there any other examples of drivers that isolate kernel specific
> > calls to one module or file of their code to ease portability between
> > different revisions of the kernel ? If not, maybe they should look at
> > what we have done, it might save them some headaches in the future. 
> 
> No, that is not how Linux kernel development is done.  Come on people,
> do your research...

To clarify:

For out-of-tree 3rd party drivers, there are two or three
"compatibility" packages which are used to allow a single driver
source to work with many kernel versions.  (I wrote one, it is used
for quite a few private drivers.  This method works well.  See
also "kcompat").

For drivers in the kernel tree, or drivers that somone would like to
go into the tree, "compatibility" headers are never used.  API changes
are for good reasons; drivers need to be updated to follow them.

When the kernel APIs change, for minor changes and sometimes even
major ones, the author of the API change will often go through all the
in tree drivers making the necessary changes.

-- Jamie

Re: Infiniband thread(s) and etiquette.

[Pete Zaitcev]

On Thu, 05 Feb 2004 22:58:00 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> However, people keep starting _new_ threads on the same subject.

Dude, I was subscribed to Infiniband-general until a week ago, and
I had to fish their messages out from +spam.html folder. This is quite
beyond repair. Just killfile with subject regex and be done with it.

> I think it's time the list started to automatically bounce messages with
> 'Re: ' in the subject line but lacking any form of references.

Might be a good idea, althoug you know, it's pretty tough to extract
references if Nate's gateway at post-office ate them. And I cannot
live without NNTP.

-- Pete