LINUX.ORG.RU

Lunatik v3.6 — релиз среды исполнения Lua в пространстве ядра Linux

 , , , ,

Lunatik v3.6 — релиз среды исполнения Lua в пространстве ядра Linux

0

4

Lunatik — это фреймворк для написания сценариев для ядра Linux на Lua. Разрабатывается LabLua в рамках Lua in kernel с явными ссылками на опыт использования Lua в ядре NetBSD.

Основные компоненты

  • интерпретатор Lua, модифицированный для работы в ядре;
  • драйвера устройства (написаны на Lua);
  • средства командной строки для запуска сценариев и управления средами выполнения из пользовательского пространства;
  • C API для загрузки и запуска сценариев и управления средами выполнения из ядра;
  • Lua API для привязки средств ядра к Lua-скриптам.

Новые возможности


Группа разработчиков Lunatik выражает благодарность контрибуторам, благодаря которым стал возможен этот релиз: sav и marcelstanley из Ring-0 Networks, sheharyaar, jperon, vincentmli, rustedusted, glk0, ну и конечно же всем другим участникам, работающими над Lunatik.

Пример драйвера устройства для генерации простых «паролей»

-- /lib/modules/lua/passwd.lua
--
-- implements /dev/passwd for generate passwords
-- usage: $ sudo lunatik run passwd
--        $ head -c <width> /dev/passwd

local device = require("device")
local linux  = require("linux")

local function nop() end -- do nothing

local s = linux.stat
local driver = {name = "passwd", open = nop, release = nop, mode = s.IRUGO}

function driver:read() -- read(2) callback
	-- generate random ASCII printable characters
	return string.char(linux.random(32, 126))
end

-- creates a new character device
device.new(driver)

>>> Исходный код релиза

>>> Документация, исходный код и примеры проекта

>>> Сопутствующие проекты

>>> Анонс в официальной группе Lua

★★★★★

Проверено: CrX ()
Последнее исправление: hobbit (всего исправлений: 9)
Ответ на: комментарий от ya-betmen

Нет конечно. И это не нужно. Лунатик сам по себе. Кому надо накатят, кому не надо знать про него не будут и никогда оно им не помешает. Lua встраиваясь в любую кодобазу не требует к себе никакого особого отношения, Lua подстраивается под ПО в которое её встраивают, а не наоборот. Да и решаемый класс задач у лунатика не широкий, количество привязок к ядерным интерфейсам небольшое.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от mord0d

numpy так то на фортран77.

думаю внушительная часть и фортран66 сработает. 90й то с си сравним по скорости а эти еще проще.

Slackware_user ★★★★★
()
Ответ на: комментарий от zabbal

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

Slackware_user ★★★★★
()
Ответ на: комментарий от LightDiver

Если я правильно понял задачу, то разницы при самой пересборке быть не должно. Все строковые значения в Lua хранятся как ссылки на реальные строки в пуле. И в локальной переменной, и в массиве, и в хеш-части таблицы.

Но вот каждая такая пересборка - это пересчет хеша всей новой строки, причем сначала для каждой вырезанной подстроки, а затем еще после каждой конкатенации. Итого - невероятно медленная операция.

Заодно по другому сообщениям отвечу.

Абсолютная каждая таблица Lua всегда имеет и часть «массив», и часть «хаш-таблица». Оно не переделывает одно в другое, просто эти части есть одновременно. А записать nil в таблицу нельзя, потому что это не значение, а указание что значения нет. Т.е. присвоение nil элементу таблицы это удаление этого элемента из таблицы. Если очень хочется, то можно схитрить, и использовать NaN в качестве своего индикатора NULL. Тогда не будет возникать дыр в массиве.

local NULL = 0/0

local function is_null(value)
  return value ~= value
end

local t = { 1, NULL, 3 }
print(is_null(t[1]))
print(is_null(t[2]))
Playermet
()
Ответ на: комментарий от bender

дык луа — нормальный язык без извратов вроде ненужных АТД, с исключениями и без необходимости в каждой строчке управлять памятью

rsync ★★
()
Ответ на: комментарий от Android

rust — язык сектантов, а сектантам не место в серьёзных проектах

rsync ★★
()
Ответ на: комментарий от Playermet

Это сработает, если записывать в отдельный элемент массива, а мне так нельзя. Ограничение на общее количество элементов массива.. Но идея очень интересная, спасибо, я записал.

Ну и по тестам, с точки зрения памяти этот вариант идентичен трем символам. Или цифре. Такое ощущение, что контент вообще игнорируется - главное созданная структура.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 4)
Ответ на: комментарий от Slackware_user

скриптинг для не очень быстрой по скорости проца но быстрой по скорости написания обработки пакетов

Ты про nftables?

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

В ядре нужно писать скрипты? Зачем?

