kernel_joe: (Default)
Как то зашел я в гости на кафедру к своему преподавателю, и он мне говорит, знаеш, что Максим, Украине нужна защищенная операционная система собвственного производства, кафедра тебя ждет. Я уже давно такие слова не воспринимаю серйозно, они подходят разве что для того, что бы молодняк заганять в институт. Есть же OpenBSD, что еще вообще надо? Но, с другой стороны я подумал, что по настоящему инновационные идеи давно уже нерождались. Последнее, что меня поразило на моей памяти была Операционная Система Бытия (харошее название), а документация там называлась Книга Бытия. Пройдемся сначала по Джобсовским задротам.

Стива Джобюса выгнали нахуй из Аппл за то, что он дохуя выйобывался, он тогда и жену свою послал нахуй беременную с которой ЛСД жрал, вообщем кризис у него был. Он что бы восстановиться создал новую компанию, назвал ее NeXT. Купил пацанчиков одних которые ObjectiveC придумали и начал думать как обустроить штаты американские. Но надо понимать, что такие люди как Джобс или Тео де Раадт зря не выйобуются. Трудно работать с дибилами -- это все знают. Дибилы в Аппл так были его заебали, что он решил начать все с нуля. Для этого он взял Mach UNIX, который служил прототипом для Windows NT. И начал делать то как он считал нужным. В Аппл контрразведчики тоже пытались съобезьянничать и инвестировали в аналогичный исследовательский проект деньги (OSF/1, MkLinux).

Вот что родил Стиви в 1992 году. На ролике он даже показывает фотку своего признанного сына, чем якобы доказывает, что он теперь в адеквате и с ним можно вести бизнес. Вообщем унылый ролик про распределенный документооборот для офисных крыс который в будущем стал основой для Mac OS X.



В это время в Microsoft допиливала первую версию Windows NT. (No Video)

Практически в это же время основалась еще одна компания, которая решила выебать и Apple и NeXT и Microsoft. Если вы внимательно посмотрите на ролики 1998 года вы увидите, что система опередила свое время на десять лет минимум:





Если бы видели сколько запускается Windows NT в то время на такой машине, и как работает видео-проигрывание, не говоря уже про OpenGL и акселерацию (в то время были Voodoo карточки 3dfx) вы бы поняли все моментально. Можно было запустить форматирование флопа, открыть ролик с CD и запустить паралельно проигрывание 4 роликов с диска, система не дергалась ни на милисекундочку. Планировщик этой системы воистину был чудесен. Слова smooth and responsive родились и воплотились в жизнь именно тогда. Сейчас же просто довольствуйтесь антикварными роликами.


Жан-Луи Гассье, глава и создатель Be, Inc.

Эта система должна была стать новым лицом Apple Computer, но вследствии того, что Стив показал фотку своего малыша и типа исправился, заключили контракт с ним, так как он все же был создатель компании как ни как. Be, Inc. потом долго кидало, Майкрософт ее давила и задавила, откупившись в суде около 20 миллионами. Так Be и умерла.

Но пару пацанчиков не бросили дело, продолжают дело, используя те же лекала. И вот что у них сейчас получилось (проект неккомерческий, но с MIT лицензией):

На этом ролике Haiku OS запускается на Zotac Ion-A with Atom 330 dual core, и проигрывает 7 видеороликов MPEG-4 (704x396px) одновременно. Для сравнения на Linux это железо проигрывает только 3 таких ролика без падения произвлдительности.



На этом ролике запускается 26 приложений (практически все что входит в поставку) за 10 секунд. Это в виртуальное машине VMware! :)



На этом ролике KHTML браузер WebPositive проходит HTML5 тесты созданные для IE9. Попробуйте их запустить на своих фаерфоксах :)



Система немного запоздала в свете современных Мультитач приколов, и Композит энжайнов, но сердце у нее бойкое, симметрично-мультипроцессорное, синхронизационно-мультипоточное, распаралеленное и готовое к мультиядерным окружениям и реальному времени, так что берегитесь. Raw Power идет. Готовьте DSP процессоры пачками. Если и есть система достойная Cell Broadcast Engine, то это определенно Haiku.
kernel_joe: (Default)
Любая интелектуальная деятельность требует систематизации.
Литературный перевод тоже.
Поэтому соберу наставления скромного переводчика,
Которыми вы можете воспользоваться и\или без зазрения совести выбросить в мусорку.

Идеи которые я буду здесь рассказывать в виде непрерывного стиха белого
Не новы, не я их придумал, не последний раз они будут рассказаны.
Простота, быстрота, лаконичность -–
Вот лозунг который подходит не только для инженеров но и филологов.

Мешание языков — первая причина конфликтов в мире переводчиков
Одни считают что нужно переводить термины иностранные
Другие считают что вообще переводить ничего не нужно
Живость языка основным критерием примите
Для сплочения людей служит он
Поэтому будьте искренни с языком, не мудрите
Раз используете слова чужеземные в кальке транситерации
Так и пишите, не обманывайте себя и публику
Заодно дети малые, которые языка не знают подучаться
И вам проще, все ж термины знают

Лоадер, Трекер, Дескбар, — не переводятся, помните
Не мое только мнение это, но и людей известных достаточно
Знающих толк в рекламе и меметике
Тема Лебедев хоть и гандон штопанный,
Но понял и тему эту двигает незлонамеренно, правильно
Перефразировать можете в языке естественном,
Но Интерфейс, Атрибуты и Индексы слова такие же
Как Твитчер, Скриптинг и Шорткаты клавиатурные.

Второе мое наставление, не бойтесь перефразировать
В этом момент творчества и мысли освобождение
Уныла кирилица по сравнению с инглишем и не для того предназначена
Поэтому ищите формы новые, заодно и отсебятины добавьте чарующей
Главное что б всем потом понравилось

Литься чтение как стих должно
Расслабляя концентрацию и вводя в медитацию
В хайку японское упрощенное
Всю докуметацию силой мысли превратите вы
Тантру буддисткую непрерывную захуярьте по скромному
Что б охуели все не замечая сами того

Третье мое наставление кануло в лету за буквами
Двух эти вполне достаточно что бы смысл выразить
И самим отыскать слова нужные
Для дальнейшего воплощения

Слова эти открытым письмом для Тотиша и всех будущих переводчиков предназначены
Русская документация вполне сносная получилась однако же
За что Рустаму, Мише и Дайверу благодарность выражается
Но тоже может быть пересмотрена :)
kernel_joe: (Default)
Termios

According to Single UNIX Specification Version 2 Ц General Terminal Interface (termios.h their structures, functions and constants) defines the way to deal with termios Terminal Structure. The main purpose of public part of specification is to provide set of constants to manage the terminal, i.e. on which codes and how terminal must answers. The private part (how driver must collect data, input and output queues, synchronization) is free to interpretation. Most common set of flags constants covers POSIX, BSD and XOPEN vision of the matter.

In other words the main purpose of Terminal Interface is to convert characters on input and output streams from symbols to device interpretable commands. The main conversion logic is concentrated in *read* and *write* subroutines of terminal driver.

The termios service (I mean *ioctl*) handler codes are also free to implementation but in general there are some *standard* codes used in BSD and System V like systems, and thereby software relays on that implementations.

Line disciplines

