LINUX.ORG.RU

В ядро NetBSD добавлена поддержка расширений на языке Lua

 ,


1

6

В состав ядра экспериментальной ветки NetBSD включена подсистема, добавляющая в ядро поддержку Lua. Разработка подсистемы под кодовым названием Lunatik была начата в 2010 году. Поддержка Lua в ядре позволит разрабатывать динамически загружаемые расширения, изменяющие поведение существующих систем или добавляющие новые возможности.

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

  • Планировщик процессов - позволяет пользователю задать свои собственные алгоритмы для управления выполняемыми задачами и для создания различных политик планирования для независимых наборов процессов или потоков.
  • Фильтр пакетов - позволяет создавать более гибкие правила для фильтрации сетевого трафика.
  • Управление питанием - позволяет пользователю задать свои методы управления энергопотреблением. Например, пользователь может определить собственный алгоритм для масштабирования частоты CPU и напряжения на нём для экономии электроэнергии или предотвращения перегрева.

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

>>> Подробности

★★★★

Проверено: Shaman007 ()
Последнее исправление: Valkeru (всего исправлений: 1)

Имхо, не такая уж и плохая идея. Только сегодня ковырялся с lua-модулями для nginx. Если использовать, как тут пишут, для нетребовательных к производительности задач (хотя LuaJIT, вроде как, довольно быстр) - вполне логично писать такие модули на простом и гибком языке. Плюс - меньше вероятность сделать что-то не так и все обрушить.

unikoid ★★★
()

О, круто! Пошёл обновлять ядро на утюге.

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

Что-ж, раз на то пошло, как скоро добавят туда C#, или JS в качестве альтернативы Lua ?

Сишарпу не впилась эта ваша BSD. :) У него есть Singularity.

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

Бинарник около 200К, а если генерить байт-код из исходников в юзерспейсе, то примено 40К

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

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

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

Мне кажется симптоматичным, что до сих пор у людей в голове есть странный ассоциативный ряд «скриптовый язык» -> «интерпретация» -> «низкая производительность».

Вот чувак написал драйвер сетевушки на Lua почти год назад:

http://blog.lukego.com//blog/2013/01/03/snabb-switchs-luajit-ethernet-device-...

И нормально, проблем с производительностью нет.

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

Вот и дожил до интерпретируемых языков в ядре -_-

Бобёр, выдыхай. Интерпретируемых языков не существует в природе.

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

Я собираюсь писать принципиально новое ядро на HTML, ибо ваш С устарел и процедурное программирование развивает шизофрению.

anonymous
()
Ответ на: комментарий от rtvd

А LuaJIT уже типа не Lua?

Думаю, встроить его в ядро будет намного проблематичнее, чем референсную реализацию

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

У меня есть модуль, который умеет исполнять схему в ядре линукса :)

Джоанна, ты?

Блядь, я здесь один не сижу на имиджбордах/где там у вас и не понимаю о ком речь?

Он про Рутковски вестимо. Не слышал правда, чтобы она схемкой упарывалась.

dukzcry
()
Ответ на: комментарий от rtvd

Мне кажется симптоматичным, что до сих пор у людей в голове есть странный ассоциативный ряд «скриптовый язык» -> «интерпретация» -> «низкая производительность».

на raspberry pi тормоза того же пистона видны невооружённым глазом.

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

₱ÿthóñΜüštĐïé

Ну так то питон. А что вы хотели от этого быдлоязычка?

anonymous
()
Ответ на: комментарий от Cancellor

Lua не в тренде, надо было жабаскрипт.

+1, вот было было бы самое правильно. А Lua маргинальщина.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от anonymous

Можно. Assembler. Правда для этого нужно быть очень бородатым программистом (иначе можно наоборот потерять производительность).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от anonymous

Это был такой намёк некоторых любителей писать «стало ещё быстрее в 100500 раз» в каждом релизе.

Deleted
()
Ответ на: комментарий от rtvd

А LuaJIT уже типа не Lua?

LuaJIT настолько же же Lua, насколько PyPy - Python. В любом случае, в ядро интегрирован обычный интерпретатор.

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

Это просто констатация факта. Обогнать сишку для ЯП типа «луа» и жабаскрипта невозможно вринципе, да даже догнать. Суть мейнстрим-ООП и слабой типизации противоречит возможности «догнать сишку».

Максимум, что можно выжать из них - писать как на сишке и надеятся, что жит сможет превратить это в сишку. А потом ещё и сконпелировать нормально.

anonymous
()
Ответ на: комментарий от KivApple

Нет. От гцц можно добиться практически идеального кодогена в 80% случаев. Правда для этого надо быть в двойне бородатым.

Ассемблер слишком гнилой язык, чтобы на нём писать. Так, максимум скролл-другой.

Пока реальных языков способных обогнать сишку нет. Я говорю про сишку в илитных руках и иной язык в тех же илитных руках.

А так обычная анскил-пародия на сишку сливается в хлам, как и i386-я породия на асм из бородатых, студенческих годов.

