Неудобно писать в личку, надеюсь коллеги меня простят. Юрий, хочу выразить благодарность за TNKernel, недавно начал пользовать, очень удобно, все нравится. Но возникли пара вопросов.. Первый такой - в tn_event_clear маской задается именно флаги которые НЕ надо очищать. Это вызвано какими-то особыми соображениями или это кажется нелогичным только мне ?
А второй такой. Очень удобно для синхронизации двух потоков использовать tn_queue_send/receive. Часто параметр data_ptr просто не нужен. Однако если send позволяет использовать NULL, то receive - нет. По-моему тоже нелогично. Или я не прав ? Конечно, все это можно поправить "для себя"... но я пока особого опыта работы со встроенными операционками не имею, только с виндой немного, поэтому и спрашиваю. Заранее спасибо !

хоть и не автор, но отвечу

>> Первый такой - в tn_event_clear маской задается именно флаги
>> которые НЕ надо очищать. Это вызвано какими-то особыми
>> соображениями или это кажется нелогичным только мне ?

я думаю особых соображений там нет:



мне это вобщем тоже показалось нелогичным, но когда портировал на PIC24, просто решил не менять API
По поводу очередей - в принципе тоже реализуемо - закомментировть проверку указателя на NULL в tn_queue_receive() и dque_fifo_read() и соответственно не сохранять указатель из FIFO по указателю в NULL.

Дмитрий сам же наверное уже все посмотрел =) Вот честно, по времени больше думал, стоит ли так сильно коцать исходники, чем собственно портировал. Решил что стоит =) http://www.pic24.ru/tnkernel.htm

ИМХО:
Это не порт, а отдельная ветка, причем не совместимая по структуре и API -- эксклюзив, можно и имя поменять --TNKernel-PIC24
- если что-то будет изменено в настоящем ядре TNKernel -- придется ветку снова перепахивать руками
- если в системе есть что-то не на PIC24(а на ARM), то придется сопровождать ДВЕ операционки... да и не будет никто такого делать, зачем такая операционка, которая на каждое семейство имеет самостоятельную реализацию...

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

Для 'маленьких' операционок приходится, поскольку практически неизбежно просматриваются определенные варианты использования и вкусовые предпочтения Автора (причем приставать к Автору со "со своим уставом", как минимум не корректно, а как максимум бесполезно). Да и качественные порты обычно ограничиваются несколькими контроллерами - остальные или "для галочки" или сделаны пользователями с очень разной степенью квалификации . Ну а для"воспользоваться наработками" из основной ветки - надо использовать контроль версий, это без вариантов.

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




Это почему же? Какая религия этого не приветствует?

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

Коллективная работа - великая вещь .

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

А зачем, простите, ВСЕ ломать? У меня, например, во FreeRTOS (сейчас глянул) 72 места правок полностью другой менеджер памяти и еще своих три файла. Кое-что для совместимости с первоисточником макросами прикрыто. Комментарии присутствуют. Синхронизация c основной веткой занимает обычно считанные минуты.

А остальное . Кроме того, поминалось коллективное обсуждение - для многих проектов колектива нет - есть Автор и все. Автор волен поступать, так, как ему видится правильным. Реакция на замечания из вне обычно очень благожелательная при указании на найденные ошибки и очень сдержанная на предлагаемые изменения в поведении системы. Реакция на изменения в, например, API скорее всего категорически отрицательная.

>> Это не порт, а отдельная ветка, причем не совместимая
>> по структуре и API

изменения в API там совсем незначительные. Сервисов вообще не касаются. Все изменения были сделаны из личных соображений - ну не хочу я использовать зарезервированные имена функций для инициализации системы. Не хочу чтобы память под стеки служебных задач выделялась при компиляции ядра или использовать в ядре динамическое выделение памяти.
Вообще API изменен только для двух функций (и то - передаваемые параметры).

Структура, ну что структура... я прекрасно понимаю, что придется делать при выпуске Юрием нового релиза. Я ж говорю - долго думал и в итоге решил делать по своему. Навязывать что-то свое автору совсем не хочется. zltigo очень правильно обозначил как авторы реагируют на замечания и просьбы.

Ну а для пример - есть проект на LPC2148 - свой код под RealView я портировал за полчаса, потому что все компиляторо/железо зависимые вещи четко обозначены. С родным кодом пришлось повозиться.

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

Следует отметить, что все мной сказанное не имеет никакого конкретного отношения к Юрию.

Это его личное мнение, как я себе понимаю, и не известно имеется ли практическое подтеждение. Принимать его на веру не следует. Моя практика другая - авторы открытых проектов идут на контакт с пользователями.

Прежде всего - спасибо всем вам за интерес к TNKernel. Всегда приятно,
когда работа находит отклик у других людей...

По поводу Event mask - такой подход только потому, что я следовал
спецификации uITRON 4.0 буквально, а в uITRON сделанно именно
так.
По поводу tn_queue_send/receive - если через очередь не надо передавать
данные(data_ptr не используется), то, IMHO, для синхронизации лучше
использовать семафор - меньше ресурсов занимает, быстрее работает.

Что же касается создания субверсий и изменений/добавлений - то лично
я это только приветствую. Единственно, что следует помнить - нужны
многочисленные и разнообразные тесты (без надлежащего тестирования то,
что работает в одном проекте, в другом может не работать).

О, понял. Спасибо. По первому так и думал честно говоря. А по второму.. Мне надо было так. Один поток ждет события. Другой его ставит. Но были опасения, что между временем пробуждения первого потока и очисткой event им же через tn_event_clear второй поток может опять выставить этот же event повторно - и тогда этот второй "запрос" будет очищен без обработки. Попробовал очередь - тогда второй поток не сможет выставить флаг для первого, пока первый не обработает запрос, т.е. то, что и нужно. Но потом вспомнил, что event можно использовать с автосбросом - думаю это оптимальный выход..