linux-kernel - Re: Version number policy!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ-VmomdD9nOrAb0_cY7vYw1DiP7ENnGALW=24newMj-XZ4cTA@mail.gmail.com>
Date:	Fri, 5 Apr 2013 12:16:46 -0700
From:	Adrian Chadd <adrian@...ebsd.org>
To:	Christian Lamparter <chunkeey@...glemail.com>
Cc:	Eugene Krasnikov <k.eugene.e@...il.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	ath9k_htc_fw <ath9k_htc_fw@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Version number policy!

The point here is that once we hit a new major version, all the
previous version checks can go away.

So, if we decide to change some WMI message formats, it'll be in 2.x
rather than 1.x.

For example, has talked about killing off rate control in the NIC and
doing it on the host. I'm happy with that (since it's easy enough to
move back into the NIC if people want it for whatever reason) so:

* Do we make it configurable?
* Do we make it backwards compatible?
* Do we just say "oh screw this" and treat it as part of the next
major revision?

If I were doing this for work and there was a long lifetime
requirement for this stuff, then sure, we may have pressure from
various groups to maintain backwards compatibility. And as we do so,
we end up slowly bloating out the firmware and adding more driver
capabilities.

But since we're doing this in an open community, we can just create
branches and let people who wish to maintain things do so, whilst not
tying ourselves down too much. We have very specific pressures here
(ie, how much RAM and CPU these little USB SoCs have), so we can't
just infinitely grow the API.

If there are bugfixes that someone like Google, Redhat or Canonical
need for the 1.3 firmware in say, 2015 (when we've moved onto a much
later evolution of this firmware) because they have a compat-wireless
download that _only gets bugfixes_ and doesn't get new features (ie
,doesn't just sync against the latest compat-wireless to get bugfixes
_and_ features), then they're quite welcome to cherry-pick fixes from
mainline, merge them into the 1.3 branch and send a diff or pull
request. But I personally don't want to maintain config options and
backwards compatibility outside of what goes on in a minor branch.

So, to address Christian's concern in more specific detail:

* I intend that major revisions are break points, and that when we
push out a new major revision, ath9k_htc (or whatever it becomes) will
eventually update to use that;
* .. then we can do things that break backwards compatibility, which
means we can kill all those capability checks if we need to;
* For things that occur during a given major release branch, we can
either use a capability bitmap OR we can do it via versioning -
because I don't want to see ath9k_htc try to support >1 major version;
* How we do that check isn't really that big a deal - as long as the
checks look like:

if (feature_xxx(sc)) {
}

.. we can easily just change feature_xxx() to be a bitmap check or a
version check.

* And then once we push out a new major release, we can reap features
that are either on by default in the new major release.

How's that sound?

Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/