[Top][All Lists]
[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
pgp9Nv7zGjzoz.pgp
Description: PGP signature
- [rdiff-backup-users] Question for Linux Kernel Hackers,
Ben Escoto <=