Come deve essere combinato un sistema operativo integrato con il codice utente?

Question

Come deve essere combinato un sistema operativo integrato con il codice utente?

#1 da (7 voti)
#2 da (3 voti)

4

Come effetto collaterale di un progetto incorporato su cui ho lavorato, ho sviluppato un piccolo sistema operativo per un processore ARM. Mentre il sistema operativo e il mio codice utente sono in directory separate e hanno dei confini puliti tra di loro, sono integrati in una singola immagine utilizzando un singolo Makefile.

Mi piacerebbe rilasciare il sistema operativo come open source. Consiste in una libreria di driver exokernel e userland.

Quello che sto cercando di decidere è come un utente di questo sistema operativo dovrebbe combinarlo con il proprio codice in fase di compilazione in modo da avere una singola immagine da far lampeggiare. Posso pensare a tre possibilità:

1) L'utente include i file sorgente del SO come parte del loro progetto. Stanno ricreando il setup che ho attualmente, ed è come FreeRTOS, ad esempio, sembra farlo (anche se ha solo tre file).

2) Avere il sistema operativo si costruisce in un file .a con cui il codice utente può collegarsi. Ciò consentirebbe all'utente di controllare completamente il posizionamento della memoria utilizzando il proprio script linker (e consentire al linker di dirgli quando un testo combinato, una sezione BSS o dati supera il suo spazio).

3) Avere il sistema operativo si costruisce in un binario non elaborato che si aspetta di avere il codice utente concatenato alla fine di esso. Il codice utente inizierebbe con una piccola intestazione (posizionata dallo script del linker) che aveva l'indirizzo della funzione principale. Il codice utente si collegherebbe anche con un file .a dei soli driver userland, non del kernel.

(1) renderebbe più facile sviluppare il sistema operativo e il mio codice utente parallelamente alla sottostruttura di git. (2) sembra avere il processo di collegamento più utile. (3) dà la più grande separazione.

Se lo stavi usando, quale preferisci e perché?

builds operating-systems embedded-systems linking

posta Dan Ellis 17.01.2014 - 16:43

fonte

2 risposte

Leggi altre domande sui tag builds operating-systems embedded-systems linking

Interprete o macchina virtuale che non esegue bytecode Questa implementazione di Decorator viola il Principio di sostituzione di Liskov?

score 7 · Answer 1

Per i sistemi piccoli, sistemi operativi embedded hardcore, la prima opzione è l'unica realmente valida.

Il problema è che per quasi ogni chipset, dovresti apportare piccole modifiche all'interfacciamento con l'hardware e questo ti dà un alto rischio che il sistema operativo debba essere ricompilato per il nuovo chipset.

Quindi, la prima opzione non è solo la più semplice per te, ma anche la più semplice per incorporarla nel prossimo progetto.

score 3 · Answer 2

Lasciatemi prima dire che sono d'accordo con la risposta di Bart, ma voglio discutere per l'opzione (2 +).

Supponiamo che il tuo progetto OSS sia un successo, che tu abbia alcune decine (o centinaia) di sviluppatori che usano il tuo sistema operativo, e sei impegnato a lavorare su V2, che ha alcune modifiche irrisolte con V1. Alcuni utenti hanno strani problemi che non puoi riprodurre, che sospetti siano legati al loro ambiente di costruzione. All'improvviso trovi che i tuoi confini chiari non sono così puliti.

Dato un componente software e un'applicazione che lo utilizza, è altamente auspicabile che il punto in cui i due vengano combinati sia il più tardi possibile nel processo di compilazione. La compilazione separata è migliore dei file di inclusione, le librerie collegabili sono migliori degli oggetti, le librerie dinamiche sono migliori di quelle statiche, il runtime è migliore del tempo di compilazione. [Ovviamente non tutte le scelte sono disponibili su tutte le tecnologie.]

È la tua chiamata basata sulle tecnologie che hai a tua disposizione, ma sbagliare sul lato della separazione dovrebbe portare benefici nel tempo. Più grande è la separazione, meglio è.