From owner-freebsd-current  Sat Sep 26 18:44:29 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA19846
          for freebsd-current-outgoing; Sat, 26 Sep 1998 18:44:29 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19831;
          Sat, 26 Sep 1998 18:44:23 -0700 (PDT)
          (envelope-from dan@math.berkeley.edu)
Received: (from dan@localhost)
	by math.berkeley.edu (8.8.7/8.8.7) id SAA22103;
	Sat, 26 Sep 1998 18:44:14 -0700 (PDT)
Date: Sat, 26 Sep 1998 18:44:14 -0700 (PDT)
From: dan@math.berkeley.edu (Dan Strick)
Message-Id: <199809270144.SAA22103@math.berkeley.edu>
To: sos@FreeBSD.ORG
Subject: Re: cd9660 mounts...
Cc: current@FreeBSD.ORG, dan@math.berkeley.edu, luigi@labinfo.iet.unipi.it
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> In reply to Luigi Rizzo who wrote:
> > 
> > An alternative hack (which seems to work and requires very little
> > modification -- just 4 lines in the device driver!) is to use the
> > device minor number to identify the track, so that you can say
> > 
> > 	mount -t cd9660 -o -s=0 /dev/wcd0tN /cdrom
> > 
> > to mount the n-th track.
> 
> I think this method is the best one, we can keep the mods in the
> atapi-cd devicedriver which still is sortof alpha code. That wont
> make it work for SCSI CDROM's, but that just too bad...
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Søren Schmidt               (sos@FreeBSD.org)               FreeBSD Core Team

FreeBSD already relies far too heavily on a proliferation of
minor devices, each of which requires its own entry in /dev.
Exactly how large a (worst case) track number are we prepared
to handle?

This kind of thing might be handled via ioctl().  The track number
could be an option argument to mount_cd9660.

Alternaticely, device drivers could have memory that transcends
close()es.  In this case, one might issue commands like:

	settrack /dev/rwcd0 N
	mount -t cd9660 /dev/wcd0 /cdrom

Dan Strick
dan@math.berkeley.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message