Здравствуйте, kaa.python, Вы писали:

KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:

KP>

KP>
• Высокая скорость работы;
  KP>
• Возможность переопределить функции работы с памятью;
  KP>
• Возможность вызывать нативные функции из виртуальной машины;
  KP>
• Чистый Си без каких-либо внешних зависимостей;
  KP>
• Хотя бы минимальные проверки обрабатываемых инструкций на безопасность;
  KP>
• Как можно меньший размер.
  KP>

KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.

Lua?

Здравствуйте, kaa.python, Вы писали:

KP>Язык уже есть, так что нужна RISC, CISC или стековая машина с простым и понятным набором инструкций.

Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?
Попробуй копать в сторону Forth, простую форт машину, даже кроссплатформенную, на шитом коде, несложно сделать.

Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:

• Высокая скорость работы;
  
• Возможность переопределить функции работы с памятью;
  
• Возможность вызывать нативные функции из виртуальной машины;
  
• Чистый Си без каких-либо внешних зависимостей;
  
• Хотя бы минимальные проверки обрабатываемых инструкций на безопасность;
  
• Как можно меньший размер.

А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.

Здравствуйте, dmikos, Вы писали:

D>Lua?

Хотелось бы именно виртуальную машину, а не интерпретатор.

Здравствуйте, kaa.python, Вы писали:

KP>Хотелось бы именно виртуальную машину, а не интерпретатор.

Посмотри NekoVM.
Я сам правда ее только мельком видел, так что возможно и не совсем то что нужно, но штука очень легкая.

Здравствуйте, kaa.python, Вы писали:

KP>Хотелось бы именно виртуальную машину, а не интерпретатор.

Еще очень легкая виртуальная машина у Caml Light, но получится ли это всунуть в
драйвер не знаю, ну и целевой ML образный язык тоже может не понравится.

Здравствуйте, kaa.python, Вы писали:

KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:

KP>

KP>
• Высокая скорость работы;
  KP>
• Возможность переопределить функции работы с памятью;
  KP>
• Возможность вызывать нативные функции из виртуальной машины;
  KP>
• Чистый Си без каких-либо внешних зависимостей;
  KP>
• Хотя бы минимальные проверки обрабатываемых инструкций на безопасность;
  KP>
• Как можно меньший размер.
  KP>

KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.
А LLVM не устраивает только по размеру или еще по чему нибудь?

Здравствуйте, kaa.python, Вы писали:

KP>Ничего не могу найти, удовлетворяющее моим требованиям. Итак, что хотелось бы:

KP>

KP>
• Высокая скорость работы;
  KP>
• Возможность переопределить функции работы с памятью;
  KP>
• Возможность вызывать нативные функции из виртуальной машины;
  KP>
• Чистый Си без каких-либо внешних зависимостей;
  KP>
• Хотя бы минимальные проверки обрабатываемых инструкций на безопасность;
  KP>
• Как можно меньший размер.
  KP>

KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.

http://sourceforge.net/projects/obasic/

KP>А нужно все это безобразие для безболезненного встраивания машины в код драйвера. Пока что остановился на варианте "выдрать и доработать машину из DTrace", но может есть более простой путь, а я о нем просто не знаю.

Пока не до читал до драйвера почему-то подумал что тебе нужно что-то типа qemu )))). Но таки, почему бы и не заюзать что нить типа MIPS симулятора? Их много, твоим требованиям такой финт ушами вроде отвечает. Да и код для VM можно компилировать штатным компилятором.

Здравствуйте, denisko, Вы писали:

D>А LLVM не устраивает только по размеру или еще по чему нибудь?

Я думал о LLVM, но сам LLVM в ядро не затащить. А собирать машинный код в UserSpace а потом заниматься ручной загрузкой на уровне ядра мне не хочется.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Пока не до читал до драйвера почему-то подумал что тебе нужно что-то типа qemu )))). Но таки, почему бы и не заюзать что нить типа MIPS симулятора? Их много, твоим требованиям такой финт ушами вроде отвечает. Да и код для VM можно компилировать штатным компилятором.

Да мне нужно что-то совсем мелкое и легкое. Задача довольно проста — есть код обрабатывающий определенные события написанный на специальном языке. Надо это дело оттранслировать в промежуточную форму (интерпретировать в ядре, все же, более опасно) и выполнить это дело.

Здравствуйте, FR, Вы писали:

FR>Еще очень легкая виртуальная машина у Caml Light, но получится ли это всунуть в
FR>драйвер не знаю, ну и целевой ML образный язык тоже может не понравится.

Язык уже есть, так что нужна RISC, CISC или стековая машина с простым и понятным набором инструкций.

Здравствуйте, FR, Вы писали:

FR>Посмотри NekoVM.
FR>Я сам правда ее только мельком видел, так что возможно и не совсем то что нужно, но штука очень легкая.

Похоже что тоже не то. Странно, но видимо у меня совсем уж уникальная хотелка

Здравствуйте, FR, Вы писали:

FR>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?

Шило на мыло — это что в сравнении с чем?

FR>Попробуй копать в сторону Forth, простую форт машину, даже кроссплатформенную, на шитом коде, несложно сделать.

Да простую RISC машину тоже очень легко сделать, там же команд раз-два и обчелся. Просто думал может уже что-то готовое есть.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, FR, Вы писали:

FR>>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?

KP>Шило на мыло — это что в сравнении с чем?

По сравнению с интепретаторами. Может, просто tinytcl допилить и всосать?

Здравствуйте, denisko, Вы писали:

KP>>Шило на мыло — это что в сравнении с чем?
D>По сравнению с интепретаторами. Может, просто tinytcl допилить и всосать?

Основной минус интерпретаторов — они задают определенный синтаксис языка. Будь то TCL, будь то ML или еще что-то. Кроме того, они усложняют проверку на потенциальные ошибки в коде за счет более сложных операций. Поэтому, мне бы хотелось именно чистую (или как ее еще назвать) виртуальную машину.

Здравствуйте, kaa.python, Вы писали:

FR>>Я понял что нужна более высокоуровневая VM, а так получается же шило на мыло, или нужна кроссплатформенность?

KP>Шило на мыло — это что в сравнении с чем?

По сравнению с высокоуровневыми ВМ, если нет требований кроссплатформенности,
то по моему вместо низкоуровневых проще сразу грузить целевой машинный код,
который для верификации компилировать в песочницу например типа гугловского
Native Client.

При таком подходе сразу встает следующий вопрос. Как скомпилировать некую пользовательскую функцию в целевой машинный код и без особо серьезных приседаний вызвать ее в требуемом месте?
Например, у нас есть заданная пользователем функция:

int foo(int a, int b)
{
    return a+b;
}

Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?

Здравствуйте, kaa.python, Вы писали:

KP>Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?

Т.е. задача — выполнять в ядре пользовательский код? Мсье понимает...

Здравствуйте, kaa.python, Вы писали:

KP>Да, я могу ее собрать при помощи LLVM и даже выполнить. Остается самая малость — как передать эту фунцию в виде целевого машинного кода в другой процесс и выполнить уже там?

Такую простую функцию, без внешних зависимостей легко, компилируем как position-independent code (-fPIC) в
память, тот же clang должен это уметь.
Вот зависимости да придется как-то разруливать в динамике.
Проще по моему не использовать отдельные функции, а грузить готовые пакеты/модули/плагины тот же
Native Client всю необходимую инфраструктуру представляет.

Здравствуйте, FR, Вы писали:

FR>Вот зависимости да придется как-то разруливать в динамике.

Само собой, зависимости будут, так что все сложнее.

FR>Проще по моему не использовать отдельные функции, а грузить готовые пакеты/модули/плагины тот же
FR>Native Client всю необходимую инфраструктуру представляет.

При передаче готовых пакетов выходит потенциально охрененно огромная дыра — возможность передать левый пакет и выполнить его в ядре. Т.е. все же я хотел бы решить задачу именно в рамках виртуальной машины.

Здравствуйте, kaa.python, Вы писали:

FR>>Вот зависимости да придется как-то разруливать в динамике.

KP>Само собой, зависимости будут, так что все сложнее.

В низкоуровневых VM это тоже придется разруливать.

KP>При передаче готовых пакетов выходит потенциально охрененно огромная дыра — возможность передать левый пакет и выполнить его в ядре. Т.е. все же я хотел бы решить задачу именно в рамках виртуальной машины.

Так песочница и валидация, смотри тот же Native Client

Здравствуйте, kaa.python, Вы писали:

D>>Lua?

KP>Хотелось бы именно виртуальную машину, а не интерпретатор.

не так давно на этом форуме (рсдн) обсуждали луа\яваскрипт в эпическом треде, рекомендую еще разок просмотреть
в частности, если не ошибаюсь, там приводились положительные качества луа: маленький размер, возможность кастрировать\допиливать, голый си и тд
там внутри есть виртуальная машина, ее можно попытаться вытащить\заюзать
вики: http://en.wikipedia.org/wiki/Lua_(programming_language)
зы. сам с луа не работал =\

успехов

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>Пока не до читал до драйвера почему-то подумал что тебе нужно что-то типа qemu )))). Но таки, почему бы и не заюзать что нить типа MIPS симулятора? Их много, твоим требованиям такой финт ушами вроде отвечает. Да и код для VM можно компилировать штатным компилятором.

KP>Да мне нужно что-то совсем мелкое и легкое. Задача довольно проста — есть код обрабатывающий определенные события написанный на специальном языке. Надо это дело оттранслировать в промежуточную форму (интерпретировать в ядре, все же, более опасно) и выполнить это дело.

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

Здравствуйте, sts, Вы писали:

sts>Вообще, конечно, так делать не стоит.

К сожалению, иногда это единственный приемлемый по скорости работы вариант.

sts>Нужен отдельный процесс в юзер-спэйсе который когда нужно обращается к драйверу для выполнение специфичных заранее определенных функций.

Да, но это сильно зависит от частоты необходимых обращений. Ну и ряда других специфичных моментов.

Здравствуйте, kaa.python, Вы писали:

KP>Да, но это сильно зависит от частоты необходимых обращений. Ну и ряда других специфичных моментов.
Ну тогда может посмотреть на "компиляцию и валидацию" ?, шустрая, мелкая и вылизанная до работы в режиме ядра ВМ звучит довольно фантастично.

Здравствуйте, denisko, Вы писали:

D>Ну тогда может посмотреть на "компиляцию и валидацию" ?, шустрая, мелкая и вылизанная до работы в режиме ядра ВМ звучит довольно фантастично.

Ну почему-же? Машина из DTrace умещается в паре тройки сишных файлов, делает почти все, что мне нужно и при этом очень простая внутри. Собственно я к своей изначальной идее взять машину из DTrace и допилить и вернулся.