Объясните теорию про сетевые интерфейсы.

потому-что в Linux все сущности == файлы.

Злобное 4.2 ☺ Ты путаешь с планом.

Ну а eth0 это не сущность, а среда передачи

Мюсьё забыл о пайпах, которые преспокойно живут в файловой системе?

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

Это специфика интерпретируемого языка в общем?

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

Тоже надо было бы иметь описание формата для разных версий ядра, которые или те же системные хедеры должны описывать, или вообще каждое приложение с собой таскать.

Формат файлов в /sys и /proc не меняется. Во всяком случае так говорит Линус.

интересен вариант с общей шиной типа (k)dbus

Да, это действительно решило бы многие проблемы.

на разных платформах системные вызовы имеют разные номера.

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

http://slashnet.wordpress.com/

Ну и план9 во все дыры.

Проблема в том что вроде как скрипты должны быть кроссплатформенны

Точно не в случае использования сисколлов / платформенных вещей :) А на BSD как запускать? Или совсем на Haiku / Plan9 / ...? :) Даже с С применять лучше функции libc, входящие в стандарт С или POSIX, а не brk вместо malloc и clone вместо fork. Конечно, если linux-only по уши, то и ладно, но вон можно почитать отзывы анонимных аналитиков о Леннартовском мнении насчет POSIX :)

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

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

Формат файлов в /sys и /proc не меняется. Во всяком случае так говорит Линус.

Это о стабильном ABI (не API) или о «we don't break userspace!!1» ? К первому эти файлы вроде не относятся, второе — а изменения связанные с наращиванием функциональности как будут вносится? Не */wifi_scan, */wifi_scan_new же. Или кто виноват, если юзерспейсная софтина сломается от добавления строки в такой файл?

Даже с С применять лучше функции libc

У libc нет функций для работы с тем же wifi, например. И много к чему нет интерфейсов. Приходится вот ioctl дёргать. Конечно я не делаю sbrk (, но пытался :))

если linux-only по уши

Да, пока linux-only. Я решил что глупо сразу писать переносимый софт (спорное мнение, многие не одобрят, знаю). Лучше написать хорошую софтину под линукс и, если взлетит и кому-то будет нужно, портировать под другие платформы чем сразу писать под то на чём использоваться скорее всего не будет.

Леннартовском мнении насчет POSIX

Это где он пишет что Linux это новый POSIX?

К первому эти файлы вроде не относятся

Он сказал что относятся.

Не */wifi_scan, */wifi_scan_new же

А там делают так - один файл — одна функция. Поэтому для наращивания функционала может быть и wifi_scan и wifi_scan_2 . По-моему, в ядре есть опции типа «включить устервшие файла /proc и /sys». И для некоторых подсистем типа scsi подобные галки есть.

У libc нет функций для работы с тем же wifi, например. И много к чему нет интерфейсов. Приходится вот ioctl дёргать.

ioctl таки в POSIX, то есть ~кроссплатформенный сам по себе. Но если нужно wpa_supplicant реимплементить, да еще и кроссплатформенно, то задача конечно незавидная :) Хотя в данном случае и ненужная, он уже BSD.

если взлетит и кому-то будет нужно, портировать под другие платформы

Это надо еще чтобы те, кому нужно, а) нашли этот продукт, сидя под другой осью; б) решились / нашли смысл об этом сказать.

Это где он пишет что Linux это новый POSIX?

Ага, и еще «BSD Isn't Relevant Anymore»

Он сказал что относятся.

Текстовые файлы в /proc и /sys — ABI? Ссылки под рукой случайно нет? В документации ядра вроде только специфичные вещи, если по имени файла смотреть.

А там делают так - один файл — одна функция.

Ну гм, /proc/net/dev, /proc/interrupts или пусть даже /proc/meminfo — гранулярность не очень мала, имхо.

ioctl таки в POSIX

Сам ioctl да, как и некоторые вещи относящиеся, например, к управлению терминала. А вот управление другими девайсами драйвероспецифично. Да и вообще оси друг от друга чертовски отличаются в деталях. Если уж файловые операции операции работают по-разному, то что уж говорить об остальном. Поэтому считаю кросплатформенность мифом. Есть даже целые руководства как писать портабельный код, но после прочтения таких мануалов оказывается что можно использовать лишь совершенно небольшую часть возможностей ОС стандартизированных 20-30 лет назад (либо юзать спецбиблиотеки-прослойки). Нафига тогда десятки лет эволюции?

Я поэтому забил на кросс-платформенность — если нужно будет то лучше отдельно допилю код и напишу отдельные тесты.

те, кому нужно, а) нашли этот продукт, сидя под другой осью; б) решились / нашли смысл об этом сказать.

Кмк, у тех кто сидит под маргинальными осями руки должны быть очень прямыми и работящими. Поэтому не вижу проблем.

Ага, и еще «BSD Isn't Relevant Anymore»

Для большинства так оно и есть. Наверно, не стоит говорить за всех...

Ссылки под рукой случайно нет?

Такое прокатит? http://thread.gmane.org/gmane.linux.kernel/1063039/focus=1065522

Я ещё видел как он откатывал изменения если кто-то сообщал что какая-то софтина сломалась, даже если эта софтина была одна, маленькая, «ненужная» и вообще было проще поправить софтину, а не ядро. Ссылки не дам :).

гранулярность не очень мала, имхо.

