kernel_joe: (Default)
The main purpose of this report is to show one of the ways how to design and build infrastructure around Haiku that will covers all the niches and OS weight categories. BeOS successor was chosen as one of very self motivated products that is proven to be such (Haiku community reimplemented BeOS kernel and subsystems with high quality code base: less that ten thousand closed bugs for such a big project). Also this document can be treated as investors guide or internal vision of Synrc Research Center, playing role of BeOS and Haiku advocate.

Coverity

Open Source world nowadays presented with walking tall Linux that covers all niches in every IT markets: from hand watches to enterprise servers and cloud networks. There are commonly discussed pros and cons about being player with Linux rules:

Pros

— Wide and spread devices and tools support
— Low time-to-market value
— Low-cost engineering

Cons

— Low code quality
— Managing in bazaar manner
— Limitation of Licence

There are some attempts to solve negative aspects of Linux-way: commercial support of BSD systems such as Wasabi Systems, Inc and custom commercial support of OpenBSD. But in general Linux is dominant OS platform for wide range of services. Though, investments to Linux from big side of IT-market is not very prominent. Most mobile developers that was chosen Linux drops their Linux-based OS development. Apparently that happened because of aggressive Android positioning that technically spoken hides ugly Linux layer from application developer. Most severs manufacturers switched from their own server OSes to Linux, but in general the happiness hadn't come. The main part of their revenue composed of support service, but R&D and Linux development is blocked up with Linux weak spots.

The first candidate for OS that can cover all devices from mobiles to server is Mach-based XNU kernel from Apple with Objective-C application framework from NeXT. It is well designed in CMU, polished by Apple and adapted to the modern needs. Another players on the market are the lightweight Windows CE and also Mach-inspired Windows NT kernel already spited in two categories and closed forever by its authors.

So the weight categories of OS presented in IT industry:

— Embedded (robots, plants, devices, appliances, real-time applications)
— Mobile (telephones)
— Handy (netbooks, pads)
— Desktop (workstations)
— Telecoms (servers)

Honestly spoken only quality based approaches and effective technologies forms the solid ground for long-term living infrastructure, that can be auto-motivated and self inspired. Victorious Linux walking holds in it only temporal nature. Only players that can quickly cut off money from Linux could select it as a base platform as did Google with Android: zero-innovation, iPhone-copy interface, problems in battery living and slow motion make Linux temporally more visible to customers. The market controlled by time-to-market parameter but not self-inspiring criterion produces low-quality goods and services. Same state of things presented in general in servers market.

However the product that can cover all the niches and comply high claims on purity and self motivation exists. Actually it was already once a time in the market in 1990-s before it was banned by Apple and pressed by Microsoft. This product had such a positive indicators from all sides of vision that it was too good for its time. Imaging 64-bit transactional attribute-driven file system and all hyper-threaded application capable of running full power on 256 processors in late 1990. Consider today MHz limitation by physics of silicon chips and growing trends on parallel processing. Clean kernel code and fast context switching make this product comparable and competitive to real-time operating systems. Fine tuned scheduler beats up all modern desktops. Of course this product was BeOS.

Kernel

Up for now already exists modern clean kernel that is proven to be good in wide range of applications. It is even more qualitative that Be's one. Originally it was developed be ex-Be engineer Travis Geiselbrecht as NewOS and later adopted and refactored by Haiku members, now forms Haiku kernel. It is well mature with clean highly portable boot architecture and object-oriented highly portable VM layer. Based on 5 primitives it has fast context switching and 80 kernel syscalls being fully compatible with original BeOS kernel. As XNU, internally it uses C++ for better presenting of concepts and externally visible through C interface.

After death of Symbian (EKA open source mobile real-time kernel) Haiku and NewOS kernel can form the new base of mobile kernels for wide range of applications, being totally free from Symbian C++ negative aspects.

Application Framework

The general idea of application layer development is taken from 90-s the servers that serves asynchronous network-transparent persisted client messages from client threads. There is set of servers that acts as isolated restartable processes: network, application, debug and other system servers that gives stability across the application layer of the system. This approach is known as application-level microkernel in contrast to drivers-level microkernel where device drivers also live as separated isolated processes (can be found in QNX). Such microkernel design is known to be native BeOS application level architecture presented in from of C++ API.