Хороший вопрос.

Презентация 2012 года Lua in the NetBSD Kernel от Mark Balmer.

  • New Lua states are created empty
  • Full control over the loading of code
  • No access to kernel memory, -functions but through predefined bindings.

Вывод: Программирование для ядра становится похожим на програмирование приложений, нет доступа ко всей памяти.

Фактически из Монолитного ядра получается Микроядро. В чем суть Микроядра? В том, что из одного процесса где каждая функция имеет абсолютные полномочия, ядро разбиваются на иерархию модулей с различными уровнями полномочий.

Тот же самы процесс достигается при добавление Lua в ядро. Только роль процессов выполняют Lua States (page 24).

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

нет доступа ко всей памяти

Так его и у eBPF программ нет. При этом никаких ограничений на то, из чего именно eBPF код скомпилирован не накладывается - пиши хоть на Хаскеле, хоть на Lua. На кой фик тащить в ядро ещё один интерпретатор?

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

На кой фик тащить в ядро ещё один интерпретатор?

Что я вам могу на этот вопрос ответить? Можно решить вопрос так, можно решить вопрос эдак. В Linux сделали eBPF, в NetBSD сделали через Lua.

Опять возвращаемся к первому сообщению:

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

В NetBSD взяли и встроили в С программу интерпретатор Lua. Без оверинжинирина. Без прописывания дополнительных интерфейсов, взяли уже готовые Lua Bindings.

Плюсы: Быстрей реализовать.
Минусы: Ограничевает выбор языков одним Lua.

По поводу Lunatik/eBPF я не разбирался в плюсах и минусах этих решений.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от zabbal

На кой фик тащить в ядро ещё один интерпретатор?

Вот вы задаете такой странный вопрос: «Нафига еще одно техническое решение?». У каждого программиста есть свой опыт и предпочтения. Когда встает практическая задача, он изучает все предлагаемые технические решения и выбирает то, которое ему кажется более подходящим.

Оно не обязательно будет более технически оптимальным. Поэтому существуют различные фреймворки, позволяющие писать GUI веб-приложения на Ruby, Python, Go и так далее без JavaScript. Например, кто-то привык писать на Python, и если ему понадобилось веб-приложение, он соберет его через прослойку. Это может быть не совсем оптимально, но задача будет решена.

Кому-то легче одной коммандой установить фреймворк и начать разрабатывать модуль на Lua, не вникая в детали более мощного инструмента.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

Кому-то легче одной коммандой установить фреймворк и начать разрабатывать модуль на Lua

Сферическому программисту в вакууме - наверняка. Но если посмотреть на общую картину, то выбирать лучше то решение, которое можно будет поддерживать годами без геморроя. В ядре уже есть eBPF и Rust, и даже их туда втаскивали с большим скрипом не один год.

Удастся-ли туда пропихнуть ещё один гибрид ежа с ужом просто потому что у кого-то такие предпочтения - очень большой вопрос. Я бы поставил на то, что нет.

То есть если делать на этом решение это практически гарантирует геморрой с поддержкой, который рано или поздно приведёт к тому что очередной менеджер прикинет дебет с кредитом, наймёт пачку аутсорсеров с ChatGPT и скомандует «перепишите это говно на что-нибудь нормальное».

Вместо этого можно скипнуть промежуточные шаги и сразу сделать нормально.

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

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

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

Вместо этого можно скипнуть промежуточные шаги и сразу сделать нормально.

Ага. Выучить Rust и сделать «правильно».

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

Выучить Rust и сделать «правильно».

Например. Хотя если с обучением современным языкам проблемы, то можно сделать компилятор Lua в eBPF и писать как привыкли.

zabbal ★★★★★
()
Ответ на: комментарий от lbvf50txt

для демонстрационного стенда на выставке надо за несколько часов написать драйвер

Вообще выставки редко случаются с анонсом за 24 часа - можно освоить сложнейшее искуство «не делать всё в последний момент». Но вообще один из ключевых разрабов ядра именно что предлагает писать все новые драйверы именно что на Rust - https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/

zabbal ★★★★★
()
Ответ на: комментарий от zabbal

то можно сделать компилятор Lua в eBPF и писать как привыкли.

Можно. Можно просто на Си написать. А можно взять уже готовый фреймворк под интерпретируемый язык выского уровня.

lbvf50txt
()
Ответ на: комментарий от zabbal

Вообще выставки редко случаются с анонсом за 24 часа - можно освоить сложнейшее искуство «не делать всё в последний момент».

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

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

Эти рассказы о том, что «надо писать правильно», — это форумное теоретизирование. В определённых обстоятельствах нужно писать «правильно», а в других — так, чтобы скорее заработало.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от zabbal

как пример.

какая-нибудь логика поверх них и управления соединениями например

Slackware_user ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.