login
Header Space

 
 

OpenBSD: Software Freedom

August 27, 2007 - 3:27am
Submitted by Jeremy on August 27, 2007 - 3:27am.
OpenBSD news

OpenBSD creator Theo de Raadt highlighted a recent commit to the NetBSD source tree saying, "if anyone had any doubt that our insistence on freedom was important, just read this." The referenced commit message describes an effort to work around issues with a blob that is included with NetBSD, something strongly avoided by the OpenBSD project. The commit message states:

"The Atheros HAL on MIPS uses %s7 as a general purpose register, but the rest of the kernel uses it to store the value of curlwp. Sam won't recompile the HAL for us (fair enough), and we can't modify the HAL to use another register because doing so could put us in breach of the license (v. crappy). So, do a save/set/restore on %s7 in KernIntr() and in the stubs that the HAL uses to call back into the kernel.

"Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files."


From: Theo de Raadt [email blocked]
To:  misc
Subject: Software freedom
Date: Sun, 26 Aug 2007 20:25:29 -0600

If anyone had any doubt that our insistance on freedom was important,
just read this.

http://mail-index.netbsd.org/source-changes/2007/08/24/0027.html

What is even more astounding is the incestious love-in these other
groups have, with their Sam-worship, that prevents them from doing the
obvious and right thing.

I for one, will say that I don't understand it at all.  But hey, it
gives me another reason to mock the cult of Sam (Leffler) and Jason
(Thorpe).

Fun fun fun.


From: [email blocked] To: misc Subject: Re: Software freedom Date: Mon, 27 Aug 2007 09:39:08 -0400 > rest of the kernel uses it to store the value of curlwp. Sam won't > recompile the HAL for us (fair enough), and we can't modify the HAL > to use another register because doing so could put us in breach of > the license (v. crappy). So, do a save/set/restore on %s7 in KernIntr() How hard is it to recompile the HAL that Sam can't be bothered to do it, and more importantly, why should a trivial change to make the software inter operable be a breach of the license? That can't be the owner's intent.
From: Theo de Raadt [email blocked] Subject: Re: Software freedom Date: Mon, 27 Aug 2007 08:37:56 -0600 > > rest of the kernel uses it to store the value of curlwp. Sam won't > > recompile the HAL for us (fair enough), and we can't modify the HAL > > to use another register because doing so could put us in breach of > > the license (v. crappy). So, do a save/set/restore on %s7 in KernIntr() > > How hard is it to recompile the HAL that Sam can't be bothered to do > it, and more importantly, why should a trivial change to make the > software inter operable be a breach of the license? That can't be the > owner's intent. I don't think you should ask our list, but instead go ask Sam directly. He is after all, the owner, since it is not free source code. Free source code depends on a basic principle that you don't need to count on the decisions of others -- whether they be companies or individuals -- because you have all the pieces you need to build, repair, or improve things. But in the case of NetBSD (and FreeBSD) users, for Atheros support, this principle has been badly broken for years. few people in a personality cult have decided that they will permit a piece of one-person-dependent binary software into their source tree, and will screw all their users by doing so. Then along came Reyk, and a few others who helped him, who wrote a completely free replacement for the non-free atheros driver. But did the NetBSD and FreeBSD developers choose to participate and help him? No, in fact they actively work through postings to reduce developer's desire to work with Reyk. A few years ago there were even core developers in those projects passing along a meme that Reyk's code was illegal or immoral in some sense. Shame on them. In that way, the FreeBSD and NetBSD developers stuck to their cult process, with Jason Thorpe (apparently) being the loud voice inside NetBSD core pushing for retaining the Sam Leffler non-free code, and dismissing the proposals from those who would have preferred to see some people in that project at least working with Reyk's free work to improve support. In FreeBSD, various developers have also let their love of Sam stand ahead of their respect for their user's wants and needs. Who does Sam love? Not the principled free source users, but perhaps an NDA with Atheros, and his friends who work there. Now, noone says that Reyk's free driver is 100% complete (and this is mostly because Atheros keeps changing their chips in really strange ways, all undocumented of course). But at least it is free, and others could participate at improving it, through the same reverse engineering and guess work that Reyk has done. On the other side of the coin, the non-free driver is only being pushed by a cult, not one of which codes to improve it, because quite frankly they can't, because they don't have the source. NetBSD and FreeBSD are reducing their community's choice. They don't represent their user community's needs or wants. They have let politics get in the way of choosing the right software. (Another funny thing has happened over the years. Because Sam's Atheros support has been so important to the cult, work on other wireless drivers has been poo-poo'd within the various development groups, and this is a major part of why OpenBSD surged ahead with support for so many other devices. We did not consider one driver the most important, because it was obvious to us that other devices which were documented were more important... right from the start..)
Subject: CVS commit: src/sys From: Andrew Doran [email blocked] List: source-changes Date: 08/24/2007 23:52:11 Module Name: src Committed By: ad Date: Fri Aug 24 23:52:11 UTC 2007 Modified Files: src/sys/arch/mips/mips: genassym.cf mipsX_subr.S src/sys/contrib/dev/ath/netbsd: ah_osdep.c Log Message: The Atheros HAL on MIPS uses %s7 as a general purpose register, but the rest of the kernel uses it to store the value of curlwp. Sam won't recompile the HAL for us (fair enough), and we can't modify the HAL to use another register because doing so could put us in breach of the license (v. crappy). So, do a save/set/restore on %s7 in KernIntr() and in the stubs that the HAL uses to call back into the kernel. To generate a diff of this commit: cvs rdiff -r1.40 -r1.41 src/sys/arch/mips/mips/genassym.cf cvs rdiff -r1.24 -r1.25 src/sys/arch/mips/mips/mipsX_subr.S cvs rdiff -r1.10 -r1.11 src/sys/contrib/dev/ath/netbsd/ah_osdep.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.



