[Xenomai-core] Problem with RTDM descriptors with only rt close handler.

[Xenomai-core] Problem with RTDM descriptors with only rt close handler.

[Gilles Chanteperdrix]

Hi,

I had a problem with an RTDM driver: /proc/xenomai/rtdm/open_fildes
could not close its descriptors. So, I tried with trunk which has
auto-cleanup of RTDM descriptors, to see if descriptors would be closed,
the descriptors were not auto-closed when killing my application
either. After a little investigation, it appears that the problem is
that my drivers had a real-time close handler but no non-realtime
handler, so when close was invoked from a non real-time context (either
/proc/xenomai/rtdm/open_fildes, or the auto-cleanup routine), the
default close handler installed by RTDM simply returned -38 and close
aborted.

The way to fix this issue was rather simple: implement a non real-time
close handler, but I find this behaviour a bit disturbing, maybe
implementing a non real-time close handler could be mandatory ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Problem with RTDM descriptors with only rt close handler.

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Hi,
> 
> I had a problem with an RTDM driver: /proc/xenomai/rtdm/open_fildes
> could not close its descriptors. So, I tried with trunk which has
> auto-cleanup of RTDM descriptors, to see if descriptors would be closed,
> the descriptors were not auto-closed when killing my application
> either. After a little investigation, it appears that the problem is
> that my drivers had a real-time close handler but no non-realtime
> handler, so when close was invoked from a non real-time context (either
> /proc/xenomai/rtdm/open_fildes, or the auto-cleanup routine), the
> default close handler installed by RTDM simply returned -38 and close
> aborted.
> 
> The way to fix this issue was rather simple: implement a non real-time
> close handler, but I find this behaviour a bit disturbing, maybe
> implementing a non real-time close handler could be mandatory ?
> 

It is, read the fine manual :). Moreover, if you had validated your
driver via CONFIG_XENO_OPT_DEBUG_RTDM, you would have got an error on
registration. But given the now even more required close_nrt handler, I
think decoupling this particular check from the debug switch is
appropriate. Will fix.

Jan


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

Re: [Xenomai-core] Problem with RTDM descriptors with only rt close handler.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Hi,
 > > 
 > > I had a problem with an RTDM driver: /proc/xenomai/rtdm/open_fildes
 > > could not close its descriptors. So, I tried with trunk which has
 > > auto-cleanup of RTDM descriptors, to see if descriptors would be closed,
 > > the descriptors were not auto-closed when killing my application
 > > either. After a little investigation, it appears that the problem is
 > > that my drivers had a real-time close handler but no non-realtime
 > > handler, so when close was invoked from a non real-time context (either
 > > /proc/xenomai/rtdm/open_fildes, or the auto-cleanup routine), the
 > > default close handler installed by RTDM simply returned -38 and close
 > > aborted.
 > > 
 > > The way to fix this issue was rather simple: implement a non real-time
 > > close handler, but I find this behaviour a bit disturbing, maybe
 > > implementing a non real-time close handler could be mandatory ?
 > > 
 > 
 > It is, read the fine manual :). Moreover, if you had validated your
 > driver via CONFIG_XENO_OPT_DEBUG_RTDM, you would have got an error on
 > registration. But given the now even more required close_nrt handler, I
 > think decoupling this particular check from the debug switch is
 > appropriate. Will fix.

I have to say that I did not really test trunk, I backported the
auto-cleanup stuff to the version of the v2.3.x branch that I am
using. So, if the debug check was added after this commit, I missed it
completely.

-- 


					    Gilles Chanteperdrix.