Also today it can transparently host Qt framework thanks to Gerasim Troeglasov. That can fullfill mobile platform built around Haiku with Symbian Qt and MeeGo Qt mobile applications considering Nokia's focus-shift to Windows platform. This is apart from huge set of existing Qt desktop applications.

However new mobile home screen lobby, new controls and layout for mobile phones and gesture API should be designed in order to support hand human interface. That is a gap in coverity of Haiku code base.

As for netbooks and geek desktop Haiku clear user interface (actually BeOS interface) in style of old-school Mac OS that is fully satisfy customer needs. Being so small and quick it starts with 6 seconds and another 6 seconds it needs to load all application shipped with the OS.

The only niche it lacks is a desktop workstation with professional specialized software that is designed only for Windows and Apple.

UNIX Services

Speaking of UNIX services Haiku must provide full set of POSIX API with modern epoll/kqueue counterpart. It already has it along with very promising multi-threading capabilities: on 8 quad Atom CPU Haiku can play simultaneously seven streams of 704x396px MPEG-4 without performance downgrade in contrast to Linux three simultaneously streams.

Existed ports system similar to Gentoo Portage exists in Haiku. Now it already has a number of common UNIX applications for server maintenance need. Among them Erlang one of the best and de facto standard in telecommunication services. Synrc Research Center examines Haiku for hosting their Erlang services.
kernel_joe: (Default)
Написано для http://synrc.com

18 Августа 2001 года. Именно этим днем датируется начало летоисчисления операционной системы Haiku как день, когда в списке рассылке было принято решение продолжать дело инженеров Be. 13 ноября 2001 года Palm завершила поглощение Be, Inc.

Сейчас уже трудно вспоминаются те времена, когда BeOS вдоновляла и когда компьютер действительно воспринимался персональным. Сейчас в эпоху Web и распределенных технологий нишу персонального компьютинга заняли мобильные телефоны, планшеты и нетбуки.

Но я бы начинал летоисчисление платформы с того момента, когда собралась команда из Стива Сакомана, Жана Луи Гасье, Бенуа Шилингса, Боба Гарольда, Эриха Рингевальда ставшая основой компании Be, Inc. Это был 1991 год. Таким образом на самом деле платформе 20 лет. 10 лет Be, Inc. писала BeOS и делала компьютеры и 10 лет — возраст Haiku сообщества.

Человеку незнакомому с системой может показаться удивительным, зачем воссоздавать с нуля операционную систему, которая в конкурентной борьбе потерпела поражение. Однако такой ход энтузиастов говорит сам за себя. То что было создано оставило неизлечимый след в умах и сердцах людей которые способны написать ОС. Таких людей не очень немного, и кроме усидчивости нужно иметь кроме всего прочего и по-настоящему неплохую сведущесть инженерных делах.

Рассвет embedded технологий, за ним рассвет мобильных ОС, а также интернет компьютеры (типа Chrome OS) это все на самом то через что десятки лет назад уже прошла BeOS. Все что мы видим сейчас, все тренды и тенденции уже были пройдены когда-то, растут только количественные показатели по закону Мура. Последний отголосок гибели операционной системы которая напоминаем нам BeOS является Symbian (EKA kernel) которая являлась сердцем легендарных портативных компютеров Psion. Что бы понять embedded сектор достаточно посмотреть на BeOS.

Так, например, в технических аспектах построения единой языковой абстракции и ОО, аспект-ориентированному программирования мы видим в LISP машинах и Smalltalk системах. На самом деле то, что в императивном программировании является сейчас трендом было создано в 60-х и до сих пор пожинаются плоды этих исследований.

Единственный конкуретно-способные операционные системы которые дошли до нашего времени для рабочий станций — NeXT и Windows NT были построены на основе ислледований по операционным системам в Карнеги-Мелон универсистете, проекте Mach.

В математике путь от вычислимости по Тьюрингу, через лямбда исчисление и до Теории Категорий просвечивался еще в 20-х годах 20 века. Теоретический предел "кремниевых" вычислений постигший компьютеры в 21 веке заставляет разрабатывать паралельные вычисления на новом, функциональном уровне.

Так что бы понять Что различные паттерны и архитектуры систем программирования достаточно изучить LISP, CLOS или Smalltalk. Что бы понять какой должна быть ОС для рабочей станции достаточно посмотреть на Mach. Что бы понять теорию вычислений достаточно изучить теорию категорий. Что бы понять embedded приложения и geek системы достаточно посмотреть на BeOS.

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

