[ale] Anyone here who is good with kernel programming?

[Doug McNash]

/dev/sr0 is a block device for reasons related to the typical use of CD's and DVD's as mounted filesystem devices.

Seems to me the easiest and cleanest solution would be to create a character device interface in drivers/cdrom.c and make it behave like a tape drive.  Optical media is essentially tape like in that it is one long spiral track but you can seek with out too much a performance hit on it since it is spiral by seeking upstream and looking for the formatted block header (I thinks this is close to the truth).

To make it behave like a tape, one would need to come up with a way to mark an EOF and return an error at EOT (cpio(Sys5) for instance asks for the next tape on most any error returned by the driver). Providing an interface to return capacity wouldn't be to hard either.

I do this stuff for a living (when I can find the work), one of my first jobs was writing scsi tape drivers.

I have always wanted this behavior on my driver too for doing tape like backups since my tape drive died about a decade ago.

I hope this makes sense cause I'm violating my no post after 11pm rule.
--
doug mcnash

---- "Michael B. Trausch" <mike at trausch.us> wrote: 
> I'm finding myself (again!) running into the annoying limitation of not 
> being able to write directly to optical media without third-party 
> programs.  What I'd like to do, even if upstream *never* accepts it, is 
> to modify my local kernel (and perhaps patch GNU tar, though that would 
> be the easy part) to permit something like the following on Linux systems:
> 
> # tar --create --multi-volume --file=/dev/sr0 /home
> 
> Currently, to accomplish the same task, one has to do something like this:
> 
> # mkfifo backup_stream
> # tar --create --tape-length=683593 --file=backup_stream /home
> 
> And then in another shell (for every single volume):
> 
> # wodim -tao backup_stream
> 
> Which generates lots of warnings and the like, and is just completely 
> not useful when someone just has to come in, run a backup, and go away 
> without any knowledge of Unixy systems in general.
> 
> There are several problems with this method:
> 
>    * All media must be the same size (or at least, no smaller than the
>      --tape-length specified on the command line)
>    * There is necessarily some wasted space on the backup media because
>      there is no way to detect the amount of data that will actually fit
>      and then pass that back to tar, so the smallest expected disc size
>      must be given to tar.
>    * wodim or growisofs must be run once for every disc in the set,
>      instead of just changing discs and telling tar that it should be
>      able to do a new disc.
>    * If the human doing the backups is only reliable enough to read
>      "Prepare volume #x for `backup_stream' and hit return:" and do that,
>      then you would have to have a program managing the burning process
>      in a pty.
> 
> Without modifying the kernel, it would seem that the best solution to 
> the entire problem would be to write a program that allocates two pty 
> pairs, runs tar in the first pty and runs wodim or growisoimage in the 
> second one, hiding all the detail away so that it is comfortable. 
> Furthermore, it could then count the directories and such and show a 
> progress indicator on the tar operation and on the per-disc burning 
> process.  However, I think I'd rather just be able to use tar and be 
> done with it.
> 
> On to the question, then:  Does anyone know what would be required to 
> implement sequential write access in the kernel?  The way that I would 
> envision it, it only needs to do two things:  Write sequentially to a 
> disc when it is already purely blank, or reject the write if there is 
> already data on the media (that is, I would be fine without the ability 
> to append to discs).  I would also be fine with the kernel only 
> guaranteeing success if the data stream is constant.  That would also 
> imply that there should be a means, perhaps via an ioctl() operation, to 
> set the speed on the drive if the stream is known to be slower than what 
> the drive's write speed is, and also that the kernel should take care of 
> some form of buffering.
> 
> The major problem is that I don't have the slightest clue where I would 
> make such changes, nor do I know the first thing about making them at 
> that level.  I'd be able to write a userspace solution if I had to, but 
> I'd rather not.
> 
> Any advice or pointers?
> 
> 	--- Mike
> 
> -- 
> Michael B. Trausch                    Blog: http://mike.trausch.us/blog/
> Tel: (404) 592-5746 x1                            Email: mike at trausch.us
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo