Date: Tue, 5 Jan 1999 05:53:08 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: ken@plutotech.com (Kenneth D. Merry) Cc: mike@smith.net.au, committers@FreeBSD.ORG Subject: Re: proposed atapi-cd patch Message-ID: <199901050453.FAA01628@labinfo.iet.unipi.it> In-Reply-To: <199901042346.QAA60358@panzer.plutotech.com> from "Kenneth D. Merry" at Jan 4, 99 04:46:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901050453.FAA01628>