"Michael S. Tsirkin" <m...@redhat.com> writes: > On Thu, Apr 14, 2016 at 09:39:07AM +0200, Markus Armbruster wrote: >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> >> > On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote: >> >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> >> >> >> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote: >> >> >> If we can protect them without >> >> >> complicating or breaking stuff, sure, why not. But not at all costs. >> >> > >> >> > The stuff we break is precisely the stuff our warnings >> >> > say might break at any time. So since you believe users >> >> > might be relied on not to ignore warnings, it should be ok ... >> >> > >> >> > As for complicating things - about 5 lines of code are spent >> >> > on the unsupported/root/ hack. It *is* a hack but >> >> > contained enough not to worry me too much ... >> >> >> >> I'm not worried about the implementation complexity at all. It's the >> >> user interface complexity. After this patch, we have a non-trivial >> >> mapping from -fw_cfg name to FW_CFG filename to explain. Whereas now, >> >> -fw_cfg name *is* the FW_CFG path. >> > >> > Only for people who ignore the rules. Most people have a trivial >> > mapping. >> >> Even when most usage falls into the simple cases, you still have to >> explain all cases. >> >> An interface's complexity is a property of the interface, not of its >> usage. > > I think I disagree. Make simple things simple and complex things > possible is the rule for a good interface.
No, you're not making a complex thing possible, you're making a simple (if unadvisable) thing complex! That's an entirely different cup of tea. The design rule that actually applies is that an interface's obvious uses should be correct uses. In my opinion, there is no truly obvious use of -fw_cfg. The closest we get to "obvious" is "use this fixed name to do that", where somebody else picked the fixed name. That somebody else should've picked a name starting with /opt/RFQDN/. Your proposal proactively breaks some of those third party interfaces between host and guest (the ones using names outside /opt) to avoid breakage in hypothetical scenarios in the future. Users have to prefix /unsupported/root/ to keep them working. Could perhaps be viewed as making an "obvious" but incorrect use less obvious. Your proposal provides does nothing for badly chosen names within /opt. The next use case to consider is a user picking a new name for a new interface between host and guest. I find the idea that such a user won't notice warnings farfetched. But let's assume such users exist. We're talking about someone who strays out of /opt out of willfulness or ignorance *and* can't be bothered to read warnings, and because of that we reject his usage outright to drive home the point. What good is that going to do? What are the chances this will make such a user actually read the docs, pick an appropriate RFQDN and stick to /opt/RFQDN/? I think they're remote. Multipy it by the probability of this case even happening, and the result is even more remote. The final use case to consider is development, testing and debugging. By their nature, these use arbitrary names, and future-proofing is entirely irrelevant. In particlar, use of names outside /opt/RFQDN/ is not wrong there. It's only wrong when you bake them into a interface that outlives your development, testing or debugging. So this use case gets more complex without any benefit. Complicating development, testing or debugging can be tolerable when there's a real benefit to users. In short, you're making one special case of one misuse of the FW_CFG name space more complex in an attempt to make this misuse less obvious in the interface, while doing nothing for other kinds of misuse. The question to ask is whether it's worth it. In my opinion, it isn't worth it, because the additional interface complexity plus the backward compatibility break, minor as they are, still dwarf the benefits several times over.
