Money.plTechnologie dla biznesu Grupy dyskusyjne pl.misc.elektronika [OT] Zarządzanie konfiguracją modułów ko

[OT] Zarządzanie konfiguracją modułów ko

[OT] Zarządzanie konfiguracją modułów ko

"Andrzej Ekiert" <d...@tlen.pl> / 2012-05-06 13:09:10
Przedstawię najpierw scenariusz oraz problem:

Mamy bibliotekę modułów kodu źródłowego, które są używane w wielu
projektach. Każdy z modułów ma swoje parametry konfiguracyjne, którymi
można go "dostroić" dla potrzeb konkretnej aplikacji i płytki - np. moduł
będący driverem do scalaka radiowego ma m.in. parametry określające do
jakich pinów procesora scalak jest podpięty, moduł będący driverem do
pamięci na I2C ma parametry mówiące którym interfejsem I2C mikrokontrolera
należy z tą pamięcią rozmawiać, jaki jest rozmiar pamięci i który pin
procesora to CS, itp.

Problem:
W każdym projekcie, który korzysta z danego modułu, ustawiamy odpowiednio
wszystkie parametry. Następnie, z dowolnej przyczyny, w bibliotece
zmieniamy zestaw parametrów konfiguracyjnych oferowanych przez moduł. W
efekcie musimy poprawić pliki konfiguracyjne w każdym z projektów, co przy
rosnącej liczbie tych projektów po chwili staje się boleśnie pracochłonne.

Szukam mądrej metody radzenia sobie z tą niepotrzebną pracą. Metody
aplikowalnej do kodu w C i assemblerze (choć bardzo chętnie usłyszę, jeśli
w C++ da się to zrobić jakoś lepiej). Ważne, aby metoda nie powodowała
skutków run-time (np. zamiast ustalać rozmiar pamięci w konfiguracji, mogę
mieć zmienną ustawianą w funkcji inicjalizującej, do pinów mogę mieć
callbacki włącz/wyłącz, też ustawiane przez API, a do sprzętowego modułu
I2C mogę mieć dodatkową warstwę abstrakcji, ale wszystko to kosztuje
pamięć lub cykle, a w przypadku niektórych parametrów jest praktycznie
niewykonalne - poza tym tylko to przesuwa problem ze zmian konfiguracji,
na zmianę API).

Jestem blisko rozpoczęcia pisania programu, który będzie mi zarządzał tą
konfiguracją, tzn. za jednym klikiem porówna konfiguracje wszystkich
zarządzanych projektów, pokaże gdzie są nieustawione parametry, gdzie są
ustawione już nieistniejące parametry, gdzie wartość parametrów różni się
od domyślnej, a następnie umożliwi wybranie akcji, ustawienie właściwych
wartości i uaktualni zarządzane pliki konfiguracyjne. Ale trochę mam
nadzieję, że istnieje jakiś inteligentny sposób, na który nie wpadłem.

ae
 
Czytaj także na forum

Re: [OT] Zarządzanie konfiguracją modułó

Zbych <z...@onet.pl> / 2012-05-06 14:19:08
W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:

> Problem:
> W każdym projekcie, który korzysta z danego modułu, ustawiamy
> odpowiednio wszystkie parametry. Następnie, z dowolnej przyczyny, w
> bibliotece zmieniamy zestaw parametrów konfiguracyjnych oferowanych
> przez moduł. W efekcie musimy poprawić pliki konfiguracyjne w każdym z
> projektów, co przy rosnącej liczbie tych projektów po chwili staje się
> boleśnie pracochłonne.

Na to nic nie poradzisz. Skoro biblioteka zmienia swoje
parametry/interface to musisz dostosować do niej programy.
W c++ od biedy można zastosować parametry domyślne albo przeciążyć
funkcje. Wtedy stare programy mogą korzystać ze starego interfejsu.

