Wayland-протокол для скринкастов: получите и распишитесь

В итоге получилось ок

За неубиваемые в режиме ядра задачи желаю им всем болезненной смерти (но быстрой, я же не зверь).

За неубиваемые в режиме ядра задачи желаю им всем болезненной смерти

Ну да, тут все обосрались. Хотя этого становится меньше, что не может не радовать.

Хотя этого становится меньше, что не может не радовать.

В чём суть?

tailgunner уже сказал тебе все, что я имел сказать.

Вы оба боитесь наступления ситуации, которая может вообще не наступить, что я ещё могу сказать. Бойтесь лучше чего-нибудь реального )

Словосочетание «по проекту» — лучшая из известных мне адекватных замен английскому «by design».

By design расширение Xshm тоже не умеет сетевую прозрачность, что ж теперь? Выкидывать иксы ради… эээ…?

К тому же By design как раз Wayland прекрасно можно реализовать передачу картинок по сети, поскольку Wayland предоставляет приложению только область памяти для вывода, а дальше он её может хоть на экран выводить, хоть по сети посылать, в чём проблема by design?

Кстати есть вот такой проект https://github.com/waltham/waltham но судя по всему сдох. Или уснул

В чём суть?

Э?

неубиваемые в режиме ядра задачи

неубиваемые в режиме ядра задачи

Я вопроса не понял. В чем суть чего?

Ну что за неубиваемые задачи?

Ну что за неубиваемые задачи?

Те, которые TASK_UNINTERRUPTIBLE, разумеется.

Так разве это не естественная Unix-фича?

Так разве это не естественная Unix-фича?

Шта? Какая ещё UNIX фича? Если какой-то упырь отправил процесс в TASK_UNINTERRUPTIBLE и повис на три минуты это не UNIX фича, это кто-то мудак.

Это было простительно Unix в 1978, когда в нем было полтора драйвера диска. Но уже не в 1998, не говоря уже о 2018.

Это было простительно Unix в 1978, когда в нем было полтора драйвера диска. Но уже не в 1998, не говоря уже о 2018.

Тут справедливо стоит заметить, что есть случаи, когда по-другому сделать сложно. Ну, например, юзер попросил положить ему данные в буфер, ядро сделало хитрую магию, зарегистрировало этот буфер под DMA операцию и ждет данных с другого хоста (привет zero-copy). А удаленная нода, например, упала. И тут все зависит от того, есть ли в протоколе timeout'ы и как именно они работают.

P.S. Но, разумеется, мы тут не говорим про какие-нибудь файловые системы, в которых один хрен есть page cache и которые так делать не должны.

Тут справедливо стоит заметить, что есть случаи, когда по-другому сделать сложно.

Ты же и сам знаешь, что это стало дефолтной формой ожидания.

например, юзер попросил положить ему данные в буфер, ядро сделало хитрую магию, зарегистрировало этот буфер под DMA операцию и ждет данных с другого хоста (привет zero-copy)

Иии... почему нельзя позволить процесу умереть? Буфер останется в драйвере зарегистрированным, но у него не будет процесса-владельца.

И тут все зависит от того, есть ли в протоколе timeout'ы и как именно они работают.

А есть протоколы, в которых нет тайм-аута?

А есть протоколы, в которых нет тайм-аута?

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

Иии... почему нельзя позволить процесу умереть? Буфер останется в драйвере зарегистрированным, но у него не будет процесса-владельца.

Потому что кому-то лень было заморочиться и сделать аналог zombie процесса, который содержит в себе только таблицу занятых ресурсов :)

Потому что кому-то лень было заморочиться и сделать аналог zombie процесса, который содержит в себе только таблицу занятых ресурсов :)

Ну, зомби-процессов может быть много, а в данном случае хватит просто одного списка «уже пофиг, как завершилась I/O-транзакция». Но да, программировать немного больше.

Ну, зомби-процессов может быть много, а в данном случае хватит просто одного списка «уже пофиг, как завершилась I/O-транзакция». Но да, программировать немного больше.

Тут просто вот ещё какая проблема. Прикинь, у нас есть fd и sg_buf. И кто-то взял в ядре fd->lock и под ним sg_buf->lock. И тут приходит сигнал. Если мы не держим таблицу занятых ресурсов, а процесс убит, то в fd уже может быть мусор.

Прикинь, у нас есть fd и sg_buf. И кто-то взял в ядре fd->lock и под ним sg_buf->lock. И тут приходит сигнал.

Это понимаю...

Если мы не держим таблицу занятых ресурсов, а процесс убит

...это не понимаю. Ты должен обработать (гипотетический) код возврата EKILLED, зачистив свои ресурсы, а _после_ этого ядро зачистит свои. Проблема в том, что ты слишком легко можешь сказать «нихачу обрабатывать EKILLED и ниипет».

Если мы не держим таблицу занятых ресурсов,

Ты ее в любом случае держишь. Ну разве что ты инициируешь и завершаешь IO всегда в контексте процесса и всё хранишь на стеке.

...это не понимаю. Ты должен обработать (гипотетический) код возврата EKILLED, зачистив свои ресурсы, а _после_ этого ядро зачистит свои. Проблема в том, что ты слишком легко можешь сказать «нихачу обрабатывать EKILLED и ниипет».

Я чушь спорол. Если сигнал грамотно обрабатывается ядром (оно прерывает spinlock/просыпает mutex и аккуратно выходит с ошибкой EKILLED по всему стеку вверх), то ядро вернется из сискола, пометив страницы буфера как «заняты, никому не отдавать» и что там дальше делает процесс ему уже не интересно.

Ты ее в любом случае держишь. Ну разве что ты инициируешь и завершаешь IO всегда в контексте процесса и всё хранишь на стеке.

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

Если сигнал грамотно обрабатывается ядром (оно прерывает spinlock/просыпает mutex и аккуратно выходит с ошибкой EKILLED по всему стеку вверх)

Ядро - это драйверописатель. Это он должен аккуратно выходить по EKILLED.

то ядро вернется из сискола, пометив страницы буфера как «заняты, никому не отдавать» и что там дальше делает процесс ему уже не интересно.

Это опять же работа драйвера.

Ты ее в любом случае держишь. Ну разве что ты инициируешь и завершаешь IO всегда в контексте процесса и всё хранишь на стеке.

Даже в этом случае ядро все это хранит (стек-то у каждого треда свой)

Если ты хранишь управляющий блок IO на стеке процесса, то процесс обязан дождаться, когда устройство завершит свою работу и просигналит об этом - он не может обработать EKILLED немедленно. А если управляющие блоки хранятся в куче, то обработка EKILLED заключается в том, что принадлежащие процессу блоки помечаются «владелец умер», и освобождаются позже.

Вот если IO выполняется прямо в память процесса (страницы get_user_pages заносятия в sg_buf) - тогда да, по EKILLED нужно либо прибивать IO транзакцию на устройстве, либо ждать, пока она завершится, и в это время процесс будет неубиваемым.

Jonas Adahl, Adam Jackson, Daniel Stone,

ajax над Wayland не работал и не работает, но сейчас хочет от некоторых обязанностей в xorg отойти. Слишком много на него одного свалилось. ajax коммитит в XWayland не свои патчи, так как XWayland - это X-сервер, который находится в дереве xorg.

Оба других упомянутых не являются разработчиками иксов. Daniel Stone был когда-то очень давно и приложил руку к новым ревизиям DRI3.

Моя задача - погрузить своё очко в лужу и сильно пёрнуть. С этим я всегда справляюсь на 5+. Остальное не важно :)

Починил. Не благодари.

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

Оба дебила?

Ты слепой?

Каким образом? ssh создаст сокет для редиректа X-протокола, но кто к нему обратится?

Ты не в курсе, как иксы устроены? Про xlib/xcb тоже не в курсе?

Там нет иксовых приложений. Чистый вяленд.

Вот с этого и надо было начинать. Тогда возникает вопрос, что вяленд делает на сервере.

это невозможно без серьёзных изменений в самом протоколе. Именно поэтому и начали пилить Wayland

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

