Uapi linux version h

Nvidia 173.14 и сырцы ядра

Почитал ридми по установке драйвера. Поставил, как там требовалось kernel-source, убедился в наличии ld При попытке запустить получаю ошибку

ЧС^W Что в высшей мере характерно, этих файлов действительно там нет. Зато есть другие:

Получаю другую ошибку:

Что я делаю не так? За три часа гугления нащупал только то, что вроде как сырцы нужно некоим образом сконфигурить. Типа в /usr/src должен лежать .config Ткните носом, что делать, куда рыть конкретнее? Примечательно то, что эта же карта (fx5200) прекрасно работала на другой машине, с этим же дистром

37-й уже пробовал. Только что проверил. Раньше карточка работала, похоже, на 173.14.05 Кочаю.

Бесполезно. «Сырцы не сконфигурированы и баста».

Вопрос снят, тема закрыта.

В общем, в заблуждение ввел талмуд nvidia. Там сказано, что для установки нужен либо kernel-sources, ЛИБО kernel-devel. Я почему-то думал, что первое включает второе. Ноу. Мне понадобилось и то, и другое. Дрова счастливо встали, как надо.

Типа в /usr/src должен лежать .config Ткните носом, что делать, куда рыть конкретнее?

На будущее — make prepare

Спасибо. А я попробовал было make config, и офигел от количества вопросов. На сотом, наверное, плюнул и решил поискать другие пути. Не зря.

Кстати еще: в прошлый раз ставил kernel-source из репы. И зипер змей мне впарил сырцы 3.1.10 В то время как

zcat /proc/config.gz > /usr/src/linux/.config && make prepare

Если в /proc/ конфига нету — должен быть в /boot/

А make config — это как make menuconfig, только оно тебя все опции спрашивает само 🙂

Да, этот допрос утомил но и впечатлил, — тонкостью/гибкостью настройки. Хотя даже трети опций не понял. Теперь вполне понимаю профит самопального ядра. По идее можно пилить ядро под конкретную машину, без лишних модулей, с минимальным весом и четко подобранным под род деятельности функционалом. Хочешь — сервак с блекджеком и шлюхами, а хочешь, минимальное ядро для флешки. При этом достаточно просто представлять себе смысл опций, и тыкать [y/n], ковыряться в коде не приходится. Мда, пингвинье дао пингвинье

ессно не приходится. сложность сборки ядра и установки-настройки всяких сорцовых дистров очень сильно преувеличена.

Ну и что непонятного во фразе The most likely reason for this is that the kernel source files in ‘/usr/src/linux’ have not been configured ?

Источник

Заметка о новом интерфейсе linux kernel — gpio uapi

Начиная с версии ядра 4.6-r1 нам стал доступен новый интерфейс для взаимодействия с подсистемой ядра gpio. Теперь существует три официальных способа работы с gpio и получения от них прерываний. Нет смысла углубляться в потребности для данной подсистемы, для малой части это суровые будни, для другой части веселое хобби, и для всех вместе в ядре была предоставлена новая возможность взаимодействия.

Заметка носит популярный характер, так как основных преимуществ, которые шли в комплекте с нововведением, а именно упрощение работы с gpio в контексте ядра касаться не будем.

Новый интерфейс uapi gpio

Во-первых, теперь gpiochip это действительно устройство и его можно видеть в devfs в виде gpiochipN, где N номер чипа присвоенный в порядке инициализации. Во-вторых, вся настройка теперь осуществляется через ioctl. И в-третьих чтение и запись, как это ни удивительно, осуществляются через вызовы read/write, правда с помощью специальной структуры struct gpiohandle_data.

gpio-mockup

Начиная с версии ядра v4.9-rc1 (использовать его фактически получится только в версиях старше v4.12-rc1) стал доступно устройство виртуальных gpio, с поддержкой управления состояниям посредством debugfs.

Рассмотрим на примере разницу между sysfs и uapi в userspace.

Инициализация gpio-mockup

• gpio_mockup_ranges — пары чисел для инициализации gpiochips, в виде «base,end», где base стартовый номер, end — конец диапазона.
• gpio_mockup_named_lines — boolean параметр, в случае если задан присваивает каждой линии метку в виде gpio-mockup-A..Z-N, где N порядковый номер линии в банке.

