LINUX.ORG.RU

DragonFly BSD 2.4

 , , lwkt, ,


0

0

Тихо и незаметно вышел очередной выпуск DragonFly BSD. Это клон семейства BSD являющийся форком FreeBSD 4.8 и представляющий собой альтернативный путь развития ядра (автор и идеолог Диллан, категорически не согласился с изменениями в ядре FreeBSD 5.0 и форкнул её уведя с собой ~200 разработчиков freebsd). Таким образом, сабж представляет собой альтернативное развитие freebsd-4.*.

Система интересна тем, что она оставаясь юниксом, имеет полностью асинхронное ядро основанное на модели LWKT Матвея Диллана. Относится к монолитно модульным ядрам, но с минимальным функционалом, драйверы и всё по максимуму выносится из ядра. Основная цель проекта DragonFly это изначальная поддержка кластерности ядром. То есть, создание сложной структуры управления кэшем для файловых систем, файлов, виртуальных машин, что позволяет очень интерактивным программам работать на многих узлах кластера одновременно с полной гарантией когерентности во всех аспектах работы программы. Включает в себя агрегацию ресурсов в том числе процессорных, методом контроля за виртуальной машиной, для безопасного предоставления ресурсов даже через Интернет (проект DragonFly BSD не ставит безопасность как свою первоочередную цель, для безопасности и корректности есть OpenBSD)

Пакетный менеджер - адаптированный pkgsrc http://www.pkgsrc.org/

Основная файловая система - HAMMER http://www.dragonflybsd.org/hammer/

Существенным недостатком системы субъективно считаю сложность мат-модели, и как следствие, сложность написание программ под эту систему, хотя портирование более 6000 пакетов с BSD/GNU/Linux свидетельствует о хорошей совместимости... Пока работает только на x86 и amd64, в планах есть порты на другие архитектуры...

Желающим работать совет дождаться DragonFly BSD 2.4.1 примерно в конце октября сего года..

>>> DragonFly BSD 2.4

Ответ на: комментарий от BAN

>>> не понял, как так ловко удается обходиться без критических секций

>> критических секций избежать нельзя // К.О.

> В модели lwkt критеческих секций по отношению ко всей системы нет

Йопт. Критические секции вообще относятся к данным. Но хорошо хоть, что неизбежность КС не отрицается.

> даже I/O всех девайсов работает асинхронно!

АФИГЕТЬ!!!!11 Сделай в линуксовом драйвере нить-обработчик, и он тоже станет асинхронным. Другой вопрос - нафиг это надо.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Йопт. Критические секции вообще относятся к данным. Но хорошо хоть, что неизбежность КС не отрицается.

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

>АФИГЕТЬ!!!!11 Сделай в линуксовом драйвере нить-обработчик, и он тоже станет асинхронным. Другой вопрос - нафиг это надо.

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

На то и есть в Стрекозе новая мат-модель чтоб реализовать асинхронность на SMP системах ПРОСТО и СОВЕРШЕННО!

BAN
()
Ответ на: комментарий от BAN

>> АФИГЕТЬ!!!!11 Сделай в линуксовом драйвере нить-обработчик, и он тоже станет асинхронным. Другой вопрос - нафиг это надо.

> здесь опять вы пропустили самые важные моменты

Я ничего не пропустил. Это ты придумал себе какие-то страшилки и старательно их боишься.

> "какой ценой этого достигнуто?" и "какую цену в будущем придётся платить чтобы это всё поддерживать и развивать?"

В модели "нить на устройство" нет ничего сложного, так что много платить не придется.

А вот за Dfly уже заплачено 6 лет работы. А где профит?

> есть в Стрекозе новая мат-модель

Ты употребляешь слова, не понимая их смысла. Привести ссылку на математическую модель слабо? Если ты не знал, то "матмодель" - это именно математическая модель. Где она?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Я ничего не пропустил. Это ты придумал себе какие-то страшилки и старательно их боишься.

Да не страшилки это, а факт, раздутое ядро стоновится всё сложнее, медление, и сложнее в поддержке.

>В модели "нить на устройство" нет ничего сложного, так что много платить не придется.

Там за 20 лет таких "много платить не придётся" знаеш сколько по "ничего сложного" накопилось?

>А вот за Dfly уже заплачено 6 лет работы. А где профит?

