Page 3 of 3

Re: Обращение к разработчикам KolibriOS

Posted: Mon Oct 08, 2007 9:50 pm
by alman
diamond wrote:
diamond wrote:Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем) (конечно, если оно в итоге заметно меньше, чем CRT на Си). Переработку menuetlibc при условии наличия большей части Си-библиотеки я могу обеспечить сам. Как было справедливо замечено, шансы на долгую память у кода и разработчика повышаются при использовании в двух ОСях.
Похоже, меня проигнорировали...
Извини. Конечно, я видел этот пост. И собирался на него ответить, когда буду для этого готов. Я выложу CRT0 на fasm. Но CRT далеко не LIBC, а лишь малейшая её часть.
diamond wrote: Это было завуалированное предложение написать эмулятор (или что-нибудь подобное) Колибри под Xameleon к разработчикам с этого форума?
И это тоже. И не только...
diamond wrote: На данный момент нет даже эмулятора под Linux, а Linux - очень известная система, у которой в том числе и на этом форуме есть сторонники! (Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)
А он нужен, эмулятор под Linux? :) Для графики у Linux есть XWindow и SDL. Также под Linux имеется десяток различных эмуляторов, в том числи и Wine.

В общем, на данном этапе я предлагаю ознакомить всех разработчиков KoibriOS с идеологией микроядра L4. Обрати внимание, я не говорю о Хамелеоне, а говорю о L4. Потратив несколько дней на изучение KolibriOS и чтение форума, я обнаружил, что у Kolibri имеются некоторые проблемы, решение которых предполагает перепроектирование системы. Навскидку - поддержка многопроцессорности, остановка подсистемы ввода/выводы во время операций с большими файлами.
Т.е. со временем всё равно придётся перепроектировать. Надеюсь, это никто не оспаривает?

Так вот, знакомство с концепцией L4 позволит разработчикам Kolibri узнать один из способов (далеко не самый худший) решения этих проблем.

В поддержку своих слов процитирую кусок кода из Kolibri (kernel/core/sync.inc):
macro WaitSimpleMutex name
{
local start_wait,ok
start_wait=$
cli
cmp [name],dword 0
jz ok
sti
call change_task
jmp start_wait
ok=$
push eax
mov eax,dword [TASK_BASE+second_base_address]
mov eax,[eax+TASKDATA.pid]
mov [name],eax
pop eax
sti
}
Этот код будет идеально работать на однопроцессорной машине, но даже на Pentium4 с технологией HT он с большой вероятностью приведёт к ошибке, которую при этом будет трудно отловить.

Почему? Потому что cli запрещает прерывания, соответственно, переключения задач не произойдёт. Но при этом второй процессор продолжает работать и может обратиться к этому же самому ресурсу.

Re: Обращение к разработчикам KolibriOS

Posted: Mon Oct 08, 2007 9:59 pm
by alman
k@sTIg@r wrote:
diamond wrote:(Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)
Вот тут подробней....что тогда для этого нужно?
Для портирования Kolibri под Linux достаточно отказаться от ядра Kolibri, оставив только графическую подсистему и все приложения.
Например, можно скачать оригинальный fasm и посмотреть как он портирован под Linux.
Конечно, вам решать, что и куда портировать и что переделывать, однако, я бы предостерёг от поспешных решений.

Re: Обращение к разработчикам KolibriOS

Posted: Mon Oct 08, 2007 10:13 pm
by bw
Никому не нужно портировать KOS под Linux, речь может идти только об эмуляторе, для более комфортной (в родной и развитой среде) разработки KOS программ. Большую часть работы и тестов я провожу в эмуляторе под виндой, за что еще раз спасибо diamond'у.

..bw

Re: Обращение к разработчикам KolibriOS

Posted: Tue Oct 09, 2007 11:07 am
by diamond
alman wrote:Извини. Конечно, я видел этот пост. И собирался на него ответить, когда буду для этого готов. Я выложу CRT0 на fasm. Но CRT далеко не LIBC, а лишь малейшая её часть.
Это хорошо. То, что CRT - только часть LIBC, я понимаю, но согласно идеологии Колибри даже выигрыш нескольких килобайт за счёт замены CRT на ассемблере - вещь полезная.
alman wrote:Этот код будет идеально работать на однопроцессорной машине, но даже на Pentium4 с технологией HT он с большой вероятностью приведёт к ошибке, которую при этом будет трудно отловить.

Почему? Потому что cli запрещает прерывания, соответственно, переключения задач не произойдёт. Но при этом второй процессор продолжает работать и может обратиться к этому же самому ресурсу.
Даже на процессорах с HT в текущей реализации это работает. Правда, только потому, что используется только одно ядро, а остальные не делают ничего. Ну а насчёт того, что вышеуказанное составит одну из проблем при написании поддержки многопроцессорности - все, кому надо, это и так уже знают, Serge об этом как-то говорил.
alman wrote:что у Kolibri имеются некоторые проблемы, решение которых предполагает перепроектирование системы.
Да нифига. Для решения этих проблем не нужно перепроектировать всю систему, не нужно даже вообще ничего перепроектировать. Нужно всего лишь разработать развитую систему блокировок и защит критических участков кода вместо используемых "cli" / "sti" (в простейшем случае), "pushf/cli" / "popf" и "mov [hd1_status], <занято приложением таким-то>" / "and [hd1_status], 0". Это довольно сложно, но перепроектирования не требует.
k@sTIg@r wrote:Вот тут подробней....что тогда для этого нужно?
Насколько я помню там столкнулись с какой-то проблемой
Оффтопить нехорошо. А личные сообщения и почту никто не отменял. Ладно, ща создам отдельную тему.

Re: Обращение к разработчикам KolibriOS

Posted: Tue Oct 09, 2007 2:30 pm
by alman
diamond wrote:
alman wrote:что у Kolibri имеются некоторые проблемы, решение которых предполагает перепроектирование системы.
Да нифига. Для решения этих проблем не нужно перепроектировать всю систему, не нужно даже вообще ничего перепроектировать. Нужно всего лишь разработать развитую систему блокировок и защит критических участков кода вместо используемых "cli" / "sti" (в простейшем случае), "pushf/cli" / "popf" и "mov [hd1_status], <занято приложением таким-то>" / "and [hd1_status], 0". Это довольно сложно, но перепроектирования не требует.
Немного не так. Вместо CLI/STI необходимо использовать атомарную операцию LOCK CMPXCHG. Только одна проблема, эта инструкция появилась только начиная с i486.

А вот как быть с блокировкой файловой системы, когда она занята одним процессом, например, копирующим большой файл?

Re: Обращение к разработчикам KolibriOS

Posted: Tue Oct 09, 2007 5:08 pm
by Mario79
alman wrote:А вот как быть с блокировкой файловой системы, когда она занята одним процессом, например, копирующим большой файл?
Устанавливаем лимит, на количество считываемой информации при превышении останавливаем доступ для данного потока, сохраняем данные в определенной области, предаем возможность доступа другому потоку, и так далее. Если активность вернулась к потоку, который был прерван, то для него производим восстановление данных и по истечении лимита снова прерываем. Данная процедура будет реализована отдельно от переключения задач.

Re: Обращение к разработчикам KolibriOS

Posted: Tue Oct 09, 2007 5:48 pm
by Serge
WaitSimpleMutex в ядре не используется. Есть функция wait_mutex расчитанная и на SMP. Но вот насчет того что для SMP не надо ничего перепроектировать я совсем не уверен.

Re: Обращение к разработчикам KolibriOS

Posted: Sat Oct 13, 2007 9:29 pm
by alman
Здравствуйте, коллеги!

Эксклюзивно для проекта KolibriOS

fasm далеко не идеально генерит исполняемый код Elf, но объектные файлы в формате Elf генерит очень хорошо.
Ниже пример некскольких библиотечных функций на fasm, которые наверняка окажутся интересными тем, кто интересуется L4.

Code: Select all

;
;    Xameleon fasm demo (c) alman @ Xameleon project
;    This code donated exclusively for KolibriOS project
;

    format	ELF

    section '.text' executable writable
    public start as '_start'
    public rootserver_id
    extrn main    

