Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Nov 19, 2019 12:31 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 124 posts ]  Go to page Previous 1 2 3 4 59 Next
Author Message
PostPosted: Thu Oct 25, 2007 2:07 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
k@sTIg@r wrote:
Посмотри на некоторые приложения колибри такие как сетап, настройка сети и т.д. Уже есть libGUI но никто не спешит переводить их под эту библиотеку. Зато на форуме присутствует много людей которые с удовольствием это сделали будь визуальная среда разработки, т.к. асма боятся как огня.

Я сильно сомневаюсь, что это действительно полезно. Визуальные среды, как я уже говорил, любят пихать кучу своего кода, который далеко не всегда необходим. Вот именно то, что с появлением подобных сред куча народу бросится на написание новых приложений и "улучшение" существующих, которое запросто может привести к разбуханию всего чего можно и нельзя (как по размеру, так и по количеству действий).

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
PostPosted: Thu Oct 25, 2007 2:36 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond
TLS в Колибри пока нет, а bound import можно сделать, хотя сейчас в этом нет необходимости. Кстати он использует "ненужное" поле TimeDateStamp.

Quote:
Импорт с привязкой (Bound import) – это вид импорта, при котором предполагается, что для определенной версии модуля, содержащего импортируемый символ, адрес символа уже известен к моменту компиляции.
Это относится, главным образом, к системным библиотекам, которые загружаются в память всегда с одного и того же адреса для данной версии библиотеки. В таком случае в таблицу импорта модуля, импортирующего такой символ, можно заранее, еще до загрузки модуля, записать предполагаемый адрес символа.
При этом для обеспечения контроля версии модуля, к которому привязан данный, при осуществлении привязки создается дополнительная таблица информации о привязанных модулях, на которую ссылается поле ForwarderChain. В поле TimeDateStamp помещается отметка времени модуля, содержащего символ (это значение поля TimeDateStamp из PE-заголовка этого модуля).
Существует так называемый “новый стиль” привязки; в этом случае TimeDateStamp= -1, а таблица информации о привязках доступна через элемент IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT каталога PEHeaders.OptionalHeader.DataDirectory.


Top
   
PostPosted: Thu Oct 25, 2007 2:50 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge wrote:
Кстати он использует "ненужное" поле TimeDateStamp.

...у динамических библиотек...


Top
   
PostPosted: Fri Oct 26, 2007 9:17 am 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
...сделайте возможность подключения PE DLL в пользовательских приложениях, это ведь не очень сложно.
Если DLL должны не просто динамически присоединяться, но еще и совместно использоваться после загрузки, то это довольно сложно.

Хочу высказать свое мнение. PE-формат - это свалка информации и если вы подсядите на него, то вас затянет по полной. Не понятно, почему за обсуждением PE никто не обратил внимание на упомянутый и также весьма распространенный ELF.EXE. В этом случае ELF.OBJ можно использовать в качестве RTL.


Top
   
PostPosted: Fri Oct 26, 2007 12:10 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Phantom-84

Я об этом уже писал.
Во-первых не все компиляторы поддерживают elf. В Win мне удалось скомпилировать elf.exe Ваткомом но в очень усечённом и несколько странноватом виде. Сделать elf c динамической линковкой или расшареный видимо можно только в *никсах.
Во-вторых позиционно-независимый код в elf занимает больше места и работает медленнее потому что процессоры отслеживают пары вызовов call/ret, а конструкции
call $+5
pop ebx
сбивают внутренний стек возвратов. Наконец в ia-32 регистров и так кот наплакал а здесь теряется ещё один. Мусора при желании в elf можно найти не меньше чем в PE и это скорее зависит от компоновщика. ld даёт компактные PE файлы если его правильно настроить. Количество секций в elf.so приближается к двадцати, больше чем в pe. Единственное преимущество elf.so перед pe.dll то что загруженные секции кода в одном процессе можно отобразить на любой адрес в другом процессе, но это и не так важно для системных библиотек. Если они загружаются в общую память то конфликта адресов не будет, а небольшие частные библиотеки можно и не расшаривать.
Наконец загрузка elf.so сложнее чем pe.dll, это играет не последнюю роль.


Top
   
PostPosted: Fri Oct 26, 2007 4:42 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Понятно, что компиляторы под Windows в первую очередь ориентированы на PE. Но кто мешает компилировать под никсами? Использование регистра ebx - это скорее заморочка компилятора. В самом формате такого нет. Там главное, чтобы адреса не были короткими, т.е. если к примеру я сохраняю в стеке адрес, то мне в исходном коде нужно использовать не короткую инструкцию push const (2 байта), а длинную (5 байт). К тому же я говорил не о формате ELF.DSO, а о формате ELF.OBJ, т.е. чистом объектнике.


Top
   
PostPosted: Fri Oct 26, 2007 6:57 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Phantom-84

Для большинства основная система пока что Win. Это приходится учитывать. Заморочка с ebx это неизбежная оптимизация иначе на каждое обращение к данным придется добавлять пару call/pop а это два лишних обращения к памяти и разболтанный стек. В целом это скорее проблема не компиляторов а генерации pic для процессоров ia32. В long mode данные адресуются относительно rip так что там изначально позиционно-независимый код, а значит пропадает последнее преимущество elf.so перед pe.dll
Обычно компиляция идёт по принципу один файл - один объектник. А в больших проектах много файлов и в один obj их собрать проблематично. Наконец в первую очередь выбирался формат для ДЛЛ с учетом автоматической линковки при загрузке приложения, а здесь pe имеет преимущества перед elf.so в простоте. На мой взгляд гибкая структура elf привела к тому что его слишком перегрузили разными секциями и парсить их стало сложно. Что касается преимущества позиционно-независимого кода elf.so то в Колибри его нет.


Top
   
PostPosted: Mon Jul 28, 2008 5:16 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Возобновляю тему...

svn://kolibrios.org/kernel/branches/kolibri_pe
Планируется постепенная и очень серьёзная переделка ядра

- единый ABI для Asm и C кода
- новый менеджер страничной памяти
- улучшенный менеджер виртуальной памяти
- разделяемые память и dll
- перенос части ядра в user-mode
- новый загрузчик приложений с поддержкой PE
- планировщик
- новая организация процессов и потоков
- гибридное микроядро
- SMP
- загрузка GRUB-ом
- перевод ядра в PE DLL
- раздельная компиляция fasm/mingw и сборка ядра ld
- Колибри 64


Top
   
PostPosted: Mon Jul 28, 2008 8:24 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5066
Звучит как логическое продолжение Колибри. Мне как юзеру и недалёкому программисту :) важна:
1. совместимость с уже написанными прогами
2. синхронизация с trunk

_________________
Через тернии к звездам


Top
   
PostPosted: Mon Jul 28, 2008 9:22 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
!!!
Офигеть... :shock: ИМХО одному человеку всё это не осилить. Кто над этим уже работает?


Top
   
PostPosted: Mon Jul 28, 2008 10:29 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Leency

Совместимость будет, но не 100%. Захват IRQ из приложений, COFF obj и тому подобные вещи останутся за бортом.

синхронизация с trunk возможна на первых этапах вплоть до внедрения планировщика, но дальше многое будет зависить от того что будет/должен представлять trunk.

Код ядра работающий в pl0 сильно уменьшится. В режиме ядра останется только управление памятью, синхронизация, планировщик/процессы/потоки/IPC, обработка прерываний.

Драйверы/cервисы останутся в общей памяти ядра но перейдут в pl_1 с iopl_0, так что всеми любимая синхронизация cli/sti накроется gpf.
Это не так "микроядерно" как сервисы в user-mode, но быстрее и избавляет от большинства проблем с доступом к данным из разных адресных пространств.

Значительная часть ядра в том числе загрузчик приложений и нынешний int 0x40 перейдёт в pl_3 в виде api.dll. При этом код ядра и api.dll будет собираться в одну DLL.

Первые пункты вплоть до планировщика можно реализовать относительно быстро. БОльшая часть этого кода уже готова. Остальное - перспективный план на будущее.


Last edited by Serge on Wed Jul 30, 2008 2:08 pm, edited 1 time in total.

Top
   
PostPosted: Tue Jul 29, 2008 7:29 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Serge
Отличные новости! Хочу поучаствовать в работе!
Недавно разобрался с APIC (IPI и таймер), думал внедрять по маленьку в ядро SMP, попутно встал вопрос с планировщиком. Модернезировать текущий для работ с несколькими процами, это так сказать работа "на от**ись", нужно уже приоритеты/балансировку вводить. IPC тоже требует разработки, без тех же спинлоков (мьютексы/барьеры/семофоры реализуются через спинлоки) на уровне ядра в SMP не обойтись...
Кроме того часть кода ядра просто стоит переписать более оптимально и с использованием соременных средств (mmx/sse/etc, смешно уже тянуть направленность на старые машины, и требывать небывалой производительности, это думаю все понимают) Да и просто часть кода ядра (в основном касаемый сис.функций), должен быть на свом месте - в либах...
В общем фронт работ большой, думаю нужно по этому поводу более детально пообщатся. Или в PM или на мыло или тут (как модератор, всех предупреждаю : за флейм буду карать, давайте по существу)

P.S. про Колибри 64, смотрел с месяц назад код Menuet64 (да простит меня Вилли), в общем ничего сложного в нем нет, ибо ядро как было IA32 так им и осталось (compatible long mode))), изменений минимум, проделать тоже самое с Колибри думаю не составит труда...


Top
   
PostPosted: Wed Jul 30, 2008 10:51 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Ghost

Отлично.

ИМХО общаться лучше здесь, пусть вся разработка будет открытой, а пустой треп надо удалять сразу. Отдельные узкоспециальные вопросы можно обсуждать в личке.

За месяц надеюсь закончить изменения в менеджерах памяти, тогда можно будет взяться за процессы и планировщик.

P.S. Отправил на мыло тест smp для trunk.


Top
   
PostPosted: Wed Jul 30, 2008 1:34 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
to All
Будет ли отделение blue screen кода от ядра? Будет ли поддержка обработки ini файлов при загрузке? Будет ли рам диск? Как он будет сделан? Он будет жестко прошит или будет формироваться при обработки ini файла?


Top
   
PostPosted: Wed Jul 30, 2008 2:02 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Судьба blue screen туманна. Ядро будет грузиться GRUB-ом а опции прописываться в ini и командной строке ядра. Рам диск сохранится. В каком виде - можно обсудить. GRUB способен загрузить и нынешний kolibri.img как модуль (даже с дискеты если он туда поместится в gzip виде), и отдельные программы чтобы загрузчик ядра сам собрал из них рам диск. Я думаю что помещать на рам диск весь дистибутив не надо. Только самые необходимые файлы.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 124 posts ]  Go to page Previous 1 2 3 4 59 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited