Линус Торвальдс представил релиз ядра Linux 3.7. В новой версии представлена большая порция существенных изменений, связанных с архитектурой ARM: возможность формирования многоплатформенных ARM-сборок, поддержка архитектуры AArch64 (ARM64), адаптация Xen для работы на процессорах ARM Cortex A15. Из других улучшений можно отметить реализацию пространства имён для идентификаторов пользователей, возможность проверки цифровой подписи при загрузке модулей ядра, использование инструкций SMAP для защиты от эксплуатации уязвимостей в ядре, поддержку протоколов SMB2.1 и VXLAN, реализацию GRE и NAT для IPv6, поддержку режима TFO на стороне сервера.

В новую версию принято 10409 исправлений от более чем 1200 разработчиков, размер патча - 95 Мб (изменения затронули 15886 файлов, добавлено 1570793 строк кода, удалено 1246965 строк). В связи с изменением структуры размещения и переработкой иерархии дириекторий некоторых частей ядра, размер нынешнего патча более чем в два раза больше по сравнению с прошлыми выпусками. Около 33% всех представленных в 3.7 изменений связаны с драйверами устройств, примерно 23% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 6% связано с сетевым стеком, 3% - файловыми системами и 3% c внутренними подсистемами ядра.

Наиболее интересные новшества ядра 3.7:

  • Аппаратные архитектуры

    • Поддержка 64-разрядной архитектуры AArch64 (ARM64), реализованной в процессорах, поддерживающих набор команд ARMv8. 64-рязрядная архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256. Реализация AArch64 для Linux поддерживает расширенную 39-разрядную адресацию памяти для ядра и пользовательского уровня и предоставляет режим совместимости, позволяющий выполнять 32-битные программы, собранные для архитектуры ARMv7 (ARM EABI). В настоящее время устройства на базе ARMv8 пока находятся на стадии тестирования прототипов, поступление в продажу первых ARMv8-систем ожидается в следующем году;

    • Унификация кода поддержки архитектуры ARM и обеспечение возможности формирования многоплатформенных ARM-сборок. Если ранее требовалось собирать отдельный вариант ядра для каждого типа  SoC, то начиная с выпуска 3.7  появится возможность собрать одно ядро, которое будет содержать поддержку различных ARM-платформ. Унифицированная сборка ядра 3.7 сможет работать на платформах  Calxeda Higbank (серверы HP Moonshot), Versatile Express (эталонная плата, поддерживается эмулятором QEMU), Marvell ARMADA (от мини-серверов до телеприставок),  Altera SoC FPGA и Picohip picoXcell (мини-базовые станции для офисов). В будущих выпусках ядра число поддерживаемых платформ будет расширено. Указанное нововведение существенно упростит жизнь разработчикам дистрибутивов для ARM-систем, которым теперь не придётся формировать отдельный загрузочный образ для каждой ARM-платформы.

  • Виртуализация и безопасность

    • Поддержка механизмов виртуализации Xen для систем на базе процессоров ARM Cortex A15. Таким образом Xen стал первым гипервизором, поддерживаемым в Linux на платформе ARM. Представленный для интеграции в ядро код основан на использовании аппаратных расширений для обеспечения виртуализации, поддерживаемых архитектурой ARMv7. Особенностью реализации Xen для ARMv7 является отсутствие разделения в поддержке запуска гостевых систем в режиме паравиртуализации (PV) и аппаратной виртуализации (HVM). Вместо этого используется один комбинированный режим запуска гостевых систем, напоминающий запуск PV поверх HVM без необходимости эмуляции оборудования при помощи Qemu. Гостевые системы при этом всегда запускаются в режиме полной виртуализации, но для доступа к сетевым и блочным устройствам должны использовать специальные паравиртуальные драйверы (т.е. для гостевых окружений не требуется модификация ядра системы, но необходимо наличие нескольких драйверов).

    • Добавлена рабочая реализация пространств имён для идентификаторов пользователей (user namespaces). Указанная возможность позволяет сформировать в контейнерах собственные наборы идентификаторов групп и пользователей, а также связанные с ними привилегии (например, в каждом контейнере может быть свой root);

    • Поддержка набора инструкций SMAP (Supervisor Mode Access Prevention), реализованного в процессорах Intel на базе микроархитектуры Haswell. Задействование SMAP в ядре позволяет блокировать доступ к данным в пространстве пользователя из привилегированного кода, выполняемого в пространстве ядра (по аналогии с тем, как добавленная в ядре 3.0 поддержка SMEP  не позволяет переходить из режима ядра к выполнению кода, находящегося в пользовательских областях). При обеспечении оборудованием поддержки инструкций SMAP, представленные средства защиты будут включаться автоматически, что существенно усложнит эксплуатацию уязвимостей в ядре, вызванных такими ошибками, как разыменование NULL-указателя;

    • Поддержка загрузки модулей ядра с проверкой их корректности по цифровой подписи. Указанная возможность разработана в рамках проекта по обеспечению поддержки загрузки верифицированного ядра Linux на системах с включенным режимом UEFI Secure Boot. При активации данной опции, ядро будет отвергать загрузку любых модулей для которых нет корректной цифровой подписи. Поддерживается и отладочный режим, при котором выполняется проверка, но она не влияет на загрузку модулей и информирует о проблемах через лог. При сборке ядра, при наличии открытого и публичного ключей процесс создания подписей для собираемых модулей выполняется автоматически, а проверочный ключ интегрируется в файл crypto/signature/key.h. Отмечается, что  генерация цифровых подписей немного замедляет процесс сборки;

    • В соответствии с пожеланиями разработчиков systemd, расширенные атрибуты для управляющих групп (control groups) могут задаваться через создание иерархии директорий. При использовании неиерархических групп управления во вложенных элементах иерархических групп будет выдаваться ошибка. Кроме того, в cgroups добавлена поддержка xattr;

  • Дисковая подсистема, ввод/вывод и файловые системы

    • В файловую систему Btrfs добавлена поддержка "hole punching", технологии при которой часть файла можно пометить как более неиспользуемую. Это позволяет файловой системе и носителям (например, накопителям SSD) заранее освобождать неактуальные неиспользуемые блоки в середине файла. Для Btrfs также ускорена работа системного вызова fsync, что позволило повысить производительность записи для виртуальных машин, образы которых размещаются поверх Btrfs. Например, выполнение теста, в которой каждая операция записи завершалась вызовом fsync() ускорилось для SATA-диска с  82 до 140 Кб в сек., а для Fusion IO-накопителя с 431 до 2532 Кб/cек. Из других изменений отмечается исключение возможности одновременного использования опций монтирования compress и nodatacow и  устрание ограничения на число жестких ссылок (hardlink) в одной директории;

    • В файловую систему Ext4 добавлена поддержка изменения размера на лету для 64-разнядных ФС (размером более 16 Тб) и ФС с meta_bg. Существенно ускорены операции удаления (unlink) файлов и их усечения (truncate). Добавлена опция монтирования max_dir_size_kb, которая позволяет задать максимальный лимит размера директории. Возобновлена поддержка опции "-o discard" при неактивном режиме журналирования;

    • В реализации файловой системы CIFS обеспечена поддержка протокола SMB2.1. Статус поддержки SMB2 на уровне ядра переведен из разряда "поломанный" в "экпериментальный";

    • Добавление модуля IMA (Integrity Measurement Architecture) для обеспечения хранения и проверки базы хэшей для проверки целостности файлов и связанных с ними метаданных. Данные для контроля целостности сохраняются как атрибуты xattr;

    • В реализацию программных RAID 0/1/10/5 (MD RAID) и файловой системы JFS добавлена поддержка команды TRIM (discard), которая позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы;

    • В подсистеме MD RAID добавлена поддержка пересборки массивов RAID10;

    • Перевод реализации NFS 4.1 в разряд стабильных (ранее поддержка NFS 4.1 была помечена как экспериментальная). В NFS добавлена опция монтирования "migration", при которой возможна передача одинаковых для нескольких клиентов идентификаторов, допускающих реализацию схем для миграции состояний между клиентами;

  • Сетевая подсистема

    • Поддержка протокола туннелирования GRE (Generic Routing Encapsulation) для IPv6;

    • Поддержка трансляции адресов (NAT, MASQUERADE, NETMAP, REDIRECT, а также хелперы для протоколов FTP, IRC, SIP и amanda) для IPv6.  IPv6 NAT позволяет осуществить подмену адресной информации в пакетах IPv6 в соответствии с заданными правилами трансляции, примерно так как это делается в классическом трансляторе адресов для IPv4. Для реализации поддержки IPv6 NAT, существующий в ядре код netfilter был переработан с целью разделения модуля NAT на два независимых компонента, один из которых включает в себя ядро подсистемы NAT, а второй реализует поддержку того или иного протокола третьего уровня;

    • Поддержка режима  быстрого открытия TCP-соединений (TFO - TCP Fast Open) на стороне сервера. Режим TFO позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и давая возможность отправки данных на начальном этапе установки соединения. В ядре 3.6 поддержка TFO была ограничена возможностью управления только на стороне клиента в процессе создания соединения. Теперь TFO может быть активирован и по инициативе серверной стороны;

    • Поддержка протокола
      VXLAN для туннелирования виртуализированных сетей второго уровня поверх сетей третьего уровня. Указанный протокол позволяет обойти ограничение на 4096 VLAN-ов (в VXLAN используются 24-разрядные идентификаторы);

  • Память и системные сервисы

    • Началась интеграция результатов работы] по рефакторингу заголовочных файлов, конечной целью которой является разделение по разным иерархиям директорий заголовочных файлов для UAPI (Userspace API) и KAPI (Kernel API). Подобное разделение позволит более явно выделить необходимые для использования в пространстве пользователя заголовочные файлы, которые теперь перемещены в include/uapi и arch/$(ARCH)/include/uapi. Например, разработчики дистрибутивов получат возможность подготовить сокращённый пакет (включить только заголовки UAPI) для сборки пользовательских компонентов, завязанных на API ядра. В рамках проекта также проведена работа по упрощению сложившейся усложнённой и запутанной схемы внутренних зависимостей между заголовочными файлами, например, разработчики сталкивались с проблемами добавления inline-функций в заголовочный файл, так как нередко в таких функциях необходимо было использовать компоненты из других заголовочных файлов. В ядро 3.7 включены не все из предложенных патчей, многие изменения перенесены на следующий выпуск ядра;

    • Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системы, без задействования udev. Наличие прошивок пока проверяется в /lib/firmware, в будущем будут добавлены гибкие настройки выбора пути;

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

    • В системный вызов epoll_ctl() добавлена опция  EPOLL_CTL_DISABLE, позволяющая отключить пулинг для указанного файлового дескриптора;

    • В утилиту perf добавлена команда trace ("perf trace PID") по выполняемым функциям напоминающая утилиту strace, но дополнительно позволяющая отображать события не связанные с системными вызовами;

    • Добавлена новая утилита "trace agent", использующая  virtio для эффективного перемещения данных о трассировке из гостевой системы в окружение хоста;

    • Добавлена утилита acpidump для записи в текстовый файл дампа системных таблиц ACPI;

    • В файл конфигурации ядра добавлена опция CONFIG_COREDUMP, позволяющая исключить при сборке код для генерации core-дампов при крахе процессов и код для поддержки связанных с управления дампами sysctl-вызовов. Использование опции позволяет сократить размер ядра на несколько килобайт;

  • Оборудование

    • Полностью переписана базовая часть драйвера Nouveau, в которой теперь учтены дополнительные особенности чипсетов NVIDIA, которые не были известны в момент написания ранее доступной базовой части драйвера. Целью переработки было общее упрощение архитектуры и её адаптация к дальнейшему обеспечению поддержки дополнительных функций, таких как SLI (Scalable Link Interface). Кроме того, в состав драйвера добавлен код для обеспечения управления кулером, работающий на устройствах серии NV40 и NV50. Добавлена поддержка загрузки собственных прошивок для карт GeForce 600 с Kepler GPU (NVE0);

    • В драйвере i915  для видеокарт Intel улучшена работа кода для настройки устройств вывода, добавлен экспорт  через Sysfs информации о частоте и режимах энергосбережения GPU, добавлена предварительная поддержка графических ядер для будущих моделей процессоров серии Haswell и ValleyView, которые ещё не выпущены на рынок;

    • В драйвере Radeon  улучшен код для управления конфигурацией нескольких мониторов, расширена поддержка управления фоновой подсветкой на ноутбуках, сокращено потребление памяти за счёт поддержки двухуровневых таблиц страниц памяти (2-level VM pagetables);

    • Проведена реорганизация подсистемы Video4Linux 2, код драйверов теперь размещён по поддиректориям в зависимости от используемого типа шины. Переписан код для обеспечения работы DVB-устройств с интерфейсом USB;

    • В звуковую подсистему ALSA добавлен новый API (PCM channel-mapping API) для управления звуковыми каналами, позволяющий настроить привязку каналов или получить точные данные о том, какой канал привязан к какой позиции в пространстве (например,  для surround 4.0 используются каналы - левый впереди, правый впереди, левый сзади, правый сзади);

    • Поддержка  Raspberry Pi, а также SoC Broadcom BCM2835, Micrel KS8695; Freescale P5040DS, Freescale / iVeia P1022RDK и MIPS Technologies SEAD3;

    • Для приложений, работающих на системах на базе архитектуры s/390, добавлена возможность использования аппаратной транзакционной памяти System zEC12;

    • Поддержка игровых пультов  Sony PS3 BD;

    • Поддержка сетевых контроллеров  Silicom Bypass, Freescale XGMAC MDIO и Microchip MRF24J40;

    • Поддержка модемов ST-Ericsson STE и звуковых плат Wolfson Bells;

    • Поддержка USB-контроллеров:  Broadcom BCM63xx, Marvell USB 3.0 PHY, ZTE USB-to-serial переходников и плат Cambridge Electronic Design 1401 USB;