As was mentioned above - one of the main purpose (besides unification of dealing with character input/output human devices) of terminal interface is to convert data streams (e.g. when we recognize " " in *write* stream we must send to message to display part of terminal "carriage return" and "new line" commands. Besides *read* and *write* routines alongside of them are *open*, *close* and *ioctl* operation that also may have some not-traditional logic for certain conversion mode. That conversion layers calls Line Disciplines. Thus line discipline is a set of terminal driver handler on of them can be chosen for fixed termios instance.

Custom Line discipline (besides) is used to handle conversion modes e.g. for standard TTY, MOUSE, PPP, SLIP protocols. Many variants of those protocols can be obtained and used in one application. On most Unix-like OS Termios structure has c_line field used to select line discipline.

Teletype Discipline

Teletype driver consists of standard conversion logic (*read* and *write* subroutines) the service logic (*ioct*, handler codes). This means exact the discipline - standard tty discipline used in most cased when used terminal subsystem. E.g. it is used in conjunction with device drivers, like pty, com, ppp, slip, and may others. Teletype driver is not working with devices directly it just converts char from raw to canonical form.

Terminal Drivers

The most wide known variants of tty drivers are pty master/slave drivers and serial line drivers. Other using of tty is covering by ppp, slip and others communication stacks. The terminal driver is responsible to handle the control characters in stream and convert it to device commands, control of it sending to device along with input/output character stream to device.

In theory each terminal driver can use their own discipline or set of disciplines along with providing no discipline. If the terminal driver provides no discipline - the common Teletype Discipline is using. From other side one discipline can be used with two or more teletype driver. I.e. discipline is not connected directly "one to one" with device type. Also terminal can always use teletype discipline as wide known discipline.

Line disciplines are distensible

I.e. you could implement your own line discipline and use it in you application or terminal drivers. For example there is no need to implement all possible and used in industry line disciplines - but must be an elegant way to extend them. Thus discipline is loadable module that can be obtained by its name.

The main teletype discipline is one of the always known disciplines when working with terminal is needed and is responsible for storing information about other disciplines and their using.

             Module 1  Module 2  Module 3
+---------+  +------+  +------+  +------+
| DISCIPL |  | TTY  |  | PPP  |  | SLIP |
| MANAGER |  | DISC |  | DISC |  | DISC |
+---------+  +------+  +------+  +------+


That means that TTY discipline module is not like other discipline module - it is main - and hosts discipline array structure. TTY discipline is some kind of master discipline. Let us see examples on how disciplines are used in TTY stack.

Example 1. RS232 Driver - the same is PTY driver

+-----------+
| USER APP  |
+-----------+
     V
----------+  +-------------+
| COM     |->| TTY         |
| DRIVER  |<-| DISCIPLINE  |
+---------+  +-------------+
     V
+-----------+
| HARDWARE  |
+-----------+



Example 2. PPP Driver

+---------------------+
| PPP client User App |
+---------------------+
    |
    V
+----------------+ +--------+   +----------------+   
| PPP DISCIPLINE | | PPP    |<- | TTY DISCIPLINE |
+----------------+ | DRIVER |-> +----------------+ 
                   +--------+           |
                                        |
                             +----------+------------+ 
                             V          V            V
                         +--------+ +--------+ +--------+ 
                         | COM    | | USB    | | NET    |
                         | DRIVER | | DRIVER | | DRIVER |
                         +--------+ +--------+ +--------+


For example I can (from user app) say to PPP driver not to use PPP discipline but instead your own implemented TEST Discipline. The mechanism of selection underlying hardware is of scope of work of Network Team. TTY subsystem just must provide proper mechanism to using with tty disciplines for authors of PPP driver.

             +-----------------+
+--------+-> | TEST DISCIPLINE |
| PPP    | <-+-----------------+ 
| DRIVER |-> +----------------+
+--------+ <-| TTY DISCIPLINE |
             +----------------+


This can be done by changing c_line flag in termios structure associated with opened file device.

But that can't guaranteed that all drivers must handle that. E.g. in PPP driver is used two disciplines one can be substained but second is always tty. You could change just one discipline by the termios interface. But driver can use more than one discipline in its conversion logic.
kernel_joe: (Default)
Я себе купил PowerMac 9600. Две сетевые карты 10 и 100 МБит, USB, карта переходник с процессором G3 750 400Mhz, внешний CDRW, два винчестера по 4 ГГб с установленными Mac OS 9.2.2, Mac OS 8.5, BeOS 5 Pro и BeOS Dano. Layout такой: четыре раздела по 2 ГГб на двух 4 гигабайтовых винчестерах. На первом винчестере только Мак, на втором только БеОС. Надо снесни минимум один раздел. Думаю какой. Хочу поставить туда Debian.
kernel_joe: (Default)
Я вдруг решил что хватит рахваливать BeOS, а то все уже начали думать что лучше ничего быть не может. Да, ребята из Be сделали много, но многое не успели, а некоторые вещи даже не планировали. Главное чего нету в BeOS, и что есть в промышленных серверных современных ОС - это две вещи: асинхронный ввод-ввывод и файлы проецируемые в память.

Asynchronous I/O. BeOS абсолютно не поддерживает асинхронный ввод вывод. Хотя показатели пропукной способности файловой системы а так же время отклика очень хорошие как для синхронного ввода/вывода. Даже Linux 2.6 начал поддерживать aio.

Memory Mapped I/O. Да, в BeOS напрочь отсутсвует файлы проецируемые в память. Вследсвии чего, многоие трюки, которые так нравятся всем кто любит NT, тут сделать нельзя. Вообщем красивее всего это сделано в NT.

Почему же инжинеры из Be, создавая систему с таким тюнингом планировщика и файловой системы заточеной под выполнение операции с mass data не позаботились об этих вариантах ввода-вывода. Может не хотели, или все таки решили что этих феничек нахер не надо ? Не думаю. Впрочем хочу отметить что лайв видео, захват и операции с большими файлами даются BeOS действительно очень легко. В чем фишка ?

Console MT

Mar. 10th, 2005 06:48 am
kernel_joe: (Default)
Я помню когда у меня впервые появилась дуальная система я первым делом написал консольное приложение, которое в двух потоках выводило символы "о" и "х", позже я написал сортировку слияинием, но это другая история. Итак, я решил ничего нового не придумывать, а опробывать (вспомнить) "мягкость" планировщика. Для сравнения я взял BeOS, Windows 2003 Server и Linux 2.4. Правда в линуксе у меня только консольный режим (поэтому он как бы вне соревнований я просто упомяну о нем). Еще раз напомню что система представляет собой два Pentium III 933 MHz.

Компетишн

Вот код для BeOS.

#include
#include
#include
#include
int32 th1(void *data) { while (1) { printf("o"); fflush(stdout); } }
int32 th2(void *data) { while (1) { printf("x"); fflush(stdout); } }

int main(void)
{
status_t exit_value;
int32 data1 = 0;
int32 data2 = 0;
int32 i1 = spawn_thread(th1, "T1", B_REAL_TIME_DISPLAY_PRIORITY, &data1);
int32 i2 = spawn_thread(th2, "T2", B_REAL_TIME_DISPLAY_PRIORITY, &data2);
resume_thread(i1);
resume_thread(i2);
wait_for_thread(i1, &exit_value);
// never reach here
printf("Console MT. version 1.0/BeOS");
return 0;
}

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

Вот версия для Windows.

#include "stdafx.h" // сомнительный инклуд
#include
#include
#include
#include

unsigned __stdcall ThreadOne( void* pArguments )
{ while (1) { printf("x"); fflush(stdout); } return 0; }
unsigned __stdcall ThreadTwo( void* pArguments )
{ while (1) { printf("o"); fflush(stdout); } return 0; }

int main(int argc, char* argv[])
{
DWORD params;
unsigned ThreadOneId;
unsigned ThreadTwoId;
HANDLE th1 = (HANDLE)_beginthreadex(
NULL, 0, &ThreadOne, NULL, 0, &amp;amp;amp;amp;ThreadOneId );
HANDLE th2 = (HANDLE)_beginthreadex(
NULL, 0, &ThreadTwo, NULL, 0, &ThreadTwoId );
WaitForSingleObject(th1, -1);
return 0;
}

Вообщем для виндовса тема такая: для всех вариантов (однопоточные, многопоточные, libc, напрмер) разный стафф - вот и здесь вместо CreateThread надо писать обернутую _beginthreadex с чем не валится libc от майкрософта. Под линукс код не выложил, но он тоже достаточно прост, используется нативные pthreads.

Тестирование

BeOS

Сначала я тестировал BeOS версию. Потоки создавал с приоритетом B_REAL_TIME_DISPLAY_PRIORITY. Сначала запустил с двумя процессорами потом с одним. С двумя все прозаично, на выводе четкое чередование "хо":

хохохохохохохохо....

С одним немного интереснее. Но сразу видно что кванты выдаются маленькие.

xxxxxoooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoooooo

Причем такое чередование в три-четыре линии довольно стабильное.
Потом я перенаправил все это дело в файл и получил приблизительно то же самое. Для двух процессоров было все таже неизменная последовательность "хохохохо". Для однопроцессорного запуска три-четыре линии сменились на четыре-пять. Вообщем не так уж и много, в целом можно сказать что чувствительность у файловой системы к многопоточным приложениям очень высокая.

Я остался доволен. Потом решил немного пришпорить лошадей и понизил приоритет с B_REAL_TIME_DISPLAY_PRIORITY до B_DISPLAY_PRIORITY. Для однопроцессорного запуска линии немного "удлиннились" а для двухпроцессорного получилась такая картина:

ooooooooxoxooxoxxxooxxxxxxoxxxxoxxoooxooooxxxxx
xooooxoxoooxoxooooxxxxxoxoooxoxoxxxxxxooooxooox
oooxoxxoooooxxxxxxoxoooxxxxoxoxxxxxxoxoxxoooooo
oooooooooooooxxxxooxxooooooxxxxxoxoxoooooxxxxxo
xxxoxxxoxooxooooooooooxoooxooxooxxoooxoxoooooxo
xxxoxooooxoxxxxooooooxoooxxxoxooxxxxxoooooxoxoo
oxoxxxxxxooooxxxxxoxxxxxxxxoooooxooxxxoxxooooox
xxxxoxxxoooxoooooooxooxooooooooooxoxoooxxxoxooo
oxxxxxxxxxxxxxxxxxxxoxooooooxoooooxxxxoooxoxoox
xxoxxoxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxoooooxxxxx
xooooooxooooxoxxxxxxxooooooxooooooooooxoxxooooo
xxoooooxooxxxxxxxooooxoooxxxoxxxoxxxoxxxxxoxxxo
oooxoxxxxxxoooooxxoooxxooooooxoooooxooxoxxxxoxx
xoooooxoooxxooooxxxxxxxxxxxxxxxxxxxxxxxxxoooxxx
oxxxxxxoxxxxxxooxoooxxoxxxxxxoooooxoooooxoxxxxx
xoooooxoooxoxxxoxoxxoxxxxxxxxxxxooxoxxoxxxxxooo
oxoxoooxxoooxxxxxoxxxoooxxxoxooxooooooooooxoxxx
oxooxoooooxxxxoxxoooxxoxxxxxxoxxxxxoxxoxoooxoxx
oxxxxxxxxxxxoooooxxxoxooxoxxxoxxxxxxxoooooooooo
ooooooooxoxxoooooxxxxxoooxoooxoooxooooxxxoooxxx
oxxxooxooooooxooooxoxxxooxxoooooxxxoxoxoxxxxxxo
xxxxxoxoooxxxooooooxxxxxoxxxooooxoxxoxxoxxxoooo

Вообщем система на потоки с таким приоритетом, как видно, откличкается неохотно. С файлами та же ситуация.

Windows

У меня на работе стоит Celeron 2.4 GHz. Вот что выдает Windows на этой однопроцессорной машине.

xxxxxoooooooooooooooooxxxxxxxxxxxxxxxxxoooooooo
oooooooooxxxxxxxxxxxxxxxxxoooooooooooooooooxxxx
xxxxxxxxxxxxxoooooooooooooooooxxxxxxxxxxxxxxxxx
ooooooooooooooxxxxxxxxxxxxxxxxxoooooooooooooooo
oxxxxxxxxxxxxxxxxxoooooooooooooooooxxxxxxxxxxxx
xxxxxoooooooooooooooooxxxxxxxxxxxxxxxxxoooooooo
oooooooooxxxxxxxxxxxxxxxxxoooooooooooooooooxxxx
xxxxxxxxxxxxxoooooooooooooooooxxxxxxxxxxxxxxxxx
oooooooooooooooooxxxxxxxxxxxxxxxxxooooooooooooo

Неплохо, скажете вы, мало чем отличается от БиОС. Ан нет. Во первых частота больше, во вторых давайте посмотрим как себя ведет файловая система. Результат после долей секунды такой: Файл размером 39 КБ состоящий из трех частей (по 13 Кб) иксы, нули, иксы. Вообщем синхронный ввод/вывод не в сравнение с BeOS.

На этом месте один мой товарищ http://shvydky.blogspot.com сказал мне: "Конечно будет плохо. Ты ведь не используеш IoCompletionPort!" И предложил такой вариант программы на до-диез:

using System;
using System.Threading;
public class test
{
public static void Method1(object state) {
char ch = (char)state;
while (true) Console.Write(ch);
}

public static void Main() {
ThreadPool.QueueUserWorkItem(new WaitCallback(Method1), 'x');
ThreadPool.QueueUserWorkItem(new WaitCallback(Method1), 'o');
Console.ReadLine();
}
}

Не обдумав все хорошенько я сразу запустил приложение на работе на своем однопроцессорном целероне. Результат еще хуже (чем просто нативные потоки):

oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Во первых, я сначала засомневался если ли вообще здесь IoCompetionPort, так как IoCompletionPort связывается с хэндлом файла, а в коде нигде такого связывания нет. Во вторых, оказывается реализация пула потоков в CLR даже на Windows NT не юзает IoCompletionPort. За детальными комментариями прошу обращаться к:

http://weblogs.asp.net/kavitak/archive/2003/12/15/43581.aspx.

Нужно переписать приложение используя нативные IoCompletionPort, но хочу предсказать что результат все равно будет хуже чем "просто пишущие два потока".

На двухпроцессорных машинах с счастью ставильная последовательность "хохохохо", чего не скажешь о Линуксе. Там даже на двухпроцессорной конфигурации имели место быть разные паттерны. Вообщем забегая вперед скажу что у Линукса самый плохой планировщик. Я не привожу сдесь линукс потому что в текстовой консоли он выводит сволочь как бешеный эти кресты и нули. Вывод в файл же настолько отстает от Windows и BeOS, что я даже не хочу сюда приводить результаты (естественно имеется ввиду мягкость вывода иксов и нулей).
kernel_joe: (Default)
После того как я болел грипом мне в голову пришла идея сново приобрести SMP систему. Итак после неудачных 350 (сгорели) и 500 (украли) у меня теперь два 933 на i815EP. Это все ради BeOS. Ка же все-таки приятно там.
kernel_joe: (Default)
As Axel Reported in OpenBeOS Kernel Maillist, the problem was in enabling A20 Gate. The problem is now fixed.
kernel_joe: (Default)
Сегодня ночью я увидел лого HAIKU в бут лоадере. Я успешно прошел плафторм лоадер, прошел бут лоадер, и дошел до ядра (остановился на vm_init). Я всего лишь поменял адреса таблиц страниц для первых 8 Мб (с 101000 на 50000), а также поменял (NextPhysicalAddress с 400000 на 300000). Видимо этот новый лэйаут не идеальный, так как валится vm_init ядра. Резюмируя: TODO: найти новый стабильный лэйаут.

P.S. Serial Debug Console:

init_page_directory reached.
allocate a new page dir...ok
clear out the page dir...ok
fill first 4MB pages...ok
fill 4MB...8MB pages...ok
init_page_directory leaved.
options = 0
boot(): enter
boot(): heap initialized...
init vesa mode list...ok
vesa initialization...vesa info block...VESA version = 200
oem string: ATI RADEON
vesa initialized.
Welcome to the Haiku boot loader!
boot drive ID: 81
size: 1e
drive_path_signature: e183
host bus: "(before 0x20 codes)", interface: "(before 0x20 codes)"
cylinders: 16383, heads: 16, sectors: 63, bytes_per_sector: 512
total sectors: 80043264
drive size: 40982151168 bytes
boot partition offset: 20497397760
partition offset = 32256, size = 10248666624
partition offset = 10248698880, size = 10248698880
partition offset = 20497397760, size = 10248698880
load kernel...
unhandled pheader type 0x6
unhandled pheader type 0x3
kernel entry at 80026ca0
Welcome to kernel debugger output!
init CPU
init interrupts
init_int_handlers: entry
init VM
vm_init: entry
kernel_joe: (Default)
Потому что у меня перегружается платформ лоадер /src/kernel/boot/platform/bios_ia32 после входа в защищенный режим (mmu_init). Говорят это происходит и на атлонах и на интелах. У меня, конкретно, Celeron на i815EP. У Акселя на атлоне и на P3/SiS все работает. Если не получится на выходных что-то узнать больше о существующей проблеме я буду искать машину на BX, с надеждой что там все получится. Очень хочется все же запустить ядро.

P.S. Я пользуюсь на Windows лептопе MTTTY (который идет в примерах MSDN).
kernel_joe: (Default)
Yesterday i've installed BeOS 5.0 with 5.1 (BONE) update from beos.spb.ru. Today i plan make kernel from open-beos sources.

I also found interesting doc about NewOS/OpenBeOS in Semaphores, Scheduler and SMP by Андрей Касинский, адрес которого я так и не нашел.
kernel_joe: (Default)
Preparing hacking OpenBeOS takes some time. The cvs sources takes 110 MB, on dial-up it is not funny even with -z3 option. Anyway i started and my preparation consist of:

1. I found BeOS 5.0 Pro CD with both PowerPC and Intel install sessions

2. I read some docs Haiku Getting Started and Haiku Disk Boot before starting

3. I downloaded following software:
  • gcc-2.95.3-beos-041202.zip toolchain from BeBits
  • perforce jam and p4 binaries for BeOS it can be taken from upper docs.
  • cvs for BeOS getted also there.
  • also i downloaded from BeBits some applications.
I didn't yet configure modem under BeOS so it takes time too. It also needs to set up IDE Replacement driver from BeBits and new network update to kernel from version 5.1.