LINUX.ORG.RU

Varlink — интерфейс ядра

 varlink


1

1

Varlink – это интерфейс ядра и протокол, который удобен для чтения как людьми, так и машинами.

Интерфейс Varlink сочетает в себе классические параметры командной строки UNIX, текстовые форматы STDIN/OUT/ERROR, страницы справочного руководства, служебные метаданные и эквивалентен файловому дескриптору FD3. Varlink доступен из любой среды программирования.

Интерфейс Varlink определяет, какие методы будут реализованы и как. Каждый из методов имеет название и задаваемые параметры ввода и вывода.

Есть возможность документирования путем добавления комментариев перед документируемым куском кода.

В протоколе Varlink все сообщения кодируются как объекты JSON и заканчиваются байтом NUL.

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

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

>>> Больше подробностей об интерфейсе

anonymous

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

который удобен для чтения как людьми, так и машинами.

sexp?

UPD:

JSON
удобен для чтения людьми

ок

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

В протоколе Varlink все сообщения кодируются как объекты JSON и заканчиваются байтом NUL.

Т.е. нулевой байт по этому протоколу передать не получится?

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

Зато произвольные байты передать не получится, man unicode.

Ну, вернее, получится, если исхитриться и ввести специальную кодировку поверх юникода, кодируемого в ASCII. Мельком видел такое развлечение, когда хотели произвольные ответы веб-сервера пихать в ElasticSearch, но не хотели всё конвертировать в base64, потому что тогда не будет работать поиск. А с трюками и текст ищется, если он в ASCII или UTF-8, и все байты сохраняются точь в точь. Та ещё радость.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)

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

RiseOfDeath ★★★★
()
Последнее исправление: RiseOfDeath (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Принципиально-то получится - хоть base64, хоть тупой массив из байтов, хоть строка с escape-последовательностями. Эффективность, конечно, будет огорчать.

derlafff ★★★★★
()

Тыщу лет всё прогрессивное человечество пользуется IDL, но нет, смузихлёбам надо непременно всё в json завернуть.

LamerOk ★★★★★
()

К месту ли там JSON, если данные ведь в основном будут ходить бинарные?

EXL ★★★★★
()

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

i-rinat ★★★★★
()
# The current state of the FTL drive and the amount of
# fuel available to jump.
type DriveCondition (
  state: (idle, spooling, busy),
  tylium_level: int
)

# The galactic coordinates use the Sun as the origin.
# Galactic longitude is measured with primary direction
# from the Sun to the center of the galaxy in the galactic
# plane, while the galactic latitude measures the angle
# of the object above the galactic plane.
type Coordinate (
  longitude: float,
  latitude: float,
  distance: int
)

# Calculate the drive's jump parameters from the current
# position to the target position in the galaxy
method CalculateConfiguration(
  current: Coordinate,
  target: Coordinate
) -> (configuration: DriveConfiguration)

# Jump to the calculated point in space
method Jump(configuration: DriveConfiguration) -> ()

Примерно то же генерит haddock.

Crocodoom ★★★★★
()

Varlink – это интерфейс ядра и протокол, который удобен для чтения как людьми, так и машинами.

huh?! это в смысле зачем..? чтобы я что, напрямую с ядром мог общаться??? но зачем? пусть с ядром общаются программы, а я буду общаться с программами...

JSON

а ну дда, куда ж без этого...

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

{ «binary»: «\x00\x01\xFE\xFF» }

и главное, компактно! почти никаких накладных расходов!

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

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

по-моему я догадался... я сначала думал, это для kernel хакеров, но скорее всего наоборот, это для нового поколения redhat и systemd админов... хочешь новый сервис виртуализации и вот к нему готовый интерфейс.

crypt ★★★★★
()

А такое будет через .App работать?

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

Что бы core i9 в минималках хеллоуворлда перестал быть анекдотом.

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

вот к нему готовый интерфейс.

только «драйвер» к этому интерфейсу похоже еще не написан

anonymous
()

Чем оно лучше protobuf? И при чём тут ядро?

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

Есит сотни классных форматов сериализации.

https://en.m.wikipedia.org/wiki/Comparison_of_data-serialization_formats

Перечислено 35. Из них большая часть — или вариации на тему JSON и XML, или явно не имеют преимуществ перед JSON: YAML, CSV, p-list, OpenDDL, или плохо переносимы с воркэраундом в виде JSON/XML, как pickle.

Что из оставшегося удобнее JSON-а?

question4 ★★★★★
()

больше %уйни богу %уйни! Даешь SOAP в ядре

vasily_pupkin ★★★★★
()

все сообщения кодируются как объекты JSON

ну это жесть какая-то.

anonymous
()

6 абзацев шизофазии
Проверено: Shaman007

Лепота.

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

Удобнее JSONа практически всё, тот же XML можно хорошо приготовить (но не нужно). Из хороших практичных вариантов это protobuf с текстовым представлением на порядки читабельнее JSON-а. Или более лёгкие вариации TLV (tag-length-value, protbuf одна из его оптимальных форм) на бинарном уровне и аналог prototext-а для пользователя. Топик не нужен, это очередная хипстерская поделка недодизайнера.

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

Toml is a data serialisation language designed to be a minimal configuration file format that's easy to read due to obvious semantics. It is an alternative to YAML and JSON. It aims to be more human friendly than JSON and simpler that YAML. TOML is designed to map unambiguously to a hash table.

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

Зачем за нами? Присоединяйся, третьим будешь. :)

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

