OSDev.org

Hello everyone. We would usually implement some device driver into our OS by either looking at a couple of boring manuals and experimenting, or by finding a tutorial, or by using someone else's code.
Unfortunately, manuals are limited to only some types of hardware, and in general usually manuals don't have too much information for OS development.
Unfortunately, tutorials are usually only available for "beginner" devices.. usually they are standard devices - keyboard, text/VGA monitor, mouse, floppy...
Last but definitely not least, use someone else's code:
Great when you can actually find it and use it... But how to find it? People from the Linux/BSD world usually note that most of their stuff is open source. Well, for example, if I want to look at the source code of the BCM4312 wireless network driver, where exactly do I look?

Thank you,
Veniamin

Well, one solution is to use a driver interface similar to UDI (Uniform Driver Interface) or EDI (Extensible Driver Interface). This is actually their very purpose.

Download http://www.kernel.org/pub/linux/kernel/ ... .28.tar.gz and you'll have all the source of linux kernel (including drivers).

I know, Love4Boobies,

People from the Linux/BSD world usually note that most of their stuff is open source. Well, for example, if I want to look at the source code of the BCM4312 wireless network driver, where exactly do I look?

I answered what he asked.

The b43 drivers (bcm43xx in mainline kernels, b43 and b43legacy in wireless-2.6 and 2.6.24 and later) are drivers for the 802.11 B/G family of wireless chips Broadcom produces. The choice of which driver your card uses depends on the revision level of the 802.11 core. This number is read by driver ssb, and the correct choice for your device is made at that point. Note: If your card is a BCM4306 Rev 2, or only has 802.11b capability, it uses b43legacy. All other models use b43.

You can find them in
/linux-2.6.28/drivers/net/wireless/b43

Cheers,
Gonzalo

True, but those are Linux-only drivers. UDI and EDI are meant to be OS-independent.

Thank you gzaloprgm for your reference. I didn't realize that all of the drivers are actually bundled together in the source with Linux.
Upon closer examination I have figured out that the specific BCM4312 is not correctly supported by the 43xx driver. I have found that people got ways to get around this problem by downloading a "STA" driver port directly from Broadcom:
http://www.broadcom.com/docs/linux_sta/ ... _12.tar.gz
...it has source code. I thought "Wow! They actually released their source code?" ...and I looked through it.... I found that most (if not all) of the code had to do with compatibility with Linux (ie, to make it into a runnable Linux module)... with the actual precious meaty functional part to be "extern"ed to some object file.

Of course, that was just my current understanding of the code. I am not a professional at C or makefile so I might be misinterpreting this thing. (I really don't understand the makefiles even though they look rather small. Assembly is my better suit.)

I will look over the Linux 43xx source. Hopefully I will have more luck there. Once again, thank you for the direct link of the Linux source code along with the exact location of the driver I am looking for.

Veniamin

OT, but I find it really annoying when people completely change their posts

I am sorry, Love4Boobies, to have apparently ignored your post. Indeed I started asking for alternatives to getting devices to work. Unfortunately I do not see much information about these UDI and EDI on google. Actually, on Wikipedia I see that UDI is noted as "disfunct" ... Is there a large collection of these drivers? Once again, I refer to the BCM4312 wireless network driver as a prominent example.

Veniamin

Indeed UDI and EDI are excellent concepts, but woefully short on actually available drivers.

Using Linux drivers, on the other hand, has a severe drawback. The Linux kernel maintainers explicitly reserve the right to change the kernel - driver interface whenever, and however they see fit. (See /usr/src/linux/Documentation/stable_api_nonsense.txt.)

Any OS utilizing the Linux drivers would have to copy the Linux driver interface, and keep changing it if it wants to benefit from fixed and new drivers. Additionally, as the driver code is GPL'ed, this would require your kernel to be GPL'ed too, which might not be what you want...

I am not sure about the state of affairs regarding the *BSDs (OpenBSD, FreeBSD, NetBSD), but perhaps they can provide what you're looking for.

I did not know about the documentation directory... I am now going through it. Thanks for the pointer Solar!

CPLH wrote: Upon closer examination I have figured out that the specific BCM4312 is not correctly supported by the 43xx driver. I have found that people got ways to get around this problem by downloading a "STA" driver port directly from Broadcom:
http://www.broadcom.com/docs/linux_sta/ ... _12.tar.gz
...it has source code. I thought "Wow! They actually released their source code?" ...and I looked through it.... I found that most (if not all) of the code had to do with compatibility with Linux (ie, to make it into a runnable Linux module)... with the actual precious meaty functional part to be "extern"ed to some object file.

Of course, that was just my current understanding of the code. I am not a professional at C or makefile so I might be misinterpreting this thing. (I really don't understand the makefiles even though they look rather small. Assembly is my better suit.)

Nope, you've pretty well nailed it. The available code that Broadcom has thrown out there is GPL'd, and is their linux compatibility code. All the brains for everything are found in the object files they distribute. That's commonly referred to as the 'binary blob'. Last I looked, the object files did have full debugging symbols and all of that, however it won't do you all that much good, the symbol names are all obscured.

Anyway, by studying the linux compatibility layer code Broadcom provides, you should be able to write interface code for your own OS.

You could also, if you were insane, try a simple implementation of the Windows driver API. I'd just start by getting something working, then worry about bug-compatibility way down the line when you encounter a driver that needs it. Then you'd have drivers for all kinds of stuff!

Then again, it'll probably be a PITA to get it to the point where it'll run a simple driver correctly.

You could also, if you were insane, try a simple implementation of the Windows driver API.

http://en.wikipedia.org/wiki/NdisWrapper

You could also look at the source to KolibriOS, has that as many asm driver in it.
http://www.kolibrios.org/?p=Download

Craze Frog wrote:

You could also, if you were insane, try a simple implementation of the Windows driver API.

http://en.wikipedia.org/wiki/NdisWrapper

NDISWrapper only works for network devices unfortunately. What would be really useful (and easier than implementing the WDM) is an implementation of WDF, which AFAIK is the API that all Vista drivers use and is much simpler and more effective than WDM.