[<prev] [next>] [day] [month] [year] [list]
Message-Id: <843616099@web.de>
Date: Tue, 28 Jul 2009 22:37:24 +0200
From: devzero@....de
To: zamsden@...hat.com
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Allow userspace block device implementation
Hello Zach,
this older thread deals with some aspects of that idea: http://communities.vmware.com/message/577841
i have collected some links (added there) quite a while ago and also added a project proposal to http://kernelnewbies.org/KernelProjects, too.
i don`t know if you came across them, but it`s nice to see that someone comes up with this stuff again and maybe it`s of interest for you.
as we had vmware vmdk image mounter v1 being implemented via nbd and v2 via fuse, i assume both are not optimal solutions?
at least the nbd version sucked big.
regards
roland
ps:
oh, btw - you quit vmware? that`s quite a loss for them and for the vmware community, i think. too much conflicting basic attitude concerning opensource/gpl? ;)
> List: linux-kernel
> Subject: [PATCH] Allow userspace block device implementation
> From: Zachary Amsden <zamsden () redhat ! com>
> Date: 2009-07-27 9:57:10
> Message-ID: 4A6D79F6.3050509 () redhat ! com
> [Download message RAW]
>
> Well, it may be a good, bad, idiotic or brilliant idea depending on your
> personal philosophy. I went down this route out of pragmatism.
> Hopefully I have not fully re-invented the wheel.
>
> The patch included allows one to implement a kernel level block device
> in userspace, using an ioctl() based interface to create a sized device
> with given properties, and then receive and respond to bio requests
> issued to the device. One can poll on the associated control socket to
> allow efficient servicing of device requests. So far only strict copy
> to/from user memory is supported, there is no fancy page flipping or
> mapping operations.
>
> Which there probably should not be. This device is not about
> performance, is it about extending the boundaries of the kernel to the
> almost improbable. Now one can literally create any kind of device
> imaginable and use it as a block device in the kernel, mounting
> partitions and such and using them as if they existed natively. I have
> attached a very simple dummy program showing how to do this.
>
> The design requirements 'kernel block device in user space' to me
> demanded that the interface be stateless. Userspace can crash, be
> killed, or interrupted. Block devices cannot, they must answer all
> requests, even if that answer is a failure. Thus there exists no state
> between the kernel and the userspace process(es) or threads serving the
> device. No establishment of connections, just a queue which can be read
> and answered via get and put, the ioctl operators available. This
> allows a completely flexible userspace implementation, with multiple
> processes, etc, and allows complete recovery via a simple reset command
> if those programs fail. I believe this also prevents any possibility of
> accidental deadlock. There may of course be some hidden deep deadlock
> potential in such a device, especially if one decided to use it as a
> swap device, but again, this is a philosophical issue.
>
> Enough talking, let's have at it and see where this goes. Obviously
> this is experimental and open to feedback. Considering it turns kernel
> interfaces on their head, I have given it what I feel is an appropriate
> name.
>
> If there is any person or list you know that I forgot to copy this to,
> please forward it on to them.
>
> Thanks,
>
> Zach
>
> _________________________________________________________________
> Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
> für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/01/
>
>
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists