From owner-cvs-all Mon Jan 4 23:52:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13038 for cvs-all-outgoing; Mon, 4 Jan 1999 23:52:03 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA12991 for ; Mon, 4 Jan 1999 23:51:55 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA01628; Tue, 5 Jan 1999 05:53:08 +0100 From: Luigi Rizzo Message-Id: <199901050453.FAA01628@labinfo.iet.unipi.it> Subject: Re: proposed atapi-cd patch To: ken@plutotech.com (Kenneth D. Merry) Date: Tue, 5 Jan 1999 05:53:08 +0100 (MET) Cc: mike@smith.net.au, committers@FreeBSD.ORG In-Reply-To: <199901042346.QAA60358@panzer.plutotech.com> from "Kenneth D. Merry" at Jan 4, 99 04:46:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > I think that diffs for both the ATAPI and SCSI drivers (and manpages) > > would make this a candidate for immediate inclusion. > > I'll certainly want to see diffs to the CAM cd driver before they go in. considering the whole patch (attached at the end for ease of reference) is 5 useful lines can people knowledgeable with CAM help me to come up (and test! i don't have a SCSI CD unit!) with a patch and test it ? Should it be for /sys/cam/scsi/scsi_cd.c right ? > I hesitate to use minor number bits to designate tracks, though. The cd yes, in fact i don't like this approach very much but this is just a temporary solution waiting for a better approach as i said. > driver currently uses the standard disk minor numbering scheme. It looks > like you're using the slice portion of the minor numbering scheme, which > limits things to 32 tracks. How many tracks can be on a CD anyway? 99, although even 32 cause a significant name space polluttion to be already too much! > One (possibly stupid) question I have, though, is why can't the cd9660 code > just remember the track offset? it could, but i think then you should act on both kernel and client side to put the offset in. I tried that approach but the offset would be scattered in far too many places. > The ioctl idea is interesting, but the problem I see is how does the driver > know which client a request is coming from, and therefore which offset to > use? you'd need to allow multiple mounts from the same CD which is not supported at the moment by the *-cd routines. so you just need one track offset for the disk. > I think it might be easier if the cd9660 code could handle the track offset > stuff. architecturally cleaner, perhaps, yes. But easier, i doubt it! cheers luigi diff -u -r1.6 atapi-cd.c --- atapi-cd.c 1998/12/07 21:58:20 1.6 +++ atapi-cd.c 1999/01/04 13:38:17 @@ -123,6 +123,7 @@ ptr->flags = F_MEDIA_CHANGED; ptr->flags &= ~(F_WRITTEN|F_TRACK_PREP|F_TRACK_PREPED); ptr->block_size = 2048; + ptr->starting_lba = 0 ; ptr->refcnt = 0; ptr->slot = -1; ptr->changer_info = NULL; @@ -377,6 +378,7 @@ acdopen(dev_t dev, int flags, int fmt, struct proc *p) { int lun = dkunit(dev); + int track = dkslice(dev); /* XXX this is a hack... */ struct acd *cdp; if (lun >= acdnlun || !atapi_request_immediate) @@ -409,6 +411,11 @@ } } } + cdp->starting_lba = ntohl(cdp->toc.tab[track].addr.lba) ; + if (track != 0) { + printf("Warning, opening track %d at %ld\n", + track, cdp->starting_lba); + } return 0; } @@ -527,7 +534,7 @@ #ifdef NOTYET lba = bp->b_offset / cdp->block_size; #else - lba = bp->b_blkno / (cdp->block_size / DEV_BSIZE); + lba = bp->b_blkno / (cdp->block_size / DEV_BSIZE) + cdp->starting_lba ; #endif else lba = cdp->next_writeable_lba + (bp->b_offset / cdp->block_size); diff -u -r1.2 atapi-cd.h --- atapi-cd.h 1998/10/15 08:11:55 1.2 +++ atapi-cd.h 1999/01/04 13:29:07 @@ -345,6 +345,8 @@ u_char speed; /* Select drive speed */ u_int next_writeable_lba; /* Next writable position */ struct wormio_prepare_track preptrack; /* Scratch region */ + + u_long starting_lba; /* for multitrack */ #ifdef DEVFS void *ra_devfs_token; void *rc_devfs_token; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message