Единственный и самый емкий сектор энтузиастов (именно энтузиастов, а не промышленный embedded сектор), которые будут двигать платформу BeOS — это гики, программисты. Скоро умрут последние гиковские операционные системы: автор SkyOS прекратил разработки, Amiga тоже подошла к концу, RISC OS в предсмертном порыве открыла исходные коды, которые откровенно говоря не сверкают, Syllable OS (AtheOS) тоже прекратила развитие. Haiku оказывается пережила их всех, и это неудивительно. Для этого достаточно посмотреть в исходники. Будем откровенными, при всех недостатках Haiku сообщества корневые разработчики пишут код в хорошем тоне, заданном Тревисом Гейсельбрехтом. Его NewOS послужила основой не только Haiku OS но и в некотором смысле служит платформой для исследований Дмитрия Завалишина и его операционной системы Phantom. Пожелаем же ему успехов и вдохновения на этом нелегком пути.

К радость или счастью Linux Торвальдса которая тоже появилась из Гик сектора с успехом завоевала всемирные embedded сектор, а также рынок серверов и околосерверного оборудования. Не будет давать оценок Линуксу, потому что дискуссия в основном сведеться к двум разным подходам к производству программного обеспечения: 1) коммунизм или демократия и 2) жесткая диктатура. Примеры первых это Linux, Windows, FreeBSD, примеры вторых это OpenBSD, Apple.

Дискурс о Линуксе очень слользская почва, потому что спектр Линукса пока намного больше чем BeOS или Haiku. Если Haiku потенциально еще можно запустить на телефоне (ARM) то ее non-MMU версия стоит пока под вопросом. Однако портируемость менеджера виртуальной памяти Haiku находится на высоком уровне, на таком же как и OpenBSD UVM. Захват рынка серверов тоже не за горами, для этого достаточно что бы Haiku стабильно хостила Erlang, который уже есть в HaikuPorts. Таким образом в принципе Haiku теоретически тоже может вместить в себя весь спектр вычислительного оборудования от мобильного телефона до телекоммуникационного сервера, но на практике спектр Линукса пока полнее. По крайней мере сам codebase чище, платформа стройнее, и если держаться диктатуры в управлении, то можно через поглощение Geek сектора добраться и к Mobile Embedded а там и до Telecommunication Servers. По крайней мере это те пути которые я вижу.

Имея лишних 1-2 ляма, я бы незамедлительно вложил их в разработку ARM порта Haiku и в дизайн мобильного GUI для телефонов. В качестве GUI API я бы выбрал Qt и для совместимости оставил бы App Server. Таким образом я бы попытался занять нишу Symbian и MeeGo (MeeGo — это текущая Geek OS в секторе Mobile Embedded от Nokia). Кроме того я бы занялся новым GUI для планшетов и сенсорных Desktop, попытавшись заключить контракты с производителями оборудования и попытаться потеснить Android и Apple. К счастью в Desktop секторе конкурентов нет (все десктоп Geek OS уже доживают свой век). А на нетбуках всем Линукс стоит у горла и все только и ждуть стабильной Хайку, тут даже вопросов не возникает, тут Хайку уже победила. Дальше я бы выпустил ядро и TRON прослойкой для японского рынка захватив таким образом embedded в японии и занялся бы стабилизацией работы Erlang на Haiku и предложениями для Erlang деплоеров. Уверен — голые цифры в превосходстве над Linux были бы убедительные миллиона слов.

Haiku Chat

Aug. 24th, 2011 08:50 pm
kernel_joe: (Default)
Brought to Haiku Community

Haiku Chat is tiny, about 300KB XMPP client. It supports core XMPP protocol, multi-user chat, Google accounts, Psi bookmarks, In-band registration and other features. It is written for Haiku, free open-source operating system inspired by BeOS. Haiku Chat is simplest and smallest client that supports XMPP Advanced Client 2009 profile.



[1]. Project Home
[2]. Haiku Chat on Haikuware
[3]. Sources on Berlios
kernel_joe: (Default)
Со времён BeOS и Be, Inc. прошло много времени. Как сейчас помню как в 1998 году я купил диск на радио рынке с BeOS R3. Я тогда только начинал познавать мир UNIX и вручную реинженирить ntoskrnl.exe в Soft-Ice. Увиденное мной тогда навсегда поселило во мне что-то, что трудно передать словами, фактически все что я узнавал как инженер в системо-строении и программировании проходило через призму увиденного. Все, кто тогда вместе со мной открывал для себя BeOS до сих пор относятся к ней с нескрытой радостью, удовольствием и уважением к незагрязненности инженерной мысли. Все системы которые я видел и изучал включая Hurd, Chorus, Mach, NT, Plan9, QNX, TRON и десятки других embedded проектов стоят у меня всегда на втором месте, не смотря на доказанное временем их значение в мире индустрии. И дело не только в многопоточности, распаралелености, отзывчивости планировщика и чистоте самого кода, есть что-то в ней запредельное, что успокаивает и заставляет радоваться как ребенка.

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

Сейчас у меня ноубук на ремонте, поэтому я взял ноутбук жены (Acer Aspire 5520) и решил поставить незаментно для нее Haiku R1/alpha2 на ее ноутбук. Оказалось, что он не видит флешку для загрузки, не беда, я записал CD. Перед этим Acronis DiskDirector освободил 10ГБ партицию. Загрузился с CD и поставил на эту партицию, отформатировав ее прямо в инсталлере. Нажатие одной кнопки и система поставилась. Записал бутсектор партиции, записал загрузчик в MBR (все это тоже из инсталлера) и перегрузился. Загрузка Haiku залипла на третьей иконке, но я случайно нажал один раз на кнопку включения\выключения ноутбука, и загрузка пошла дальше. Всего загрузка системы длится 14 секунд на этом ноутбуке. Объем необходимой оперативной памяти 100МБ (можно даже без свопа, правда разработчики не рекомендуют пока его отключать). Правда вы можете использовать 48МБ оперативной памяти и 64 виртуальной памяти, все равно она будет работать :) Это нормально для Geek систем.



Сразу мы попадаем вот в такой мир. Именно этот экран обратил внимание моей дочери. "Какие красивые иконки, какая приятная штучка, можна я за ней посижу", -- попросила меня моя 9-летняя дочь. Что ж устами младенца глаголит истина. Через некоторе время малая уже баловалась вот такими штуками:



Но больше всего ей понравился графический редактор, который рядом не стоял с Paint. Шарит разные браши, поддерживает векторные пути и полигоны, разного рода растяжки и стили, такой себе nano-Photoshop смешного размера:



nForce сетка и звук поднялись сразу, но иногда сетка отваливается, а звук постоянно глитчится. Однако мне удалось запустить 12 видеороликов проигрывающихся одновременно без падения производительности до того как MediaPlayer выпал в gdb. Выглядит плеер очень мило. Я замаунтил NTFS диски и начал смотреть Хауса. Один диск удалось замаунтить как Read-Write и я создал там пару файлов, но потом почему-то диски перестали маунтится как read-write. Вот фото Гриши:



Даже если у вас не определится сеть по ряду причин, одна из которых отсуствущий работающий Wi-Fi WPA2, вы всегда сможете насладиться чтением оригинальной документации по API (BeBook) и прочитать про устройство системы используя родной браузер построенный на KHTML/WebKit, т.е. на самом современном движке который используют Google и Apple:



Для задротов с немытыми головами тут будет уютно, тут есть bash, binutils, fileutils, куча библиотек out of the box, многое потихоньку портируется, а что соотвествует идеологии -- включается в дистрибутив. Есть два gcc: 2.9.5 и 4.3.3. Это связано с тем, что Haiku поддерживает приложения своего оригинала -- BeOS R5 и должна иметь возможность запускать и разрабатывать приложения с gcc2.



API ядра очень сильно по простоте напоминает TRON, есть всего 5 объектов операционной системы: потоки, процессы, семафоры, области виртуальной памяти, порты сообщений. Но не смотря на свою простоту API достаточно мощное что бы реализовать POSIX. Линкуется API ядра как С библиотеки, хотя многое внутри ядра написано на С++, включая изящную кросплатформенную систему виртуальной памяти. Прочитать про API ядра можно здесь:

http://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Overview_Introduction.html

