> >>>> Not only inform firmware. > >>>> Hotplug notify callback will invoke acpi_bus_add -> ... -> > >>>> implicitly invoke drv->ops.add method to add the hotadded memory > >>>> device. > >>> > >>> Gotcha. > >> > >> ? So it will lose the notification and no way to add the new memory > >> device in the future. > >> > >> Xen memory hotplug logic consist of 2 parts: > >> 1) driver logic (.add/.remove etc) > >> 2) notification install/callback logic > >> If you want to use 'xen_stub driver + .add/.remove ops', then > >> notification install/callback logic would implement with xen_stub > >> driver (means in build-in part, otherwise it would lose notification > >> when the ops unload) --> but that would make xen_stub in big build-in > >> size. > > > > How about > > * build-in part: xen_stub driver (stub .add to record what matched > > cpu devices) + notification install/callback; > > * module part: .add/.remove ops; > > w/ it, native driver has no chance to load and no hotplug event lose, > > and approximately 1/3 code is build-in and 2/3 are module. > > > > I think it will work but I'm not quite sure, at least we can have a > > try/test? > > > > Thanks, > > Jinsong > > > > Thoughts? If you think it's OK, I will update later.
Pls try. I am just thinking that the less we of code that has to be built-in - the better. > > Thanks, > Jinsong -- 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/
