Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Sep 2004 14:20:13 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Sam <sah@softcardsystems.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: AoE for 4.x
Message-ID:  <41533E0D.9000908@elischer.org>
In-Reply-To: <Pine.LNX.4.60.0409231620240.19882@athena>
References:  <Pine.LNX.4.60.0409211531450.32120@athena> <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> <Pine.LNX.4.60.0409231519030.19882@athena> <41532FA0.6030405@elischer.org> <Pine.LNX.4.60.0409231620240.19882@athena>

next in thread | previous in thread | raw e-mail | index | archive | help
you could look at the sbp driver that is part of the firewire code..
I think that may be the closest analog.


Sam wrote:

> On Thu, 23 Sep 2004, Julian Elischer wrote:
>
>> I think that if you have a working driver we can assign you a number.
>> I do have some questions however..
>>
>> this is AoE.. is it not possible at all to combne it with either the CAM
>> framework (such as the atapicam stuff) or the existing ATA stuff..
>> Don't take this the wrong way.. it's just a question..
>> CAM is being used to talk to drives over firewire, usb, ata, scsi, 
>> fibrechannel.
>> it would seem that to unify this would be something that we should 
>> look at..
>> Of course CAM itslef is showing its age in soem places and it could 
>> do with some work itself..
>
>
> It might be possible to plug into the CAM; I only briefly
> glanced at it and it didn't appear appropriate.  The ATA
> layer definitely isn't as parts of ATA don't make sense
> in this context (Read DMA, Read Multiple, eg) and AoE
> devices don't conform to the simple hardware probe/attach
> methodology (as I understand it).
>
> I would love to be proved wrong.  I'm always willing to
> try a new approach if it's demonstrably better.
>
> Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41533E0D.9000908>