Зачем видеодрайвера в Линуксе засунули в ядро?

Есть платформы где нет ни vesa, ни EFI gop.

Там есть u-boot framebuffer.

Я думаю это про вот это: https://www.opennet.ru/opennews/art.shtml?num=55150

Это вроде про сеть, а не про видеодрайвера.

Vesa bios extension, EFI gop, uboot framebuffer это все зависимость на system firmware. Ну вот хотели сделать графику без зависимости на system firmware. Ты прямо осуждаешь это стремление.

Ну вот хотели сделать графику без зависимости на system firmware.

Зачем?

Ты прямо осуждаешь это стремление.

Да, осуждаю. Лучше сделать modesetting драйвер в u-boot/EFI. Это более гибкое решение, им можно будет пользоваться из любой ОС.

К тому же ядерные драйвера не будут доступны на ранних стадиях инициализации ядра и нельзя будет вывести логи загрузки на экран.

Никто не любит зависимости. А существование других ядер мало волнует разработчиков ядра линукса.

eBPF. Вот тебе интересное чтиво: https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story

Почему-то VLC любит валить видеодрайверы. В Линуксе видимо будет kernel panic.

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

Ты сам-то в это веришь?

Не так давно из-за бага в интеловом драйвере было наоборот, вешались именно иксы, помогал только их перезапуск.

Поэтому я и написал

по причине, не связанной с видеодрайвером

У меня раньше был глючный драйвер тачпада, который регулярно крашил иксы. При использовании KMS я видел стектрейс от обработчика SIGSEGV X-сервера и получал возможность перезапустить его из шелла на tty1, а без KMS приходилось заходить по ssh с соседней машины.

С повисшем драйвером видеокарты (как и любого другого сложного устройства) тяжело что-то сделать, вне зависимости от того, где он находится - в ядре или в юзерспейсном X-сервере. Если его убить, то видеокарта окажется в неопределённом состоянии, и разработчику драйвера придётся очень постараться, чтобы написать такой код инициализации, который бы умел карту из любого неизвестного состояния приводить в нужное.

чтобы был универсальный API в юзерспейс а не куча костылей и подпорок у каждого производителя

Вот я что-то подобное припоминаю. Вроде то ли AMD, то ли Nvidia пытались протолкнуть еще один API для упрощения себе работы с разработкой.

Если его убить, то видеокарта окажется в неопределённом состоянии

Так сложно сделать hardware reset? Почему тогда при перезагрузке сброс состояния без проблем работает?

ну вот тебе поточнее

Так сложно сделать hardware reset? Почему тогда при перезагрузке сброс состояния без проблем работает?

Я это где-то видел кстати, кажется в радеоне. Когда оно уходит в бесконечный ресет это выглядит довольно весело

Да, именно про этот найденный по ^F@ абзац я и написал «Как будто эта ссылка что-то объяснила».

В Linux драйверы по большей части входят в состав ядра, потому что stable API nonsense. Исключения есть и самое наверное известное - nvidia(которая, как известно, fuck you). Таким образом обновления драйверов прилетают вместе с новым ядром, а для этого нужно перезагрузиться и окошки закроются и несохраненные данные потеряются(тут уже от приложения зависит, sublime, например, старается их не терять). Таким образом предлагаемая для решения задача не имеет особого смысла в контексте Linux экосистемы

Ух да ты ШО!? ПРАВДА???????
Блииин, ниииизанли низнали, какой ты ууууууууууумный!!!!

{ Как в твоём сознании уживается такая тождественность, как модель распространения (доставки, обновления) драйверов и архитектура работы ОС + драйверов + пользовательского ПО ? }

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

Можно её саму перезагрузить. Сброс питания на устройство решает эту проблему.

У меня 1920x1080 работает с VESA без проблем.

Где в гайке? Т.е. официальное руководство врёт?

«While Haiku's VESA mode performs very well, you may experience some limitations. You may not be able to drive your widescreen display in its native resolution, resulting in a somewhat blurred picture.»

Собственно почему:

• https://scorpius.github.io/nvidia-hack-haiku.htm
• https://news.ycombinator.com/item?id=17441662

Купить нормальное железо.

Отличный ответ! А вы точно специалист, который собирается заниматься в гейке видеоподсистемой? М... Её ждёт светлое будущее. :) Полагаться на то, что производитель зашьёт в BIOS нестандартный режим, который будет доступен только части пользователей и делать вид что это нормально. Знаете, вам лучше подать резюме в Apple. Там такой подход и советы оценят. :-D

