"compromising" with blobs... (?)

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
earlz

"compromising" with blobs... (?)

Post by earlz »

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
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:"compromising" with blobs... (?)

Post by Pype.Clicker »

so you're trying to do something like http://ndiswrapper.sourceforge.net/, right?
blob is like a binary driver(like how win-modem drivers are)
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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:"compromising" with blobs... (?)

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
omin0us

Re:"compromising" with blobs... (?)

Post by omin0us »

Brendan wrote:
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.
By run out of time...do you mean die of old age?
Habbit

Re:"compromising" with blobs... (?)

Post by Habbit »

omin0us wrote:
Brendan wrote:
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.
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
Post Reply