[haiku] Re: lkl-haiku-fsd: patch for GSoC acceptance

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 15 Apr 2010 09:58:22 +0200

On 2010-04-15 at 00:54:50 [+0200], Lucian Adrian Grijincu 
<lucian.grijincu@xxxxxxxxx> wrote:
> One of the things you mention you want students to work on is a patch
> to prove their skills and understanding of the project.
> 
> I was looking at the list of tickets for file systems [1] and found
> [2] "Implement a file system for IMAP".
> 
> Now, even though my work on the LKL-based file system driver would be
> done in kernel using the Haiku VFS API [3], I'd like to know if it
> mattered if I tried to hack things up using userlandfs.
> 
> My arguments:
> * there's a lot of IMAP processing to be done in the kernel which
> improperly written can lead to nasty remote code execution, machine
> takeover etc.
> * there are IMAP libraries that can be used from userspace. Converting
> them to kernel API is not trivial and I don't see an advantage to
> this.
> * authentication protocols are especially hard to get right. No one
> would use a file system driver which would send their password
> plain-text over the internet, and I really think implementing SSL in
> kernel is too far out (think about key verification, key revocation
> lists, CA public key management, etc., etc.).

Your arguments are sound. The pretty much only argument against using 
userlandfs is performance. Unlike e.g. FUSE our userlandsfs uses a 
userland-kernel interface that allows a pretty much exact replication of the 
kernel FS interface (including its usage patterns) in userland. It is more 
geared towards aiding writing kernel FSs than implementing efficient userland 
FSs.

You're right, however, that porting the protocol libraries to the kernel (or 
implementing the protocols from the scratch) is not a particularly good idea. 
Maybe a hybrid approach would be possible -- like implementing the FS in 
kernel, but letting it spawn a userland process for the communication part. 
That would allow for a more efficient special-purpose kernel-userland 
interface, thus yielding a way better performance than a userlandsfs based 
solution.

Anyway, since you ask specially for a task to promote your GSoC application, 
I guess a full IMAP FS implementation is somewhat over the top, particulary 
since our deadline for selecting applications is the 21st. If you want to 
start working on it, feel free of course. Even a partial implementation that 
can mount the FS and list the mail files would be an ample demonstration. A 
userlandsfs based solution will be fine, of course. At any rate please mind 
the deadline, giving us at least another day to review the code.

CU, Ingo

Other related posts: