Is it possible to encode a device driver in Java?

Question

Introduction

I heard something about writing device drivers in Java (I heard it in the ears and not from the Internet) and wondered ... I always thought that device drivers work at the operating system level and therefore should be written in same language as OS (thus mainly CI)

Questions

• Am I mistaken in this assumption? (it seems so)
  
• How to driver in a "foreign" language in the OS?
  
• What are the requirements (from a programming language) for a device driver anyway?
  
  

Thanks for reading

Answer 1

There are several ways to do this.

First, code that runs at the "OS level" does not have to be written in the same language as the OS. It just needs to be associated with the OS code. Almost all languages ​​can interact with C, and that’s really all that is needed.

So, in terms of language, technically there is no problem. Java functions can call C functions, and C functions can call Java functions. And if the OS is not written in C (say, for the sake of an argument written in C ++), then the C ++ OS code can call some intermediate C code, which is sent to your Java, and vice versa. C is pretty much a programming language.

Once a program has been compiled (for native code), its source language no longer matters. Assembler looks about the same, regardless of what language the source code was written before compilation. As long as you use the same calling convention as the OS, this is not a problem.

A bigger problem is runtime support. There are not many software services in the OS. For example, there is usually no Java virtual machine. (There is no reason why it could not technically be there, but usually, but usually, we can safely assume that it is not present).

Unfortunately, in its default Java bytecode view, a Java program requires a lot of infrastructure. He needs a Java virtual machine to interpret and JIT bytecode, and he needs a class library, etc.

But there are two ways around this:

• Java support in the kernel. This will be an unusual step, but it can be done.
• Or compile the Java source code in a native format. A Java program does not need to be compiled into Java bytecode. You can compile it for x86 assembler. The same goes for any class libraries that you use. They can also be compiled to assembler. Of course, parts of the Java class library require certain OS functions that will not be available, but then the use of these classes could be avoided.

So yes, it can be done. But it is not simple, and it is not clear what you received.

Of course, another problem may be that Java will not allow you to access arbitrary places of memory, which will greatly complicate the transfer of hardware. But this could also be handled, perhaps by calling very simple C functions that simply return the corresponding memory areas as arrays for Java to work.

Answer 2

Writing Solaris device drivers in Java spans A RAM device written in Java.

Another for Linux . Learn more about why you might need a DD in Java (as some people wondered about other posts and comments)

Answer 3

This is not impossible, but perhaps difficult and may not make much sense.

Perhaps because Java is a common programming language, if you have some way of accessing data, this is not a problem. Typically, in a modern operating system, the kernel has a layer that allows you to somehow provide raw access to the equipment. Also, drivers already exist in user space, at least the userpace-Part should not be a problem for implementation in Java.

This does not make too much sense, because the kernel must start the JVM to start the driver. Also, JVM implementations usually contain a lot of memory.

You can also use Java code compiled to run on the platform (rather than using the JVM). This is usually not as effective, but it may be suitable for the device driver.

The question is, does it make sense to implement a driver in Java? Or stated differently: what are you hoping for if you use Java to implement a driver instead of another alternative? If you can answer this question, you must find a way to make this possible.

At the end, a hint of JNode is a project that tries to implement a complete OS exclusively based on Java.

Answer 4

A device driver can be many things.

In fact, I write device drivers in java for life: drivers for industrial devices such as scales or weighing devices, packaging machines, barcode scanners, weight bridges, printers for bags and boxes ... Java is really a good choice here.

Industrial devices are very different from your home / office devices (e.g. scanners, printers) . Especially in the field of production (for example, food), companies are increasingly choosing a centralized server that runs the MES application (for example, developed in Java). The MES server must communicate with production line devices, but also contains business logic. Java is a language that can do both.

If your home / office devices are often integrated into your computer or connected using a USB cable, these industrial devices typically use Ethernet or RS232 connectors. So, in fact, almost every language can do the job.

There is not much standardization in this area yet. Most vendors prefer to create their own protocols for their devices. After all, they are hardware manufacturers, not software geniuses. The result is a wide variety of protocols. Some vendors prefer simple text protocols, but others prefer complex binary protocols with CRC codes, framing, ... Sometimes they like to stack several protocols (for example, the algorithm for confirming the connection of a particular provider on top of the OPC level). A strong OOP language has many advantages here.

For example, I saw Java printing at a constant speed of 100 ms / cycle. This includes creating a unique label, sending it to the printer, receiving confirmation, printing it on paper and applying it to the product using air pressure.

So the power of Java:

• This is useful for both business logic and complex interaction.
• It is as reliable with sockets as C.
• Some drivers may benefit from the power of Java OOP.
• Java is fast enough.

Answer 5

Did you hear the link to JDDK ?

Writing a device driver to 100% in Java is not possible without built-in code to provide interaction between (1) entry points and agreements on a specific driver for the OS and (2) a JVM instance. A JVM instance can be run in-process (and in-process can have different meanings depending on the OS and whether the driver is a kernel-mode or user-mode driver) or as a separate user-friendly process with which a thin can interact , the adaptive level of the adaptive driver, and to which said driver adaptation layer can offload the user's actual work.

Answer 6

Your device drivers are too narrow.

I wrote such device drivers on top of MOST in an automotive application. Wider use could be a driver for USB devices if Java ever gets a decent USB library.