struc L4_KIP
{
    .Prefix		dd	??	; 0x00
    .API_Version	dd	??	; 0x04
    .API_Flags		dd	??	; 0x08
    .KernDescPtr	dd	??	; 0x0c
    
			dq	??	; 0x10 reserved
			dq	??	; 0x18 reserved
			dq	??	; 0x20 reserved
			dq	??	; 0x28 reserved
			dq	??	; 0x30 reserved
			dq	??	; 0x38 reserved
			dq	??	; 0x40 reserved
			dq	??	; 0x48 reserved
			
			dd	??	; 0x50 reserved
    .MemoryInfo		dd	??	; 0x54 reserved
			dq	??	; 0x58 reserved

			dq	??	; 0x60 reserved
			dq	??	; 0x68 reserved
			dq	??	; 0x70 reserved
			dq	??	; 0x78 reserved
			dq	??	; 0x80 reserved
			dq	??	; 0x88 reserved
			dq	??	; 0x90 reserved
			dq	??	; 0x98 reserved

			dq	??	; 0xa0 reserved
    .UtcbInfo		dd	??	; 0xa8
    .KipAreaInfo	dd	??	; 0xac
    
			dq	??	; 0xb0 reserved
    .BootInfo		dd	??	; 0xb8
    .ProcDescPtr	dd	??	; 0xbc

    .ClockInfo		dd	??	; 0xc0
    .ThreadInfo		dd	??	; 0xc4
    .PageInfo		dd	??	; 0xc8
    .ProcessorInfo	dd	??	; 0xcc
    
; -----	L4 system calls ----
    .SpaceControl	dd	??	; 0xd0
    .ThreadControl	dd	??	; 0xd4
    .ProcessControl	dd	??	; 0xd8
    .MemoryControl	dd	??	; 0xdc
    
    .IPC		dd	??	; 0xe0
    .LIPC		dd	??	; 0xe4
    .Unmap		dd	??	; 0xe8
    .ExchangeRegisters	dd	??	; 0xec
    
    .SystemClock	dd	??	; 0xf0
    .ThreadSwitch	dd	??	; 0xf4
    .Schedule		dd	??	; 0xf8
			dd	??	; 0xfc - Reserved syscall
}

macro L4_KDB_Enter msg
{
    local jump
    int3
    jmp		jump
    
    mov		eax, msg 
jump: 
}

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
start:                          ; start of execution

;    mov  [env_size], esp
;    add  [env_size], 16 
	
    push	ebp
    mov		ebp, esp

    lock nop			; Get KIP pointer into EAX
    mov	 [kip], eax

    L4_KDB_Enter hello_string

    mov   ax, [ eax + 198 ]
    shr	ax, 4
    movzx	eax, ax
    add		eax, 2
    sal		eax, 14
    or		eax, 1
    mov		[rootserver_id], eax
    
    call 	main
    

    L4_KDB_Enter goodbye_string

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This is a main L4 userspace system call
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    public L4_Ipc as 'L4_Ipc'
L4_Ipc:
;
; 0030  L4_ThreadId_t *	from
; 002c  L4_Word_t 	Timeouts,
; 0028  L4_ThreadId_t 	FromSpecifier,
; 0024	L4_ThreadId_t 	to,
; 0020	Function return address	
; 001c	eax		Temp = esp
; 0018	ecx
; 0014	edx
; 0010	temp
; 000c	ebp
; 0008	esi
; 0004	edi	<- ebp points here

    pushad
    mov	  ebp, esp
    ; Set destination thread
    mov	  eax, [ ebp + 0x24 ]
    ; Set from specifier
    mov	  edx, [ ebp + 0x28 ]
    ; Set timeouts
    mov	  ecx, [ ebp + 0x2c ]
    ; Set UTCB
    mov	  edi, [ gs:0 ]
    ; Set message register 0
    mov   esi, [ edi ]
    ; Do L4 IPC syscall
    mov	  ebp, [kip]
    mov	  ebp, [ebp + 0xe0]
    add	  ebp, [kip]
    push  leave_ipc
    push  ebp
    ret
    
leave_ipc:
    mov   ebp, esp
    mov	  [ ebp + 0x1c ], esi
    mov	  ebx, [ ebp + 0x30 ]
    mov	  [ ebx ], eax
    popad
    ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; UTCB area is an area that conveys message registers
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
public GetUTCB
GetUTCB:
    mov eax, [gs:0]
    ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; CONSTANT DATA AREA
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
section '.rodata' writable
hello_string:	db   'fasm is ready for Xameleon', 0x0d, 0x0a, 0
goodbye_string:	db   'See ya soon!', 0x0d, 0x0a, 0
	

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Static variables
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
section '.data' writeable
kip		dd		0
env_size	dd		0
rootserver_id	dd		0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Start of BSS area
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
section '.bss' writeable align 4
_BSS_start	dd		?

I_END:
С уважением, Алексей Мандрыкин

Re: Обращение к разработчикам KolibriOS

Posted: Sat Oct 13, 2007 9:39 pm
by alman
Простейший пример использования L4_IPC.
fasm crt0.asm
gcc -c demo.c
ld -static -Ttext=0x4000000 -Tinit.lds crt0.o demo.o -o demo

Code: Select all

#define L4_ThreadId_t	unsigned int
#define L4_Word_t	unsigned int

//////////////////////////////////////////////////////////////////////////////
// Function prototypes
//////////////////////////////////////////////////////////////////////////////
extern L4_Word_t L4_Ipc (	
    L4_ThreadId_t 		to,
    L4_ThreadId_t 		FromSpecifier,
    L4_Word_t 			Timeouts,
    L4_ThreadId_t 	*	from);