Источник »
Главная ссылка к новости »

Был, был и весь вышел...

2 (11.12.2012 21:20:20 отредактировано redux)

Lupo Alberto пишет:

Nouveau

Lupo Alberto пишет:

i915  для видеокарт Intel

Lupo Alberto пишет:

Radeon

Что-то я совсем отстал от жизни. Драйвера для xorg в ядре?
Если нет, то совпадающие названия что-ли?
UPD, консольные видеодрайвера походу. Вылетело из головы совсем,- в menuconfig видел я их или нет.
Если кто надуху как ковырял .config - может напомните....

3

Ну да. Драйвера для Xorg в ядре. Нисколько не консольные. Хотя они и фреймбуфферные тоже.

Йа тьомный эльф

4 (12.12.2012 03:02:54 отредактировано Rassol2)

Ну может в ubuntu 13.04 запилят там покатаю )))
второй абзац вообще хорош )))

Никогда не бойся делать то, что ты не умеешь. Помни, "КОВЧЕГ" был построен ЛЮБИТЕЛЕМ. ПРОФЕССИОНАЛЫ построили "ТИТАНИК"

5 (12.12.2012 13:56:30 отредактировано redux)

bobr пишет:

Нисколько не консольные. Хотя они и фреймбуферные тоже.

Под словом консоль- имел в виду именно фреймбуфер.

