Проприетарные разработки глубоко проникли в код многих приложений и сервисов. В сложных системах избавиться от них очень непросто. Зачастую для этого используются обходные пути, которые скорее являются костылями. В ядре Linux для работы с проприетарными драйверами используются драйверы-прослойки, которые предназначены практически исключительно для трансляции обращений драйвера к ядру. У прослойки код открытый, так что проблемы с GPL-лицензией нет, формальности соблюдены.
Но у такого подхода немало противников. Один из них Кристоф Хелвиг (Christoph Hellwig), разработчик ядра Linux. Ранее он был членом управляющего технического комитета организации Linux Foundation. Также он выступал истцом в судебном процессе с VMware. Хелвиг предложил значительно ужесточить защиту от связывания проприетарных драйверов с компонентами ядра Linux.
Для этого он предлагает использовать патчи, которые дают возможность наследовать флаги, связанные с экспортом GPL-символов. В этом случае наследуется флаг TAINT_PROPRIETARY_MODULE во всех модулях, импортирующих символы из модулей с данным флагом. Суть защиты в том, что если драйвер-прослойка будет импортировать что-то не из GPL-модуля, то GPL-модуль унаследует метку TAINT_PROPRIETARY_MODULE и не сможет обращаться к компонентам ядра, доступным только для GPL-модулей.
Источник: 3dnews
В ходе обсуждения предложили и обратную блокировку. Так, если модуль импортирует EXPORT_SYMBOL_GPL, то в этом случае любые экспортируемые модулем символы не должны импортироваться теми модулями, которые не заявляют о совместимости с GPL. Предложение было сделано не Хелвигом, а другим участником дискуссии. Но Хелвиг согласился с ним. Скорее всего, Линус Торвальдс не пропустит это предложение, поскольку оно приведет к блокированию ряда подсистем ядра для проприетарных драйверов.
Весь сыр-бор разгорелся после публикации инженера из Facebook патчей с реализацией подсистемы netgpu. Эта подсистема дает возможность организовать прямой обмен данными между сетевой картой и GPU с выполнением обработки протокола силами CPU. На базе предложения можно сделать общую реализацию RDMA для обмена данными между GPU или внешней CXД. Многие разработчики выразили недовольство подобными нововведениями, поскольку реализация доступна лишь для проприетарных драйверов NVIDIA через предоставляемую этими драйверами прослойку. Хелвиг даже назвал разработчика троллем.
В свою очередь, автор патча возразил, что подсистема не привязана к NVIDIA, так что ее поддержка может быть обеспечена для программных интерфейсов к GPU AMD и Intel. В конечном итоге продвижение netgpu в ядре признали невозможным до появления рабочей поддержки на основе таких свободных драйверов, как AMDGPU, Intel i915 или Nouveau.
