Re: [Xenomai] xenomai-3.0-rc5 : binding named semaphores from external process

[Frederik Bayart <frederik_bayart@yahoo.co.uk>]

>> ./stest --session=foo 1
>>
>> The first process binds to the named semaphore which is not yet created. According to the description of rt_sem_bind,  if the object does not exist on entry, the caller may block until a semaphore of the given name is created.
>>
>> So based on this description, I would I expect that if the second process is started, the first process would bind and continue and blocks in the p operation. The same for the 2nd process. Is this correct ? At the moment, if I start the 2nd process, I get a segfault in rt_sem_create :
>>
>> [ 9758.887921] [Xenomai] switching main to secondary mode after exception #14 from user-space at 0x7f6ad8c4a43e (pid 9256)
>> [ 9758.887930] main[9256]: segfault at 7f903bf6e038 ip 00007f6ad8c4a43e sp 00007fffbd2c2eb8 error 6 in libcobalt.so.2.0.0[7f6ad8c3d000+1e000]
>>
>
>Looking at the copperplate code, yep, this definitely can't work. Ok,
>queued.

I noticed also :

 ./stest --session=foo 1
 ./stest --session=foo 0

Both processes are waiting in rt_sem_p . The first process catches SIGINT, the second doesn't. If you press CTRL+C on the second process it stops but also the first process is falling through the rt_sem_p although no rt_sem_v is raised. At that moment no process is pending on rt_sem_p anymore. But if you do then a rt_sem_inquire, nwaiters is still 1.
>
>>
>> 2)
>>
>> The fuse filesystem is not unmounted. This is because in xenomai-3.0-rc5/lib/copperplate/regd/regd.c the fullpath is hardcoded to fusermount and umount
>>
>> I could fixed it, with the diff below. It's not clear to me why access of umount is tested and not from fusermount.
>>
>
>Piping the "which" output seems seriously overkill. Besides, we don't
>want to rely on the environment to find those paths, we are running with
>supervisor privileges (i.e. we don't want to run what the user tells us
>what "umount" should be, but rather what the distro actually says
>"umount" is).
>
>Per LSB 3.0, /bin/umount would be the place to find this, so basically,
>testing a couple of reasonable locations should be enough.
>
>
>-- 
>Philippe.