Date: Fri, 29 Dec 2006 10:07:04 -0700 (MST) From: Scott Long <scottl@samsco.org> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, stable@FreeBSD.org Subject: Re: burncd 'blank' not terminating ? Message-ID: <20061229100334.F6511@pooker.samsco.org> In-Reply-To: <20061229164955.GA82150@icarus.home.lan> References: <20061221092717.A6431@xorpc.icir.org> <20061222073857.GA10704@tmn.ru> <20061225165735.M22401@atlantis.atlantis.dp.ua> <458FF48A.3010802@mail.zedat.fu-berlin.de> <20061228222306.GB836@turion.vk2pj.dyndns.org> <4594C099.9040307@pooker.samsco.org> <20061229164955.GA82150@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Dec 2006, Jeremy Chadwick wrote: > On Fri, Dec 29, 2006 at 12:15:37AM -0700, Scott Long wrote: >> Did you know that ATAPI is actually just the SCSI command set that is >> merely encapsulated into the IDE wire protocol? > > This is something Linux has done (you can still use the direct ATA > and IDE subsystems if you want, but in most major distros I've seen > as of late, they use a SCSI-to-ATA conversion layer). > > Thus: why haven't we moved the front-end to the ATA subsystem into > atapicam(4) then? Is it just the amount of work involved, or are > there technical reasons? > atapicam works by using CAM (SCSI) as the front end and ATA as the back end. It's not correct to say that the rest of ATA should be moved into atapicam. Instead what you want is to teach CAM how to do more back-ends than just parallel SCSI. There are no technical reasons not to experiment with this. It is a bit of work, though. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061229100334.F6511>