The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Комментарии разработчиков udev по поводу очередного форка пр..., opennews (??), 19-Ноя-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


9. "Комментарии разработчиков udev по поводу очередного форка пр..."  +6 +/
Сообщение от Аноним (-), 19-Ноя-12, 21:29 
> поэтому зависимость от kmod как раз изчезает.

И правда - ну его нафиг выносить повторный код в шаред либ. Давайте лучше таскать redundant-код по куче бинарников.

Ответить | Правка | Наверх | Cообщить модератору

32. "Комментарии разработчиков udev по поводу очередного форка пр..."  +1 +/
Сообщение от anonymous (??), 19-Ноя-12, 22:25 
>И правда - ну его нафиг выносить повторный код в шаред либ. Давайте лучше таскать redundant-код по куче бинарников.

А его и так таскать. Или ты собрался грузить модули только через udev?

Ответить | Правка | Наверх | Cообщить модератору

105. "Комментарии разработчиков udev по поводу очередного форка пр..."  +/
Сообщение от Аноним (-), 20-Ноя-12, 09:24 
> А его и так таскать. Или ты собрался грузить модули только через udev?

Я почему-то думал что сарказм в том постинге просматривается и без тегов, при том судя по реакции народ его вполне разглядел. В отличие от вас :)

Ответить | Правка | Наверх | Cообщить модератору

107. "Комментарии разработчиков udev по поводу очередного форка пр..."  +/
Сообщение от Аноним (-), 20-Ноя-12, 09:29 
> А его и так таскать. Или ты собрался грузить модули только через udev?

Одно дело если все утили имеющие дело с вгрузкой модулей дернут либу "а загрузи ка нам модуль" и другое - если весь код этой либы будет вкорячен в каждый такой бинарь. Поэтому лучше уж этот функционал 1 раз в libkmod чем ...цать раз раскиданный по всем бинарникам, в каждом из которых будет жить по сути весь код libkmod, что как бы маразм.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

118. "Комментарии разработчиков udev по поводу очередного форка пр..."  –3 +/
Сообщение от Аноним (-), 20-Ноя-12, 09:55 
wut? Каждая утилита/бинарник, дергающий fork+exec для modprobe должна вкомпилить этот modprobe в себя? Вы что-то не понимаете.
Ответить | Правка | Наверх | Cообщить модератору

120. "Комментарии разработчиков udev по поводу очередного форка пр..."  –1 +/
Сообщение от Аноним (-), 20-Ноя-12, 09:58 
> wut? Каждая утилита/бинарник, дергающий fork+exec для modprobe должна вкомпилить этот
> modprobe в себя? Вы что-то не понимаете.

Я понимаю что дергать какой-то бинарник в системе вместо библиотечного вызова - это чесать правой ногой левое ухо. Если зависимость программы от либы еще можно понять, то вот зависимость программы от внешних исполняемых - это уже как-то горбато. А какого, собственно рожна кто-то возомнил что modprobe является какой-то стандартной утилитой, неотъемлимой частью системы и прочая?

И не надо ли в таком случае делать fread() путем создания команды fread и ее пинка через fork?

Ответить | Правка | Наверх | Cообщить модератору

125. "Комментарии разработчиков udev по поводу очередного форка пр..."  +4 +/
Сообщение от kekeke (ok), 20-Ноя-12, 10:11 
Претензии я так понимаю к тому, что kmod - это одна из реализаций функционала загрузки модулей ядра, но это не общепризнанный интерфейс(а всего лишь попытка сделать таковой), в качестве такого универсального интерфейса выступает команда modprobe.
Не понятно другое - почему нельзя было просто добавить ключик --disable-kmod например и вызовы kmod модуля в этом случае просто приводят к запуску modprobe, а не к вызовам libkmod? И волки сыты и овцы целы. Надо быстро - собирай с libkmod, надо переносимо - собирай без него. Самый логичный вариант и совсем не сложный по сути в реализации.
Ответить | Правка | Наверх | Cообщить модератору

134. "Комментарии разработчиков udev по поводу очередного форка пр..."  +1 +/
Сообщение от linux rip (?), 20-Ноя-12, 11:03 
Ленарт не настроен писать переносимый код.
О чем он не раз заявлял.
Ответить | Правка | Наверх | Cообщить модератору