Мне непонятно, почему вяленд-онли приложение будет обращаться к сокету иксов.

Никто и не говорил, что оно будет. Наоборот: разработчики вяленого и их подпёрдыши кричали, что корень всех бед в сетевой прозрачности, а кому надо, тот будет сидеть в VNC-ГУЛАГе.

Вообще-то это вялендопедики требуют, чтобы их поделие внедряли.

Он стал дефолтом год назад.

4.2

Когда вяленда станет достаточно, тогда и ssh -W появится, потому что кому-то это станет очень нужно.

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

А именно: те, которые в еще бородатых годах разработали один из самых долгоживущих протоколов, или те, которые скатили его в говно в двухтысячных.

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

В говно? Серьёзно? Если бы не Паккард - вообще бы сейчас хер пойми что было с графикой в линуксах.

Ты обдолбанный наркоман. Кит Паккард иксы пилит, а не вяленого.

Jonas Adahl, Adam Jackson, Daniel Stone, это из тех кого сразу вспомнил

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

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

Это эволюционное развитие. И развитие конкретного графического сервера. Но дебилы вроде тебя всегда сравнивают разные сущности, протокол и сервер (собственно, потому и дебилы), и когда удобно, меняют объекты сравнения местами. Я могу напомнить даже то, как XFree86 работал в 90-е и как стал работать в нулевые.

XWayland - это иксы поверх вяленого. То есть, приложения для вяленого не заработают.

Pipewire - это Pulseaudio, только для аудио и видео сразу. Очередное говно сделанное с целью сломать стандарты.

В говно? Серьёзно? Если бы не Паккард - вообще бы сейчас хер пойми что было с графикой в линуксах.

Ты обдолбанный наркоман. Кит Паккард иксы пилит, а не вяленого.

Нет, детка, это ты ослеплён пламенем своей жопы. Я про иксы и говорил.

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

Я перечислял уважаемых в опенсорсе людей, а не неадекватов ЛОРа типа тебя

Оставь надежду всяк туда смотрящий.

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

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

Я всё ещё верю в силу опенсорца )

есть ли где-то напосмотреть зачем таки нужен wayland?

Купи Jolla Sailfish и увидишь вживую. Дальше область применения вяленого отсутствует.

Я понимаю, что тема жёванная пережёванная, но есть ли где-то напосмотреть зачем таки нужен wayland? Так что бы для дурачков и максимально наглядно?

Убунта, федора, арч. Вообще, на посмотреть можно в любом приличном дистрибутиве, надо только поставить.

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

Я сильно переживаю даже о том, как буффер обмена буду в ssh сессии прокидывать,

Буфер обмена работает также как в иксах, есть мышиный, есть обычный. Про x2go ничего не могу сказать, скорее всего через xwayland будет работать как обычно.

Да даже ssh -XYC достаточно в локалке.

ssh -X это всего лишь быстрый способ указать на использование сетевой прозрачности. Для каждого конкретного случая оптимальными будут те или иные опции с теми или иными дополнительными приблудами. Можно даже winswitch припомнить, если на то пошло.

XWayland - это иксы поверх вяленого. То есть, приложения для вяленого не заработают.

XWayland - это обычный вяленд-клиент. Не вижу, почему бы рядом с ними не работать родным вяленд-приложениям.

На Jolla Sailfish есть рантаймовые библиотеки LLVM, нужные для компиляции шейдеров в Mesa3D?

Daniel Stone был когда-то очень давно и приложил руку к новым ревизиям DRI3.

Он загадил подсистему ввода, а потом за ним пришлось в спешке убирать говно.

Нет, детка, это ты ослеплён пламенем своей жопы. Я про иксы и говорил.

Речь была про вяленый. Ты пытаешься понятия подменять и уходить от темы.

Я перечислял уважаемых в опенсорсе людей, а не неадекватов ЛОРа типа тебя

Неадекват тут ты и только ты. Я вполне адекватен и привожу логические доводы подкреплённые фактами. Дэниэль Стоун - это абсолютная мразота, которая ни разу не принесла пользу, зато вредила многим.