Re: Implementing poll(2) for Mini-OS?

[Wei Liu <wei.liu2@citrix.com>]

On Mon, 2013-02-18 at 17:05 +0000, Wei Liu wrote:
> On Mon, 2013-02-18 at 16:25 +0000, Ian Campbell wrote:
> > On Mon, 2013-02-18 at 16:18 +0000, Wei Liu wrote:
> > > On Mon, 2013-02-18 at 16:06 +0000, Ian Campbell wrote:
> > > > On Mon, 2013-02-18 at 15:40 +0000, Wei Liu wrote:
> > > > > Hi Samuel and Daniel
> > > > > 
> > > > > I sent a patch to switch cxenstored's event loop from using select to
> > > > > using poll several weeks ago, however this would break xenstore-stubdom
> > > > > as Mini-OS has no poll(2) implementation at the moment.
> > > > > 
> > > > > I think implementing poll(2) for Mini-OS could be a good idea, but I
> > > > > don't know how far I should go. I'm not familiar with xenstore-stubdom,
> > > > > and I tried setting it up but it didn't work so I gave up. :-(
> > > > > 
> > > > > To my understanding we only care about the interface but not the
> > > > > implementation. I looked into Mini-OS's lib/sys.c this morning, noticing
> > > > > that the internal file abstraction only supports up to 32 files. Is this
> > > > > xenstore-stubdom only for DomU? If it is for Dom0, how can it handle
> > > > > more than 32 fds?
> > > > 
> > > > What do you mean? A stubdom must necessarily be dom!=0 but it should be
> > > > able to service all other domains, including dom0 and other domUs.
> > > > 
> > > 
> > > Hah? This is my first impression, but we still need a xenstored running
> > > in Dom0, right?
> > 
> > No
> > 
> > >  Otherwise what's the output of `xenstore-ls` in Dom0?
> > 
> > It talks to the remote stubdom, in the same way that a domU normally
> > would.
> > 
> > There is only one xenstored in the entire system. (Ignoring extreme
> > disaggregation like the XOAR paper).
> > 
> 
> OK.
> 
> > > > Do we use an fd per evtchn or only one in xenstore? If the former then
> > > > that's a bit of a limitation of the xenstore stubdom!
> > > > 
> > > 
> > > Xenstore has a struct connection which has one fd for each connection.
> > > So if there are too many connections, how can xenstore stubdom handle
> > > this situation? As I can see in a xenstore process running in Dom0, it
> > > can certainly opens more than 32 fds.
> > 
> > In theory it could share the same /dev/xen/evtchn handle between all
> > connections.
> > 
> 
> I think the real magic is that in cxenstore's implementation there is
> some ifdef around specific code to avoid using too many fds, but I
> haven't gone too deep into that...
> 

Oops, hit send for a mis-composted email, please ignore this... I'm
still investigating this.


Wei.