The NOVA filesystem

Posted Aug 7, 2017 16:13 UTC (Mon) by sasha (guest, #16070)
Parent article: The NOVA filesystem

"Academic work has a discouraging tendency to stop when the papers are published and the grant money runs out"

As BFQ I/O scheduler (2008: https://lkml.org/lkml/2008/4/1/234 2014: https://lwn.net/Articles/600366/ 2016: https://lwn.net/Articles/709202/) shows, academic work has a discouraging tendency to be ignored by kernel community for years, because there is no "BIG CORP" behind it. Google or Facebook can say "we already use this patch, please accept it" and kernel community accepts even imperfect patch. It is not so easy for patches from academic community; at least it was not so easy for Paolo Valente.

The NOVA filesystem

Posted Aug 7, 2017 17:12 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

It takes ongoing work to get something merged into the kernel, and that work falls outside the scope of typical academic funding/manpower. Meanwhile, Google/Facebook/etc employs full-time kernel folks, and getting stuff mainlined is part of their job description.

So it's less about $BIGCORP and more to do with the realities of academia being somewhat different from the real world. (Or at least the realities of the kernel development process..)

The NOVA filesystem

Posted Aug 8, 2017 2:36 UTC (Tue) by smckay (guest, #103253) [Link] (2 responses)

I'm very much an outsider, but it definitely does seem like contributions from large companies have an easier time getting merged. I'm sure a lot of it is down to having people experienced with kernel development getting paid to do the work, but I think justifying the change is easier too. Like, is this patch worth the effort? Will it be used? If it's already running on umpty-million Android handsets or a jillion cloud servers or a thousand enterprise customers are slavering to buy the hardware that goes with this driver, the usefulness is already there. Whereas something coming out of academia, probably not production quality yet, without a significant installed base, is going to be harder to justify.

The NOVA filesystem

Posted Aug 9, 2017 17:03 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

Not sure about big companies having an easier time due to it being easier to justify changes.

I think the justification is far more linked to the technical merits, maintenance load and the impact on the kernel than the number of devices using it.

For example the android "wake lock" stuff took years before being merged (and it wasn't merged "as is" but in a significantly modified form).

There are drivers for very niche devices, driver submissions are accepted, even from "unknown" individuals, provided they respect the license and coding style rules and pass review. I've never seen any questions about how many of the devices are out there for it to be "worth the effort"...
For this reason, contrary to popular belief, Linux actually supports *more* devices than Windows (particularly true for older devices).

Getting non trivial code into the core kernel though, is significantly more difficult since the potential for breakage is much higher.

But yes, corporate developpers do have the advantage of having more time, by virtue of being paid to work on the kernel, and often in house peer review before anything even gets submitted to the public mailing lists.

The NOVA filesystem/Patches from large companies

Posted Sep 7, 2017 19:22 UTC (Thu) by vomlehn (guest, #45588) [Link]

The biggest reasons why contributions from large companies have an easier time getting merged is that they tend to approach the kernel community with complete implementations that have been run for months on a large number of systems, and they often have benchmarks to show performance, memory, etc. improvements over a range of configurations. Compare that with someone who has a notion that they've tested a few times and seems to work for them.

Additionally, large companies tend to have the resources to hire people and keep them working on the kernel. This allows a level of familiarity and comfort with their work to grow. This is very useful when evaluating the likelihood that someone's work is correct, though the same factors risk a sense of complacency.

Note that that large companies do not always get it right. For example, multiple features Google created were too narrowly focused on Android and did not work as the larger community would have wished. It's taken years to remedy the ones that could be remedied. A large part of this was a failure to openly and frequently engage with the kernel community up front.

I would, however, hope that nobody is discouraged if they don't work for a large company. Those companies, economic powerhouses though they may be, tend towards group think and hold no monopolies on creativity. It's a lot of work to get something into the kernel but it still remains well within the abilities of lone developers.