Bug 16007
| Summary: | cdcontrol(1) defaulting do /dev/cdrom instead of /dev/cd0c | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Alexander Langer <alex> | ||||
| Component: | bin | Assignee: | joe <joe> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.0-CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Alexander Langer
2000-01-09 16:10:01 UTC
Responsible Changed From-To: freebsd-bugs->joe I'll do this in a spare moment. 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 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] 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 >>>>> 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 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. 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. 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. >>>>> 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 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 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. |
