про 255 знаю, но ИМХО больше 255 - жопа, нужно всётки на библиотеки налягать.
Mario79
не понял твой вопрос. Посмотри сорци (~40kb), сейчас там просто 2 таблици, одна для адоптированных, вторая для старых - как я сказал для "мягкого" перехода.
Fast System Call
Ghost
Извиняюсь ступил. Пока не посмотрел исходники, думал, что в ядре все-таки будет одна таблица, которая подменяется при компиляции ядра.
Извиняюсь ступил. Пока не посмотрел исходники, думал, что в ядре все-таки будет одна таблица, которая подменяется при компиляции ядра.
Адоптировал функции : -1, 2, 7, 10, 11, 12, 13, 14, 16, 17, 19, 23, 29, 35 и 40.
Функции 36 и 54 вырезал совсем ибо первая ещё с Менуэта "недописана", а вторая вообще непонятно зачем (вторая пустышка). Переписал undefined_syscall - таблица не адоптированных вызовов уменьшилась с 1024 до 292 байт. Немного почистил код. Наткнулся на 35 (GetPixel) - подумал, может её переделать? Сейчас приложение сначала узнаёт ширину экрана, перемножает её на x.coord потом ядро делает обратную работу. Используют её вроде только экранная лупа и демка прозрачности.
И собственно интересует вопрос: нужна ли эта работа? Если да, то я сливаю всё на svn и все вперёд, на адоптацию...
P.S. Сорци там же.
Функции 36 и 54 вырезал совсем ибо первая ещё с Менуэта "недописана", а вторая вообще непонятно зачем (вторая пустышка). Переписал undefined_syscall - таблица не адоптированных вызовов уменьшилась с 1024 до 292 байт. Немного почистил код. Наткнулся на 35 (GetPixel) - подумал, может её переделать? Сейчас приложение сначала узнаёт ширину экрана, перемножает её на x.coord потом ядро делает обратную работу. Используют её вроде только экранная лупа и демка прозрачности.
И собственно интересует вопрос: нужна ли эта работа? Если да, то я сливаю всё на svn и все вперёд, на адоптацию...
P.S. Сорци там же.
Ghost
Все что увеличивает эффективность системы, является положительной вещью. Удачи.
Все что увеличивает эффективность системы, является положительной вещью. Удачи.
Я думаю нужно залить на svn.
имхо, в заточенных под AMD системах имеет смысл вызывать стандартные сисфункции через int40,
а специализированный сервис и расширенный ioctl драйверов (который на пнях всё равно не пойдет) - через SYSCALL/SYSRET;
с передачей параметров в пользовательском стеке (или в регистрах,- кроме ECX).
На Sempron-140 вызов функции-пустышки через SYSCALL занимает 94 такта (в 2.4 раза быстрее, чем через int40):
а специализированный сервис и расширенный ioctl драйверов (который на пнях всё равно не пойдет) - через SYSCALL/SYSRET;
с передачей параметров в пользовательском стеке (или в регистрах,- кроме ECX).
На Sempron-140 вызов функции-пустышки через SYSCALL занимает 94 такта (в 2.4 раза быстрее, чем через int40):
- Attachments
-
-
SYSCALL.jpg (38.1 KiB)Viewed 10248 times
-
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Кстати,
Serge, Ghost,
А обязательно ли при вызове сисфункции переключаться в стек нулевого уровня, да еще и с выцарапыванием параметра из третьего кольца:Браво, такие выверты даже в Колибри - редкость!
Только зачем?
Переключения задачи ведь все равно не происходит, а возврат в ring3 воможен только через sysret.
Так может, лучше юзерским стеком воспользоваться: быстро, просто, и методически-корректно?
Serge, Ghost,
А обязательно ли при вызове сисфункции переключаться в стек нулевого уровня, да еще и с выцарапыванием параметра из третьего кольца:
Code: Select all
;(взято из core/syscall.inc)
syscall_entry:
; cli syscall clear IF
xchg esp, [ss:tss._esp0]
push ecx
lea ecx, [esp+4]
xchg ecx, [ss:tss._esp0]
sti
push ecx
mov ecx, [ecx]
;------------------
pushad
cld
movzx eax, al
call dword [servetable2 + eax * 4]
popad
;------------------
mov ecx, [ss:esp+4]
pop esp
sysret
Только зачем?
Переключения задачи ведь все равно не происходит, а возврат в ring3 воможен только через sysret.
Так может, лучше юзерским стеком воспользоваться: быстро, просто, и методически-корректно?
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
art_zh
Выносим ядро ?
Выносим ядро ?
Code: Select all
xor esp, esp
sysenetr
1001-й (не самый разрушительный) способ преднамеренного членовредительства...Serge wrote:art_zh
Выносим ядро ?Code: Select all
xor esp, esp sysenetr
Согласен, для десктопа не годится.
P.S. Хотя, в принципе, эта дырка затыкается в 2 хода.
Всё равно ring 3 не прокатит. В режиме ядра может происходить переключение контекста со всеми вытекающими.
Ясно.
Нет никакого смысла резать живое ядро ради 30-40 тактов, тем более что на пнях всё равно не будет никакого выигрыша.
Спасибо Serge.
Но для AMDшного API я всё-таки его (syscall+SP3) попробую.
Нет никакого смысла резать живое ядро ради 30-40 тактов, тем более что на пнях всё равно не будет никакого выигрыша.
Спасибо Serge.
Но для AMDшного API я всё-таки его (syscall+SP3) попробую.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Внимание!
1) Начиная с #1937 отменена официальная поддержка инструкций syscall и sysenter для вызова API-функций ядра.
2) В ближайшее время эти инструкции будут удалены из всех программ репозитория (кроме /programs/develop/fast_call_test ) и заменены на int40h.
3) Старые обработчики syscall- и sysenter-вызовов оставлены в ядре до 1 июля 2011г.
4) После 01/07/11 нормальная работа старого кода с новыми версиями ядра не гарантируется.
5) Просьба к разработчикам: проверьте свой код и внесите соответствующие изменения в свои FTP-ресурсы.
Attention!
1) Since #1937 the kernel access via syscall and sysenter instructions is discontinued.
2) All the repository sources will be carefully inspected to replace these instructions with the standard int40h.
3) The current entry points of syscall and sysenter are kept in the kernel till the 1st of July, 2011
4) After 01/07/2011 the old code might not be guaranteed to work with the newer kernels.
5) Dear developers, please check your code and upload your FTPs with the fresher sources.
1) Начиная с #1937 отменена официальная поддержка инструкций syscall и sysenter для вызова API-функций ядра.
2) В ближайшее время эти инструкции будут удалены из всех программ репозитория (кроме /programs/develop/fast_call_test ) и заменены на int40h.
3) Старые обработчики syscall- и sysenter-вызовов оставлены в ядре до 1 июля 2011г.
4) После 01/07/11 нормальная работа старого кода с новыми версиями ядра не гарантируется.
5) Просьба к разработчикам: проверьте свой код и внесите соответствующие изменения в свои FTP-ресурсы.
Attention!
1) Since #1937 the kernel access via syscall and sysenter instructions is discontinued.
2) All the repository sources will be carefully inspected to replace these instructions with the standard int40h.
3) The current entry points of syscall and sysenter are kept in the kernel till the 1st of July, 2011
4) After 01/07/2011 the old code might not be guaranteed to work with the newer kernels.
5) Dear developers, please check your code and upload your FTPs with the fresher sources.
Может не стоит так торопиться ? Продлить переходный период и выпустить в конце официальный дистрибутив как новую точку отсчёта.
И мнение остальных неплохо узнать.
И мнение остальных неплохо узнать.
Serge
Пока народ перед фактом не поставишь - никто и не почешется.
По-моему, 6 недель - вполне приличный срок. Тем более что я не собираюсь сразу же после этого ядро кромсать назло всем.
Всего лишь гарантирую, что до июля все будет как и раньше.
И внимательно слушаю чужие мнения.
Пока народ перед фактом не поставишь - никто и не почешется.
По-моему, 6 недель - вполне приличный срок. Тем более что я не собираюсь сразу же после этого ядро кромсать назло всем.
Всего лишь гарантирую, что до июля все будет как и раньше.
И внимательно слушаю чужие мнения.
Если система станет ещё более быстрой и компактной, то я только за, удаление не нужного.
Who is online
Users browsing this forum: No registered users and 1 guest