Re: [Xen-devel] Implementing poll(2) for Mini-OS?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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).

> > 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.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel