Board.KolibriOS.org

Official KolibriOS board
http://board.kolibrios.org/

Предложения по коррекции программного интерфейса ядра

http://board.kolibrios.org/viewtopic.php?t=2143

Page 1 of 2

Предложения по коррекции программного интерфейса ядра

Posted: Wed Sep 19, 2012 8:43 pm
by FireWall
В результате сравнения дистрибутивов возникли следующие замечания (повторю их из соседней ветки «0.7.7.0 и текущее состояние: (1) сравнение API ядра»):

(1) Функция 43 - ввод/вывод в порт. Скорее всего должна быть объявлена устаревшей! (Ибо функция для резервирования портов (SysFn 46) уже объявлена устаревшей, а без предварительного резервирования портов, функция 43 неработоспособна.) .

Функция 46 - зарезервировать/освободить группу портов ввода/вывода. Объявлена устаревшей!

(2) На мой взгляд, некоторые функции должны быть также объявлены устаревшими, а может быть удалены:

Функция 6 - прочитать файл с рамдиска.
Функция 7 - вывести изображение в окно.
Функция 64 - перераспределить память приложения.

(3) Также, на мой взгляд, следует ещё раз обратить внимание на обращение к видео фрейм-буферу через селектор gs. (Может быть лучше просто добавить функцию, отображающую его в адресное пространство приложения. + (1) более стандартный способ доступа, + (2) в будущем возможность контролировать, например, единственность такого доступа в каждый данный момент)

(4) Следует также обратить внимание на:

Функция 26 (Получение параметров системы.) требует серьёзного рассмотрения на предмет устаревших подфункций.
Функция 58 (- работа с файловой системой ) возможно требует некоторой переработки.

Возникла также дискуссия по поводу SysFn 58. Реакция на эту дискуссию, а также на чат в следующем сообщении.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Wed Sep 19, 2012 8:49 pm
by FireWall
В целях проверки необходимости той или иной системной функции собрал модифицированное ядро KolibriOS :)

(1) Изменил поведение неопределённых системных функций:

Файл kernel.asm :
Spoiler:

Code: Select all

; FireWall
paleholder:
        
        mov		esi, paleholder_data0
        call    sys_msg_board_str
        
        mov     eax, [CURRENT_TASK]
        call	sys_msg_board_byte
        
        mov		esi, paleholder_data1
        call    sys_msg_board_str
        
        mov		eax, [esp + 32]
        call	sys_msg_board_byte
        
        mov		esi, paleholder_data2
        call    sys_msg_board_str
        call    sys_end

        ret


paleholder_data0:
		db		'K: slot:[', 0
		
paleholder_data1:
		db		'] SysFn:[', 0

paleholder_data2:
        db      '] ERROR:paleholder!', 0x0d, 0x0a, 0
; END FireWall
Файл kernel.asm :

Code: Select all

; FireWall
align 4

undefined_syscall:		; Undefined system call
		;push    esi
		;push	eax
		
		mov		esi, paleholder_data0
        call    sys_msg_board_str
        
        mov     eax, [CURRENT_TASK]
        call	sys_msg_board_byte
        
        mov		esi, paleholder_data1
        call    sys_msg_board_str
        
        mov		eax, [esp + 32]
        call	sys_msg_board_byte
		
        mov		esi, wb_udf_sysc_date
        call    sys_msg_board_str
        call    sys_end
        
        ;pop		eax
        ;pop     esi
        mov     [esp + 32], dword -1
        ret

wb_udf_sysc_date:
        db      '] ERROR:Undefined syscall!',0x0d, 0x0a, 0
; END FireWall
Теперь применение неопределённых системных функций приводит к завершению потока с отладочным сообщением вроде: K: slot:[xx] SysFn:[xx] ERROR:Undefined syscall!


(2) Я попытался отключить SysFn 58 и отловить приложения, которые из за этого не будут работать. Скрупулёзно не проверял, но вроде все приложения из дистрибутива работают. Точно работают:
- Pig ;
- все трёхмерные демо;
- @panel , rtfreader, pong3, fasm, animage, Kpack.

P.S.

Для отключения SysFn 58 внёс изменения в core/syscall.inc
Spoiler:

Code: Select all

; FireWall
      dd undefined_syscall       ; 56-reserved
      ;dd cross_order             ; 58-Common file system interface
; END FireWa
ll
Файл kos_kernel_syfn_check.7z содержит исходники модифицированных файлов ядра (против trunk , снятого 18.09.2012), а также само модифицированное ядро Kolibri OS.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Wed Sep 19, 2012 8:54 pm
by FireWall
Добавлю ещё некоторые замечания:

(3) Если посмотреть на

Code: Select all

 align 4
  servetable:
      dd socket                  ; 53-Socket interface
      dd 0
      dd 0
      dd 0
      dd 0
      dd file_system             ; 58-Common file system interface
      dd 0
      dd 0
      dd 0
      dd 0                       ; 62-PCI functions
      dd sys_msg_board           ; 63-System message board
то можно заметить, что только в трёх системных функциях не раскручена «карусель регистров». Если удалить SysFn 58 , раскрутить SysFn 63 (что не выглядит слишком сложным), crossorder переместить вместе с
align 4

Code: Select all

socket:                                 ; Socket interface
        call    app_socket_handler

;     mov   [check_idle_semaphore],5    ; enable these for zero delay
;     call  change_task                 ; between sent packet

        mov     [esp+36], eax
        mov     [esp+24], ebx
        ret
в network/stack.inc , то «раскрутку карусели» можно считать практически законченной (особенно с учётом того, что пишется новый сетевой стек, а значит 53-Socket interface скоро станет устаревшей и тратить время на её модификацию большого смысла нет).

(4) Если посмотреть начальный код обработчика прерывания int 40h :

Code: Select all

i40:
        pushad
        cld
        movzx   eax, al
        call    dword [servetable2 + eax * 4]
        popad
        iretd
- нельзя не заметить, что для номера функции реально используется только al , а не весь eax. Учитывая тот факт, что более чем 200 системных функций для KolibriOS вряд ли потребуется, то это поведение надо бы задокументировать. Это можно сделать, например, заменив текст документации:
«Перед вызовом следует указать в eax номер системной функции. »
на
«Перед вызовом следует указать в al номер системной функции. »
а также:
«Функция -1 - завершить выполнение потока/процесса
Параметры:
eax = -1 - номер функции
»
на
«Функция 0xff - завершить выполнение потока/процесса
Параметры:
al = 0xff - номер функции
[Примечание: вполне допустимо поместить в eax -1 ,например, кодом:
xor eax, eax
dec eax ]
»

Подобное изменение документации позволит для новых системных функций использовать ah, а также более старшие биты (байты) для чего-то ещё. Например, подфункцию 15 SusFn 86 (это просто пример) сейчас приходится вызывать, например так:

Code: Select all

xor	eax, eax
mov	ebx, eax
mov	al, 86
mov	bl, 15
int	40h
Если для подфункций испоьзовать ah, то вызов можно сделать кодом:

Code: Select all

mov	ax, 15*256 + 86  ; теперь старшие байты обнулять не нужно!
int	40h

Re: Предложения по коррекции программного интерфейса ядра

Posted: Wed Sep 19, 2012 9:34 pm
by art_zh
FireWall wrote:... позволит для новых системных функций использовать ah, а также более старшие биты (байты) для чего-то ещё. ...
не будет этого, аминь.

Code: Select all

i40:
        pushad
        cld
        movzx   eax, al
        call    dword [servetable2 + eax * 4]
        popad
        iretd
FireWall wrote:...; теперь старшие байты обнулять не нужно!
да их и сейчас вообще-то не обязательно обнулять (в "возвращаемых" функциях API их всё равно затрёт)

Re: Предложения по коррекции программного интерфейса ядра

Posted: Thu Sep 20, 2012 11:48 am
by FireWall
Цитата: "да их и сейчас вообще-то не обязательно обнулять (в "возвращаемых" функциях API их всё равно затрёт)"

Так вот это и надо задокументировать :) Иначе программист обязан следовать документации - обнулять старшие байты.

НО - это обязывающее решение: тем самым число системных функции ограничивается числом <255.

Цитата: "не будет этого, аминь."