Ну имеем монолитное асинхронное кластерное ядро, ФС хаммер..., это совсем не мало учитывая что модель lwkt реализована впервые.

>> есть в Стрекозе новая мат-модель

>Ты употребляешь слова, не понимая их смысла. Привести ссылку на математическую модель слабо? Если ты не знал, то "матмодель" - это именно математическая модель. Где она?

Я имел ввиду lwkt, её новой мат-моделью ядра другие обозвали я об этом не думал. Формализированная модель гдето должна быть, не искал...

BAN
()
Ответ на: комментарий от BAN

> раздутое ядро стоновится всё сложнее, медление, и сложнее в поддержке.

Будет Dfly поддерживать столько же платформ и железа, сколько Линукс - посмотрим, чем она станет. Но она не будет.

>> В модели "нить на устройство" нет ничего сложного, так что много платить не придется.

> Там за 20 лет таких "много платить не придётся" знаеш сколько по "ничего сложного" накопилось?

Ну ты и дремучий. За какие 20 лет? Даже кода от 2.2 осталось мало. Ядро переписали уже несколько раз.

> Формализированная модель гдето должна быть, не искал...

Ну так и не говори умных слов, пока не найдешь ее.

tailgunner ★★★★★
()
Ответ на: комментарий от GNUFun

>Данный проэкт, ЕДИНСТВЕННАЯ за всю историю юникс попытка изменить архитектуру мат-модели ядра, и добавить асинхронность работы на MP системы, что _должно_ значительно упростить развитие _другой_ юникс в будущем, когда неокласические ядра достигнут заката, а микроядра так создать и не получится...

http://ru.wikipedia.org/wiki/Plan_9

?

jackill ★★★★★
()
Ответ на: комментарий от tailgunner

>Будет Dfly поддерживать столько же платформ и железа, сколько Линукс - посмотрим, чем она станет. Но она не будет.

Разработчики говорят что стараются писать архитектурно независемый код.

>> Там за 20 лет таких "много платить не придётся" знаеш сколько по "ничего сложного" накопилось?

>Ну ты и дремучий. За какие 20 лет? Даже кода от 2.2 осталось мало. Ядро переписали уже несколько раз.

Да, они стараются чистить, переписывают, но речь об архитектуре ядра Линукс которая приводит к его черезмерному росту, особенно это касается ветки 2.6, тоже относится ко всем монолитным ядрам кроме Dfly, где благодаря новой архитектуры ядра его роста при добавлении очень сложных вещей таких как виртуализация, SSI кластер роста не происходит.

>Ну так и не говори умных слов, пока не найдешь ее.

Здесь уже давали основы архитектуры на русском, мало? Хочешь стать разработчиком? Да напиши им в рассылку кинут тебе ссылку на непонятный талмуд на англицком, у них терменология специфическая, трудно привыкнуть...

BAN
()
Ответ на: комментарий от jackill

>>Данный проэкт, ЕДИНСТВЕННАЯ за всю историю юникс попытка изменить архитектуру мат-модели ядра, и добавить асинхронность работы на MP системы, что _должно_ значительно упростить развитие _другой_ юникс в будущем, когда неокласические ядра достигнут заката, а микроядра так создать и не получится...

>http://ru.wikipedia.org/wiki/Plan_9

>?

Оно lwkt?

Я слышал о распределённости plan9 но помоему оно не то. Dfly вполне может жить и на одном проце и на оюной машине, и только по спец требованиям вычеслительных мощьностей, становится SSI кластером.

BAN
()
Ответ на: комментарий от BAN

> архитектурно независемый

> знаеш

> где благодаря новой архитектуры ядра

> терменология

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

> ссылку на непонятный талмуд на англицком

Лучше бы тебе кто дал ссылку на букварь. И далее по цепочке.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

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

Две архитектуры, просто для amd64 нет прекомпиленых пакетов. Да драйверов там мало. Но здесь я не об этом, а атом что есть другая монолитная модель ядер юниксов где поддержка не будет сложнее микроядер и кто знает может работа в этом направлении очень пригодится, когда ядро Линукса и фри непомерно раздуется, а микроядра неуспеют появится...

>что в нём нельзя поставить спеллчекер?

Я в Линуксе!

BAN
()
Ответ на: комментарий от BAN

> когда ядро Линукса и фри непомерно раздуется, а микроядра неуспеют появится

