Re: AoE for 4.x

From: Sam (sah_at_softcardsystems.com)
Date: 09/30/04

  • Next message: John Baldwin: "Re: scheduler (sched_4bsd) questions" 
    Date: Thu, 30 Sep 2004 09:04:18 -0500 (EST)
To: Stephan Uphoff <ups@tree.com>

    I haven't heard any major objections to my getting a major
    number -- can someone please step up and help me out?

    Sam

    On Thu, 23 Sep 2004, Stephan Uphoff wrote:

    > Since a complete disk operation in AoE is encapsulated in a single
    > Ethernet request/response pair - The data size of a read/write operation
    > is smaller than a single page.
    >
    > I don't think any existing framework can deal with this efficiently.
    >
    > Stephan
    >
    > On Thu, 2004-09-23 at 17:20, Julian Elischer wrote:
    >> 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
    >>
    >>
    >> _______________________________________________
    >> freebsd-arch@freebsd.org mailing list
    >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    >>
    >>
    >
    >
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: John Baldwin: "Re: scheduler (sched_4bsd) questions"