Я не хотел сказать, что в будущем надо бы переделать имеющиеся функции так, чтобы номер подфункции был в ah. Но
- есть "нерасширяемые" функции, в которых ebx используется для чего-то другого (если позволить для них номер подфункции помещать в ah, то появляется возможность их расширения);
- в будущем будут новые функции ...

(Надеюсь, что Вы не хотели цитатой из кода сказать, что старшие байты затираются. Их можно восстановить, хоть тем же тупым
mov eax, [esp + 32] ; это по старому
точнее
mov eax, [esp + 28]
Это так - на всякий случай :wink: )

Re: Предложения по коррекции программного интерфейса ядра

Posted: Thu Sep 20, 2012 12:09 pm
by Mario
1) Я думаю менять сложившуюся систему будет огромным геморроем.
2) Не надо торопиться удалять функции - не такая уж большая экономия получится.
3) Приложения требуют гораздо большего внимания - много чего надо исправлять, переделывать и дополнять.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Thu Sep 20, 2012 1:14 pm
by FireWall
Моя реплика , соответственно :
1) Не менять, а дополнить, но обязательно задокументировать то, что есть de facto.
2) Торопиться удалять не надо, но нужно (торопиться) объявить устаревшими.
3) Раз уж Kolibri OS имеет монолитную архитектуру, то новая версия Kolibri OS - это (прежде всего) новая версия ядра, а не приложений.

P.S.

Есть ещё одно хитрое решение:
удалить из документации, реально не удаляя :D

Re: Предложения по коррекции программного интерфейса ядра

Posted: Thu Sep 20, 2012 6:11 pm
by Mario
FireWall wrote: Есть ещё одно хитрое решение:
удалить из документации, реально не удаляя :D
Я против. Нам только не хватало искусственно созданных недокументированных возможностей.
Самый рациональный способ уже применялся - функция удаляется после переписывания всех приложений ее использующих.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Thu Sep 20, 2012 8:40 pm
by FireWall
Цитата: "Самый рациональный способ уже применялся - функция удаляется после переписывания всех приложений ее использующих."

На том и остановимся : ловим (пока безуспешно :) ) и исправляем для начала относительно SysFn 58 :(

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 7:06 am
by Mario
Если Quake кто-нибудь сподобится пересобрать (только не я! в силу известных причин), то вопрос с ней можно закрывать. А вот с 7-й функцией советую не торопиться - немало программ ее используют.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 2:41 pm
by FireWall
В начале нужно убедиться, что Quake не работает : где бы найти этот gfx.wad . Без него программа не работает, но для его поиска SysFn58 не используется (т.е. - я запускал эту программу, но без gfx.wad , так что поиграть не смог).

В контексте SysFn26 речь может идти только о некоторых подфункциях (признание их устаревшими). В целом она несомненно нужна.

SysFn7 действительно используется очень часто (в.т.ч. её использует Eolite). В контексте этой функции может быть только дискуссия по поводу её признания устаревшей.

Следующая, из выше названных функций по использованию : SysFn64. Вот её как раз использует и Pig, Quake, и трёхмерные демо (правда не все, но сам просмотрщик использует, что самое главное).

----------------- дополнение :

Цитата: "может быть только дискуссия"

На самом деле SysFn7 очень удобна для случая, когда надо отображать сгенерированные в памяти элементы изображения. Так что можно спорить по поводу того, признавать ли её устаревшей.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 3:23 pm
by XVilka
Рекомендую оформить это в виде багов - bugs.kolibrios.org

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 3:26 pm
by Serge
FireWall
SysFn64 аналог sbrk(). Без неё надо править malloc menuetlibc.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 4:58 pm
by Mario
Еще KFM завязан на 64 функцию.

Re: Предложения по коррекции программного интерфейса ядра

Posted: Fri Sep 21, 2012 8:49 pm
by FireWall
Цитата: "Рекомендую оформить это в виде багов - bugs.kolibrios.org"

На самом деле это не баг - функция даже не была объявлена устаревшей.

Цитата: "Без неё надо править malloc menuetlibc."

malloc menuetlibc (и другие библиотеки, если они используют устаревшие функции) - это первое, что надо править. Всё остальное - потом

P.S.

И в контексте SysFn64 , к 0.8.0 сможем только объявить устаревшей.
All times are UTC+03:00
Page 1 of 2

Powered by phpBB® Forum Software © phpBB Limited