From owner-freebsd-hackers Wed Feb 15 11:31:13 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA00334 for hackers-outgoing; Wed, 15 Feb 1995 11:31:13 -0800 Received: from tfs.com (mailhub.tfs.com [140.145.250.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA00328 for ; Wed, 15 Feb 1995 11:31:12 -0800 Received: by tfs.com (smail3.1.28.1) Message-Id: From: julian@tfs.com (Julian Elischer) Subject: Re: scsi(1) and WORM drives.. To: dufault@hda.com (Peter Dufault) Date: Wed, 15 Feb 1995 11:30:08 -0800 (PST) Cc: jkh@FreeBSD.org, hackers@freefall.cdrom.com In-Reply-To: <199502151121.GAA11387@hda.com> from "Peter Dufault" at Feb 15, 95 06:21:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2230 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > Jordan K. Hubbard writes: > > > > I've got a Phillips CDROM burner that I would, for obvious reasons, > > love to actually have work under FreeBSD. I know that it's probably > > impractical, since these things need to be fed a steady stream of > > data, but perhaps I could use the new rtprio() stuff to make sure that > > the `burning' process didn't have to give up the CPU until it was damn > > well ready. When it's making a CDROM, I don't want it doing anything > > else anyway. run it in single-user? :) > > > > It wasn't recognised by the SCSI driver, or at least it was probed and > > then noted as having no explicit driver available and then ignored, so > > I configured in the UK device and here's what I got: > > > > sd1: 4095MB (8388315 total sec), 3712 cyl, 21 head, 107 sec, bytes/sec 512 > > bt0 targ 3 lun 0: type 4(worm) removable SCSI1 > > bt0 targ 3 lun 0: > > uk0: unknown device > > bt0 targ 3 lun 1: type 4(worm) removable SCSI1 > > bt0 targ 3 lun 1: > > ... ah another of those wonderful devices that respond on ALL LUNs... > > > > > Anyone know how or if I can now use scsi(1) to somehow get raw data to > > the device? Ideally, I would just like to be able to do the equivalent > > of: dd if=image.cd0 of=/dev/rsd2d I believe it's now scsi(8). :) (looks good to me peter) > > You can't do this, though it may make sense to change the unknown driver > to support read and write translating over to regular read and write. > That should work for both processor type and WORM devices. I've considered this, but do we use 6-byte or 10-byte (or 12?) read/write commands, and do we put in a block-number, or a block-size? e.g. as seen in tapes. > > > But as life is probably nowhere near that simple, I'll also settle for > > being able to open some device and ram the file down its throat > > somehow after suitable ioctl()s, or whatever. > > This should send 512 bytes of data read from stdin to block 17: > > scsi -f /dev/uk0 -c "2A 0 i4 0 i2 0" 17 -o 512 - > very slick.. I'm just getting ready to use the scsi library now.... (for SEF) and it looks quite neat.. maybe we could do it via the scsi library.. julian >