anonymous
()
Ответ на: комментарий от annulen

Хорошо написанный Lua работает практически со скоростью С

/me .oO( интересно, зачем делали LuaJIT? )

Чтобы работало со скоростью С-с-оптимизацией

А вот как выглядит «практически скорость Си»: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=g...

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

gcc тоже умет гадить лишними инструкциями в конечном варианте, которые на момент зачатия были не запланированы и это увы никакая оптимизация не выключает. А, нет, вру, -O немного корректирует положение и делает код таким, которым изначально был написан xd. А вообще из всех вариантов мнемоники ассемблеров для всех архитектур, самый человеко-подобный - это x86 ну и арм тоже более-менее можно прожевать. На самом деле, если не углубляться в самые низкие лвл процессора, на нем можно писать прекрасные программы, которые просто не могут тормозить, если конечно там не будет конструкция по типу: «0010: jmp 0010» :)

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

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

Просто одно дело, когда кодоген пишется, ибо лень писать битиками - это как тот же hex. Писать меньше, а профита от того ,что будешь юзать 0b нет.

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

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

anonymous
()
Ответ на: комментарий от Sharezil

Прекрасные программы можно писать на сишке. Ассемблер для х86 слишком гнилой. Если из х86 выкинуть это cisc( и всю гнилую прослойку) говно и запилить номальный risc-ассемблер, оформить его в виде си-функций и добавить к этому си-подобный макроязык - то да, это будет писабильно.

А так - писать на х86 ассемблере проще тормазящие говно, чем нормальный код.

Не углубляясь в лоулевел - можно писать разве что говно, которое сейчас и пишут сишники. Суть сишки - указатели, которые осилили нормально 3-5% сишников. Без указателей нет быстрого кода. Банальный тебе пример.

Сама сишка уже тоже протухла, писать сейчас реально только на gnuc99+.

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

И вот такие люди пишут стандарт, реализуют фичи, а потом пацаны хаят твою сишку.

anonymous
()
Ответ на: комментарий от aedeph_

Фортран сливает в говно. Единственно, что он научился быстро - это заменять код гореговноваятелей, аля for(i)for(j)for(k) на нормальные реализации - это умеет так же делать icc для сишки, возможно где-то хуже.

На обычном коде( который писал не тотальный идиот, который учил сишку на 1-м курсе недовуза) сольёт в говно, на обычно прикладном коде сольёт в тотальное говно.

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

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

for(i)for(j)for(k) никто давным давно не пишет, так как есть векторные операции. В отличии от сей с их ссанной дрочнёй вокруг указателей.

Ну и хотелось бы бенчмарков, а не анонимной аналитики уровня «сольёт в говно». На моей ограниченной практике ifort значительно превосходил icc.

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

Ну и хотелось бы бенчмарков, а не анонимной аналитики уровня «сольёт в говно».

Кхм. Ты, конечно, понимаешь, что разговариваешь с суперхаккиллером1997?

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

for(i)for(j)for(k)

Все пишут. У тебя есть 2 пути - этот, либо указатели. Хотя один хрен это говно конпелятор перепишет за тебя на указатели.

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

От тебя я тоже пруфцов не видел, кстати.

anonymous
()
Ответ на: комментарий от tailgunner

Ты что-то имеешь против или сомневаешься в моём скилле? Я уж не помню, обежал я тебя или нет.

anonymous
()

Надо было встраивать js, или хотя бы php.

Vit ★★★★★
()

А само ядро теперь перепишут на PHP?

Lavos ★★★★★
()

Офигенно, я считаю! Вот бы в линукс такое добавили, только на javascript, конечно, lua — это несуразность какая-то.

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

только на javascript

Это же тормоза сплошные. Ничего не знаю про lua, но слышал что js-обекты являются сплош текстовыми массивами. Получается работа интерпритатора это сплошной парсинг. Итого: парсинг исходного скрипта+парсинг объектов. Дважды интерпритация. Точнее в квадрате, наверное. Не пинайте, если что-то понял не так.

Csandriel
()
Ответ на: комментарий от tailgunner

LuaJIT настолько же же Lua, насколько PyPy - Python.

LuaJIT - нормальная реализация Lua. Интерпретатор считается нормальным только у окодемигов, вечно считающих факториалы.

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

Весьма прискорбно.

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

Думаю, встроить его в ядро будет намного проблематичнее, чем референсную реализацию

Возможно. Но референсную реализацию встраивать - бессмысленно.

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

А вот как выглядит «практически скорость Си»: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=g...

Это сравнение кода на C и интерпретатора Lua или LuaJIT?

P.S. само соревнование - мягко говоря низкокачественное. Там море кода нарушает правила и организаторы забили на это болт.

rtvd ★★★★★
()

Здорово. Это пригодится для нашего полностью свободного смартфончика на NetBSD с облачной синхронизацией и распознаванием рукописных/голосовых сообщений, который будет создан в течение ближайших 20 лет.

anonymous
()
Ответ на: комментарий от special-k

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.