call to linux with interrupt

[watashiwa_daredeska]

а если на ассемблере?

Тебя чем-то не устраивает ассемблер? Извини, так уж устроен Linux и C, что syscall без ассемблера никак.

i	Уведомление от модератора sash-kan
	отрезано от лили ли лиnux?

[sash-kan]

а если на ассемблере?

Тебя чем-то не устраивает ассемблер?

эээ, гхм, ну я просто предложил попробовать воспользоваться языком низкого уровня для решения нетривиальной задачи при работе с оборудованием (конкретно — трусами)·
ааа! наверно, с трусами тоже linux работает, и просто драйвера не хватает (от производителя трусов)·

Извини, так уж устроен Linux и C, что syscall без ассемблера никак.

ух ты! правда, что ли?

[watashiwa_daredeska]

ух ты! правда, что ли?

Правда. Функция syscall реализована на ассемблере во всех известных мне реализациях libc.

вот ты удалил /usr/bin/X, и возможности оператора сузились·

Вот ты удалил libc, и возможности оператора сузились.

[sash-kan]

ух ты! правда, что ли?

Правда. Функция syscall реализована на ассемблере во всех известных мне реализациях libc.

ну, в той же glibc на ассемблере много чего остаётся написанным (и не только для linux-а, но и для всех остальных поддерживаемых ядер):
$ find glibc-2.9 -type f -name \*.S | wc -l
1187
$ find glibc-2.9 -type f -name \*.S | xargs cat | wc -l
237107
почему так? а потому что быстрее работает…

вот ты удалил /usr/bin/X, и возможности оператора сузились·

Вот ты удалил libc, и возможности оператора сузились.

да-да, лишь немножко (в случае libc) сузились·
до абсолютного нуля·

[watashiwa_daredeska]

почему так? а потому что быстрее работает…

Не потому. Но ежели ты приведешь реализацию syscall на чистом C, без библиотек, то пожалуй соглашусь.

до абсолютного нуля·

Ну, определение ОС, данное тобой в самом начале обсуждения, выполняется. Или мы уже о чем-то другом говорим?

[sash-kan]

почему так? а потому что быстрее работает…

Не потому. Но ежели ты приведешь реализацию syscall на чистом C, без библиотек, то пожалуй соглашусь.

я приводил выше ссылку на man syscall, где эта функция определена на чистом си·
в случае glibc по дефолту gcc заменит её на код из glibc-2.9/sysdeps/unix/sysv/linux/i386/syscall.S (там, кстати, ещё куча макро-подстановок, это я просто к слову)·
если пошаманить (извини, я не силён ни в си, ни в *cc, поэтому не подскажу — как именно), то gcc строку "syscall(x)" заменит сразу на нужные машинные команды·
ну, как он делает, например, в случае "inc(x)"·

p.s. написал и подумал: а вдруг и inc() в glibc тоже расписана в виде ассемблера в каком-нибудь *.S файле?
ну, в таком случае, пример надо взять какой-нибудь другой; я очень надеюсь, что ты не будешь «проезжаться» по моим поверхностным познаниям потрохов всех этих сей, [гэ]либсей и [гэ]сесей·

до абсолютного нуля·

Ну, определение ОС, данное тобой в самом начале обсуждения, выполняется. Или мы уже о чем-то другом говорим?

о майн гад! т.е., к слову «посредник» я должен был добавить ещё и слово «работоспособный»?
чёрт, пошёл искать какую-нибудь книгу по юриспруденции: пора мне уже каждый свой пост оформлять с такой же тщательностью, как и договор купли-продажи, со всеми полагающимися оговорками, определениями терминов, критическими местами, набранными мелким шрифтом, и т.д. и т.п.

[bormant]

почему так? а потому что быстрее работает…

Не потому. Но ежели ты приведешь реализацию syscall на чистом C, без библиотек, то пожалуй соглашусь.

я приводил выше ссылку на man syscall, где эта функция определена на чистом си·

Федот, да не тот. По приведённой выше ссылке: объявление (declaration) функции syscall() -- контракт о вызове с набором аргументов (к слову сказать, наличие у компилятора C "перед глазами" объявления функции необязательно, его отсутствие не даст проверить правильность вызова, но не помешает компиляции). А вот реализация её (definition/implementation), как правильно заметили, в файле

glibc-2.9/sysdeps/unix/sysv/linux/i386/syscall.S (там, кстати, ещё куча макро-подстановок, это я просто к слову)·

