[MPlayer-dev-eng] [PATCH] libmpdvdkit2/dvd_reader.c: do not second-guess user

Arpi arpi at thot.banki.hu
Thu Oct 20 19:13:23 CEST 2005


Hi,

> On Thu, Oct 20, 2005 at 10:55:55AM +0200, Arpi wrote:
> > but libdvdread also recognizes if the given path is mounted from a device
> > (based on mount tab), and then uses the raw device itself instead of the
> > filesystem. it's required to handle mounted css-encrypted disks.
> > (before you ask: why dont the user give the device insteda of the path
> > in this case? because on some OSes it's quite difficult to know the device
> > name, esp. on device mappers and other messy devfs-like systems, while you
> 
> IMO this is not true. The device name is stored in /etc/fstab and is
> quite constant, and a properly setup system will always have a symlink
> to it (named something like /dev/dvd).

on linux, maybe. it seems you never used Solaris, nor OSX...

> > can easily know the mount point, not even mentioning windows, where you
> > dont have device names, just drives which are actually paths...)
> 
> This is why I want windows to be handled specially.. Other such
> systems could be too..

so anything but linux should be handled specially.

> > the best would be adding a -dvd-filesystem or such option, and patch
> > libdvdread to handle it.
> > so if you use -dvd-device path, it will know you want to use the device,
> > located based on the given path, and if you use -dvd-filesystem  then
> > you want to use file access instead of raw sector-based addressing.
> 
> I suppose this is ok, but I still don't like libdvdread doing scanning
> for the device name. Anyway the current code is INCORRECT, since it
> assumes getmntent exists, which is NOT required by POSIX/SUS.
> getmntent is legacy bsd crap, and I've removed it from my (in
> progress) libc replacement because it's not useful for any program
> except mount/umount/df (basic system progs which can include their own
> code, or better yet use /proc)..

:)))

A'rpi




More information about the MPlayer-dev-eng mailing list