Пространства имён, AppArmor?

Когда эта проблема встала всего вышеперечисленного по моему даже в проекте ещё не было.

Запускать в контейнере, где только сам сервер и его конфиг.

Похоже на латание дыр в тришкином кафтане. Здравый смысл говорит, что то, что может не работать от рута - не должно от него работать.

Из исходников libdrm:

    /* The whole drmOpen thing is a fiasco and we need to find a way
     * back to just using open(2).  For now, however, lets just make
     * things worse with even more ad hoc directory walking code to
     * discover the device file name. */

Гении архитектуры (facepalm). Причём в Haiku нет этих device major/minor:

static status_t
devfs_read_stat(fs_volume* _volume, fs_vnode* _vnode, struct stat* stat)
{
	struct devfs_vnode* vnode = (struct devfs_vnode*)_vnode->private_node;

	TRACE(("devfs_read_stat: vnode %p (%" B_PRIdINO "), stat %p\n",
		vnode, vnode->id, stat));

	stat->st_ino = vnode->id;
	stat->st_rdev = vnode->id;
	stat->st_size = 0;
	stat->st_mode = vnode->stream.type;

Т.е. официальное руководство врёт?

You may not be able to drive your widescreen display in its native resolution

Что означает английское слово «may» знаете?

Отличный ответ!

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

Что означает английское слово «may» знаете?

Знаю. Ребята честные, говорят, что может и не срастись.

Ну а что я должен ещё сказать?

То, чего не хочется.

Разработчиков не хватает.

Дело не в разработчиках. Драйвер тупо нужен. Написан он или нет - дело десятое, он необходим, вот что главное. А это ответ на заданный в топике вопрос. Я не знаю как там гайка, может как Windows - GUI-only OS, но для Linux это не так. GUI тут лишь опциональная навеска. А для fb консоли графика формально должна стартануть до иксов, при загрузке. А для этого драйвер должен в ядре быть.

И да, use text-mode, Luke, не проходит, потому что десктопами дело не ограничивается, где-то этого text-mode и нет...

Знаю.

Ну и где тогда враньё?

То, чего не хочется.

Ну давайте просветите.

А для fb консоли графика формально должна стартануть до иксов

Есть VESA/GOP. Графика будет ещё до загрузки ядра на любом железе где графика актуальна. Для ядерной консоли видеодрайверы в ядре не нужны.

Мне эти 16 битные major/minor напоминают номера устройств и функций VxD из ядра Windows 9x. Зачем это всё ещё нужно в 2021 году?

Ну давайте просветите.

Не могу. Я вам прямым текстом говорю - не понимаете.

Графика будет ещё до загрузки ядра на любом железе где графика актуальна.

Это может оказаться не актуальная графика, т.к. её разрешение может не совпадать с разрешением LCD-панели.

Для ядерной консоли видеодрайверы в ядре не нужны.

Нет. Вам не нужна, потому что у вас лично всё работает.

её разрешение может не совпадать с разрешением LCD-панели.

Для ядерной консоли это большого значения не имеет. Она нужна только в аварийных ситуациях.

Гении архитектуры (facepalm).

Тише ты. Сейчас прибежит тот самый полоумный апологет подхода «ВСЁ ЕСТЬ ФАЙЛ», того самого подхода, который порождает подобную костыльную ахинею везде где только можно и начнёт кидаться калом в этой теме, полностью убив зачатки любых технических дискуссий.

Так сложно сделать hardware reset? Почему тогда при перезагрузке сброс состояния без проблем работает?

Да ладно перезагрузка, есть же pcie hotplug и egpu. Они же как-то инициализируются во время работы ОС.

Вот и разработчики других систем в своё время не поняли, зачем это Intel пропихивает свой KMS в ядро Linux.

да, я сейчас прочитал эту грустную историю https://lwn.net/Articles/616097/

*BSD как-то там что-то подтягивают и портируют.

X512 я правильно понимаю, что Nvidia предлагает самый здоровый подход: drm в виде модуля ядра nvidia_drm?

Сейчас прибежит тот самый полоумный апологет

Я очень люблю сей подход. Он есть единственно верный. Только в большинстве *nix систем от него местами отклонились. Однако, не зря же Отцы UNIX создали Plan9, который ещё более UNIX, чем оригинал. Вот это и есть верный путь... Или даже лучше PlanB!

А чем Kepler Geforce GT 710/GDDR5) хуже Pascal (GT 1030)?

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

С этим тоже не всё так просто, иначе бы не появлялись такие проекты: https://github.com/gnif/vendor-reset

Drm появился, когда в XFree86/Xorg делали direct rendering. Приложение общается напрямую с видеоадаптером, минуя сервер, рендерит картинки в gpu. А потом серверу говорит - хочу картинки с gpu отобразить в окно. Появился одновременный доступ к видеоадаптеру из нескольких процессов, пришлось вынести владельца ресурса в ядро. И в драйвере Nvidia ядерная часть тоже есть, и тоже решает задачу совместного доступа нескольких процессов. API наверное другой, но смысл тот же.

Но может это вообще ошибка, и надо вернуться на indirect rendering, починить indirect glx? Приложения будут общаться только с сервером, с видеоадаптером будет общаться только сервер, никакого драйвера в ядре не потребуется.

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

и будет ровно одна реализация сервера, а если оконная система не нужна всё равно ставь сервер, даже если нужно квадратик нарисовать на экране ставь сервер.

Тише ты. Сейчас прибежит тот самый полоумный апологет подхода «ВСЁ ЕСТЬ ФАЙЛ»

чувак тебе говорит зачем ты центральное отопление провёл ему теперь дрова не у кого пиз..ть.

Самый годный коммент в треде.

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

По-моему, ты ошибаешься, думая, что это связано с какими-то значительными отличиями архитектуры граф. стека от линуксового. То, что ты видишь в винде, когда «видеодрайвер перестал отвечать и был успешно восстановлен» - на самом деле озачает, что система решила, что гпу завис, и попросила ядерный драйвер ресетнуть его, сообщив об этом юзерспейсу. Причем ядерный драйвер продолжал работать корректно и успешно выполнил ресет. Да, в видеодрайверах для винды ресет гпу хорошо реализован, с поддержкой в юзерспейсной части, композиторе и директ3д. Но в целом архитектура та же - код управления гпу и аллокацией видеопамяти в ядре, если он крашнется - будет бсод. Юзерспейсная часть примерно соответствует месе.

https://superuser.com/questions/693059/how-is-windows-7-able-to-recover-from-a-driver-crash https://docs.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery https://docs.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-architecture

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

не проблема и на Linux реализовать, например для драйвера v4l2 я релизовал suspend/resume ровно так как инициализацию, устройство восстанавливает работу после полного сброса, ядро может в любое время полностью ресетнуть устройство налету вызвав suspend -> resume

а еще лучше PlanO, где все есть Объект.

В данном случае ещё актуальна вот эта ссылка.

https://lurkmore.to/Advice_dog

а мордочка собаки-советчицы заменяется символом @

вот это мда, ни в жисть бы не догадался

а еще лучше PlanO

Где про него почитать? Кто разрабатывает?

Ну или когда-нибудь научатся всё ядро менять на лету…

Любители микроядерной QNX, например, очень гордятся, что там почти всё можно поменять на лету.

Ну или когда-нибудь научатся всё ядро менять на лету…

В принципе, можно уже сейчас попробовать с помощью CRIU мигрировать процессы с машины А на машину Б, на А обновить ядро, перезагрузиться, а затем мигрировать процессы обратно с Б на А.
Voilà, смена ядра на лету.

там почти всё можно поменять на лету

Но какой в этом смысл? Разве QNX не для встроенных приложений, где вообще никогда ничего не обновляется по частям? Прошивку обновляют только целиком.

Для марсохода какого-нибудь вдруг.

Немного костыльно конечно.

Десять лет назад это вообще было из разряда фантастики.

Немного костыльно конечно.

аппаратная часть в любом случае резервируется, например Буран

 На борту корабля находилось два комплекта БЦВМ «Бисер-4» (элементная база - микропроцессор К582) по четыре аппаратно-параллельных компьютера и аппаратного компаратора, допускающего автоматическое отключение подряд двух компьютеров в случае аварийных результатов (4 основных + 4 резерв). Для сравнения, КК «Space Shuttle» в 1980 году имел квадруплексную БЦВМ с трёхкратным аппаратным резервированием[39] на основе вычислителей семейства IBM System/4 Pi.