In these cases, there is a general low-level protocol that is processed in its own code, and the Java driver processes the device specifics (data formats, state machines, ...).

Answer 7

It is possible to compile java code for hardware related instructions (i.e. not with JVM bytecode). See for example GCJ . With this in hand, you are much closer to compiling device drivers than before.

I do not know how practical this is.

Answer 8

Maybe?

Yes, but only in special circumstances. Because you can write an operating system in Java and C #, and then to be able to write device drivers for it. The memory that gets into these drivers and operating systems will be substantial.

Probable?

Most likely. At least not in the world of Windows or MacOS or even Linux ... At least in the near future. Because languages ​​like C # and Java are dependent on the CLR and JVM. The way these languages ​​work means that they cannot be loaded efficiently into ring0.

In addition, the performance hit will be quite large if managed languages ​​are used in device drivers.

Answer 9

For motivation, please remember that there are many fast languages ​​that are better than C for programming; they may not be as fast as C, but they are safe languages: if you make a mistake, you will not get undefined behavior. And "undefined behavior" includes the execution of arbitrary code provided by some attacker who formats your HD. Many functional languages ​​are usually compiled into native code.

Device drivers contain most of the errors in the kernel of the OS - I know that for Linux (Linus Torvalds and others say so), and I heard that for Windows. While you need first-class performance for a drive or an Ethernet driver, and while Linux drivers today have a bottleneck for 10G Ethernet or SSDs, most drivers do not need that much speed - all computers are waiting with the same speed.

That is why there are various projects that allow you to write drivers that run outside the kernel, even if it causes a slowdown; when you can do this, you can use any language that you need; you just need the Java bindings for your hardware management library — if you are writing a driver in C, you will still have a library with C. bindings

For drivers in kernel mode, there are two problems that I have not seen before:

• Garbage collection, and this is a tough requirement. You need to write a garbage collector in the kernel; some GC algorithms are based on virtual memory, and you cannot use them. In addition, you will probably need to scan the entire OS memory to find the roots for the GC. Finally, I would only trust an algorithm guaranteeing a (soft) GC in real time, which would make the overhead even greater. Reading an article that mentioned Java device drivers on top of Linux, they just give up and require programmers to manually free memory. They try to argue that this will not compromise security, but I don’t think their argument is convincing - it’s not even clear whether they understand that garbage collection is necessary for a safe language.

• Reflection and loading of classes. A full Java implementation, even when using native code, should be able to load new code. This is a library that you can avoid, but if you have an interpreter or JIT compiler in the kernel (and there is no real reason that makes it technically impossible).

• Performance

  . The Linux JVM document is very poor and their performance is not convincing - indeed, they test the USB 1.1 network driver and then show that the performance is not so bad! However, given enough effort, you can do something better.

Two last things:

• I would like to mention Singularity, which is a complete OS written in C #, with just a level of hardware abstraction in the native language.
• About picoJava, it is a bad idea to use it if your system is really limited by memory, like a smart card. Cliff Click has already explained why: it gives the best performance for writing a good JIT, and even smartphones can support it these days.

Answer 10

Device drivers must be written in a language that can be executed in the kernel, either compiled into it, or loaded as a module at runtime. This usually prevents writing device drivers in Java, but I suggest that you could theoretically implement the JVM inside the device driver and let it run Java code. Not that any sane person wants to do this.

On Linux, there are several user-defined (i.e., not the kernel) file system implementations that use a common abstraction layer (fuse) that allows user-land programs to implement things that normally run in the kernel.

Answer 11

The Windows Driver Foundation (WDF) is a Microsoft API that allows the User and kernel-mode device drivers> to be written. This is done today, and now it is compatible with w2k and later (used to not have w2k as a supported target). There is no reason JNI calls cannot be made to do some work in JRE. (Assuming JNI is still a way to call Java from C / C ++ ... my knowledge is dated in this arena). This can be an interesting way for high-level algorithms to directly collect data from a USB tube for something with this., Cool stuff!

Answer 12

PCIe user space drivers can be written in Pure Java. See JVerbs for details on direct memory-based hardware access in the OFED context. This is a method that you can use to create high-performance systems.

You can check the PCI bus to determine the memory areas for this device, which ports it has, etc. Areas of memory may be displayed in the JVM process.

Of course, you are responsible for implementing everything .

I did not say easily. I said that it is possible .;)

See also User Space Device Drivers for a discussion of using the UIO structure to create a user space driver.

Answer 13

First of all, pay attention to the fact that I am not an expert in device drivers (although I myself wrote several times a day), and even more so, an expert in Java.

Leave the fact that writing device drivers in a high-level language is not a good idea (for performance, and possibly for many other reasons) aside for a moment, and answer your question.

You can write device drivers in almost any language, at least in theory.

However, most device drivers need to run many low-level files, such as handling interrupts and communicating with the OS using the OS's APIs and system calls, which I believe you cannot make in Java.

But if your device communicates using, say, a serial port or USB, and if the OS does not have to know the device (only your application will access the device *), you can write a driver in any language that provides the necessary means to access the device .

So, for example, you probably cannot write a SCSI card driver in Java, but you can write a driver for a proprietary control device, USB lava, license key, etc.

* The obvious question here, of course, is that it is considered a driver?