Данной командой мы создали два gpiochip по 8 линий каждый, c диапазонами [0-8), [8,16). Про gpio_mockup_named_lines мы поговорим чуть позже.

Сравнение sysfs и uapi

С помощью нового драйвера рассмотрим отличия между двумя системами с точки зрения пользователя.

Информация о gpiochip’s

sysfs

Задание линии как входа и чтение значения

sysfs

Задание линии как выхода

sysfs

Edge handling

sysfs

Polling on events

В документации ядра для sysfs указано использовать EPOLLPRI и EPOLLERR (или exceptfds для select), это в принципе характерно для любого вызова sysfs_notify необязательно именно для подсистемы gpio.

Для uapi достаточно EPOLLIN.

Читаем мы событие с временной меткой и типом GPIOEVENT_EVENT_RISING_EDGE или GPIOEVENT_EVENT_FALLING_EDGE.

EPOLLET для uapi работает согласно документации на epoll.

labels

Маленькая ремарка для sysfs

Имя контакта gpioN к которому так все привыкли, вообще говоря, каноническим не является, а используется если контакту не было присвоено имя, например в Device Tree.

Попробуем gpio-mockup с опцией gpio_mockup_named_lines:

Как мы видим имя контакта приобрело вид gpio_chip_label—gpio_offset, но это справедливо только для драйвера gpio-mockup.

Способа «угадать» заранее, существует ли имя для контакта, не используя uapi не представляется возможным, а поиск экспортированной «именованной» линии затруднен, если имя заранее не известно (опять же если известно, то нам для однозначной идентификации необходимо имя и смещение на известном gpiochip).

Интерфейс uapi позволяет нам без инициализации видеть имена линий:

С соответствующим файлом device tree (пример взят из документации ядра):

Мы бы видели имя в struct gpioline_info для каждого контакта, к сожалению, мало кто именует контакты, даже для распостраненных SBC.

Возможности uapi недоступные для sysfs

Теперь перечислим преимущества недоступные старому интерфейсу.

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

Если позволяет драйвер устройства, линия дополнительно может быть сконфигурирована как открытый коллектор (GPIOLINE_FLAG_OPEN_DRAIN) или открытый эммитер (GPIOLINE_FLAG_OPEN_SOURCE), данное нововведение как раз может быть легко перенесено в sysfs, но этого не будет так как Линус Ваерли против.

Так же новый api позволяет присваивать каждому контакту пользовательские ярлыки при инициализации в struct gpiohandle_request поле consumer_label.

И в заключение позволяет «читать» и «писать» сразу группу состояний для контактов.

Заключение по сравнению

Субъективно, uapi выглядит более громоздким, чем sysfs, но не стоит забывать, что сравнивали мы управление через стандартные утилиты GNU cat и echo и C код, если сравнивать C код для каждого из интерфейсов, получится приблизительно тоже самое по сложности и объему.

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

Преимущества uapi

Критика uapi

Официальной или неофициальной критики нет, или я её не нашёл. Поэтому обойдемся парой собственных мыслей.

• Непонятно почему обошли стороной push-pull, debounce, и pull-up, pull-down.
• В struct gpioevent_data неплохо было бы добавить параметр value с текущим значением линии

Критика sysfs gpio

Закончим официальной критикой интерфейса sysfs. Линусом Ваерли (сопровождающий в ядре подсистемы gpio и pinctrl) в комментариях к патчам были выдвинуты следующие тезисы:

• Невозможно включить выключить сразу несколько линий одним вызовом
• Для работы sysfs должен быть включен соответствующий ключ в конфигурации ядра
• В случае краха приложения gpio линии остаются в «инициализированном» состоянии
• Затруднён поиск необходимой линии
• «Sysfs is horribly broken» ©

В общем, и, если честно, я считаю, что sysfs вполне нормален, для тех задач, которые возлагаются на gpio в userspace. В нём есть нечто романтичное, когда люди не знакомые даже с основами электротехники могли зажигать свет с помощью echo. С помощью нового интерфейса такой прямой связи не чувствуется, так как теперь требуются дополнительные утилиты для взаимодействия.

