Qualcomm выпустил открытый 2D/3D-драйвер, который был отвергнут разработчиками ядра

Компания Qualcomm объявила об открытии исходных текстов модуля Linux-ядра, предназначенного для обеспечения поддержки работы 2D/3D-механизмов акселерации, доступных в OpenGL ES-совместимом графическом ядре чипсета Snapdragon, на базе которого выпускаются мобильные устройства и телефоны. В частности, на данной платформе построены смартфоны Google Nexus One и Dell Streak.

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

Также у разработчиков вызывает нарекание технология по которой построен драйвер, работающий в режиме ядра - организация его работы сильно отличается от методов, используемых в работающих на уровне ядра открытых драйверах, например, драйвер Qualcomm создает специальное устройство /dev/kgsl и собственный набор ioctl-вызовов для управления.

С другой стороны драйвер предоставляет высокоуровневый интерфейс к графической подсистеме и позволяет управлять графической памятью, переключением контекста и прерываниями, что упрощает создание независимым сообществом на его основе полностью открытого пользовательского драйвера. Из положительных моментов также сообщается, что помимо собственного проприетарного интерфейса KGSL (Kernel Graphics Support Layer), драйвер поддерживает DRM (Direct Rendering Manager), GEM (Graphics Execution Manager) и частично позволяет обеспечить поддержку DRI2.

Политики запрещения приема в ядро таких драйверов придерживается Дэвид Эйрли (David Airlie), работающий в компании Red Hat и отвечающий в Linux-ядре за поддержку DRM. В качестве причины такой точки зрения, кроме связанных с лицензированием проблем, называется необходимость проверки работоспособности представленного для включения в Linux ядро кода, которую трудно провести без присутствия открытого работоспособного пользовательского драйвера. Также закрытый код мешает проверке корректности поддерживаемого API, которое может содержать скрытые функции, которые теоретически могут представлять угрозу безопасности.

©  OpenNet