как раз на ассемблере. Вот о замене той реализации на реализацию на чистом C, без вызовов функций, содержащих ассемблерный/машинный код, и шла речь. Дело в том, что в "языке C" отсутствует возможность вызова прерывания языковыми средствами (ассемблерный int Num), а реализации выполнены специальными функциями, частью языка C не являющимися.

[sash-kan]

bormant
вы всё верно пишете·
но цитируете вы мои возражения, которые изначально вызвала вот эта фраза:

Извини, так уж устроен Linux и C, что syscall без ассемблера никак.

к сожалению, я не располагаю информацией, во всех ли компьютерных архитектурах переключение в привилегированный режим осуществляется вызовом прерывания·
ну, допустим, во всех (где используется тот или иной вид привилегированных/непривилегированных режимов)·
опять-таки к моему сожалению, я не располагаю списком компьютерных архитектур, в которых такие режимы вообще не используются·
но существование таких архитектур явно следует из статьи wikipedia://CPU modes:

CPU modes (also called processor modes, CPU states, CPU privilege levels and other names) are operating modes for the central processing unit of some computer architectures

я склонен доверять этой информации·
если у вас есть ей опревержения, буду рад их услышать·
например, в таком виде: «linux может работать только на тех архитектурах, в которых есть "cpu modes", и переход в привилегированный режим на всех таких архитектурах осуществляется только вызовом прерывания»·

а то, что вызов прерывания не входит в стандарт языка си, я, конечно, знаю, и с _этим_ не спорю·

[sash-kan]

p.s. пожалуй, дискуссию о жёсткой привязке syscall-ов linux к вызову прерываний стоит отрезать в новую тему·

upd. отрезал·

[sash-kan]

Но ежели ты приведешь реализацию syscall на чистом C, без библиотек

кстати, роясь в исходниках glibc·
а это чего такое?

Код: Выделить всё

$ tail -n 17 glibc-2.9/misc/syscall.c
#include <sysdep.h>
#include <errno.h>
#include <unistd.h>

/* Do system call CALLNO, passing it the remaining arguments.
   This only makes sense in certain operating systems.  */

long int
syscall (callno)
     long int callno;
{
  __set_errno (ENOSYS);
  return -1;
}

stub_warning (syscall)
#include <stub-tag.h>

[bormant]

А это реализация-затычка: устанавливает ошибку ENOSYS и возвращает -1. Но не больше.

ссылку на man syscall, где эта функция определена на чистом си·

Повторюсь, суть возражения была в том, что по ссылке функция не "определена", а "объявлена". А вот определена она совсем не на Си.

[sash-kan]

А это реализация-затычка: устанавливает ошибку ENOSYS и возвращает -1. Но не больше.

ну, т.е., условию ваташивы:

ежели ты приведешь реализацию syscall на чистом C, без библиотек, то пожалуй соглашусь.

она (формально) удовлетворяет·

p.s. да-да, приходится буквоедствовать, но это только ответная защитная реакция на встречное буквоедство·
в ответ ваташива скажет «но эта реализация неработоспособна!»·
а я в ответ напишу: «а ты ничего не говорил про работоспособность!»
(улыбка)

[bormant]

sash-kan, не пройдёт :) Она хоть и называется syscall(), но никакого вызова не выполняет, ни системного, ни иного (__set_errno обычно простой define).

[sash-kan]

bormant
перечитайте мой последний пост·
я вносил в него дополнения, видимо, после того, как вы его прочитали·

отсылка про работоспособность была вот к этим словам:

о майн гад! т.е., к слову «посредник» я должен был добавить ещё и слово «работоспособный»?

[sash-kan]

Извини, так уж устроен Linux и C, что syscall без ассемблера никак.

финальный штрих: а без ассемблера си вообще никак·
1. переименовываю ассемблер:
$ /bin/sudo mv /usr/bin/as{,.save}
2. пытаюсь скомпилировать программу и получаю ошибку:
$ make helloworld
cc helloworld.c -o helloworld
cc: error trying to exec 'as': execvp: No such file or directory
make: *** [helloworld] Error 1

сам файл примитивнейший:

Код: Выделить всё

$ cat helloworld.c
main()
{
    return 0;
}

может быть, gcc можно запустить так, чтоб он не использовал ассемблер, а сразу записывал машинные коды? или он так не умеет?