Date: Fri, 5 Jun 2009 12:17:38 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Scott Long <scottl@samsco.org> Cc: Alexander Motin <mav@mavhome.dp.ua>, FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration Message-ID: <200906051917.n55JHcLO077306@apollo.backplane.com> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:CAM is being expanded to be a framework for scheduling, recovery, and
:topology management, agnostic to the transport and protocol being used.
:SPI and SCSI are being separated into transport and protocol modules,
:and Alexander has been amazing and kind enough to start a SATA transport
:and ATA protocol module. Unlike Linux, OpenBSD, or anything else out
:there, this is not a tacked-on library for speaking SCSI/SPI at the top
:level and then translating it to something else at a lower level. This
:is about speaking native SBP/RBP/ATA at the periph level and native
:SPI/PATA/SATA/FCAL/SMP/USB at the transport level.
:
:So, before you continue to cast ignorant doubts on our approach and hawk
:your incomplete wares, please at least look at what is being done on our
:end, and make an attempt to ask some reasonable questions.
:
:Scott
Huh. Get up on the wrong side of the bed, Scott? Just remember who
started making the shit comments this time.
I have no interest with what FreeBSD is doing with CAM. My only interest
vis-a-vie this thread are the AHCI driver efforts by the various BSDs,
including ours.
In particular, my interest is in NCQ, hot-plug support, and port
multiplier support, as these three items can put SATA/AHCI on-par
with dedicated SCSI controllers (at least once AHCI hardware revs
past the original spec). It is something very important
to all Open-Source OS projects as it consolidates the storage device
driver spec and removes a huge thorn in the sides of all the projects
with regards to the forward-support of new hardware.
--
IMHO the only SCSI command non-SCSI devices have to fake-up is IDENTIFY.
Everything else is a straight translation, and an easy one at that.
Even SENSE doesn't need to be faked-up all that much, one just sets
an AUTOSENSE flag bit and include the sense in the CCB. So interfacing
to CAM is not really a big deal. The SCSI command set is the only
cross-device portable command set that exists today, after all.
The only problem I have with the original CAM is that it didn't use a
dedicated thread for bus-reset/probe/scan/identify/attachment and
detachment. That's the only reason the original API was such a bitch
to deal with by device drivers. Fixing that fixes all the device
interaction issues for attachment/detachment. The API doesn't actually
change, but the recursive nature of the direct calls goes away and
greatly simplifies device drivers. That's the only thing I see wrong
with CAM, frankly.
So I applaud your efforts on cleaning up the attach/detach stuff in
FreeBSD, but it isn't my focus in this thread and not something I'm
interested in doing for the DragonFly project, beyond what I mentioned
above. Your comments are improper.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906051917.n55JHcLO077306>