Интересно, у тех кто говорит о раздутии ядра есть реальные данные кроме размера тарболла исходников. Ядро линукса состоит чуть менее чем полностью из драйверов. А сам кёрнел слабо распухал со времён 2.0.

> Я в Линуксе!

Не оправдание.

Интересно, что это за новый вид специальной олимпиады — BSD пухлотроллинг?

PolarFox ★★★★★
()
Ответ на: комментарий от GNUFun

> С микроядрами есть проблема в самой их мат-модели, ну работали писали но пока не получается..

чего именно не получается? L4 есть, есть NewOS, Minix, вот на BitC уже который год грозятся чего-то там всем показать..

>Данный проэкт, ЕДИНСТВЕННАЯ за всю историю юникс попытка изменить архитектуру мат-модели ядра,


ЕДИНСТВЕННАЯ? вряд ли.
И кстати, define "мат-модель ядра". Чего там математического в этой модели.

> добавить асинхронность работы на MP системы


какой в этом особый смысл без асинхронности работы самого железа? Вот в Amiga была "аппаратная многозадачность", один custom chip для звука, один copper chip для видео процессора, DMA везде, а CPU оставалось только задания раздавать на custom chip'ы. Да и то, железо было не асинхронное.

или это такое обобщение BeOS-ной концепции pervasive multithreading? Так вот в Snow Leopard Grand Central Dispatch симпатичнее реализован. Откуда мне знать, на сколько нитей приложение разбивать оптимально будет, если это зависит а) от железа, количества ядер CPU или GPGPU б) от текущей загрузки задач -- пусть у ОС голова с планировщиком болит, а мы тут просто замыкания в Си добавим (blocks) и их из системного планировщика вызывать будем.

Всё довольно-таки user level, зачем это в ядро пихать?

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