Be API прикладного уровня, является не менее мощным средством, чем Win32 и NeXT, спроектировано примерно в тоже время, что и NeXT Framework. Но в отличии от С API Win32, и ObjectiveC линковки Cocoa, библиотеки линкуются как с++ библиотеки со всеми вытекающими последствиями: простотой разработки, ненужно дополнительных прослоек (все и так красиво), привязка к ABI компилятора gcc. Именно объектность API BeOS и стала причиной распространения двух версий gcc с Haiku и возможностью запускать бинарники скомпилированные несовместимыми версиями gcc. В Haiku используется ELF формат. Если хотите написать лоадер для загрузки PE или COFF файлов других систем, чувствуйте себя свободно :)

http://www.haiku-os.org/legacy-docs/bebook/TheApplicationKit_Overview_Introduction.html

Писать под Be API одно удовольствие. Вы можете попробовать ненавязчивую среду разработки, которая состоит из маленького окошечка проекта и редакторов исходников, что бы убедится в этом:



Что мне в ней нравится:
- простота, чистота, код без наследия
- изящность, красота
- быстрота, грузится 15 секунд
- дизайн (архитектура микроядра и обслуживающих серверов)
- MIT лицензия, позволяющая стартовать коммерческие проекты
- изобильное использование объектов синхронизации на всех уровнях системы
- кроссплатформенность (ARM, PowerPC, x86_64)
- совместимость с BeOS R5 (ничего не надо учить я все уже знаю)
- WebKit браузер
- Практически полная POSIX совместимость
- поддержка UNICODE на всех уровнях (IBM ICU идет с системой)
- поддержка японского языка из коробки
- Gallium3D, в ней в будущем должны работать DRI драйвера для Linux
- в ней могут работать сетевые драйвера от FreeBSD 8
- совместимость с ноутбуком моей жены
- то что ей полностью хватает 100МБ памяти
- достаточно современная журнальная файловая система, что бы не было здесь вообще вопросов
- механизм Query, по типу Windows Search, Spotlight или Beagle
- куда не ткнись везде все сделано как надо и сделадно просто и понятно
- нравится детям
- имеет огромный педагогический потенциал (начиная от ребенка, заканчивая студентом)
- успокаивает нервы
- в ней можно красиво реализовать свои неоплачиваемые (пока) фантазии
- годится как в embedded сектор, сектор нетбуков, так и в сектор гиков

P.S. Чесно говоря, когда я в 2004 году зашел на канал #haiku на фриноде, у них не было ничего, что мне было интересно, я просто думал что они не потянут. В то время я разговаривал тогда напрямую с Тревисом Гейсельбрехтом, бывшим инженером Be, автором оригинального ядра NewOS (В Haiku ядро NewOS лишь немного зарефакторено). Хотел у него поспрашивать про IDE драйвер для его ядра NewOS, на что он сказал мол иди к ребятам из Хайку, у них есть. С тех пор слежу за проектом и хочу сказать, что ребята эти меня радуют. По крайней мере я и моя дочь получили удовольствие от тестировочной альфа версии системы.
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)
Вчера зашел в IRC на канал #haiku@irc.freenode.net и распизделись с чувачком Артурчиком из Польши. В конце взял у него интервью по поводу его работы и планов. Надо понимать что ни я ни он английского не знаем.

Artur Wyszynski
Haiku OpenGL Kit

Maxim: Tell us about yourself ?
Artur: I'm a 27 years old, working as a game developer in GameLion Studios, long time BeOS user and almost 2-3 years Haiku developer :)

Maxim: What is current OpenGL state in Haiku ?
Artur: OpenGL state in Haiku OpenGL Kit is so simple that even Windows GL API beat us in that manner it was designed 10-12 years ago, without current GPU's multi-threading rendering etc. My plan if nobody beats me is to implement TTM memory menager in kernel, then port DRM on kernel side, provide a simple test cases which shows that it works and then rewrite from scratch Haiku OpenGL kit but as a base use Apple's OpenGL framework. It's mature, well designed and great :)

For example, current implementation of OpenGL Kit doesn't allow you to have more contexts, and for example, current engines uses multiple threads in their engines and in current design you can't divide application to use multiple context, for example one to render, one to process, one to physics etc.

Maxim: Tell us about Gallium3D in Haiku ?
Artur: softpipe in Ggallium3D takes a role of a reference driver. If you want to write driver for gallium you can take a look at softpipe. It's a pure software implementation, designed without performance in mind but as a reference. It doesn't touch GPU, and works only on cpu. There is a fork of softpipe, called llvmpipe, which uses LLVM to produce highly optimized multithreaded code, which on linux (pure software without GPU) can play Open Arena game at 32 fps on 800x600. It's pretty amazing, pure mesa have performance at 3-5 fps.

First I need to implement TTM and DRM, then I could focus on bringing OpenGL kit up to date. TTM is an API for managing memory on GPU's, DRM is a direct rendering manager, kernel side implementation of how to talk to graphics card, popular on Linux. I'm using code from FreeBSD and some parts from Linux. But lately I'm trying to get more from Linux as FreeBSD port of Mesa and GL stack at all isn't complete as much as Linux ones. But there are limits, for example linux GL stack on kernel side (DRM) is GPL'ed and on Haiku we are focusing on having much not GPL code as we can.

Maxim: You mentioned LLVM. Will you use it ?
Artur: LLVM is a Low Level Virtual Machine, it's another topic, but it allows to generate higly optimized code for cpu. Nope, i'm not planning to use it.

Maxim: What GPU will be accelerated first in plans ?
Artur: What GPU ? Which I have, nVidia :D If we're going to provide an OpenGL Kit, it should be a fully accelerated by GPU, not a software implementation. But really, my plans are first to use VMware vGPU driver and if it works, then try with real hardware. VMware vGPU is a virtual GPU architecture, which translates guests OpenGL calls into native calls from hosts, so you can get native performance from your nvidia card running on linux on your Haiku runned from VMware.

Maxim: Will Haiku support Linux DRM drivers ?
Artur: If we don't want to reinvent the wheel on haiku, we should implement DRM on our side and use stable, bug-free linux drivers. TTM and DRM are to be implemented as kernel mode code. And Haiku DRM will provide DRM API that is compatible on source level with Linux DRM drivers, similar as it was done by our colleages with FreeBSD network compatibility layer which we have for network drivers.
kernel_joe: (Default)
Любая интелектуальная деятельность требует систематизации.
Литературный перевод тоже.
Поэтому соберу наставления скромного переводчика,
Которыми вы можете воспользоваться и\или без зазрения совести выбросить в мусорку.

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

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

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

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

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

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

Слова эти открытым письмом для Тотиша и всех будущих переводчиков предназначены
Русская документация вполне сносная получилась однако же
За что Рустаму, Мише и Дайверу благодарность выражается
Но тоже может быть пересмотрена :)
kernel_joe: (kernel_joe)
Written for https://www.haiku-os.org/node/3401


This article will describe current state of Haiku bootstrap architecture. It will unveil information about earliest boot stages, some hints to platform porters will be given. This can be interpreted as an extension to Haiku Article How to get Haiku booted.

Hardware Loader

Here we draw various boot scenarions that are independent from OS and depends only from hardware architecture. Current status on each platform and its perspectives will be discussed.
  • x86 legacy systems has many options to load first stage loader. It can be boot within other loaders such as LILO, GRUB, U-Boot or directly via MBR tiny bootstrap code. x86 stage 1 boot code can be found in stage1.bin and is placed in the start of BFS partition. Other option for x86 new systems is to boot first stage Haiku loder from EFI firmware that is similar to wide known OpenFirmware hardware abstraction standard.

    Currently Haiku on x86 can be booted from MBR or other boot loaders (LILO, GRUB, etc). It just hands control (chainload) to the stage 1 BFS Boot Code directly. Stage 1 and Stage 2 bootloaders are passed. Modern EFI boot process not supported but GUID Partition Table is. Newer version of GRUB2 does support BFS so it is possible with GRUB2 to load Stage 2 haiku_loader without BFS Boot Code, but it is untested, though.

  • ARM boards usually have OpenFirmware or U-Boot on its ROM. Widely used in ARM development is U-Boot monitor that is also a kind of loader. It has support of loading images from ext2, JFFS, TFTP, NFS and other filesystems. But BFS support in U-Boot is definetly missing.

    Currently stage 2 bootloader on ARM can be booted only from U-Boot directly within using special form of gzipped bootable image (uimage) prepared with U-Boot mkimage tool. This is temporary state of things as stage 1 bootloader (BFS Boot code) is not used. Stage 2 is passed though.

  • PowerPC machines and development boards are also use both OpenFirmware ROMs and U-Boot ROMs (such as SAM440ep). But more common for PowerPC world is to use OpenFirmware (Pegasus, Apple, IBM).

    Currently stage 2 bootloader on PowerPC can be booted as binary image only from OpenFirmware directly in a form of ISO 9660 image. Stage 1 bootloader (BFS Boot Code) is not used. Stage 2 is not passed.

