[Xenomai-help] newby question, can/socket stuff

[Xenomai-help] newby question, can/socket stuff

[roland Tollenaar]

Hi,

I am looking through the rtcan code provided with the xenomai package
and I realize one thing:

I know too little of the basic socket programming. Not even sure my
wording in the previous sentence is capturing the correct area of
ignorance.

I suspect very strongly that the rtcan functionality is designed to
piggyback on whatever standard iocontrol is taking place in functions
like

ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);

and
ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);

But exactly what is happening is beyond me at the moment.

Now I can obviously try to copy like a chinaman (no disrespect
intended!) and not understand what I am doing but it is not really a
mode of operation I relish.

I have briefly tried to locate the rt_dev_ioctl back to a xenomai
header but have not managed to trace it yet.

Is it defined in the standard linux ioctl headers? Where can I find
some info on what arguments these functions are passed etc?

Much appreciated.

Regards,

Roland.

Re: [Xenomai-help] newby question, can/socket stuff

[Gilles Chanteperdrix]

roland Tollenaar wrote:
 > Hi,
 > 
 > I am looking through the rtcan code provided with the xenomai package
 > and I realize one thing:
 > 
 > I know too little of the basic socket programming. Not even sure my
 > wording in the previous sentence is capturing the correct area of
 > ignorance.
 > 
 > I suspect very strongly that the rtcan functionality is designed to
 > piggyback on whatever standard iocontrol is taking place in functions
 > like
 > 
 > ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);
 > 
 > and
 > ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);
 > 
 > But exactly what is happening is beyond me at the moment.
 > 
 > Now I can obviously try to copy like a chinaman (no disrespect
 > intended!) and not understand what I am doing but it is not really a
 > mode of operation I relish.
 > 
 > I have briefly tried to locate the rt_dev_ioctl back to a xenomai
 > header but have not managed to trace it yet.
 > 
 > Is it defined in the standard linux ioctl headers? Where can I find
 > some info on what arguments these functions are passed etc?
 > 
 > Much appreciated.

If you start from:
http://www.xenomai.org/documentation/trunk/html/api/group__userapi.html#g72b69315a44f235b05627a0c257c01f4

And follow the links, you will arrive at:
http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newby question, can/socket stuff

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi,
> 
> I am looking through the rtcan code provided with the xenomai package
> and I realize one thing:
> 
> I know too little of the basic socket programming. Not even sure my
> wording in the previous sentence is capturing the correct area of
> ignorance.

There are plenty text books on BSD socket programming and the rational 
behind it.

> I suspect very strongly that the rtcan functionality is designed to
> piggyback on whatever standard iocontrol is taking place in functions
> like
> 
> ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);
> 
> and
> ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);
> 
> But exactly what is happening is beyond me at the moment.

SIOCGIFINDEX gets the interface index for a named device and 
SIOCSCANBAUDRATE allows to set the baudrate. The RT-Socket-CAN utilities 
are now even hyperlinked with the API doc (still not 100% perfect yet) e.g.:

http://www.xenomai.org/documentation/trunk/html/api/rtcanconfig_8c-example.html

> Now I can obviously try to copy like a chinaman (no disrespect
> intended!) and not understand what I am doing but it is not really a
> mode of operation I relish.
> 
> I have briefly tried to locate the rt_dev_ioctl back to a xenomai
> header but have not managed to trace it yet.

> Is it defined in the standard linux ioctl headers? Where can I find
> some info on what arguments these functions are passed etc?

Hm, try:

$ cd <xenomai-root>
$ find . -name '*.[ch]' | xargs grep SIOCSCANBAUDRATE

> Much appreciated.

Wolfgang.

Re: [Xenomai-help] newby question, can/socket stuff

[roland Tollenaar]

>
> And follow the links, you will arrive at:
> http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html

Actually this is where I had been spending most of my time before
posting my mail.

I must be blind because I really do not see anything remotely
resembling functions like:

rt_dev_ioctl(arg1, arg2, and maybe arg 3 don;t know off by heart anymore)

Are you sure the above is the link I must look at?

Regards,

Roland


>
> --
>
>
>                                             Gilles Chanteperdrix.
>

Re: [Xenomai-help] newby question, can/socket stuff

[roland Tollenaar]

Hi,


You must all be getting very exasperated with me. :)

> > I know too little of the basic socket programming. Not even sure my
> > wording in the previous sentence is capturing the correct area of
> > ignorance.
>
> There are plenty text books on BSD socket programming and the rational
> behind it.
These are the ones I need. But without the time to get hold of them I
will have to search the net.

> > ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);
> >
> > and
> > ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);
> >
> > But exactly what is happening is beyond me at the moment.
>
> SIOCGIFINDEX gets the interface index for a named device and
> SIOCSCANBAUDRATE allows to set the baudrate. The RT-Socket-CAN utilities

My email must have been very bad. I realize roughly what SIOCGIFINDEX
and  SIOCSCANBAUDRATE do. This is described very nicely in your
documentation or rather the documentation that refers to you and which
Gilles kindly also pointed out to me but which I already knew about.

No my problem is with the
rt_dev_ioctl

part. I would like to have a better understanding of the part that
these functions play.

> are now even hyperlinked with the API doc (still not 100% perfect yet) e.g.:
>
> http://www.xenomai.org/documentation/trunk/html/api/rtcanconfig_8c-example.html

And by tremendous chance this was also the code I was studying when I
posted my email.

Sorry to be such a nuisance. I'll see if I can google for some info on
rt_dev_ioctl.

Regards,

Roland


>
> > Now I can obviously try to copy like a chinaman (no disrespect
> > intended!) and not understand what I am doing but it is not really a
> > mode of operation I relish.
> >
> > I have briefly tried to locate the rt_dev_ioctl back to a xenomai
> > header but have not managed to trace it yet.
>
> > Is it defined in the standard linux ioctl headers? Where can I find
> > some info on what arguments these functions are passed etc?
>
> Hm, try:
>
> $ cd <xenomai-root>
> $ find . -name '*.[ch]' | xargs grep SIOCSCANBAUDRATE
>
> > Much appreciated.
>
> Wolfgang.
>

Re: [Xenomai-help] newby question, can/socket stuff

[Wolfgang Grandegger]

roland Tollenaar wrote:
>>
>> And follow the links, you will arrive at:
>> http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html
> 
> Actually this is where I had been spending most of my time before
> posting my mail.
> 
> I must be blind because I really do not see anything remotely
> resembling functions like:
> 
> rt_dev_ioctl(arg1, arg2, and maybe arg 3 don;t know off by heart anymore)
> 
> Are you sure the above is the link I must look at?

The RTDM user API is listed at 
http://www.xenomai.org/documentation/trunk/html/api/group__userapi.html 
including rt_dev_ioctl() but this will point you back to the profiles.

Wolfgang.

Re: [Xenomai-help] newby question, can/socket stuff

[Gilles Chanteperdrix]

roland Tollenaar wrote:
 > >
 > > And follow the links, you will arrive at:
 > > http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html
 > 
 > Actually this is where I had been spending most of my time before
 > posting my mail.
 > 
 > I must be blind because I really do not see anything remotely
 > resembling functions like:
 > 
 > rt_dev_ioctl(arg1, arg2, and maybe arg 3 don;t know off by heart anymore)
 > 
 > Are you sure the above is the link I must look at?

Yes, Ok, you need a bit of knowledge of how ioctl works. The first
argument is the socket/file descriptor, the second argument is a
command, and the third argument an argument to that command.

The commands are those listed in the section entitled "IOCTLs". Now, if
you read:
#define SIOCGIFINDEX   _IOWR(RTIOC_TYPE_CAN, 0x00, struct ifreq)

You are supposed to understand that SIOCGIFINDEX is a valid command,
that the argument of this command is a pointer to a "struct ifreq", and
that this command reads and writes to this structure. Since the text
below this define is "Get CAN interface index by name", you should
understand that you have to use it that way:

