From alex@cichlids.com  Sun Jan  9 08:04:54 2000
Return-Path: <alex@cichlids.com>
Received: from cichlids.com (as15-122.rp-plus.de [149.221.237.122])
	by hub.freebsd.org (Postfix) with ESMTP id 3C383151EC
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  9 Jan 2000 08:04:52 -0800 (PST)
	(envelope-from alex@cichlids.com)
Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10])
	by cichlids.com (Postfix) with ESMTP id 4610CAB92
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  9 Jan 2000 17:04:57 +0100 (CET)
Received: (from root@localhost)
	by cichlids.cichlids.com (8.9.3/8.9.3) id RAA06356;
	Sun, 9 Jan 2000 17:04:47 +0100 (CET)
	(envelope-from alex)
Message-Id: <200001091604.RAA06356@cichlids.cichlids.com>
Date: Sun, 9 Jan 2000 17:04:47 +0100 (CET)
From: Alexander Langer <alex@cichlids.com>
Reply-To: alex@cichlids.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
X-Send-Pr-Version: 3.2

>Number:         16007
>Category:       bin
>Synopsis:       cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    joe
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan  9 08:10:01 PST 2000
>Closed-Date:    Sat Feb 10 10:57:44 PST 2001
>Last-Modified:  Sat Feb 10 10:59:35 PST 2001
>Originator:     Alexander Langer
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
none
>Environment:

-current

>Description:

Since almost every program I know uses /dev/cdrom as default path to access
the cd-rom, I think cdcontrol(1) should do, too.
Acutally, it uses /dev/cd0c, which is somehow uncommon.

Attached is the small patch to fix it. 

Comments?

>How-To-Repeat:

$ cdcontrol play

>Fix:

in /usr/src/usr.sbin/cdcontrol

--- cdcontrol.c.old	Sun Jan  9 16:59:57 2000
+++ cdcontrol.c	Sun Jan  9 16:59:48 2000
@@ -46,7 +46,7 @@
 #define ASTS_VOID       0x15  /* No current audio status to return */
 
 #ifndef DEFAULT_CD_DRIVE
-#  define DEFAULT_CD_DRIVE  "/dev/cd0c"
+#  define DEFAULT_CD_DRIVE  "/dev/cdrom"
 #endif
 
 #ifndef DEFAULT_CD_PARTITION

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->joe 
Responsible-Changed-By: joe 
Responsible-Changed-When: Sun Jan 9 10:18:04 PST 2000 
Responsible-Changed-Why:  
I'll do this in a spare moment. 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Alexander Langer <alex@cichlids.com>, joe@FreeBSD.ORG
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Sun, 9 Jan 2000 16:30:35 -0700

 On Sun, Jan 09, 2000 at 17:04:47 +0100, Alexander Langer wrote:
 > >Description:
 > 
 > Since almost every program I know uses /dev/cdrom as default path to access
 > the cd-rom, I think cdcontrol(1) should do, too.
 > Acutally, it uses /dev/cd0c, which is somehow uncommon.
 > 
 > Attached is the small patch to fix it. 
 > 
 > Comments?
 > 
 > >How-To-Repeat:
 > 
 > $ cdcontrol play
 > 
 > >Fix:
 > 
 > in /usr/src/usr.sbin/cdcontrol
 > 
 > --- cdcontrol.c.old	Sun Jan  9 16:59:57 2000
 > +++ cdcontrol.c	Sun Jan  9 16:59:48 2000
 > @@ -46,7 +46,7 @@
 >  #define ASTS_VOID       0x15  /* No current audio status to return */
 >  
 >  #ifndef DEFAULT_CD_DRIVE
 > -#  define DEFAULT_CD_DRIVE  "/dev/cd0c"
 > +#  define DEFAULT_CD_DRIVE  "/dev/cdrom"
 >  #endif
 
 
 Huh?  There is no /dev/cdrom created by MAKEDEV, so it must be created
 either by the user or by sysinstall.  I kinda doubt sysinstall creates it,
 though I could be wrong.
 
 In any case, I think this is more likely to confuse/annoy people than solve
 any problems.
 
 What programs use /dev/cdrom, anyway?  Most that I'm aware of default to
 /dev/cd0{c|a}, if anything.
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
 

