From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F84A7C.8000909@domain.hid> Date: Fri, 17 Oct 2008 10:19:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20081016145757.935266172@domain.hid> <48F76068.7050903@domain.hid> <48F76362.4010104@domain.hid> <48F79F7A.2030304@domain.hid> <48F7B98D.8040000@domain.hid> <48F84233.1050003@domain.hid> <48F844D8.3060601@domain.hid> In-Reply-To: <48F844D8.3060601@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig33CEDF38CF695278A98A70BE" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-core] [PATCH 0/2] Fix and improve task/thread inquire services List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33CEDF38CF695278A98A70BE Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Philippe Gerum wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >>> Philippe Gerum wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Jan Kiszka wrote: >>>>>>> This series fixes the issues around rt_task_inquire I posted yest= erday. >>>>>>> Additionally, it introduces an analogous services pthread_inquire= _np for >>>>>>> the POSIX skin. That allows, among other things, to implement tes= t cases >>>>>>> for the upcoming fast xnsynch/mutex patches. >>>>>> Ok. Since this applies only for debugging purpose, and displaying >>>>>> whether a task is in primary mode may be use badly by users, maybe= we >>>>>> should make this service a shadow syscall, and not export any inte= rface >>>>>> to use it. This would further avoid duplication between the native= and >>>>>> posix skins. >>>>> Debugging is not the holy, exclusive business of Xenomai hackers. >>>>> >>>>> The inquire services are useful in libraries as well, when you want= to >>>>> check if the caller complies to the call convention ("don't use in >>>>> primary mode", "caller's priority must not exceed X" or whatever). >>>>> >>>>> That said, I'm open for unifying the code, maybe introducing some >>>>> xnthread_inquire. >>>>> >>>> That would be much better than publishing an open interface to fiddl= e even more >>>> with thread modes via rt_task_set_mode(). I would definitely merge t= hat. >>> Code refactoring is no problem, will work that out. I just want to ke= ep >>> the user interface. >> Looking into this, I come to the conclusion that xnthread_inquire is >> only then a gain if both rt_task_inquire and pthread_inquire_np use th= e >> same data structure layout. And that means that both need to use the >> same time encodings, not struct timespec vs. RTIME like it is now. Tha= t >> would not be beautiful, but feasible (e.g. picking __u64 as type, >> passing nanoseconds). Still, it does not yet convince me. >> >=20 > The idea behind xnthread_inquire() is not about replacing rt_task_inqui= re() > under the hood, but rather to get back only fundamental values, such as= the > current thread status, in order to determine whether XNRELAX is set or = not for > instance. >=20 > XENOMAI_SYSCALL1(__xn_sys_inquire) =3D> xnthread_inquire(xnpod_current_= thread()) OK, slowly getting to your core. Assume we had __xn_sys_inquire, what should it return, and what should we mask from rt_task_inquire, and do we still want pthread_inquire_np. But I really dislike this approach of artificially complicating/crippling interfaces just to hide XNRELAX (I can't imagine you have problems with the other information rt_task_inquire returns). Jan --------------enig33CEDF38CF695278A98A70BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkj4Sn8ACgkQniDOoMHTA+ncJgCfeeL7twudtsEe2APLC8F2UwB7 zp8An0mVhvRzZ8FmDh8kL+tjReE6EvIF =81hl -----END PGP SIGNATURE----- --------------enig33CEDF38CF695278A98A70BE--