Hacker News Reader

Comment by drewg123 | Hacker News Reader

Let's just say that the Intel drivers have a pretty checkered history and your experience was not unique. There are new people at Intel working on their drivers, and they are more responsive. Also, iflib is coming, and it will move a lot of the stack-facing driver code from the Intel (and other) drivers to a common location. It is much higher performance and far less buggy than the vendor code it replaces.

The beauty of the BSD license is that you don't have to contribute back if you don't want to. Some companies contribute at lot. For example, the Netflix contribution of async sendfile, CAM support for NVME, etc.

View on HN

My experience is not limited to the e1000(4) driver. The device tree driver subsystem is based on hardware model from the early 90s, the mbuf API is plagued with code duplication. Nobody want to touch this because the old guard is pretty much locking these interface. Everybody praise the Lord PHK, but his actual code in the tree is really sub-standard... The way to change things is to do what Adrian Chadd has been doing, sneaking in, and changing stuff behind's people back.

The way to contribute to BSD is easy, you have to be big to have enough influence (including monetary wise) to get stuff in. When you are a small nobody, you end up being treated as such.

Comparatively, I've had Linus look up at some issue I used to have with Linux USB stack (which were likely local interconnect issue). A world of difference.

edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon. At the end of the day, the dev submit at 10kloc patch that is unrewiewable, and it gets in with rather poor amount of discussion. The only public discussion held is pretty much bikeshedding. There is way more interesting technical conversation happening in a day on the LKML than will happen in a year on FreeBSD ml.

The problem with mbufs is that they have been around and been extended since the 80s. And Rototilling the interface will break a LOT of hardware. One of the nice things about iflib is that abstracts mbufs away from drivers. Of course that doesn't help much with crusty old drivers, but it does help some.

Having worked on both systems, there are some things I like better about mbufs as compared to skbs. But BSD badly needs the skb frags (eg, attached pages) concept to avoid excessive pointer chasing. We've been using an internal (not shared) patch that puts attached pages into an iovec, but it needs a lot of cleanup before upstreaming.

Oddly, I've had just the opposite experience as you. I've always found contributing to FreeBSD much easier. I was the author of network drivers for an IHV (not Intel) at a previous job. FreeBSD was a million times easier to deal with than Linux. I had a commit bit, and just developed my driver in head. Whereas with Linux, submitting even minor patches was a major ordeal thanks to davem and the netdev cabal. The Linux driver was often lacking features as compared to FreeBSD just because getting patches in was so time consuming.

There is actually quite a bit of public discussion of patches in Phabricator these days.

then maybe hardware vendors should contribute their code so that API could be changed all along, instead of keeping it paywalled. Though, I doubt they want people to look at how poor quality they are.

And yes, my job was also to "integrate" custom drivers for our appliances bells and whistles (eg. fail-to-wire interfaces, hardware sensors, etc.), in our source tree.

> edit: while I think about it, most large changes in FreeBSD are discussed in private. Public discussion on patch and technical discussion is frowned upon.

Ugh. That sounds pretty bad for an open source OS.

Reply on news.ycombinator.com