From: Josef Karthauser <joe@pavilion.net>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Alexander Langer <alex@cichlids.com>, joe@FreeBSD.ORG,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Sun, 9 Jan 2000 23:54:43 +0000

 On Sun, Jan 09, 2000 at 04:30:35PM -0700, Kenneth D. Merry wrote:
 > 
 > Huh?  There is no /dev/cdrom created by MAKEDEV, so it must be created
 > either by the user or by sysinstall.  I kinda doubt sysinstall creates it,
 > though I could be wrong.
 > 
 > In any case, I think this is more likely to confuse/annoy people than solve
 > any problems.
 > 
 > What programs use /dev/cdrom, anyway?  Most that I'm aware of default to
 > /dev/cd0{c|a}, if anything.
 > 
 
 How many people have SCSI disks?  In today's climate directed more and more
 towards the common or garden pc most people will have /dev/wcd, or /dev/acd.
 A /dev/cdrom link makes sense, in the same way that we've got /dev/mouse.
 
 Joe
 -- 
 Josef Karthauser	FreeBSD: Take the red pill and we'll show you just how
 Technical Manager	deep the rabbit hole goes. (http://www.uk.freebsd.org)
 Pavilion Internet plc.  [joe@pavilion.net, joe@freebsd.org, joe@tao.org.uk]
 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Josef Karthauser <joe@pavilion.net>
Cc: Alexander Langer <alex@cichlids.com>, joe@FreeBSD.ORG,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Sun, 9 Jan 2000 17:00:19 -0700

 On Sun, Jan 09, 2000 at 23:54:43 +0000, Josef Karthauser wrote:
 > On Sun, Jan 09, 2000 at 04:30:35PM -0700, Kenneth D. Merry wrote:
 > > 
 > > Huh?  There is no /dev/cdrom created by MAKEDEV, so it must be created
 > > either by the user or by sysinstall.  I kinda doubt sysinstall creates it,
 > > though I could be wrong.
 > > 
 > > In any case, I think this is more likely to confuse/annoy people than solve
 > > any problems.
 > > 
 > > What programs use /dev/cdrom, anyway?  Most that I'm aware of default to
 > > /dev/cd0{c|a}, if anything.
 > > 
 > 
 > How many people have SCSI disks?  In today's climate directed more and more
 > towards the common or garden pc most people will have /dev/wcd, or /dev/acd.
 > A /dev/cdrom link makes sense, in the same way that we've got /dev/mouse.
 
 What I'm getting at is that we don't have a /dev/cdrom link, so changing
 cdcontrol to point to something that isn't generally there will just annoy
 people.
 
 Sure, it's nice to have a symlink that points to the right place, but you
 probably need to make sure it gets created somehow in a normal
 installation.  Otherwise, cdcontrol won't "just work".
 
 This probably should be discussed more before it goes in the tree.  I would
 suggest taking it to -current or -hackers or something for discussion.
 
 If this goes in, it will be a precedent for other utilities, and so we
 shouldn't rush into it without at least getting some opinions on it.
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
 

From: Jean-Marc Zucconi <jmz@FreeBSD.ORG>
To: alex@cichlids.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 01:13:07 +0100 (MET)

 >>>>> Alexander Langer writes:
 
  > Since almost every program I know uses /dev/cdrom as default path to access
  > the cd-rom, I think cdcontrol(1) should do, too.
  > Acutally, it uses /dev/cd0c, which is somehow uncommon.
 
 /dev/cd0c is more common than /dev/cdrom because /dev/cdrom does not
 exist :-) Where in /dev/MAKEDEV is this device created?
 
  > Attached is the small patch to fix it. 
 
 Your patch does not even change the man page!
 
  > Comments?
 
 I am against this patch.
 
 Jean-Marc
 
 -- 
  Jean-Marc Zucconi                    PGP Key: finger jmz@FreeBSD.ORG
 

From: Alexander Langer <alex@big.endian.de>
To: Jean-Marc Zucconi <jmz@FreeBSD.ORG>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 14:22:38 +0100

 Thus spake Jean-Marc Zucconi (jmz@FreeBSD.ORG):
 
 > /dev/cd0c is more common than /dev/cdrom because /dev/cdrom does not
 > exist :-) Where in /dev/MAKEDEV is this device created?
 
 Heh ;-)
 Hmm. joe pointed out /dev/mouse as a symbolic link. how it /dev/mouse
 being created?
 
 >  > Attached is the small patch to fix it. 
 > Your patch does not even change the man page!
 
 Yes, I'm aware of this. It was rather a symbolic patch to lead to
 comments than a real fix ;-)
 
 Alex
 
 -- 
 I doubt, therefore I might be. 
 

