l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Question to throw at you guys


From: Justin Emmanuel
Subject: Re: A Question to throw at you guys
Date: Wed, 15 Nov 2006 04:09:01 +0000

Well after reading the replies, I sure have a lot of material to go through. I see that people have attempted this before. However, I think that the timing was wrong. They also made the mistake of not covering Microsoft operating systems at least in the UDI framework.

Also I think that a key statement that has been said was that "If the hardware was co operative, but that's out of topic" I think that that may very well be in topic.
Reducing the number of drivers that your company has to make, whilst being able to claim compatibility for more operating systems is a business case that maybe needs to be brought to certain hardware manufacturers. I think that if the hardware, which is trusted, was to announce to the OS, its name and negotiate its resources ( I.E. If it has mapped IO memory, that it states this to the OS and how much it needs, also its registers). From that point, a framework can be applied.
What I would like to see is programming in the generic against the device specific. This could take 3 layers.

1) The Driver - This is completely isolated from everything but its untrusted interfaces with the OS. It must be written in a fairly high-level language I.E no such thing as pointers. For instance, say a disk drive. The command to raise the arm, label code block 'raise arm'. Send code to a register 'n' via OS – which knows where the resources lie. This is a very simple example, but now the OS knows how to raise the arm of the hard drive. More abstraction could be built in, for instance instead of raise arm, you could have a seek block label, which abstracts all the steps necessary to get to this stage. The point is, that the programming is couched in non-OS dependant terms. It is also couched in non kernel programming terms.

2) The OS - This plugs in, contains and monitors the driver. It uses the Hardware provided ID and resources to contain and point the driver to the right hardware device.

3) The Hardware - (Self describing potentially - only by announcing its resources)

Isolate the drivers as much as possible
Make the drivers as platform independent as possible

I have been making my way through the references pointed out in this thread. I thought that it was interesting that the same questions that I asked myself were being asked by a lot of different folk. The work being done on Singularity is particularly interesting with regards to some of the paths that they have decided to take.
The original thought that I had was, wouldn't it be cool if:

The DDL was compiled to a byte code (This allows for closed source drivers).
The byte code would be used by the OS to 'learn' to build the driver code itself. (It may have logic errors, but should be syntactically perfect). Nothing direct from the outside would be placed directly against the hardware and the drivers should be fully held to account at every step.
A simple run time would then interface between the OS core and the OS created drivers. The thinking that if every piece of hardware has a driver this would include CPU's, in which case they would not loop back into the OS. If they are a peripheral, they would more than likely loop back to the OS as in the example of the hard drive given above.

This is just an idea that I had when I had some time on my hands.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]