Интересна именно ситуация со вложенными драйверами, когда каждый драйвер предоставляет блокирующие операции. Получается, что первый драйвер должен для выполнения блокирующей операции несколько раз вызвать блокирующую операцию следующего драйвера. Чего as is в условии «лёгких потоков» он сделать не может, ибо не помнит, на чем он на прошлой итерации остановился.
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
А удалось использовать легковесные потоки с ссылающими друг на друга драйверами устройств? Ну, допустим, когда драйвер block_device флешпамяти использует драйвер spi и так далее?
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
Строго говоря, возможны разные реализации, но таки обычно директорий представлен специальным типом файла и описан в полноправной inode. Так что жёсткая ссылка на него допустима так же, как и на любой другой файл.
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
У меня вопрос о вашем бэкграунде (в части знаний).
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Строго говоря, ipv6 не ломает концепцию NAT. NAT можно перевести на ipv6 ровно в том виде, в котором он сейчас существует.
Впрочем, наверняка можно придумать более правильные механизмы фильтрации. Тоесть, реализовывать фильтрацию трафика не лишая внутреннюю машину глобального ip.
Процесс, в любом случае, необратим… Так что перейдём все, никуда не денемся.
50% до конца десятилетия — верится с трудом. График очень красивый. Похож на правду — по идее — колебательный процесс с небольшими флуктуациями, похож на процессы в ТАУ. Если это действительно так, процесс ускорится, но не на много. 2022, ИМХО, более реальный прогноз для 50%. Дальше рост начнет замедляться. Где-то к 2032 от ipv4 остануться проценты.…
Фактически это о том, что у системы есть некий наиболее вероятный класс состояний, к которому она стремиться при бесконечной последовательности случайных изменений (можно считать, что действует закон больших чисел). Для риса и чечевицы — это мешанина. Для воды и масла — это разделение на две фракции.
То есть, по сути, энтропия — это не о физическом процессе вообще, а о круговороте возможных состояний системы. И теперь мне наконец-то понятна энтропия в информатике.
Может быть вы подскажите, почему операционные системы так долго загружаются. Даже рекордные семь секунд — это же целая вечность во временном масштабе ПО, не говоря уже о загрузке десктопных осей. Что они делают всё это время? На что уходят эти семь секунд?
А opengl здесь и работает…
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Впрочем, наверняка можно придумать более правильные механизмы фильтрации. Тоесть, реализовывать фильтрацию трафика не лишая внутреннюю машину глобального ip.
50% до конца десятилетия — верится с трудом. График очень красивый. Похож на правду — по идее — колебательный процесс с небольшими флуктуациями, похож на процессы в ТАУ. Если это действительно так, процесс ускорится, но не на много. 2022, ИМХО, более реальный прогноз для 50%. Дальше рост начнет замедляться. Где-то к 2032 от ipv4 остануться проценты.…
Ну… Гадание по графику…
Фактически это о том, что у системы есть некий наиболее вероятный класс состояний, к которому она стремиться при бесконечной последовательности случайных изменений (можно считать, что действует закон больших чисел). Для риса и чечевицы — это мешанина. Для воды и масла — это разделение на две фракции.
То есть, по сути, энтропия — это не о физическом процессе вообще, а о круговороте возможных состояний системы. И теперь мне наконец-то понятна энтропия в информатике.