From: Alexander Langer <alex@big.endian.de>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Josef Karthauser <joe@pavilion.net>, joe@FreeBSD.ORG,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 14:21:21 +0100

 Thus spake Kenneth D. Merry (ken@kdm.org):
 
 > Sure, it's nice to have a symlink that points to the right place, but you
 > probably need to make sure it gets created somehow in a normal
 > installation.  Otherwise, cdcontrol won't "just work".
 
 It won't "just work" on my system, too.
 
 Alex
 
 -- 
 I doubt, therefore I might be. 
 

From: Alexander Langer <alex@big.endian.de>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: joe@FreeBSD.ORG, FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 14:20:28 +0100

 Thus spake Kenneth D. Merry (ken@kdm.org):
 
 > >  #ifndef DEFAULT_CD_DRIVE
 > > -#  define DEFAULT_CD_DRIVE  "/dev/cd0c"
 > > +#  define DEFAULT_CD_DRIVE  "/dev/cdrom"
 > >  #endif
 > Huh?  There is no /dev/cdrom created by MAKEDEV, so it must be created
 > either by the user or by sysinstall.  I kinda doubt sysinstall creates it,
 > though I could be wrong.
 
 Yes. That is right. But there is also no /dev/cd0c on a typical
 ATAPI-installation, what today's CDROMs mainly are (at least on
 systems cdcontrol(1)) will be used mainly -- _user_ systems).
 
 The advantage is, that you can create the symlink /dev/cdrom yourself
 and therefore use cdcontrol after you've created it once (for another
 program).
 
 Otherwise, I have to type cdcontrol -f /dev/wcd0c play everytime. :-(
 (Yes, I'm aware of aliases).
 
 > In any case, I think this is more likely to confuse/annoy people than solve
 > any problems.
 
 I don't think so. I got the idea when I helped a person on #freebsd
 with playing audio CD's.
 better let sysinstall/MAKEDEV install a default cdrom-symbolic-link,
 if it doesn't exist already.
 
 > What programs use /dev/cdrom, anyway?  Most that I'm aware of default to
 > /dev/cd0{c|a}, if anything.
 
 mainly cross-platform tools, e.g. ports audio/dagrab, that are written
 for different platoforms, where the devices are not the same.
 from dagrab's help page:
         -d device       : set cdrom device (default=/dev/cdrom)
 
 I saw this behaviour in different programs, that I can't remember now.
 
 Well, that's why I wanted to discuss it :-)
 
 Alex
 -- 
 I doubt, therefore I might be. 
 

From: Jean-Marc Zucconi <jmz@FreeBSD.ORG>
To: alex@big.endian.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 19:25:10 +0100 (MET)

 >>>>> Alexander Langer writes:
 
  > Thus spake Jean-Marc Zucconi (jmz@FreeBSD.ORG):
  >> /dev/cd0c is more common than /dev/cdrom because /dev/cdrom does not
  >> exist :-) Where in /dev/MAKEDEV is this device created?
 
  > Heh ;-)
  > Hmm. joe pointed out /dev/mouse as a symbolic link. how it /dev/mouse
  > being created?
 
 It is created by MAKEDEV:
 mouse*)
         name=`expr $i : 'mouse\(.*\)'`
         if [ ! -c $name ]; then
                 $0 $name                        # make the appropriate device
         fi
         ln -fs $name mouse
         ;;
 
  :-}
 
 Jean-Marc
 
 -- 
  Jean-Marc Zucconi                    PGP Key: finger jmz@FreeBSD.ORG
 

From: Alexander Langer <alex@big.endian.de>
To: Jean-Marc Zucconi <jmz@FreeBSD.ORG>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/16007: cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c
Date: Mon, 10 Jan 2000 19:39:31 +0100

 Thus spake Jean-Marc Zucconi (jmz@FreeBSD.ORG):
 
 > It is created by MAKEDEV:
 > mouse*)
 >         name=`expr $i : 'mouse\(.*\)'`
 >         if [ ! -c $name ]; then
 >                 $0 $name                        # make the appropriate device
 >         fi
 >         ln -fs $name mouse
 >         ;;
 
 Can't we have something similar for cdrom?
 
 The above looks nice, could work for cdrom in a similar way.
 
 I'd very like to see it.
 
 Alex
 
 -- 
 I doubt, therefore I might be. 
 
State-Changed-From-To: open->closed 
State-Changed-By: joe 
State-Changed-When: Sat Feb 10 10:57:44 PST 2001 
State-Changed-Why:  
Use the CDROM enviroment variable instead for now.  Devfs is coming 
soon and the creation of a /dev/cdrom may be implemented in a future 
device daemon (devd) daemon. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16007 
>Unformatted:
