Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> On Thu, Apr 14, 2016 at 09:39:07AM +0200, Markus Armbruster wrote:
>> "Michael S. Tsirkin" <address@hidden> writes:
>> 
>> > On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote:
>> >> "Michael S. Tsirkin" <address@hidden> 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.