rdiff-backup-users
[Top][All Lists]
Advanced

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

[rdiff-backup-users] Question for Linux Kernel Hackers


From: Ben Escoto
Subject: [rdiff-backup-users] Question for Linux Kernel Hackers
Date: Sun, 9 Nov 2003 23:03:00 -0800

Hi, I have spent a bit of time working on the format as described at:

http://www.nongnu.org/duplicity/new_format.html#concrete

and have a minimal prototype that can read and write _very_ basic
files of this type.  However, I've run into a little snag when trying
to write the filesystem for it.  Before I ask my question, I'm going
to write a litte background, so you can see if my question is
well-posed.


      Problem:

The basic problem is that linux filesystems seem to have to run in the
kernel.  This implies it is running as root, and (in practice) must be
written entirely in C.  However, this program may have to invoke
GnuPG, it may be parsing XML, etc.  It doesn't seem appropriate to do
this in kernel space.  And, as I may have mentioned, I don't know/like
C very well.


      Rejected Solution:

One strategy which at first I thought might work would be to write a
program like losetup, which simulates a block device.  The result
would be something like this:

  Kernel <===========> Loop device <============> archive file
          conventional              main archive
           filesystem                 program

where the conventional fs driver would be running in the kernel, but
could be pretty small, and would do the usual fs things (i.e. reading
blocks from a block device).  In the theory the loop device could even
mimic an existing file system.  The archive program wouldn't have to
run in the kernel, and could invoke GnuPG and whatnot.

However, the problem with this is that losetup seems to have to run as
root and even in kernel space.  So really nothing is gained by
splitting things like this; everything must still be a kernel module.
Correct me if I'm wrong.


      Proposed Solution:

Instead of through a block device, the kernel module and archive
program could communicate over a socket:

  Kernel <================> socket <==============> archive file
             filesystem              main archive
          (unconventional)             program

The protocol used to communicate between the main program and the
kernel driver could be very simple, with the "main archive program"
doing almost all the work.  The kernel portion of the filesystem could
be written in less than 1000 lines of C I think.

Since now we are just communicating by sockets, the main program
(which runs GnuGP, etc.) could be in a different process (or computer)
and running in user space.  (And it wouldn't have to be written in C.)

To users, setting this up would require that they run the main archive
program, and then run 'mount':

dar --bind-as-filesystem socket_file archive.dar
mount -t darfs -o socket_file none /mnt/mount_point


      The Question(s):

So, does this make sense?  Am I missing something silly?  I'm not
familiar with kernel programming, so it's quite possible.  The kernel
file systems I've read have all used bread() or similar to read
data---would there be complications in using a socket instead?  Is
there a better/easier way to do what I want?


-- 
Ben Escoto

Attachment: pgp9Nv7zGjzoz.pgp
Description: PGP signature


reply via email to

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