так то /proc, устаревший интерфейс. Нынче модно такие вещи в /sys хранить.

Поэтому считаю кросплатформенность мифом.

Для конкретной задачи она часто вполне реальна. Мне тот же wpa_supplicant нравится в этом смысле. Сам собирать под разные ОС не пробовал, но заявленная поддержка впечатляет. И без autotools всяких.

И он не такое уж исключение среди (свободного && не веб) софта.

Кмк, у тех кто сидит под маргинальными осями руки должны быть очень прямыми и работящими. Поэтому не вижу проблем.

Это не к рукам, это а) просто удача, найти именно эту программу; б) оптимистичная оценка перспектив. /me бы в подобной ситуации совсем не факт что стал бы связываться с автором, просто из пессимизма :)

Для большинства так оно и есть. Наверно, не стоит говорить за всех...

Ну не в теме кроссплатформенности же. Тем более мой смысл изначально был в том, что стоит просто это учитывать, народные волнения в т.ч. :)

Если в общем, то одно дело, мне кажется, не использовать ту же BSD лично, а другое — принимать участие в становлении Ein Fuehrer, Ein Reich. Но это глубоко идеологический вопрос, да.

Такое прокатит? http://thread.gmane.org/gmane.linux.kernel/1063039/focus=1065522

Это чуть другое, я его отдельно выносил. Вопрос был являются ли такие вещи ABI. Но неважно. Дзен хорош :)

Я ещё видел как он откатывал изменения если кто-то сообщал что какая-то софтина сломалась

Думаю это всё же не абсолютное правило, но контрпримеров нет. memcpy это вроде в glibc меняли, когда flash отвалился.

Мне тот же wpa_supplicant нравится в этом смысле

Согласен, побольше бы таких примеров.

/me бы в подобной ситуации совсем не факт что стал бы связываться с автором

Можно для начала просто форкнуть и допилить самому :).

стоит просто это учитывать, народные волнения в т.ч. :)

А как это учтёшь? Даже два человека зачастую не могут договориться, а тут различные ОС с десятками тысяч разработчиков.

memcpy это вроде в glibc меняли, когда flash отвалился.

Там поменялся undefined behavior (UB). У меня мнение однозначное по этому вопросу — нельзя на такое закладываться когда есть более прямые пути решения. Я бы вообще причислил UB == never use.

Потому что прикостыляли потом

Мюсьё забыл о пайпах, которые преспокойно живут в файловой системе?

(unnamed)pipe это файлы. Да, особые, но таки файлы.

Злобное 4.2 ☺ Ты путаешь с планом.

я ничего не путаю. Это ты путаешь.

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

это и не_нужно «исправлять». В Linux всё правильно сделано. Просто ты не правильно понимаешь концепцию GNU/Linux. И твой мертворождённый план9 тоже.

ioctl таки в POSIX

POSIX тоже не нужно

Альтернативы? Или кроссплатформенность (пусть и несовершенная) не нужна тоже?

Можно для начала просто форкнуть и допилить самому :)

Технически оно-то можно, а практически когда в todo месяцами висит десяток подобных задач, поменьше объемом... тут и заскучаешь :)

А как это учтёшь? Даже два человека зачастую не могут договориться, а тут различные ОС с десятками тысяч разработчиков.

Да в среднем по больнице. Unix-way, отсутствие монолитности, человекочитаемые форматы данных, кроссплатформенность, высокая скорость работы плюс малый объем кода / зависимостей и т.п. — известные плюшки. Ругать конечно всегда найдут за что, но ругань ругани рознь имхо.

Там поменялся undefined behavior (UB).

Помню, но было бы это ядро — была бы та же ситуация, сломали юзерспейс.

Да в среднем по больнице. Unix-way, отсутствие монолитности, человекочитаемые форматы данных, кроссплатформенность, высокая скорость работы плюс малый объем кода / зависимостей и т.п.

Так это же не стандарты, это рекомендации. Впрочем, можно попытаться обсудить минимальный management layer. Типа, стандартные интерфейсы для управления сетевыми интерфейсами итп.

было бы это ядро — была бы та же ситуация, сломали юзерспейс.

Тогда бы точно реверснули обратно, Торвальдс как раз об этом и вещал. У него, правда, была несколько другая позиция, аля «раздули из мухи слона, замените memcpy на memmove и не парьте людям мозги».

Альтернативы? Или кроссплатформенность (пусть и несовершенная) не нужна тоже?

аватарки включи

Так это же не стандарты, это рекомендации.

Угу. POSIX — стандарт, придерживаться его — рекомендация. А критикам будет всё едино. В общем, неважно. Мой исходный посыл был к тому, что игнорировать ясно дело можно, когда нужно, просто желательно иметь чем отбиваться. Тот же Поттеринг мог просто сказать, что пишет init только для Linux, и больше ничего не объяснять — право имеет же. А пассажи про новые стандарты и ненужные ОС имхо только хуже делают.

Впрочем, можно попытаться обсудить минимальный management layer. Типа, стандартные интерфейсы для управления сетевыми интерфейсами итп.

Теоретизируя что было бы лучше в апстриме, или для конкретной задачи? Оба варианта дело не всегда благодарное :)

Тогда бы точно реверснули обратно, Торвальдс как раз об этом и вещал.

Одна проприетарная программа, положившаяся на undefined behaviour... Было бы удручающе, по-моему.

Включены. Намек вроде понял, больше не буду.