[dm-devel] Another experimental dm target... an encryption target

[jon+lvm at silicide.dk]

On Sat, Jul 26, 2003 at 07:52:55PM +0200, Christophe Saout wrote:
> Am Sa, 2003-07-26 um 18.54 schrieb jon+lvm at silicide.dk:
>  
> > > > Well this does kind of make my project redundant and moot :(
> > > 
> > > Not really. There are still things like storing the key on disk,
> > > encrypted with an assymetric key (password) or something. And the LVM
> > > part.
> > 
> > yeah, but arent you gonna make those?
> 
> No, I just wanted to play with the device mapper, the in-kernel part
> only. I don't know why, but I find kernel programming much more
> attractive. And the device-mapper is a very cleanly structured piece and
> easy to understand.

i sort of consider LVM part of the kernel too, because without each
other, neither is anything.

 
> > > Hmm, just for fun?
> > 
> > hehe, thats the spirit :)
> 
> Yes. The thing is, my semster at the university ended some days ago and
> I really love programming but don't have too much time. I wanted to play
> with the device-mapper for some time and now I got some ideas. I didn't
> think it was so easy. I even barely had any oopses.

i have other kernel coding ideas if you're interested, some are more
hardcore than others. They are not LVM related though, except that 
one of them might be a dm-target, or a filesystem. That one is because
i'm a little annoyed that it is cumbersome to add more disks to a
system, and LVM is not the answer i'm looking for. What i want is:
i have a number of disks, and i want to distribuate data across those,
but the data must be replicated so i can handle a loss of one or more
disks (user specified). Further more, i want to be able to add new
disks to this blockdevice, and remove them. The filesystem grows
and shrinks. It is sort of a raid5 device that you can add new disks
into like you can with LVM, and then the system distribuates the data
across the disks. This might take some time to rearrange the data,
but the point is that the sysadm shouldnt worry about how to migrate
data, he/she justs adds disks.


> The interesting thing is that Joe said that the crypt target would be
> easier than the file target (ok, if I have had to find out how to use
> the filesystem it would have taken much more time, but I could simply
> use the implementation of the loop driver). Actually my crypt target is
> larger than the file target, and I used the worker thread I had
> implemented there. Now it's 675 lines in size, a lot of comments, a lot
> of copied code, really not complicated.

just because it is bigger doesnt mean it isnt easier, and besides, Joe could
be mistaken ;-)


> > Well, it's sort of both ways. I like encryption, and i want more support
> > for that in linux. That part i am thrilled about. But i'm not too thrilled
> > if i means the end of my university project, however, i guess that i better
> > get used to other people doing the same things that i want to, it's not like
> > i own the idea. You did catch me off guard, i didnt expect anyone to rush 
> > out and do the same thing that i said i would try, but maybe thats common
> > in the OS development world?
> 
> Yes, there is a lot of development in parallel. Normally this leads to
> better and better implementations in the end.

yeah, well i only expected this to happen after i did mine.


> The thing is, after my file backed target worked I wanted to try how you
> could manipulate the data on its way through the target. The only useful
> thing I could think of was using the cryptoapi because I had seen how it
> was used in the loop driver - and it was very easy to use.
> 
> After it worked I was just too happy that it worked so I couldn't resist
> to post it. Sorry.

i can understand that you were happy.




JonB