linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* PATCH - InfiniBand Access Layer (IBAL)
@ 2004-02-24 19:29 Woodruff, Robert J
  2004-02-24 19:44 ` Greg KH
  0 siblings, 1 reply; 41+ messages in thread
From: Woodruff, Robert J @ 2004-02-24 19:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg KH, Hefty, Sean, Coffman, Jerrie L, Davis, Arlin R,
	Woodruff, Robert J, marcelo.tosatti, torvalds


Since it is rather big,
I have posted a patch for the InfiniBand Access Layer (IBAL) 
for the linux-2.6.3 kernel on sourceforge in the file releases
area. 
http://sourceforge.net/projects/infiniband

We have already received some comments from Greg and others(such as 
not liking the Component library (Complib) abstraction layer)
and we are starting to make those changes. Greg suggested that
we submit the code to the larger Linux community for review, 
so here it is. 

Please let us know what other changes might be needed so that it is
acceptable for inclusion into the 2.6 base. 

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-02-24 21:33 Woodruff, Robert J
  0 siblings, 0 replies; 41+ messages in thread
From: Woodruff, Robert J @ 2004-02-24 21:33 UTC (permalink / raw)
  To: Greg KH, Woodruff, Robert J
  Cc: linux-kernel, Hefty, Sean, Coffman, Jerrie L, Davis, Arlin R,
	marcelo.tosatti, torvalds

On Tue, Feb 24, 2004 at 11:45:04AM -0800, Greg KH  wrote:
>The
http://osdn.dl.sourceforge.net/sourceforge/infiniband/patch-2_6_3-iba.bz
2
>patch is corrupted.
 
I may have made a mistake in upload to sourceforge. 
I tried to upload both a compressed patch file and a compressed 
tar file for those that do not want to deal with patches. 
I think it should be Ok now.  
Jerrie could you download the patch from sourceforge and take a 
look at it to make sure it is OK. 

>Please make those changes and then post the patch here 
>(not just a link, if it's too big, split it up into 
>the logical pieces to fit.)  We can go from there.

Ok, we will do that too. 


^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-02-24 22:18 Woodruff, Robert J
  0 siblings, 0 replies; 41+ messages in thread
From: Woodruff, Robert J @ 2004-02-24 22:18 UTC (permalink / raw)
  To: Greg KH, Christoph Hellwig, Woodruff, Robert J, linux-kernel,
	Hefty, Sean, Coffman, Jerrie L, Davis, Arlin R, marcelo.tosatti,
	torvalds

On Tue, Feb 24, 2004 at 07:50:18PM +0000, Greg KH wrote:

>Please make those changes and then post the patch here 
>(not just a link, if it's too big, split it up into the logical pieces
to fit.)  
> We can go from there.

> You mean this whole huge chunk of code doesn't have any hardware
drivers?  
> What good is it then?

Good to split things into chunks so that it is more manageable for
review
by the Linux community. 

Hardware drivers coming soon.
I saw an email on the InfiniBand sourceforge list 
a couple weeks back that the Mellanox people will be providing open
source code 
for their InfiniBand hardware pretty soon. It may need some rework to
meet the 
standards of the Linux community and fit into the reworked IBAL. I also
saw 
a note from a guy from Fujitsu on the Infiniband list 
that they have a 2.6 hardware driver for IBAL for their HCA, but I am
not 
sure of their open source plans. 
Pretty soon, I don't think people will need worry about a lack of
InfiniBand open 
source code. There may be more of it than you will want to deal with. 

BTW. The patch on sourceforge should be OK now. My error on initial
upload
and now fixed. 

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-02-24 23:02 Woodruff, Robert J
  2004-02-25  3:32 ` Rik van Riel
  0 siblings, 1 reply; 41+ messages in thread
From: Woodruff, Robert J @ 2004-02-24 23:02 UTC (permalink / raw)
  To: Rik van Riel
  Cc: Christoph Hellwig, Woodruff, Robert J, linux-kernel, Hefty, Sean,
	Coffman, Jerrie L, Davis, Arlin R, marcelo.tosatti, torvalds,
	Troy Benjegerdes, Greg KH