да получилось, есть оне уже, попуститесь: L4, NewOS, Minix, тысячи их.. а про "закат неоклассических ядер вручную" -- хотелось бы поподробнее. Мичуринский яббл добавляет в снежный песец замыкания в Си и LLVM, и на тебе -- +50% производительности. БеОС с гайками (ведро с болтами, гы-гы) вставляет "всеобъемлющую многопоточность" куда надо и не надо (у них кстати, микроядро NewOS.. и да, интересно, чем концепция LWKT *НЕ* ложится на гайкино микроядро + серверы в отдельных нитках) -- и тоже вполне себе работают..
Чем лучше стрекозиный подход, когда всё то же самое можно сделать и в user level (Snow "Песец" Leopard's GCD) или микроядро+нитки (Haiku NewOS + app_server + *server ) ?

anonymous
()
Ответ на: комментарий от PolarFox

>Интересно, у тех кто говорит о раздутии ядра есть реальные данные кроме размера тарболла исходников. Ядро линукса состоит чуть менее чем полностью из драйверов. А сам кёрнел слабо распухал со времён 2.0.

code swarm посмотрел? как именно и где он там распухал? стало больше подсистем, связей между подсистемами -- всяких разных, а не в одну сторону, как с драйверами

anonymous
()
Ответ на: комментарий от BAN

ядро Plan 9, ЕМНИП, обычный монолит без претензий на микроядерность. Однако, количество сисколлов резко уменьшено, есть стандартный "файловый" (а точнее, универсальный запроса ресурсов) протокол Styx, прозрачный по сети, свой сетевой слой TCP/IL. Концепция пространств имён личных у каждой программы, и унифицированной организации ресурсов в пространство имён (ресурс = файл, устройство, сокет, клиент-серверный ресурс для запроса у другой программы, и т.п.). Концепция виртуальных программных и реальных аппаратных ресурсов. ОС выступает просто мультиплексором, отображая ресурсы виртуальные на реальные, а пространство имён именует их таким унифицированным способом. Хотя есть соображения, что само ядро "почти реального времени", никто его реально не измерял и не сертифицировал. На тему распределённости есть реализации GRID на Plan9 или Inferno, которые тривиальны в силу простоты реализации сетевых сервисов на этих ОС, и прозрачности протокола Styx.

Возьмём идею "ОС как мультиплексора нескольких аппаратных в один виртуальный" ресурс, доведём до абсурда-экстремума (когда даже реализация "ресурсов" (то есть, и "сисколлов") "ядру" не известна, и сидит в отдельной библиотеке (API реализации ресурсов уходят в библиотеку, но API распределения-мультиплексирования абстрактных, произвольных (не зависящих от их API) ресурсов) -- и получим экзоядро с LibOS. Заметь, нет особого "протокола ресурсов", а есть API-интерфейс "экзоядра" с той же целью.

anonymous
()
Ответ на: комментарий от anonymous

> стало больше подсистем, связей между подсистемами -- всяких разных, а не в одну сторону, как с драйверами

Вы так говорите, будто это что-то плохое.

Но тем не менее Linux лучшее открытое ядро на текущий момент. В FreeBSD похуже с железом.

PolarFox ★★★★★
()
Ответ на: комментарий от BAN

> Оно lwkt?

Как бы не понимаю самоценности lwkt. Это как в лисп-системе, реализация может поддерживать native threads, а может и не поддерживать, и тогда придётся эмулировать многопоточность продолжениями и замыканиями. Не факт, что на продолжениях хуже получится.
Вдруг ВНЕЗАПНО допилят BitC или MacOSX ядро перепишут с блоками и GCD, что тогда будет со стрекозой?
МОНОЛИТ НИНУЖЫН, адынадынадын ??

anonymous
()
Ответ на: комментарий от PolarFox

> Вы так говорите, будто это что-то плохое.

всяких-разных связей -- да, именно - плохое. Целью микроядер является не размер, а модульность, чёткая конкретизация интерфейсов API и -- отсутствие лишних связей, а следовательно, и ненужного роста сложности.

>Но тем не менее Linux лучшее открытое ядро на текущий момент

кто б спорил. Под остальные ядра тупо может не быть такой массы драйверов.

anonymous
()
Ответ на: комментарий от anonymous

> Вдруг ВНЕЗАПНО допилят BitC

Не допилят. Шапиро профейлил еще один проект %)

tailgunner ★★★★★
()
Ответ на: комментарий от PolarFox

>Но тем не менее Linux лучшее открытое ядро на текущий момент.

Linux — самое дырявое ведро на текущий момент.

Fixed.

>В FreeBSD похуже с железом.


В каком месте?

iZEN ★★★★★
()
Ответ на: комментарий от Led

>Да, практически, в любом

Пруфлинк?

Ctrl+Alt+F2 на линаксе в большинстве случаев вызывает зависание X'ов.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

>Ctrl+Alt+F2 на линаксе в большинстве случаев вызывает зависание X'ов.

Лузер - это судьба

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

> всяких-разных связей -- да, именно - плохое. Целью микроядер является не размер, а модульность, чёткая конкретизация интерфейсов API и -- отсутствие лишних связей, а следовательно, и ненужного роста сложности.

А Линус (или не он) наоборот писал, что за кажущейся простотой отдельных компонентов микроядра скрывается более трудное отслеживание этих самых связей между компонентами (общая структура ядро<->модули сложнее чем просто ядро в случае монолита)

Так что микроядро не панацея.

PolarFox ★★★★★
()
Ответ на: комментарий от iZEN

> Linux — самое дырявое ведро на текущий момент.

То что в FreeBSD никому не сдалось искать дырки не значит что их нет. Принцип неуловимого Джо, которым раньше рулил линукс.

> В каком месте?

Ну например моя замечательно работающая видеокарточка под фрибсд работает только в vesa. Или например вебкамера. И вайфай интеловский не запахал. Сужу по PC-BSD прошлогодней.

В позапрошлогодней убунте всё работало.

PolarFox ★★★★★
()
Ответ на: комментарий от anonymous

>чего именно не получается? L4 есть, есть NewOS, Minix, вот на BitC уже который год грозятся чего-то там всем показать..

У них есть система "напосмотреть", а стрекоза вылезана уже до уровня садись и работай, хоть в десктопе хоть на серваре, хоть на кластере.

>>Данный проэкт, ЕДИНСТВЕННАЯ за всю историю юникс попытка изменить архитектуру мат-модели ядра,

>ЕДИНСТВЕННАЯ? вряд ли. >И кстати, define "мат-модель ядра". Чего там математического в этой модели.

История дела такая, в Линукс 2.4 и BSD 4.8 можно было относительно просто добавлять в ядро и поддерживать сложный функционал. В Линуксе 2.6 и фри 5 уже это стало для сообщества неподёмно сложной задачей.

Стрекоза спроектирована на другой архитектуре (прозваной LWKT) как монолитное ядро с целью сделать очень простой реализацию и поддержку следующих вещей:

1. SMP многопроцесорную поддержку, полностью асинхронно все процессы и даже девайсы.

2. SSI кластер единого системного образа

3. виртуализацию

Тоесть модель стрекозы изначально спроэктирована так что как минимум три выше перечисленные задачи реализуются очень просто...

>какой в этом особый смысл без асинхронности работы самого железа?

I/O девайсов в стрекозе асенхронен.

>или это такое обобщение BeOS-ной концепции pervasive multithreading? Так вот в Snow Leopard Grand Central Dispatch симпатичнее реализован. Откуда мне знать, на сколько нитей приложение разбивать оптимально будет, если это зависит а) от железа, количества ядер CPU или GPGPU б) от текущей загрузки задач -- пусть у ОС голова с планировщиком болит, а мы тут просто замыкания в Си добавим (blocks) и их из системного планировщика вызывать будем.

