On 31.01.22 07:23, Oscar Salvador wrote: > On Fri, Jan 28, 2022 at 04:15:40PM +0100, David Hildenbrand wrote: >> ... and call node_dev_init() after memory_dev_init() from driver_init(), >> so before any of the existing arch/subsys calls. All online nodes should >> be known at that point. >> >> This is in line with memory_dev_init(), which initializes the memory >> device subsystem and creates all memory block devices. >> >> Similar to memory_dev_init(), panic() if anything goes wrong, we don't >> want to continue with such basic initialization errors. >> >> The important part is that node_dev_init() gets called after >> memory_dev_init() and after cpu_dev_init(), but before any of the >> relevant archs call register_cpu() to register the new cpu device under >> the node device. The latter should be the case for the current users >> of topology_init(). > Hi Oscar, > So, before this change we had something like this: > > do_basic_setup > driver_init > memory_dev_init > do_init_calls > ... > topology_init > register_nodes/register_one_node > > And after the patch all happens in driver_init() > > driver_init > memory_dev_init > node_dev_init > > I guess this is fine as we do not have any ordering problems (aka: none > of the functions we used to call before expect the nodes not to be > there for some weird reason). > > So, no functional change, right? > Right, and the idea is that the online state of nodes (+ node/zone ranges) already has to be known at that point in time, because otherwise, we'd be in bigger trouble. Thanks! -- Thanks, David / dhildenb
