А в содержимое смотрел-то хоть? Там в половине файлов тупо ещё один #include.

Как насчёт такого варианта?

$ grep ' T ' /boot/System.map-$(uname -r) | awk '{print $3}' | wc -l
15704

Хороший вариант, но мне нужно получить их именно из header'ов.

ну, во-первых, _ потерян, но все-равно получится только ~197

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

Добавил _. Ну, мне нужен список всех функций, которые можно дёрнуть. Но не просто список, а с параметрами.

дернуть от куда?
из юзерной проги или из ядра?

Из юзерной проги.

Э-э-э... My best shot.

$ ls -1 /usr/include/x86_64-linux-gnu/sys/*.h   \
| awk '{print "#include <" $1 ">"}'             \
| gcc -E -o- -xc -                              \
| grep '^extern '                               \
| sed -e 's/^extern //'                         \
      -e ':loop'                                \
        -e 's/^unsigned //'                     \
        -e 's/^signed //'                       \
        -e 's/^long //'                         \
        -e 's/^struct //'                       \
        -e 's/^union //'                        \
      -e 't loop'                               \
| awk '{print $2}'                              \
| grep -v ';$'                                  \
| wc -l
444

gcc

А, хитро.
Он ещё и ненужные хедеры отбрасывает:

/usr/include/x86_64-linux-gnu/sys/elf.h:22:3: error: #error This header is unsupported on x86-64.
 # error This header is unsupported on x86-64.
   ^
In file included from <stdin>:81:0:
/usr/include/x86_64-linux-gnu/sys/vm86.h:24:3: error: #error This header is unsupported on x86-64.
 # error This header is unsupported on x86-64.
   ^

а у меня только так...

grep -i "^extern [a-z_0-9]*" /usr/include/x86_64-linux-gnu/sys/*.h | awk 'FS=":" {print $2}'
221

awk 'FS=":" {print $2}'

Почему-то у меня это некоторые строки корёжит. Хотя двоеточие в каждой строке только одно.
Но есть же ключ -h у grep.

$ grep -h "^extern [a-z_0-9]*" /usr/include/x86_64-linux-gnu/sys/*.h | wc -l
225

у меня -h только пустые строки выдает...

$ ls -1 /usr/include/x86_64-linux-gnu/sys/*.h   \
| awk '{print "#include <" $1 ">"}'             \
| gcc -E -o- -xc -                              \
| grep -oP '^extern .*? [a-zA-Z0-9_*]+ \('      \
| awk '{print $(NF-1)}'                         \
| sed 's/^*//'                                  \
| wc -l
442

А ещё имена функций могут как бы начинаться со звёздочки для тех, кто возвращает указатели.

И скобка там обязательна в регэкспе, а то попадают extern struct, которых там быть не должно.

тут ищутся только системные (доступные из юзер-спейса)

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

Возможно, я использую неправильную терминологию. Меня интересуют функции типа mount, kill, mknod и всё линукс-специфичное.

При компиляции генерируется System.map, там есть все экспортируемые символы, еще можно сделать readelf на само ядро. Если грипать именно по исходникам, то можно вспомнить про макрос:

EXPORT_SYMBOL(alloc_anon_inode);

Можно сформировать список имен функций, а потом уже грипать в поисках именно прототипов, а не вызовов. Кстати очень быстро в это умеет git grep

А что ты конкретно хочешь, в чем задача?

Что-то маловато. Так и должно быть?

cat /boot/System.map|wc -l
70795

А столько хватит?

А зачем? Просто, не проще посмотреть реализацию того-же mount в glibc и посмотреть какие она использует системные вызовы. Говорят напрямую вызывать ядро из своей программы - моветон.

напрямую вызывать ядро из своей программы - моветон

Ладно, попробую найти обходной путь.

libc и есть обходной путь, зачем его искать?

Вообще непонятно, что именно тебе нужно, и ты не можешь это сформулировать. А вообще, посмотри, что можно вытянуть из LXR.

man syscalls

здрасьте! я о этих (в дереве ядра) include/linux/syscalls.h функциях

это как-раз те самые «системные вызовы»

