OSDev.org

in case anyone doesn't know.. blob is like a binary driver(like how win-modem drivers are)

now I have been thinking over and over about a way to fix it.. the only way I can think of is emulating some windows syscalls(or whatever) since most drivers don't do advanced stuff such as windows and message queqe's it shouldn't be as hard as reimplementing the whole winapi

but can anyone think of any ideas on how to "compromise" with the blobs?


the only way I can really think of(with my os..) is having a ring0 loader for the blob with the blob in ring3 with some way of having the ring0 loader have complete control over it(paging and all) kindof like a debugger and emulate called interrupts or whatever

btw I'm a bit sleepy so sorry for lacks of comprehensible language

so you're trying to do something like http://ndiswrapper.sourceforge.net/, right?


Oh, you mean Binary blob (didn't know that meaning of the word). Still i'm lacking what you mean with "compromise" with blobs ...
I guess you're concerned by the potential harm an uncontrolled ring0-code could do to the system, and would like to run it in a sort of sandbox.

Hi,

There's currently a large problem with some devices that don't allow device drivers to be written due to intellectual property or other reasons - winmodems, video cards, wireless ethernet cards, etc.

If your OS could use device drivers designed for Windows, this would solve the problem, however, getting Windows device drivers to run would be another large problem, and getting them to run in a ring3 sandbox would be even harder. You'd still have a large problem, but it'd be a different large problem.

For example, you'd need to:

Decide which version of Windows the device drivers come from - would your OS need Windows XP drivers, or Windows Vista drivers? How long before Microsoft release another OS and change the device driver model again?
Figure out how to give the device driver access to the caller's address space. For this you'd need to map the caller's data into the driver's address space, possibly at a different address to avoid conflicts.
Implement everything that the device driver relies on so that it behave like Windows. This includes the dynamic linker, the memory manager, scheduler, TCP/IP stack, the device manager, the registry, etc.
Implement enough to allow the device driver to be installed. For example, if a device driver comes with a setup utility, then you'd need to (at least partially) support normal Windows applications so that this setup utility can be run.

For most of us, there's a large number of native device drivers that can be written, some native device drivers that can't be written, and not enough time to implement most of them anyway. The normal solution is to implement some of the device drivers, provide some generic support where you can, and then tell people the OS doesn't support the device drivers you haven't written yet.

If you try to support native device drivers and Windows device drivers, then you will run out of time and won't get much of either finished. If you support Windows device drivers only, then it might be better to join the ReactOS project - interestingly, they had their 10 year anniversary recently, but still have "Please bear in mind that ReactOS 0.3.0 is still in alpha stage and is not recommended for everyday use." on their home page).


Cheers,

Brendan

By run out of time...do you mean die of old age?

I think he meant the biblical sense: after thousands of generations of coding hybrid device driver support the Lord will summon the world at the End of Time... You know, the Four Horsemen and all that ;D