#102232 - keldon - Tue Sep 12, 2006 2:24 am
Now something has been bugging me for years. Ever since I first had the horror of having to chase a driver for a piece of hardware that had no driver support for the current operating systems I have had one thought. Hardware that provided the driver for the operating system.
Now there are obvious questions and concerns. How does this work for all operating systems? Can it work for all operating systems? How can it work? How can it fail?
Now I think that first there needs to be a standards body to hold the descriptions of hardware. Anything new has to be sent to them to be specified so that they can turn it into a standard.
Next the hardware provides some sort of description of how the OS needs to communicate with it to fulfil the specification of its function. This could be some sort of custom bytecode, coupled with some technology to bridge the inbetween parts to work with the way the OS operates.
Now let's assume that this technology exists and is a trade secret of some company but it does exist somehow. Let is now try to break it down and figure out how it works .... you never know, maybe it is possible.
p.s. I'm not sure if this is related, but one researcher in my uni has created a program that can take a mathematical proof and create a program from it. An example is when he put the proof of infinite prime numbers into the program, and the program created a completely new and efficient algorithm for finding prime numbers. Such a technology could possibly be used to turn a specification into a program.
Discus!!!
#102235 - tepples - Tue Sep 12, 2006 3:02 am
Open Firmware was supposed to implement at least some of what you talk about, where the drivers for some popular device classes are written in Forth and stored on the card's ROM. However, hardware manufacturers work faster than standards bodies and will likely add "extensions" as selling points that have the side effect of restoring incompatibility.
What does discus have to do with anything?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#102255 - keldon - Tue Sep 12, 2006 9:37 am
Sorry, I meant discuss. It's a tradition at some other forum I used to post at.
In all honesty I'm just looking for an alternative MSc research topic and this is one piece of technology I would like to see on hardware.
Extensions can be handled in the typical way as long as the device can function well without it. And this can still be handled by the technology. The hardware can have a flash update tool for when the standards upgrade their specification.
I also think that all hardware should have lifelong support information available. Vendors often remove help/support information for legacy products which I think is unacceptable, especially if the product is not yet obsolete. So the standards body could handle this. Linux can benefit greatly for this by having instant support for hardware.
I can demonstrate this with virtual hardware, like a modified emulator or something, and prove it with a simulated flash update.
#102333 - josath - Wed Sep 13, 2006 12:37 am
This could be feasibly done for USB devices...just make your device a Composite USB device, one of the devices would be a standards-compliant mass storage device, which contains the mac/linux/windows drivers for the actual device.
#102371 - keldon - Wed Sep 13, 2006 10:05 am
| josath wrote: |
| This could be feasibly done for USB devices...just make your device a Composite USB device, one of the devices would be a standards-compliant mass storage device, which contains the mac/linux/windows drivers for the actual device. |
The whole point of it is that there would be no individual drivers for operating systems. Instead a single driver that is read and processed for any OS, otherwise your windows, mac, and linux driver become obsolete with the next installment of the OS.
#102463 - sgeos - Thu Sep 14, 2006 6:45 am
I don't know much about drivers. The idea is cute, but here are my thoughts.
I. A driver is software support for a hardware device. (Ie, a library that handles GBA IO calls so that you don't have to.)
II. OSs operate in different ways.
I think what you will end up with is:
Hardware -> firmware driver -> OS driver
The only way that this could possibly be useful is if all of the firmware drivers (for a particular type of device) have the same interface. Then all of the OS drivers/systems could use any hardware.
(Embedded) java (or some other OO language) seems like the way to go. Interfaces could be subclassed to provide extensions. As tepples said, now things are no longer compatable (or they are, but the extensions can not be used). If java is used, especially for firmware, efficiency could be a problem. (Usually I'd say that pre-optimization is bad, but we are talking about drivers =)
As far as standards bodies go... they work slowly. Unless the standards really have something to offer, they won't be adopted.
-Brendan
#102473 - kusma - Thu Sep 14, 2006 9:41 am
| keldon wrote: |
The whole point of it is that there would be no individual drivers for operating systems. Instead a single driver that is read and processed for any OS, otherwise your windows, mac, and linux driver become obsolete with the next installment of the OS. |
You allways need something in the other end that knows how to interpret the shared memory and registers, how to respond to a given interrupt and so on. Data structures must be converted, memory must be mapped. A virtual machine might not be able to deal with all the differences in how different operating systems deal with these kind of problems. In many cases hardware is not a total solution to a problem, and it is often too expensive to add gates just to keep the sofware-interface simple.
I don't think this is a very good idea, at least not when looked upon from a hardware vendors point of view. (I guess I would kinda know, as I work at one.) Ofcourse innovation is allways cool, and making cross platform driver development easier could perhaps be an interresting field of research.
#102506 - keldon - Thu Sep 14, 2006 7:39 pm
The proposal was not host controlled drivers, but a single driver written in a customised bytecode that can then be JITTED or compiled for any processor and work with any OS.
And isn't java's slow speed more of a myth than anything. this benchmark and many others have java outperforming c some tasks and not doing too bad with algorithms. I read that it was mostly down to the startup speed of java apps and the java gui and some of the synchronization for its util library that makes many java apps look slower than they are, or just slower full stop.
The main issue is in having something that all OS's can work with, although that might not be an issue at all.
But all of the issues are topics that can be covered in research.
Maybe no standard is required at all other than the bytecode. And doesn't hardware like gfx cards still need to work towards the same functionality anyway since there is only one directX?
What I would then like to ask kusma then is what would be so difficult about having a driver written in a custom bytecode that is interpreted by the OS? And I don't ask this as a rhetoric, I want to know what is supposedly so difficult.
#102508 - keldon - Thu Sep 14, 2006 7:47 pm
Oh, it looks like there has been some development in this area. http://www.windowsfordevices.com/news/NS9658454425.html
#102592 - sgeos - Fri Sep 15, 2006 2:54 pm
| keldon wrote: |
Maybe no standard is required at all other than the bytecode. And doesn't hardware like gfx cards still need to work towards the same functionality anyway since there is only one directX?
|
A dual display TV tuner video card, and a triple buffer hi-res game video card do different things.
In theory I might want to make a video card that can switch resolutions instantly using a custom keyboard. (The card block reads from memory depending on the mode. The keyboard buttons poke registers. Stupid or not, that is the design.) That would need special drivers. I imagine all OSs would be unequally unhappy with this deal.
-Brendan
#102602 - keldon - Fri Sep 15, 2006 3:37 pm
| Quote: |
| A dual display TV tuner video card, and a triple buffer hi-res game video card do different things. |
I am not oblivious to the subject of device drivers, I am only considering the area. What I was talking about is that gfx cards have some comformity to direct x. Their driver has to communicate with direct x, and anything it does that isn't handled by DX is never witnessed unless the game independantly handles it. The only pieces of hardware that do not adhere to a standard would be ones that are unique and for their package only right? Nearly every piece of hardware on your computer has a standard, the unique driver only communicates with the HAL (or which ever layer) anyway.
And for your proposed system [through my interpretation] you would need the keyboard/gfx card to be interfacing with the OS to free the memory, the OS for allowing access for the video drivers to use that area of memory (or have the same driver working with both). I don't see any difficulty in the system unless I am interpretting it wrong.
The way I see such a system is that you read from the custom keyboard, and send messages/data to the gfx card. I don't get what is difficult about it. The keyboard doesn't need to write to any specific area of memory; just the same area of memory that the gfx card is accessing. And you wouldn't ever create hardware that OS's would be unhappy with in the first place anyway.
If you can write a driver for one OS then what is stopping you from writing it from another? Now all operating systems handle their policies differently but what really would make it impossible to have an OS independant driver running on a virtual machine? You can quite easily, for example, create a virtual machine with hardware access and program a midi handler that can work for each OS via the VM. So long as the VM has access to the hardware, interrupts vectors can be allocated then what is stopping it?
#102612 - Joe_Sextus - Fri Sep 15, 2006 4:57 pm
| keldon wrote: |
...since there is only one directX?
|
Your system couldn't be specific to DirectX if you plan on it being OS independent. A dependence on DirectX would limit the hardware to Windows, Wine, and possibly ReactOS, but would not be useable by Linux or MAC machines.
-Joe
#102619 - keldon - Fri Sep 15, 2006 6:15 pm
| Joe_Sextus wrote: |
| keldon wrote: |
...since there is only one directX?
|
Your system couldn't be specific to DirectX if you plan on it being OS independent. A dependence on DirectX would limit the hardware to Windows, Wine, and possibly ReactOS, but would not be useable by Linux or MAC machines.
-Joe |
I wasn't talking about having a system specific to direct X. I am just exploring the possiblity of a driver system where a driver can be written once and interpreted by any OS. Now everything says that cannot be done. For a start all hardware [read by common drivers] adhere to some sort of common system. Windows drivers for sound cards communicate in a specific way with windows. Now they are all communicating the same data, so maybe this is sounding more like a wrapper. But with some research there might be a way to write for this single wrapper, and AI could then patch it into the system of the OS. It's only a thought and a question of what would make it possible if it could be done.
#102630 - Joe_Sextus - Fri Sep 15, 2006 8:04 pm
| keldon wrote: |
I wasn't talking about having a system specific to direct X. I am just exploring the possiblity of a driver system where a driver can be written once and interpreted by any OS. Now everything says that cannot be done. For a start all hardware [read by common drivers] adhere to some sort of common system. Windows drivers for sound cards communicate in a specific way with windows. Now they are all communicating the same data, so maybe this is sounding more like a wrapper. But with some research there might be a way to write for this single wrapper, and AI could then patch it into the system of the OS. It's only a thought and a question of what would make it possible if it could be done.
|
It could be possible, but would be easier to transfer most of the software functions to the hardware instead of using software, so that the "driver" is just a wrapper for the function in the hardwares firmware/ROM.
-Joe
#102638 - keldon - Fri Sep 15, 2006 9:03 pm
But then that would be a great overhead to any hardware that does such a thing. It's not the ideal solution, but maybe there is no solution. I would just like to see if it is anything worth exploring.
The way it looks to me is that the simplest solution is actually a subsystem/abstraction layer which is accessed via a VM, and then each OS can then have their own communication with it. Doesn't sound like a good thing at the moment, but maybe part of the research is in finding a system that can take the driver for the VM and then convert it to a driver specifically for the OS. It might be possible.
And this is not something that is expected to 'take off' or anything, it is more for research purposes. It can be tested with a virtual scenario and benchmarking performance of both systems. So we would have a driver written directly for one OS for the virtual item of hardware, and then a driver written using the abstraction layer via the VM. Code will have to be jitted, and instructions minimized - maybe reduce to 16 or so instructions.
Of course who knows what research may uncover; but I'll have to see, I've already got a research topic, this is just a plan b.
#102658 - tepples - Fri Sep 15, 2006 11:24 pm
| sgeos wrote: |
| A dual display TV tuner video card, and a triple buffer hi-res game video card do different things. |
Then the driver of the card with a TV tuner would implement the "Image Sequence Capture" and "Audio Capture" APIs in addition to the "Frame Buffer Display" API, and the driver of the card with a polygon accelerator and three frame buffers would implement the "GL State Machine" API and support at least three disjoint surfaces in the "Frame Buffer Display" API.
| sgeos wrote: |
| In theory I might want to make a video card that can switch resolutions instantly using a custom keyboard. (The card block reads from memory depending on the mode. The keyboard buttons poke registers. Stupid or not, that is the design.) That would need special drivers. |
The keyboard would include drivers that turn register pokes into keypress events, your operating system would turn keypress events into frame buffer zoom commands, and the video card would include drivers that act on frame buffer zoom commands.
| keldon wrote: |
| The only pieces of hardware that do not adhere to a standard would be ones that are unique and for their package only right? |
Unfortunately, every hardware manufacturer thinks that its hardware is unique, whether it is in fact or not.
| keldon wrote: |
| If you can write a driver for one OS then what is stopping you from writing it from another? |
If you continue to support your hardware across multiple operating systems, then you can't squeeze additional revenue from your customers who have to re-buy hardware, can you?
| Joe_Sextus wrote: |
| Your system couldn't be specific to DirectX if you plan on it being OS independent. A dependence on DirectX would limit the hardware to Windows, Wine, and possibly ReactOS |
You forgot Windows XB (Xbox OS based on stripped-down Win2K) and Windows XB 360.
| Joe_Sextus wrote: |
| but would not be useable by Linux or MAC machines. |
s/DirectX/OpenGL and OpenAL/g and the main point of the argument remains true.
| Joe_Sextus wrote: |
| It could be possible, but would be easier to transfer most of the software functions to the hardware instead of using software, so that the "driver" is just a wrapper for the function in the hardwares firmware/ROM. |
But it's less expensive to manufacture devices where functions are performed on the host machine than on a separate processor in the card. Witness Winmodems. The suggestion here is that drivers be written in the same kind of "managed" code used in apps for the Java platform and the .NET framework. Open Firmware is a start.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#102714 - sgeos - Sat Sep 16, 2006 11:24 am
| tepples wrote: |
| sgeos wrote: | | In theory I might want to make a video card that can switch resolutions instantly using a custom keyboard. (The card block reads from memory depending on the mode. The keyboard buttons poke registers. Stupid or not, that is the design.) That would need special drivers. |
The keyboard would include drivers that turn register pokes into keypress events, your operating system would turn keypress events into frame buffer zoom commands, and the video card would include drivers that act on frame buffer zoom commands. |
That is all fine and dandy, but I can't see a generic ROM driver being able to do that across all OSs. I could be wrong.
The VM is a neat idea. Assuming that it was supported by all OSs, it could work, but I don't really see the point. It adds another software layer. If I understand correctly, you are using a VM to provide a standard hard interface across OSs. The hardware is constant from the start, so I don't see the point. You might know something I don't.
-Brendan
#102735 - zzo38computer - Sat Sep 16, 2006 3:20 pm
Actually I need to make a PC Hardware which is compatible with the future (the software also has to be compatible with the future), and run Linux.
_________________
Important: Please send messages about FWNITRO to the public forum, not privately to me.
#102763 - keldon - Sat Sep 16, 2006 9:09 pm
| sgeos wrote: |
The VM is a neat idea. Assuming that it was supported by all OSs, it could work, but I don't really see the point. It adds another software layer. If I understand correctly, you are using a VM to provide a standard hard interface across OSs. The hardware is constant from the start, so I don't see the point. You might know something I don't.
-Brendan |
Well it's not that I have anything special, or anything at all, I just want to know what would make it possible if it could be possible. And also how it could be done best.
The point and motivation is simply being able to write a single driver that is compatible with practically any OS.
Thinking further it has only just come to my attention that there are only a small number of devices that would ever require generic drivers in the first place:
- multimedia cards (cam/gfx/audio)
- storage media
- control surfaces (keyboards, mice, joypads, midi devices)
- and whatever I forgot
Most hardware vendors are adding some support for linux so maybe it would serve no purpose. I guess that the ideal solution is one that is as fast as if the driver had been written specifically for the OS, then it would be great. It sounds like a dream because the extra layer would make such a thing impossible, but there could be a way to then compile the driver specifically for your OS using some form of AI. So then the driver would probably need to be a little more declaritive, defining the communication specification for hardware to operate, and the method of communication to extract the information required for the OS.
#102849 - sgeos - Sun Sep 17, 2006 11:11 am
tepples hit the nail on the head with APIs.
You could put the source in ROM and rely on some type of auto compilation, but I don't think that that solves the main problems. One problem is that OSs handle generic tasks in different ways.
Unless, I missed something, all OSs would need to support a model similar to this:
device -> generic driver/API implementation -> standard driver VM/API -> OS
If the number one OS share holder (Windows) decides to not participate, or decides to use a deviant driver VM/API, that will slow everyone else down for years. Microsoft has done this with various web technologies.
In theory they just botched the implementation. It goes without saying that all OSs would need to virtually bug free VMs for this to be of any use.
It sounds to me like you'd have a hard time getting all parties to participate. If I was in charge of MS, I would have no reason to care if hardware devices are supported by other OSs. I'd actually have reasons to wish that some hardware devices are not supported.
Likewise, if I'm a hardware vendor and have a million lines of working driver library code already written, I have a reason not to want to bother touching your new VM. This is especially true if the code is OS specific.
I guess I'd like to hear an answer "why do I care?", from the perspective of...
... a user. (done)
... a hardware vendor.
... an OS vendor.
... a free OS developer. (obvious, they are the ones who get left out)
-Brendan
#102857 - keldon - Sun Sep 17, 2006 2:17 pm
I'm not thinking about something that would be implemented, but technology to research.
Hardware vendor: for those who write linux drivers, it allows them to write a single driver that can support either OS
OS Vendor: It means your OS has support that does not rely on the hardware vendors targetting your OS
| Quote: |
| Likewise, if I'm a hardware vendor and have a million lines of working driver library code already written, I have a reason not to want to bother touching your new VM. This is especially true if the code is OS specific. |
Some hardware vendors like ATI are developing linux drivers. If there was one efficient way to write a single driver then they have a driver for all versions of mac, windows and older operating systems (that can support the VM, or whatever mechanism is used).
| Quote: |
You could put the source in ROM and rely on some type of auto compilation, but I don't think that that solves the main problems. One problem is that OSs handle generic tasks in different ways.
Unless, I missed something, all OSs would need to support a model similar to this:
device -> generic driver/API implementation -> standard driver VM/API -> OS |
With research you may find a way that does not rely on this. The language could be both declarative and imperative in some way, using declaration as a way for each OS to find their own solution to bridging the communication.
#129335 - keldon - Mon May 21, 2007 10:55 pm
It appears that the hardware vendor gains nothing as the target platform is either Windows or Mac. Having said that a lecturer at my uni created an algorithm that turned proofs into efficient algorithms - one of my potential topics is standardizing that into a language. I'll add a tag about drivers to remind myself of a potential area for the topic.