On 19/11/13 15:19, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 19, 2013 at 02:56:41PM +0000, David Vrabel wrote: >> The relevant bits in dummy_numa_init are in the error path of >> xen_numa_init(). > > That seems the wrong place to do it. The top layer calls > in each of the numa implementations and then falls back to > the dummy.
Think of it as not the dummy, but Xen setting the NUMA configuration up with only a single node. The useful bits in dummy_numa_init() are two calls to standard functions for use by *_numa_init() calls so it just seems easier all round to just call then directly than add a dependancy on dummy_numa_init(). > Calling from within the implementation on something that is eventually > done on the upper level already is not right. >From the point of view of the caller, it does the right thing. NUMA is setup. >> I do think this approach (using the provided API to setup the single >> (dummy) node), is preferable to calling dummy_numa_init(). > > Doesn't it do the same thing? And also what about if you the user > provides fakenuma? I don't know what "fakenuma" is refering to. >> If I thought the hypervisor ABI was finalized, I'd be happy with this >> series as-is -- the remaining issues are superficial. > > That reads to me as an Ack, but I know you like to have it stated > explicitly - so could you state the proper tag please? "If I thought the hypervisor ABI was finalized..." is a pretty big "if" so I have deliberately /not/ given an ack or a reviewed tag but I've tried to be clear than I think the Linux side is now good enough (except for any changes for any updates to the hypervisor ABI). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
