Pull to refresh

Comments 19

занятно.
в моей ОСи примерно такая же система взаимодействия.
хотя с другой стороны, она же тоже микроядерная, так что сложно было что-то новое придумать.
PS: скоро планирую написать статью как раз про создание собственного линкера, код у меня уже есть, но надо всё в кучу собрать.
Было бы интересно почитать, как раз сейчас копаюсь в структуре объектников и, в частности, в вопросах линковки.

А что у Вас за ось, если не секрет? Можно ссылку?
> Было бы интересно почитать, как раз сейчас копаюсь в структуре объектников и, в частности, в вопросах линковки.

на этой неделе выложу статью. линкер в принципе модульный. Достаточно имплементировать интерфейс входного формата (у меня пока только COFF + зачатки ELF Relocable) и/или выходного (сейчас бинарный и своего собственного формата).

> А что у Вас за ось, если не секрет? Можно ссылку?
Пока она сугубо у меня на локалхосте, линкер — часть цикла о написании этой ОСи (причём, как ни странно — первая :) ). Собственно начав цикл и опишу эту ОСь.
Кстати, а Ваш подход весьма не плох. Не хочу пугать, говоря, что написание ОС — титанический труд, но написание своего линкера — это очень хороший ход. Я без иронии — сам мечтаю о линкёре, который бы мог бы связывать объектные файлы, созданные разными компиляторами, в пределах одной архитектуры. Например, слинковать объектные файлы, созаднные gcc и MS Visual C++. А если бы ещё ключиком можно было указать тип исполняемого формата, например Elf или PE, то этому линкёру цены бы не было.

Я не знаю, напишите ли Вы свою ОС или нет, но знайте, что есть люди, которым интересен Ваш линкер. Удачи в осуществлении задуманного!

Эцсамое, под «архитектурой» обычно понимается именно архитектура процессора — i686, x86_64, arm, mips. В результате выражения типа «объектный файл необходимо связать (сликновать) с библиотечными функциями требуемой архитектуры» и «исполняемый файл для родной архитектуры, на которой установлен компилятор. В моём случае — Slackware Linux» порядком рвут шаблон и заставляют задуматься о том, что же такое курил автор.
Спасибо за справедливое замечание. Ночь, усталость, спешка — получаются такие ляпы. Впредь буду внимателен к терминам, а статью исправлю, как только наберусь сил и приведу мысли в порядок.
Вероятно, вам будет интересно «пощупать» свежую версию Инстрментария разработчика системы Xameleon.

l4os.ru/license
Исходный код системы и/или её подсистем, если это не оговорено отдельно, не распространяется и является собственностью их разработчиков.


Спасибо, не интересно.
Спасибо за комментарий. Не желаю, чтобы в этой теме «светились» минусы за комментарии — каждый имеет право на своё мнение.

Хотелось бы задать вопрос, а для чего Вам лично нужен исходный код? Исходный код какого модуля/сервиса Вам интересен?

В нашем проекте пока (слава Богу) нет лойеров, поэтому лицензии пишем сами как умеем. Вот, к примеру, продукт, который распространяется в исходном коде. Его лицензия проста:

Приобретая продукт, Вы имеете право:

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

Вы не имеете право:

распространять исходные тексты продукта.


Пусть это называется «лицензия Хамелеон».

Что касается цитаты «собственность разработчиков», то наша команда готова предоставить разработчикам необходимые инструменты, а также мы готовы продвигать решения сторонних разработчиков для системы Хамелеон. Для этого случая и существует оговорка — «код принадлежит его разработчику». Т.е. если, не дай Бог, возникнут какие-либо разногласия, то автор кода вправе требовать не использовать его в проекте.
Хотелось бы задать вопрос, а для чего Вам лично нужен исходный код? Исходный код какого модуля/сервиса Вам интересен?

Для удовлетворения собственного любопытства, разумеется. Читать, изучать, отлаживать, взламывать, улучшать, специализировать, генерализировать и т.д. Код — не роскошь.
Это вдвойне странно, учитывая что есть другие реализации L4, открытые и свободные, взгляните на эту табличку.

Его лицензия проста:

Приобретая продукт, Вы имеете право:

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

Вы не имеете право:

распространять исходные тексты продукта.

Его лицензия противоречива: я встрою сервис в виде исходного кода в свой пакет и буду распространять исходные коды своего пакета. Зачем вы изобретаете велосипед на ровном месте?
Закрадывается подозрение что и в исходном коде вашего продукта водятся подобные велосипеды.

если, не дай Бог, возникнут какие-либо разногласия, то автор кода вправе требовать не использовать его в проекте.

И что, будете изымать этот код из проданных экземпляров? (:
Простите, кажется уже второй раз отвечаю мимо комментария — не со злым умыслом, а по спешке и невнимательности. Мне, право, неудобно за свою неуклюжесть.

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

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

Это вдвойне странно, учитывая что есть другие реализации L4, открытые и свободные, взгляните на эту табличку.

Дык, Хамелеон построен сверху Pistachio, а Pistachio распространяется под Two Clause BSD license. Но я Вам так скажу, насколько бы прекрасно не было Pistachio (а это микроядро прекрасно), его спецификация ещё лучше: www.l4ka.org/l4ka/l4-x2-r7.pdf — это одна из лучших спецификаций, с которыми мне приходилось сталкиваться за всю карьеру разработчика.
И вот под какой лицензией она распространяется:

Permission to copy and distribute verbatim copies of this specification in any medium for any purpose without fee or royalty is hereby granted. No right to
create modifications or derivates is granted by this license. The L4Ka Team may make changes to this specification at any time, without notice. The latest
revision of this document is available at l4ka.org/.

No modifications nor derivates

Его лицензия противоречива: я встрою сервис в виде исходного кода в свой пакет и буду распространять исходные коды своего пакета. Зачем вы изобретаете велосипед на ровном месте?

Легко. Вы можете встраивать сервис под любой лицензией, если она прямо не запрещает использовать продукт совместно с Хамелеоном. Хоть под MS EULA, если EULA этого не запрещает.

Закрадывается подозрение что и в исходном коде вашего продукта водятся подобные велосипеды.

Хмм. Ядро (которое поверх микроядра и ниже userspace) уже превысило 100 тыс. строк. Вероятно, там есть и велосипеды, и баги, и светлые идеи, а также максимально оптимизированные места соседствуют с кодом, написанным «на авось» и «потом переделаю». Меня радует уже то, что когда писал libc, хватило ума не изобретать велосипед, а обратиться к стандарту POSIX. Т.ч. насчёт велосипедов — я не согласен.

Помимо этого Хамелеон использует несколько оригинальных алгоритмов, которые назвать велосипедом — язык не поворачивается. Например, L4 позволяет аллокировать страницы виртуальной памяти с размером, отличным от размера страниц поддерживаемым архитектурой процессора. Грех было этим не воспользоваться и не написать свою реализацию работы с памятью. Насколько я знаком со внутренней архитектурой Linux и Windows, они используют другие принципы работы с виртуальной памятью.

И что, будете изымать этот код из проданных экземпляров? (:

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

Наконец, используя API, предоставляемое Хамелеоном, Вы можете распространять модули без исходного кода. Например, Вы разработали драйвер звуковой карты и согласовали с нами его системные вызовы. Мы можем договориться о включении этого драйвера в систему даже без исходного кода. Т.е. Ваши идеи и наработки останутся Вашими и если в какой-то момент Вам покажется, что сотрудничество не выгодно, или другой разработчик предложит Вам более выгодные условия, взамен потребовав убрать код из других систем, то сможете это сделать просто известив нас об этом. Что касается протокола взаимодействия с Вашим драйвером, то тут всё сложнее — мы не заинтересованы в потере протоколов. Даже не знаю, как быть в такой случае.

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

Довольно эмоциональный пассаж, призванный как бы разжалобить читающего/будущего покупателя. Кстати, между «чтобы» и «мог» пропущено местоимение «я». Как бы это помягче сказать… Это ваше личное дело, как вы разрабатываете — молитесь ли вы на код, приносите ли вы ему человеческие жертвы, делаете ли вы на него ставки, света белого не видите, или как-либо ещё. Ничто из этого не сделает плохой код лучше, а хороший код не испортит.

Дальше, выделение в цитате — моё.
[...]
его спецификация ещё лучше
[...]
И вот под какой лицензией она распространяется:

Permission to copy and distribute verbatim copies of this specification in any medium for any purpose without fee or royalty is hereby granted. No right to
create modifications or derivates is granted by this license. The L4Ka Team may make changes to this specification at any time, without notice. The latest
revision of this document is available at l4ka.org/.


Во-первых это спецификация и она открытая. Да, она не полностью свободная. Код — полностью свободный. Согласитесь, большая разница с тем что предлагаете вы.

Вообще, идея, которую я хотел донести с самого начала состоит в том, что закрытость проекта — неслабый отталкивающий фактор для некоторых разработчиков.
Тот самый. Уважаемый gribozavr не затрудняясь сломал сервер и вытянул его исходный код. В приватном сообщении он рассказал, каким образом удалось сломать — я ему очень за это благодарен — мне урок, ему почёт и уважение.

Таки мне есть чем возразить на велосипед с квадратными колёсами. Много Вы знаете FTP серверов для POSIX систем, не использующих функцию select()?

Появление этого «велосипеда с квадратными колёсами» объяснить очень просто — мне было необходимо отлаживать TCP/IP стек, а для такой задача FTP протокол подходит как нельзя лучше — во первых, протокол подразумевает как исходящие, так и входящие TCP соединения, во вторых, можно передавать большие объёмы информации в обе стороны. Лучшего теста для TCP/IP стека не придумаешь. При том, что существуют десятки, если не сотни, FTP клиентов для различных платформ. Можно ли придумать лучший тест? И это с учётом того, что мой велосипед «заточен» именно под отладку TCP/IP стека — пишет тонны отладочной информации в stdout и stderr.
Т.ч. я бы не был на Вашем месте столь категоричен. :)

Много Вы знаете FTP серверов для POSIX систем, не использующих функцию select()?

Студенческая лаба? Из серьёзных — ни одного не знаю.
А в чём особенная доблесть использования/не использования select?
С функцией sеlect очень удобно писать сетевые программы. Многие вещи упрощаются — из одного процесса и потока можно обслуживать несколько сокетов. Например, классический FTP сервер форкается при каждом новом соединении, при этом управляющий канал и канал данных обслуживаются через select — всё красиво и просто. Что даёт? Например, при посылке или приёме большого файла, вы можете послать по управляющему каналу команду ABORT.

Неиспользование select, это не доблесть, а ограничение — в Хамелеоне не реализован системный вызов select — ни в сетевой подсистеме, ни в файловой. Он поэтому и не реализован, потому что по стандарту этот системный вызов может принимать как дескрипторы файлов, так и дескрипторы сокетов, но вот беда — в отличие от монолитных, в микроядерных системах сетевой сервис и файловый сервис могут быть совершенно разными независимыми процессами. Более того, в какой либо конфигурации может не быть сетевой системы, а в другой конфигурации может не быть файловой. По логике — нужно писать отдельный диспетчер для select и других вызовов, с другой стороны не хочется плодить лишние сущности. И пока чаша весом не перевесила ни в одну сторону, было сказано: «Хрен с ним, пусть пока работает без select».

Он поэтому и не реализован, потому что по стандарту этот системный вызов может принимать как дескрипторы файлов, так и дескрипторы сокетов, но вот беда — в отличие от монолитных, в микроядерных системах сетевой сервис и файловый сервис могут быть совершенно разными независимыми процессами

Мне кажется, что в select редко складывают разнородные дескрипторы, а в тех случаях когда это делают, код понятным образом можно разделить на два потока, обрабатывающих дескрипторы разных классов. Более «ровным», на мой поверхностный, без знания внутренностей взгляд, решением было бы реализовать select и там и там, и ругаться когда в него передаётся смешанный набор дескрипторов.
Спасибо. Я тоже склоняюсь к такому мнению. Тем более, если будет реализация select в двух местах, то при необходимости не составит особо труда написать обвязку для смешивания.

Пожалуй, мне понадобится некоторое время на реализацию хотя бы в сетевом сервисе.
Sign up to leave a comment.

Articles