Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Mar 1999 00:59:37 -0700 (MST)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        =?US-ASCII?Q?S=F8ren?= Schmidt <sos@freebsd.dk>
Cc:        current@FreeBSD.org
Subject:   Re: How to add a new bootdevice to the new boot code ???
Message-ID:  <199903200759.AAA16581@narnia.plutotech.com>
In-Reply-To: <199903171205.NAA25764@freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <199903171205.NAA25764@freebsd.dk> you wrote:
> It seems David O'Brien wrote:
>> > Boot from an ata disk on major# 30, device name "ad", plain and simple.
>> 
>> Does this mean ata disks won't come under CAM/da ?
> 
> Not if I can help it :)
> It could be done by slamming a translation layer ontop of the existing
> wd driver or of cause on top of the new I'm doing, but all it adds
> is overhead, both performance wise and codesize wise. There is nothing
> that prohibits having both of cause, but it is not a priority for me
> to add more complexity into the picture before everything else is done.

My main complaint so far about the new ATAPI stuff is that it duplicates
or lacks (assuming it will be implemented) much of what CAM would have
given for almost free:

- Interrupt driven configuration
- Peripheral driver to device routing
- debugging/tracing facilities
- an extensible error recovery framework
- an understanding of command queuing (also relevant for ATAPI)
- understanding of hot plug events
- an aplication pass-thru interface

The question about translation layers is secondary and I would likely
choose to not introduce a translation at all.  Issuing pure ATAPI commands
to atapi devices at the peripheral driver level is somthing that CAM
could easily do.  I would probably choose to merge ATAPI functionality
into the da driver to avoid duplicated code and to ensure that bug
fixes only need to be performed in one place.  After all, the machinery
for talking to an ATAPI or SCSI disk is very similar (If the disk says
it needs to be spun up, spin it up; if we have too many transactions
outstanding and fear tag starvation, send an ordered tag; when we
close the disk or panic, synchronize its cache to stable media; etc. etc.)
even if the command op codes and format are slightly different.

But hey, I don't have the time to work on ATAPI.  Soren does, so he gets
to call the shots.

--
Justin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




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