k@sTIg@r
В системе есть отладочная доска (Board) куда любое приложение может выводить сообщение, по сути общий stdout.
>- как быть с приложениями запущеными обычным способом(то есть без потоков), а именно поведение функций 3 и 4
Обычно приложение само запрашивает дескрипторы стандартных потоков у ядра, этим занимается стартап-код.
В принципе дескрипторы потоков можно сделать и в Колибри все необходимое для этого в ядре уже есть. Возможно надо модифицировать функцию запуска приложения
Консоль
Ну отладочная доска на крайний случай для stderr подойдет. Мне вообще странно такое недопонимание потоков (stdin, stdout, stderr) и консоли в системе. Все эти особенности нужно было учитывать еще при проектировании системы, по сути системы именно с таких интерфейсов и начинаются. Конечно, кому то он не нужен, и ктото может сразу перейти к работе с гр. интерфейсом, но вот объясните, как вы будите организовывать сборку и тестирование приложения когда требуется:
Да и как выполнять подобное и выводить на единственную консоль:
Я этот вопрос тоже планирую решать, но видимо по своему.
..bw
- Компиляция.
- Линковка.
- Конвертирование формата.
- Создание образа.
- Перенос полученного кода на образ.
- Запуск эмулятора с монтированным образом.
Да и как выполнять подобное и выводить на единственную консоль:
- ps -A | grep nginx
- ls | more
Я этот вопрос тоже планирую решать, но видимо по своему.
..bw
Не совсем понял цели размещения предыдущего поста... Никто ведь не спорит, что консоль нужна. Вот её и пишут потихоньку. А до сих пор не написали, потому что у всех, кто может такое написать, очень мало времени.
Ку.
p.s. Да и не все согласны. Я решил что не стоит вывешивать список тех кто поддерживает идею и тех кто нет, а просто высказал свое мнение в адрес тех кто отрицательно смотрит на совершение подобной работы.
..bw
p.s. Да и не все согласны. Я решил что не стоит вывешивать список тех кто поддерживает идею и тех кто нет, а просто высказал свое мнение в адрес тех кто отрицательно смотрит на совершение подобной работы.
..bw
bw
>Все эти особенности нужно было учитывать еще при проектировании системы
Тот кто придумал систему давно на неё забил и делает другую. А проектирования и в помине не было.
И это не наша идеология. Если можешь написать потоки для ядра - сделай это. Это идеология.
>Все эти особенности нужно было учитывать еще при проектировании системы
Тот кто придумал систему давно на неё забил и делает другую. А проектирования и в помине не было.
И это не наша идеология. Если можешь написать потоки для ядра - сделай это. Это идеология.
Согласен, но что теперь поделаешь... это тяжелое наследие Menuet. У меня по этому поводу был один вопрос к разработчикам Kolibri, но я его не стал задавать раньше и теперь задавать не буду.Все эти особенности нужно было учитывать еще при проектировании системы, по сути системы именно с таких интерфейсов и начинаются.
Обещанный ввод. Функции con_getch (аналог _getch()) и con_gets (аналог fgets(...,stdin)). Ссылка та же: http://diamondz.land.ru/console.7z
...а также con_kbhit для проверки существования введённой клавиши. Кстати, изменять программы, рассчитанные на версию 2 библиотеки (входящую в дистрибутив), не нужно.
Хочу попробовать реализовать одну идейку по поддержке консоли. Если кто видит в этом что-то нереализуемое или вовсе неправильное, пишите.
Консольный сервис - функция ядра с несколькими подфункциями создает и управляет буферами stdin/out, которых должно быть несколько (8 например), но для начала 1
На каждый stdin/out могут зарегистрироваться две программы с разными правами. Одна регистрируется как терминал, другая - как консольное приложение.
Терминал имет право получать информацию об активности в stdin/out, читать из stdout и писать в stdin ... . (Механизм ещё полностью не продуман, могут быть логические ошибки).
Консольное приложение получает при запуске параметр с номером stdin/out в котором ее ожидают увидеть. Эти sdtin/out оно и должно открыть соответствующей подфункцией.
(Stdin - только чтение, stdout - только запись. Ну как обычно.)
Функция чтения строки из stdin может работать подобно системной функции ожидания события. Приложения просто "висит" пока в stdin не появится строка (если, конечно, на момент вызова функции чтения stdin был пуст).
Консольный сервис - функция ядра с несколькими подфункциями создает и управляет буферами stdin/out, которых должно быть несколько (8 например), но для начала 1
На каждый stdin/out могут зарегистрироваться две программы с разными правами. Одна регистрируется как терминал, другая - как консольное приложение.
Терминал имет право получать информацию об активности в stdin/out, читать из stdout и писать в stdin ... . (Механизм ещё полностью не продуман, могут быть логические ошибки).
Консольное приложение получает при запуске параметр с номером stdin/out в котором ее ожидают увидеть. Эти sdtin/out оно и должно открыть соответствующей подфункцией.
(Stdin - только чтение, stdout - только запись. Ну как обычно.)
Функция чтения строки из stdin может работать подобно системной функции ожидания события. Приложения просто "висит" пока в stdin не появится строка (если, конечно, на момент вызова функции чтения stdin был пуст).
Igor
А если оно не захочет открывать именно этот sdtin/out или откроет по ошибке другой. Пусть лучше наследует родительские. Для этого можно задействовать биты флагов ф70.7Консольное приложение получает при запуске параметр с номером stdin/out в котором ее ожидают увидеть. Эти sdtin/out оно и должно открыть соответствующей подфункцией
Я сейчас занимаюсь портированием линуховой VFS. Оно за собой тянет и stdin/stdout (не знаю нужен ли stderr). А также pipeFS.
Твоя сисетма, как-то сложновато выглядит, если честно. В линуксе все просто и эффективно.
Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса (исходники открыты + есть 2 неплохие книжки). Также готов поделится знаниями в свободное для меня время!
Но тебя никто не заставляет, ты можешь воплне реализовывать свой способ, может быть он лучше окажется
Твоя сисетма, как-то сложновато выглядит, если честно. В линуксе все просто и эффективно.
Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса (исходники открыты + есть 2 неплохие книжки). Также готов поделится знаниями в свободное для меня время!
Но тебя никто не заставляет, ты можешь воплне реализовывать свой способ, может быть он лучше окажется
О "настоящих" никсовых stdin/stdout речь не шла.
Что касается VFS. Я понимаю её полезность. Но внедрение
такого механизма предусматривает перестройку
половины ядра. Это не только API по работе с файлами.
Сколько времени займет реализация поддержки файлов устройств
и заточка под них соответствующих функций ядра?
Колибри изначально не задумывалась как unix подобная ос.
И не стоит всё радикально менять.
P.S: А может быть стоит... Надо подумать над твоим предложением.
Что касается VFS. Я понимаю её полезность. Но внедрение
такого механизма предусматривает перестройку
половины ядра. Это не только API по работе с файлами.
Сколько времени займет реализация поддержки файлов устройств
и заточка под них соответствующих функций ядра?
Колибри изначально не задумывалась как unix подобная ос.
И не стоит всё радикально менять.
P.S: А может быть стоит... Надо подумать над твоим предложением.
k@sTIg@r
А можно подробнее про VFS, что там будет и как должно работать ?
А можно подробнее про VFS, что там будет и как должно работать ?
Так а никто не собирается превращать колибри в юникс-подобную ось.
Наличие linux-like VFS не делает ее unix-like OS. Так же как и оконный интерфейс не делает ее windows-like OS (ну или macOS-like, кому как нравится).
Да, работы немерянно, тут я соглашусь. Но я думаю оно того стоит.
Да функции ядра тоже изменятся. Сразу нафиг полетят текущие ф-ции работы с файлами (хотя для них можно написать обертки, тока это не эффективно). Появится понятие дескриптора файла (добавится открытие/закрытие файла), писать/читать можно будет только открытые файлы.
Нужно будет поменять ф-ции запуска/остановки приложения. Ф-ция exec уйдет из файловой системы... И т.д. и т.д.
Поддержка файловых у-в? У нас их не много поддерживается Зато абстракция позволит просто добавлять поддержку новых у-в, а так же новых файловых систем. Причем прозрачно для ф-ций ядра. А не так как щас.
В итоге радикально ничего и не поменяется(для пользовательского уровня). Только работа с файловой системой.
Единственное с чем я щас борюсь - это структура VFS. Мне близка корневая структура, как в unix-like осях. Она очень эффективна (кто не юзал тот не поймет). Дисковая структура (как в windows) для меня не эффективна. А в колибри она такова, только диски называются не буквами латинского алфавита, а физическим расположением.
Уже с ребятами был спор по этому поводу. Корневую никто не хочет принимать Но до этого еще далеко, че-нить придумаю.
Наличие linux-like VFS не делает ее unix-like OS. Так же как и оконный интерфейс не делает ее windows-like OS (ну или macOS-like, кому как нравится).
Да, работы немерянно, тут я соглашусь. Но я думаю оно того стоит.
Да функции ядра тоже изменятся. Сразу нафиг полетят текущие ф-ции работы с файлами (хотя для них можно написать обертки, тока это не эффективно). Появится понятие дескриптора файла (добавится открытие/закрытие файла), писать/читать можно будет только открытые файлы.
Нужно будет поменять ф-ции запуска/остановки приложения. Ф-ция exec уйдет из файловой системы... И т.д. и т.д.
Поддержка файловых у-в? У нас их не много поддерживается Зато абстракция позволит просто добавлять поддержку новых у-в, а так же новых файловых систем. Причем прозрачно для ф-ций ядра. А не так как щас.
В итоге радикально ничего и не поменяется(для пользовательского уровня). Только работа с файловой системой.
Единственное с чем я щас борюсь - это структура VFS. Мне близка корневая структура, как в unix-like осях. Она очень эффективна (кто не юзал тот не поймет). Дисковая структура (как в windows) для меня не эффективна. А в колибри она такова, только диски называются не буквами латинского алфавита, а физическим расположением.
Уже с ребятами был спор по этому поводу. Корневую никто не хочет принимать Но до этого еще далеко, че-нить придумаю.
<k@sTIg@r> Мне близка корневая структура, как в unix-like осях.
Мне тоже близка. Но привыкших к Windows пользователей она почему-то сильно напрягает.
<k@sTIg@r> Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса...
На сколько я понимаю, BSD тоже пойдет. В плане VFS больших отличий от Linux-а быть
не должно. Просто у меня на компе FreeBSD, так сказать всегда под руками.
Короче, могу помочь, если смогу. Заодно вопрос с консолью как-нибудь решим.
Мне тоже близка. Но привыкших к Windows пользователей она почему-то сильно напрягает.
<k@sTIg@r> Если хочешь, присоединяйся ко мне. Но придется подучить ядро линукса...
На сколько я понимаю, BSD тоже пойдет. В плане VFS больших отличий от Linux-а быть
не должно. Просто у меня на компе FreeBSD, так сказать всегда под руками.
Короче, могу помочь, если смогу. Заодно вопрос с консолью как-нибудь решим.
Who is online
Users browsing this forum: No registered users and 0 guests