И тебе здрасте.. научи меня sys_exit() вызвать на x86, из юзерспэйса? Толку что у них есть имена?

научи меня sys_exit() вызвать на x86, из юзерспэйса?

блин :)
тебе функции отдаются без sys_, так что пиши просто exit(). Не стоит благодарности.

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

как glibc вызывает, так и без неё в любой программе можно

есть ещё man syscall для того, что не имеет обёрток в glibc

точки входа указаны в System.map

А когда это юзерспейсный процесс научился в пространство ядра?

так что пиши просто exit()

И glibc само вызовет исключение с номером соответствущего системного вызова НЕ ИМЕНЕМ.

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

я не и говорил, что можно линковать с ядром обычную прогу, ты сам-то откуда это взял?? %)

ты сам-то откуда это взял

Я написал:

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

Ты ответил:

здрасьте! я о этих (в дереве ядра) include/linux/syscalls.h функциях

Т.е. если тебе понадобилось ответить, то ты хотел сказать что я в чем-то неправ? В чем?

не линкуется, но вызывается через/с помощью прерывания 0x80
ну окей, не «вызвается», а «дергается» - так понятнее будет? :)

Ну да, и я это и подразумевал под другим механизмом. Просто ты говоришь:

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

я и подумал что ты имеешь в виду линковку.. а что ты этим хотел сказать?

с помощью прерывания 0x80

Афаик, там по возможности используется спец-инструкция sysenter, а прерывания оставлены в качестве фоллбека.

да эт уже _меня_ проглючило... :-\
последие две неделии вся голова в мыслях о ядре, причем не о нашем уютном, а о вражеском оффтопиковском ;(

// причем заказ на девайс, в конечном итоге, для горкорпорации, но они Linux еще не осилили, не смотря на все крики о «Российской ОС»/МСВС/AstraLinux. А NASA-блок МКС уже год как на Дебиане. Ну эт ладно... наболело просто %)

да, точно, мои сведения уже устарели %)

спец-инструкция sysenter

В пользовательской программе не обязательно использовать sysenter и обвязку для нее. Готовый код отображается в пространство каждого процесса. Это вроде называется vsdo.

vDSO? Похоже metawishmaster прав. Не совсем понятно как оно работает, но занятно.

man vdso

да, забыл как это называлось и где читал, а когда не вспомнил, пошел на попятную :-\

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

p.s. кстати, от сюда же вытекает то, что при размере оперативки в 4Гига пользовательскому приложению будет доступно только 3Гб - 1 Гб мапится на ядро. Ну и, разумеется, это можно регулировать в ядре. В смысле, можно делать 3:1, 2:2, даже 1:3 %)

не на x86_64

при размере оперативки в 4Гига пользовательскому приложению будет доступно только 3Гб

Linux в отличие от форточек поддерживал PAE достаточно давно.

и у оффтопика такого не было, и по-моему до сих пор нет

Главное повторять эту мантру почаще, верить в исключительность линукса и есть мозоли на завтрак обед и ужин.

малыш-кайк, на твою фигню отвечать - это до твоего уровня спускаться... если есть что сказать, так не говори голословно. пруф нужен.
я нашел пруф, вот тебе цитата: «So if application code running in user-mode (at privilege level 3) cannot call code running in kernel-mode (at privilege level 0) how do system calls in Windows NT work?». дальше рассказывают про Interrupt-gate. Андерстенд?

а следовательно, mein trottelig kind, мое «и у оффтопика такого не было, и по-моему до сих пор нет» можно/нужно заменить на «и у оффтопика такого не было, и до сих пор нет».

Ути какие мы гордые. Не хотим до малышей опускаться. Хотим постить unrelated «пруфы».

vdso был введён для ускорения некоторых системных вызовов путём делания видимыми некоторых ядерных переменных в userspace, чтобы было возможно их прочитать не ныряя в ядро.

Аналогичный приём используется в Windows®™ начиная эдак с Windows®™ 95®™. Всего-то 20 лет.

но почему-то никакого механизма кроме «System calls in Windows NT are initiated by executing an „int 2e“ instruction.» там не указано