> Szukam mądrej metody radzenia sobie z tą niepotrzebną pracą. Metody
> aplikowalnej do kodu w C i assemblerze (choć bardzo chętnie usłyszę,
> jeśli w C++ da się to zrobić jakoś lepiej). Ważne, aby metoda nie
> powodowała skutków run-time (np. zamiast ustalać rozmiar pamięci w
> konfiguracji, mogę mieć zmienną ustawianą w funkcji inicjalizującej, do
> pinów mogę mieć callbacki włącz/wyłącz,

A to już zwykłe makra, definy, funkcje inline, specjalizacje szablonów
nie wystarczą do ukrycia fizycznego położenia pinów?

> sprzętowego modułu I2C mogę mieć dodatkową warstwę abstrakcji, ale
> wszystko to kosztuje pamięć lub cykle, a w przypadku niektórych
> parametrów jest praktycznie niewykonalne - poza tym tylko to przesuwa
> problem ze zmian konfiguracji, na zmianę API).

Jeśli do wszystkich modułów I2C z różnych procesorów jesteś w stanie
opracować jeden interface to nie ma problemu. Dodajesz do projektu plik
ze swoją obsługą I2C od danego procka i już. Moduł radiowy wykorzysta te
funkcje, które dołączy linker. Zero narzutu.


Ja raczej unikami używania tej samej kopii biblioteki do różnych
projektów. Dasz sobie głowę uciąć, że zmiana w bibliotece pod bieżący
projekt x nie spowoduje jakiś anomalii w projekcie x-10, który pisała
inna osoba?
Wolę zrobić kopię biblioteki z projektu x-1 i nanieść poprawki.
 

Re: [OT] Zarządzanie konfiguracją modułó

Jacek Domański <j...@NOSPAMchello.pl> / 2012-05-06 14:21:22
Ja osobiście jestem na początku drogi - tj. jeszcze nie powstały te
dziesiatki modulow do dziesiatek aplikacji, ale zaczynam już dostrzegać
problem, stąd moje zainteresowanie tą problematyką - tak, aby zawczasu
coś ustalić i pisać dalej w/g ustalonej, optymalnej metody.

Jednym z pomysłów jest wykorzystanie programów do zarządzania wersjami
typu: SVN, GIT, Mercurial.
Innym pomysłem, który mnie zainteresował, jest wykorzystanie linków do
plików zamiast kopii plików (pod Linuxem) - w ten sposób mamy tylko
jeden plik, widziany przez dowolnie wiele projektow i zmiana w nim
przenosi się automatycznie na wszystkie projekty.

Najprosciej byłoby nie zmieniać parametrow konfiguracyjnych w bibliotece
;-)
A może zostawić stare jako 'deprecated', a dodac do nich nowe?


--
Jado




W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:
> Przedstawię najpierw scenariusz oraz problem:
>
> Mamy bibliotekę modułów kodu źródłowego, które są używane w wielu
> projektach. Każdy z modułów ma swoje parametry konfiguracyjne, którymi
> można go "dostroić" dla potrzeb konkretnej aplikacji i płytki - np.
> moduł będący driverem do scalaka radiowego ma m.in. parametry
> określające do jakich pinów procesora scalak jest podpięty, moduł będący
> driverem do pamięci na I2C ma parametry mówiące którym interfejsem I2C
> mikrokontrolera należy z tą pamięcią rozmawiać, jaki jest rozmiar
> pamięci i który pin procesora to CS, itp.
>
> Problem:
> W każdym projekcie, który korzysta z danego modułu, ustawiamy
> odpowiednio wszystkie parametry. Następnie, z dowolnej przyczyny, w
> bibliotece zmieniamy zestaw parametrów konfiguracyjnych oferowanych
> przez moduł. W efekcie musimy poprawić pliki konfiguracyjne w każdym z
> projektów, co przy rosnącej liczbie tych projektów po chwili staje się
> boleśnie pracochłonne.
>
> Szukam mądrej metody radzenia sobie z tą niepotrzebną pracą. Metody
> aplikowalnej do kodu w C i assemblerze (choć bardzo chętnie usłyszę,
> jeśli w C++ da się to zrobić jakoś lepiej). Ważne, aby metoda nie
> powodowała skutków run-time (np. zamiast ustalać rozmiar pamięci w
> konfiguracji, mogę mieć zmienną ustawianą w funkcji inicjalizującej, do
> pinów mogę mieć callbacki włącz/wyłącz, też ustawiane przez API, a do
> sprzętowego modułu I2C mogę mieć dodatkową warstwę abstrakcji, ale
> wszystko to kosztuje pamięć lub cykle, a w przypadku niektórych
> parametrów jest praktycznie niewykonalne - poza tym tylko to przesuwa
> problem ze zmian konfiguracji, na zmianę API).
>
> Jestem blisko rozpoczęcia pisania programu, który będzie mi zarządzał tą
> konfiguracją, tzn. za jednym klikiem porówna konfiguracje wszystkich
> zarządzanych projektów, pokaże gdzie są nieustawione parametry, gdzie są
> ustawione już nieistniejące parametry, gdzie wartość parametrów różni
> się od domyślnej, a następnie umożliwi wybranie akcji, ustawienie
> właściwych wartości i uaktualni zarządzane pliki konfiguracyjne. Ale
> trochę mam nadzieję, że istnieje jakiś inteligentny sposób, na który nie
> wpadłem.
>
> ae


 