On Tue, 24 Feb 2004,  Rik van Riel wrote:
>Beats me. I hope we can just bury this infiniband stuff
>before we waste any more time on it.

>I really can't see any reason why we would want to have
>this.

You may want to start talking more with some of your customers. I'm
thinkin
they might have a different opinion about wanting InfiniBand support in
Linux. 
You can hide your head in the sand and hope it goes away, but I don't
think
it is going to. 

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-13 22:07 Woodruff, Robert J
  2004-03-14  1:13 ` Andrew Morton
  2004-03-14  2:28 ` Greg KH
  0 siblings, 2 replies; 41+ messages in thread
From: Woodruff, Robert J @ 2004-03-13 22:07 UTC (permalink / raw)
  To: Linus Torvalds, Sam Ravnborg, Greg KH
  Cc: Timothy Miller, Rik van Riel, Matti Aarnio, Christoph Hellwig,
	Woodruff, Robert J, linux-kernel, Hefty, Sean, Coffman, Jerrie L,
	Davis, Arlin R, marcelo.tosatti

On Wed, 25 Feb 2004, Linus Torvalds wrote:

>Oh, I agree that _reviewing_ code is good, together with feedback 
>on what would improve its chances of getting accepted later on. 
>But it should be clear that regardless, 
>we don't add features that nobody 
>can sanely test and where hardware isn't available.
>
>		Linus

Just wanted to give an update on where we are with the InfiniBand IBAL.

After we submitted the IBAL code for review, there has been additional
InfiniBand code put into open source by the major InfiniBand companies,
namely TopSpin, Mellanox, InfiniCon, and Voltaire.
This presents somewhat of a problem because now there are multiple 
versions of the various InfiniBand S/W components, Access Layers, and
ULPs.

We now need to review all this code and
determine which code is best to use as a basis for something that 
we would eventually try to get into Linux. We hope that people in the
linux community will help us sort through this mess and come up with
a "best of breed" stack out of all the available code. 

The Mellanox and Topspin folks along with some people from some of
the national labs are trying to start up a website called openib.org,
with data bases, email lists, etc. where people can submit code for
this "best of breed" stack and discuss it. As long as it is truly 
open, the linux community is allowed to participate, and the code
is evaluated on it's technical merits, rather than one companies
personal
agenda, this forum might serve as a way for us to sort through this
without
taking every issue to lkml. 

What are your thoughts on how we should proceed ? 







^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-14  3:46 Woodruff, Robert J
  2004-03-15  2:10 ` Greg KH
  0 siblings, 1 reply; 41+ messages in thread
From: Woodruff, Robert J @ 2004-03-14  3:46 UTC (permalink / raw)
  To: Greg KH, Woodruff, Robert J
  Cc: Linus Torvalds, Sam Ravnborg, Timothy Miller, Rik van Riel,
	Matti Aarnio, Christoph Hellwig, Woodruff, Robert J,
	linux-kernel, Hefty, Sean, Coffman, Jerrie L, Davis, Arlin R,
	marcelo.tosatti

On Sat, Mar 13, 2004 at 02:07:13PM -0800, Greg KH wrote:
>I think you need to work with the openib.org people as they seem to
>have:
>	- working code with support for a number of different devices
I have code that has been running MPI NBPs, Pallas benchmark, and IPoIB
stress tests
for almost 10 days now on multiple vendors equipment. We are also close
to having
a major data base vendor's DAPL stress test running very well.  I'm
thinkin this code could be
running 1000 nodes clusters within a couple of months, if people wanted
to try it,
but that would require Mellanox to open source their TVPD. 
>	- developers with extensive kernel programming experience
As if we don't. 
>	  working on cleaning up the code to fit properly into the
>	  kernel tree.
The comments you have given on IBAL would probably only take a few weeks
to change.
>	- their code showing up in at least one distro which will expose
>	  them to a much wider range of testing than Intel's project so
>	  far has had.
Ok, the OEMS pushed for and got a distro to accept a TTM solution,
that's OK for getting
InfiniBand jumpstarted, 
but does that mean we have to accept it into Linux 
and live with that solution forever. 

I guess I just wish they had started working with us on this open source
project 2 years ago
when we started it, rather than developing a complete stack behind
closed doors and then
releasing it without any input from anyone. Now there are serious issues
that will take a lot 
of work to fix. At least our project was totally open from the 
start and anyone could have provided input at any time. 

Enough said.

I understand your position.  We will submit our code to openib.org. 








^ permalink raw reply	[flat|nested] 41+ messages in thread
* Re: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-14 23:14 Nivedita Singhvi
  0 siblings, 0 replies; 41+ messages in thread
From: Nivedita Singhvi @ 2004-03-14 23:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Kernel Mailing List

> That is, of course, an excellent approach.
> 
> But beware of being *too* disconnected from the lists@vger.kernel.org.  We
> don't want to get in the situation where you pop up with a couple of
> person-years' worth of work and other kernel developers have major issues
> with it.  Please find a balance - some way of regularly checkpointing.

Andrew,

Thanks. I had wanted to convey the gist of what you say to someone
earlier this week.  It would have been nice to point to some document
that captures this, and though I looked around, I haven't found anything
in one place, surprisingly. It's a plea kernel maintainers frequently make
to Linux contributors, but new projects seem to run into the same problems
repeatedly. I figured it would be worth putting together your comments
and some basic related advice given to those wishing to get their
code into the kernel in a document. Hope that's ok.

File follows in a separate mail.

thanks,
Nivedita



^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-15 22:52 Woodruff, Robert J
  2004-03-15 23:17 ` Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 41+ messages in thread
From: Woodruff, Robert J @ 2004-03-15 22:52 UTC (permalink / raw)
  To: Greg KH, Woodruff, Robert J
  Cc: linux-kernel, Hefty, Sean, Coffman, Jerrie L, Davis, Arlin R

On Sun, Mar 14, Greg KH wrote:

First, As my boss remined me this morning,
let me make sure I was clear, there are not 2 different efforts now,
only one, openib.org. 

1) OpenIB represents a number of companies coming together with lots of
InfiniBand source code, 
with duplicate code for the access layer and most of the ULPs
2) the SourceForge work is already part of this
3) the foundation of infiniband support will be the Access Layer, so it
needs the community's feedback first
4) we are looking for feedback on both the access layer code in the
current openib snapshot and the access layer code that we submitted a
few weeks ago 
to learn which is more acceptable to the community.

Now to answer a couple specific questions. 

>Hm, without open source drivers, the Intel stack doesn't seem very 
>viable, correct?

Correct, that is why we hope that Mellanox contributes their driver for
IBAL to open source. 

>> The comments you have given on IBAL would probably only take a few
>> weeks to change.
>Is that work already underway?  Finished?  If neither, why not?

Work is, or at least was underway, but
we put it aside last week to review the rest of the code now in
openib.org.
We also need an open source driver.

>What are the issues with the OpenIB stack?  

As I stated above, we are part of the openib.org collaboration and 
will be working on helping develop a stack that is "best of
breed" from all of the available code. Starting from the bottom up, 
we first need to review the various proposals for the 
Access Layer and determine which code base to start with. 
The initial agreement was to use the 
TopSpin code for an access layer. This agreement was made before anyone
got to see any code. 
After review of this code, we think it needs a lot of work. We were
waiting for the openib.org email lists to open and sending in comments
there.
That way we could work a lot of details offline from lkml, since 
lots of discussion will be needed. 

But since you asked here are a few,

1.) The tsapi APIs look like Windows APIs (at least in the original
drop)
2.) Looking at the API specification document, 
It is missing lots of verbs required by the InfiniBand Specification
CloseCA, ModifyAV, QueryCQ, CreateEEC, ModifyEEC, QueryEEC, 
DestroyEEC, QueryMR, ReregisterMR, ReregisterPhysMR, RegisterSharedMR, 
AllocMW, QueryMW, BindMW, and FreeMW
3.) The code is not compliant with the InfiniBand specification and has
proprietary
implementations of things like "path records" so it will only work with
the 
TopSpin subnet manager that requires you to buy a topspin switch.
4.) Not sure if they have fixed this yet in the 2.6 code, but the 2.4
code 
has like 18 different loadable modules. This could probably be collapsed
into 5, one for the HCA driver, one for the access layer, one for the
IPoIB driver, one for the SRP driver and one for the SDP driver. 
5.) There is no user-mode access layer requiring ULPs to code to the HCA

