All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH] systemd_git.bb: Alias mkostemp() to mkstemp() for uclibc targets
Date: Fri, 01 Jul 2011 10:11:12 -0700	[thread overview]
Message-ID: <4E0DFFB0.7080806@gmail.com> (raw)
In-Reply-To: <1309530191.2633.63.camel@phil-desktop>

On 07/01/2011 07:23 AM, Phil Blundell wrote:
> On Fri, 2011-07-01 at 06:48 -0700, Khem Raj wrote:
>>
>> On Jul 1, 2011, at 2:48 AM, Phil Blundell<philb@gnu.org>  wrote:
>>
>>> On Thu, 2011-06-30 at 22:38 -0700, Khem Raj wrote:
>>>> ++#ifdef __UCLIBC__
>>>> ++/* uclibc does not implement mkostemp GNU extention */
>>>> ++#define mkostemp(x,y) mkstemp(x)
>>>> ++#endif
>>>
>>> Is that safe?  It would be nice to have some commentary in the patch
>>> explaining why the flags are not required for systemd to operate
>>> correctly.  If it genuinely doesn't need to be using mkostemp() then
>>> perhaps this change should just be made upstream for all libcs.
>>>
>> right
>> I have to test it eglibc systems
>
> I'm not sure that's quite the point.  What I was trying to say before
> was that, if systemd is going to the trouble of using mkostemp() rather
> than mkstemp() in the first place, one would normally assume that it is
> expecting that extra argument to be respected.  So it seems like there
> are two possibilities:
>
> a) the standardised semantics of mkstemp() are actually sufficient for
> systemd's requirements and there was no need for it to be using
> mkostemp() at all.  In this case it should just be patched (ideally
> upstream) to use mkstemp() unconditionally.

yes I was using a mobile device did not type too much but this is the 
case I am inclined to test.

>
> b) the specific semantics of uClibc's mkstemp() implementation are
> sufficient for systemd's needs, although the semantics guaranteed by the
> standards are not.  In this case your patch might be appropriate but
> there should be a comment explaining why it is safe and what exactly the
> uClibc behaviour is that it depends on.  This would still not be an
> ideal state of affairs since uClibc might change in the future, but it's
> probably acceptable; a better solution might be either to add mkostemp()
> into uClibc explicitly, or to patch systemd to obtain the semantics that
> it needs by some other route.

no if the flags are needed then uclibc's mkstemp wont work. We have to 
provide an implementation of mkostemp or alter the code in systemd so
it uses something else. But this is second choice. Since uclibc does not 
like the extentions to be implemented.

>
> I'm not familiar enough with either systemd or uClibc to know which of
> the above is true here.  Can you clarify?
>
> p.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel




      reply	other threads:[~2011-07-01 17:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01  5:38 [meta-oe][PATCH] systemd_git.bb: Alias mkostemp() to mkstemp() for uclibc targets Khem Raj
2011-07-01  7:01 ` Koen Kooi
2011-07-01  8:47 ` Paul Menzel
2011-07-01 17:19   ` Khem Raj
2011-07-01  9:48 ` Phil Blundell
2011-07-01 13:48   ` Khem Raj
2011-07-01 14:23     ` Phil Blundell
2011-07-01 17:11       ` Khem Raj [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E0DFFB0.7080806@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.