Re:

"Andrzej Ekiert" <d...@tlen.pl> / 2012-05-06 14:44:09
Dnia 06-05-2012 o 14:21:22 Jacek Domański
napisał(a):

> Jednym z pomysłów jest wykorzystanie programów do zarządzania wersjami
> typu: SVN, GIT, Mercurial.

Ależ ja to wszystko mam pod Mercurialem, tyle że to tego problemu akurat
nie rozwiązuje.

> Innym pomysłem, który mnie zainteresował, jest wykorzystanie linków do
> plików zamiast kopii plików (pod Linuxem) - w ten sposób mamy tylko
> jeden plik, widziany przez dowolnie wiele projektow i zmiana w nim
> przenosi się automatycznie na wszystkie projekty.

Chodzi o to, że dla każdego projektu mam te same parametry ustawione w
inny sposób. Więc też nie rozwiązuje problemu.

> Najprosciej byłoby nie zmieniać parametrow konfiguracyjnych w bibliotece
> ;-)

No rzeczywiście :-)

ae
 

Re:

"Andrzej Ekiert" <d...@tlen.pl> / 2012-05-06 14:55:59
Dnia 06-05-2012 o 14:19:08 Zbych napisał(a):

> A to już zwykłe makra, definy, funkcje inline, specjalizacje szablonów
> nie wystarczą do ukrycia fizycznego położenia pinów?

Wystarczą, ale dla każdego projektu trzeba te define'y inaczej ustawić -
ta sama nazwa, inna wartość.

> Jeśli do wszystkich modułów I2C z różnych procesorów jesteś w stanie
> opracować jeden interface to nie ma problemu. Dodajesz do projektu plik
> ze swoją obsługą I2C od danego procka i już. Moduł radiowy wykorzysta te
> funkcje, które dołączy linker. Zero narzutu.

Przy wielu architekturach, to akurat nie mam wyjścia i muszę zrobić
takiego HALa, ale narzut jest. W przypadku jednej architektury, to zamiast
po prostu się odwołać do rejestru sprzętowego modułu, muszę przekazać
mojemu driverowi do chipu jakąś strukturę drivera do modułu I2C, która
będzie mieć np. callbacki do funkcji pośredniczących. Narzut jak diabli,
choć czasem trzeba się na niego zgodzić (np. wspódzielony dostęp kilku
"driverów" do jednego sprzętowego I2C).

> Ja raczej unikami używania tej samej kopii biblioteki do różnych
> projektów. Dasz sobie głowę uciąć, że zmiana w bibliotece pod bieżący
> projekt x nie spowoduje jakiś anomalii w projekcie x-10, który pisała
> inna osoba?

Staram się tak modularyzować kod i dawać takie API, żeby zmiany nie
wywoływały efektów ubocznych. Oczywiście przetestować to zawsze trzeba i
nie dam sobie uciąć nawet paznokcia.

> Wolę zrobić kopię biblioteki z projektu x-1 i nanieść poprawki.

Wykrywasz błąd albo robisz usprawnienie w x-1 i dopiero masz poprawianie
wszędzie gdzie ta kopia jest. Brrr...

ae
 
wstecz
1 2 3 4 5 6 7 8 9
współpraca