libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Re: Burned CD-RW and DVD+RW via libcdio MMC interfa


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Re: Burned CD-RW and DVD+RW via libcdio MMC interface
Date: Sat, 19 Dec 2009 19:15:20 -0500

The patches you sent have now been applied in the git repository. Please
double check that everything came out correct. If you want direct access to
the libcdio repository in the future contact me off list.

I had some trouble with cut and paste with "patch" but Emacs 23's Diff mode
didn't seem to have a problem.

I have some questions about the patches though.

And after that I hope I can answer your other outstanding questions.

Yes, obviously run_mmc_cmd_linux wasn't using the direction parameter and
that was a bit odd.  Harmlessly odd though for a program that to now didn't
purport to support writing (despite the `O' in "libdio").  The question I
have is whether run_mmc_linux after the patch *now* does something
reasonable (or not incorrect) when e_direction parameter is
SCSI_MMC_DATA_NONE ?

Anyone care to comment?

The second question or concern I have is changing  O_RDONLY to  O_RDWR in
cdio_open_am_linux. I think there has been a bit of discussion and concern
about if not this then whether to use blocking or non-blocking mode. I don't
recall the issues. Clearly opening read-only *when that is all you need* is
probably a good thing. It is likely that many processes can simultaneously
open read only, while with read/write one might need exclusive access. (I
can't imagine for CD's that Unix's "last write wins" policy is used.)

Comments? Flameyes? (the author of unieject)

Herbert Valerio Riedel when he wrote vcdimager (from which this grew out of)
added a provision on the open to specify an "access mode" .  Generally this
was whether to use SCSI MMC commands or Unix IOCTL kinds of access. For
example reading blocks had several commands one could try -- a READCD
command or an older READ10 command. So I suppose it might be possible to use
this parameter to indicate that one wants write access and set O_RDWR only
when that's the case.

I don't know. I hope others will share their views.

- - - -
Okay, now finally hopefully to address other points you raise. First, the
request to support CD burining comes from rms via Karl Berry. So rest
assured, at least to them, this is strategic!

As for supporting the various OSes and whatnot, this is not really a new
problem. On some OS's writing will be unimplemented until someone can
implement it. (This is a simple answer even if it's not satisfying).  If the
past is prologue, in due time generally things get done (provided someone
knows how to. Accessing CD-ROMs in OSX has always been a big mystery.)

I think we don't have a view that it all has to happen before the next
release can occur. Distributions can lag years behind a release. For example
only recently has FreeBSD gone with the support provided inside libcdio than
use its own hacked driver. Debian recently jumped from  0.78 to 0.81.  And
various software packages like xine and xmbc have packaged their own
versions. So all of this relieves some of the pressure in making sure every
last detail is addressed and gives some flexibility in when to releases.

I haven't tried xorriso or your recent libburn changes from SVN yet I but
will try to do so soon.

Yes, libcdio should handle extra info which describes ACL and xattr of files
in an
ISO 9660 image.

If you have other questions or I haven't addressed the ones you asked, let
me know.

Thanks.

On Sat, Dec 19, 2009 at 2:29 PM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> > You are *not* annoying.
>
> For now. :))
>
> I include two patches:
>
> ------------------------------------------------
> The fix for the obvious bug in
> run_mmc_cmd_linux(). I deem this of value in any
> case. (Although direction WRITE will not work on
> Linux without open(O_RDWR).
> ------------------------------------------------
>
> --- libcdio-0.82/lib/driver/gnu_linux.c 2009-07-03 01:31:58.000000000 +0200
> +++ libcdio-0.82.ts/lib/driver/gnu_linux.c      2009-12-19
> 17:42:37.000000000 +0100
> @@ -1229,7 +1229,7 @@ run_mmc_cmd_linux( void *p_user_data,
>   memcpy(&cgc.cmd, p_cdb, i_cdb);
>   cgc.buflen = i_buf;
>   cgc.buffer = p_buf;
> -  cgc.data_direction = (SCSI_MMC_DATA_READ == cgc.data_direction)
> +  cgc.data_direction = (SCSI_MMC_DATA_READ == e_direction)
>     ? CGC_DATA_READ : CGC_DATA_WRITE;
>
>  #ifdef HAVE_LINUX_CDROM_TIMEOUT
>
> ------------------------------------------------
> The introduction of transfer direction NONE
> and its implementation in gnu_linux.c.
> Plus hardcoded usage of open(O_RDWR) in
> gnu_linux.c
> This is a very provisory patch and should only
> be used for experiments with libburn on Linux.
> On other systems one would first have to
> implement direction NONE.
> This patch assumes the first one was applied
> (and overwrites its change by a new one).
> ------------------------------------------------
>
> --- libcdio-0.82/include/cdio/mmc.h     2008-11-29 05:52:43.000000000 +0100
> +++ libcdio-0.82.ts/include/cdio/mmc.h  2009-12-19 18:04:15.000000000 +0100
> @@ -377,12 +377,16 @@ typedef struct mmc_cdb_s {
>   } cdio_mmc_feature_list_header_t;
>
>   /** An enumeration indicating whether an MMC command is sending
> -    data or getting data.
> +    data, or getting data, or does none of both.
>   */
>   typedef enum mmc_direction_s {
>     SCSI_MMC_DATA_READ,
> -    SCSI_MMC_DATA_WRITE
> +    SCSI_MMC_DATA_WRITE,
> +    SCSI_MMC_DATA_NONE
>   } cdio_mmc_direction_t;
> +  /** Indicate to applications that SCSI_MMC_DATA_NONE is available
> +  */
> +#define SCSI_MMC_HAS_DIR_NONE 1
>
>   typedef struct mmc_subchannel_s
>   {
>
> --- libcdio-0.82/lib/driver/gnu_linux.c 2009-12-19 17:47:31.000000000 +0100
> +++ libcdio-0.82.ts/lib/driver/gnu_linux.c      2009-12-19
> 18:07:32.000000000 +0100
> @@ -1229,8 +1229,10 @@ run_mmc_cmd_linux( void *p_user_data,
>   memcpy(&cgc.cmd, p_cdb, i_cdb);
>   cgc.buflen = i_buf;
>   cgc.buffer = p_buf;
> -  cgc.data_direction = (SCSI_MMC_DATA_READ == e_direction)
> -    ? CGC_DATA_READ : CGC_DATA_WRITE;
> +
> +  cgc.data_direction = (SCSI_MMC_DATA_READ == e_direction) ? CGC_DATA_READ
> :
> +                       (SCSI_MMC_DATA_WRITE == e_direction) ?
> CGC_DATA_WRITE :
> +                       CGC_DATA_NONE;
>
>  #ifdef HAVE_LINUX_CDROM_TIMEOUT
>   cgc.timeout = i_timeout_ms;
> @@ -1641,7 +1643,7 @@ cdio_open_am_linux (const char *psz_orig
>
>   ret->driver_id = DRIVER_LINUX;
>
> -  if (cdio_generic_init(_data, O_RDONLY|O_NONBLOCK)) {
> +  if (cdio_generic_init(_data, O_RDWR|O_NONBLOCK)) {
>     return ret;
>   } else {
>     cdio_generic_free (_data);
>
> ------------------------------------------------
>
> After applying both patches one may test the
> newest SVN version of libburn:
>  svn co http://svn.libburnia-project.org/libburn/trunk libburn
>  cd libburn
> For the next command one needs autotools >= 1.7
>  ./bootstrap
> (If SVN is inconvenient to you, ask me for a
> tarball with ./bootstrap already applied.)
>
> Now request that experimental adapter sg-libcdio
> is used instead of normal adapter sg-linux:
>  ./configure --enable-libcdio
> and let
>  make
>
> Command
>  cdrskin/cdrskin
> should work without make install.
> So if you have rw-access to the drive device file
> you do not need to be superuser for a first test.
>
> Remember: Only the Linux driver of libcdio is
>          prepared yet.
>
> Experiments:
>
> Get an overview of drives
>  $ cdrskin/cdrskin --devices
>  cdrskin 0.7.5 : limited cdrecord compatibility wrapper for libburn
>  ...
>  cdrskin: Overview of accessible drives (6 found) :
>
>  -----------------------------------------------------------------------------
>  0  dev='/dev/cdrom'  rwrw-- :  'HL-DT-ST'  'DVD-ROM GDR8162B'
>  1  dev='/dev/hdc'  rwrw-- :  'LITE-ON '  'LTR-48125S'
>  2  dev='/dev/sr0'  rwrw-- :  'TSSTcorp'  'CDDVDW SH-S203B'
>  3  dev='/dev/sr1'  rwrw-- :  'HL-DT-ST'  'BD-RE GGW-H20L'
>  4  dev='/dev/sr2'  rwrw-- :  'HL-DT-ST'  'BDDVDRW GGC-H20L'
>  5  dev='/dev/sr3'  rwrw-- :  'SanDisk '  'Cruzer'
>
>  -----------------------------------------------------------------------------
>
> Insert some media into one of the drives and let
> cdrskin report about it:
>  $ cdrskin/cdrskin dev=/dev/sr2 -v -minfo
>  ...
>  Identifikation : 'BDDVDRW GGC-H20L'
>  ...
>    1T speed low:  4 1T speed high: 10
>  Product Id:    97m15s35f/79m59s74f
>  Producer:      Nan-Ya Plastics Corporation
>  Manufacturer: Nan-Ya Plastics Corporation
>
>  Mounted media class:      CD
>  Mounted media type:       CD-RW
>  Disk Is erasable
>  disk status:              complete
>  session status:           complete
>  ...
>  Track  Sess Type   Start Addr End Addr   Size
>  ==============================================
>      1     1 Data   0          19732      19733
>
> Burn a CD-RW in TAO mode
>  $ cdrskin/cdrskin -v dev=/dev/sr2 \
>                    blank=as_needed \
>                    -tao padsize=300k \
>                    /my/test/image.iso
>  ...
>  Starting to write CD/DVD at speed MAX in real BLANK mode for single
> session.
>  Last chance to quit, starting real write in   0 seconds. Operation starts.
>  cdrskin: blanking done
>  Blanking time:   28.114s
>  ...
>  Track 01: data   125 MB
>  Total size:      125 MB (14:16.15) = 64062 sectors
>  Lout start:      125 MB (14:18/15) = 64062 sectors
>
>  Starting to write CD/DVD at speed MAX in real TAO mode for single session.
>  Last chance to quit, starting real write in   0 seconds. Operation starts.
>  Waiting for reader process to fill input buffer ... input buffer ready.
>  ...
>  Track 01: Total bytes read/written: 131198976/131198976 (64062 sectors).
>  Writing  time:  117.206s
>  Cdrskin: fifo had 64062 puts and 64062 gets.
>  Cdrskin: fifo was 0 times empty and 14480 times full, min fill was 99%.
>  Min drive buffer fill was 45%
>  cdrskin: burning done
>
> The same command may be applied to other media.
> I tested only DVD+RW for now, but there is few
> reason why DVD-RW, DVD-R, DVD+R, BD-R, BD-RE
> should not work. (If all goes well, that is. In
> case of renitent drive or media, there might
> occur confusion. libburn is driving blindly
> here.)
>
> For more see
>  $ man cdrskin/cdrskin.1
> especially the EXAMPLES section.
>
> Do not use option -eject for now or else the
> program will not end voluntarily (it is ok
> to end it by Ctrl+C after the tray is out).
> CD burning without option -tao fail for now.
>
> If possible use a drive at USB or eSATA for the
> first tests. It might be that the drive gets
> stuck if the burn program fails during certain
> states of the drive or the Linux driver.
> In that case one has to cycle power. With
> built-in drives this means reboot.
>
> If problems occur then it would be helpful to
> compare with the normal Linux adapter:
>  ./configure --disable-libcdio
>  make clean
>  make
>  cdrskin/cdrskin ...
>
>
> Have a nice day :)
>
> Thomas
>
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]