struct ifreq ir;
ir.ifr_name = "rtcan0";
rt_dev_ioctl(socket, SIOCGIFINDEX, &ir);
index = ir.ifr_ifindex;

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newby question, can/socket stuff

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

roland Tollenaar wrote:
> Hi,
> 
> 
> You must all be getting very exasperated with me. :)

How did you guess this? ;)

> 
>> > I know too little of the basic socket programming. Not even sure my
>> > wording in the previous sentence is capturing the correct area of
>> > ignorance.
>>
>> There are plenty text books on BSD socket programming and the rational
>> behind it.
> These are the ones I need. But without the time to get hold of them I
> will have to search the net.

"man" is your friend (if installed on your linux distro). E.g.

# man recvmsg

Then there is the OpenGroups spec:

http://www.opengroup.org/onlinepubs/009695399/

But I thing before diving too deep into this, rather apply the
Chinaman's tactic.

> 
>> > ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);
>> >
>> > and
>> > ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);
>> >
>> > But exactly what is happening is beyond me at the moment.
>>
>> SIOCGIFINDEX gets the interface index for a named device and
>> SIOCSCANBAUDRATE allows to set the baudrate. The RT-Socket-CAN utilities
> 
> My email must have been very bad. I realize roughly what SIOCGIFINDEX
> and  SIOCSCANBAUDRATE do. This is described very nicely in your
> documentation or rather the documentation that refers to you and which
> Gilles kindly also pointed out to me but which I already knew about.
> 
> No my problem is with the
> rt_dev_ioctl
> 
> part. I would like to have a better understanding of the part that
> these functions play.

Add 1 to 1: The CAN profile describes what IOCTLs are available for CAN
sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the way to
pass these IOCTLs down to the CAN stack.

I think this should be visible when making one step back, looking at the
whole picture of the documentation pieces and the examples, no?

> 
>> are now even hyperlinked with the API doc (still not 100% perfect yet)
>> e.g.:
>>
>> http://www.xenomai.org/documentation/trunk/html/api/rtcanconfig_8c-example.html
>>
> 
> And by tremendous chance this was also the code I was studying when I
> posted my email.
> 
> Sorry to be such a nuisance. I'll see if I can google for some info on
> rt_dev_ioctl.
> 
> Regards,
> 
> Roland
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] newby question, can/socket stuff

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi,
> 
> 
> You must all be getting very exasperated with me. :)

Why, you seem to be exasperated ;-).

>> > I know too little of the basic socket programming. Not even sure my
>> > wording in the previous sentence is capturing the correct area of
>> > ignorance.
>>
>> There are plenty text books on BSD socket programming and the rational
>> behind it.
> These are the ones I need. But without the time to get hold of them I
> will have to search the net.
> 
>> > ret = rt_dev_ioctl(can_fd, SIOCGIFINDEX, &ifr);
>> >
>> > and
>> > ret = rt_dev_ioctl(can_fd, SIOCSCANBAUDRATE, &ifr);
>> >
>> > But exactly what is happening is beyond me at the moment.
>>
>> SIOCGIFINDEX gets the interface index for a named device and
>> SIOCSCANBAUDRATE allows to set the baudrate. The RT-Socket-CAN utilities
> 
> My email must have been very bad. I realize roughly what SIOCGIFINDEX
> and  SIOCSCANBAUDRATE do. This is described very nicely in your
> documentation or rather the documentation that refers to you and which
> Gilles kindly also pointed out to me but which I already knew about.
> 
> No my problem is with the
> rt_dev_ioctl
> 
> part. I would like to have a better understanding of the part that
> these functions play.
> 
>> are now even hyperlinked with the API doc (still not 100% perfect yet) 
>> e.g.:
>>
>> http://www.xenomai.org/documentation/trunk/html/api/rtcanconfig_8c-example.html 
>>
> 
> And by tremendous chance this was also the code I was studying when I
> posted my email.
> 
> Sorry to be such a nuisance. I'll see if I can google for some info on
> rt_dev_ioctl.

