LINUX.ORG.RU
ФорумTalks

udev катится в СГ

 , ,


3

5

Эпичный срач на LKML, Торвальдс жырно негодует. Для Ъ, мнение патриарха обозначено в теме сообщения.

https://lkml.org/lkml/2012/10/3/484


On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers <kay@vrfy.org> wrote:
>
> Nothing really «breaks», It's «slow» and it will surely be fixed when
> we know what's the right fix, which we haven't sorted out at this
> moment.

A thirty-second pause at bootup is easily long enough that some people might think the machine is hung.

I also call bullshit on your «it will surely be fixed when we know what's the right fix» excuses.

The fact is, you've spent the last several months blaming everybody but yourself, and actively told people to stop blaming you:

https://bugzilla.redhat.com/show_bug.cgi?id=827538#c12

and have ignored patches that were sent to you:

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006357.html

despite having clearly seen the patch (you *replied* to it, for chissake, and I even told you in that same thread why that reply was wrong at the time).

> I also have no issues at all if the kernel does load the firmware from
> the filesystem on its own; it sounds like the simplest and most robust
> solution from a general look at the problem. It would also make the
> difference between in-kernel firmware and out-of-kernel firmware less
> visible, which sounds good.

So now, after you've dismissed the patch that did the equivalent fix in udev (Ming Lei's patch basically disabled your idiotic and wrong sequence number test for firmware loading), you say it's ok to bypass udev entirely, because that is «more robust».

Kay, you are so full of sh*t that it's not funny. You're refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs, and say that we should have done so from the very beginning.

Yes, doing it in the kernel is «more robust». But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we *revert* the thing that broke.

So yes, we're clearly better off doing it in the kernel.

Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill.

Linus



Плевок в рожу Леннарта: https://lkml.org/lkml/2012/10/2/303

> I basically tried a few different approaches, including deferred probe(),
> as you suggested, and request_firmware_async(), as Kay suggested.

Stop this crazy. FIX UDEV ALREADY, DAMMIT.

Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

Lennart/Kai, fix the udev regression already. Lennart was the one who brought up kernel ABI regressions at some conference, and if you now you have the *gall* to break udev in an incompatible manner that requires basically impossible kernel changes for the kernel to «fix» the udev interface, I don't know what to say.

«Two-faced lying weasel» would be the most polite thing I could say. But it almost certainly will involve a lot of cursing.



Жира много, наслаждайтесь, вот ветка целиком: https://lkml.org/lkml/2012/10/2/194

★★★★★

Ответ на: комментарий от at

>Вариант перехода дебиана на mdev (или что то подобное), насколько понял, пока не рассматривался?

По крайней мере мне такое неизвестно. Правда я рассылку не читаю, неудобно.

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

Так я и не говорю, что одно и то же. Линукс тут при том Но он тут всё равно при чём ввиду последних инноваций и нанотехнологий.

Deleted
()

Вкратце: Линусу скучно стало, он дартаньяном решил прикинуться. Получился срач, предсказуемо. :)

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

Так и systemd уже по дефолту кое-где идет. Вот только на универсальнось не катит ни одно, ни другое

ananas ★★★★★
()

годно торвальдс вбросил. видел менее чем с 5 страницами каментов

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

В ./configure из systemd-194 я не вижу ключей, для отдельной сборки udev. Т.е. дебиану придется либо переходить на systemd (но тогда непонятно что делать с kfreebsd) либо использовать что то другое.

Оба варианта, ИМХО, не совсем правильные.

at ★★
()

Two-faced lying weasel

Чего это он так мягко? Сильнее надо было, они того заслужили.

Solace ★★
()
Ответ на: комментарий от at
--- systemd-193/configure	2012-09-28 00:07:22.000000000 +0000
+++ systemd-194/configure	2012-10-03 18:33:04.000000000 +0000
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for systemd 193.
+# Generated by GNU Autoconf 2.69 for systemd 194.
 #
 # Report bugs to <http://bugs.freedesktop.org/enter_bug.cgi?product=systemd>.
 #
