On Friday 03 June 2011, Scott Wood wrote: > On Fri, 3 Jun 2011 17:28:43 +0200 > Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Thursday 02 June 2011, Scott Wood wrote: > > > I wanted to have the hypervisor take an update dtb (we already have special > > > meta-properties for things like deletion as part of the hv config > > > mechanism). But others on the project wanted to keep it simple, and so > > > get/set property it was. :-/ > > > > > > It's unlikely to change at this point without a real need. > > > > > > As for a filesystem interface, it's not a good match either. > > > You can't iterate over anything to read out the full tree from the hv. > > > > kexec iterates over /proc/device-tree to create a dts blob. > > That's irrelevant, because we're not talking about that device tree. We're > talking about the device tree of another hypervisor guest. I understand that it's a different device tree. That doesn't mean we can't use the same tools. > > > You can't delete anything. > > > > rm, rmdir > > > > > You can't create empty nodes. > > > > mkdir > > I know how to operate a filesystem. You can't do these operations *on > another guest's device tree through the hv interface*. Why not? From a device driver perspective, it's not much of a difference whether you export a device (or hypervisor, firmware, ...) setting as an ioctl or an inode operation. > > > There would still be other ioctls needed for starting/stopping the > > > partition, etc. > > > > Right, although you could model them as a file interface as well. > > KVMfs is one example doing that. > > And what would be the benefit of this major restructuring and added > complexity? I think it would be a slightly better abstraction, and the complexity is not as big as you make it sound. I'm mainly countering your statement that it would be a bad interface or that would not possible to do. I'm not that opposed to having an ioctl interface for your hypervisor interface, but I am opposed to making design choices based on a bad representations of facts or not having considered the options that other people suggest. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