user-mode driver APIs directly. 
This will mean that new user mode ULPs will need to be 
developed for each new HCA that comes along. 
6.)The VAPI code has extra propietary verbs that are not specified by
the InfiniBand 
Specification. 
7.) The implementation is deficient in it's support for InfiniBand
management
services, like the required RMPP protocol, MAD services, SA query helper
functions. 
8.) Some of the message fields of the CM are hard coded. 
9.) The CM does not support reliable datagrams. 
10) There is no built in support for plug and play events, port up/down,
LID change, SM change,
11) VAPI call stack is deep and puts a lot of big data structure on the
stack. 

There is more, but as I stated before, we suggest discussing most of
these issues within
openib.org first, trying to come to agreement on what is best and then
review our 
suggestions with lkml to make sure we are one track. 

>If there are any, how does the Intel stack solve those 
>issues?  

The SourceForge code IBAL(not just developed by Intel but has
contributions from several companies,
including InfiniCon, Mellanox, Fujitsu and Intel) 
is feature complete and compliant with the InfiniBand specification. It
may not be quite as
hardened as the TopSpin stack, but that gap is rapidly closing. 
We'd also like to know from the other openib.org people, 
What are the issues with the SourceForge IBAL ? 

We know the issues raised by lkml and think these can be fixed. 

The biggest problem I see is that we do not have an open source HCA
driver
and that could be fixed too, if Mellanox wanted to, or someone could
take the VAPI code they open sourced and port it to IBAL. 

>Could the Intel solutions be merged 
>into the OpenIB stack to solve these issues?

Given there are so many issues with the TSAPI, would it be easier to 
fix the issues lkml raised with IBAL and port the "best of breed" ULPs
to it ?
Since all the tsAPIs will have to change anyway, to non-Windows-ize
them, 
all the ULPs will need to be re-ported again anyway. 