BFS Boot Code

The main purpose of first stage boot loader is to load haiku_loader binary image that resides on BFS partition /system/haiku_loader. Normally BFS Boot Code is platform dependend and must be implemented for any supporting platform.

Pretty attractive case of loading stage 2 bootloader is to provide BFS access (searching by BFS nodes for haiku_loader) directly from ROM (stage 0 bootloader). This is already done for ext2 filesystems in U-Boot or ISO9660 in OpenFirmware. It is possible for hardware manufacturers provide modified version of ROM.

Notes on x86 implementation

BFS Boot Code detects drive id, check if we have disk extension provided by the BIOS, load the rest of the stage 1 bootloader, validate the BFS superblock, search the stage 2 bootloader on disk, load the stage 2 bootloader into memory and run the stage 2 bootloader.

Stage 1 boot code can be found in /src/system/boot/platform/bios_ia32. The offset of the partition in 512 byte blocks must be written at position PARTITION_OFFSET_OFFSET or otherwise the code can't find the partition. The partition must be a BFS formatted. The stage 2 boot loader — /system/haiku_loader loaded into memory at 0x1000:0x0000 and entered at 0x:1000:0x0200 with EAX (partition offset in 512 byte blocks) and DL (BIOS ID of the boot drive).

makebootable binary utility makes the specified BFS partitions/devices bootable by writing BFS boot code into the first two sectors. It doesn't mark the partitions active. This utility can be compiled to run under BSD, Linux, Mac OS X, BeOS and Haiku hosts. In the case of a missing makebootable we never get to that stage 2 bootloader. You can read more about makebootable in Haiku Article about makebootable.

Haiku Loader

Haiku loader is second stage boot loader. It is presented as haiku_loader binary image that resides on BFS boot partition. The main purpose of second stage boot loader is to load relocated kernel. It draws Menu select boot device with BFS partition, collecting kernel startup settings and passes them to kernel.

The second stage boot loader divided onto two parts: platform dependent that is startup entry point itself and platform dependent functions and such as video framebuffer or video console platform dependent functions and platform independent menu, file system support and main platform independent function.

Hardware Abstraction Layer

All platform dependent functions (hardware abstraction layer) that is used in Haiku Loader can be divided into following groups: Menu, Devices, Memory, Serial Port, Keyboard, Video, Processor. Memory is about to manage basic mmu settings and second stage loader's heap. There are two MMU modes: one is for haiku loader and second is for kernel bootstrap.

For each hardware platform must be implemented following functions:
  • Menu: platform_add_menus, platform_update_menu_item, platform_run_menu
  • Devices: platform_add_boot_device, platform_get_boot_partition, latform_add_block_devices, platform_register_boot_device
  • Memory: platform_init_heap, platform_release_heap, platform_allocate_region, platform_free_region, mmu_map_physical_memory, mmu_allocate, mmu_free, mmu_init, mmu_init_for_kernel
  • Serial Port: serial_putc, serial_disable, serial_enable, serial_cleanup, serial_init
  • Keyboard: clear_key_buffer, wait_for_key, check_for_boot_keys
  • Processor: cpu_init
  • Boot: platform_start_kernel