But GPIOs are often used together as a group. As a simple example (and the only), consider a pair of GPIOs used as an I2C bus; one line handles data, the other the clock.

По поводу первого тезиса ничего сказать не могу, никогда не сталкивался с такой необходимостью, в конце концов можно сразу инициализировать контакты как входы или выходы в device tree. Знаю, что данная функциональность пригодилась бы тем кому нужен bit-banging в user-space, но здесь существует одно но, на чистом linux, bit-banging возможен разве что для очень низкочастотных вещей, а так нужeн как минимум PREEMPT_RT patch.

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

Третий еще более странен, может просто не надо «краха» приложения?

По поводу четвертого могу сказать, что ничего принципиально почти не поменялось. Если указанный в платформенном драйвере или в device tree label для gpiochip соответствует действительности, то «поиск» несложен, а если они названы «черти-как», то интерфейс здесь уже никак не поможет.

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

Утилиты

Для uapi их пока далеко не так много, как для sysfs.

Linux kernel gpio tools

• gpio-event-mon — утилита для отслеживания событий gpio линий
• gpio-hammer — включает/выключает линию n раз с фиксированной частотой
• lsgpio — пример листинга gpiochip и линий

libgpiod

От автора драйверов gpio-mockup и irq-sim товарища Bartosz’a Gołaszewski.

Позиционируется автором как библиотека, для облегчения работы с gpio посредством нового интерфейса uapi, так же содержит набор полезных утилит.

• gpiodetect — листинг gpiochip с именем, ярлыком и количеством линий
• gpioinfo — листинг gpiochip с именем, смещением, ярлыком и статусом линий
• gpioget — читаем состояние линии
• gpioset — задаем состояние линии, и если необходимо держим линию занятой до истечения заданного времени, сигнала или пользовательского ввода
• gpiofind — находит линию по имени и выводит устройство gpiochipN и смещение линии
• gpiomon — то же самое, что и gpio-event-mon

Источник

Missing «version.h» when installing fglrx

I have downloaded the fglrx driver installer from the ATI drivers page.

when I start the installation, everything goes smoothly until I hit an error message, telling me to check /usr/share/ati/fglrx-install.log .

The contents of that file are as follows:

Check if system has the tools required for installation. fglrx installation requires that the system have kernel headers. /lib/modules/3.8.11-200.fc18.x86_64/build/include/linux/version.h cannot be found on this system. One or more tools required for installation cannot be found on the system. Install the required tools before installing the fglrx driver. Optionally, run the installer with —force option to install without the tools. Forcing install will disable AMD hardware acceleration and may make your system unstable. Not recommended.

Now, after a bit of searching around, I found that the symbolic link called build in /lib/modules/3.8.11-200.fc18.x86_64 points to a nonexistent location.

I installed the kernel-devel package, and now it had pointed to an existing directory.

However, in the /lib/modules/3.8.11-200.fc18.x86_64/build/include/linux/ directory, that is populated with various header files — I cannot find the one I need — version.h .

How can I solve this problem? Should I install the driver in a different manner? Which other package can I install to get the version.h file?

I’m running a clean install (default) of Fedora 18, which I had updated today.

Источник

What is the path to the kernel headers so I can install vmware?

I installed the VMware bundle on my Ubuntu 11.04 successfully but when I open it it gives me this window

and I don’t know the path to this C headers.

8 Answers 8

After adding the symlink, the path is /usr/src/linux-headers-$(uname -r)/include (Thanks @Kariem!)

Below commands are very helpful for you:

Step 1 : Ctrl + Alt + T

Step 2 : sudo apt-get install linux-headers-$(uname -r)

Step 3 : The path to the kernel headers is then /usr/src/linux-headers-$(uname -r)/include

Before installing Vmware Workstation you need to install build-essential and linux headers

Done thats it, install Vmware Workstation now

There are a few files in locations that the installer doesn’t expect, I run this and it works:

My first guess is that you haven’t installed the headers. You need to install the appropriate linux-headers package. Most likely, you need to install linux-headers-generic . However, if if you’re running some kernel other than linux-generic , install the linux-headers package for that kernel.

If you’ve already installed the headers, they should be in /usr/src .

Источник