From owner-freebsd-hackers Fri Feb 17 16:30:33 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA28017 for hackers-outgoing; Fri, 17 Feb 1995 16:30:33 -0800 Received: from tree.com (tree.com [204.91.58.2]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA28011 for ; Fri, 17 Feb 1995 16:30:30 -0800 Received: by tree.com (5.0/SMI-SVR4) id AA02120; Fri, 17 Feb 95 19:28:44 EST Date: Fri, 17 Feb 95 19:28:44 EST From: ups@tree.com (Stephan Uphoff) Message-Id: <9502180028.AA02120@tree.com> To: jkh@FreeBSD.org Subject: Re: scsi(1) and WORM drives.. Cc: hackers@freefall.cdrom.com X-Sun-Charset: US-ASCII content-length: 1710 Sender: hackers-owner@FreeBSD.org Precedence: bulk There is a Linux mini-HOWTO about a program called cdwrite and Philips cd writers. ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/CD-Writer Good luck Stephan Uphoff > 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. > > 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: > ... > > 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 > > 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 would actually be such an advantage for us that I think there > could be some money in this if somebody wanted to contract for the job > of making this all work. Comments? > > Jordan >