User: Password:
Subscribe / Log in / New account

A suspend blockers post-mortem

A suspend blockers post-mortem

Posted Jun 6, 2010 22:41 UTC (Sun) by mikov (subscriber, #33179)
Parent article: A suspend blockers post-mortem

One thing that wasn't mentioned in the discussion so far is the financial burden to a smaller development house. Sure, Google can afford to have a few highly paid kernel developers spend months, if not years, just trying to push upstream something which already is working. That would be suicide for a small company.

If I might venture a guess (well, it is more than a guess), small embedded vendors don't seriously consider upstreaming their development. It is simply outside of the realm of financial possibility.

It doesn't help that having a driver upstream can be an additional hassle rather than a benefit. It can actually make it harder to deliver updates to customers. (If your driver is already upstream and you need to deliver an urgent fix, what do you do, especially if your customers are not kernel developers?)

I am not sure there is a better way to handle these problems, but at least they ought to be acknowledged.

(Log in to post comments)

A suspend blockers post-mortem

Posted Jun 7, 2010 17:53 UTC (Mon) by nlucas (subscriber, #33793) [Link]

Was thinking the same thing until I saw your post.

Kernel developers seem to live on a world of multinationals, forgetting most of the economy passes by small and medium companies (specially on small countries, where a medium company is a micro-company on the states).

git FTW

Posted Jun 7, 2010 23:06 UTC (Mon) by dmarti (subscriber, #11625) [Link]

The Coraid web site no longer has Ed Cashin's presentation on this subject -- "Unstable API Sense". He covers how to maintain a driver in git, and release both vendor versions and merge requests to upstream. Of course this is for a "leaf" driver, not a core feature, but the releases to customers problem is manageable.

git FTW

Posted Jun 8, 2010 18:59 UTC (Tue) by mikov (subscriber, #33179) [Link]

I couldn't find this presentation, but from your brief description it seems like it is missing the point. Git has nothing to do with this - as a convenient tool it simplifies just one trivial aspect of it - namely rebasing the sources and storing revisions.

The vendor still has to maintain and test multiple versions, some of which are not under its control (the mainline versions). The procedure for replacing a mainline driver with an updated vendor version at a customer site is a huge PITA. Worse, some customers have the mainline one, some the vendor one, and it is non-trivial to find out which (most people are not kernel experts). You need different procedures for different cases and so on. This makes both support and development more expensive.

In short, for anything that is not a truly mass market product, it turns out it is actually in the vendor's and customers' detriment to have the driver in the mainline.

On a similar note, I have always found the notion that a driver in the mainline is somehow "better maintained" very very strange. Nobody actually tests all the drivers in the kernel before each release. All that is done is making sure they can compile. How can anybody be satisfied with that is beyond me.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds