lkml.org 
[lkml]   [2000]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Driver for emulating a tape device on top of a cd writer...
On Tue, Dec 19 2000, Stelian Pop wrote:
> > > Basically, I would like to be able to use a cdwriter as a tape
> > > device, with software like dump(8) or tar(1). With /dev/tcdw
> > > as name (for example), I'd like to be able to do:
> > > [...]
>
> > What you describe is actually one of the goals of the packet writing
> > driver. To do this reliably you need packet writing, I won't even
> > start to think about the headaches wihtout it...
>
> Yes, I saw your patch for packet writing but:
> - the CD written with packet writing software may not be readable
> on standard CD-ROM drives (and I want that, because almost
> everybody has one).

On CD drives sold during the last two years or so, and of course
all DVD drives they are readable. But of course of you want 100%
coverage, it isn't good enough.

> - using packet writing you basically write _files_ on top of an
> UDF filesystem. Tar and dump (or afio, cpio etc) does not
> support that kind of access, they expect to be given a character
> device they can stream data to. (Of course, it is possible to
> add some additionnal level of indirection on top of the packet
> device and provide character based access to the UDF files, but
> IMHO _this_ would be overkill).

Why would you even want to use UDF for this? You want raw access
to the device. Packet writing or not, this is totally unrelated.

> - data backups are expected to be fast. Writing data in DAO/TAO
> mode is much quicker than in packet mode.

No no no, not much quicker. Write large packets and it's just
as fast as dao/tao. 64Kb packets are a bit slower because of
run-in, run-out block over head, but using larger packets this
isn't the noticable. And packet writing has so many other
advantages...

> - reliability is a question of implementation. cdrecord can
> be very reliable. If a user space application can provide this
> level of reliability, it should be even simpler to achieve it
> in kernel space (and I plan to use the BurnProof/etc extensions
> which will be present on all future cdwriters).

Even simpler to achieve reliability in the kernel? I gather you
mean feeding-data reliability, and not stability.

> > > I'll start to work on this, probably by looking at the cdrecord
> > > low level code and porting it into kernel space.
> >
> > Oh god no! You can do all this from user space.
>
> Please pay attention to the fact that I was refering to the 'low level
> code'. I don't intend to write a driver who can replace cdrecord.
> _This_ would be madness.

Very much so

> What I indend to do is just a 'small' driver, which supports only the
> mmc drives. I expect the driver to be only some hundreds lines long.

A few hundred lines? *This* I look forward to seeing :)

> Doing that from user space would mean propagating the data from
> the user space application (dump or tar) to a character mode
> driver, and back to a user space application (something like a hacked
> cdrecord), which will return in kernel space using sg interface...
> It could be easier to write (even if I don't exactly feel confident
> about hacking the cdrecord source :) ), but the reliability and
> the performance would be far far away...

Pipes and 100% user space based, then pass to sg? I don't see the
problem.

--
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.131 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site