Re: [Xen-devel] [PATCH 6/6] xen/xenbus-backend: Only register device if communication ring is local

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Dec 12, 2011 at 07:28:07PM +0100, Bastian Blank wrote:
> On Mon, Dec 12, 2011 at 10:42:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Sat, Dec 10, 2011 at 07:29:51PM +0100, Bastian Blank wrote:
> > > -module_init(xenbus_backend_init);
> > > -module_exit(xenbus_backend_exit);
> > 
> > Why are we removing the module functionality?
> > Can't this [the purpose of this patch] be done while still maintaining the 
> > module functionality?
> 
> Not really. The purpose is to register the device only if the ring is
> local. This information is not available to modules.
> 
> However we could just move the whole xenbus ring setup into a "module".
> Or is there any reason for this to be in a postcore_initcall, even if it
> is only operational after a userspace process works?

My thinking is that we do not want to use memory space if the kernel
is booted as baremetal (as there is no point of having Xen pieces around).
Modules work great for that.

But then part of this code is __init so some does get evicted, but not sure
how much. Could you measure this on baremetal please?

> 
> > >  int xenstored_ready;
> > >  
> > > +/* A flag to determine if xenstored is 'local' */
> > > +#ifdef CONFIG_XEN_BACKEND
> > > +static int xenstored_local;
> > 
> > bool?
> 
> Well. The other flags are int also.

Sure.. and they ought to be modified to bool too now that I think of it.

> 
> > > +                 BUG();
> > No way. A WARN, sure - but BUG() is way too intense for this.
> 
> Okay.
> 
> Bastian
> 
> -- 
> The sight of death frightens them [Earthers].
>               -- Kras the Klingon, "Friday's Child", stardate 3497.2

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel