On Fri, 28 Dec 2001 02:33, Net Llama wrote:

> 1) What's the deal with the wacky chained symlinks?  Symlinks are a
> truly horrible idea when it comes to block devices, because most people
> have no clue what they're trying to do with them (the infamous
> /dev/cdrom thing on RedHat boxes comes immediately to mind).  Try
> mounting the actual block device, rather than a symlink two levels up.
> Additionally, the dmesg output you presented indicates that Linux thinks
> the drive is /dev/sr0, yet /dev/sr0 is a symlink.  Linux should be
> recognizing the actual block devce, not a symlink.

No argument. General info for others:

devices.txt lists SCSI cdroms as /dev/srX. This is historical. By convention, 
the names of kernel device driver modules have similarly named labels in the 
/dev tree. Thus the unfortunately named sr_mod.o (the scsi, cd, device 
driver) is associated with /dev/srX. Textual information in kernel messages 
deriving from this driver state /dev/srX as the object of curiosity (eg dmesg 
and /var/log/messages)

However, this is, historical.

The preferred labelling is in fact /dev/scdX. devices.txt states "this might 
make more sense". Indeed it does, and conforms better to the xxxCDxxx style 
labelling conventions employed everywhere else.

Thus, as a point of confusion, that you can hunt down over four years in just 
about any mailing list,  either the name sr0  *or*  scd0 are *the* answer to 
cd woes. The reader fails to realise, they both mean the same thing.

At least they're meant to be the same, reaiity is different.

In a Redhat system (and from memory Caldera), only /dev/scdX exists in the 
/dev tree. /dev/sr anything does not. This causes some confusion to older 
versions of burn software, since they are hardwired to look for srX. The 
answer has been to provide symlinks. In this instance lllama, I have to 
disagree with you and say, non-generic symlinks are necessary to relieve the 
pain.

A point worth mentioning is that any /dev/name has almost no relevance. They 
are solely and only used to look up the 'real' address, eg the major minor 
file node. If you wanted, you could access your scsi cd as /dev/elephants. 
The name as such has no meaning to the device driver.

Secondly, as it applies to IDE cd read/WRITE. There is no such thing.

Instead, that CD-RW is emulated in scsi. 

And it's here that all hell breaks loose, because, the cd REMAINS as an ide 
cd ROM (sorry for the capital emphasis, trying to make a point)

You thus get the all too frequent message on a list that "I can read, but not 
write to my cd"

Say for instance your ide cd burner is /dev/hdc and it is emulated as 
/dev/scd0 (alias /dev/sr0)

*Assuming* you have all the correct modules loaded,  you can mix and match 
the following (almost) any time you like

mount /dev/hdc   ....
mount /dev/scd0  ...
mount /dev/sr0    ....

The latter two commands achieve an identical effect (one is a symlink of the 
other) The same drivers are used, eg sr_mod.0, ide-scsi.o, cd_rom.o. This cd 
is burnable.

The first command uses different drivers, specifically ide-cd.o. Bypassing 
scsi altogether. This same cd is not burnable.

The confusion comes via /etc/fstab, because, generally speaking, a mere 
mortal will use a command like

mount /mnt/cdrom .....

For this command, or anything like it, to work, the mount binary relies on 
information in the /etc/fstab to 'discover' the real /dev/name.

and of course, the entry in fstab is often along the lines of

/dev/cdrom  == /mnt/cdrom

which, of course means another symlink is involved where /dev/cdrom points 
'somewhere'. If it points to /dev/scdX, burn baby burn, otherwise, you're 
looking back at the /dev/hdc ide interface.

So, for this reason,  I agree with you about /dev/symlinks. generic names 
suchs as 'cdrom' should be avoided.

And finally, the biggest woe is the infamous cryptic modprobe error messages 
that have bugger all information (or are just plain wrong). These typically 
occur (and the orginator of this subject seems to have been affected) when 
the ide-cd.o module got inadvertently loaded. It grabs ownership of the 
'node', and no attempts of mount /dev/scd anything will help.

-- 
http://linux.nf -- [EMAIL PROTECTED]

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
Linux-users mailing list
Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users

Reply via email to