Quicksearch
Navigation
Events
Trusted Ad
Blower Door Test
Luftdichtigkeitsmessung für Gebäude Raum Hamburg ab 160 excl. MwSt
www.m-tectum.de
Luftdichtigkeitsmessung für Gebäude Raum Hamburg ab 160 excl. MwSt
www.m-tectum.de
Kategorien
About this blog- Apple
- iPhone
- Aviation
- Bahn
- Begriffe des Lebens
- Blogosphere
- Braindump
- Business Travel
- CANBOX
- CeBIT
- CEC
- Computing
- del.icio.us
- Fundsache
- General
- i hate sundays
- Kochen
- Mindfuck
- Movies
- Music
- On Benchmarketing
- Persoenliches Pech
- Photographie
- policy of ...
- Privacy
- Recommended Blogs
- Security
- Solaris
- Strange Days
- Sun
- suncec2007
- suncec2008
- Technology
- The IT Business
- Toolbox
- Travel
- Work
Device driver in Java
Thursday, January 18. 2007
Panchaleswar Nayak points to an interesting research paper about Writing Solaris Device Drivers in Java. I find this development very promising. You only have to write your drivers once for all platforms that implements the Squawk Java virtual machine. The next step to drive this concept would be the definition of an common generic interface between drivers and the operating system integrated in different operating systems outside the Solaris world. You would be able to use the same driver in different operating system without recompilation.
This would be great help in the competition against the windows ecosphere with their overhelming amount of drivers, as the fragmentation of the unix market from the look of driver developers would disappear.
This would be great help in the competition against the windows ecosphere with their overhelming amount of drivers, as the fragmentation of the unix market from the look of driver developers would disappear.
Posted by Joerg Moellenkamp
in Sun
at
12:33
| Comments (9)
| Trackbacks (0)
View as PDF: This entry | This month | Full blog
View as PDF: This entry | This month | Full blog
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Except you don't need Java for this. You just need the common generic interface.
But with Java you could use the the same "binary" on x86 or Sparc for example without any modifications.
There's little benefit for cross-platform here because the device driver interfaces between different operating systems are so drastically unlike that bridging over those differences isn't quite as trivial as "get a JVM into the OS kernel".
In short, if you read through the paper, it provides native interfacing to Solaris DDI. That doesn't create a platform-independent driver interface layer. All it does is to allow a Solaris device driver being written in a different programming language than "C" - Java. Well, you could use C++ anyway, as SunCluster does; you could use Fortran if you're sick enough, or in the end any compiler that creates C-ABI compliant object code and allows calling C-ABI linkage functions.
How much of a problem is it to compile your device driver twice to get Sparc/x86 binaries ? None.
Now if you think of creating a "Universal Driver Interface" (google for the term) Layer for several UN*X(-like) operating systems, you end up with the ill-fated stillborn UDI approach (ever since which the notion of a 'stable driver interface layer' has become a 150% no-no on Linux). Add to that the desire to make such a layer include e.g. MS Windows, and you're way deep in dreamland.
I mean, that said, there's no reason why platform-independent / cross-platform mechanisms are impossible. In userland, libusb for example demonstrates this (available for Linux, *BSD, Windows, Solaris). And a Java (or Python, Perl, Tcl, ...) Interface to such a library, why not ? Or a Java program that interfaces with cross-platform compatible devices such as V4L ? Of course you can do that. Do it in userland, where the platform abstraction is much easier to get than to put such a glue layer into the kernel ...
In short, if you read through the paper, it provides native interfacing to Solaris DDI. That doesn't create a platform-independent driver interface layer. All it does is to allow a Solaris device driver being written in a different programming language than "C" - Java. Well, you could use C++ anyway, as SunCluster does; you could use Fortran if you're sick enough, or in the end any compiler that creates C-ABI compliant object code and allows calling C-ABI linkage functions.
How much of a problem is it to compile your device driver twice to get Sparc/x86 binaries ? None.
Now if you think of creating a "Universal Driver Interface" (google for the term) Layer for several UN*X(-like) operating systems, you end up with the ill-fated stillborn UDI approach (ever since which the notion of a 'stable driver interface layer' has become a 150% no-no on Linux). Add to that the desire to make such a layer include e.g. MS Windows, and you're way deep in dreamland.
I mean, that said, there's no reason why platform-independent / cross-platform mechanisms are impossible. In userland, libusb for example demonstrates this (available for Linux, *BSD, Windows, Solaris). And a Java (or Python, Perl, Tcl, ...) Interface to such a library, why not ? Or a Java program that interfaces with cross-platform compatible devices such as V4L ? Of course you can do that. Do it in userland, where the platform abstraction is much easier to get than to put such a glue layer into the kernel ...
Iīve didnīt wrote that this is already an device independent driver layer. But i think this would have the potential for bringing a stable this into unix and beside this, itīs a interesting concept.
But you are right. Windows ? No chance. And the missing stable interface in Linux is more a political issue.
But you are right. Windows ? No chance. And the missing stable interface in Linux is more a political issue.
Yes of course UDI is dead. And therefore the idea of creating a committed driver interface for Linux and other UN*Xes is also dead.
That it's technically possible to have a stable, cross-OS driver interface layer - no doubt. But realizing that doesn't depend on (or benefit from) having Java in the kernels.
That it's technically possible to have a stable, cross-OS driver interface layer - no doubt. But realizing that doesn't depend on (or benefit from) having Java in the kernels.
Iīm not entirely sure, if the inkernel JVM is without any benefit. I know, die-hard driver developer would rather shoot themself in the foot than using anything else than C or C++ for programming. But beeing able to use Java for developing drivers can be a benefit in itself by making it more difficult to totally screw up things.
Wrt. to "screwup", any language allows this. Just in different ways. Java isn't a protection against that either.
Don't underestimate the differences between a rich environment (application-level, with a nice set of runtime library features - that's the strength of Java), and a restricted environment (kernel-level, where you just don't have the full set of simple interfaces that make programming in a feature-rich language such a joy).
That said, it's an additional choice - and choice is always good. Time will tell.
Don't underestimate the differences between a rich environment (application-level, with a nice set of runtime library features - that's the strength of Java), and a restricted environment (kernel-level, where you just don't have the full set of simple interfaces that make programming in a feature-rich language such a joy).
That said, it's an additional choice - and choice is always good. Time will tell.
From my experience C or C++ leaves the leash longer to ease up hanging your self 
An restricted environment with a well choosen set of libraries may be really helpful to make the programming more efficient. But you are right, itīs an additional way to reach a target on a different way.
An restricted environment with a well choosen set of libraries may be really helpful to make the programming more efficient. But you are right, itīs an additional way to reach a target on a different way.
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0
Contact
Networking
open.bc
LinkedIn
Facebook
My photos
- mail: joerg@c0t0d0s0.org
- icq: 144000169
- Me, myself and I
- openBC
- My del.icio.us
- c0t0d0s0@twitter
- c0t0d0s0@last.fm
- wiki@c0t0d0s0
- Amazon Wishlist
Networking
open.bc
My photos
Syndication
Comments
about My thoughts about the future of Sun ...
Thu, 20.11.2008 10:50
Well ... i donīt really think that muscle cars and Pick Ups are good products. Those cars have enough cylinder cap [...]
Thu, 20.11.2008 10:50
Well ... i donīt really think that muscle cars and Pick Ups are good products. Those cars have enough cylinder cap [...]
about My thoughts about the future of Sun ...
Thu, 20.11.2008 09:59
Nice articel but i guess that the products himself cant help to safe the future of sun. GM also have great product [...]
Thu, 20.11.2008 09:59
Nice articel but i guess that the products himself cant help to safe the future of sun. GM also have great product [...]
about My thoughts about the future of Sun ...
Thu, 20.11.2008 07:25
Nettes Posting welches sich ab er wieder nur um die Produkte von SUN dreht und nicht um das Doing drumherum. 600-80 [...]
Thu, 20.11.2008 07:25
Nettes Posting welches sich ab er wieder nur um die Produkte von SUN dreht und nicht um das Doing drumherum. 600-80 [...]
about My thoughts about the future of Sun ...
Thu, 20.11.2008 00:47
Great post. We need to see pos ts like this up front and cent re, linked from popular websit es whenever and wherever [...]
Thu, 20.11.2008 00:47
Great post. We need to see pos ts like this up front and cent re, linked from popular websit es whenever and wherever [...]
about Afterthought about the Transitive deal
Wed, 19.11.2008 21:44
Even 5 GHz wonīt give you an e fficient and performant experi ence at translating between th e two architectures and [...]
Wed, 19.11.2008 21:44
Even 5 GHz wonīt give you an e fficient and performant experi ence at translating between th e two architectures and [...]
Getaggte Artikel
AMD Apple avs Bahn Blogging Blogosphere braindump Business Travel CeBIT cec cec2006 CMT del.icio.us deutsch dtrace fliegen Fundsache General Hamburg IBM i hate sundays Intel iscsi jumpstart Links Linux lksf Mindfuck Movies Music Musik Niagara Opensolaris Opteron Photographie policy of ... Politik Security Solaris storage Sun suncec2007 sunw t1 The IT Business Ultrasparc ultrasparc t1 Wirtschaft Work ZFS
Blog Administration
Buttons
