> > [Follow-up from LPC discussion] > > > > This patch is not needed, you can use liveupdate_flb_get_incoming() > > directly in early boot. The main concern is that we take mutex in that > > function, but that I think is safe. The might_sleep() has the proper > > handling to be called early in boot, it has "system_state == > > SYSTEM_BOOTING" check to silence warning during boot. > > Right. I will give it a try. For hugetlb, this works fine since it > doesn't really need to do much in FLB retrieve anyway, it just needs to > parse some data structures. > > If other subsystems end up needing a two-part retrieve, one in early > boot and one later, then I think it would be a good idea to model that > properly instead of leaving it up to the subsystem to manage it. > > Anyway, that isn't a real problem today so let's look at it when it does > show up.
FLB has exactly one .retrieve() lifecycle event. Once called, the data is considered fully available and cached in private->incoming.obj. If a subsystem has a requirement where it needs a specific state available very early and other state available much later, the clean solution is simply to register two separate FLBs. Pasha