^ permalink raw reply	[flat|nested] 41+ messages in thread
* Re: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-20 17:15 Acker, Dave
  2004-03-20 17:55 ` Ulrich Drepper
  0 siblings, 1 reply; 41+ messages in thread
From: Acker, Dave @ 2004-03-20 17:15 UTC (permalink / raw)
  To: linux-kernel

Ulrich Drepper <drepper@redhat.com> wrote in message
news:<1ByNc-1km-21@gated-at.bofh.it>...
> 
> First, the working group I refer to is this:
> 
>   http://www.opengroup.org/icsc/
> 
> But that's all there is.  The socket extension working group
> 
>   http://www.opengroup.org/icsc/sockets/
> 

Most of us IB folks wanted to work with the ICSC stuff waaaaay back but
it never went anywhere and we all had to ship products.  So various
stacks developed.  All that is being specified by the ICSC is an API.
There are already several APIs into IB that are not IB specific.
These include:
DAPL - http://www.datcollaborative.org/,
http://sourceforge.net/projects/dapl/ 
MPI - http://www-unix.mcs.anl.gov/mpi/ 
SDP - (not really an API but is run over IB verbs and RDMA verbs and
meets up with your sockets note) See InfiniBand Specification, Volume 1,
Annex A4, Release 1.1, http://www.rdmaconsortium.org/home 

There is no reason we can't implement support for the ICSC APIs if the
Linux community desires this.  I can say that these other APIs are
already being used by other programs (or other APIs themselves) and
really can't go away.  If folks ask for ICSC support, it will probably
get in there.

> So, these people come up with their own software stacks, unreviewed
> interface extensions, and demand that everybody accepts what they were
> "designing" without the ability to question anything.
> I surely find this completely  unacceptable and any consideration of
> accepting anything the Infiniband group comes up with should be
> postponed until every bit of the design can be reviewed.  If bits and
> pieces are accepted prematurely it'll just be "now that this is
support
> you have to add this too, otherwise it'll not be useful".

While some of the same people were on the ICSC lists as the IBTA lists
or the DAT lists, it doesn't mean that they are operating as one big
group with some secret agenda.  The ICSC group went one way and only
recently produced a spec.  The DAT group went another and has had a spec
for some time.  The RDMA folks went yet another and produced a spec a
bit ago.  While there are some people in both groups, the groups act
independently with different companies and individuals have more
control/influence in one than the other.

All that said, the IB developer community has decided as a whole to open
things up.  InfiniCon, TopSpin, Voltaire, DivergeNet, Mellanox, etc.
have all opened up their code.  Add to this the already started open
effort on sourceforge (IBAL) and we hope to find a best of breed final
solution.  So please do review every single bit posted.  If there is
going to be a standard linux infiniband stack it will have to be very
good or else splinter versions and incompatible versions will live on.

-Ack

p.s. While I may work for an IB company, I am expressing my own
opinions, not their official opinions.

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: PATCH - InfiniBand Access Layer (IBAL)
@ 2004-03-20 19:15 Acker, Dave
  0 siblings, 0 replies; 41+ messages in thread
From: Acker, Dave @ 2004-03-20 19:15 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: linux-kernel



> -----Original Message-----
> From: Ulrich Drepper [mailto:drepper@redhat.com]
> Sent: Saturday, March 20, 2004 12:56 PM
> To: Acker, Dave
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: PATCH - InfiniBand Access Layer (IBAL)
> 
> Acker, Dave wrote:
> > I can say that these other APIs are
> > already being used by other programs (or other APIs themselves) and
> > really can't go away.  If folks ask for ICSC support, it will
probably
> > get in there.
> 
> Spoken in true "proprietary-software, don't get the concept of free
> software"-fashion.
> 
> Just consider the implications if this would be accepted as an
argument.
>  Everybody who is producing a new API has to create just a couple of
> programs using it before publishing the specs to be able to say: well,
> here's the API.  Use it.  Oh, and don't change it, that's not
acceptable
> because we have code relying on the API.  Yep, strong-arming people
you
> have no control over works out fine, all the time.
> 
> The only acceptable order in which things can happen is:
> 
> 1. develop API
> 
> 2. propose API to be accepted by "community"/distributions
> 
> 3. change API if necessary, and go back to 2.
> 
> 4. write applications using new API
> 
> 

I don't mean that these other APIs MUST be accepted...just that people
are using them and will want to keep using them because they work for
them.  Even if there is one true standard linux interconnect API, I
suspect this APIs may hang around outside of standard linux.  Changing
an API is a lot easier than changing all the software that uses it.
 
I mention these other APIS because people have an interest in them
already and having interest in an API is a good thing.  People who are
actually going to use the API bring useful comments to the table.
Developing an API that no one wants to use isn't a very good way to
spend your time in my opinion.
The process you define is great if a company can wait for the process to
shake out a final API.  Often companies can not wait and have to move
forward.  The IB companies did just that.  This isn't to say we are not
open to moving from a proprietary API we made out of need to a community
accepted one.  That is what OpenIB.org is all about.  If we didn't care
we would not have bothered with this.  We are not trying to "strong-arm"
anyone into anything.  We want an open standard and are willing to
follow this process.  All of the companies involved have agreed to
support the results of this process. 


> > If folks ask for ICSC support, it will probably
> > get in there.
> 
> You did not in the least address the main point: IB is just one fiber.
> I cannot imagine anybody but the IB people want to have a specific API
+
> kernel extensions for each separate interconnect fiber.
> 
> Get it all over with in one stroke.  Come up with an API which covers
it
> all.  The requirements aren't that different.  And I singled out ICSC
> because it attempts to do just this.
> 

We are not looking for a specific API + kernel extensions for each
interconnect fiber.  We work in the area of IB and want to solve its
issues but I don't think that we are against a standard that solves all
interconnect issues.  I don't believe that we are against an API that
covers it all.  We (most IB companies) have supported DAPL and MPI.
Both are standards that try to work for all interconnects, not just IB.
If the community sees these as the wrong way to go and ICSC (or
something else) as the correct way then we (the IB community) will work
to support it.

> And don't say "we did our part, if the Linux community wants to have
> something else it's their to come up with a unified solution".  That
> would be acceptable only if it wouldn't be the IB people who want
their
> code to be generally accepted.  If you don't care about the later,
fine,
> leave it all as is.  But the code might not be picked up at all.
> 

Again, we are totally open to a unified solution...I don't believe we
have ever said we were not.  We started with looking for an InfiniBand
solution because that is what we know about and deal with everyday.

> Furthermore, don't count on much community participation.  There
aren't
> many people out there with the necessary hardware.  Or even the
ability
> to collect experiences.  The price for the changes have to be carried
by
> the parties with the agenda.
> 

Sure.  We expect to be making the changes ourselves often.

> 
> > If there is
> > going to be a standard linux infiniband stack it will have to be
very
> > good or else splinter versions and incompatible versions will live
on.
> 
> And by very good you mean of course your implementation.  From the
> comment above it is clear that if the standardized stack does not
> include your code you intent to keep using your code anyway.
Designing
> standards is always about compromises.
> 

Not at all.  In fact, the stack my company uses is not the base stack
openib.org has starting with, yet InfiniCon is still involved.
Compromises have already been made and more will be made in the future.
By "very good", I just mean that we want lots of review on the code.  We
want to hear what the community has to say.

> The organizations with interconnect interest have to come together to
> create just this, a compromise which in the end might not fulfill you
> "very good" criteria in all places.
> 

Sure.  It is totally possible that the final version lacks things that
some IB folks see as "very good" or needed.  This is where IB companies
can still offer and support additional pieces of open software that
suite their customer's needs.  For example, it is doubtful that MPI will
end up being the interconnect standard accepted by the linux community.
It is likely that its users will not be willing to change to another
interconnect API, even a standard one.  The rewrite cost would be too
high for many of them.  In these cases companies that sell interconnects
used for MPI applications will have to continue to support MPI.
Meanwhile others are free to use the standard out of the box and get
standard kernel support for it.

I am pretty sure RedHat and other Linux distributors have done similar
things for similar reasons.

-Ack

p.s. Again, these are my opinions, not the official opinions of
InfiniCon. 

^ permalink raw reply	[flat|nested] 41+ messages in thread
end of thread, other threads:[~2004-03-21 22:19 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-24 19:29 PATCH - InfiniBand Access Layer (IBAL) Woodruff, Robert J
2004-02-24 19:44 ` Greg KH
2004-02-24 19:50   ` Christoph Hellwig
2004-02-24 19:57     ` Greg KH
2004-02-24 22:29       ` Rik van Riel
2004-02-25  0:28         ` Matti Aarnio
2004-02-25  3:39           ` Rik van Riel
2004-02-25 16:25             ` Timothy Miller
2004-02-25 17:34               ` Roland Dreier
2004-02-25 18:55               ` Sam Ravnborg
2004-02-25 18:05                 ` Linus Torvalds
2004-02-25 19:09                   ` Timothy Miller
2004-02-25 19:55                   ` Sam Ravnborg
2004-02-25 19:05                     ` Linus Torvalds
2004-02-25 13:19           ` Christoph Hellwig
2004-02-24 21:33 Woodruff, Robert J
2004-02-24 22:18 Woodruff, Robert J
2004-02-24 23:02 Woodruff, Robert J
2004-02-25  3:32 ` Rik van Riel
2004-03-13 22:07 Woodruff, Robert J
2004-03-14  1:13 ` Andrew Morton
2004-03-14  2:28 ` Greg KH
2004-03-14  3:46 Woodruff, Robert J
2004-03-15  2:10 ` Greg KH
2004-03-14 23:14 Nivedita Singhvi
2004-03-15 22:52 Woodruff, Robert J
2004-03-15 23:17 ` Christoph Hellwig
2004-03-15 23:44   ` Johannes Erdfelt
2004-03-15 23:48     ` Christoph Hellwig
2004-03-15 23:54       ` Johannes Erdfelt
2004-03-16  0:09         ` Christoph Hellwig
2004-03-16  0:18           ` Johannes Erdfelt
2004-03-16  1:41 ` Roland Dreier
2004-03-19 18:47 ` Ulrich Drepper
2004-03-19 19:21   ` Fab Tillier
2004-03-19 20:20     ` Ulrich Drepper
2004-03-19 20:47   ` Roland Dreier
2004-03-20 17:15 Acker, Dave
2004-03-20 17:55 ` Ulrich Drepper
2004-03-21 22:16   ` Roland Dreier
2004-03-20 19:15 Acker, Dave

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).