Можно ли написать драйвер устройства на Java?

Это можно сделать двумя способами.

Во-первых, код, работающий на «уровне ОС», не обязательно должен быть написан на том же языке, что и ОС. Он просто должен быть связан с кодом ОС. Практически все языки могут взаимодействовать с C, а это действительно все, что нужно.

Так что с точки зрения языка проблем технически нет. Функции Java могут вызывать функции C, а функции C могут вызывать функции Java. И если ОС написана не на C (скажем, ради аргумента, что она написана на C ++), то код ОС C ++ может вызывать некоторый промежуточный код C, который пересылается на вашу Java, и наоборот. C - это в значительной степени lingua franca программирования.

После того, как программа была скомпилирована (в машинный код), ее исходный язык больше не актуален. Ассемблер выглядит одинаково независимо от того, на каком языке исходный код был написан до компиляции. Пока вы используете то же соглашение о вызовах, что и ОС, это не проблема.

Более серьезная проблема - это поддержка во время выполнения. В ОС доступно не так много программных сервисов. Например, обычно нет виртуальной машины Java. (Нет причин, по которым технически не могло быть, но обычно, но обычно можно с уверенностью предположить, что его нет).

К сожалению, в своем "стандартном" представлении в виде байт-кода Java программа Java требует большой инфраструктуры. Ему нужна виртуальная машина Java для интерпретации и JIT байт-кода, а также библиотека классов и так далее.

Но есть два способа обойти это:

• Поддержка Java в ядре. Это был бы необычный шаг, но его можно было бы сделать.
• Или скомпилируйте исходный код Java в собственный формат. Программу Java не нужно компилировать в байт-код Java. Вы можете скомпилировать его на ассемблер x86. То же самое касается любых библиотек классов, которые вы используете. Их тоже можно было скомпилировать до ассемблера. Конечно, для частей библиотеки классов Java требуются определенные функции ОС, которые будут недоступны, но тогда использования этих классов можно было бы избежать.

Так что да, это можно сделать. Но это непросто, и непонятно, что вы получите.

Конечно, еще одна проблема может заключаться в том, что Java не позволит вам получить доступ к произвольным участкам памяти, что сделало бы большую часть аппаратной связи довольно сложной. Но это тоже можно обойти, возможно, вызвав очень простые функции C, которые просто возвращают соответствующие области памяти в виде массивов для работы Java.

Написание драйверов устройств Solaris на Java касается устройства RAM-диска, написанного на Java. .

Еще один для Linux. Более подробно рассматривается, почему вам также может понадобиться DD на Java (поскольку некоторые люди интересовались внешним видом других сообщений и комментариев)

Драйвером устройства может быть много чего

На самом деле я пишу драйверы устройств на java, чтобы заработать себе на жизнь: драйверы для промышленных устройств, таких как весы или устройства для взвешивания, упаковочные машины, сканеры штрих-кода, мосты для взвешивания, принтеры для сумок и коробок, ... Java - действительно хороший выбор.

Промышленные устройства сильно отличаются от ваших домашних / офисных устройств (например, сканеров, принтеров). В частности, в сфере производства (например, продуктов питания) компании все чаще выбирают централизованный сервер, на котором выполняется приложение MES (например, разработанное на Java). Сервер MES должен взаимодействовать с устройствами производственной линии, но также содержит бизнес-логику . Java - это язык, который может делать и то, и другое.

Там, где ваши домашние / офисные устройства часто встроены в ваш компьютер или подключены с помощью USB-кабеля, эти промышленные устройства обычно используют разъемы Ethernet или RS232. Так что, по сути, практически любой язык может сделать работа.

В этой области пока нет большой стандартизации. Большинство поставщиков предпочитают создавать свои собственные протоколы для своих устройств. В конце концов, они строители оборудования, а не гении программного обеспечения. В результате существует большое разнообразие протоколов. Некоторые поставщики предпочитают простые текстовые протоколы, но другие предпочитают сложные двоичные протоколы с кодами CRC, кадрированием, ... Иногда им нравится складывать несколько протоколов (например, алгоритм подтверждения связи конкретного поставщика поверх уровня OPC). У сильного ООП-языка есть много преимуществ.

Например. Я видел печать Java с постоянной скоростью 100 мс / цикл. Это включает создание уникальной этикетки, отправку ее на принтер, получение подтверждения, печать на бумаге и нанесение на продукт с помощью давления воздуха.

Итак, возможности Java:

• Это полезно как для бизнес-логики, так и для сложных интерфейсов.
• Он так же надежен в связи с сокетами, как и C.
• Некоторые драйверы могут использовать преимущества ООП Java.
• Java достаточно быстрая.

