[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Receiving Network Packets with Mirage/kFreeBSD

On 22 Aug 2012, at 00:48, "Robert N. M. Watson" <robert.watson@xxxxxxxxxxxx> 

> On 20 Aug 2012, at 14:46, PALI Gabor Janos wrote:
>> On Sun, Aug 19, 2012 at 07:19:00PM +0100, Richard Mortier wrote:
>>> out of curiosity, and from a *very* naive viewpoint [..], how applicable
>>> would the same structures be to supporting disk/other io access?
>> As far as I know [1], handling I/O is implemented by two asynchronous halves
>> in the kernel.  The lower half sits on interrupt services and places the
>> received data in (per-device) queues.  In parallel with this, the upper half
>> reads the shared queues and processes their elements.  (Sending data is just
>> the opposite.)
>> In this particular case, the lower half is implemented in C while the upper
>> half is in OCaml.  I do not see any difficulties in adapting this to other
>> I/O devices, but Robert or Anil may prove me wrong :-)
> Disk I/O operations are a lot like packets, especially lately with high TPS 
> flash-based storage devices (vis FusionIO, etc). The KPIs are all a bit 
> different, but there's no reason to think that could easily be worked 
> through. An interesting question is where else storage-esque requests might 
> be sent -- the places, off the top of my head, that sound plausible are:
> (a) A hypervisor running under the OS hosting Mirage/kFreeBSD -- e.g., as 
> though Mirage were running straight on the hypervisor.
> (b) OS services underlying Mirage/kFreeBSD -- e.g., the block storage 
> mechanism (geom), file system, etc.
> (c) Userspace running on top of FreeBSD -- e.g., a miraged that can proxy 
> requests somewhere.
> However, I'm ignorant of Mirage's storage-esque facilities -- ordinary file 
> system? Flag transactional thingy?

We have libs for:

- FAT16/32/64
- Simple k/v
- https://github.com/Incubaid/baardskeerder (CoW B-tree)
- NFSv3 (needs porting, but fairly minor)

The Block interface is a ring buffer, with the underlying protocol shared with 
Net (a ring buffer with req/responses), and there is no special filesystem 
layer.  Applications currently just link against their desired fs or k-v 




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.