Да асинхронность похожа до БиОС и Гейки... Планировщик LWKT решает проблему управления нитями более эфективно и без блокировок чем другие, особенно планировщики неокласических ядер..

>Всё довольно-таки user level, зачем это в ядро пихать?

В стрекозе изначально ядро минимально и всё по максимуму выносится в пользовательский режим, оно не есть много больше микроядер и разработчики говорят что будут стараться втиснуть его в 500 000 строк кода. Но ядро там хитрое оно может запускатся как процес планировщиком LWKT на каждом процесоре системы уже в пользовательском режиме...

>да получилось, есть оне уже, попуститесь: L4, NewOS, Minix, тысячи их.. а про "закат неоклассических ядер вручную" -- хотелось бы поподробнее. Мичуринский яббл добавляет в снежный песец замыкания в Си и LLVM, и на тебе -- +50% производительности. БеОС с гайками (ведро с болтами, гы-гы) вставляет "всеобъемлющую многопоточность" куда надо и не надо (у них кстати, микроядро NewOS.. и да, интересно, чем концепция LWKT *НЕ* ложится на гайкино микроядро + серверы в отдельных нитках) -- и тоже вполне себе работают.. Чем лучше стрекозиный подход, когда всё то же самое можно сделать и в user level (Snow "Песец" Leopard's GCD) или микроядро+нитки (Haiku NewOS + app_server + *server ) ?

Выше я описал основные идеи и преимущества стрекози -- просто делать то что в других моделях получается очень сложно.

Линус Торвальдс и другие, подробно разбирали модель LWKT и сказали что "это другой уровень математической абстракции и формальзации использование которого не есть очевидно в плане простоты кода и быстродействию асинхронной системы" ищите статьи за ...2003-2004... годы, рассылки ядерщиков...

BAN
()
Ответ на: комментарий от BAN

> Но ядро там хитрое оно может запускатся как процес планировщиком LWKT на каждом процесоре системы уже в пользовательском режиме..

Это здорово.. А можно сделать такой финт: берём драйвер (как модуль ядра), составляем по нему модель (DSL) в терминах API ядра, описываем API ядра в терминах ресурсов, абстракций и мат. модели этого API (другой DSL), отображаем DSL1 в DSL2. Если мат. модель и DSL2 достаточно удобно подобраны, такой транслятор из DSL1 через DSL2 в другой DSL1-1 (с другим API, другой мат. модели) может быть довольно простым. В итоге получаем автоматически сгенерированный драйвер в терминах другого API. А из возможности вынести модуль ядра в пользовательский режим и обратно следует простая возможность юнит-тестов для такого транслятора.

PolarFox> А Линус (или не он) наоборот писал, что за кажущейся простотой отдельных компонентов микроядра скрывается более трудное отслеживание этих самых связей между компонентами (общая структура ядро<->модули сложнее чем просто ядро в случае монолита)

ну да. Возьми например runtime ObjectiveC. Он простой как палка, но позволяет вещи вроде proxy class, override superclass, протоколы и категории. Которые не так просты, как в C++ RTTI, API классов и интерфейсов. Некоторые даже говорят "Objective-C considered harmful", но это просто более гибкий runtime, который надо больше ограничивать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.