bobr пишет:

Ну да. Драйвера для Xorg в ядре.

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

И всё-таки. Драйвера для фреймбуфера fbdev это всё-таки нечто более простое, чем иксовые драйвера.
К примеру груб увидали на экране,- уже работает фреймбуфер,- а будут ли там еще иксы- это вопрос.

так как фреймбуфер просто выполняет отрисовку кадров в область видеопамяти.
А драйвера для иксов призваны реализовывать более сложные вещи,- такие как поддержку опенGL, (каких-нибудь)D  итд.
К примеру:
xf86-video-nouveau-1.0.4.tar.bz2   
(вот http://ftp.osuosl.org/pub/blfs/svn/Xorg/ или вот
http://xorg.freedesktop.org/releases/individual/driver/  )

Если я в чем тут неправильно пишу,- прошу раскидать как надо.

6

У каждого драйвера видеокарты для иксов есть юзерспейсовая либа, которую подгружает икс-сервер, и есть ядерный модуль, который непосредственно обращается к железке.
Давно ли так? Сколько себя помню - всегда так было. А это по крайней мере, с версии 2.4.
И модули ядра, такие как radeon или nouveau являются не только драйверами для иксов, но и для фреймбуффера.
А OpenGL и прочие "более сложные вещи" реализованы отнюдь не в драйверах для иксов. Они реализованы в самой железке. А обращаться к железке может только ядро. Из юзерспейса обращаться к железу нельзя.

Йа тьомный эльф

7 (12.12.2012 16:27:17 отредактировано redux)

bobr пишет:

не в драйверах для иксов. Они реализованы в самой железке

Но, поддержка в драйвере-то должна быть?

bobr пишет:

Они реализованы в самой железке. А обращаться к железке может только ядро. Из юзерспейса обращаться к железу нельзя.

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

bobr пишет:

Давно ли так? Сколько себя помню - всегда так было. А это по крайней мере, с версии 2.4.

То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

А на сомом-то деле для Этого 3D (как пример) нужет отдельный иксовый драйвер,- отдельно он от ядра идет,- причем даже в случае открытого интел.И этот драйвер отлдичается от фреймбуферного драйвера,-
то есть мое предположение оказывается верным- названия совпадают,- сами драйвера -нет.

8 (12.12.2012 16:49:51 отредактировано redux)

.....Вот, нашел у себя на вскидку конфиг от ядра по-новее((3.1.0), которое, всмысле я сам ковырял):

#
# Graphics support
#
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_TTM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
.................

-понял я про что речь идет, это никак не искосвые драйвера, это и есть
фреймбуфер==консоль.
И названия( в целой части в смысле,- в общем то есть) совпадают с соотвествующими иксовыми.

9 (12.12.2012 16:38:11 отредактировано redux)

Могу еще согласиться с такой концепцией:
что это части одного и того же драйвера,- одна часть в ядре,- другая по желанию- для иксов, если они предусмотрены в системе. Хотя,- это разные тарболы с кодом. То есть, если называть частями,- то в широком смысле.

ЗЫ
bobr,- я это не срача ради, а истины для. bx

10

redux пишет:

То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

Прям да. Еще раз повторю: 3D реализовано в железе видеокарты. Иксовые драйвера - это только библиотеки для обращения к функциям ядерного модуля.

redux пишет:

названия совпадают,- сами драйвера -нет.

Совпадают. Библиотеки для иксов и модули ядра - это два компонента одного драйвера. Одно без другого не работает.
Скажем, есть свободные дрова (nouveau) для нвидии и есть закрытые(nvidia). И, скажем, иксовый драйвер nouveau  никак не сможет работать с модулем ядра nvidia и наоборот. Тоже самое можно сказать и о радеонах.

Йа тьомный эльф

11 (12.12.2012 16:50:52 отредактировано redux)

bobr пишет:

Прям да. Еще раз повторю: 3D реализовано в железе видеокарты.

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

Свою туманность я понял и для себя разъяснил,
я думал, что для фреймбуфера один какой-нибудь "fbdev-драйвер" в ядре,-
а оказалось - для каждой фирмы свой (заметьте фирмы, а не карты).
(И главное, ведь не обращал на это внимание, когда включал это дело мудулями в ядро.)

bobr, - спасибо подтолкнул в нужном направлении. ab

12 (12.12.2012 16:56:27 отредактировано redux)

bobr пишет:

redux пишет:

    То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

Прям да.

Вот тут только не согласен, идущий в составе ядра прям от линуса драйвер,- 3D и остальных вкусностей не несет,- оно заработает только под управлением иксового драйвера, -то есть только в нем и содержится. Во фреймбуферных же драйверах (хоть частями их называйте) - только и есть что простая прорисовка в видеопамять.(хотя, это если всё-таки упрощенно,- а если разбираться, то OpenGL можно реализовать без иксов, но на примере 3D- да )

13

Если я ничего не путаю, то код 3D как раз не в иксовых дровах, и для работы иксов 3D не нужно. То о чем вы говорите реализовано в библиотеке Mesa, которую используют свободные дрова. Либо в своих вендорских либах в случае проприетарных дров.

Йа тьомный эльф

14

bobr пишет:

код 3D как раз не в иксовых дровах, и для работы иксов 3D не нужно.

Как раз таки 3D используют приложения,- работающие как клиенты иксов, и больше никто. То есть 3D таки всегда работает через иксы (экзотику и всякие вайланды не берем сейчас в рассмотрение). Хотя если разбираться, кто первичнее в этой цепочке,- то конечно 3D дается мезой. Но реализовывается то оно на практике только иксами. Нету у нас 3D во фреймбуфере:

Ну вот, упомянутое вами Mesa, в лице mesa-utils: попробуйте перейти в истинную консоль и запустить хоть glxinfo, хоть glxgears,- не для фреймбуфера суть они,- ибо даже дисплея не обрящут.

С другой же стороны, при сборке xorg'a из сорцов,- драйвера его собираются именно обязательно,- никакой даже возможной замены для них в уже готовом на данной машине и запущенном ядре даже и не мыслимо.

С 15й стороны, при установке xorg'a в пакетном дистре,- свои драйвера он тянет лишь при собственной установке.
Не поставьте xserver-xorg-video-intel, который тянется за xorg'ом, а дайте ему всего лишь vesa-драйвер,- и какое у вас будет 3D в иксах (да хоть где)?-Никакого.
А ведь это не смотря на то, что Mesa ваша пашет при этом во всю в своих ядерных модулях. Вот и получается, что ксоргу нужны собственные 3D -дрова. И то, что они традиционно носят имена своих фирм,- так же как и соотвествующие DRM-драйвера в ядре,- породило эту тему.

15 (12.12.2012 22:04:35 отредактировано redux)

redux пишет:

Хотя если разбираться, кто первичнее в этой цепочке,- то конечно 3D дается мезой. Но реализовывается то оно на практике только иксами. Нету у нас 3D во фреймбуфере

Размышления над этой темой  уже породили во мне сомнения.

Поставим вопрос максимально конкретно:
1.Имеем  на машине систему без иксов.
2.Для упрощения задачи- карта интел,- (проприетарщину для чистоты экперимента не впутываем).

Вопрос: Можно ли как либо задействовать 3D ускорение (и ускорение чего) на такой машине-системе?

Ну, пусть ситуация типа такой, феерической: "пишем игру с 3D без иксов".  Что-то мне кажется, для того, чтобы задействовать 3D-рендеринг, мы должны будем написать свой драйвер-надстройку для ядерного DRM-модуля.-То есть не хватит нам модуля DRM ядра, или как?




- И если  о ней- о мезе. Она требуется то в системе только иксам,- ну тупо по blfs знаю,- больше сослаться не на что на вскидку.

{И рядом вопросик:

bobr пишет:

в библиотеке Mesa, которую используют свободные дрова. Либо в своих вендорских либах в случае проприетарных дров.

- и вот здесь (о проприетрщине),- не свои ли модули ( .ko ) проприетарная установка пихает?- как самодостаточные,- чего им гордым-то через линусовские к железу обращаться,- они же тут уже не юзерспейс- они сами -- ядро(ну части его)}


Вот как-бы по-подробнее и по-яснее  тут, а?

16

Собственно на основной вопрос отвестить помогла википедия:

вики пишет:

Mesa ....на сегодняшний день является частью X.Org.

- то есть не будет никакого 3D без иксов. И драйвера у ксорга на это дело свои- отдельные,- насколько может быть отдельный код в отдельном тарболе на серверах проекта Xorg (а ни на kernel.org)

И чтобы попользовать 3D без иксов надо это дело в новый проект упаковывать....- ну то есть только гипотетически так можно- в принципе,- на на практике-шиш.

17

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

18 (12.12.2012 22:21:31 отредактировано redux)

yars пишет:

Я, конечно, в этом не очень разбираюсь, но то, что 3D сейчас используется в основном иксами и их клиентами-приложениями еще не значит, что на машине без иксов нельзя смотреть фильмы . И

Для воспроизведения фильма не нужно просчитывать мильоны треугольников в секунду,- это не 3D.
(к примеру кино можно смотреть на vesa-драйвере, а он, как известно 2D-драйвер).


yars пишет:

не значит, что на машине без иксов нельзя смотреть фильмы .

- конечно не значит, mplayer прекрасно показывает кино в консоли на машине, где вообще нет иксов.- он кадры свои во фреймбуфер передает и все,- это не 3D.

Картинка для кино уже готова и лежит в файле с фильмом. Ее на ходу вычислять не нужно, когда, например герой игры бежит по коридору и тд.

yars пишет:

Я, конечно, в этом не очень разбираюсь,

- если б я разбирался,- я бы тут ничего не спрашивал. bx

19

lupo@gentoo-laptop ~ % uname -a
Linux gentoo-laptop 3.7.0-funtoo-r0a #1 PREEMPT Wed Dec 12 20:17:13 FET 2012 i686 Genuine Intel(R) CPU T1350 @ 1.86GHz GenuineIntel GNU/Linux
Был, был и весь вышел...

20

Lupo Alberto,- ядро собрали,- поздравляем. А мы тут около вашего ядра вопросы обсуждаем.- Присоединяйтесь ab

21

Aptosid радует - вчера ядро уже было в репах http://oscar.aptosid.com/debian/pool/ma … x-aptosid/

История показывает, что во всем новом обычно кроется какой-то подвох.
Классическая ошибка, которую совершают проектировщики
абсолютно надежных систем, - недооценка изобретательности клинических идиотов.

22

redux пишет:

Для воспроизведения фильма не нужно просчитывать мильоны треугольников в секунду,- это не 3D.
(к примеру кино можно смотреть на vesa-драйвере, а он, как известно 2D-драйвер).


yars пишет:

не значит, что на машине без иксов нельзя смотреть фильмы .

- конечно не значит, mplayer прекрасно показывает кино в консоли на машине, где вообще нет иксов.- он кадры свои во фреймбуфер передает и все,- это не 3D.

Картинка для кино уже готова и лежит в файле с фильмом. Ее на ходу вычислять не нужно, когда, например герой игры бежит по коридору и тд.

ОК. Согласен. Тогда так: что такое вообще Mesa? Это, как я понимаю, API - OpenGL. В чем задача API? Предоставить стандартизированный интерфейс. Но железо-то бывает разным, значит, нужен еще один посредник - драйвер, он же ядерный модуль.  Что есть драйвер? Опять же, интерфейс, только на этот раз - между железом и API. То есть, никаких дополнительных  надстроек нам писать, имхо, не нужно. Как-то так ab

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

23 (12.12.2012 22:48:03 отредактировано redux)

yars, меза - нынче- часть проекта Xorg и без оного не будет 3D см выше, я на вику постил. bx
Если кратко зайдите в настоящую консоль и попробуйте запустить стандартные утилиты mesa- они даже не запустятся.

В принципе,- да позволяет пользование OpenGL без Xorg, но на практике это где-нибудь реализовано, кроме проекта xorg?

Вопрос то изначально был, находятся ли видеодрайвера для ксорг уже в ядре (мы выяснили это DRM), либо их надо специальные иксовые ставить(да надо).

24

redux, да, я еще за эти уже почти два года знакомства с Linux, такой программы, кроме иксов, не встречал. Но все это время я считал, что фреймбуфер - это графический режим. Все-таки в нем доступно куда больше, чем в чисто текстовом режиме.

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

25 (12.12.2012 23:02:54 отредактировано redux)

yars пишет:

Но все это время я считал, что фреймбуфер - это графический режим.

Да - графический. Дословно- "кадровый буфер". У вас есть битовая карта картинки,- вы ее туда отправляете,- она появляется в области памяти,- откуда берет монитор, чтобы показывать.
А вот будет ли фреймбуфер полигоны обсчитывать, используя десятки ядер GPU на борту видеокарты?
По-моему вот именно тут отличие фреймбуфера от 3D  у ксорга.

Вика( http://ru.wikipedia.org/wiki/Direct_Ren … astructure )
по этому поводу пишет, если кратко:
Без иксов можно. Но на данный момент реализация практическая только в иксах этого OpenGL. И (я уже пишу): для этого иксам нужен еще видеодрайвер,- вместе они с DRM будут давать результат.

26 (12.12.2012 23:12:17 отредактировано redux)

Короче говоря, можно без иксов 3D (это будет реализовано через OpenGL). (В случае открытых дров!).

Но вот когда 3D с иксами,- ему надо еще видеодрайвер под конкретную фирму видеокарты. Почему так сделано?
Я думаю, чтоб ы сделать общим интерфейс подкючения и открытых и проприетарных дров к икс-серверу.
Разделили их на две части. Причем в случае проприетращины, без иксов 3D не будет ибо драйвера для OpenGL для проприетарных карт только для иксов (Не?)
И вот как появился методом обратной разработки Nouveau, и достиг хорошего уровня работы,- его засунули в ядро.