extern L4_Word_t * GetUTCB();

//////////////////////////////////////////////////////////////////////////////
// External variables definition
//////////////////////////////////////////////////////////////////////////////
extern 	L4_ThreadId_t	rootserver_id;

//////////////////////////////////////////////////////////////////////////////
// This function destroys calling process by sending command to Supervisor
//////////////////////////////////////////////////////////////////////////////
int sys_exit(int status)
{
    L4_ThreadId_t fake_from;
    L4_Word_t * MR = GetUTCB();
    MR[0] = 0x00040001;	// Message register 0 conveys information about message
    MR[1] = status;	// Process exit status
    return L4_Ipc( rootserver_id, rootserver_id, 3, &fake_from );
}

int main(void)
{
    return sys_exit(13);
}
В этом примере всё сознательно упрощено для простоты понимания.

Re: Обращение к разработчикам KolibriOS

Posted: Sun Oct 14, 2007 12:49 am
by diamond
Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем)
Извините, похоже, я погорячился и чего-то недопонял. Вышеприведённый crt0.asm для программ Колибри, разумеется, бесполезен.

Re: Обращение к разработчикам KolibriOS

Posted: Sun Oct 14, 2007 11:27 am
by bw
> ld -static -Ttext=0x4000000 -Tinit.lds crt0.o demo.o -o demo
А под виндой можно собрать?
У меня ld ругается: PE operations on non PE file.

..bw

Re: Обращение к разработчикам KolibriOS

Posted: Sun Oct 14, 2007 7:23 pm
by alman
bw wrote:> ld -static -Ttext=0x4000000 -Tinit.lds crt0.o demo.o -o demo
А под виндой можно собрать?
У меня ld ругается: PE operations on non PE file.
А как Вы собирали? По идее, чтобы собралось, нужны объектники Elf и линкер, поддерживающий Elf.
Если не ошибаюсь, FASM смотрит на директиву format в заголовке файла, поэтому crt0.o - Elf.
Если сишный код собриали gcc, то, если не ошибаюсь, demo.o тоже будет в формате Elf.
Остаётся думать на линкер.

Тут фишка в том, что собранный пример сможет запуститься под чистым микроядром L4, а собранный в исполняемый формат PE только под Хамелеоном.

Кстати, Вы мне хорошую идею подкинули. Поскольку FASM умеет сам собирать EXE файлы (WinPE формат), то попробую этот путь.

Re: Обращение к разработчикам KolibriOS

Posted: Mon Oct 15, 2007 3:43 am
by bw
Если судить по первым символам в объектах, то crt0.o - ELF, demo.o - нет, первой идет L (4C010300 00000000).
init.lds взял из архива на l4os.ru (http://l4os.ru/20070825/xameleon_demo.src.tar.gz). gcc и ld из mingw. Ключи для сборки не менял, все как в примере.

>а собранный в исполняемый формат PE только под Хамелеоном
Т.е. можно .exe исполнять? А подключение динамических библиотек происходит :-) ?

p.s. Лучше на ты, пожалуй.

..bw

Re: Обращение к разработчикам KolibriOS

Posted: Wed Oct 17, 2007 9:31 am
by alman
bw wrote:Если судить по первым символам в объектах, то crt0.o - ELF, demo.o - нет, первой идет L (4C010300 00000000).
init.lds взял из архива на l4os.ru (http://l4os.ru/20070825/xameleon_demo.src.tar.gz). gcc и ld из mingw. Ключи для сборки не менял, все как в примере.
Оказывается, MinGW генерит PE объектники.Интересно.
bw wrote:>а собранный в исполняемый формат PE только под Хамелеоном
Т.е. можно .exe исполнять? А подключение динамических библиотек происходит :-) ?
Да, можно исполнять exe. Только исполняемый файл должен быть слинкован с хамелеоновсой libc.
поддержки DLL пока нет. Недели за две, за месяц, можно было бы реализовать при надобности.
В принципе, исполнить можно всё, что имеет следующую структуру:

Code: Select all

.text
.rodata
.data
.bss
.text и .rodata склеиваются в один сегмент с атрибутом "только для чтения"
.data сегмент содержит статические данные и загружается из файла.
.bss - динамически растущий сегмент, используется malloc() и free()
И Elf и WinPE в сущности используют одинаковые принципы, т.ч. проблем нет.

Когда Хамелеон запускает исполняемый файл Kolibri, то и .text и .data указывают на один диапазон, указанный в заголовке, а .bss устанаваливается как интервал от значения end до до значения memsize. Вроде как это позовлило запустится исполняемому файлу Kolibri.
bw wrote:p.s. Лучше на ты, пожалуй.
С удовольствием.