Uma das Pesquisas no Laboratorio investiga o uso de C++ moderno (inicialmente 2011, agora 2014) na definicao de programas bare metal. Nosso interesse geral esta em aplicacoes de I/O e um dos nossos interesses especificos esta em aplicacoes tipo "dispositivo criptografico".Ao retornar para esta Pesquisa, resolvemos atualizar nossas ferramentas para obter uma implementacao completa do C++ 2014. Nossa motivacao foi o lancamento do GCC 5.1 que inclui suporte completo para esta nova especificacao.Nosso objetivo e estudar aplicacoes para BIOS, UEFI, Multiboot 1 e 2 e outras "maquinas" similares emuladas com qemu. Estamos construindo programas para arquitetura i686-pc-elf. Nosso ambiente de desenvolvimento e Fedora 21 64 bits, onde as ferramentas tem arquitura alvo x86_64-redhat-linux. Apesar de x86_64 e i686 serem "compativeis", nesse tipo de projeto e necessario um cross toolchain.Precisamos basicamente de um cross binutils e um cross g++. Existem diversas maneiras de obter o toolchain final, esta e a maneira que funcionou para nos.Para construir binutils, explodimos o pacote de codigo-fonte, configuramos com o --target i686-pc-elf e o --prefix onde sera instalado o nosso novo toolchain, e usamos make normalmente.tar -xzf binutils-2.25.tar.gzmkdir binutils-i686-pc-elfpushd binutils-i686-pc-elf../binutils-2.25/configure --build=x86_64-redhat-linux --target=i686-pc-elf --prefix=/opt/tools-i686-pc-elfmakepopd Para construir gcc, explodimos o pacote de codigo-fonte e configuramos de acordo com binutils, entao usamos make com certos make target especiais para construir aquilo que faz sentido.tar -xjf gcc-5.1.0.tar.bz2mkdir gcc-i686-pc-elfpushd gcc-i686-pc-elf../gcc-5.1.0/configure --build=x86_64-redhat-linux --target=i686-pc-elf --prefix=/opt/tools-i686-pc-elf --enable-languages=c,c++ --without-headersmake all-gccmake all-target-libgccmake install-gccmake install-target-libgccpopdCom este cross toolchain conseguimos construir programas para rodar no qemu com depuracao no gdb. Hoje, mais uma vez, resolvi um problema de projeto virando o jogo de cabeca para baixo.Pretendo refazer este artigo no futuro com uns diagramas mais legais; por enquanto segue apenas o texto para nao ficar esquecido.Um sistema extensivel exibe padroes conhecidos; por toda parte vemos sistemas de "plugins".Imaginando nosso sistema com "plugins", vemos um elemento Central e diversos elementos Adicionais que podem ser inseridos e removidos do sistema a vontade. O elemento Central e um so e ha varios Adicionais ligados ao Central.Extraindo dessa imagem uma imagem conceitual, vemos o tipo Central em relacao com o tipo Adicional, onde Adicional tem multiplicidade zero ou mais.Partindo daqui para uma imagem comportamental, vemos o que acontece quando inserimos o Adicional. Ou tentamos ver. O que acontece? Quem faz o que?Vamos supor que estamos criando tudo isso com um servidor de aplicacao J2EE. Nesse ambiente, os modulos, quando iniciados, sofrem (1) injecao de dependencias em @EJB etc., (2) chamadas a @PostConstruct.Acompanhando nossa imagem conceitual, onde Central tem Adicionais, buscamos entender como Central pode fazer alguma coisa a cada vez que um Adicional e inserido e iniciado no sistema de modulos.Se nos temos um sistema com resolucao e injecao automatica de depenencias, declarariamos que o Central tem dependencia nos Adicionais, com o objetivo de causar o sistema de modulos injetar Adicionais no Central sempre que forem iniciados, e o inverso quando forem removidos. Como acontece isso? O sistema de modulos ativar uma rotina qualquer de Central a cada vez que um Adicional for iniciado -- uma rotina addDependency por exemplo. O oposto aconteceria quando o Adicional e removido. A esperanca e que Central receba