Intel Striving To Overhaul Their Multiple Ethernet Linux Drivers: "The Great Code Dedup"

[gotar]

What a funny joke with all this "lovelie"!
[newline required, otherwise 403] I'm just amazed!

But if I mind asking a question: are there any grown ups there? Maybe it's just about time to start fixing your bugs (i.e. working around hardware issues) instead of removing entire bug tracker (e1000.sf)?

[mb_q]

I don't think closed source has anything to do with it. Almost all the software I write is closed source, but I've never seen anyone duplicating things just for kicks. Haven't written device drivers though, maybe that's a different world. Though it still seems unlikely, there would roughly the same engineers working on them, because device drivers require more domain knowledge than most other pieces of software.

It's not for kicks; the mechanism is probably like this: we have a driver for A, but now we need to support B, which is similar, but not quite; we can either make a more complex AB driver and risk breaking A or just copy A driver and adapt it to support B -- less risk, less complexity. In the OSS world people would (in theory) complain about the aesthetics and long-term consequences of this decision, but business is about local minima. The optics obviously change when there is so many live copies that they become a maintenance problem, or when a lack of common abstraction hinders the speed of enabling yet another device in the series.

[gotar]

we can either make a more complex AB driver and risk breaking A or just copy A driver and adapt it to support B -- less risk, less complexity.

It's even simpler - until you finish the driver for B, you have no idea what changes to the common code would be required (including refactoring, new options etc.) and which parts would actually stay common.
So it's just easier to copy the entire codebase, freely mess with it and only after dust settles down merge the final product back to the master tree.

The point is - with commercial software this last step can be simply ruled out, as justified by "cutting costs, delivering fast".
So it has nothing to do with the code being closed or open, but the need for "ready to market" or "not accepting code in this state for our project".

[NotMine999]

Exactly

1. Make it work
2. Make it right
3. Make it fast

You are quite probably "spot on" in your observation.

So why develop that way?

When developing a driver for a new bit of kit sometimes you don't want to mess with a stew that already tastes good; you don't want to screw up something that already works.

[NotMine999]

No love for igb?

Agreed. If you don't show it any love there is a risk that Fedora might drop it.

[F.Ultra]

I don't think closed source has anything to do with it. Almost all the software I write is closed source, but I've never seen anyone duplicating things just for kicks. Haven't written device drivers though, maybe that's a different world. Though it still seems unlikely, there would roughly the same engineers working on them, because device drivers require more domain knowledge than most other pieces of software.

Well that is my experience from working in a lot of places over the last 30+ years, was only in the open source world where I saw people actually caring about long term maintenance, in the closed world it was basically seen as "now is product A done, lets create product B from scratch so we can demand more development hours from the customer" and also so that in case the changes to B was great then you could get back and squeeze out more money from the customers of A if you could add those changes there as well but unless you could no one bothered.

[chithanh]

There's been an ongoing effort to overhaul their Ethernet driver management to reduce code duplication between the different drivers for better code sharing and with an end goal of more unification...

Interesting. I wonder whether there has been a change in policy, or whether the Ethernet team is governed by different rules than the graphics team in this regard. For instance there is extensive code duplication between i915 and gma500 drivers and it is intentionally so.

How they got there is quite easy, common closed source proprietary way of working where you see each and every driver as a completely new project starting from scratch with a separate team.

No. We have so much code duplication precisely because the proprietary approach is they don't start from scratch. Instead for new hardware they branch off the existing driver code. The branch for the old hardware goes into maintenance mode basically (to avoid regressions), and the branch for the new hardware sees the development work.

[mdedetrich]

I don't think closed source has anything to do with it. Almost all the software I write is closed source, but I've never seen anyone duplicating things just for kicks. Haven't written device drivers though, maybe that's a different world. Though it still seems unlikely, there would roughly the same engineers working on them, because device drivers require more domain knowledge than most other pieces of software.

I agree, I don't think this is an open vs closed source issue but rather one that reflects organizational structure in a company (i.e. disparate teams working on different drivers can create this result).

[F.Ultra]

Interesting. I wonder whether there has been a change in policy, or whether the Ethernet team is governed by different rules than the graphics team in this regard. For instance there is extensive code duplication between i915 and gma500 drivers and it is intentionally so.

No. We have so much code duplication precisely because the proprietary approach is they don't start from scratch. Instead for new hardware they branch off the existing driver code. The branch for the old hardware goes into maintenance mode basically (to avoid regressions), and the branch for the new hardware sees the development work.

poor choice of words from my side, the above is basically what I meant, aka that they see each end product as separate branches, from scratch can include "copy stuff from old code"