@@ -591,8 +591,8 @@
 # Identity of this package.
 PACKAGE_NAME='systemd'
 PACKAGE_TARNAME='systemd'
-PACKAGE_VERSION='193'
-PACKAGE_STRING='systemd 193'
+PACKAGE_VERSION='194'
+PACKAGE_STRING='systemd 194'
 PACKAGE_BUGREPORT='http://bugs.freedesktop.org/enter_bug.cgi?product=systemd'
 PACKAGE_URL='http://www.freedesktop.org/wiki/Software/systemd'
 
@@ -1596,7 +1596,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures systemd 193 to adapt to many kinds of systems.
+\`configure' configures systemd 194 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1666,7 +1666,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
-     short | recursive ) echo "Configuration of systemd 193:";;
+     short | recursive ) echo "Configuration of systemd 194:";;
    esac
   cat <<\_ACEOF
 
@@ -1878,7 +1878,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-systemd configure 193
+systemd configure 194
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2293,7 +2293,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by systemd $as_me 193, which was
+It was created by systemd $as_me 194, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4674,7 +4674,7 @@
 
 # Define the identity of the package.
  PACKAGE='systemd'
- VERSION='193'
+ VERSION='194'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -18599,7 +18599,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by systemd $as_me 193, which was
+This file was extended by systemd $as_me 194, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES    = $CONFIG_FILES
@@ -18666,7 +18666,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
 ac_cs_version="\\
-systemd config.status 193
+systemd config.status 194
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"

и где же он был в 193, но вдруг исчез в 194?

megabaks ★★★★
()

А я говорил, что пора перелезать на mdev.

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

С разморозкой.

http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary
tags
6 months ago 182 udev 182

http://lwn.net/Articles/490413/
Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build.

Поверили? Ну-ну...

http://www.ohloh.net/p/udev-fork
http://www.spinics.net/lists/hotplug/msg05614.html
http://www.spinics.net/lists/hotplug/msg05617.html
This is not entirely true. A different makefile might be a temporary solution, but udev is already dependent on libsystemd, and I'm afraid this process may go much much further.

и дальше по треду...

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

Не передергивай. Удев в составе системд не универсален. Поьому что требует лишних телодвижений при пакетировании. Также как и мдев

ananas ★★★★★
()

A thirty-second pause at bootup is easily long enough that some people might think the machine is hung.

ЕМНИП это зависит от init-скриптов, хотя все правильно сказал, надо фиксить это дерьмо.

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

пояснишь?

182 по отношению к 194 тоже прошлая, хоть и не ближайшая прошлая.
http://www.spinics.net/lists/hotplug/msg05617.html
$ wget http://www.freedesktop.org/software/systemd/systemd-194.tar.xz
$ tar xz systemd-194.tar.xz
$ cd systemd-194
$ ./configure | grep «disable-systemd\|udev-only»
$

Как собрать udev без systemd?

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

чувак, у меня прям ща стоит удев 193 без системы_дерьма
а собирается просто - с овер дохрена --disable
посмотри ебилды генты, например
таки дела

megabaks ★★★★
()

Плевок в рожу Леннарта

О да, как долго я этого ждал… :)

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

и дальше по треду...

и чо? кастрированный udev это не udev?

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

нет, не говорит
вот тебе список файлов пакета

/sbin/udevadm
/etc/udev/udev.conf
/usr/bin/udevadm
/usr/share/pkgconfig/udev.pc
/usr/share/doc/udev-193/README.bz2
/usr/share/doc/udev-193/NEWS.bz2
/usr/share/doc/udev-193/DISTRO_PORTING.bz2
/usr/share/doc/udev-193/README.keymap.txt.bz2
/usr/share/doc/udev-193/TODO.bz2
/usr/share/man/man8/udevadm.8.bz2
/usr/share/man/man8/systemd-udevd.service.8.bz2
/usr/share/man/man8/systemd-udevd.8.bz2
/usr/share/man/man7/udev.7.bz2
/usr/lib/libgudev-1.0.so
/usr/lib/libgudev-1.0.so.0
/usr/lib/pkgconfig/gudev-1.0.pc
/usr/lib/pkgconfig/libudev.pc
/usr/lib/libgudev-1.0.so.0.1.2
/usr/lib/libudev.so.1.1.4
/usr/lib/udev/keyboard-force-release.sh
/usr/lib/udev/findkeyboards
/usr/lib/udev/rules.d/40-gentoo.rules
/usr/lib/udev/rules.d/75-probe_mtd.rules
/usr/lib/udev/rules.d/95-keyboard-force-release.rules
/usr/lib/udev/rules.d/95-keymap.rules
/usr/lib/udev/rules.d/61-accelerometer.rules
/usr/lib/udev/rules.d/60-persistent-v4l.rules
/usr/lib/udev/rules.d/60-cdrom_id.rules
/usr/lib/udev/rules.d/95-udev-late.rules
/usr/lib/udev/rules.d/80-drivers.rules
/usr/lib/udev/rules.d/78-sound-card.rules
/usr/lib/udev/rules.d/75-tty-description.rules
/usr/lib/udev/rules.d/75-net-description.rules
/usr/lib/udev/rules.d/64-btrfs.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/60-persistent-alsa.rules
/usr/lib/udev/rules.d/60-persistent-input.rules
/usr/lib/udev/rules.d/60-persistent-serial.rules
/usr/lib/udev/rules.d/60-persistent-storage-tape.rules
/usr/lib/udev/rules.d/50-udev-default.rules
/usr/lib/udev/rules.d/42-usb-hid-pm.rules
/usr/lib/udev/mtd_probe
/usr/lib/udev/keymap
/usr/lib/udev/accelerometer
/usr/lib/udev/v4l_id
/usr/lib/udev/keymaps/force-release/common-volume-keys
/usr/lib/udev/keymaps/force-release/samsung-90x3a
/usr/lib/udev/keymaps/force-release/samsung-other
/usr/lib/udev/keymaps/force-release/hp-other
/usr/lib/udev/keymaps/force-release/dell-xps
/usr/lib/udev/keymaps/force-release/dell-touchpad
/usr/lib/udev/keymaps/zepto-znote
/usr/lib/udev/keymaps/toshiba-satellite_m30x
/usr/lib/udev/keymaps/toshiba-satellite_a110
/usr/lib/udev/keymaps/toshiba-satellite_a100
/usr/lib/udev/keymaps/samsung-sx20s
/usr/lib/udev/keymaps/samsung-sq1us
/usr/lib/udev/keymaps/samsung-90x3a
/usr/lib/udev/keymaps/samsung-other
/usr/lib/udev/keymaps/oqo-model2
/usr/lib/udev/keymaps/onkyo
/usr/lib/udev/keymaps/olpc-xo
/usr/lib/udev/keymaps/module-sony-vpc
/usr/lib/udev/keymaps/module-sony-vgn
/usr/lib/udev/keymaps/module-sony-old
/usr/lib/udev/keymaps/module-sony
/usr/lib/udev/keymaps/module-lenovo
/usr/lib/udev/keymaps/module-ibm
/usr/lib/udev/keymaps/module-asus-w3j
/usr/lib/udev/keymaps/micro-star
/usr/lib/udev/keymaps/medionnb-a555
/usr/lib/udev/keymaps/medion-fid2060
/usr/lib/udev/keymaps/maxdata-pro_7000
/usr/lib/udev/keymaps/logitech-wave-pro-cordless
/usr/lib/udev/keymaps/logitech-wave-cordless
/usr/lib/udev/keymaps/logitech-wave
/usr/lib/udev/keymaps/lg-x110
/usr/lib/udev/keymaps/lenovo-thinkpad_x200_tablet
/usr/lib/udev/keymaps/lenovo-thinkpad_x6_tablet
/usr/lib/udev/keymaps/lenovo-thinkpad-usb-keyboard-trackpoint
/usr/lib/udev/keymaps/lenovo-ideapad
/usr/lib/udev/keymaps/lenovo-3000
/usr/lib/udev/keymaps/inventec-symphony_6.0_7.0
/usr/lib/udev/keymaps/ibm-thinkpad-usb-keyboard-trackpoint
/usr/lib/udev/keymaps/hewlett-packard-tx2
/usr/lib/udev/keymaps/hewlett-packard-tablet
/usr/lib/udev/keymaps/hewlett-packard-presario-2100
/usr/lib/udev/keymaps/hewlett-packard-pavilion
/usr/lib/udev/keymaps/hewlett-packard-compaq_elitebook
/usr/lib/udev/keymaps/hewlett-packard-2510p_2530p
/usr/lib/udev/keymaps/hewlett-packard
/usr/lib/udev/keymaps/genius-slimstar-320
/usr/lib/udev/keymaps/fujitsu-esprimo_mobile_v6
/usr/lib/udev/keymaps/fujitsu-esprimo_mobile_v5
/usr/lib/udev/keymaps/fujitsu-amilo_si_1520
/usr/lib/udev/keymaps/fujitsu-amilo_pro_v3205
/usr/lib/udev/keymaps/fujitsu-amilo_pro_edition_v3505
/usr/lib/udev/keymaps/fujitsu-amilo_pa_2548
/usr/lib/udev/keymaps/fujitsu-amilo_li_2732
/usr/lib/udev/keymaps/everex-xt5000
/usr/lib/udev/keymaps/dell-latitude-xt2
/usr/lib/udev/keymaps/dell
/usr/lib/udev/keymaps/compaq-e_evo
/usr/lib/udev/keymaps/asus
/usr/lib/udev/keymaps/acer-travelmate_c300
/usr/lib/udev/keymaps/acer-aspire_6920
/usr/lib/udev/keymaps/acer-aspire_5920g
/usr/lib/udev/keymaps/acer-aspire_8930
/usr/lib/udev/keymaps/acer-aspire_5720
/usr/lib/udev/keymaps/acer
/usr/lib/udev/scsi_id
/usr/lib/udev/collect
/usr/lib/udev/cdrom_id
/usr/lib/udev/ata_id
/usr/lib/systemd/system/systemd-udev-settle.service
/usr/lib/systemd/system/systemd-udev-trigger.service
/usr/lib/systemd/system/systemd-udevd.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service
/usr/lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket
/usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
/usr/lib/systemd/system/systemd-udevd-kernel.socket
/usr/lib/systemd/system/systemd-udevd-control.socket
/usr/lib/systemd/systemd-udevd
/usr/include/libudev.h
/usr/include/gudev-1.0/gudev/gudevenumerator.h
/usr/include/gudev-1.0/gudev/gudevdevice.h
/usr/include/gudev-1.0/gudev/gudevclient.h
/usr/include/gudev-1.0/gudev/gudevtypes.h
/usr/include/gudev-1.0/gudev/gudevenumtypes.h
/usr/include/gudev-1.0/gudev/gudevenums.h
/usr/include/gudev-1.0/gudev/gudev.h
/usr/lib/libudev.so
/usr/lib/libudev.so.1
ldd каких хочешь видеть?

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

Но почему systemd не универсален?

Потому что универсальность — это не впилить одно говно всюду, где только можно.

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

ldd каких хочешь видеть?

Не стОит, собралось, посмотрел, по ldd претензий нет.
Попробую приладить на место с учётом изменений и посмотреть на результат более внимательно.

bormant ★★★★★
()

У линуса опять в разных местах свербит?

vurdalak ★★★★★
()

У Линуса настроение плохое видать, то его не видно и не слышно, то вбрасывает по полной. Знатный срач получился.

gwinn ★★★★
()

Что, до сих пор та самая канитель с асинхронной загрузкой прошивок?

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

ЕМНИП это зависит от init-скриптов, хотя все правильно сказал, надо фиксить это дерьмо.

Если это тот самый баг, который тянется с udev-18?, то не зависит, только от местоположения файла прошивки.

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

Потому что универсальность — это не впилить одно говно всюду, где только можно.

Вполне себе определение универсальности

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

т.е. на самом деле он не подвисает?

Подвисает.

Грег: Кай, исправьте ситуацию.

Кай: Ох, ах... мы пока не знаем как, поэтому оставили как есть, с подвисанием.

Линус: В таком случае ревертите сломавший патч. СЕЙЧАС. Чтобы не было регрессии. Такова наша политика.

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

Сиверс еще в январе написал в рассылку (правда не совсем в ту (% ), и заинтересованые лица все поправили давным давно. Щас уже октябрь, и тут только начали чуваки чехла давать, что не работает. Молодцы, чо.

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

Ты же меня зафрендил?

Меня он френдил как минимум раза три, у него это каждый раз ненадолго.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от GNU-Ubuntu1204LTS

ХЗ. Убунтой не пользуюсь, хотя иногда и просматриваю репы, поэтому и спросил.

И, кстати, в убунте есть что то похожее на сид/эксперементал?

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

mdev сильно слабее по возможностям, и подходит на замену в общем случае чуть менее чем совсем. За пруфами можно почитать письма в рассылки (напр. gentoo-dev@) от автора mdev, но там очень длинные треды.

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

думаю он пересрал перед отцом основателем :)

/me записывает: мейнтейнер udev - трусливый враль, способный только выпендриваться перед младшими.

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

mdev - это просто недоразумение. Я вообще не понимаю зачем он нужен. Его можно использовать только для примитивных фиксированных конфигураций. Имхо более рабочим вариантом был бы тупо диспатчер и куча обычных sh скриптов. Другой вопрос что это говно, но в линаксе так все уже привыкли

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

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

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

т.е. как удев, да? дикий набор (неверифицируемых?) правил + запуск sh скрипта, под конец многих из них.

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

Да, удев с т.з. конфигурации — жуткое говно. Я думаю после мерджа с systemd лучшем вариантом было бы поменять это страшное наречие на unit формат. Запуск скрипта из правил с systemd, кстати, не нужен

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

Да, удев с т.з. конфигурации — жуткое говно. Я думаю после мерджа с systemd лучшем вариантом было бы поменять это страшное наречие на unit формат.

превратив юнит формат в адское неподдерживаемое говно? Или объявив 2/3 возможностей udev deprecated и забив на них?

Запуск скрипта из правил с systemd, кстати, не нужен

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

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

превратив юнит формат в адское неподдерживаемое говно?

Ну, почему же. Там не так уж много точек свободы. IfName= SetName= итд.

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

нужен, для любой нетривиальной вещи, которая не была продумана автором

Вместо RUN можно поставить WANT, и эту нетривиальную вещь запустит systemd из правильного контекста (если она действительно нужна, а не как сейчас). Вот с IMPORT хуже, да

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

Ну, почему же. Там не так уж много точек свободы. IfName= SetName= итд.

я вот заглянул сейчас в '/lib/udev/rules.d/80-udisks.rules' и не поверил тебе.

вообще идея DSL мне кажется логичной для системы управления такого уровня, главное, чтобы оно было максимально верифицируемо.

Вместо RUN можно поставить WANT, и эту нетривиальную вещь запустит systemd из правильного контекста (если она действительно нужна, а не как сейчас). Вот с IMPORT хуже, да

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

В любом случае SD сделало отличную вещь - толчок к унификации и попыткам перепродумать то, что должно быть в init скриптах.

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

я вот заглянул сейчас в '/lib/udev/rules.d/80-udisks.rules' и не поверил тебе.

Ну и чо там? Расстановка переменных в env группами? Тут как раз ничего военного нет

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