3 ms·

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 wit

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.

drewg123 10y ago
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.
- alacombe 10y ago
  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.
toomanythings4 10y ago
I know a few people who have contributed and none of them are rich or famous. Your own personal experience at a small company apparently is not representative of the world at large.
rpgmaker 10y ago
> 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.

drewg123 10y ago

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.

alacombe 10y ago
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.

toomanythings4 10y ago

I know a few people who have contributed and none of them are rich or famous. Your own personal experience at a small company apparently is not representative of the world at large.

rpgmaker 10y ago

> 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.