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

Re: Receiving Network Packets with Mirage/kFreeBSD



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?

Robert


 


Rackspace

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