Related Links:

Isn't this normal ...

August 27, 2007 - 6:52am
Anonymous (not verified)

The kernel core should always be altered to accomodate random use of registers by proprietary binary blobs? It makes the development so much more exciting! And just to keep things more interesting, the next version of the Atheros HAL will use yet another register which is known to be used by the kernel. After all, every bad programmer should know that drivers should dictate the structure of the kernel. The proprietors have the upper hand too - they can see all the *BSD code and decide which register to foul next...

userspace

August 27, 2007 - 11:22am
TEf (not verified)

And if they do that enough, eating up more registers with each release, won't they eventually end up with what is effectively a userspace driver (since more state will have to be saved/restored when switching to the driver's code).

I'd think the bigger problem with this is that you'd end up with two different kinds of context-switching, the normal one and the one specifically for drivers. Do you start getting into a microkernel design then?

It's not in core kernel

August 28, 2007 - 11:55am
Anonymous (not verified)

It's not in core kernel code.

It's in the open source/ operating system specific part of the Atheros driver.

Hacks like this are necessary in almost any driver that uses a binary blob.

The impact on the OS itself is still negligible.

Open source device drivers

August 27, 2007 - 8:56am
Fred Flinta (not verified)

We must have fully-documented open source device drivers!

And we must have publically-available published technical specifications of hardware and registers.

And you must be new to this

August 27, 2007 - 9:35am
Anonymous (not verified)

And you must be new to this party.

Who cares if he is new or

August 28, 2007 - 6:46pm
Anonymous (not verified)

Who cares if he is new or not - he is right.

And you must work for Broadcom or nVidious

August 28, 2007 - 9:59pm
Anonymous (not verified)

Crap like this is why I stick to hardware that has either open specs (preferable) or at least truly F/OSS drivers (e. g. Intel video).

I just purchased (like, 20 minutes ago) an LSI MegaRAID SATA controller. The reason is that the specs are published, and it's thus well supported by both OpenBSD and Linux. I could've bought a 3ware, but they're too damned blobby with their mgmt. tools. To hell with that! I voted with my dollars.

If you want to stick with closed blob-ware, go back to your Windows or Mac OS X box.

Hmm...maybe you work for Microsoft? Tell the Chair Thrower (TM) (C) (R) (SM) (Patent Pending) we said hi. :-D

Wifi on MIPS?!

August 27, 2007 - 1:59pm
Anonymous (not verified)

If there was a stable widely followed standard for which registers can be used for general purpose, this would be no problem.

Wifi on MIPS.. must be for routers.

Or the MIPS workstations

August 27, 2007 - 2:36pm
Anonymous (not verified)

Or the MIPS workstations that are reasonably easy to pick up, dumbass.

Don't workstations usually

August 27, 2007 - 6:15pm

Don't workstations usually have wired ethernet?

--
Program Intellivision and play Space Patrol!

Don't some networks skip

August 27, 2007 - 8:11pm
Anonymous (not verified)

Don't some networks skip huge messes of wires in lew of a bunch of radio waves instead?

Most of those machines are ARM-based....

August 27, 2007 - 11:32pm

...and hardly qualify as workstations. They tend to be quite a bit more portable. :-)

(I'm assuming you refer to the wireless cellphone network.)

Seriously, I hear MIPS CPUs are fairly popular in WiFi routers. I can't imagine someone wiring up an old MIPS based SGI to a semi-recent WiFi card to get on the 'net. I take that back... I can imagine that, and but I can't imagine that being at all widespread.

--
Program Intellivision and play Space Patrol!

it will never happen ...

August 28, 2007 - 12:24am
Anonymous (not verified)

Not only is each operating system different, but for each class/version of CPU that the OS runs on there are different features and different sets of registers, not to mention that the developers may decide to shuffle them around. It is simply not possible to have a 'standard' for what registers are used for general purpose within the kernel. The chief problem here is that the super-secret source code is not being built against a specific kernel+CPU so it's not playing nice with the rest of the system. It is an incredibly stupid situation and one which only arises with proprietary code. Proprietary driver code is simply unmaintainable and the situation only gets worse when the company that owns that code disappears or loses interest in supporting a product (especially older products).

This should be a non-issue.

August 27, 2007 - 3:46pm
Anonymous (not verified)

This should be a non-issue. OpenBSD has an excellent free and open driver that should be easily ported to the other BSDs. Don't give me any BS about the regulatory HAL daemon neededing to be closed source either.

Politics!

August 27, 2007 - 4:57pm
Anonymous (not verified)

Politics!

Chip, meet Theo's shoulder

August 28, 2007 - 5:13am
BigChris (not verified)

This is not a non-issue, nor as someone else claims has it to do with politics. The OpenBSD driver is not as feature complete, nor does it support as many Atheros based devices as Leffler's NDA'ed driver. When the OpenBSD driver is a compelling enough replacement, I'm pretty confident it will be ported to NetBSD and FreeBSD. As for the politics, the only person who still has a chip on his shoulder about the disagreement that resulted in OpenBSD is Theo. If he hadn't been so abusive on the NetBSD mailing lists in the first place he wouldn't have been frozen out by the then core team (most of whom, like Hannum have bugger all to do with NetBSD anymore).

Yes, let's put the cart before the horse

August 28, 2007 - 11:52am
Anonymous (not verified)

and demand that the driver get better before it gets looked at by other developers.

If the net and free folks would pull it in and start working on it, then maybe we'd avoid things like this in the future.

But, hey, what's hijacking the kernel when you get a driver out of it, right?

Why *not* wait for the

August 28, 2007 - 1:00pm
BigChris (not verified)

Why *not* wait for the OpenBSD driver to get better before porting it? I didn't see any OpenBSD folks pitching in to help with SMP support for Net, which once reasonably mature was ported to OpenBSD with no patches submitted back to Net. Neither did I see any patches being fed back to the Free developers when Open developers chose to port softdeps. That's fine, as the BSD license allows all of the projects to be freeloaders, the difference is that only Theo makes a song and dance about people contributing to Open related code - and given how much of a prick Theo is it isn't surprising.

"Why *not* wait for the

August 28, 2007 - 3:12pm
Anonymous (not verified)

"Why *not* wait for the OpenBSD driver to get better before porting it?"

So you don't have to deal with this sort of fix-the-kernel-because-of-driver-bug bullshit again? Just a thought.

But, hey, what's a cogent argument when you can just scream about Theo again?

What do you mean? He makes a

August 28, 2007 - 6:50pm
Anonymous (not verified)

What do you mean? He makes a very valid point about OpenBSD allegedly contributing back to FreeBSD and NetBSD and vice versa (or not).

Theo just loves to dance - it is true. And it is a reason why I will never USE OpenBSD, because of this arrogant attitude of an architect thinking too highly. NetBSD stated it nicely, they dont make a big fuzz, neither positive hype or negative hype. (And FreeBSD really is the best BSD right now IMO as far as usability for "average joe" is concerned.)

Yes, let's throw out any

August 28, 2007 - 7:11pm
Anonymous (not verified)

Yes, let's throw out any changes that have come from OBSD's proactive stance.

...and thinking too highly? Be careful not to aim low, you just might hit the mark.

I guess the grandparent post

August 29, 2007 - 4:56am
Anonymous (not verified)

I guess the grandparent post meant that Theo "thinks too highly of himself", in other words that he's arrogant. If so, then that would be a fair assessment and exactly what got him booted from NetBSD all those years ago. If you don't believe me, go and read the mailing list posts from the debacle which are hosted on Theos own website. However, it's worth noting that he doesn't include the abusive posts he made to the NetBSD lists which lead up to his being shunned.

humpg

August 29, 2007 - 4:13am
veins (not verified)

Oh yeah, I forgot that OpenBSD was using a blob to provide SMP support meanwhile.

"Oh yeah, I forgot that

August 29, 2007 - 4:50am
BigChris (not verified)

"Oh yeah, I forgot that OpenBSD was using a blob to provide SMP support meanwhile."

Nope, the key OpenBSD developers stated that SMP was not a feature they were interested in. Funnily enough, it became a feature they were interested in when support could be ported from NetBSD with relative ease. Now that's fine and all in keeping with the BSD license, but Theo can hardly criticise the technical decisions of other projects when they that just happen to conflict with his own moral judgement.

As for another posters insinuation that the other BSD's owe a lot to OpenBSD on the security front, that's doubtful. Even the OpenBSD team acknowledge that the auditing is not a great way to find bugs - test harnesses, particularly fuzzing tools, are a much better way of finding problems by simulating wildly fluctuating inputs to see what breaks.

No, SMP has never been a big

August 29, 2007 - 5:00am
Anonymous (not verified)

No, SMP has never been a big thing for OpenBSD, instead an OpenBSD developer was hired to port the NetBSD SMP to OpenBSD i386, and he did, and he was given money, and since the work was done, it was commited to CVS. This was all discussed when it happened, a few years ago.

Device Drivers

August 29, 2007 - 8:19pm
Anonymous (not verified)

Has NetBSD written drivers for any newer hardware in recent memory?
Its a two way street.

If features and closed code

August 28, 2007 - 5:29pm
Anonymous (not verified)

If features and closed code are fine, then why even concern yourself with this at all? Just use Windows, OS X, Solaris, or whatever.

I use OpenBSD's ath driver, and it works fine for my uses (thanks Reyk!). For my access point I'm using a different chipset, by a vendor that actually provides full specs without an NDA.

Freedom first, then features! If you need both, then do not do business with the likes of Atheros, because they don't play well with others. If you allow NDAs and BLOBs, then the code will suffer, and it has, and it will again.

And as for politics, OpenBSD code is available no matter what you think of Theo. All of it. For whatever purpose you want it. I know that some OpenBSD devs check what's going on in Net and Free (and Dragonfly). If the converse isn't true then it's a matter of closed eyes, not a matter of availability or willingness of OpenBSD to share.

It's just plain BLOB, fer chrissake

August 28, 2007 - 1:13am
Anonymous (not verified)

If I see one more mention of "binary BLOBs", I'm going to use my Universal USB keyboard, LCD display, and central CPU unit to write an angry electronic email to the Department of Redundancy Department... if I don't run out of RAM memory.

Most folk refer to them as

August 28, 2007 - 1:51am
Anonymous (not verified)

Most folk refer to them as blobs in the, "gooky pile of muck," way, not the acronym. They're blobs that are binary, rather than blobs of disgusting, unmaintainable code.

good work!

September 1, 2007 - 5:57am
lws (not verified)

Thank you very much by the article!
A very good work!
------------------------

http://www.luckywebsoft.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary