Linux за българи: Форуми

Програмиране => Общ форум => Темата е започната от: halturata в Aug 09, 2007, 18:23



Титла: Проблем с "struct cdev" и "struct semaphore"
Публикувано от: halturata в Aug 09, 2007, 18:23
Здравейте,

Работата е следната - написах си едно малко тестово драйверче, като упражнение към тази книга, и също като прелюдия към написването на функционален драйвер.
За да изпробвам докъде съм я докарал (вече имам open(), read(), write(), ioctl() функциите) си написах проста програмка, за да видя дали въобще ще работят както очаквам:
Примерен код
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>       /* mmap() */
#include <fcntl.h>        /* open(), close(), etc. */
#include <unistd.h>       /* exit() */
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/cdev.h>

#include "iptimer_ppc_linux26_fnc.h"
#include "iptimer_ppc_linux26_io.h"

int main(int argc, char ** args)
{
      int fd, status = 0;
      unsigned long quantum, qset;
      
      if( (status = open("/dev/iptimer0", O_RDWR)) < 0 ){
            perror("open");
            printf("Error opening /dev/iptimer device file, errno = %d\n", errno);
            exit (1);
      }
      
      if((status = ioctl(fd, IPTIMER_IOCTL_GET_QUANTUM, quantum)) < 0 ){
            perror("ioctl");
            printf("Error getting quantum, errno = %d\n", errno);
            exit (1);
      }
      printf("*** quantum = %d", quantum);

      if((status = ioctl(fd, IPTIMER_IOCTL_GET_QSET, qset)) < 0 ){
            perror("ioctl");
            printf("Error getting qset, errno = %d\n", errno);
            exit (1);
      }
      printf("*** qset = %d", qset);      
      
      return 0;
}

Когато се опитам да я компилирам обаче, получавам следните грешки:
Примерен код
pi3 ~ELINOS_PROJECT/src/rwtest # make
/opt/elinos-4.1/cdk/ppc/60x/glibc-2.3.4/bin/ppc_60x-gcc -c -o main.o -g main.c
In file included from main.c:13:
iptimer_ppc_linux26_fnc.h:32: error: field `iptimer_cdev' has incomplete type
iptimer_ppc_linux26_fnc.h:33: error: field `iptimer_sem' has incomplete type
make: *** [main.o] Error 1

Ето го въпросното място в хедъра където гърми:
Примерен код
struct iptimer_dev{
      iptimer_qset_t   *iptimer_data;      /* Pointer to first quantum set */
      int                    quantum;            /* The current quantum size */
      int                    qset;               /* The current array size */
      unsigned long int  size;             /* Amount of data stored */
      struct cdev           ptimer_cdev;  /* Char device structure */
      struct semaphore  iptimer_sem;       /* Mutual exclusion semaphore */
      int                       dev_minor;                        
};

Така, тези двете структури на семафора и чаръктър дивайса (омг...) са дефинирани без typedef в кода на ядрото. Въпроса ми е как да оправя тези грешки при компилацията? Иначе драйвера се компилира без проблем. Ето и линк към сорса ако някой се интересува.

Всякакви идеи и флейм са добре дошли :)

P.S. Ето ги и въпросните дефиниции на struct semaphore / struct cdev:
Примерен код
#ifndef _LINUX_CDEV_H
#define _LINUX_CDEV_H
#ifdef
 
struct cdev {
         struct kobject kobj;
         struct module *owner;
         struct file_operations *ops;
         struct list_head list;
         dev_t dev;
         unsigned int count;
 };

Примерен код
#ifdef
 #ifndef _ASM_POWERPC_SEMAPHORE_H
 #define _ASM_POWERPC_SEMAPHORE_H
 #include <asm/atomic.h>
 #include <asm/system.h>
 #include <linux/wait.h>
 #include <linux/rwsem.h>
 
 struct semaphore {
         atomic_t count;
         wait_queue_head_t wait;
 };


Примерен код
07-08-09 12:41 :( # uname -a
Linux 2.4.21-47.0.1.ELsmp #1 SMP Thu Oct 19 10:46:05 CDT 2006 i686 i686 i386 GNU/Linux
07-08-09 12:52 :( # $CC --version
ppc_60x-gcc (GCC) 3.4.4

Да не би да трябва да пъхна някой от тези #define statementsв моя код?


Титла: Проблем с "struct cdev" и "struct semaphore"
Публикувано от: the_real_maniac в Aug 09, 2007, 20:52
Не знам дали ще имам време да погледна, но поне да се разпиша че ми е интересно...

пп: а не трябва ли да отчетеш факта , че може би проблема е че правиш cross compile :?  и може би там нещо ...

едит:

_ASM_POWERPC_SEMAPHORE_H

Примерен код

07-08-09 12:41 :( # uname -a
Linux 2.4.21-47.0.1.ELsmp #1 SMP Thu Oct 19 10:46:05 CDT 2006 i686 i686 i386 GNU/Linux
07-08-09 12:52 :( # $CC --version
ppc_60x-gcc (GCC) 3.4.4






Титла: Проблем с "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

Цитат

#ifdef _ _ K E R N E L _ _


 в хедърите забеляза ли? :Р Не можеш да използваш тези структури в 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
Цитат (tarator @ Авг. 11 2007,06:50)
Разбира се, че имам, не говоря наизуст. Едно време от файловете се е четяло и се е писало в тях. Много авангардна идея, нали? :)

А ти имаш ли някаква идея защо смятам, че ioctl са идиотщина, или ги защитаваш без да мислиш? :)

Просто попитах, не съм ползвал нещо различно от ioctl < така че това е идеята..

пп: не си чешам езика, така че не -> не пиша без да мисля :D 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 @ Авг. 10 2007,02:07)
A

Цитат

#ifdef _ _ K E R N E L _ _


 в хедърите забеляза ли? :Р Не можеш да използваш тези структури в userspace.

P.S. Нещо форума "забравя" _ _ K E R N E L _ _ ако го напиша както трябва

За протокола: Значи 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
Цитат (tarator @ Авг. 13 2007,18:05)
> Толкова ли много ти/ви пречи това, че не може да ползвате ioctl през
> мрежата :?

Да. Такива неща показват дали една операционна система е мрежова, или мрежата е добавена впоследствие и не толкова добре.

Да, съгласен, сега те/Ви разбирам напълно ;-) :-)

Ще си позволя едно лирично отклонение, примери по-скоро:

във вградени системи ... автоматизации , прочие...
датчиците са 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" (т.е. пълни права) на терминала, който използва (все пак има физически достъп до него). И по-точно файловете, предоставящи достъп до локалните устройства са собственост на потребителя, който се е логнал. Ако той поиска, може да даде достъп на други потребители до тях.