Slashdot Mirror
Free/Open Source Software Hardware Requirements?
Bender asks: "Most on Slashdot seem to be concerned with getting Free/Open Source software to be compatible with hardware (firmware, register sets, etc). My question is from the other side of the table: I'm in the hardware business and I'm wondering if there are any central guidelines to better guarantee compatibility with Linux/*BSD. As an example, to guarantee that our hardware runs Microsoft Windows, we have to conform to the Windows Logo Program Requirements. These requirements dictate (among other things) firmware interfaces, debug ports, and DRM. Some of these requirements, if not implemented carefully, could trigger incompatibilities with non-Microsoft operating systems. Is there a Linux/*BSD equivalent to the Microsoft requirements to allow hardware designers to build OS agnostic systems?"
Well documented, unencumbered interfaces would be a nice start.
My ininformed, off-the-cuff answer would be:
Complete and freely available documentation.
If your product is really wanted, people will adapt (look at how hard people try to do this with things like reverse-engineered open-source drivers). If you freely provided complete documentation on your hardware, it would make it several orders of magnitude easier for developers to write software for your hardware.
The real key is to make documentation available to OS developers, preferably without an NDA. Pretty much everything else can be worked around--a lot of the main OS developers are pretty bright.
One other thing to consider is that there is a lot of 64-bit hardware running on free OSs. It's nice when PCI devices can DMA to the full address space.
I always felt the term "Windows compatible hardware" was a big piece of bullshit. Shouldn't it be the software to conform to the hardware, and not the other way round? Hardware seems to be the lowest common denominator here.
Of course (as some posts already mentioned), this can only be achieved if the hardware in question is properly documented so that developers know how to write drivers for it, without having to resort to dirty (and sometimes illegal) tricks like reverse engineering.
Score: i, Imaginary
So the *nix crowd has always been followers.
If the harware guys want to play OS here's the game plan:
1. exactly follow existing spes (where posable)
2. clearly and loudly publish interface details
3. release *Linux drivers with the hardware
[#3 is cheaper than you think!]
...then people will correct you if it's wrong. If you release open source drivers to the community and do it in a fashion which inspires feedback (mailing lists, forums, Sourceforge) and people find fault (bugs, standards compliance, bad code style) it can and likely will be fixed.
If you are prepared to put paid developers at the whim of the community then you are already on the right track to wide acceptance. You have to realize it isn't your baby anymore and if you've just released a horrible monster it will get tamed and put into other projects that have nothing to do with you.
Going open source is easy - anyone will tell you what is good and bad to do. Closed source, proprietary software tends to lean towards groupthink and suddenly a bad project is worse. There is no reason to keep discussions and ideas behind closed doors in the open source world so you can benefit from wider feedback.
In a year you'll be discussing you're release on Slashdot, and we'll be saying *BSD is dying. But that will be some of the best marketing and market research you can do, and it will all pay off.
I'm in a weird mood..
Get your Unix fortune now!
If you release complete documentation of said hardware ...
True. The trend seems to be that many F/OSS projects prefer to develop the drivers themselves (as it assures them a known level quality from reliable developers). That is not to say they don't trust the developers in many hardware companies. But let's face it, a EE sometimes makes a crappy programmer (and I have pleny of EE-wielding friends that work for hardware companies and end up getting pressed into service writing drivers for hardware when they would rather be designing the next batch of hardware).
Failing that, as long as the F/OSS people can QA the stuff and suggest modifications it will eventually make it in. This can be seen in the all the back-and-forth between the Linux kernel developers and SGI over getting support for XFS into the kernel, which ultimately resulted the XFS patches getting accepted into Linus' tree.
Publicly document the hardware interface. That's all that's need, really. As a programmer and electrical engineer all I need is a decent spec sheet for a piece of hardware to construct an interface to a linux system.
Remember that documenting your interface does not mean revealing the secrets of what's going on under the hood! What do the signal lines do? What commands are accepted? What are the timing characteristics? What format of text/image/video flows along the lines? etc
If you write your own drivers for Linux and one of the BSDs and release them under the GPL and BSDL with the complete documentation. From that point on the community can take care of maintaining and porting them if you don't (it's better if you do).
It's not enough to release your own closed-source driver for one architecture (like nvidia and ati do) because this locks out people on other architectures and later kernel versions.
BS!
Way to sidestep the question. It sounds as if the original author wants his system to just drop in and work. You suggesting that he document and let others fix a problem that shouldn't have occured in the first place.
One should not theorize before one has data. -Sherlock Holmes-
My guess this guy is working as a systems integrator. AKA he is building boxs.
I think he wants to know how to select parts that will work with Linux and BSD not how to build parts that will work with them.
If so it is a very good question. How would a hardware integrator know what Video, SATA card, Raid controllers, and motherboards to use?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.