Qual è un buon modo per spiegare che la configurazione del sistema in fase di esecuzione non dovrebbe essere modificata dal codice al momento della compilazione? [chiuso]

Question

Qual è un buon modo per spiegare che la configurazione del sistema in fase di esecuzione non dovrebbe essere modificata dal codice al momento della compilazione? [chiuso]

#1 da (2 voti)

1

Sto programmando per un sistema embedded. Quando questo sistema si avvia, legge da un file di configurazione alcuni dati ed esegue le regole per mettere lo stato del sistema in base alla lettura della configurazione. Questa configurazione dipende dall'ambiente / requisiti di ogni cliente e può essere gestita tramite interfacce di gestione (come interfaccia Web).

Vorrei spiegarmi meglio: questo sistema integrato è un router domestico (CPE) per gli ISP. La configurazione per il router è memorizzata in una partizione flash e nel file system è incluso un file di configurazione predefinito incluso nell'immagine del firmware. Uno di questi ISP ci ha chiesto di rilasciare un nuovo firmware che dovrebbe includere una configurazione diversa per una delle interfacce di rete utilizzate dal router.

Il problema è che questo ISP non desidera eseguire un ripristino del file di configurazione predefinito nei CPE dei suoi clienti per non perdere la configurazione che ogni cliente ha salvato su di esso (come ESSID per l'interfaccia WLAN). L'ISP vuole che il firmware sia in grado di connettersi utilizzando il nuovo requisito per l'interfaccia di rete una volta che il CPE è stato aggiornato.

Uno dei miei colleghi lo ha proposto: all'avvio del nuovo firmware, controlla se l'interfaccia esiste nella configurazione CPE e, in caso contrario, la aggiunge durante l'avvio al file di configurazione.

Mi piacerebbe spiegarli (ISP e collaboratori) usando buoni motivi per cui il file di configurazione non dovrebbe essere modificato in fase di esecuzione tranne che per le interfacce di gestione.

project-management embedded-systems configuration-management

posta MABC 05.10.2014 - 19:14

fonte

1 risposta

Leggi altre domande sui tag project-management embedded-systems configuration-management

È una buona idea usare i filtri bloom per questo scenario? esiste qualcosa chiamato schema logico e lo schema concettuale di una tabella di database?

score 2 · Accepted Answer

Essendo questa in pratica la variante "Magic Number" -s "++", molti degli stessi argomenti valgono (o dovrebbero, almeno). Per rendere alcune delle mie considerazioni immediate completamente verbali:

L'aggiunta di codice magico allo scopo di modificare un valore è una procedura di manutenzione elevata. Qualsiasi modifica all'operazione richiede ricerche di codice, verifiche, ricompilazioni e re-flashing, mentre la modifica di tale valore non lo fa direttamente.
L'aggiunta di codice magico può aumentare la vulnerabilità. Se fatto come aggiunta rapida, può (leggi: will) causare percorsi di esecuzione non testati e / o imprevedibili, se deve legare l'interfaccia, questo può anche causare un breve periodo di accesso non protetto con l'aggiunta di una singola supervisione, a seconda sull'intero codice, naturalmente.
Non ha un buon rapporto qualità-prezzo. Se riesci a eliminare i primi due come argomenti, passi un sacco di tempo da uno sviluppatore dedicato di alto livello all'aggiunta e modifica delle funzionalità per problemi che possono essere risolti più facilmente ed economicamente.
Ci sono alternative migliori al problema posto.

La mia alternativa, come al punto 4: Progettazione, aggiunta e test di un modulo che può apportare una singola modifica incrementale alla configurazione, utilizzando la stessa autenticazione e crittografia utilizzate per altri collegamenti sicuri ai dispositivi. Consentendo agli interni di copiare la configurazione corrente, ma cambiando solo quella configurazione nel processo, tutto localmente, possibilmente in modalità non responsiva. Questa è una nuova funzionalità reale, che se la progettate bene può rimanere al sicuro, l'esecuzione è provata per tutte le situazioni e può essere utilizzata da un lavoratore molto più basso per riconfigurare parti senza restrizioni del set-up negli anni a venire.

Ovviamente è necessario impostare dei limiti per quanto riguarda ciò che può essere modificato se si desidera che il cliente finale rimanga al sicuro nella consapevolezza che nessuno può reimpostare le proprie password WiFi o router a qualcos'altro.

Tutto ciò che ho detto, la mia esperienza personale con gli ISP e 9 su 10 delle aziende che costruiscono il loro firmware in generale è simile alla tua: l'ideologia di "buttare lì dentro e compilare" continua a regnare. Questa è in effetti una grande forza trainante in questi giorni nella scelta del mio ISP, oltre costo e velocità, come preferisco l'affidabilità.

Lavorare con gli altri in sistemi embedded può essere un campo minato: -)