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

Question

Введение

Я что-то слышал о написании драйверов устройств на Java (слышал, как "моими ушами", а не из Интернета), и мне было интересно ... Я всегда думал, что драйверы устройств работают на уровне операционной системы и поэтому должны быть записаны тот же язык, что и ОС (таким образом, в основном CI)

Вопросы * * 1005 Я вообще не прав с этим предположение? (похоже)
Как может водитель в "инопланетянине" язык будет использоваться в ОС?
Какие требования (из точка зрения языка программирования) в любом случае для драйвера устройства?

Спасибо за чтение

Answer 1

Есть несколько способов сделать это.

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

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

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

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

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

Но есть два пути решения этой проблемы:

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Таким образом, сила Java:

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

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

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

Answer 8

Возможно?

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

Вероятные

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

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

Answer 9

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

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

Answer 10

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

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

Конечно, вы сами ответственны за реализацию всего .

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

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