Pela minha leitura, o desempenho do dbus deve ser duas vezes mais lento que outros mecanismos do ipc de mensagens devido à existência de um daemon.

Na discussão da questão soqual técnica IPC do Linux usar alguém menciona problemas de desempenho. Você vê problemas de desempenho além do fator duas vezes mais lento? Você vê o problema que impede que o dbus seja usado no sistema incorporado?

Para meu entendimento, se o dbus se destina a pequenas mensagens. Se uma grande quantidade de dados precisar ser transmitida, uma das soluções é colocar os dados na memória compartilhada ou em uma pilha e usar o dbus para notificar. Outros mecanismos de ipc de acordo com a discussão em consideração são: sinais, tubulações anônimas, tubulações nomeadas ou FIFOs, filas de mensagens SysV, filas de mensagens POSIX, memória compartilhada SysV, memória compartilhada POSIX, semáforos SysV, semáforos POSIX, bloqueios FUTEX, bloqueios de arquivo memória compartilhada suportada e anônima usando mmap, soquetes de domínio UNIX, soquetes Netlink, soquetes de rede, mecanismos de inotificação, subsistema FUSE, subsistema D-Bus.

Eu deveria mencionaroutra pergunta que lista os requisitos (embora esteja centrado no apache):

orientado a pacotes / mensagenscapacidade de lidar com comunicação ponto a ponto e um para muitossem hierarquia, não há servidor e clientese um ponto final falhar, os outros deverão ser notificadosbom suporte das distribuições Linux existentesexistência de um "bind" para o Apache, com o objetivo de criar páginas dinâmicas - isso é muito específico, mas pode ser ignorado em uma discussão geral de uso do dbus incorporado

Aindaoutra pergunta sobre desempenho menciona técnicas para melhorar o desempenho. Com tudo isso sendo resolvido, acho que deve haver menos problemas ou inconvenientes quando o dbus é usado em um sistema incorporado.