Kernel-space flirting with user-space

Simon turner25 at gmail.com
Wed Jan 16 13:04:46 EST 2013


On Fri, Jan 11, 2013 at 10:32 AM, Kristof Provost <kristof at sigsegv.be> wrote:
>
> On 2013-01-10 16:09:49 (-0500), Simon <turner25 at gmail.com> wrote:
> >   Firstly, I was wondering if it would be possible to implement the
> > filesystem entirely as a kernel module.  I would need TCP/UDP sockets.
> > I
> > think this is really not the recommended approach, but an advantage I
> > see
> > is it could be used to mount the root filesystem before calling init
> > (that
> > would be before user-space exists, right?).  On the other hand,
> > separating
> > the work to have a program/daemon in user-space do the communication and
> > processing would allow me to write that part in C++ (which I personally
> > prefer).
>
> It's certainly possible to implement a network file system entirely in
> kernel space. That's where NFS is implemented.
> If you *really* care about performance it's pretty much the only way to
> go. If you don't you should keep as much as possible in user space.
>
> In either case I'd recommend you start your development on top of fuse
> though. That means you can implement all new code in user space, in
> whatever language you prefer. It'll be much easier to debug in any case.
> Think of it as a fast prototype, to validate your protocol.

Hi Kristof,
  thanks for your reply.  On my personnal projects, when starting from
scratch, I usually set the goal to "refuse optimization" the code or
the goal to "write inefficient code".  This is mostly a psychological
barrier to avoid premature optimization, which I am prone to.
However, efficiency is a goal for the later stages and so writing the
whole thing in kernel space from the start might be a good idea (less
stuff to rewrite or to "fit in").

  About using FUSE.  I have to say your arguments for its use are
compelling.  However, one of my hidden goals is to learn and practice
kernel programming and if I'd use fuse, I'd be constrained to "fuse
programming" which is also restricted to filesystems.  The day I want
to build something else I would have to start from square one with
kernel programming.

  Also, another project I have in mind after this one is to implement
the same concept, but using a block device instead (I think this comes
very close to what iSCSI does).  It would enable the use of RAID or
LVM on top of that networked block device.  I don't think this will be
more efficient than my current project (specially for use on the
internet), but it might be useful in other ways (for backups perhaps,
or a raid mirror of local device with networked device tuned with
--write-mostly and --write-behind).  At least, mdadm can be used to
handle disconnects/failures, to resync the devices, to manage what
remote hosts are used.  Anyway, this one is still a very foggy idea in
my mind; it has the word "perhaps" stamped in red across it! ;)

  I'll weight the pros and cons for using fuse when I feel ready to
start development.

Thanks again,
  Simon



More information about the Kernelnewbies mailing list