Это не невозможно, но, возможно, сложно и, возможно, не имеет особого смысла.

Возможно, потому что Java - это нормальный язык программирования, и пока у вас есть способ доступа к данным, это не проблема. Обычно в современной ОС ядро ​​имеет уровень, позволяющий каким-либо образом разрешить прямой доступ к оборудованию. Также уже существуют драйверы в пользовательском пространстве, по крайней мере, пользовательскую часть не должно быть проблем для реализации на Java.

Возможно, в этом нет особого смысла, потому что ядро ​​должно запустить JVM для выполнения драйвера. Также реализации JVM обычно потребляют много памяти.

Вы также можете использовать Java-код, скомпилированный для выполнения на платформе (не с помощью JVM). Обычно это не так эффективно, но может подойти для драйвера устройства.

Вопрос в том, есть ли смысл реализовать драйвер на Java? Или по-другому: на какую выгоду вы надеетесь, если вы используете Java для реализации драйвера вместо другой альтернативы? Если вы можете ответить на этот вопрос, вы должны найти способ сделать это возможным.

В конце подсказка к JNode, проекту, который пытается реализовать полную ОС, основанную исключительно на Java.

У вас слишком узкое представление о драйверах устройств.

Я написал такие драйверы устройств поверх MOST в автомобильном приложении. Более широкое использование могут быть драйверы для USB-устройств, если Java когда-либо получит достойную USB-библиотеку.

В этих случаях существует общий протокол низкого уровня, который обрабатывается в собственном коде, а драйвер Java обрабатывает особенности устройства (форматы данных, конечные автоматы и т. Д.).

Возможно, вы слышали ссылку на JDDK?

Написание драйвера устройства на 100% на Java невозможно без собственного кода, чтобы обеспечить взаимодействие между (1) точками входа и соглашениями для драйвера, зависящими от ОС, и (2) экземпляром JVM. Экземпляр JVM может быть запущен «в процессе» (и «в процессе» может иметь разные значения в зависимости от ОС и от того, является ли драйвер драйвером режима ядра или пользовательского режима) или как отдельная пользовательская область. процесс, с которым может взаимодействовать тонкий, собственный уровень адаптации драйвера и на который упомянутый уровень адаптации драйвера может разгрузить фактическую работу пользователя.

Возможно скомпилировать Java-код в аппаратные инструкции (т. Е. Не байт-код JVM). См., Например, GCJ. Имея это в руках, вы намного ближе к возможности компилировать драйверы устройств, чем раньше.

Но я не знаю, насколько это практично.

Возможно?

Да, но только в особых случаях. Потому что вы можете написать операционную систему на Java и C #, а затем уметь писать для нее драйверы устройств. Ущерб памяти для этих драйверов и операционных систем был бы значительным.

Вероятно?

Скорее всего, не. По крайней мере, не в мире Windows, MacOS или даже Linux ... По крайней мере, в ближайшее время. Потому что такие языки, как C # и Java, зависят от CLR и JVM. Работа этих языков означает, что они не могут быть эффективно загружены в ring0.

Кроме того, падение производительности было бы довольно большим, если бы в драйверах устройств использовались управляемые языки.

Для мотивации, пожалуйста, помните, что существует множество быстрых языков, которые лучше, чем C для программирования; они могут быть не такими быстрыми, как C, но это безопасные языки: если вы сделаете ошибку, вы не получите неопределенного поведения. А «неопределенное поведение» включает выполнение произвольного кода, предоставленного каким-либо злоумышленником, который форматирует ваш HD. Многие функциональные языки обычно компилируются в собственный код.

Драйверы устройств содержат наибольшее количество ошибок в ядре ОС - я знаю это для Linux (Линус Торвальдс и другие постоянно так говорят), и я слышал это для Windows. В то время как для диска или драйвера Ethernet вам нужна первоклассная производительность, и хотя современные драйверы Linux являются узким местом для 10G Ethernet или SSD-дисков, большинству драйверов не нужна такая высокая скорость - все компьютеры ждут с той же скоростью.

Вот почему существуют различные проекты, позволяющие писать драйверы, которые работают вне ядра, даже если это вызывает замедление; когда вы можете это сделать, вы можете использовать любой язык, какой захотите; вам как раз тогда понадобятся привязки Java для библиотеки управления оборудованием, которую вы используете - если бы вы писали драйвер на C, у вас все равно была бы библиотека с привязками C.

Для драйверов, работающих в собственно режиме ядра, есть две проблемы, о которых я еще не упоминал:

