On Thu, 30 Jun 2005, Roland Dreier wrote:
Robert> I think that your suggestion to s/DAT/RDMA makes sense,
Robert> since this code is quickly becoming "the" RDMA transport
Robert> independent interface for Linux, rather than trying to
Robert> RNIC-PI unionize the IB core layer to ma
On Thu, 30 Jun 2005, Christoph Hellwig wrote:
Could you please stop that comitte crap?
James, what do you think about doing an s/DAT/RDMA/ and s/dat/rdma/
on the code so we can stop this endless mess?
If we explain the changes we're making, there should be no need to
do that.
In the end
Carlin wrote,
>True.
>My assumption is that each transport would have its
>own CM module with similar, but not identical APIs.
>An application wants to go direct it could do the
>if/else ifs on its own.
If the application will have to have if/else for some functions,
then it already has to be
On 6/30/05, Bob Woodruff <[EMAIL PROTECTED]> wrote:
> Catlin wrote,
> >application -> DAT Layer ---> RDMA Verbs >
> >model-specific code
> > \ ^
> > \ /
> >
Sean Hefty wrote:
Caitlin Bestler wrote:
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for "RDMA verbs". It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS, fr
Catlin wrote,
>application -> DAT Layer ---> RDMA Verbs >
>model-specific code
> \ ^
> \ /
> \/
Tell me how y
Caitlin Bestler wrote:
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for "RDMA verbs". It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS, from user to kernel, e
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for "RDMA verbs". It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS, from user to kernel, etc.
So in some ways DAT
Christoph wrote,
>Well, the plan was to take the parts of the DAT API that make sense
>and put them into that generic RDMA layer. DAT advocates claimed there
>were such useful higherlevel abstractions, but the more I look at
>the dat/dat-provider codebase I doubt there's a lot of them.
One exampl
Roland wrote,
>I disagree. It doesn't make sense to me for us to add an abstraction
>layer on top of another abstraction layer -- let's just fix the first
>abstraction layer.
>If we follow the approach of changing the name of DAT to RDMA and then
>putting it in the kernel, we end up with a stack
Christoph> Well, the plan was to take the parts of the DAT API
Christoph> that make sense and put them into that generic RDMA
Christoph> layer. DAT advocates claimed there were such useful
Christoph> higherlevel abstractions, but the more I look at the
Christoph> dat/dat-provid
On Thu, Jun 30, 2005 at 09:18:20AM -0700, Roland Dreier wrote:
> Robert> I think that your suggestion to s/DAT/RDMA makes sense,
> Robert> since this code is quickly becoming "the" RDMA transport
> Robert> independent interface for Linux, rather than trying to
> Robert> RNIC-PI unio
Robert> I think that your suggestion to s/DAT/RDMA makes sense,
Robert> since this code is quickly becoming "the" RDMA transport
Robert> independent interface for Linux, rather than trying to
Robert> RNIC-PI unionize the IB core layer to make it support both
Robert> IB and iWarp
Christoph wrote,
>On Thu, Jun 30, 2005 at 08:38:45AM -0700, Caitlin Bestler wrote:
>> actual code requirements makes no sense. If you
>> can't come up with something that remains acceptable
>> to the broader community of DAT users then you should
>> refrain from using the "dat_" symbols and their a
On Thu, Jun 30, 2005 at 08:38:45AM -0700, Caitlin Bestler wrote:
> actual code requirements makes no sense. If you
> can't come up with something that remains acceptable
> to the broader community of DAT users then you should
> refrain from using the "dat_" symbols and their already
> established m
Taking an interface because it has a user base, and then
ignoring that user base is just plain idiotic.
If you want to design your own RDMA interface do so.
But changing DAT to meet your whims rather than
actual code requirements makes no sense. If you
can't come up with something that remains ac
Could you please stop that comitte crap?
James, what do you think about doing an s/DAT/RDMA/ and s/dat/rdma/
on the code so we can stop this endless mess? In the end it won't
look like dat anyway, and the sooner why make that absolutely clear
that less idiocy like this is going to happen.
__
Title: Message
Dear DAT and OpenIB members,
There is a
debate going on on OpenIB and DAT reflectors which is going around about kDAT
registry for Linux.
I would like to
review the requirements we had
agreed at DAT
collaborative and captured in the
kDAT
and uDAT specs and review DAT regi
18 matches
Mail list logo
