On Mon, 6 Jun 2011 17:53:09 +0200 Arnd Bergmann <arnd@xxxxxxxx> wrote: > 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. The kernel does not have the same sort of access to this tree. > > > > 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? Because the hypervisor does not support it. It provides only getprop and setprop. I think you took my "you can't do that" statements to be a statement about limitations of using a filesystem interfcae -- quite the opposite, I was saying the hv functionality is too limited to support a filesystem interface with normal semantics. > > 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. I don't really see how a filesystem is a better abstraction for a wrapper around a procedural interface. A somewhat better argument is that ioctls are a pain, and Linux doesn't have a better way to expose a procedural interface, that doesn't require a wrapper program -- though as the wrapper already exists, and the fs interface would probably be sufficiently awkward that people would still use a wrapper, that doesn't buy us too much either. This is not being proposed as any sort of standard kernel API, just a way for userspace to get access to implementation-specific hcalls. Implementation-specific backdoor is practically the definition of ioctl. :-) I would be interested to see a concrete proposal for what this would look like as a filesystem, though, based on the actual operations that are available. How would you deal with getting all the parameters in, performing the operation, and getting the results back? What about when multiple processes are doing this at the same time? What would the memcpy hcall look like? -Scott -- 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