Unfortunately, there is a problem with hyperlinking rt_dev_ioctl() in 
Doxygen :-(.

Wolfgang.

> 
> Regards,
> 
> Roland
> 
> 
>>
>> > Now I can obviously try to copy like a chinaman (no disrespect
>> > intended!) and not understand what I am doing but it is not really a
>> > mode of operation I relish.
>> >
>> > I have briefly tried to locate the rt_dev_ioctl back to a xenomai
>> > header but have not managed to trace it yet.
>>
>> > Is it defined in the standard linux ioctl headers? Where can I find
>> > some info on what arguments these functions are passed etc?
>>
>> Hm, try:
>>
>> $ cd <xenomai-root>
>> $ find . -name '*.[ch]' | xargs grep SIOCSCANBAUDRATE
>>
>> > Much appreciated.
>>
>> Wolfgang.
>>
> 
> 

Re: [Xenomai-help] newby question, can/socket stuff

[roland Tollenaar]

Hi,

> > You must all be getting very exasperated with me. :)
>
> How did you guess this? ;)
It generally happens when one asks silly questions .:)


>
> "man" is your friend (if installed on your linux distro). E.g.
>
> # man recvmsg
I have man but seem to have no entry for recvmsg, recv or recvfrom. I
hope this does not mean the functions will not be available on my
system.....

>
> Then there is the OpenGroups spec:
>
> http://www.opengroup.org/onlinepubs/009695399/
>
> But I thing before diving too deep into this, rather apply the
> Chinaman's tactic.
Had a look at it and you know what? I think you are right :(
I will settle for the semi-chinaman technique.....

> > No my problem is with the
> > rt_dev_ioctl
> >
> > part. I would like to have a better understanding of the part that
> > these functions play.
>
> Add 1 to 1: The CAN profile describes what IOCTLs are available for CAN
> sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the way to
> pass these IOCTLs down to the CAN stack.

Actually this sheds quite a bit of light on matters. If you would be
so kind as to give a brief explanation of what a "stack" is exactly. I
have been confronted with the term quite a lot now but its not
becoming clearer. I used to think it was a buffer of some kind. Kind
of like the ones that one "pushes" and "pops" on but I can't see a
connection between that concept and what you say above.


>
> I think this should be visible when making one step back, looking at the
> whole picture of the documentation pieces and the examples, no?
Absolutely. Thanks.


Regards,

Roland.


>
> >
> >> are now even hyperlinked with the API doc (still not 100% perfect yet)
> >> e.g.:
> >>
> >> http://www.xenomai.org/documentation/trunk/html/api/rtcanconfig_8c-example.html
> >>
> >
> > And by tremendous chance this was also the code I was studying when I
> > posted my email.
> >
> > Sorry to be such a nuisance. I'll see if I can google for some info on
> > rt_dev_ioctl.
> >
> > Regards,
> >
> > Roland
> >
>
> Jan
>
>
>

Re: [Xenomai-help] newby question, can/socket stuff

[roland Tollenaar]

Hi,

> > You must all be getting very exasperated with me. :)
>
> Why, you seem to be exasperated ;-).
But I have good cause to be. I am the one not understanding what you
all find so obviously clear. :)