157. "Комментарии разработчиков udev по поводу очередного форка пр..."  +/
Сообщение от Аноним (-), 20-Ноя-12, 14:01 
> Ленарт не настроен писать переносимый код.

Переносимый код ... загрузки модулей в конкретное ядро "linux"? Да вы упоролись, эти операции по определению специфичны для конкретной операционки.

Ответить | Правка | Наверх | Cообщить модератору

158. "Комментарии разработчиков udev по поводу очередного форка пр..."  +1 +/
Сообщение от Аноним (-), 20-Ноя-12, 14:11 
каких еще "модулей"? разупорись!
Ответить | Правка | Наверх | Cообщить модератору

162. "Комментарии разработчиков udev по поводу очередного форка пр..."  –2 +/
Сообщение от Аноним (-), 20-Ноя-12, 14:39 
> каких еще "модулей"? разупорись!

Пардон, вы с луны упали? В этой ветке вроде про загрузку модулей спич.

Ответить | Правка | Наверх | Cообщить модератору

189. "Комментарии разработчиков udev по поводу очередного форка пр..."  +/
Сообщение от linux RIP (?), 20-Ноя-12, 17:33 
а ничего что могут быть разные версии ядра?
как уже показали выше - libkmod не единственный метод это сделать.

хотя ничего - завтра systemd будет тоже wrapper для modprobe - ну зачем вам 2 бинарника то?

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

161. "Комментарии разработчиков udev по поводу очередного форка пр..."  +2 +/
Сообщение от Аноним (-), 20-Ноя-12, 14:39 
> лишь попытка сделать таковой),

Универсальным интерфейсом должен быть библиотечный вызов. Ну как для fread() или там чего еще. А вот кто и по какому поводу модуль подгрузит - это уж его дело. Надо удеву - пусть удев грузит, дернув либу. Надо modprobe-у - пусть модпроб либу дернет. Ну и так далее.

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

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

> в качестве такого универсального интерфейса выступает команда modprobe.

И вот это - криво. Ибо заставляет утилиты что-то там знать о каких-то нестандартных бинарниках и их дергании. Напрашивается нормальное API сделанное не через з@дницу.

> Не понятно другое - почему нельзя было просто добавить ключик --disable-kmod например
> и вызовы kmod модуля в этом случае просто приводят к запуску modprobe, а не
> к вызовам libkmod?

Технически наверное можно, но накукуй нужен весь этот геморрой? Как там утили внутри себя модули грузят - их собачье дело. Новые утили писать станет в разы проще, как и старые поддерживать. И ничему не противоречит тот же модпроб грузящий модули путем дерга вызова шаред библы, например. Зато код вгрузки модулей будет в каком-то одном месте, реюзаемом остальными.

> И волки сыты и овцы целы. Надо быстро - собирай с libkmod, надо переносимо - собирай без него.

Переносимо? А что, модули линя научились грузиться куда-то кроме линя? Или может у систем хоть названия и пути расположения модулей совпадают? Или в каком месте там переносимость вообще может возникать? Это системозависимая хрень, переносимость которой около нуля. Ну то-есть, в другой системе подсистема драйверов может быть устроена тотально иначе. И соответственно никакой особой переносимости там не будет.

> Самый логичный вариант и совсем не сложный по сути в реализации.

Пардон? Майнтенансить 2 варианта кода - геморройнее чем один. А ради чего все это - не понятно. Какая-то мифическая "переносимость", что довольно смешно звучит относительно вгрузки конкретных модулей конкретной операционки. А как, собственно, линевый модуль сможет вгрузиться на какой-то иной оси? Никак? Тогда где там переносимость? Даже у относительно родственных *никс-образных как минимум напрочь не совпадают названия модулей, а временами формат и уж тем более зависимости и прочая. А если операционка чуть иначе устроена - вообще швах.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

184. "Комментарии разработчиков udev по поводу очередного форка пр..."  +1 +/
Сообщение от максо (?), 20-Ноя-12, 16:07 
>Переносимо?

КО сообщает - между разными дистрибутивами

Ответить | Правка | Наверх | Cообщить модератору

204. "Комментарии разработчиков udev по поводу очередного форка пр..."  +/
Сообщение от kekeke (ok), 21-Ноя-12, 08:59 
гы, уже сделали патч, про что я говорил:
https://github.com/gentoo/eudev/commit/626bf3de512f8694ecebc...
Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру