On Sun, Jan 26, 2025 at 03:41:11PM -0500, Pasha Tatashin wrote: > number of physical ranges is going to be small. If the preserved data > is so large that it cannot fit into a reasonably sized tree, then I > claim that the data should not be saved directly in the tree. Instead, > it should have its own metadata that is pointed to from the tree. It sounds like if a driver needs more than a few hundred bytes it should go this other way. > Yes, for entities like file systems, there absolutely should be a > small KHO info entry pointing to metadata pages that preserve the > normal pages. However, for devices that are kept alive, most of the > data should be saved directly in the tree, This doesn't seem feasible for the NIC we are looking at. There will be ALOT of data, it doesn't make alot of sense to significantly involve the boot DT in this. I think the same will be true for iommu as well. I think you guys are leaning too much into simpler SW based things like ftrace as samples.. > > Also, I'm not sure forcing using DT as a serializing scheme is a great > > idea. It is complicated and doesn't do that much to solve the complex > > versioning problem drivers face here.. > > The primary goal of the KHO device tree is to standardize the > live-update metadata that drivers preserve to maintain device > functionality across reboots. Honestly, I think this will not be welcomed, or workable. DT does not fully preserve compatability, it is designed for a world where if you don't read the values serialized then no harm. If you want to use DT you need to make it simple for drivers to address this. But that does not describe KHO, if the predecessor kernel serialized something and the successor doesn't understand it, that is fatal. I also think YAML and more formality is *way* too much process! One of my big bug-a-boos about KHO is that it *NOT* create a downside for the majority of kernel users that don't/can't use it. Meaning we don't mangle the normal driver paths, we don't impose difficult ABI requirements into the driver design and more. > getting device tree from firmware. Otherwise, we could just use other > methods such as PKRAM where it no inherent standardization involved, > but that allows to serialize devices absolutely during any phase of > reboot. This sounds like a better idea, at least as as starting point. Maybe down the road some more formalism can be be agreed, but until we have experiance with how much pain KHO is going to cause I think we should go slow in upstream. Jason
