[-- Attachment #1: Type: text/plain, Size: 473 bytes --] В общем, я обточил слегка и собрал udev-0.43. Даже работает (самосборное 2.6.9 по мотивам rider'овского (патчсеты и спек могут быть выложены)) В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus ;-)) Все приготовились? :-)) P.S. Завтра проверю, насколько работоспособным в итоге оказался hal... [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 259 bytes --] В сообщении от Четверг 11 Ноябрь 2004 21:37 Alexey Morozov написал(a): [...] > поменяю /udev на /dev Может на /dev/udev для начала? -- Regards, Sergey, ALT Linux Team, http://www.altlinux.ru http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08 [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #1: Type: text/plain, Size: 673 bytes --] Hi, On Fri, Nov 12, 2004 at 12:37:40AM +0600, Alexey Morozov wrote: > В общем, я обточил слегка и собрал udev-0.43. Даже работает > (самосборное 2.6.9 по мотивам rider'овского (патчсеты и спек > могут быть выложены)) > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus > ;-)) Все приготовились? :-)) Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и /dev/udev. :) > P.S. Завтра проверю, насколько работоспособным в итоге оказался hal... :) -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 600 bytes --] On Thu, Nov 11, 2004 at 10:16:19PM +0300, Dmitry V. Levin wrote: > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит > > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, > > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus > > ;-)) Все приготовились? :-)) > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и > /dev/udev. :) Сдаюсь... Говорите правильный ответ :-). > > P.S. Завтра проверю, насколько работоспособным в итоге оказался hal... > :) "Он еще и издевается!" Что делать-то будем? [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 627 bytes --] On Fri, Nov 12, 2004 at 04:43:45PM +0600, Alexey Morozov wrote: > On Thu, Nov 11, 2004 at 10:16:19PM +0300, Dmitry V. Levin wrote: > > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит > > > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, > > > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus > > > ;-)) Все приготовились? :-)) > > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и > > /dev/udev. :) > Сдаюсь... Говорите правильный ответ :-). Помещайте туда, куда надо, в sisyphus_check будет адаптирован. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
В Птн, 12/11/2004 в 14:24 +0300, Dmitry V. Levin пишет:
> On Fri, Nov 12, 2004 at 04:43:45PM +0600, Alexey Morozov wrote:
> > On Thu, Nov 11, 2004 at 10:16:19PM +0300, Dmitry V. Levin wrote:
> > > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит
> > > > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений,
> > > > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus
> > > > ;-)) Все приготовились? :-))
> > > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и
> > > /dev/udev. :)
> > Сдаюсь... Говорите правильный ответ :-).
>
> Помещайте туда, куда надо, в sisyphus_check будет адаптирован.
То есть в /dev? Просто куда-то еще помещать нет смысла, кроме как, может
быть, посмотреть "ути-пути, как мы умеем динамически создавать
устройства!"
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --] On Fri, Nov 12, 2004 at 02:24:20PM +0300, Dmitry V. Levin wrote: > > > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и > > > /dev/udev. :) > > Сдаюсь... Говорите правильный ответ :-). > Помещайте туда, куда надо, в sisyphus_check будет адаптирован. В том-то и вопрос: а _куда_ надо? В смысле, видят ли г-да разработчики ("остальные господа разработчики") в дальнейшем этот самый udev в качестве одного из основных средств манипулирования /dev - тогда, понятное, дело, надо, надо все совать в /dev. Если udev останется игрушкой (а для меня он сейчас - игрушка, хотя и прикольная, во всяком случае, /udev/usb/hiddev0 у меня сейчас открывается, а /dev/usb/hiddev* ругается на no such device, привет Райдеру :-)), то его можно запихать куда угодно, хоть в /var/tmp - все одно, на выброс... 2rider: нет, [на 2.6.9] оно все равно не работает, даже после того, как открылось... А CONFIG_USB_DYNAMIC_MINORS=y - это больше походит как тест на вшивость :-)... Спасибо vsu - заметил и подсказал :-) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 324 bytes --] Да, пока я думаю, что пусть будет нейтральный вариант: /dev/udev. Потом, если udev окончательно прописывается в системе, можно заменять им статический /dev полностью (то есть, понадобится загонять его в initrd, и собирать, соответственно, статически или с klibc), для того, чтобы нормально проходило монтирование / [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --] В сообщении от Четверг 11 Ноябрь 2004 21:37 Alexey Morozov написал(a): > В общем, я обточил слегка и собрал udev-0.43. Даже работает > (самосборное 2.6.9 по мотивам rider'овского (патчсеты и спек > могут быть выложены)) > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не > пролазит сквозь наш замечательный sisyphus_check. Если ни у кого > нет возражений, хе-хе, то я поменяю /udev на /dev и отправлю это > хозяйство в Sisyphus ;-)) Все приготовились? :-)) > > P.S. Завтра проверю, насколько работоспособным в итоге оказался > hal... Может поглядеть, полезны ли нам эти изменения? ---------- Пересланное сообщение ---------- Subject: Re: [asplinux-support] udev и cdrom Date: Пятница 12 Ноябрь 2004 12:43 From: Andy Shevchenko <andriy@asplinux> To: asplinux-support@lists.asplinux Igor Didkovsky пишет: > В fedora core внесли кое-какие изменения c расположением девайсов > (спасибо udev). Что теперь указывать vmware, которой требуется > указать девайс (раньше звался /dev/cdrom)? vmware >= 4.5.2 работает с udev (работа с внутренними устройствами vmware: vmmon, vmnet, ...). Но работу с CD в нашем (Донецком) офисе никто не проверял. With best regards, Andy Shevchenko. mailto: andriy@asplinux ------------------------------------------------------- -- Regards, Sergey, ALT Linux Team, http://www.altlinux.ru http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08 [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #1: Type: text/plain, Size: 494 bytes --] On Fri, Nov 12, 2004 at 03:19:31PM +0300, Mikhail Zabaluev wrote: > быть, посмотреть "ути-пути, как мы умеем динамически создавать > устройства!" На моей машине я вижу это уже 2-й год. devfs. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): <thresh> vsu: хм. а эта ругань вообще нормальна? <vsu> thresh: нормальна для попытки грузить всякую фигню <thresh> vsu: как ему сказать, чтобы не пытался грузить всякую фигню? :) <vsu> thresh: rm /etc/hotplug/pci.rc ;) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 713 bytes --] On Fri, Nov 12, 2004 at 04:04:51PM +0300, Sergey V Turchin wrote: > > P.S. Завтра проверю, насколько работоспособным в итоге оказался > > hal... > Может поглядеть, полезны ли нам эти изменения? > > > (спасибо udev). Что теперь указывать vmware, которой требуется > > указать девайс (раньше звался /dev/cdrom)? alex@pyro /var/tmp/linux-2.6.7 $ ls -l /udev | grep cdrom lrwxrwxrwx 1 root root 3 Ноя 11 23:57 cdrom -> hdc alex@pyro /var/tmp/linux-2.6.7 $ _ Так что, в принципе, _это_ место точно не пострадало ;-) Вообще, если я правильно понимаю ситуацию, то в рамках того же udev возможны несколько схем именования дивайсов: классическая (как у меня сейчас), та, что была в devfs и т.п.) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 507 bytes --] В сообщении от Пятница 12 Ноябрь 2004 16:19 Alexey Morozov написал(a): > On Fri, Nov 12, 2004 at 04:04:51PM +0300, Sergey V Turchin wrote: > > > P.S. Завтра проверю, насколько работоспособным в итоге > > > оказался hal... > > > > Может поглядеть, полезны ли нам эти изменения? Я про "посмотреть на изменения в fedora". Просто, раз они что-то меняли, может и нам есть смысл? [...] -- Regards, Sergey, ALT Linux Team, http://www.altlinux.ru http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08 [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --] On Fri, Nov 12, 2004 at 03:19:31PM +0300, Mikhail Zabaluev wrote: > В Птн, 12/11/2004 в 14:24 +0300, Dmitry V. Levin пишет: > > On Fri, Nov 12, 2004 at 04:43:45PM +0600, Alexey Morozov wrote: > > > On Thu, Nov 11, 2004 at 10:16:19PM +0300, Dmitry V. Levin wrote: > > > > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит > > > > > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, > > > > > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus > > > > > ;-)) Все приготовились? :-)) > > > > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и > > > > /dev/udev. :) > > > Сдаюсь... Говорите правильный ответ :-). > > > > Помещайте туда, куда надо, в sisyphus_check будет адаптирован. > > То есть в /dev? Просто куда-то еще помещать нет смысла, кроме как, может > быть, посмотреть "ути-пути, как мы умеем динамически создавать > устройства!" (по прочтению udev.html) Конечно в /dev, куда же ещё. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 526 bytes --] On Fri, Nov 12, 2004 at 04:46:57PM +0300, Sergey V Turchin wrote: > В сообщении от Пятница 12 Ноябрь 2004 16:19 Alexey Morozov > написал(a): > > On Fri, Nov 12, 2004 at 04:04:51PM +0300, Sergey V Turchin wrote: > > > > P.S. Завтра проверю, насколько работоспособным в итоге > > > > оказался hal... > > > > > > Может поглядеть, полезны ли нам эти изменения? > Я про "посмотреть на изменения в fedora". Просто, раз они что-то > меняли, может и нам есть смысл? Это не меняет суть использования udev. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --] On Wed, Nov 17, 2004 at 12:33:23PM +0300, Dmitry V. Levin wrote: > On Fri, Nov 12, 2004 at 03:19:31PM +0300, Mikhail Zabaluev wrote: > > В Птн, 12/11/2004 в 14:24 +0300, Dmitry V. Levin пишет: > > > On Fri, Nov 12, 2004 at 04:43:45PM +0600, Alexey Morozov wrote: > > > > On Thu, Nov 11, 2004 at 10:16:19PM +0300, Dmitry V. Levin wrote: > > > > > > В моей нынешней сборке он плещется в /udev. Это, разумеется, не пролазит > > > > > > сквозь наш замечательный sisyphus_check. Если ни у кого нет возражений, > > > > > > хе-хе, то я поменяю /udev на /dev и отправлю это хозяйство в Sisyphus > > > > > > ;-)) Все приготовились? :-)) > > > > > Думаю, что "наш замечательный sisyphus_check" завернёт и /udev, и /dev, и > > > > > /dev/udev. :) > > > > Сдаюсь... Говорите правильный ответ :-). > > > > > > Помещайте туда, куда надо, в sisyphus_check будет адаптирован. > > > > То есть в /dev? Просто куда-то еще помещать нет смысла, кроме как, может > > быть, посмотреть "ути-пути, как мы умеем динамически создавать > > устройства!" > > (по прочтению udev.html) Конечно в /dev, куда же ещё. sisyphus_check-0.7.10-alt1 уже адаптирован. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 394 bytes --] On Fri, Nov 19, 2004 at 11:14:43PM +0300, Dmitry V. Levin wrote: > sisyphus_check-0.7.10-alt1 уже адаптирован. Спасибо. Как Блохин (вероятно, он же должен в Дедал класть, да?) поместит туда новую версию, счастливые обладатели 2.6 могут пробовать udev-0.50-alt1 Только чур не нанимать киллеров после первой же неудачи ;-). Вероятно, service udevd stop должен помочь страждущим ;-) [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Не знаю, в какой момент (возможно, побочный эффект даунгрейда), но словил ещё один прелестнейший глюк: на /dev/null оказались права 0644. В udev-0.50 в permissions.d написано 0666, в udev-0.60 не смотрел. -- Alexey "Ktirf" Rusakov
Привет всем. Поставил тут вчера на vmware'ку FC5. Из того, что понравилось -- udev стартует до всех остальных сервисов, соответственно нет проблем с созданием, к примеру, lvm2-устройств, которые наблюдаются в данный момент (в сизифе, конечно) у нас. Почему бы такую вещь не провернуть и у нас? смотрел https://bugzilla.altlinux.org/show_bug.cgi?id=7101 и https://bugzilla.altlinux.org/show_bug.cgi?id=7369 , похоже, воз и ныне там. -- Pavlov Konstantin, ALT Linux Team, jid: thresh@altlinux.org
On Thu, 23 Mar 2006 14:53:42 +0300, Pavlov Konstantin wrote:
> Привет всем.
>
> Поставил тут вчера на vmware'ку FC5.
>
> Из того, что понравилось -- udev стартует до
> всех остальных сервисов, соответственно
> нет проблем с созданием, к примеру,
> lvm2-устройств, которые наблюдаются в
> данный момент (в сизифе, конечно) у нас.
>
> Почему бы такую вещь не провернуть и у
> нас?
>
> смотрел https://bugzilla.altlinux.org/show_bug.cgi?id=7101 и
> https://bugzilla.altlinux.org/show_bug.cgi?id=7369 , похоже, воз
> и ныне там.
Тема хорошая и правильная, патчи приветствуются.
Rgds,
Rider
Один из наших партнёров создает ядерный драйвер одного устройства под, который подключен по DAC-порту. Драйвер разработал, однако он не определяется через udev. А материала и мыслей на эту тему у них не хватает. Кто может проконсультировать? -- Андрей Черепанов ALT Linux Solutions cas@altlinux.ru
[-- Attachment #1: Type: text/plain, Size: 405 bytes --] On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote: [...] > А установить в систему пакет udev_X (где X - нужная версия) - вобще > невозможно. Потому, что: > $ grep udev /usr/lib/rpm/0common-files.req.list > /etc/udev/rules.d udev-rules > > Это зачем? Что никому неповадно было нужный ему udev собрать? А чем 0common-files.req.list мешает кому-то собрать нужный ему udev? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
> On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
> [...]
>
> > А установить в систему пакет udev_X (где X - нужная версия) - вобще
> > невозможно. Потому, что:
> > $ grep udev /usr/lib/rpm/0common-files.req.list
> > /etc/udev/rules.d udev-rules
> >
> > Это зачем? Что никому неповадно было нужный ему udev собрать?
>
> А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
Собрать - не мешает. Установить - раскажите как.
В 0common-files.req.list вобще костылей понатыкано - даже если хочется что-то
исправить (некоторые пакеты) - не получится, без форканья rpm.
Вы тоже не можете объяснить, зачем эти костыли, если только не для того, чтобы
совать палки в колёса мейнтейнерам?
--
Led
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --] On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote: > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote: > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote: > > [...] > > > > > А установить в систему пакет udev_X (где X - нужная версия) - вобще > > > невозможно. Потому, что: > > > $ grep udev /usr/lib/rpm/0common-files.req.list > > > /etc/udev/rules.d udev-rules > > > > > > Это зачем? Что никому неповадно было нужный ему udev собрать? > > > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev? > > Собрать - не мешает. Установить - раскажите как. А в чём принципиальная сложность установить? > В 0common-files.req.list вобще костылей понатыкано - даже если хочется что-то > исправить (некоторые пакеты) - не получится, без форканья rpm. > Вы тоже не можете объяснить, зачем эти костыли, если только не для того, чтобы > совать палки в колёса мейнтейнерам? Эта проактивная мера нужна для того, чтобы мантейнеры меньше ошибались. Эдакий свод нежелательных ошибок. Наш rpm-build содержит изрядное число подобных мер. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote: > On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote: > > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote: > > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote: > > > [...] > > > > > > > А установить в систему пакет udev_X (где X - нужная версия) - вобще > > > > невозможно. Потому, что: > > > > $ grep udev /usr/lib/rpm/0common-files.req.list > > > > /etc/udev/rules.d udev-rules > > > > > > > > Это зачем? Что никому неповадно было нужный ему udev собрать? > > > > > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev? > > > > Собрать - не мешает. Установить - раскажите как. > > А в чём принципиальная сложность установить? Странно слышать этот вопрос от разработчика ALT-RPM:) Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на установку алтернативных пакетов (с другим именем, с версией в имени)? аргументов, кроме как "Для вашего же блага!" я не услышал. Попробуйте установить альтернативную сборку udev_xyz, альтернативную сборку tetex (с tetex у меня в конце концов получилось, нагородив полдюжины костылей, чтобы обойти один костыль в rpm/0common-files.req.list) - не исключено, что у вас получится - возможно вы знаете "недокументированные возможности" или "секретные читы":) Можно ещё вспомнить про "супероптимизированные зависимости" buildreq, когда на каждый чих приходится перегенировать BuildRequires и пересобирать сотню пакетов в репозитарии - просто удивительная "автоматизация" - помоб мейнтейнерам - ведь им от скуки и безделия просто девать себя нЕкуда:) > > > В 0common-files.req.list вобще костылей понатыкано - даже если хочется > > что-то исправить (некоторые пакеты) - не получится, без форканья rpm. > > Вы тоже не можете объяснить, зачем эти костыли, если только не для того, > > чтобы совать палки в колёса мейнтейнерам? > > Эта проактивная мера нужна для того, чтобы мантейнеры меньше ошибались. > Эдакий свод нежелательных ошибок. > Наш rpm-build содержит изрядное число подобных мер. Теперь понятно: чтоб не лезли, "куда не просят - будут меньше ошибаться":) -- Led
[-- Attachment #1: Type: text/plain, Size: 970 bytes --] Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: >> А в чём принципиальная сложность установить? L> Странно слышать этот вопрос от разработчика ALT-RPM:) L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на L> установку алтернативных пакетов (с другим именем, с версией в L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал. Предлагаю перейти к конструктиву: что конкретно ломается при установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто недопонимание или незадокументирование? -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
10 января 2009 г. 1:58 пользователь Led <ledest@gmail.com> написал:
> On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote:
>> On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote:
>> > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
>> > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
>> > > [...]
>> > >
>> > > > А установить в систему пакет udev_X (где X - нужная версия) - вобще
>> > > > невозможно. Потому, что:
>> > > > $ grep udev /usr/lib/rpm/0common-files.req.list
>> > > > /etc/udev/rules.d udev-rules
>> > > >
>> > > > Это зачем? Что никому неповадно было нужный ему udev собрать?
>> > >
>> > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
>> >
>> > Собрать - не мешает. Установить - раскажите как.
>>
>> А в чём принципиальная сложность установить?
>
> Странно слышать этот вопрос от разработчика ALT-RPM:)
> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на установку
> алтернативных пакетов (с другим именем, с версией в имени)? аргументов, кроме
> как "Для вашего же блага!" я не услышал.
> Попробуйте установить альтернативную сборку udev_xyz, альтернативную сборку
> tetex (с tetex у меня в конце концов получилось, нагородив полдюжины
> костылей, чтобы обойти один костыль в rpm/0common-files.req.list) - не
> исключено, что у вас получится - возможно вы знаете "недокументированные
> возможности" или "секретные читы":)
>
> Можно ещё вспомнить про "супероптимизированные зависимости" buildreq, когда на
> каждый чих приходится перегенировать BuildRequires и пересобирать сотню
> пакетов в репозитарии - просто удивительная "автоматизация" - помоб
> мейнтейнерам - ведь им от скуки и безделия просто девать себя нЕкуда:)
Пожалуй, это становится даже мне интересно. Все эти фичи появились
вчера? Не лучше ли объяснить, что и как Вам мешает, почему именно
сегодня и как по Вашему будет лучше _всем_ разработчикам?
Rgrds, Алексей
On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote: > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: > >> А в чём принципиальная сложность установить? > > L> Странно слышать этот вопрос от разработчика ALT-RPM:) > > L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на > L> установку алтернативных пакетов (с другим именем, с версией в > L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал. > > Предлагаю перейти к конструктиву: что конкретно ломается при установке > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто > недопонимание или незадокументирование? http://lists.altlinux.org/pipermail/devel/2008-July/157577.html P.S. "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@ -- Led
On Saturday, 10 January 2009 01:13:35 Aleksey Novodvorsky wrote: > 10 января 2009 г. 1:58 пользователь Led <ledest@gmail.com> написал: > > On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote: > >> On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote: > >> > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote: > >> > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote: > >> > > [...] > >> > > > >> > > > А установить в систему пакет udev_X (где X - нужная версия) - > >> > > > вобще невозможно. Потому, что: > >> > > > $ grep udev /usr/lib/rpm/0common-files.req.list > >> > > > /etc/udev/rules.d udev-rules > >> > > > > >> > > > Это зачем? Что никому неповадно было нужный ему udev собрать? > >> > > > >> > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev? > >> > > >> > Собрать - не мешает. Установить - раскажите как. > >> > >> А в чём принципиальная сложность установить? > > > > Странно слышать этот вопрос от разработчика ALT-RPM:) > > Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на > > установку алтернативных пакетов (с другим именем, с версией в имени)? > > аргументов, кроме как "Для вашего же блага!" я не услышал. > > Попробуйте установить альтернативную сборку udev_xyz, альтернативную > > сборку tetex (с tetex у меня в конце концов получилось, нагородив > > полдюжины костылей, чтобы обойти один костыль в > > rpm/0common-files.req.list) - не исключено, что у вас получится - > > возможно вы знаете "недокументированные возможности" или "секретные > > читы":) > > > > Можно ещё вспомнить про "супероптимизированные зависимости" buildreq, > > когда на каждый чих приходится перегенировать BuildRequires и > > пересобирать сотню пакетов в репозитарии - просто удивительная > > "автоматизация" - помоб мейнтейнерам - ведь им от скуки и безделия просто > > девать себя нЕкуда:) > > Пожалуй, это становится даже мне интересно. Все эти фичи появились > вчера? Не вчера. > Не лучше ли объяснить, что и как Вам мешает, Об этом был тред в devel@ > почему именно > сегодня и как по Вашему будет лучше _всем_ разработчикам? Я задавал этот вопрос. получил ответ из разряда: 1) Так надо 2) Так красивее 3) Так на спек получается на 5 строчек короче -- Led
[-- Attachment #1: Type: text/plain, Size: 997 bytes --] Twas brillig at 01:23:10 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: >> Предлагаю перейти к конструктиву: что конкретно ломается при >> установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь >> просто недопонимание или незадокументирование? L> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html L> P.S. "Proivdes: udev-rules" - не рашает, несмотря на утверждение L> at@ Так это ж баг, его надо повесить. Ответа в списке нету (есть только последующий неконкретный стон в ltsp-server), бага в багзилле тоже не видно - кто ж знал, что заявленная фича не работает, если про это никто не сообщил? -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 01:32:25 Mikhail Gusarov wrote: > Twas brillig at 01:23:10 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: > >> Предлагаю перейти к конструктиву: что конкретно ломается при > >> установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь > >> просто недопонимание или незадокументирование? > > L> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html > > L> P.S. "Proivdes: udev-rules" - не рашает, несмотря на утверждение > L> at@ > > Так это ж баг, его надо повесить. Ответа в списке нету (есть только > последующий неконкретный стон в ltsp-server), бага в багзилле тоже не > видно - кто ж знал, что заявленная фича не работает, если про это никто > не сообщил? Т.е. вы считаете, что это бага? Мне показалось, что это, по всем признакам, "прибитая гвоздями" фича. Как я мог о фиче репортить в багзиллу?:) Я сам мейнтейнер и знаю, что ничего неприятнее нет, как потратить пару дней на разборки с багрепортом, чтобы потом поставить на него статус NOTABUG:) -- Led
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --] Twas brillig at 01:38:24 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: L> Т.е. вы считаете, что это бага? Мне показалось, что это, по всем L> признакам, "прибитая гвоздями" фича. Как я мог о фиче репортить в L> багзиллу?:) Бага. at говорит, что Provides решает, а на самом деле - не решает. Налицо расходение между спецификацией (какая уж есть) и реализацией. L> Я сам мейнтейнер и знаю, что ничего неприятнее нет, как потратить L> пару дней на разборки с багрепортом, чтобы потом поставить на него L> статус NOTABUG:) Иногда это приятно - означает, что не придётся ещё месяц чинить, чтобы потом поставить FIXED :) -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 01:39:26 Mikhail Gusarov wrote:
> Twas brillig at 01:38:24 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
> L> Т.е. вы считаете, что это бага? Мне показалось, что это, по всем
> L> признакам, "прибитая гвоздями" фича. Как я мог о фиче репортить в
> L> багзиллу?:)
>
> Бага. at говорит, что Provides решает, а на самом деле - не
> решает. Налицо расходение между спецификацией (какая уж есть) и
> реализацией.
Т.е. получается что механизм с костылём по имени 0common-files.req.list - одна
сплошная бага? Спасибо, не прошло и двух лет и хоть кто-то из ALT это
признал:)
Я не иронизирую (ну, почти:). Означает ли это, что отношение меняется
с "отмахнулись - не до этого" на "некотарая заинтересовааность"? И можно
поднимать другие вопросы, который в своё время "замяли"?
--
Led
[-- Attachment #1: Type: text/plain, Size: 1903 bytes --] Twas brillig at 01:49:35 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: L> Т.е. получается что механизм с костылём по имени L> 0common-files.req.list - одна сплошная бага? Разумеется, нет. Багом является то, что sisyphus_check не проверяет Provides. Впрочем, в любом случае, костыли для объезда 0common-files.req.list не нужны, нужно исправление бага в sisyphus_check. Который вы пока что не повесили. Поскольку at в devel давно не видно - повесить будет не вредно, чтобы не потерялось. L> Означает ли это, что отношение меняется с "отмахнулись - не до L> этого" на "некотарая заинтересовааность"? Можно ли привести ссылки, подтверждающие в данном случае "отмахнулись"? Последним письмом в вышеуказанном треде было письмо at@, описавшего спецификацию механизма работы. Механизм не работает, но про это никаким образом, кроме телепатического, догадаться было нельзя (опять же, неконкретный стон в ltsp-server не считается). L> И можно поднимать другие вопросы, который в своё время "замяли"? Замятые не по существу вопросы всегда можно и нужно поднимать, пока не станет понятно, в чём вообще состоит проблема. -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 01:58:23 Mikhail Gusarov wrote: > Twas brillig at 01:49:35 10.01.2009 UTC+02 when ledest@gmail.com did gyre > and gimble: > > L> Т.е. получается что механизм с костылём по имени > L> 0common-files.req.list - одна сплошная бага? > > Разумеется, нет. Багом является то, что sisyphus_check не проверяет > Provides. > > Впрочем, в любом случае, костыли для объезда 0common-files.req.list не > нужны, нужно исправление бага в sisyphus_check. Который вы пока что не > повесили. А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз повторяю: пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным sisyphus_check. Но в систему он если и устанавливается (?), то только "с бубном". И все "танцы с бубном" идут насмарку при первом же apt-get dist-upgrade (вопросительные знаки, потому что я не помню все детали, бинаного udev108 у меня уже нет, а собрать его из существующего udev108.spec не представляется возможным из-за "странностей" текущей klibc). А повторять всё "с нуля" чисто из академического интереса желания у меня нет, пока не будет хотя бы 90%-ной уверенности, что данный тред не закончится как и предидущие (т.е. ничем) :( > Поскольку at в devel давно не видно - повесить будет не > вредно, чтобы не потерялось. > > L> Означает ли это, что отношение меняется с "отмахнулись - не до > L> этого" на "некотарая заинтересовааность"? > > Можно ли привести ссылки, подтверждающие в данном случае "отмахнулись"? Сорри, не коллекционирую:) > Последним письмом в вышеуказанном треде было письмо at@, описавшего > спецификацию механизма работы. Механизм не работает, но про это никаким > образом, кроме телепатического, догадаться было нельзя (опять же, > неконкретный стон в ltsp-server не считается). > > L> И можно поднимать другие вопросы, который в своё время "замяли"? > > Замятые не по существу вопросы всегда можно и нужно поднимать, пока не > станет понятно, в чём вообще состоит проблема. Вот как раз с "всегда" и "нужно" - проблема (у меня). К сожалению, у меня нет привычки и желания "зудеть и надоедать пока не обратят внимания" - я жадный и мне жаль на это времени :( -- Led
[-- Attachment #1: Type: text/plain, Size: 2582 bytes --] Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: L> А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз L> повторяю: пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным L> sisyphus_check. L> Но в систему он если и устанавливается (?), то только "с бубном". Отлично, тогда вообще письмо at@ было не в тему. Забыли про него. L> И все "танцы с бубном" идут насмарку при первом же apt-get L> dist-upgrade (вопросительные знаки, потому что я не помню все L> детали, бинаного udev108 у меня уже нет, а собрать его из L> существующего udev108.spec не представляется возможным из-за L> "странностей" текущей klibc). А повторять всё "с нуля" чисто из L> академического интереса желания у меня нет, пока не будет хотя бы L> 90%-ной уверенности, что данный тред не закончится как и предидущие L> (т.е. ничем) :( Если его закончить ничем, то он и закончится ничем. А если довести до нормального багрепорта, то он не закончится ничем. В том треде ничего не говорилось про то, что два udev'а не могут сосуществовать. Если что-то глючит - надо воспроизвести и отрепортить. Иначе оно так и будет кривым до скончания веков, создавая поводы для брюзжания и мешая. >> Замятые не по существу вопросы всегда можно и нужно поднимать, пока не >> станет понятно, в чём вообще состоит проблема. L> Вот как раз с "всегда" и "нужно" - проблема (у меня). К сожалению, у меня нет L> привычки и желания "зудеть и надоедать пока не обратят внимания" - я жадный и L> мне жаль на это времени :( -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
[-- Attachment #1: Type: text/plain, Size: 564 bytes --] Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: L> Вот как раз с "всегда" и "нужно" - проблема (у меня). К сожалению, у L> меня нет привычки и желания "зудеть и надоедать пока не обратят L> внимания" - я жадный и мне жаль на это времени :( Значит, workaround'ы плодить и потом сопровождать их годами времени не жаль? :) -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 02:27:49 Mikhail Gusarov wrote:
> Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
> L> А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз
> L> повторяю: пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным
> L> sisyphus_check.
>
> L> Но в систему он если и устанавливается (?), то только "с бубном".
>
> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо (ответ на
пост @at) в рассылку. Естественно, там нет подробностей,
разжёвывающих "почему так происходит" - at@ они не нужны были, он ведь в
контексте того, что он делает:)
--
Led
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --] Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него. L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей, L> разжёвывающих "почему так происходит" - at@ они не нужны были, он L> ведь в контексте того, что он делает:) Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про sisyphus_check. В общем, осталось только разобраться, почему apt-у плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по недоразумению, вопросов нет. -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 02:29:05 Mikhail Gusarov wrote:
> Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
> L> Вот как раз с "всегда" и "нужно" - проблема (у меня). К сожалению, у
> L> меня нет привычки и желания "зудеть и надоедать пока не обратят
> L> внимания" - я жадный и мне жаль на это времени :(
>
> Значит, workaround'ы плодить и потом сопровождать их годами времени не
> жаль? :)
Вы знаете, а ведь так и есть: делать воркэраунды и пропатчить ядро, чтоб оно
работало с новым udev в своё время оказалось в несколько раз проще и заняло
на порядок меньше времени, чем попытки кого-то в чём-то убедить :(
--
Led
On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote: > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: > >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него. > > L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо > L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей, > L> разжёвывающих "почему так происходит" - at@ они не нужны были, он > L> ведь в контексте того, что он делает:) > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про > sisyphus_check. В общем, осталось только разобраться, почему apt-у > плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по > недоразумению, вопросов нет. Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение, что "udev сильно завязан на конкретную версию ядра" и предложение "привязывать" конкретные ядра с конкретными udev'ами. На что я и заметил, что это врядли получится из-за прибитых гвоздями в rpm костылей. Кстати, необходимость последних, кроме как "аргумента": "чтоб мейнтейнеры меньше ошибались", больше ничем не оправдывается? -- Led
[-- Attachment #1: Type: text/plain, Size: 673 bytes --] Twas brillig at 02:52:41 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble: L> Кстати, необходимость последних, кроме как "аргумента": "чтоб L> мейнтейнеры меньше ошибались", больше ничем не оправдывается? Пусть ответят прибивавшие. В архивах ничего не нашлось. У меня тоже вопрос возник: почему проверки для мейнтейнеров находятся в rpm (или apt? где оно там ломалось-то точно?), а не в sisyphus_check? -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 02:56:39 Mikhail Gusarov wrote:
> Twas brillig at 02:52:41 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
> L> Кстати, необходимость последних, кроме как "аргумента": "чтоб
> L> мейнтейнеры меньше ошибались", больше ничем не оправдывается?
>
> Пусть ответят прибивавшие. В архивах ничего не нашлось. У меня тоже
> вопрос возник: почему проверки для мейнтейнеров находятся в rpm (или
> apt? где оно там ломалось-то точно?), а не в sisyphus_check?
У меня есть подозрения, что подобные костыли появились во время
очередного "аврала/дистрибутив нужен на вчера":) Но утверждать не стану -
могу ошибаться.
--
Led
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --] On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote: > On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote: > > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre > and gimble: > > >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него. > > > > L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо > > L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей, > > L> разжёвывающих "почему так происходит" - at@ они не нужны были, он > > L> ведь в контексте того, что он делает:) > > > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про > > sisyphus_check. В общем, осталось только разобраться, почему apt-у > > плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по > > недоразумению, вопросов нет. > > Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение, > что "udev сильно завязан на конкретную версию ядра" и > предложение "привязывать" конкретные ядра с конкретными udev'ами. Как вы это себе представляете в свете того, что содержимое /etc/udev/rules.d/ размазано по пакетам? > На что я и заметил, что это врядли получится из-за прибитых гвоздями в rpm > костылей. Не надо называть удобный автогенератор зависимостей костылями. Вас могут понять неправильно. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 553 bytes --] Twas brillig at 04:01:04 10.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble: DVL> Как вы это себе представляете в свете того, что содержимое DVL> /etc/udev/rules.d/ размазано по пакетам? В случае сильной необходимости можно и /etc/udev_nnn/* добавить, и поручить его наполнять, опять же, мейнтейнеру udev_nnn, по результатам жалоб пользователей. -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
On Saturday, 10 January 2009 03:01:04 Dmitry V. Levin wrote: > On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote: > > On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote: > > > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did > > > gyre > > > > and gimble: > > > >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него. > > > > > > L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо > > > L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей, > > > L> разжёвывающих "почему так происходит" - at@ они не нужны были, он > > > L> ведь в контексте того, что он делает:) > > > > > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был > > > про sisyphus_check. В общем, осталось только разобраться, почему apt-у > > > плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по > > > недоразумению, вопросов нет. > > > > Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение, > > что "udev сильно завязан на конкретную версию ядра" и > > предложение "привязывать" конкретные ядра с конкретными udev'ами. > > Как вы это себе представляете в свете того, что содержимое > /etc/udev/rules.d/ размазано по пакетам? Я себе представляю (и вы, наверное, тоже, хоть и не хотите в этом признаться), что вариант ставить зависимость на каталог, а не на пакет, безусловно имеет право на существование, но этот вариант не является "серебрянной пулей" и универсальным на ВСЕ случаи жизни:) > > > На что я и заметил, что это врядли получится из-за прибитых гвоздями в > > rpm костылей. > > Не надо называть удобный автогенератор зависимостей костылями. > Вас могут понять неправильно. Почему же - поняли правильно. А вот реакция... в общем - не удивила:) -- Led
On Saturday, 10 January 2009 03:09:04 Led wrote:
> On Saturday, 10 January 2009 03:01:04 Dmitry V. Levin wrote:
> > On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote:
> > > On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote:
> > > > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did
> > > > gyre
> > >
> > > and gimble:
> > > > >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
> > > >
> > > > L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
> > > > L> (ответ на пост @at) в рассылку. Естественно, там нет
> > > > подробностей, L> разжёвывающих "почему так происходит" - at@ они не
> > > > нужны были, он L> ведь в контексте того, что он делает:)
> > > >
> > > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был
> > > > про sisyphus_check. В общем, осталось только разобраться, почему
> > > > apt-у плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто
> > > > по недоразумению, вопросов нет.
> > >
> > > Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение,
> > > что "udev сильно завязан на конкретную версию ядра" и
> > > предложение "привязывать" конкретные ядра с конкретными udev'ами.
> >
> > Как вы это себе представляете в свете того, что содержимое
> > /etc/udev/rules.d/ размазано по пакетам?
>
> Я себе представляю (и вы, наверное, тоже, хоть и не хотите в этом
> признаться), что вариант ставить зависимость на каталог, а не на пакет,
> безусловно имеет право на существование, но этот вариант не является
> "серебрянной пулей" и универсальным на ВСЕ случаи жизни:)
Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
Provides: /etc/udev/rules.d/
будет в пакете udev rules, а не в 0common-files.req.list?
--
Led
[-- Attachment #1: Type: text/plain, Size: 556 bytes --] * Led <ledest@> [090110 04:18]: > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/. > Provides: /etc/udev/rules.d/ > будет в пакете udev rules, а не в 0common-files.req.list? А эта фраза вообще смысла не имеет. В общем прежде чем критиковать (в очередной раз), было бы неплохо побольше узнать о критикуемом предмете. Кстати, об'яснение от создателя этого механизма не так давно было в этой рассылке (или я перепутал и это было в IRC). -- Regards, Sir Raorn. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
On Saturday, 10 January 2009 16:12:21 Alexey I. Froloff wrote: > * Led <ledest@> [090110 04:18]: > > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если > > Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/. > > > Provides: /etc/udev/rules.d/ > > будет в пакете udev rules, а не в 0common-files.req.list? > > А эта фраза вообще смысла не имеет. > > В общем прежде чем критиковать (в очередной раз), было бы неплохо > побольше узнать о критикуемом предмете. Я не критиковал, а просто спросил (нижайше попросив прощения, перед тем как спрашивать)! Сколько ещё раз нужно поприседать и сказать "Ку!" перед тем как что-то спросить? > Кстати, об'яснение от > создателя этого механизма не так давно было в этой рассылке (или > я перепутал и это было в IRC). -- Led
[-- Attachment #1: Type: text/plain, Size: 922 bytes --] Задача 1: Есть устройства, скажем A и B. Каждое из них может быть установлено в компьютер в количестве от 0 до количества слотов :) Они могут быть установлены как по отдельности, так и вместе. Однако если они установлены вместе, нобходимо чтобы драйвер для A загрузился раньше чем драйвер для B. Задача 2: Усложняем -- это не A и B, это больше десятка разных устройств со своими драйверами. Задача 3: Есть еще initscipt. К моменту запуска этого initscript'а модули для всех этих устройств, если они установлены в компьютер, должны быть загружены. Как такое решать? Поясняю зачем это -- для драйверов DAHDI (телефония). Из-за особенностей адресации в DAHDI сильно желательно чтобы драйвера для E1 загружались раньше, чем драйвера для аналоговых интерфейсов. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
On Tuesday, 22 December 2009 01:44:38 Денис Смирнов wrote:
> Задача 1:
>
> Есть устройства, скажем A и B. Каждое из них может быть установлено в
> компьютер в количестве от 0 до количества слотов :) Они могут быть
> установлены как по отдельности, так и вместе.
>
> Однако если они установлены вместе, нобходимо чтобы драйвер для A
> загрузился раньше чем драйвер для B.
>
> Задача 2:
>
> Усложняем -- это не A и B, это больше десятка разных устройств со своими
> драйверами.
>
> Задача 3:
>
> Есть еще initscipt. К моменту запуска этого initscript'а модули для всех
> этих устройств, если они установлены в компьютер, должны быть загружены.
>
>
> Как такое решать?
>
> Поясняю зачем это -- для драйверов DAHDI (телефония). Из-за особенностей
> адресации в DAHDI сильно желательно чтобы драйвера для E1 загружались
> раньше, чем драйвера для аналоговых интерфейсов.
Модули, указанные в /etc/modules загружаются в в порядке следования
в /etc/modules и до запуска системного udev.
--
Led
22.12.2009 02:44, Денис Смирнов пишет:
> Задача 1:
>
> Есть устройства, скажем A и B. Каждое из них может быть установлено в
> компьютер в количестве от 0 до количества слотов :) Они могут быть
> установлены как по отдельности, так и вместе.
>
> Однако если они установлены вместе, нобходимо чтобы драйвер для A
> загрузился раньше чем драйвер для B.
Как тебе уже сказали - нужно просто прописать необходимые модули в
порядке загрузки в /etc/modules
[-- Attachment #1: Type: text/plain, Size: 657 bytes --] On Tue, Dec 22, 2009 at 01:59:39AM +0200, Led wrote: > Модули, указанные в /etc/modules загружаются в в порядке следования > в /etc/modules и до запуска системного udev. Но следует учитывать, что в случае, если загружаемые таким образом модули требуют подгрузки firmware в момент их загрузки, firmware не загрузится как раз из-за незапущенного udevd. Модули такого рода в текущем состоянии системы можно загружать только из initramfs (через mkinitrd --with $module) - там udevd запускается до загрузки модулей, но udevadm trigger (вызывающий загрузку модулей в неопределённом порядке) вызывается после обработки явно заданного списка модулей. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 895 bytes --] On Tue, Dec 22, 2009 at 10:09:15AM +0300, Anton Farygin wrote: AF> Как тебе уже сказали - нужно просто прописать необходимые модули в AF> порядке загрузки в /etc/modules Мне эта идея сильно не нравится вот почему: Этап 1: пользователь устанавливает систему Этап 2: пользователь втыкает устройства Этап 3: пользователь включает машину -- и, опаньки, приехали На машинах где я админ я могу все сделать сам. А дистрибутивно - не могу придумать как. Разве что наиболее мерзким и грязным хаком -- в initscript'е lsmod'ом смотреть загруженные модули, и насильно их выгружать, а потом загружать в правильном порядке. Могу ли я при этом быть увереным что на момент запуска initscript'а udev свои развлечения с подгрузкой драйверов уже закончил? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 818 bytes --] On Tue, Dec 22, 2009 at 12:54:57PM +0300, Sergey Vlasov wrote: SV> Но следует учитывать, что в случае, если загружаемые таким образом SV> модули требуют подгрузки firmware в момент их загрузки, firmware не SV> загрузится как раз из-за незапущенного udevd. Модули такого рода в SV> текущем состоянии системы можно загружать только из initramfs (через SV> mkinitrd --with $module) - там udevd запускается до загрузки модулей, SV> но udevadm trigger (вызывающий загрузку модулей в неопределённом SV> порядке) вызывается после обработки явно заданного списка модулей. Часть из них с firmware. Значит остается только единственный разумный путь -- делать все в initscript'е? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 414 bytes --] On Tue, Dec 22, 2009 at 12:54:57PM +0300, Sergey Vlasov wrote: А можно запретить udev'у подгружать эти модули автоматом, чтобы я из initscript'а не страдал выгрузкой -- а с помощью lspci посмотрел какие модули требуются, отсортировал их в правильном порядке, а потом загрузил? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 519 bytes --] On Tue, Dec 22, 2009 at 04:25:27PM +0300, Денис Смирнов wrote: > On Tue, Dec 22, 2009 at 12:54:57PM +0300, Sergey Vlasov wrote: > > А можно запретить udev'у подгружать эти модули автоматом, чтобы я из > initscript'а не страдал выгрузкой -- а с помощью lspci посмотрел какие > модули требуются, отсортировал их в правильном порядке, а потом загрузил? Можно - blacklist $module где-нибудь в /etc/modprobe.d/*.conf (надо использовать имена вида *.conf для совместимости с будущими версиями module-init-tools). [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --] В Втр, 22/12/2009 в 16:34 +0300, Sergey Vlasov пишет: > On Tue, Dec 22, 2009 at 04:25:27PM +0300, Денис Смирнов wrote: > > On Tue, Dec 22, 2009 at 12:54:57PM +0300, Sergey Vlasov wrote: > > > > А можно запретить udev'у подгружать эти модули автоматом, чтобы я из > > initscript'а не страдал выгрузкой -- а с помощью lspci посмотрел какие > > модули требуются, отсортировал их в правильном порядке, а потом загрузил? > > Можно - blacklist $module где-нибудь в /etc/modprobe.d/*.conf (надо > использовать имена вида *.conf для совместимости с будущими версиями > module-init-tools). если ты не планируешь собирать module-init-tools, то будущих версий у нас не предвидится -- Valery V. Inozemtsev [-- Attachment #2: Эта часть сообщения подписана цифровой подписью --] [-- Type: application/pgp-signature, Size: 198 bytes --]
On Tue, Dec 22, 2009 at 04:23:32PM +0300, Денис Смирнов wrote: > Могу ли я при этом быть увереным что на момент запуска > initscript'а udev свои развлечения с подгрузкой драйверов > уже закончил? udevadm settle? -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 238 bytes --] On Tue, Dec 22, 2009 at 04:50:44PM +0200, Michael Shigorin wrote: MS> udevadm settle? Оно, спасибо. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1: Type: text/plain, Size: 487 bytes --] On Tue, Dec 22, 2009 at 04:34:42PM +0300, Sergey Vlasov wrote: SV> Можно - blacklist $module где-нибудь в /etc/modprobe.d/*.conf (надо SV> использовать имена вида *.conf для совместимости с будущими версиями SV> module-init-tools). Спасибо! Правильно ли я понял, что udev и вся прочая хитрумная автоматика вызывает modprobe c --use-blacklist? -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 424 bytes --] Привет всем. Собрал я пакет для связи с айфоном по USB, но почему-то его правила не отрабатываются udev, https://git.altlinux.org/tasks/archive/done/_293/300393/ Прилагаю два лога udevadmin Если есть возможность, поправьте меня. === С уважением, Хихин Руслан [-- Attachment #1.1.2: udevadm_add_iphone.log --] [-- Type: text/x-log, Size: 6072 bytes --] # udevadm monitor -p monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[315.417897] add /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/007 DEVTYPE=usb_device PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=007 SEQNUM=3347 MAJOR=189 MINOR=262 KERNEL[315.425912] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3348 KERNEL[315.426042] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 (wakeup) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 SUBSYSTEM=wakeup SEQNUM=3349 KERNEL[315.426125] bind /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=bind DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/007 DEVTYPE=usb_device DRIVER=apple-mfi-fastcharge PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=007 SEQNUM=3350 MAJOR=189 MINOR=262 KERNEL[315.426368] remove /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3351 KERNEL[315.437004] change /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge (power_supply) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge SUBSYSTEM=power_supply POWER_SUPPLY_NAME=apple_mfi_fastcharge POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_CHARGE_TYPE=Trickle POWER_SUPPLY_SCOPE=Device SEQNUM=3352 UDEV [315.464527] add /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/007 DEVTYPE=usb_device PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=007 SEQNUM=3347 USEC_INITIALIZED=315442495 USBMUX_SUPPORTED=1 SYSTEMD_WANTS=usbmuxd.service ID_VENDOR=Apple_Inc. ID_VENDOR_ENC=Apple\x20Inc. ID_VENDOR_ID=05ac ID_MODEL=iPhone ID_MODEL_ENC=iPhone ID_MODEL_ID=12a8 ID_REVISION=1108 ID_SERIAL=Apple_Inc._iPhone_000080200004558E21D2002E ID_SERIAL_SHORT=000080200004558E21D2002E ID_BUS=usb ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01: ID_GPHOTO2=1 GPHOTO2_DRIVER=PTP ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE ID_PATH=pci-0000:00:10.0-usb-0:1 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1 DRIVER=apple-mfi-fastcharge ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1 COLORD_DEVICE=1 COLORD_KIND=camera MAJOR=189 MINOR=262 TAGS=:systemd:uaccess:seat: CURRENT_TAGS=:systemd:uaccess:seat: UDEV [315.472859] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3348 USEC_INITIALIZED=315470028 GPHOTO2_DRIVER=PTP ID_GPHOTO2=1 ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE adb_user=yes ID_PATH=pci-0000:00:10.0-usb-0:1:1.0 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1_1_0 ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1_1_0 COLORD_DEVICE=1 COLORD_KIND=camera TAGS=:uaccess:seat: CURRENT_TAGS=:uaccess:seat: UDEV [315.473580] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 (wakeup) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 SUBSYSTEM=wakeup SEQNUM=3349 USEC_INITIALIZED=315473505 UDEV [315.483655] bind /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=bind DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/007 DEVTYPE=usb_device DRIVER=apple-mfi-fastcharge PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=007 SEQNUM=3350 USEC_INITIALIZED=315442495 USBMUX_SUPPORTED=1 SYSTEMD_WANTS=usbmuxd.service ID_VENDOR=Apple_Inc. ID_VENDOR_ENC=Apple\x20Inc. ID_VENDOR_ID=05ac ID_MODEL=iPhone ID_MODEL_ENC=iPhone ID_MODEL_ID=12a8 ID_REVISION=1108 ID_SERIAL=Apple_Inc._iPhone_000080200004558E21D2002E ID_SERIAL_SHORT=000080200004558E21D2002E ID_BUS=usb ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01: ID_GPHOTO2=1 GPHOTO2_DRIVER=PTP ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE ID_PATH=pci-0000:00:10.0-usb-0:1 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1 ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1 COLORD_DEVICE=1 COLORD_KIND=camera MAJOR=189 MINOR=262 TAGS=:systemd:uaccess:seat: CURRENT_TAGS=:systemd:uaccess:seat: UDEV [315.486417] remove /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3351 USEC_INITIALIZED=315470028 GPHOTO2_DRIVER=PTP ID_GPHOTO2=1 ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE adb_user=yes ID_PATH=pci-0000:00:10.0-usb-0:1:1.0 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1_1_0 ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1_1_0 COLORD_DEVICE=1 COLORD_KIND=camera TAGS=:uaccess:seat: CURRENT_TAGS=:uaccess:seat: UDEV [315.489317] change /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge (power_supply) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge SUBSYSTEM=power_supply POWER_SUPPLY_NAME=apple_mfi_fastcharge POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_CHARGE_TYPE=Trickle POWER_SUPPLY_SCOPE=Device SEQNUM=3352 USEC_INITIALIZED=315489207 [-- Attachment #1.1.3: udevadm_add_iphone2.log --] [-- Type: text/x-log, Size: 4957 bytes --] udevadm monitor -p monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent KERNEL[807.281139] add /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/009 DEVTYPE=usb_device PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=009 SEQNUM=3369 MAJOR=189 MINOR=264 KERNEL[807.290630] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3370 KERNEL[807.290761] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 (wakeup) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 SUBSYSTEM=wakeup SEQNUM=3371 KERNEL[807.290870] bind /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=bind DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/009 DEVTYPE=usb_device DRIVER=apple-mfi-fastcharge PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=009 SEQNUM=3372 MAJOR=189 MINOR=264 KERNEL[807.300895] change /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge (power_supply) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge SUBSYSTEM=power_supply POWER_SUPPLY_NAME=apple_mfi_fastcharge POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_CHARGE_TYPE=Trickle POWER_SUPPLY_SCOPE=Device SEQNUM=3373 UDEV [807.333747] add /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/009 DEVTYPE=usb_device PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=009 SEQNUM=3369 USEC_INITIALIZED=807314147 ID_VENDOR=Apple_Inc. ID_VENDOR_ENC=Apple\x20Inc. ID_VENDOR_ID=05ac ID_MODEL=iPhone ID_MODEL_ENC=iPhone ID_MODEL_ID=12a8 ID_REVISION=1108 ID_SERIAL=Apple_Inc._iPhone_000080200004558E21D2002E ID_SERIAL_SHORT=000080200004558E21D2002E ID_BUS=usb ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01: ID_GPHOTO2=1 GPHOTO2_DRIVER=PTP ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE ID_PATH=pci-0000:00:10.0-usb-0:1 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1 DRIVER=apple-mfi-fastcharge ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1 COLORD_DEVICE=1 COLORD_KIND=camera MAJOR=189 MINOR=264 TAGS=:seat:uaccess: CURRENT_TAGS=:seat:uaccess: UDEV [807.339372] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/3-1:1.0 SUBSYSTEM=usb DEVTYPE=usb_interface PRODUCT=5ac/12a8/1108 TYPE=0/0/0 INTERFACE=6/1/1 MODALIAS=usb:v05ACp12A8d1108dc00dsc00dp00ic06isc01ip01in00 SEQNUM=3370 USEC_INITIALIZED=807338870 GPHOTO2_DRIVER=PTP ID_GPHOTO2=1 ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE adb_user=yes ID_PATH=pci-0000:00:10.0-usb-0:1:1.0 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1_1_0 ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1_1_0 COLORD_DEVICE=1 COLORD_KIND=camera TAGS=:seat:uaccess: CURRENT_TAGS=:seat:uaccess: UDEV [807.340091] add /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 (wakeup) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge/wakeup35 SUBSYSTEM=wakeup SEQNUM=3371 USEC_INITIALIZED=807339805 UDEV [807.364355] bind /devices/pci0000:00/0000:00:10.0/usb3/3-1 (usb) ACTION=bind DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/003/009 DEVTYPE=usb_device DRIVER=apple-mfi-fastcharge PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=003 DEVNUM=009 SEQNUM=3372 USEC_INITIALIZED=807314147 ID_VENDOR=Apple_Inc. ID_VENDOR_ENC=Apple\x20Inc. ID_VENDOR_ID=05ac ID_MODEL=iPhone ID_MODEL_ENC=iPhone ID_MODEL_ID=12a8 ID_REVISION=1108 ID_SERIAL=Apple_Inc._iPhone_000080200004558E21D2002E ID_SERIAL_SHORT=000080200004558E21D2002E ID_BUS=usb ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01: ID_GPHOTO2=1 GPHOTO2_DRIVER=PTP ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE ID_PATH=pci-0000:00:10.0-usb-0:1 ID_PATH_TAG=pci-0000_00_10_0-usb-0_1 ID_FOR_SEAT=usb-pci-0000_00_10_0-usb-0_1 COLORD_DEVICE=1 COLORD_KIND=camera MAJOR=189 MINOR=264 TAGS=:seat:uaccess: CURRENT_TAGS=:seat:uaccess: UDEV [807.367095] change /devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge (power_supply) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:10.0/usb3/3-1/power_supply/apple_mfi_fastcharge SUBSYSTEM=power_supply POWER_SUPPLY_NAME=apple_mfi_fastcharge POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_CHARGE_TYPE=Trickle POWER_SUPPLY_SCOPE=Device SEQNUM=3373 USEC_INITIALIZED=807366985 [-- Attachment #1.1.4: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
22 мая 2022 г. 14:07:54 GMT+03:00, Ruslandh <ruslandh@gmail.com> пишет:
>Привет всем.
>
>Собрал я пакет для связи с айфоном по USB, но почему-то его правила не
>отрабатываются udev,
>
>https://git.altlinux.org/tasks/archive/done/_293/300393/
>
>Прилагаю два лога udevadmin
>
>
>Если есть возможность, поправьте меня.
Я не нашёл в логах ничего, что могло бы совпасть с
ENV{ID_USB_DRIVER}=="ipheth"
[-- Attachment #1.1.1: Type: text/plain, Size: 592 bytes --] 22.05.2022 15:37, Paul Wolneykien пишет: > 22 мая 2022 г. 14:07:54 GMT+03:00, Ruslandh <ruslandh@gmail.com> пишет: >> Привет всем. >> >> Собрал я пакет для связи с айфоном по USB, но почему-то его правила не >> отрабатываются udev, >> >> https://git.altlinux.org/tasks/archive/done/_293/300393/ >> >> Прилагаю два лога udevadmin >> >> >> Если есть возможность, поправьте меня. > И я тоже, вот этого я и не пойму ;-) [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 15247 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
On Sunday, 22 May 2022 14:07:54 MSK Ruslandh wrote:
[...]
> https://git.altlinux.org/tasks/archive/done/_293/300393/
>
> Прилагаю два лога udevadmin
>
>
> Если есть возможность, поправьте меня.
Разве файл ipheth-modprobe.conf ни на что не намекает?
--
Regards, Sergey.
[-- Attachment #1.1.1: Type: text/plain, Size: 545 bytes --] 23.05.2022 17:37, Sergey V Turchin пишет: > On Sunday, 22 May 2022 14:07:54 MSK Ruslandh wrote: > > [...] >> https://git.altlinux.org/tasks/archive/done/_293/300393/ >> >> Прилагаю два лога udevadmin >> >> >> Если есть возможность, поправьте меня. > Разве файл ipheth-modprobe.conf ни на что не намекает? > Там ошибка, но исправление её не помогает, я загружаю ipheth, и всё по-прежнему [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
On Monday, 23 May 2022 18:26:01 MSK Ruslandh wrote: [...] > > Разве файл ipheth-modprobe.conf ни на что не намекает? > Там ошибка, но исправление её не помогает, > я загружаю ipheth В репозитории не вижу. Самосбор? > , и всё по-прежнему Да и ipheth-modprobe.conf в оригинале сильно отличается. -- Regards, Sergey.
[-- Attachment #1.1.1: Type: text/plain, Size: 524 bytes --] 24.05.2022 10:24, Sergey V Turchin пишет: >> , и всё по-прежнему > Да и ipheth-modprobe.conf в оригинале сильно отличается. Еще раз взглянул: Не могу найти /usr/local/bin/ipheth-pair.py нигде в инете # iPhone USB Ethernet Driver # # This configuration forces modprobe to execute device pairing script after # loading the driver. install ipheth /sbin/modprobe --ignore-install ipheth && /usr/local/bin/ipheth-pair.py [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
On Tuesday, 24 May 2022 16:53:24 MSK Ruslandh wrote:
> 24.05.2022 10:24, Sergey V Turchin пишет:
>
> >> , и всё по-прежнему
> >
> > Да и ipheth-modprobe.conf в оригинале сильно отличается.
> Еще раз взглянул:
> Не могу найти /usr/local/bin/ipheth-pair.py нигде в инете
> # iPhone USB Ethernet Driver
> #
> # This configuration forces modprobe to execute device pairing script after
> # loading the driver.
> install ipheth /sbin/modprobe --ignore-install ipheth &&
> /usr/local/bin/ipheth-pair.py
А /usr/bin/ipheth-pair не подойдёт?
--
Regards, Sergey.
On Sunday, 22 May 2022 14:07:54 MSK Ruslandh wrote: > Привет всем. > > Собрал я пакет для связи с айфоном по USB, но почему-то его правила не > отрабатываются udev, > > https://git.altlinux.org/tasks/archive/done/_293/300393/ > > Прилагаю два лога udevadmin > > > Если есть возможность, поправьте меня. udevadm monitor и смотреть его в момент подключения устройства. > === > С уважением, Хихин Руслан -- Regards, Sergey.
[-- Attachment #1.1.1: Type: text/plain, Size: 1197 bytes --] 24.05.2022 17:12, Sergey V Turchin пишет: > On Tuesday, 24 May 2022 16:53:24 MSK Ruslandh wrote: >> 24.05.2022 10:24, Sergey V Turchin пишет: >> >>>> , и всё по-прежнему >>> >>> Да и ipheth-modprobe.conf в оригинале сильно отличается. >> Еще раз взглянул: >> Не могу найти /usr/local/bin/ipheth-pair.py нигде в инете >> # iPhone USB Ethernet Driver >> # >> # This configuration forces modprobe to execute device pairing script after >> # loading the driver. >> install ipheth /sbin/modprobe --ignore-install ipheth && >> /usr/local/bin/ipheth-pair.py > А /usr/bin/ipheth-pair не подойдёт? > Не, не подходит # modprobe ipheth /usr/bin/ipheth-pair: -3: cannot get default device modprobe: ERROR: Error running install command '/sbin/modprobe --ignore-install ipheth && /usr/bin/ipheth-pair' for module ipheth: retcode 255 modprobe: ERROR: could not insert 'ipheth': Invalid argument > udevadm monitor > и смотреть его в момент подключения устройств именно так и делаю udevadm monitor -p [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 422 bytes --] 24.05.2022 22:00, Dmitriy Khanzhin пишет: > Предположу, что Ваш iPhone цепляется как PTP-камера. > Во всяком случае, по логу очень похоже. > Устройство создается? С какими правами? > Нет, не создаётся, для создания устройства , в теории нужны ещё пакеты [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --] 24.05.2022 17:21, Ruslandh пишет: > 24.05.2022 17:12, Sergey V Turchin пишет: >> On Tuesday, 24 May 2022 16:53:24 MSK Ruslandh wrote: >>> 24.05.2022 10:24, Sergey V Turchin пишет: >>> >>>>> , и всё по-прежнему >>>> >>>> Да и ipheth-modprobe.conf в оригинале сильно отличается. >>> Еще раз взглянул: >>> Не могу найти /usr/local/bin/ipheth-pair.py нигде в инете >>> # iPhone USB Ethernet Driver >>> # >>> # This configuration forces modprobe to execute device pairing >>> script after >>> # loading the driver. >>> install ipheth /sbin/modprobe --ignore-install ipheth && >>> /usr/local/bin/ipheth-pair.py >> А /usr/bin/ipheth-pair не подойдёт? >> > Не, не подходит > > # modprobe ipheth > > /usr/bin/ipheth-pair: -3: cannot get default device > modprobe: ERROR: Error running install command '/sbin/modprobe > --ignore-install ipheth && /usr/bin/ipheth-pair' for module ipheth: > retcode 255 А почему /usr/bin? Из Makefile: install -m 0644 90-iphone-tether.rules /lib/udev/rules.d Патч из Debian прилагаю. > modprobe: ERROR: could not insert 'ipheth': Invalid argument > > > > udevadm monitor > > и смотреть его в момент подключения устройств > > именно так и делаю > udevadm monitor -p > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Best regards, Leonid Krivoshein. [-- Attachment #2: modprobe-conf-fix.patch --] [-- Type: text/x-patch, Size: 417 bytes --] --- ipheth-1.0+git20111206.orig/ipheth-driver/ipheth-modprobe.conf +++ ipheth-1.0+git20111206/ipheth-driver/ipheth-modprobe.conf @@ -3,5 +3,4 @@ # This configuration forces modprobe to execute device pairing script after # loading the driver. -install ipheth /sbin/modprobe --ignore-install ipheth && /usr/local/bin/ipheth-pair.py - +install ipheth /sbin/modprobe --ignore-install ipheth && /lib/udev/ipheth-pair
25.05.2022 02:54, Leonid Krivoshein пишет:
> install -m 0644 90-iphone-tether.rules /lib/udev/rules.d
Не ту строку схватил, сорри!
install -m 0755 ipheth-pair /lib/udev/
--
Best regards,
Leonid Krivoshein.
[-- Attachment #1.1.1: Type: text/plain, Size: 982 bytes --] 25.05.2022 02:55, Leonid Krivoshein пишет: > > 25.05.2022 02:54, Leonid Krivoshein пишет: >> install -m 0644 90-iphone-tether.rules /lib/udev/rules.d > Не ту строку схватил, сорри! > > install -m 0755 ipheth-pair /lib/udev/ Привёл https://git.altlinux.org/people/ruslandh/packages/?p=udev-ipheth.git;a=summary к тому что есть на компе. И собрал его для Сизифа в таком состоянии. В кармане https://git.altlinux.org/tasks/300577/ версия для p10. Что-то я начал подозревать, что дело глубже и проблема в поддержке ipheth моего айфона, так-как запуск напрямую ipheth-pair --list говорит : $ /lib/udev/ipheth-pair --help usage: /lib/udev/ipheth-pair [--list] [--uuid UUID] [--oldc] $ /lib/udev/ipheth-pair --list /lib/udev/ipheth-pair: -3: no devices [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 1702 bytes --] 25.05.2022 00:03, Ruslandh пишет: > 24.05.2022 22:00, Dmitriy Khanzhin пишет: >> Предположу, что Ваш iPhone цепляется как PTP-камера. >> Во всяком случае, по логу очень похоже. >> Устройство создается? С какими правами? >> > > Нет, не создаётся, для создания устройства , в теории нужны ещё пакеты И всё-таки, как мне убедиться, что до правила udev доходит очередь ? Создаю такой файл udev (для отладки) # udev rules for setting correct configuration and pairing on tethered iPhones ATTR{idVendor}!="05ac", GOTO="ipheth_rules_end" # Execute pairing program when appropriate SUBSYSTEM=="usb", ENV{ID_V4L_PRODUCT}!="", ENV{COLORD_DEVICE}="0",\ ENV{COLORD_KIND}="", RUN+="echo "Yes"> /tmp/yes" #ACTION=="add", SUBSYSTEM=="net", ENV{ID_USB_DRIVER}=="ipheth",\ SYMLINK+="iphone", RUN+="ipheth-pair" LABEL="ipheth_rules_end" Он будет отрабатывать echo "Yes"> /tmp/yes", если udev увидит ATTR{idVendor}!="05ac"? Тут нет ошибки ? Хочу номер ему или уменьшить, или наоборот увеличить. Потому, что у меня 2 варианта, почему не хватается айфон: 1. эта модель не поддерживается ядром, а с пакетом всё нормально. 2. правило udev должна иметь другой номер. И надо понять, с чем я имею дело. [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 1479 bytes --] 25.05.2022 16:57, Ruslandh пишет: > 25.05.2022 00:03, Ruslandh пишет: Ruslandh, [25.05.2022 17:30] SUBSYSTEM=="usb", DRIVER=="usb", ATTR{idVendor}=="05ac", ATTR{idProduct}=="12a8", SYMLINK+="iphone", RUN+="ipheth-pair" Вот такое правило у меня создаёт symlink, но в логах его отработки я вижу : UDEV [23998.480307] add /devices/pci0000:00/0000:00:07.0/0000:02:00.0/usb4/4-1/4-1.3 (usb) ACTION=add DEVPATH=/devices/pci0000:00/0000:00:07.0/0000:02:00.0/usb4/4-1/4-1.3 SUBSYSTEM=usb DEVNAME=/dev/bus/usb/004/021 DEVTYPE=usb_device PRODUCT=5ac/12a8/1108 TYPE=0/0/0 BUSNUM=004 DEVNUM=021 SEQNUM=3216 USEC_INITIALIZED=23998458855 DRIVER=usb USBMUX_SUPPORTED=1 SYSTEMD_WANTS=usbmuxd.service ID_VENDOR=Apple_Inc. ID_VENDOR_ENC=Apple\x20Inc. ID_VENDOR_ID=05ac ID_MODEL=iPhone ID_MODEL_ENC=iPhone ID_MODEL_ID=12a8 ID_REVISION=1108 ID_SERIAL=Apple_Inc._iPhone_000080200004558E21D2002E ID_SERIAL_SHORT=000080200004558E21D2002E ID_BUS=usb ID_USB_INTERFACES=:060101:010100:010200:030000:fffe02:fffd01: ID_GPHOTO2=1 GPHOTO2_DRIVER=PTP ID_VENDOR_FROM_DATABASE=Apple, Inc. ID_MODEL_FROM_DATABASE=iPhone 5/5C/5S/6/SE ID_PATH=pci-0000:02:00.0-usb-0:1.3 ID_PATH_TAG=pci-0000_02_00_0-usb-0_1_3 ID_FOR_SEAT=usb-pci-0000_02_00_0-usb-0_1_3 COLORD_DEVICE=1 COLORD_KIND=camera MAJOR=189 MINOR=404 DEVLINKS=/dev/iphone TAGS=:seat:systemd:uaccess: CURRENT_TAGS=:seat:systemd:uaccess: [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
On Wed, May 25, 2022 at 04:57:19PM +0300, Ruslandh wrote:
> Создаю такой файл udev (для отладки)
>
> # udev rules for setting correct configuration and pairing on tethered
> iPhones
> ATTR{idVendor}!="05ac", GOTO="ipheth_rules_end"
>
> # Execute pairing program when appropriate
> SUBSYSTEM=="usb", ENV{ID_V4L_PRODUCT}!="", ENV{COLORD_DEVICE}="0",\
> ENV{COLORD_KIND}="", RUN+="echo "Yes"> /tmp/yes"
> #ACTION=="add", SUBSYSTEM=="net", ENV{ID_USB_DRIVER}=="ipheth",\
> SYMLINK+="iphone", RUN+="ipheth-pair"
>
> LABEL="ipheth_rules_end"
Тут еще есть условие ENV{ID_V4L_PRODUCT}!="", а такого поля в
ваших логах я не вижу. Зачем это условие было добавлено?
Я не большой специалист по udev, но мне всегда казалось,
что он очень прямолинеен: пишешь условие, если оно выполняется,
то и правило исполняется.
Ну и еще пара общих вещей про правила udev rules (я плохо
чувствую, насколько такие вещи общеизвестны, прошу прощения, если пишу
тривиальное):
- При подключении у вас возникает целое дерево usb-устройств,
надо написать такие условия, чтобы выбрать нужное.
- Разные атрибуты устройств удобно смотреть командой
udevadm info -a -p /sys/bus/usb/devices/...
- ATTR и ATTRS это разные ключи (действуют на одно устройство
и на устройство со всеми его родителями)
- операторы == и = - это разные вещи (зачем, например, у
вас в этом тестовом примере есть =, если вы только хотите запустить
echo?)
On Wed, May 25, 2022 at 07:31:40PM +0300, Vladislav Zavjalov wrote:
> On Wed, May 25, 2022 at 04:57:19PM +0300, Ruslandh wrote:
> > Создаю такой файл udev (для отладки)
> >
> > # udev rules for setting correct configuration and pairing on tethered
> > iPhones
> > ATTR{idVendor}!="05ac", GOTO="ipheth_rules_end"
> >
> > # Execute pairing program when appropriate
> > SUBSYSTEM=="usb", ENV{ID_V4L_PRODUCT}!="", ENV{COLORD_DEVICE}="0",\
> > ENV{COLORD_KIND}="", RUN+="echo "Yes"> /tmp/yes"
> > #ACTION=="add", SUBSYSTEM=="net", ENV{ID_USB_DRIVER}=="ipheth",\
> > SYMLINK+="iphone", RUN+="ipheth-pair"
> >
> > LABEL="ipheth_rules_end"
>
> Тут еще есть условие ENV{ID_V4L_PRODUCT}!="", а такого поля в
> ваших логах я не вижу. Зачем это условие было добавлено?
>
> Я не большой специалист по udev, но мне всегда казалось,
> что он очень прямолинеен: пишешь условие, если оно выполняется,
> то и правило исполняется.
>
> Ну и еще пара общих вещей про правила udev rules (я плохо
> чувствую, насколько такие вещи общеизвестны, прошу прощения, если пишу
> тривиальное):
> - При подключении у вас возникает целое дерево usb-устройств,
> надо написать такие условия, чтобы выбрать нужное.
> - Разные атрибуты устройств удобно смотреть командой
> udevadm info -a -p /sys/bus/usb/devices/...
> - ATTR и ATTRS это разные ключи (действуют на одно устройство
> и на устройство со всеми его родителями)
> - операторы == и = - это разные вещи (зачем, например, у
> вас в этом тестовом примере есть =, если вы только хотите запустить
> echo?)
- А ENV{...} - это не атрибут устройства, а переменная окружения,
информации об устройстве она не должна нести, если только ее
специально кто-то не установил. Я такой экзотикой никогда не
пользовался, но, наверное, может быть полезно.
[-- Attachment #1.1.1: Type: text/plain, Size: 2802 bytes --] 25.05.2022 19:46, Vladislav Zavjalov пишет: > On Wed, May 25, 2022 at 07:31:40PM +0300, Vladislav Zavjalov wrote: >> On Wed, May 25, 2022 at 04:57:19PM +0300, Ruslandh wrote: >>> Создаю такой файл udev (для отладки) >>> >>> # udev rules for setting correct configuration and pairing on tethered >>> iPhones >>> ATTR{idVendor}!="05ac", GOTO="ipheth_rules_end" >>> >>> # Execute pairing program when appropriate >>> SUBSYSTEM=="usb", ENV{ID_V4L_PRODUCT}!="", ENV{COLORD_DEVICE}="0",\ >>> ENV{COLORD_KIND}="", RUN+="echo "Yes"> /tmp/yes" >>> #ACTION=="add", SUBSYSTEM=="net", ENV{ID_USB_DRIVER}=="ipheth",\ >>> SYMLINK+="iphone", RUN+="ipheth-pair" >>> >>> LABEL="ipheth_rules_end" >> Тут еще есть условие ENV{ID_V4L_PRODUCT}!="", а такого поля в >> ваших логах я не вижу. Зачем это условие было добавлено? >> >> Я не большой специалист по udev, но мне всегда казалось, >> что он очень прямолинеен: пишешь условие, если оно выполняется, >> то и правило исполняется. >> >> Ну и еще пара общих вещей про правила udev rules (я плохо >> чувствую, насколько такие вещи общеизвестны, прошу прощения, если пишу >> тривиальное): >> - При подключении у вас возникает целое дерево usb-устройств, >> надо написать такие условия, чтобы выбрать нужное. >> - Разные атрибуты устройств удобно смотреть командой >> udevadm info -a -p /sys/bus/usb/devices/... >> - ATTR и ATTRS это разные ключи (действуют на одно устройство >> и на устройство со всеми его родителями) >> - операторы == и = - это разные вещи (зачем, например, у >> вас в этом тестовом примере есть =, если вы только хотите запустить >> echo?) > >- А ENV{...} - это не атрибут устройства, а переменная окружения, > >информации об устройстве она не должна нести, если только ее > >специально кто-то не установил. Я такой экзотикой никогда не > >пользовался, но, наверное, может быть полезно. > > > > Спасибо, уже изучаю https://russianblogs.com/article/85191544984/ ;-) [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 15247 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
On Wed, May 25, 2022 at 08:21:11PM +0300, P X wrote: > Спасибо, уже изучаю https://russianblogs.com/article/85191544984/ ;-) Мне еще вот этот текст понравился (хотя он довольно старый): http://www.reactivated.net/writing_udev_rules.html
[-- Attachment #1.1.1: Type: text/plain, Size: 410 bytes --] 25.05.2022 21:22, Vladislav Zavjalov пишет: >> Спасибо, уже изучаюhttps://russianblogs.com/article/85191544984/ ;-) > Мне еще вот этот текст понравился (хотя он довольно старый): > http://www.reactivated.net/writing_udev_rules.html > На английском, наверное самым свежим будет man udev ;-) [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 15247 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 203 bytes --]
[-- Attachment #1.1.1: Type: text/plain, Size: 3239 bytes --] 25.05.2022 05:12, Ruslandh пишет: > 25.05.2022 02:55, Leonid Krivoshein пишет: >> >> 25.05.2022 02:54, Leonid Krivoshein пишет: Поставил в VirtualBox последнюю Ubuntu, вот так выглядит отработка правил UDEV в нём. По всему выходит, что у них другой модуль ядра ipref KERNEL[872.864143] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1 (usb) KERNEL[872.872042] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:1.0 (usb) KERNEL[872.872087] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge/wakeup12 (wakeup) KERNEL[872.872106] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge/hwmon2 (hwmon) KERNEL[872.872143] bind /devices/pci0000:00/0000:00:0b.0/usb1/1-1 (usb) KERNEL[872.873056] remove /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:1.0 (usb) KERNEL[872.886591] change /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge (power_supply) UDEV [872.934100] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1 (usb) KERNEL[872.964594] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.0 (usb) KERNEL[872.968593] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.1 (usb) KERNEL[872.968643] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2 (usb) KERNEL[872.972742] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/eth0 (net) KERNEL[872.972783] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/eth0/queues/rx-0 (queues) KERNEL[872.972816] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/eth0/queues/tx-0 (queues) KERNEL[872.972852] bind /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2 (usb) UDEV [873.056171] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:1.0 (usb) UDEV [873.108344] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge/wakeup12 (wakeup) UDEV [873.110813] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge/hwmon2 (hwmon) UDEV [873.195838] bind /devices/pci0000:00/0000:00:0b.0/usb1/1-1 (usb) UDEV [873.238856] change /devices/pci0000:00/0000:00:0b.0/usb1/1-1/power_supply/apple_mfi_fastcharge (power_supply) UDEV [873.271203] remove /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:1.0 (usb) UDEV [873.273286] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.0 (usb) UDEV [873.357614] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.1 (usb) UDEV [873.363520] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2 (usb) KERNEL[873.403053] move /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/enxe6b2fb396ea6 (net) UDEV [883.457791] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/enxe6b2fb396ea6 (net) UDEV [883.488110] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/eth0/queues/tx-0 (queues) UDEV [883.496447] add /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/eth0/queues/rx-0 (queues) UDEV [883.527921] bind /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2 (usb) UDEV [883.544252] move /devices/pci0000:00/0000:00:0b.0/usb1/1-1/1-1:4.2/net/enxe6b2fb396ea6 (net) [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 657 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --]
Может, с запозданием, но всё же интересно...
25.05.2022 19:46, Vladislav Zavjalov пишет:
> On Wed, May 25, 2022 at 07:31:40PM +0300, Vladislav Zavjalov wrote:
>> On Wed, May 25, 2022 at 04:57:19PM +0300, Ruslandh wrote:
>>> Создаю такой файл udev (для отладки)
>>>
>>> [...]
>>>
>>> Ну и еще пара общих вещей про правила udev rules (я плохо
>>> чувствую, насколько такие вещи общеизвестны, прошу прощения, если пишу
>>> тривиальное):
>>> [...]
>>> - Разные атрибуты устройств удобно смотреть командой
>>> udevadm info -a -p /sys/bus/usb/devices/...
Наиболее интересным для отладки правила было бы увидеть вывод
udevadm test /ваш/путь/...
--
Best regards,
Leonid Krivoshein.