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?"
If you release complete documentation of said hardware ...
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.
... send a free piece of the hardware to every major kernel-programmer.
If you mod this up, your slashdot background will turn into a beautiful sunset!
Microsoft requirements (to their legacy code and operating system) are what really holds the PC back. Has there been any decent effort to break this mold?
A feeling of having made the same mistake before: Deja Foobar
Why not ask someone who doesnt know?
After all, this seems like there will be a 'right' answer to this question, and where's the fun in that?
Conform to freely available published standards. If you have good reason to produce proprietary hardware, publish the programming interface in sufficient detail for people to make a clean-room implementation of drivers. And don't worry -- free drivers will follow.
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.
You can use the distributions like RedHat, Mandrake, Debian to test the devices and put the specified support in kernel. Or better, why not send the hardware to one group of kernel developers.
http://www.michel.eti.br
The obvious solution is the Open Hardware Certification at http://www.open-hardware.org/
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
You said:
From the "MS Logo" link:
So is it really a question of ensuring that your hardware "works", or is it a marketing issue in which you need to show the colourful Windows flag on your product's packagaing?
I'll admit that I didn't devle too deep into that MS document, though, so it may encompass far more than the logo, despite what the title suggests.
maybe GNU could launch a documentation database with docs from the manufacturers.
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!
THANK YOU!!! I wish more hardware manufacturers thought like you!
<Microsoft>Thats not a bug its a feature</Microsoft>
Insightful, this? People, the o.p. asked a sensible question which shows they are serious about adding support for Linux, and all you can poke out of your ass is a dig at Microsoft. If you can't help, then leave alone!
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
Make all registers readable! Write-only registers are a pain in the #$@#$%^!
Like the beaver, it's just Dam one thing after another
POSIX.1 ... nuff said.
As for hardware specs... on an i386 class box [which includes pretty much everything even the x86_64] the PCI bus is accessible through MMIO and I/O ports.
This doesn't change just because you're in BSD or Linux.
Sure the actual code may change due to the organization of the respective kernels but the hardware manual which explains how the device works is applicable to both.
The biggest problem with most hardware is
1. Undocummented hardware
2. "pointless revisions" [*]
[*] A typical ploy is to change the mapping on a wifi card so that version X-1 drivers don't work. It's not that the developer actually fix things or improve it otherwise just to make sure the OSS crowd is always at least one step behind.
Tom
Someday, I'll have a real sig.
Likewise, you can not design "for F/OSS" because F/OSS is a means. Linux and the like may be most associated with F/OSS, so you might legitimately ask "how to I do hardware so that it is compatible with most linux distributions", but NOT (generally) with F/OSS. Consider the (unlikely) case where MS open source'd XP source code today - there you have it .. F/OSS software, and you see that your question loses its correctness.
And now for the part that will receive real flames from the unthoughtful: F/OSS came of age with linux. But, likewise, the fundamentally good idea is handicapped by its association with it. F/OSS is too important an idea and reality to be associated with a unix clone with generally poor usability (despite its stability) and the blindered hobbyists who dance around it.
Maybe, but considering that Linux and friends have been accelerating in marketshare growth and visibility, the compatibility issues will become a greater priority for the OEMs and it will be the companies' employees who will take care of what would otherwise have been the dirty hippies' project. Just another instance of supply catching up with demand.
First of all, provide documentation and an engineering contact to answer questions about the documentation. Keep in mind that you will get asked questions from sources other than those related to the core Linux development team - the *BSD teams may have questions for you, some hobbiest may ask questions - answer them all. Incorporate the answers to their questions into your documentation, etc.
If you are doing anything that is truly groundbreaking, for your company, but has been done in other places, at other times, the experienced OS developers in the free software community can sometimes provide invaluable feedback on what is wrong with your design.
For example, as I understand it, the AMD64 architecture did not have an IOMMU until rather late. The Linux developers working with AMD on providing support for this architecture pointed out that it was useful and a huge performance win to have one, so AMD reworked that into the architecture. That kind of feedback is invaluable, and something a company like MicroSoft simply can't give, because they lack the necessary cross-platform experience to care. I believe the major Linux distributors are open to consulting arrangements of this type - approach them and ask them for assistance!
If the hardware you have needs firmware to be loaded into it, consider what license the firmware is distributed under, and how that interacts with the licenses of the free software you are trying to work with. At the very least, make sure other people can redistribute the firmware, unmodified, so the users are not dependent on a download from your site.
So, document the hardware interfaces. Answer questions on the hardware, and involve those more knowledgeable than your company early and often to give a better design.
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.
Intel is trying to release Linux drivers at the same they release hardware. They are also trying to create a hardware copatability matrix. If you are a system builder or VAR this would be very helpfull. Some background:n ux/2100-7344_3-5465225.html?tag=nefd.top/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://techrepublic.com.com/5100-22_11-5465929.htm l?part=rss&tag=feed&subj=tr/
http/news.com.com/Intel+more+active+in+desktop+Li
I suppose that's why FreeBSD has been explicitly offering Linux binary compatibility for years, because no one wants it.
Hmm.
I have to say that don't even think about some proprietary binary no matter how wrapped and supported it was by distributions.
Diversity does not "hold open source back." It only does so in the minds (and I use the term "mind" rather loosely, here) of chimps like yourself, who've been brought up on Microsoft's "Eine Reich, Eine Volk, Eine OS," rhetoric. The thing that makes this worse, however is the fact that people don't advocate a monoculture because it's in any way a good thing...it most certainly isn't. They advocate it purely because they've been brainwashed by Microsoft to do so.
If diversity holds open source back in any manner, it does so only because those who desire a monoculture desire one precisely for the reason that a monoculture allows them to avoid having to think...which as we all know, is the one thing most human beings will do virtually anything in order to avoid having to do. A monoculture means that people who actually deliberately and consciously desire to be stupid lemmings are empowered to do so. If there's only one choice, you don't need to put any thought into making said choice. It is only those people that either have an active desire to avoid using their brains, or a fear of personal responsibility, who do not want choice. Unfortunately, I'm aware that that constitutes 98%-99% of the human population. You yourself however have a choice as to whether you also wish to be a lemming, and join the others in their journey over the cliff, or whether you choose to be self-determining. It's a case of the eternal red pill vs blue pill question again.
My answer to this hardware developer would be that Linux (or not just Linux - operating systems in general) primarily needs peripherals which talk to the rest of the hardware in a relatively straightfoward and sane way...unlike winmodems as probably the best example which slave off the CPU, and do so in an undiscoverable and intentionally proprietary/closed manner. Hardware shouldn't be designed to keep secrets...its purpose and means of performing its tasks should be as easily visible as possible. The more people who can figure out how the hardware works, or at the very least how to relatively easily adapt it for their particular operating system, the wider the potential adoption of said hardware will be, and the more unit sales and money you as a hardware developer will make.
How is saying "no DRM" a poke at Microsoft? It's also a poke at Intel, DMCA, MPAA, RIAA, BSA, w/e. Sheesh. Aren't we defensive today.
- Slaving off to software what should be done in hardware, unless you're planning on going cross-platform with the software support. Think WinModems here.
- Closed. Binary. Firmware. There's a whole bunch of wireless hardware that it'll be years before anyone can use under Linux, if they even bother, for precisely this reason, and it bugs the hell out of me.
So, yeah - if you're going open, go all the way.This is a wonderful suggestion which is why every nerd and geek who furiously insists on porting Linux to a parking meter he stole at the last Trekkie convention will object to it.
The original poster is quite serious. It *is* a pain in the butt to have write-only registers. This is very common.
What this means is that you write some control values to the registers, which causes the hardware to do something.
If you later wish to use those values, you can't just read them back from the registers. You have to have "shadow" registers which cache the last value written to the real hardware registers.
-- Andyvan
Your company almost certainly doesn't want to provide support for the driver itself (for each of the OS's, etc) - but just putting out the reference driver with the conditions that it works (i.e. "this was only tested on the 2.0 kernel running Caldera Linux") can help people with the clues they need
Hey Bender,
I've gone around this block a few times and I have a few comments that you might find useful.
First off, you didn't say what is your market space. Are you shooting for home, office, workstation or server? I think you'll probably find it easiest to be compatible in the office desktop or server spaces where the configurations are quite generic and not apt to be modified by the end user. Secondly, you didn't say what you did. Are you a full system designer, motherboard designer or configurator? Are you looking to design components that are *nix compatible or are you looking to put together off the shelf components into a system that is *nix compatible? How you answer these questions will affect how you approach the problem.
If I were in your position, I would suggest that you look at the "PC/99" Specification put out by Microsoft/Intel and see what you can do to be compatible with this specification instead of the more Windows (and DRM) specific later specifications and try to get/design hardware that meets this specification; it should be very *nix compatible although it will not encompass the latest audio and video specifications (which is why I suggested office desktop and (preferably 1U) server products.
The problem with this approach will be specifying chipsets that can handle the latest processors and memory. You should be able to mix and match to end up with a motherboard that will run the latest processors with the most appropriate memory and access EIDE and SCSI storage and should be very *nix friendly.
Good luck and let us know how you make out,
myke
Mimetics Inc. Twitter
Personally, I *want* Linux to be able to used the good parts of Trusted Computing (palladium).
DRM is a technology - not unlike encryption - that has it's uses and places in the Linux world. Surely you wouldn't claim that Linux would be better off without SSL support. Some uses of DRM technology are a valuable and logical extention to help improve secure commerce. I want Linux to have a place in those solutions.
First of all, I must commend you and your company for caring about these things - it's definitely nice to see that there are companies who actually care about their customers. ^_~ That being said, here are a few things to get you started:
Hope this helps!
quidquid latine dictum sit altum videtur.
As Linus said himself (almost TWO years ago), there is no fundamental incompatibility between DRM and Linux.
quidquid latine dictum sit altum videtur.
In Windoze land, Microsoft publishes a list of requirements, and offers testing services to ensure compliance. You code to these requirements and get the thing tested and validated. Once done, Microsoft awards you the right to put "Windows-certified" on your box, and you can consider your product "done" (modulo bug fixes/patches).
In F/OSS circles, no such certification program exists. There is no list of requirements; there is no explicit testing service. Instead, what there is is the complete kernel source code (so that you can determine precise requirements yourself), hundreds of existing drivers (to get you started writing your own), and hundreds of thousands of users who will beat up on your hardware/driver and liberally shower you with bug reports (of highly variable quality).
This may seem like a recipe for complete disaster but, depending on what you want to do, it's really not. Linux's device driver model is almost pathetically simple compared to the byzantine mess that Windows uses. So getting a driver with basic functionality is a fairly simple affair. Depending on your device, you'll probably be able to leverage off of existing infrastructure to handle bookkeeping details (for example, I2C bus devices already have an API layer that handles reference counts and locking; coding to it is dead-simple).
Conversely, there are some areas of Linux driver land that are still evolving. One of the big areas is power management. There are three major competing power management mechanisms for Linux (APM, ACPI, and the lesser-known DPM). None of them really address all power management needs and, while some sleep/suspend modes sorta kinda work, Linux's solution is far from complete. You'll be working with a moving target.
As other posters have already mentioned, publicly-available, complete hardware documentation (register maps, theory of operation, strapping options, clock diagrams, etc.) is absolutely essential . In case you get bored with your product or, heaven forfend, your company dies, the F/OSS community will be able to take up the slack. They'll also be able to add features or enhance kernel compatibility when and where it's needed. (Some lawyers or senior execs will try to veto a documentation release, citing imaginary fears such as "loss" of proprietary information and trade secrets. You are encouraged to nut-punch these knuckleheads until their opinion is changed.)
F/OSS is not as strictly regimented as the Windows camp, so strictly regimented project planning isn't as easy. There's a lot of chaos out there. This is, on balance, widely regarded as a good thing. You may be surprised at how well your engineers cope in such an environment. (Conversely, it will also help you identify more quickly exactly which features your users actually value.)
Schwab
P.S: If you have the ability, tell Microsoft to take their copy protection ("DRM") requirements and cram them.
Editor, A1-AAA AmeriCaptions
We don't need you to write drivers for us. It would be nice, and we will thank you profusely if you do. But we're not requiring it. All we care about is access to the complete hardware specifications. It's that simple.
Even if you have "proprietary" behavior you need to hide behind some proprietary software, just provide us an object file for that *tiny* portion of code, and we can manage the rest. We might grumble a little bit, but we'll still accept it.
What we don't want is for you to act as if you own the hardware. Don't lock us in to your driver. That's just rude.
Don't blame me, I didn't vote for either of them!
This guy is "in the hardware business".
Meaning, he buys hardware from a distributor, and with a $4 screwdriver, assembles said hardware and pitches it a customer.
I've been there, and done that. Trying to make one that's WINDOWS compatable is a royal pain in the arse, let alone OSS.
When I ran a store, we had a few lines of hardware that seemed to be more or less compatable with each other. We had to continually buy hardware of all kinds and test them to see how they did together.
It was always shocking to me how much of the hardware just didn't pass our testing. Our testing was pretty extensive, and consequently, the hardware lines we stocked were fairly limited.
Also, it was commonplace to have hardware revisions that would change without any notice whatsoever, ruining compatability.
At the time (ending Spring of 2000) one of the *WORST* offenders was Asus. On the other hand, a few relatively unknown brands (DFI and A-trend) scored rather well in our testing, and were cheaper to boot!
My best advice would be to simply test some hardware before you sell it, and see how compatable it is with your favorite distro.
Good luck.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
From the way I understand the question it seems nobody understood what the poster meant.
It seems to me like the guys is looking at some kind of guide to writing drivers for the different *nix flavours. Telling him to write open drivers with open documentation and specs isn't helping him.
As far as Linux is concerned, a good place to start is here. *BSDs probably have a similar way of working: almost all the communication between the kernel/driver developers is done by email on mailing lists. IRC channels are also used.
Many of the free unix flavours (linux/bsd/etc.) share open source drivers; ethernet card drivers is a good example of that. The interface with the kernel may be slightly different across platform but the low-level hardware access remains fairly similar.
My best advice would be to look at existing drivers. They are all open source so you can look at the source code all you want.
Anyway, this is much harder for a small manufacturer to acomplish.
Placing drivers in the Internet Archive and etching the URL on the hardware is the minimium they should do.
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.
Depends on how you look at it. Sure, if you work with the obfuscated code in the normal course of development then that's fine. But developing it "normally" and then obfuscating it for release is technically a violation. The source code is defined as "the preferred form of the work for making modifications to it." If you're releasing anything as "source code" other than what you work with, then that's not the "preferred" form.