From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Implementing poll(2) for Mini-OS? Date: Mon, 18 Feb 2013 17:05:59 +0000 Message-ID: <1361207159.3825.40.camel@zion.uk.xensource.com> References: <1361202056.3825.28.camel@zion.uk.xensource.com> <1361203619.1051.25.camel@zakaz.uk.xensource.com> <1361204290.3825.37.camel@zion.uk.xensource.com> <1361204755.1051.38.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1361204755.1051.38.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Samuel Thibault , Daniel De Graaf , wei.liu2@citrix.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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... Wei. > Ian. >