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

[Michael B. Trausch]

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