Re: [Ksummit-discuss] [CORE TOPIC] [nomination] Move Fast and Oops Things

[Theodore Ts'o <tytso@mit.edu>]

On Thu, May 22, 2014 at 09:31:44AM -0700, Dan Williams wrote:
> Neil already disabused me of the idea that a "gatekeeper" could be
> used to beneficial effect in the core kernel, and I can see it's
> equally difficult to use this in filesystems that need to be careful
> of ABI changes.  However, nothing presented so far has swayed me from
> my top of mind concern which is the ability to ship pre-production
> driver features in the upstream kernel. I'm thinking of it as
> "-staging for otherwise established drivers".

In the case where you are just adding some additional hardware
enablement for some newer version of some chipset, I can see the
applicability.  But if the new feature also requires new core code
functionality (for example some smarter way of handling interrupt
mitigation or interrupt steering, for example), the "gatekeeper"
approach can also get problematic, for the reasons Neil outlined.

For example, I can remember lots of serial driver enhancements that
required core tty layer changes in order to be effective.  (In fact I
had a friendly competition with the FreeBSD tty maintainer many years
ago, but one of the reasons why I was able to get significantly better
improvements with Linux was because the FreeBSD core team back then
viewed the architecture from BSD 4.3 to be handed down from the
mountain top as if from Moses....)

So this is why I'm wondering how commonly applicable this particular
technique might be, and if it's restricted to individual driver code,
is there any thing special we really need to do to encourage this.
After all, device drivers authors could use a sysfs file to do this
sort of thing today, right?

					- Ted