Quicksearch
Disclaimer
The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
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.
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.
+1
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0
Contact
Networking
xing.com
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
xing.com
My photos
Comments
about Tracks
Tue, 15.05.2012 19:46
Very nice, I like the way the
eye is taken right into the pi
cture. Did you use any filter
s not to make the green [...]
about Köhlbrand Bridge
Mon, 07.05.2012 17:48
I realy love the image.
Tha
nk you for the original size o
n flickr. I will add this as p
oster to my corridor (wi [...]
Wed, 02.05.2012 14:40
Buttons
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
