Once again, we firstly provide the code, and then explain the example code.
Где же explanation?)
Приводить в пример scull драйвер - это, конечно, сильно, особенно, если вы не собираетесь объяснять, что там происходит. Почему бы не написать обычный "Hello World", как, например, в SimpleLinuxDriver? Есть даже статья, которая достаточно хорошо описывает, что, как и зачем делается, включая то, почему ваше устройство нужно создавать руками через mknod и как это сделать из LKM.
В старых версиях ядра таким же методом загружалось и удалялось само ядро
Что? Приведите, пожалуйста, ссылку на источник, где вы это нашли
и именно в драйвере определяется define/open/read/write
Интересная операция define, никогда о ней не слышал))
Например, совершая операцию “open” (открыть) с устройством под управлением драйвера, я выполняю функцию scull_open, что эквивалентно «перехвату» функции open в системном вызове.
Не совсем правда, никто ничего не перехватывает, VFS вызывает ->open(...) и в зависимости от файловой системы -> будут вызваны разные функции для разных FS, т.к. будут получены разные структуры file.
сначала читать книги, чтобы усвоить базовые концепции, а затем искать информацию по конкретным деталям, когда дойдёт дело до практического применения
IMHO, этот гайд применим для изучения абсолютно всего, что угодно.
Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended.
А также по поводу sync перед дропом кэшей:
This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped.
И что если в свопе больше чем RAM может вместить, а система пытается дропнуть весь своп обратно в память?
Начнем с больного места многих версий Linux. Разработчики совсем не любят заморачиваться поддержкой оборудования
Ну уж нет, в Linux есть поддержка огромного количества оборудования, которое очень часто дополняется, включая топовые версии процов Intel/AMD, и т.п.
В целом РЕД ОС оставила очень приятное впечатление. Очень простая установка, даже на старую машину и параллельно с Windows.
А чем сложнее установка RHELL/Ubuntu/Debian и т.п.?
Отлично решается задача установки периферии – все действия «Муром» выполняет автоматически, не требуя при этом множества дополнительных действий.
Вопрос тот же. RHELL/Ubuntu/Debian делают по сути тоже самое, стоит упомянуть, что речь идёт о KDE (на всякий случай)
Иными словами, РЕД ОС – это Linux, в котором можно вообще обойтись без терминала.
Вопрос тот же. DE (Desktop Environment) для Linux уже много лет разрабатываются в подобном направлении, в частности KDE очень проста в использовании и там можно обойтись без терминала для обычного пользователя
родовая боязнь разработчиков всех без исключения дистрибутивов Linux показаться слишком похожими на Windows.
Хотелось бы увидеть чуть более подробное описание vectorcall.
Также стоило бы упомянуть, что вы используете Win32 ABI, т.к. в System V ABI есть отличия для наименований, количестве передаваемых в регистрах аргументов для fastcall и т.д.
Да, вы абсолютно правы, в статье нет упоминания про expand up стек, про то, как ведёт себя стек при каких-либо исключениях процессора и много чего ещё, к сожалению
Изначально казалось, что статья будет необоснованно большой, если начать писать про все команды, влияющие на поведение стека, такие как pusha/popa, pushad/popad, pushf/popf и многие другие, а также при расписывании всех EFLAGS, которые могут быть затронуты при операциях на стеке, хотя про совместимость инструкций push sp я однозначно дополню статью, остальные замечания, лучше, думаю, будет описать во второй части статьи, т.к., действительно, я о многом не рассказал, что касается стека i386, в данной статье.
Где же explanation?)
Приводить в пример scull драйвер - это, конечно, сильно, особенно, если вы не собираетесь объяснять, что там происходит. Почему бы не написать обычный "Hello World", как, например, в SimpleLinuxDriver? Есть даже статья, которая достаточно хорошо описывает, что, как и зачем делается, включая то, почему ваше устройство нужно создавать руками через mknod и как это сделать из LKM.
Что? Приведите, пожалуйста, ссылку на источник, где вы это нашли
Интересная операция define, никогда о ней не слышал))
Не совсем правда, никто ничего не перехватывает, VFS вызывает ->open(...) и в зависимости от файловой системы -> будут вызваны разные функции для разных FS, т.к. будут получены разные структуры file.
IMHO, этот гайд применим для изучения абсолютно всего, что угодно.
А теперь чутка документации на drop_caches (её иногда полезно читать):
А также по поводу sync перед дропом кэшей:
И что если в свопе больше чем RAM может вместить, а система пытается дропнуть весь своп обратно в память?
Ну уж нет, в Linux есть поддержка огромного количества оборудования, которое очень часто дополняется, включая топовые версии процов Intel/AMD, и т.п.
А чем сложнее установка RHELL/Ubuntu/Debian и т.п.?
Вопрос тот же. RHELL/Ubuntu/Debian делают по сути тоже самое, стоит упомянуть, что речь идёт о KDE (на всякий случай)
Вопрос тот же. DE (Desktop Environment) для Linux уже много лет разрабатываются в подобном направлении, в частности KDE очень проста в использовании и там можно обойтись без терминала для обычного пользователя
Как насчёт вспомнить 2006 год, когда Miscrosoft хотела подать в суд за сильное соответствие UI Linux к Windows 95
Ну конечно же нет, I use Arch, btw :)
Интересная статья, однако стоило бы указать, к какой именно архитектуре относятся данные соглашения.
Например, везде в коде однозначно используется x86, однако в vectorcall затрагиваются регистры x64, хотя, безусловно, данное соглашение существует и для x86, и для x64 (https://docs.microsoft.com/ru-ru/cpp/cpp/vectorcall?view=msvc-170):
Хотелось бы увидеть чуть более подробное описание vectorcall.
Также стоило бы упомянуть, что вы используете Win32 ABI, т.к. в System V ABI есть отличия для наименований, количестве передаваемых в регистрах аргументов для fastcall и т.д.
Спасибо, поправил
Да, соглашусь насчёт того, что стоило бы показать исполнение прогаммы из gdb или другого дебагера, подумаю над дополнением статьи
А ссылка на исходный код указана в заключении под номером 9, на всякий случай продублирую здесь
Исходный код на GitHub с небольшими изменениями - https://github.com/d0wnFvll/x86-asm-argv/blob/main/args.S
Спасибо за замечание, поправил
Да, вы абсолютно правы, в статье нет упоминания про expand up стек, про то, как ведёт себя стек при каких-либо исключениях процессора и много чего ещё, к сожалению
Изначально казалось, что статья будет необоснованно большой, если начать писать про все команды, влияющие на поведение стека, такие как pusha/popa, pushad/popad, pushf/popf и многие другие, а также при расписывании всех EFLAGS, которые могут быть затронуты при операциях на стеке, хотя про совместимость инструкций push sp я однозначно дополню статью, остальные замечания, лучше, думаю, будет описать во второй части статьи, т.к., действительно, я о многом не рассказал, что касается стека i386, в данной статье.
Спасибо за замечание!