• Сборка мусора, а это жесткое требование. Вам необходимо написать сборщик мусора внутри ядра; некоторые алгоритмы GC полагаются на виртуальную память, и вы не можете их использовать. Более того, вам, вероятно, потребуется просканировать всю память ОС, чтобы найти корни для GC. Наконец, я бы доверял только алгоритму, гарантирующему (мягкий) сборщик мусора в реальном времени, что еще больше увеличило бы накладные расходы. Читая статью о драйверах устройств Java поверх Linux, они просто сдаются и требуют, чтобы программисты вручную освободили память. Они пытаются утверждать, что это не поставит под угрозу безопасность, но я не думаю, что их аргумент убедителен - даже не ясно, понимают ли они, что сборка мусора необходима для безопасного языка.

• Отражение и загрузка класса. Полная реализация Java, даже при запуске собственного кода, должна иметь возможность загружать новый код. Этой библиотеки можно избежать, но если у вас есть интерпретатор или JIT-компилятор в ядре (и нет реальной причины, делающей это технически невозможным).

• Представление. Статья о JVM в Linux очень плохая, и их показатели производительности неубедительны - действительно, они тестируют сетевой драйвер USB 1.1, а затем показывают, что производительность не так уж плоха! Тем не менее, если приложить достаточно усилий, можно наверняка сделать что-то лучшее.

Две последние вещи:

• Я хотел бы упомянуть Singularity, полную ОС, написанную в варианте C #, только с уровнем аппаратной абстракции на родном языке.
• Что касается picoJava, использовать его - плохая идея, если только ваша система не имеет действительно ограниченного объема памяти, например смарт-карту. Cliff Click уже объяснил, почему: это дает лучшую производительность для написания хорошей JIT, и в настоящее время даже смартфоны могут это поддерживать.

Драйверы устройств должны быть написаны на языке, который может выполняться в ядре, либо скомпилирован в него, либо загружен как модуль во время выполнения. Обычно это препятствует написанию драйверов устройств на Java, но я полагаю, что теоретически вы могли бы реализовать JVM внутри драйвера устройства и позволить ему выполнять код Java. Не то чтобы здравомыслящий человек захотел это сделать.

В Linux существует несколько реализаций файловых систем на уровне пользователя (то есть не на уровне ядра), которые используют общий уровень абстракции, называемый (fuse), который позволяет программам на уровне пользователя реализовывать вещи, которые обычно выполняются в ядре.

Windows Driver Foundation (WDF) - это API Microsoft, который позволяет как User и Kernel. Это делается сегодня, и теперь он совместим с w2k и более поздними версиями (раньше w2k не поддерживался). Нет причин, по которым вызовы JNI не могут выполняться для работы в JRE. . . (при условии, что JNI по-прежнему является способом вызова Java из C / C ++ ... мои знания датируются этой областью). Это может быть интересным способом заставить алгоритмы высокого уровня напрямую пережевывать данные из USB-канала для чего-то в этом роде. . . крутая вещь!

Драйверы устройств пользовательского пространства PCIe могут быть написаны на Pure Java. См. JVerbs для получения подробной информации о прямом аппаратном обеспечении на основе памяти. доступ в контексте OFED. Это метод, который можно использовать для создания систем с очень высокой производительностью.

Вы можете исследовать шину PCI, чтобы определить области памяти для данного устройства, какие у него порты и т. Д. Области памяти могут быть отображены в процессе JVM.

Конечно, вы несете ответственность за все сами.

Я не сказал «легко». Я сказал, что возможно. ;)

См. Также Драйверы устройств в пространстве пользователя , в котором обсуждается использование инфраструктуры UIO для создания драйвера пользовательского пространства.

Прежде всего, обратите внимание, что я не эксперт по драйверам устройств (хотя некоторые из них я написал в свое время), не говоря уже о Java.

Давайте на мгновение оставим в стороне тот факт, что написание драйверов устройств на языке высокого уровня - не лучшая идея (для производительности и, возможно, по многим другим причинам), и ответим на ваш вопрос.

Вы можете писать драйверы устройств практически на любом языке, по крайней мере, теоретически.

Однако большинству драйверов устройств необходимо выполнять множество низкоуровневых функций, таких как обработка прерываний и взаимодействие с ОС с помощью API ОС и системных вызовов, что, как я полагаю, невозможно сделать в Java.

Но если ваше устройство обменивается данными, используя, скажем, последовательный порт или USB, и если ОС не обязательно должна знать об устройстве (только ваше приложение будет получать доступ к устройству *), тогда вы можете написать драйвер в любом язык, обеспечивающий необходимые средства для доступа к устройству.

Так, например, вы, вероятно, не можете написать драйвер карты SCSI на Java, но вы можете написать драйвер для проприетарного устройства управления, USB-лавовой лампы, лицензионного ключа и т. Д.

* Возникает очевидный вопрос, считается ли это водителем?