start realtime nodejs node javascript driver linux-device-driver ecmascript-5

realtime - ¿Cómo escribir controladores de dispositivo en Javascript?



rethinkdb nodejs (6)

No en realidad no. Quiero decir, podrías escribir algo que compila Javascript en C, pero eso sería bastante loco. Poco como intentar usar una cuchara como una motosierra.

Aprende C. Esa es la herramienta correcta para el trabajo.

¿Es posible escribir controladores de hardware en Javascript? ¿Cuáles serían los pasos necesarios para tal tarea?

Además, no estaba seguro de dónde publicar esto, por lo que cualquier sugerencia sobre esto también es bienvenida. Espero que esta sea la ubicación exacta para la pregunta.


Nos enfrentamos a un problema similar, necesitábamos acceder al hardware a través de nuestra plataforma en línea y mostrarlo en vivo, por lo que nuestra solución fue comprar un adaptador que proporcione ip al puerto de hardware para poder hablar con él usando node.js tal vez pueda encontrar una solución similar


Por tonto que parezca, ahora se está haciendo para varios dispositivos IOT. Pero en todos los casos que he visto, el dispositivo incluye una versión modificada del motor V8 JS. El teléfono Mozilla expone una interfaz de acceso HW, pero nuevamente no es realmente un controlador de dispositivo "real", sino más bien una API de esqueleto expuesta a JS.

Le insto a que aprenda Object Pascal o C / C ++, ya que son los únicos lenguajes "reales" adecuados para este tipo de trabajo. Tradicionalmente, C es el lenguaje más usado, pero C y Pascal son esencialmente la misma cosa con diferente sintaxis. C ++ Builder y Object Pascal incluso comparten el mismo código, con diferentes analizadores / lexer en la parte superior.

Dicho esto, no hay ninguna razón real por la que algunos controladores personalizados puedan codificarse en NodeJS. Bajo Linux, una gran cantidad de middleware HW se escribe primero en Python, y se finaliza en C. Así que todo es posible, siempre que alguien haya adaptado el tiempo de ejecución con respecto al acceso al hardware. FreePascal y Python facilitan el acceso a GPIO en la Raspberry PI 1-2. Pero no puede haber duda de que los lenguajes reales, como C / C ++ y Object Pascal tienen la ventaja.

Con significado "real" compilado a código de máquina para la plataforma, e irreal al referirse a motores de script como python y javascript.


Se puede utilizar cualquier idioma para escribir el controlador del dispositivo, siempre que se cumplan algunas condiciones:

  1. Memoria de acceso directo. Mira este código fuente:

https://patchwork.kernel.org/patch/8163061/

Como controlador de dispositivo, puede acceder directamente a la memoria virtual o física (en el caso de DMA) y, por lo tanto, es necesario omitir la configuración de la memoria virtual por la MMU. El acceso directo a la memoria virtual significa que conoce la dirección virtual y desea leer la dirección directamente.

Java o Javascript no tiene ninguna construcción de lenguaje para leer la memoria directamente a través de una dirección conocida.

  1. Tareas sensibles al lenguaje de ensamblaje: el acceso al hardware muy a menudo requiere instrucciones de ensamblaje especiales, como deshabilitar la interrupción, cambiar de una CPU a otra, o transmitir mensajes entre CPU, etc. No hay una estructura Java para hacer todo esto, tal vez ni siquiera C idioma. Por eso es que a menudo es necesario combinar el ensamblaje de C +. Pero no hay manera de combinar Java y ensamblaje.

  2. Idioma nativo frente a interpretado: todos los idiomas interpretados deberán pasar por un intérprete para ejecutar el idioma. En Javascript o Java, necesita JVM para ejecutar Java. Entonces, si necesita Java en el kernel, entonces necesitará un intérprete JVM en el kernel. Esto no es imposible: el kernel de Linux reciente tiene un intérprete BPF ejecutándose en el kernel, por lo que tiene una máquina virtual BPF ejecutándose en el kernel:

https://events.linuxfoundation.org/sites/events/files/slides/bpf_collabsummit_2015feb20.pdf

https://lwn.net/Articles/599755/

La idea de Java como controlador de dispositivo se ha implementado anteriormente, como un trabajo de investigación / proyecto (para el sistema operativo Sun Solaris):

http://dl.acm.org/citation.cfm?id=1215998

http://www.c0t0d0s0.org/archives/2587-Device-driver-in-Java.html

Pero no estoy seguro de cómo se resuelve el problema del acceso directo a la memoria.

Sin embargo, siempre es posible diseñar un sistema mediante el cual parte de las tareas pueda realizarlas un módulo de bajo nivel, que depende de C / Assembly, y otro componente que puede escribirse en un lenguaje que no sea C, como se muestra en este artículo reciente (Usenix 2009):

https://www.usenix.org/legacy/event/usenix09/tech/full_papers/renzelmann/renzelmann_html/

Vea el diagrama a continuación:

Haga clic para ver la imagen


Wow, esta idea no tiene sentido, en mi humilde opinión usted elige un lenguaje de programación para resolver un problema o tarea y no al revés. Trabajo con controladores de dispositivos y cosas relacionadas con el kernel del sistema operativo, pero solo porque puedo programar en CI, no uso C para realizar otras tareas como la administración de Linux para mi dispositivo integrado; en cambio, uso algo de alto nivel como Bash, Perl o Python (dependiendo de mi estado de ánimo :)).

¿Por qué estás interesado en js? En realidad, debe comprender los aspectos internos del lenguaje de programación para saber qué está tratando de lograr y también necesita saber cómo interactuará su programa con su sistema operativo para comunicarse con los registros e interrupciones del dispositivo, entre otras cosas.


Oh Dios mío. Escribiendo un driver en js ? ¿Por qué? Quiero decir, podrías escribir un contenedor de javascript para algo en C o C++ , tal vez, pero ¿por qué querrías hacer eso? Los controladores de dispositivos se comunican con la máquina a un nivel bastante bajo (nivel de hardware). Javascript no lo hace. Javascript es un lenguaje web (bueno, en su mayoría).

Como dijo Rich Bradshaw, es como usar una cuchara como una motosierra. Aunque para mí sería más como tratar de usar una canoa como tanque.