Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Dec 2012 22:40:10 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <bright@mu.org>, svn-src-stable-9@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>
Subject:   Re: svn commit: r244663 - stable/9
Message-ID:  <CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org>
References:  <201212241422.qBOEMrcF021632@svn.freebsd.org> <CAJ-VmokV-JL_xZ9otRXubKZ8KQKe7GgLuLU3UMij0HUD_KhCNw@mail.gmail.com> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25 December 2012 11:17, Robert Watson <rwatson@freebsd.org> wrote:

> While I would love to have a stable KBI, or even KPI, for VFS, past
> experience suggests that we are not prepared to document one, let alone
> enforce it, and that we frequently experience changes that disrupt both the
> binary and programming interfaces -- often for very good reasons (e.g.,
> fixing critical bugs, improving performance, etc).  And that the notional
> VFS KPI is extremely promiscuous, being made up of not just the obvious VFS
> parts, but also VM parts, etc.  We've done a bit better with device drivers,
> where the consensus is that we should Try Fairly Hard, but even there we
> have only limited documentation of what even constitutes the KPI and KBI.

> In the end, not all kernel interfaces can be "KPIs" or "KBIs" -- otherwise,
> we could change almost nothing in -STABLE, causing branches to stagnate
> rapidly. If you look at Apple's model (for example), they designate certain
> interfaces as "API" or "KPI" rather than using the terms more casually to
> refer to any interface in userspace or kernel, and we need to take the same
> perspective.  A few years ago, I took a gander through a number of core
> network stack data structures used by device drivers, while trying to help
> resolve how TOE would fit into the network device driver picture, and you
> can see the results here:

There's likely a bunch of companies/users that would love things to
not change during a stable branch and there's likely a bunch of
companies/users that would hate things being immutable during a stable
branch.

There's never been a formal "kernel ABI stuff in stable shouldn't
break" or not, but as far as I was aware, the unofficial method was
"discuss on -stable or -arch to see whether it's worth the break, then
break it if needed, or not-break it and add a dirty hack for that
branch" if not.

This is why things like vimage/vnet were so dirty in the backports, if
you remember. Julian and others made a specific attempt _not_ to break
KBI when backporting the feature.

So, regardless of whether we should or shouldn't break things, a more
thorough discussion would've been nice.



Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=oYfzxwEDYnXotx4b8qvnQTr4ofrLRkwkKH5C9GB0sMg>