объясните виндонубу, зачем это нужно? )

Прост)

Tuxman
()

В таком виде описание этого интерфейса очень напоминает... sh. который также имеется в ядре.

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

Вот я тоже думал, что это за х#$я, зашел в репу, а там @kaysievers... ну, короче, все понятно, расходимся. Надеюсь, Линус еще не окончательно стал толерантным и инклюзивным, и прогонит его снова ссаными тряпками.

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

очередная приблуда для мамкиных веб-погромистов? догадываюсь откуда JSON (javascript) взялся.

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

догадываюсь откуда JSON (javascript) взялся.

Зачем догадываться, если я прямо написал: чтобы результаты класть в ElasticSearch. Возможно, он в каком-то другом виде умеет данные принимать, хранить и обрабатывать, но я не в курсе. Знаю, что он принимает POST-запросы с полезной нагрузкой в виде JSON. Мне говорили, что ему становится плохо, если JSON невалидный. А валидный JSON — в UTF-8.

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

Удобнее JSONа практически всё, тот же XML

А ты, затейливый!

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

Toml

Авторы несогласны :)

https://github.com/toml-lang/toml :

TOML ... is not intended for serializing arbitrary data structures
it doesn't permit top-level arrays or floats, so it cannot directly serialize some data.
There is also no standard identifying the start or end of a TOML file

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

Сколько я с ним работал — для статических конфигов не лучше и не хуже, чем JSON или YAML. Только парсер на Го подглючивает, не всегда читает конфиг до конца.

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

Удобнее JSONа практически всё, тот же XML можно хорошо приготовить (но не нужно).

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

protobuf с текстовым представлением
лёгкие вариации TLV ... и аналог prototext-а для пользователя.

Смотрю. Сериализация protobuf в человекочитаемые помимо XML есть?

question4 ★★★★★
()

Что это за хрень, интерфейс ведра для чего?

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

пусть с ядром общаются программы, а я буду общаться с программами...

А ты типа не программа? Ну ок, давай как будто мы поверили

af5 ★★★★★
()
Ответ на: комментарий от i-rinat

Стабильность!даже такая,плохая стабильность.

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

Как насчёт бинарных форматов? Которые и занимают меньше места при пересылке, и кодируются/раскодируются быстрее? И в которых тебе не обязательно раскодировать всё сообщение, чтобы получить только его часть?

theNamelessOne ★★★★★
()

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

У папуасов в треде тоже зачётно подгорает, однако.

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