/mnt/cdrom or /mnt ?

Daniel Bradley islabs at uq.net.au
Sat Apr 3 04:10:17 PST 1999


keld at dkuug.dk wrote:
> 
> I see benefits for novice users that there be a standard
> mount point for things like the first cdrom and the first floppy,
> and also windows partitions.

I'm starting to think that bothering to standardise a CD-Rom mount might
be short-sighted. Take as an example the floppy-drive, it is now
gradually being superceded by Zip/Jazz/Super disks. Would this mean that
there should be either a /zip(/mnt/zip) etc for each one.

This may be the device equivalent of User based access control vs Role
Based Access Control.

Perhaps something more along the lines of Role Based Device Mapping
should be thought off. In most cases the actual media is insignificant
i.e. Floppy vs Zip disk (they're both used for the same purpose). Isn't
that the whole point of having a VFS, the only thing that cares about
device type is the module loader.

I think that perhaps there should be three layers:

/home/username/mnt/MyFloppy --> /mnt/mag0 --> /dev/fd0
/home/username/mnt/MyJazz --> /mnt/mag1 --> /dev/jazz???
/home/username/mnt/CD --> /mnt/opt0 --> /dev/hdb (ATAPI CD-ROM)
/home/username/mnt/SBPCD --> /mnt/opt1 --> /dev/sbpcd
/home/username/mnt/Win --> /mnt/hdc1 --> /dev/hdc1

The purpose of the first layer is to provide a user-friendly and
customizable layer. This layer would be automatically generated during
OS install to give meaningful names to underlying mounted devices.

The purpose of the 2nd layer is to provide a static layer applications
can always depend on. However in this case it wouldn't be necessary for
it to be standardized, as long as the first layer is pointing to the
right place. Standardization would be desirable though. In this case
when a user installs an app they would select the link at layer1, the
app finds where that link points too and remembers that.

The reason for the third is obvious.

> The goal for me is to make the system fly just without any
> special configuration. I would like Linux to
> be a mainstream operating system that is good enough for
> the current average MS Windows user, - so installation should really
> be a no-brainer.

Agreed.

> For the cdrom and floppy stuff this would mean that there be
> a standard mount point, and where it is done is not really
> important, as said it is for the average non-professional user
> and it could be in the /mnt directory - although this is not my
> own personal preference.
> 
> A number of utilities could take advantage of this, such as mount,
> wine, different music stuff etc, which then would work out of the box.

Music is an interesting problem. In the case of audio CDs both xplaycd
and the KDE CD player like to use /dev/cdrom. What do you do if you
actually want to play CDs using another CD player (/dev/sbpcd).
Currently I've changed /dev/cdrom to point to /dev/sbpcd, and in I'm now
referencing the other CDRom directly as /dev/hdb.

I'm sure there is a way to fix this up in the .Xdefaults file but really
users shouldn't have to fiddle there.

> Especially much of the installation stuff could be done
> automagically - with of cause a choice to override the default settings.
> /etc/fstab should be initiated under installation with the default
> settings here, so a new system is born with access to windoze
> partitions and cdrom and floppy. We already have standard hardware
> names in /dev - so why not also logical names?
> 
> This should also include windoze partitions, all of them, and
> that should be named in a manner equivalent to how windoze names
> them, like c, d, e etc  (/mnt/c /mnt/d ...)

A problem here is that the Windows drive mapping can be dynamic. Also NT
allows you do arbitrarily assign drive letters. I think really it is
everyone's wish to get away from the DOS/Windows way of mapping drive
letters, which changes if you put another drive in your system with a
primary partition.

> Keld

Cheers,
Daniel.
-- 
----------------------------------------
Email: Daniel Bradley <islabs at uq.net.au>
Web:   http://www.islabs.com



More information about the lsb-discuss mailing list