This hardware abstraction layer functions are resides in Haiku repository in haiku/src/system/boot/platform/* directories.

Platform Independent Code

Platform independent Haiku Loader code lives in /src/system/boot/platform/generic and /src/system/boot/loader directories. The platform dependent bootstrap code fires up main function in platform independent part of loader directly.

The main function of second stage loaders inits heap, video. Then its retrieve boot filesystem to boot up, if no found it shows user menu. Then it loads modules and kernel with elf_load_image and starts kernel by calling platform_start_kernel from HAL API.
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)
Написано для http://qube.ru

Хотелось бы написать ответ на два открытых письма Майкла Фиппса «Почему Haiku еще актуальна сегодня» и «Вызовы которые стоят перед Haiku». Начать предлагаю с того что бы выяснить чем же Haiku является сегодня на самом деле, что из себя представляет проект, и есть ли успешные аналоги управление подобного рода проектами. ... )
kernel_joe: (Default)
Написано для http://qube.ru

Я не даром привел здесь только Mach и NT и не касался Linux который тоже развивался в это время параллельно, а также BSD сообщество, которое в основном исповедовало принципы 70–х годов и сильно держалось наследного кода. Промышленные операционные многое изменили внесли то чего раньше не было. Во первых настоящие хакеры и geeks не воспринимали соборные закрытые монументальные архитектуры и быстро переключились с самодельных компьютеров на открытые операционные системы, в основном это были BSD и Linux. И только последний хакер Ричард Столман пошел по Правильному пути и выбрал Mach для реализации полной цепочки хакерского арсенала: операционная система (hurd), компилятор (gcc), средства разработки (emacs), отладчик (gbd). Представьте себе все это создано одним человеком! Все эти вещи – это репозиторий методов для решения повседневных задач и полигон воплощения собственных идей.

Однако речь здесь совсем не про него, а про маленькую компанию Be Inc где работали хакеры которые очень сильно повлияли на состояние дел. Здесь я попытаюсь раскрыть какие главные достижения сделанные инженерами Be. Для начала сделаем маленькую ретроспективу Be Inc. ... )
kernel_joe: (Default)
Написано для http://qube.ru

Как правило, когда идет речь о BeOS, всегда начинают с истории компании Be Inc. Но я хотел бы начать рассказ этой истории с более ранних времен, иначе не ясно почему все произошло именно так и никак иначе.

После того как Стив Джобс покинул Apple в 1985 году началась новая история. Операционные системы стали значить намного больше для компьютера, чем это было раньше до этого. В конце восьмидесятых активно начало возникать философия открытого программного обеспечения, последний хакер Столман, который создал gcc, emacs, gdb, bfd и hurd основал GNU. Возникло два направления организации кода, «базар» (открытые open source проекты для многих людей) и «собор» (корпоративный код). Я бы еще выделил «наследие» (BSD проекты).

Я не даром называю десятилетия эпохой. В мире ИТ один год значит столько сколько в других десятки лет. За один год компания может сменить две философии и аппаратную платформу. Конец 80х годов ознаменовал собой эпоху промышленных операционных систем – компьютеры стали достаточно мощными для того что бы как быть персональными так и обслуживать отделы, сетевое оборудование, быть рабочими станциями для CAD/CAM/CAE систем. Поэтому системы стали несколько сложнее. Сообщество любителей отвергало такие рыночные отношения производителя и пользователя, и они с тоской вспоминали о временах 6502, M68000 и своими Atari, Apple II, Commodore 64.

Mach

Mach — яркий пример одного из немногих проектов, который вопреки своему большому влиянию на развитие индустрии, так мало знаком не только конечному потребителю, но и профессионалам, которые в силу узкой специализации так и не столкнулись со столь необычным детищем академической формализации профессоров университета Карнеги–Мэллоуна. ... )
kernel_joe: (Default)
Написано для http://qube.ru

Как правило, когда идет речь о BeOS, всегда начинают с истории компании Be Inc. Но я хотел бы начать рассказ этой истории с более ранних времен, иначе не ясно почему все произошло именно так и никак иначе.

Первые хакеры

Все началось еще в MIT, когда Гринблатт и Госпер сидели по ночам за своим TX–0. Это поколение программистов, которое создало первые компьютерные игры, писали первые хаки (такие как, воспроизведение музыки дисководом), сражались бессонными ночами за сокращение программы на несколько байт, их по заслугам называют родоначальниками компьютерной эпохи настоящих хакеров. Все что было создано после этого является всего лишь повторение пройденного пути. Забегая вперед скажу что апогеем достижения первых хакеров стали ЛИСП машины – настоящие произведения искусства, которые как и все красивые вещи с невероятной силой отвергаются рынком информационных технологий.

В те дни были сформулированы первые базовые принципы свободного программиста, человека который полностью управляет компьютером, человека который не стеснен методами выражения своей творческой фантазии и стремлением сделать что–то неординарное для компьютера. Можно выделить, если хотите, «кодекс» первых хакеров: ... )
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