Linked by Thom Holwerda on Thu 1st Feb 2007 14:41 UTC, submitted by Oliver
FreeBSD "Linux has a large amount of device drivers for hardware not supported on FreeBSD, especially USB devices. Not rarely, such drivers have been written based on information derived by protocol sniffing, reverse engineering and the like. This makes the code highly undocumented, and renders the porting effort extremely error prone. To help with this task, I decided to start working on an emulation layer that would let us recompile the linux source code on FreeBSD, and provide a sufficiently complete emulation of the kernel APIs so that device drivers (or at least certain classes) could be used without modifications to their source code."
Thread beginning with comment 208166
To read all comments associated with this story, please click here.
Back on Topic
by GinoRotormind on Thu 1st Feb 2007 23:03 UTC
Member since:

I am just curious as to everybodies opinion on whether or not this is actually a good thing. As history tells us emulating other operating system (subcomponents even) tends to reduce the number of native ports. Given that these linux drivers are full of magic numbers etc and the aformentioned constantly volatile linux driver api, how do FreeBSD plan to support these devices should this be merged in FreeBSD 7? Are users on their own? I am all for supporting more devices but wouldn't it be better to take on the more difficult task of writing native drivers that remove the magic numbers etc so that it is properly documented? Doing so benefits the whole community including linux.

Reply Score: 3

RE: Back on Topic
by Morin on Thu 1st Feb 2007 23:18 in reply to "Back on Topic"
Morin Member since:

Finally, somebody is back on-topic ;)

As for the magic numbers, many of them have no proper documentation and have a very device-specific meaning. Documenting them is not really a problem of porting the driver, but writing a clean driver in the first place. This would help Linux as much as it would help FreeBSD, but it's going to be a tough job. And it's a particularly uninteresting job if the device is a hardly-known and old one from a hardly-known company that already went out of business.

As for the porting itself, I think its a really bad idea. You can only emulate the OS/driver API properly if there is such an API in the first place. This isn't the case with Linux. I have actually written a kernel module once and I have to classify the kernel as "unstructured spaghetti code" - there simply aren't properly defined interfaces between the different parts.

If you want to emulate that mess in FreeBSD, you have to port half the kernel just to make sure every little bit behaves as intended. If you don't, you'll get headaches again and again for every single driver to be ported. I don't know if FreeBSD has similar code structuring problems, but if it does, a FreeBSD kernel with Linux emulation is going to be an unmaintainable mess that will never work.

Reply Parent Score: 3

RE: Back on Topic
by Vanders on Fri 2nd Feb 2007 08:03 in reply to "Back on Topic"
Vanders Member since:

This looks similiar to the sort of thing we do on Syllable. Providing an API that is "close enough" to Linux has worked very well for us, at least. We can port things like ethernet and USB drivers very quickly, with the minimum amount of changes and maintain similiar levels of hardware compatability as the original driver.

Tracking the ever-changing Linux API hasn't been too bad. It helps if you're only dealing with a limited number of driver classes, because that obviously limits the size of the APIs you need to concern yourself with. The fundemental APIs (E.g. Stuff like kmalloc()) are very stable, so there are generally no problems there.

Reply Parent Score: 2