Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: halturata в Aug 09, 2007, 18:23 Здравейте,
Работата е следната - написах си едно малко тестово драйверче, като упражнение към тази книга, и също като прелюдия към написването на функционален драйвер. За да изпробвам докъде съм я докарал (вече имам open(), read(), write(), ioctl() функциите) си написах проста програмка, за да видя дали въобще ще работят както очаквам:
Когато се опитам да я компилирам обаче, получавам следните грешки:
Ето го въпросното място в хедъра където гърми:
Така, тези двете структури на семафора и чаръктър дивайса (омг...) са дефинирани без typedef в кода на ядрото. Въпроса ми е как да оправя тези грешки при компилацията? Иначе драйвера се компилира без проблем. Ето и линк към сорса ако някой се интересува. Всякакви идеи и флейм са добре дошли P.S. Ето ги и въпросните дефиниции на struct semaphore / struct cdev:
Да не би да трябва да пъхна някой от тези #define statementsв моя код? Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: the_real_maniac в Aug 09, 2007, 20:52 Не знам дали ще имам време да погледна, но поне да се разпиша че ми е интересно...
пп: а не трябва ли да отчетеш факта , че може би проблема е че правиш cross compile :? и може би там нещо ... едит: _ASM_POWERPC_SEMAPHORE_H
Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: gat3way в Aug 09, 2007, 21:50 Емм... gcc си има опция -I с която се указва include директорията. Като ще го билд-ваш за ppc замислял ли си се, че е възможно в /usr/include/linux да има нещо различно от това, което ти трябва?
Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 10, 2007, 01:07 A
в хедърите забеляза ли? :Р Не можеш да използваш тези структури в userspace. P.S. Нещо форума "забравя" _ _ K E R N E L _ _ ако го напиша както трябва Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: halturata в Aug 10, 2007, 10:52 @the_real_maniac: Ами за крос компайла не мисля, че той създава проблеми, използвам крос компилатор различен от нативния, който си има и свой собствени include директории.
@gat3way: Колкото до -I опцията на gcc за директориите, даже съм я хард-коднал в мейкфайла, но май по всичко личи че е include проблем... @tarator: Аз тези структури не ги ползвам директно в user space, искаш да кажеш че дори ако от user space инклудна файл, който ги дефинира пак ще има проблеми? Ще го мъча още пък да видим Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 10, 2007, 20:52 Може да не ги използваш, но структурите, които използваш ги включват.
Дефинирай внимателно структурите които ще използваш с ioctl да не включват никакви структури от ядрото. П.П. ioctl е едно от най-идиотските неща в Юникс. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: the_real_maniac в Aug 10, 2007, 21:20 offtopic: (може би ? )
Но можеш ли по-друг начин да задаваш свойства от-до , т.е имаш ли нещо , с което да го замениш ? май не ? Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 11, 2007, 05:50 Разбира се, че имам, не говоря наизуст. Едно време от файловете се е четяло и се е писало в тях. Много авангардна идея, нали?
А ти имаш ли някаква идея защо смятам, че ioctl са идиотщина, или ги защитаваш без да мислиш? Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: gat3way в Aug 11, 2007, 12:15 Абе не е точно така. Някои блокови устройства например имат функции, които далеч не се изчерпват с четене/писане. Например как ще си извадиш "софтуерно" CD-то?
Ако става въпрос за streamed I/O е простотия де Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: the_real_maniac в Aug 11, 2007, 14:12
Просто попитах, не съм ползвал нещо различно от ioctl < така че това е идеята.. пп: не си чешам езика, така че не -> не пиша без да мисля haha ;-) :-) :-P Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: gat3way в Aug 11, 2007, 15:18 Обаче би било забавно вместо ioctl-та и някакви слабоумни syscall интерфейси за такива дейности да се минава през sysfs или procfs. Би било много по-удобно, най-малкото доста неща ще могат да се правят с прости шел скриптове, а не с писане на С да речем
Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 11, 2007, 15:54 Най-големия проблем на ioctl e, че не може да се прави по мрежа. Замисляли ли сте се защо не може да се експортне блоково устройство в NFS (например) и да се използва на друг компютър? Забравете идиотските оправдания, причината е, че няма как да се реализира ioctl операцията по мрежата.
> Някои блокови устройства например имат функции, които далеч не се > изчерпват с четене/писане. Например как ще си извадиш "софтуерно" > CD-то? Хората са измислили как да стават такива неща преди повече от 15 години Защо едно устройство трябва да бъде представено с един файл? В Plan9 CD-то се вади така: echo eject > /dev/sdD0/ctl Как се вади CD-то на отдалечена машина? echo eject > /mnt/node1/dev/sdD0/ctl :Р Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: halturata в Aug 13, 2007, 09:41 Леле, тука какъв спор се е развихрил
За структурите, разбрах, доста небрежно съм се отнесъл към тях, пипнах тук-там и сега всичко е ОК - най-главното беше да отделя лузър спейс от кернел спейс типовете. А колкото до ioctl()-а, на мене ми трябва да чета и пиша в няколко 16-битови регистъра на устройството, което го представям като character device, не е чак такава философия като CD-та и т.н. Мерси отново, както виждам тук има поле за разискване на такъв род въпроси. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: the_real_maniac в Aug 13, 2007, 16:59
За протокола: Значи tarator се оказа прав и проблема наистина беше в това, че без да искаш си се опитвал да ползваш структури от kernel в userspace :? е браво за крайният резултат ;-) :-) ---- относно другото: Толкова ли много ти/ви пречи това, че не може да ползвате ioctl през мрежата :? директно ? И защо това да е проблем, а ако беше възможно, не трябва ли преди това да се помисли как да се подсигури (да е сигурна) една такава комуникация м/у две машини, все пак може да говорим за Ioctl() , свойства на у-ва и прочие , но намесваме и мрежова комуникация ;-) :-) Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 13, 2007, 17:05 > Толкова ли много ти/ви пречи това, че не може да ползвате ioctl през
> мрежата :? Да. Такива неща показват дали една операционна система е мрежова, или мрежата е добавена впоследствие и не толкова добре. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 13, 2007, 17:06 halturata,
А тези регистри не можеш ли да ги променяш с "write"? Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: the_real_maniac в Aug 13, 2007, 17:33
Да, съгласен, сега те/Ви разбирам напълно ;-) :-) Ще си позволя едно лирично отклонение, примери по-скоро: във вградени системи ... автоматизации , прочие... датчиците са node-ове, да кажем, точки и се разглеждат като отделни у-ва. Винаги има нужда от настройки , донастройване, калиброване и прочие ... (или поне все има нещо да се пипне и ще е най-добре, ако мжое да се прави отдалечено (и сигурно))./ И по тази логика, ако всеки датчик се разглежда като у-во , вместо да се прави собствен софтуер / характерен , специфичен ... / да да се разлежда като някакво по-стандартно у-во ... като цяло това, което казваш аз си го пренасям в мойта сфера и му намирам приложение, наистина е вярно, че щеше да е уникално лесно, ако вместо да отварям socket-и и чудесии , да правя комуникации , протоколи , можех по един универсален и стандартен начин да влиая в/у устройствата , ктойо са ми отдалечение , но ... мрежови. ммда :-) Отделено вече говорим за компютри навързани в мрежа или някаква по компютърна периферия, принтери , all-in-one копир машини и прочие. ;-) :-) пп: мисля ,че Ви разбрах правилно ? :-) редакция: и ... това да пишете директно във файлове, засега се явява какво - най-добраият workaround , алтернатива :? като цяло е simple ... => и най-вроятно стабилно => и лесно може да се подсигури. един файлов трансфер over ssh или ... мм пиша всичко това , понеже предпоалгам ,че се занимавате със Server организация или нещо подобно ;-) :-) А не толкова .. нещо в моята насока, датчици , авт. системи и прочие, но може и да греша :-) Като цяло итерсна тема , а и много полезна за мен ;-) Благодаря. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 13, 2007, 17:50 Могат да се дадат много примери как в Юникс не всичко е файл, и какви огромни предимства би имало ако наистина бяха файлове. Мързи ме да ги пиша, може да прочетеш това на български.
Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: gat3way в Aug 13, 2007, 18:32 За да не заформям излишни спорове, бих казал, че предимствата са повече, отколкото ми трябват...лично на мене
Обаче подхода на plan9 към TCP сокетите е готин, не мога да отрека Мерси за линка Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 14, 2007, 05:42 > За да не заформям излишни спорове, бих казал, че предимствата са
> повече, отколкото ми трябват...лично на мене Това е защото не си използвал системата и не можеш да си представиш как би ти опростила живота. Например връзваш принтер към десктоп-а си. За да го използваш на отдалечен сървър трябва да го конфигурираш там, или пък да го включиш в централната конфигурация на принтери в системата. В Plan9 принтера както всичко друго е йерархия от файлове, като се логнеш на някой сървър и се опиташ да печаташ, нещата _автоматично_ ще се отпечатат на същия принтер, който си конфигурирал на десктоп-а ти. Дори принтера е локален, пак ще се отпечата без никакви специални усилия. Или пък да се върнем на TCP стека. Всеки потребител може да има собствен TCP стек, например VPN към някоя отдалечена мрежа и може да си го конфигурира както си иска без да пречи на останалите потребители. Нещо повече, потребителя може да има _няколко_ VPN-a, в различни прозорци. И още много други подобни улеснения. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: gat3way в Aug 14, 2007, 09:36 Ясно, но според мен администрацията на мрежа от машини с такава ОС, с достатъчно много потребители и привилегии, ще е един малък ад
Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: halturata в Aug 14, 2007, 10:32 @the_real_maniac: Да това се оказа проблема, просто "главния" хедър с дефинициите на структури за драйвера съм го инклуднал без да мисля и от там проблемите.
@tarator: Ами то работата е малко по-сложна: устройството (Industry Pack модул) се намира на един carrier board, който board е "закачен" за VME bus, който бъс го управлява контролер "закачен" за PCI. Аз имам драйвер за PCI-tо-VME контролера, но ми трябва и драйвер, който да генерира прекъсвания по VME бъса, когато дадено събитие настъпи (малко послъгах че е само четене/писане, просто досега дотам съм го докарал). Всъщност въпросното устройство е тайминг модул, който при получаване на дадено събитие, да подаден тригер на няколко ADC-та (които също са "закачени" за VME бъса) да започнат data taking и да уведоми чрез прекъсване процес в user space, че има данни за "събиране" от паметта на ADC-тата. Четенето и писането в "контролните" регистри на таймера е за да определиш колко да забави тригера към ADC-тата и прекъсването към user space процеса, за да може да се уцели точния момент за дата такинг (става въпрос за милисекунди и обикновено event generation-а е програмиран така че да се разпространява по тайминг системата маалко преди събитието реално да настъпи). Та в този контекст, как мога да използвам "write" и какво точно имаше предвид с твоето предложение? Целия този setup е за един малък ускорител (Photo Injector Test Facility Zeuthen - PITZ), но понеже сега на физиците им е писнало да плащат луди пари за SPARC/Solaris за VME крейтовете си, искат да пробват с PowerPC/Linux как ще стане Днеска ще питам шефовете дали мога да постна една снимка на "желязото", да придобиете по ясна представа за какво говоря. Понеже и на мене са ми малко неясни нещата още, ще се радвам на въпроси, тъкмо обяснявайки, ще затвърждавам и мойте знания. И като малко допълнение към лирическото отклонение - тук пак има доста устройства, които трябва да се контролират и от които трябва да се изчитат данни. За целта е разработена тъй наречената Distributed Object Oriented Control System (DOOCS) , където се използват RPC calls. Титла: Проблем с "struct cdev" и "struct semaphore" Публикувано от: tarator в Aug 14, 2007, 17:31 > Ясно, но според мен администрацията на мрежа от машини с такава ОС,
> с достатъчно много потребители и привилегии, ще е един малък ад Мислиш като Юникс сисадмин, който по неволя трябва да контролира всичко. В Юникс трябва да се дефинира какви права има даден потребител да използва определен ресурс на _всеки_ компютър (потребител А може да печата на принтер П на сървър С). И понеже това е ужасно трудно, се налага авторитатно управление, при което конфигурациите са централни и ако даден потребител поиска нещо малко по-различно започват мъките му с администраторите. В Plan9 правата се дават за ресурс, независимо къде ще се използват. Ако можеш да четеш и пишеш даден файл, можеш да го правиш от всеки компютър Потребителя има "root" (т.е. пълни права) на терминала, който използва (все пак има физически достъп до него). И по-точно файловете, предоставящи достъп до локалните устройства са собственост на потребителя, който се е логнал. Ако той поиска, може да даде достъп на други потребители до тях. |