>> Ещё один минус - микроядерный
>> подход более сложный - прийдётся чётко выверять протоколы между всеми компонентами
>> и "Stable API nonsense" уже не очень получится, т.е. что-то поменять
>> уже становится сложнее.
> как вообще (не)стейблАпи соотносится с (микро)ядерностью??? вы можете выкатить два апи
> для юзерленда - один для всех, второй для дров которые в
> вашем дереве исходников, и его перекраивать каждый релиз В том-то и дело, что с точки зрения системы нет такого разделения - драйвера это такие-же процессы, как и другие, и всем доступно одинаковое API. Если говорить про конкретику - например в QNX - есть базовый механизм IPC - Send()/Receive()/Reply() - всё в системе на самом деле обменивается сообщениями, и даже когда Вы говорите open("/home/my_file", O_RDONLY); то на самом деле от Вашего, прикладного процесса, посылается сообщение, в котором закодировано, что надо выполнить операцию открытия такого-то файла и посылает это сообщение соответствующему менеджеру. Определением необходимого менеджера может потребовать посылку других сообщений какому-нибудь "менеджеру менеджеров" который знает, кто за какую часть файловой системы отвечает.
Т.е. в итоге для каждой компоненты системы, будь то файловый менеджер, сетевой менеджер ещё кто-нибудь, есть чётко определённый набор запросов и ответов. Менеджеры тоже могут общаться между собой (например NFS или SMB, который вроде как файловый, но потом обращается к сетевому). И вот вы добавили что-то дополнительное в запрос. В Linux, как я понимаю, эти доп. признаки обработаются где-то на уровне входа в системный вызов и драйвера про него может даже и не узнают. В QNX надо этот новый флаг добавлять во все соответствующие сообщения, или плодить, как в linux - новые сообщения для open(), new_open(), new_new_open() и придумывать как в динамике определять есть этот new_new_open() или нет . В общем, имхо, много проблем на пустом месте.