> Unfortunately, there is a problem with hyperlinking rt_dev_ioctl() in
> Doxygen :-(.
Pity, but don't worry. Jan's explanation earlier elucidates matters
tremendously.

Thanks,

Roland


>
> Wolfgang.
>
> >
> > Regards,
> >
> > Roland
> >
> >
> >>
> >> > Now I can obviously try to copy like a chinaman (no disrespect
> >> > intended!) and not understand what I am doing but it is not really a
> >> > mode of operation I relish.
> >> >
> >> > I have briefly tried to locate the rt_dev_ioctl back to a xenomai
> >> > header but have not managed to trace it yet.
> >>
> >> > Is it defined in the standard linux ioctl headers? Where can I find
> >> > some info on what arguments these functions are passed etc?
> >>
> >> Hm, try:
> >>
> >> $ cd <xenomai-root>
> >> $ find . -name '*.[ch]' | xargs grep SIOCSCANBAUDRATE
> >>
> >> > Much appreciated.
> >>
> >> Wolfgang.
> >>
> >
> >
>
>

Re: [Xenomai-help] newby question, can/socket stuff

[Paul]

On Monday 26 February 2007 20:37, roland Tollenaar wrote:
> > "man" is your friend (if installed on your linux distro). E.g.
> >
> > # man recvmsg
>
> I have man but seem to have no entry for recvmsg, recv or recvfrom. I
> hope this does not mean the functions will not be available on my
> system.....

Some distros package the more interesting pages in manpages-dev

 On the subject of text books - Richard Stevens, Unix Network Programming 
Vol.1 & 2 must still rank as the bible. Or for a quick intro, Advanced Linux 
Programming from CodeSourcery - quick link: 
http://lycos.dropcode.net/docs/Advanced Linux Programming/

If you had been local to me, I could have loaned you the UNP tomes...


Regards, Paul.

Re: [Xenomai-help] newby question, can/socket stuff

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

roland Tollenaar wrote:
>> Add 1 to 1: The CAN profile describes what IOCTLs are available for CAN
>> sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the way to
>> pass these IOCTLs down to the CAN stack.
> 
> Actually this sheds quite a bit of light on matters. If you would be
> so kind as to give a brief explanation of what a "stack" is exactly. I
> have been confronted with the term quite a lot now but its not
> becoming clearer. I used to think it was a buffer of some kind. Kind
> of like the ones that one "pushes" and "pops" on but I can't see a
> connection between that concept and what you say above.

http://en.wikipedia.org/wiki/Protocol_stack? :->

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] newby question, can/socket stuff

[Roland Tollenaar]

Hi,

Absolutely clear. From the metaphorical chinaman's point of view that is. :)

Thanks all.

Roland.


Jan Kiszka wrote:
> Roland Tollenaar wrote:
>> Hi
>>
>>>>> Add 1 to 1: The CAN profile describes what IOCTLs are available for CAN
>>>>> sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the way to
>>>>> pass these IOCTLs down to the CAN stack.
>>>> Actually this sheds quite a bit of light on matters. If you would be
>>>> so kind as to give a brief explanation of what a "stack" is exactly. I
>>>> have been confronted with the term quite a lot now but its not
>>>> becoming clearer. I used to think it was a buffer of some kind. Kind
>>>> of like the ones that one "pushes" and "pops" on but I can't see a
>>>> connection between that concept and what you say above.
>>> http://en.wikipedia.org/wiki/Protocol_stack? :->
>> Thanks.
>>
>> Would that mean that the protocol stack we are looking at is something
>> like this?:
> 
> Yep.
> 
>> CANOpen (in my application)
>> RTCAN (incorporated in Xenomai)
>> CAN Driver (e.g. the PEAK dongle dirver)
>> Parallel port driver
> 
> That driver doesn't exist here technically.
> 
>> :
>> Parallel Port Hardware
>> Dongle
>>
>> Whereby the last two would officially not make out part of the protocol
>> stack.
>>
>> and rt_dev_ioctl passes the IOCTLS to the layer RTCAN in my example above?
>>
> 
> Yes.
> 
>> And in this text
>>>>> Add 1 to 1: The CAN profile describes what IOCTLs are available for
>>>>> CAN sockets. rt_dev_ioctl() (or ioctl() with the POSIX skin) is the
>>>>> way to pass these IOCTLs down to the CAN stack.
>> the final word should technically speaking not be "stack" but rather
>> "layer". ?
> 
> Yes and no. The first layer to see the request is the CAN protocol
> layer, but it may decide to pass it down to the driver, which may decide
> to hand it to the hardware. That's why I was speaking of the whole thing
> "stack" here.
> 
>> If all the above is a roughly correct understanding of the situation I
>> should be able to make a bit more sense out of the CAN code.
>>
>> Thanks,
>>
>> Roland
>>
> 
> Jan
>