Paweł Sikora wrote: >> Author: vip Date: Fri Feb 23 12:07:33 2007 GMT >> ++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20) >> ++ INIT_WORK(&(thread_obj->work), routine); >> ++#else >> + INIT_WORK(&(thread_obj->work), routine, pcontext); [...] > > mistrzu, work->data dla >= 2.6.20 tez trzeba ustawic. > inaczej moze sie taka zabawa brzydko skonczyc ;-)
Ja tu jeszcze widzę inny problem - dla nowego INIT_WORK (2.6.20) drugi argument - routine powinien być wskaźnikiem funkcji, której jedynym argumentem jest wskaźnik do struct work_struct. Dla starego INIT_WORK (< 2.6.20), routine również jest wskaźnikiem do funkcji, ale jej argumentem jest jakaśtam inna struktura danych (która nawiasem mówiąc posiada pole wskaźnika do struct work_struct). W obydwu przypadkach wskaźnik do tej funkcji ląduje jako pole func zmiennej/struktury wskazywanej przez pierwszy argument INIT_WORK. Dalej w toku zmagań na wysokości pliku kernel/workqueue.c w funkcji __run_work (2.6.20) lub run_workqueue (<2.6.20) wywoływana jest ta funkcja z argumentem work (2.6.20) lub data (w naszym wypadku pcontext) (dla < 2.6.20) Co ciekawsze funkcja przekazywana jako routine jest (z mojego pobieżnego przejrzenia kodu) definiowana w ramach dostarczanego binarnego bloba (a przynajmniej samo przekazywanie wskaźnika do tej funkcji jest tylko w blobie) - tu zakładam że zaimplementowana jest w "starej" formie tj. argumentem jej jest wskaźnik do czegoś innego niż struct work_struct. No i dochodzimy do sedna - w 2.6.20 po wywołaniu __run_work wywoływana jest funkcja "routine" z nieoczekiwanym argumentem -> BUM ? To tyle dywagacji, ale może funkcja przekazywana jako wskaźnik routine jest gdzieś zdefiniowana w postaci źródłowej i można ją przedefiniować ? Pozdrawiam, Marek _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl