🚀 go-pugleaf

W dniu 28.01.2012 22:57, Andrzej W. pisze:
> Witam,
>
> Jestem od sprzętu więc nie krzyczcie za bardzo.
> Mam kod modułu jądra, który reaguje na zdarzenia sprzętowe, zliczając
> je, w swoim programie mogę odczytać ten licznik.
> Chciałbym tak zmodyfikować kod tego modułu by po każdym zdarzeniu moduł
> informował jakoś mój program, bym nie musiał jak głupi w pętli odpytywać
> tego licznika.
> Pomyślałem sobie, że moduł mógłby do mojego programu wysyłać np. sygnał
> SIGUSR1.
> Pytanie, czy jest to właściwe i optymalne ze względu na szybkość
> działania modułu jądra rozwiązanie?
> Jeśli nie, to jakie rozwiązanie było by lepsze?
>

Witam.

A w jaki sposób masz rozwiązaną na tę chwilę komunikację między kernelem 
a programem?

Zastanów się nad utworzeniem urządzenia w /dev.
Program mógłby spać w oczekiwaniu na dane.

Zrób sobie np. cat /dev/input/mice i poruszaj myszką - dopóki nie ma 
danych cat śpi i nie żżera CPU.

Pozdrawiam.

W dniu 2012-01-29 13:42, Krzysztof Magosa pisze:
> Witam.
> 
> A w jaki sposób masz rozwiązaną na tę chwilę komunikację między kernelem
> a programem?
> 
> Zastanów się nad utworzeniem urządzenia w /dev.
> Program mógłby spać w oczekiwaniu na dane.
> 
> Zrób sobie np. cat /dev/input/mice i poruszaj myszką - dopóki nie ma
> danych cat śpi i nie żżera CPU.


W tej chwili w moim programie, w pętli odczytuje stan licznika przerwań.
Licznik przerwań zaś jest obsługiwany (zwiększany) przez kod modułu
urządzenia.
Pomyślałem sobie, żeby w kodzie modułu zamiast "count++" dać
"kill(PID,SIGUSR1)" a w moim programie dać "pause".
Pytanie tylko o ile dłużej od "++" będzie się wykonywał "kill" w tym module.


-- 
Pozdrawiam,
Andrzej

On 01/29/2012 08:09 PM, Andrzej W. wrote:
> W dniu 2012-01-29 13:42, Krzysztof Magosa pisze:
>> Witam.
>>
>> A w jaki sposób masz rozwiązaną na tę chwilę komunikację między kernelem
>> a programem?
>>
>> Zastanów się nad utworzeniem urządzenia w /dev.
>> Program mógłby spać w oczekiwaniu na dane.
>>
>> Zrób sobie np. cat /dev/input/mice i poruszaj myszką - dopóki nie ma
>> danych cat śpi i nie żżera CPU.
>
>
> W tej chwili w moim programie, w pętli odczytuje stan licznika przerwań.
> Licznik przerwań zaś jest obsługiwany (zwiększany) przez kod modułu
> urządzenia.
> Pomyślałem sobie, żeby w kodzie modułu zamiast "count++" dać
> "kill(PID,SIGUSR1)" a w moim programie dać "pause".
> Pytanie tylko o ile dłużej od "++" będzie się wykonywał "kill" w tym module.
>
>

Zrob dokladnie tak jak napisal Krzysztof Magosa, aby modul byl dostepny
przez noda w /dev/
wtedy funkcjami poll/epoll/select uspisz swoj userspace'owy
program w oczekiwaniu na zdarzenie (w twoim przypadku inkrementacja 
licznika), a potem program odczyta dzieki ioctl stan licznika w module 
(wtedy nie "zgubisz" zadnego przerwania nawet jak czas miedzy odebraniem 
eventa a odczytem biezacej wartosci bedzie zbyt duzy)

Sygnaly maja pewna "nieprzyjemna" wlasciwosc a mianowicie w programie
wielowatkowym przerywaja wszystkie watki "czekajace" w wywolaniach jak
select(), sem_wait() itp a wtedy te zwracaja -1 i maja ustawiony errno
na EINTR co musisz sobie sprawdzic i spowrotem wywolac w/w funkcje

Mariusz

W dniu 2012-01-30 12:06, macu pisze:
> Zrob dokladnie tak jak napisal Krzysztof Magosa, aby modul byl dostepny
> przez noda w /dev/
> wtedy funkcjami poll/epoll/select uspisz swoj userspace'owy
> program w oczekiwaniu na zdarzenie (w twoim przypadku inkrementacja
> licznika), a potem program odczyta dzieki ioctl stan licznika w module
> (wtedy nie "zgubisz" zadnego przerwania nawet jak czas miedzy odebraniem
> eventa a odczytem biezacej wartosci bedzie zbyt duzy)

Moduł który chce przerobić obsługuje GPIO procesora, każdy z IO jest już 
reprezentowany w /dev/, ale raczej na takim pliku się poll nie postawi, 
rozumiem, że mam zrobić urządzenie, które będzie przechowywać tylko 
wartość licznika?

O czym mam sobie poczytać, żeby się uświadomić w temacie tworzenia 
takich urządzeń?

-- 
Dziękuję,
Andrzej.

On 01/30/2012 03:07 PM, Andrzej W. wrote:
> W dniu 2012-01-30 12:06, macu pisze:
>> Zrob dokladnie tak jak napisal Krzysztof Magosa, aby modul byl dostepny
>> przez noda w /dev/
>> wtedy funkcjami poll/epoll/select uspisz swoj userspace'owy
>> program w oczekiwaniu na zdarzenie (w twoim przypadku inkrementacja
>> licznika), a potem program odczyta dzieki ioctl stan licznika w module
>> (wtedy nie "zgubisz" zadnego przerwania nawet jak czas miedzy odebraniem
>> eventa a odczytem biezacej wartosci bedzie zbyt duzy)
>
> Moduł który chce przerobić obsługuje GPIO procesora, każdy z IO jest już
> reprezentowany w /dev/, ale raczej na takim pliku się poll nie postawi,
> rozumiem, że mam zrobić urządzenie, które będzie przechowywać tylko
> wartość licznika?
>
> O czym mam sobie poczytać, żeby się uświadomić w temacie tworzenia
> takich urządzeń?
>

poszukaj na sieci ksiazek
Linux-Device-Drivers-3rd-Edition.pdf (+ plik ldd3_examples.tar.gz)
OReilly,.Linux.System.Programming.pdf
Professional Linux Kernel Architecture.pdf
LinuxKernelInANutshell.pdf


generalnie kod drivera wypelnia pola struktury file_operations
wskaznikami do swoich funkcji, jest tam m.in. pole
    unsigned int (*poll) (struct file *, struct poll_table_struct *);
jak masz zrodla drivera do gpio to sprawdz czy jest tam tak robione,
jesli tak to moze moglbys sie "podczepic" ze swoim poll'em z aplikacji

Mariusz

W dniu 2012-01-31 13:50, macu pisze:
> generalnie kod drivera wypelnia pola struktury file_operations
> wskaznikami do swoich funkcji, jest tam m.in. pole
>     unsigned int (*poll) (struct file *, struct poll_table_struct *);
> jak masz zrodla drivera do gpio to sprawdz czy jest tam tak robione,
> jesli tak to moze moglbys sie "podczepic" ze swoim poll'em z aplikacji

Pisząc, że nie da się zrobić poll na pinie IO obecnego drivera miałem na 
myśli, że ten pin czyta się "w kółko", tz. zrobienie "cat /dev/gpio1" 
zapełnia nam od razu cały ekran i kolejne też, jego wartością.

Przeanalizuje kod sterownika i przez analogię postaram się zrobić 
"/dev/gpio1.count" przechowujące wartość licznika zmian stanu, wtedy 
poll na takim urządzeniu da mi to czego potrzebuję.

-- 
Dziękuję za pomoc,
AWa.