Patchwork Add init script (sysv) support for busybox's ntpd

login
register
mail settings
Submitter Laszlo Papp
Date March 20, 2014, 3:26 a.m.
Message ID <1395285985-13867-1-git-send-email-lpapp@kde.org>
Download mbox | patch
Permalink /patch/68911/
State New
Headers show

Comments

Laszlo Papp - March 20, 2014, 3:26 a.m.
---
 meta/recipes-core/busybox/busybox.inc             | 10 ++++--
 meta/recipes-core/busybox/busybox_1.22.1.bb       |  2 ++
 meta/recipes-core/busybox/files/busybox-ntpd      | 39 +++++++++++++++++++++++
 meta/recipes-core/busybox/files/busybox-ntpd.conf |  1 +
 4 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd
 create mode 100644 meta/recipes-core/busybox/files/busybox-ntpd.conf
Ross Burton - March 20, 2014, 10:45 a.m.
On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
> +PEER=127.0.0.1

That doesn't seem like a very useful default.  We also can't use the
NTP pool by default, so this should copy the behaviour of the ntpd
package in meta-networking and default to no peers, and not start if
none are specified.

Ross
Koen Kooi - March 20, 2014, 11:22 a.m.
Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:

> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>> +PEER=127.0.0.1
> 
> That doesn't seem like a very useful default.  We also can't use the
> NTP pool by default, so this should copy the behaviour of the ntpd
> package in meta-networking and default to no peers, and not start if
> none are specified.

And the initscript is missing LSB headers.
Laszlo Papp - March 20, 2014, 11:34 a.m.
On Thu, Mar 20, 2014 at 10:45 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>> +PEER=127.0.0.1
>
> That doesn't seem like a very useful default.  We also can't use the
> NTP pool by default, so this should copy the behaviour of the ntpd
> package in meta-networking and default to no peers, and not start if
> none are specified.

Yeah, some real timeserver could be put behind comments.
Laszlo Papp - March 20, 2014, 11:34 a.m.
On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>
>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>>> +PEER=127.0.0.1
>>
>> That doesn't seem like a very useful default.  We also can't use the
>> NTP pool by default, so this should copy the behaviour of the ntpd
>> package in meta-networking and default to no peers, and not start if
>> none are specified.
>
> And the initscript is missing LSB headers.

Just like the other similar scripts.
Otavio Salvador - March 20, 2014, 11:59 a.m.
On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>
>> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>>
>>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>>>> +PEER=127.0.0.1
>>>
>>> That doesn't seem like a very useful default.  We also can't use the
>>> NTP pool by default, so this should copy the behaviour of the ntpd
>>> package in meta-networking and default to no peers, and not start if
>>> none are specified.
>>
>> And the initscript is missing LSB headers.
>
> Just like the other similar scripts.

This does not mean we ought to make the problem worse so add it for
new ones. If you are in good mood, send a fix for the others too ;)
Laszlo Papp - March 20, 2014, 12:16 p.m.
On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp <lpapp@kde.org> wrote:
>> On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>
>>> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>>>
>>>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>>>>> +PEER=127.0.0.1
>>>>
>>>> That doesn't seem like a very useful default.  We also can't use the
>>>> NTP pool by default, so this should copy the behaviour of the ntpd
>>>> package in meta-networking and default to no peers, and not start if
>>>> none are specified.
>>>
>>> And the initscript is missing LSB headers.
>>
>> Just like the other similar scripts.
>
> This does not mean we ought to make the problem worse so add it for
> new ones. If you are in good mood, send a fix for the others too ;)

I do not think this is a problem. Could you please point out what
functionality it breaks? Send patches for the others, and I will make
this cosmetic change for this one, too. Consistency is more important
than a mess of different styles, especially when it comes to cosmetic
changes like this.

That said, Ross had a good point - although that is not critical
either, and since everyone is overriding the default, it could work
without that - , so I will update that one.
Otavio Salvador - March 20, 2014, 12:26 p.m.
On Thu, Mar 20, 2014 at 9:16 AM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>> On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>
>>>> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>>>>
>>>>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>> +PEER=127.0.0.1
>>>>>
>>>>> That doesn't seem like a very useful default.  We also can't use the
>>>>> NTP pool by default, so this should copy the behaviour of the ntpd
>>>>> package in meta-networking and default to no peers, and not start if
>>>>> none are specified.
>>>>
>>>> And the initscript is missing LSB headers.
>>>
>>> Just like the other similar scripts.
>>
>> This does not mean we ought to make the problem worse so add it for
>> new ones. If you are in good mood, send a fix for the others too ;)
>
> I do not think this is a problem. Could you please point out what
> functionality it breaks? Send patches for the others, and I will make
> this cosmetic change for this one, too. Consistency is more important
> than a mess of different styles, especially when it comes to cosmetic
> changes like this.

Koen and I think it is important. So consider this my NACK for the patch as is.

You are free to do whatever you want.

> That said, Ross had a good point - although that is not critical
> either, and since everyone is overriding the default, it could work
> without that - , so I will update that one.

Better.
Laszlo Papp - March 20, 2014, 12:44 p.m.
On Thu, Mar 20, 2014 at 12:26 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Thu, Mar 20, 2014 at 9:16 AM, Laszlo Papp <lpapp@kde.org> wrote:
>> On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>> On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>>>
>>>>> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>>>>>
>>>>>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>>> +PEER=127.0.0.1
>>>>>>
>>>>>> That doesn't seem like a very useful default.  We also can't use the
>>>>>> NTP pool by default, so this should copy the behaviour of the ntpd
>>>>>> package in meta-networking and default to no peers, and not start if
>>>>>> none are specified.
>>>>>
>>>>> And the initscript is missing LSB headers.
>>>>
>>>> Just like the other similar scripts.
>>>
>>> This does not mean we ought to make the problem worse so add it for
>>> new ones. If you are in good mood, send a fix for the others too ;)
>>
>> I do not think this is a problem. Could you please point out what
>> functionality it breaks? Send patches for the others, and I will make
>> this cosmetic change for this one, too. Consistency is more important
>> than a mess of different styles, especially when it comes to cosmetic
>> changes like this.
>
> Koen and I think it is important. So consider this my NACK for the patch as is.

You are free to NACK without an explanation why it is important, but
do not expect it to weigh much that way, at least in my eyes, based on
that you are not even a maintainer as far as I know.

I also think that it is not constructive to give NACK without
answering the questions, and only telling again "It is important".
Please be more constructive and explain the real issue. That is a
better way of convincing a contributor than telling the person it is
bad what you are doing because it is bad.

There was someone today publishing a blog post how important it is to
become pragmatic to get things done. Currently, cosmetic changes are
just in the way of getting things done. The feature shall be more
important than cosmetic changes. I saw this frightening away
contributors, and features actually not getting into projects.

That being said, if you can explain your reasoning, and I find it
reasonable and worthy, I will update it.
Ross Burton - March 20, 2014, 1:28 p.m.
On 20 March 2014 12:44, Laszlo Papp <lpapp@kde.org> wrote:
> You are free to NACK without an explanation why it is important, but
> do not expect it to weigh much that way, at least in my eyes, based on
> that you are not even a maintainer as far as I know.

One good reason: systemd reads the LSB headers.

Ross
Martin Jansa - March 20, 2014, 1:30 p.m.
On Thu, Mar 20, 2014 at 12:44:47PM +0000, Laszlo Papp wrote:
> On Thu, Mar 20, 2014 at 12:26 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
> > On Thu, Mar 20, 2014 at 9:16 AM, Laszlo Papp <lpapp@kde.org> wrote:
> >> On Thu, Mar 20, 2014 at 11:59 AM, Otavio Salvador
> >> <otavio@ossystems.com.br> wrote:
> >>> On Thu, Mar 20, 2014 at 8:34 AM, Laszlo Papp <lpapp@kde.org> wrote:
> >>>> On Thu, Mar 20, 2014 at 11:22 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >>>>>
> >>>>> Op 20 mrt. 2014, om 11:45 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
> >>>>>
> >>>>>> On 20 March 2014 03:26, Laszlo Papp <lpapp@kde.org> wrote:
> >>>>>>> +PEER=127.0.0.1
> >>>>>>
> >>>>>> That doesn't seem like a very useful default.  We also can't use the
> >>>>>> NTP pool by default, so this should copy the behaviour of the ntpd
> >>>>>> package in meta-networking and default to no peers, and not start if
> >>>>>> none are specified.
> >>>>>
> >>>>> And the initscript is missing LSB headers.
> >>>>
> >>>> Just like the other similar scripts.
> >>>
> >>> This does not mean we ought to make the problem worse so add it for
> >>> new ones. If you are in good mood, send a fix for the others too ;)
> >>
> >> I do not think this is a problem. Could you please point out what
> >> functionality it breaks? Send patches for the others, and I will make
> >> this cosmetic change for this one, too. Consistency is more important
> >> than a mess of different styles, especially when it comes to cosmetic
> >> changes like this.
> >
> > Koen and I think it is important. So consider this my NACK for the patch as is.
> 
> You are free to NACK without an explanation why it is important, but
> do not expect it to weigh much that way, at least in my eyes, based on
> that you are not even a maintainer as far as I know.
> 
> I also think that it is not constructive to give NACK without
> answering the questions, and only telling again "It is important".
> Please be more constructive and explain the real issue. That is a
> better way of convincing a contributor than telling the person it is
> bad what you are doing because it is bad.
> 
> There was someone today publishing a blog post how important it is to
> become pragmatic to get things done. Currently, cosmetic changes are
> just in the way of getting things done. The feature shall be more
> important than cosmetic changes. I saw this frightening away
> contributors, and features actually not getting into projects.
> 
> That being said, if you can explain your reasoning, and I find it
> reasonable and worthy, I will update it.

I don't remember the exact issue I was seeing in runtime with systemd
and SysV scripts which were missing LSB headers, but it was handling
them somehow different.

If you search meta-oe git log, then you'll find many commit messages
where LSB headers were added when e.g. importing some older recipe from
oe-classic, that's good enough reason to add them to new ntp script,
isn't it?
Koen Kooi - March 20, 2014, 4:28 p.m.
Op 20 mrt. 2014, om 14:28 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:

> On 20 March 2014 12:44, Laszlo Papp <lpapp@kde.org> wrote:
>> You are free to NACK without an explanation why it is important, but
>> do not expect it to weigh much that way, at least in my eyes, based on
>> that you are not even a maintainer as far as I know.
> 
> One good reason: systemd reads the LSB headers.

As well as other inits that support sysv mode.

regards,

Koen
Khem Raj - March 20, 2014, 4:42 p.m.
On Thu, Mar 20, 2014 at 5:16 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>>> And the initscript is missing LSB headers.
>>>
>>> Just like the other similar scripts.
>>
>> This does not mean we ought to make the problem worse so add it for
>> new ones. If you are in good mood, send a fix for the others too ;)
>
> I do not think this is a problem. Could you please point out what
> functionality it breaks?

it would be not groked by systemd e.g. folks use sysvinit, systemd,
upstart with OE
moreover we do have aspirations to come closer to lsb
there are lsb images that some distros produce. There might be
existing scripts which
dont have lsb headers however those are wrong examples to adhere to
when generating brand
new scripts.

 Send patches for the others, and I will make
> this cosmetic change for this one, too.

having said above why is that a condition for you to make your patch better ?

Consistency is more important
> than a mess of different styles, especially when it comes to cosmetic
> changes like this.

lets say we are moving towards consistency one after another its not
going to happen overnight
but each contribution in right direction helps.
Laszlo Papp - March 20, 2014, 6:49 p.m.
On Thu, Mar 20, 2014 at 1:28 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 20 March 2014 12:44, Laszlo Papp <lpapp@kde.org> wrote:
>> You are free to NACK without an explanation why it is important, but
>> do not expect it to weigh much that way, at least in my eyes, based on
>> that you are not even a maintainer as far as I know.
>
> One good reason: systemd reads the LSB headers.

This init script is for SysV, not systemd.
Otavio Salvador - March 20, 2014, 6:53 p.m.
On Thu, Mar 20, 2014 at 3:49 PM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Mar 20, 2014 at 1:28 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 20 March 2014 12:44, Laszlo Papp <lpapp@kde.org> wrote:
>>> You are free to NACK without an explanation why it is important, but
>>> do not expect it to weigh much that way, at least in my eyes, based on
>>> that you are not even a maintainer as far as I know.
>>
>> One good reason: systemd reads the LSB headers.
>
> This init script is for SysV, not systemd.

Laszlo, we made several valid points. The outcome is we don't want to
have more init scripts lacking LSB headers. The desire to have this
patch is yours so if you want to have our ack, address those remarks.

As I said, it is your call to handle it or not.

I am not the maintainer of OE-Core, so I don't have a final word on
this (Richard does) but I made clear my point and my NACK for current
status of the patch.
Laszlo Papp - March 20, 2014, 6:53 p.m.
What is actually probably a bigger issue than the LSB, is that the
conf is currently sourced. That means if it contains an "rm -rf /"
statement, it will execute it.

Perhaps, this should be solved more gently...
Laszlo Papp - March 20, 2014, 7:01 p.m.
On Thu, Mar 20, 2014 at 4:28 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 20 mrt. 2014, om 14:28 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:
>
>> On 20 March 2014 12:44, Laszlo Papp <lpapp@kde.org> wrote:
>>> You are free to NACK without an explanation why it is important, but
>>> do not expect it to weigh much that way, at least in my eyes, based on
>>> that you are not even a maintainer as far as I know.
>>
>> One good reason: systemd reads the LSB headers.
>
> As well as other inits that support sysv mode.

This init script is adding support for sysv and no more. This is also
indicated in the first line of the commit message. I am sorry, but I
will not test it systemd and with other systems. You are free to test
it with everything in the world out there, and provide a more
intelligent change and void my work.

This is what I call not pragmatic. It is not like incremental
improvement is not useful because it does not do all the things in the
world right away. This is clearly communicated in the commit message
what it is for. For SysV, this is not any problem, it works fine.

No one has revealed a real issue with that so far as far as I can
tell. So why block a feature that was meant for something just because
someone cannot test on everything and/or does not want? What is being
read here in my understand is, "everything or nothing". This is not
pragmatic.

Please notice that perfection is the enemy of good. So my bottom line,
feel free to reject this feature in favor of having nothing instead of
something.

Unless someone can come up with a rebuttal that it is not working for
the intended and documentation use case, I am not willing to change
it, sorry. It would be pointless because I could not test it anyway,
and I will not send blind changes like that.
Ross Burton - March 20, 2014, 7:59 p.m.
On 20 March 2014 19:01, Laszlo Papp <lpapp@kde.org> wrote:
> This init script is adding support for sysv and no more. This is also
> indicated in the first line of the commit message. I am sorry, but I
> will not test it systemd and with other systems

You're not being asked to test with systemd.  You're being asked to
add LSB-standard sysvinit-specific headers to a sysvinit script.

Ross
Laszlo Papp - March 21, 2014, 1:59 p.m.
On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 20 March 2014 19:01, Laszlo Papp <lpapp@kde.org> wrote:
>> This init script is adding support for sysv and no more. This is also
>> indicated in the first line of the commit message. I am sorry, but I
>> will not test it systemd and with other systems
>
> You're not being asked to test with systemd.  You're being asked to
> add LSB-standard sysvinit-specific headers to a sysvinit script.

In my understanding, people were referring to two issues:

1) not working with systemd and what not compat modes. This is not
something I will test any soon.

2) It is not consistent, whereas if I take a look into busybox, the
consistency is what I do, apparently.

I would like to quote from the Fedora wiki for instance:

"LSB Headers are not required for Fedora SysV-style initscripts, but
they may be used. There is no requirement in the LSB certification for
any system scripts to be LSB compliant, and it can cause issues with
ordering."

So what is wrong about it without systemd and other compat modes? If
it is that big a deal (i.e. blocker), perhaps it is better to document
it in the contribution guideline as a generic trap.
Martin Jansa - March 21, 2014, 2:39 p.m.
On Fri, Mar 21, 2014 at 01:59:15PM +0000, Laszlo Papp wrote:
> On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > On 20 March 2014 19:01, Laszlo Papp <lpapp@kde.org> wrote:
> >> This init script is adding support for sysv and no more. This is also
> >> indicated in the first line of the commit message. I am sorry, but I
> >> will not test it systemd and with other systems
> >
> > You're not being asked to test with systemd.  You're being asked to
> > add LSB-standard sysvinit-specific headers to a sysvinit script.
> 
> In my understanding, people were referring to two issues:
> 
> 1) not working with systemd and what not compat modes. This is not
> something I will test any soon.

Other people already know it's causing the issues without LSB headers,
so if you just add them, you don't need to test it with systemd, other
people who care about systemd will do that for you or at least be OK
with adding this script, because it will have LSB headers (so it should
work fine in systemd world).

> 2) It is not consistent, whereas if I take a look into busybox, the
> consistency is what I do, apparently.
> 
> I would like to quote from the Fedora wiki for instance:
> 
> "LSB Headers are not required for Fedora SysV-style initscripts, but
> they may be used. There is no requirement in the LSB certification for
> any system scripts to be LSB compliant, and it can cause issues with
> ordering."
> 
> So what is wrong about it without systemd and other compat modes? If
> it is that big a deal (i.e. blocker), perhaps it is better to document
> it in the contribution guideline as a generic trap.
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Laszlo Papp - March 22, 2014, 2:03 p.m.
On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Mar 21, 2014 at 01:59:15PM +0000, Laszlo Papp wrote:
>> On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> > On 20 March 2014 19:01, Laszlo Papp <lpapp@kde.org> wrote:
>> >> This init script is adding support for sysv and no more. This is also
>> >> indicated in the first line of the commit message. I am sorry, but I
>> >> will not test it systemd and with other systems
>> >
>> > You're not being asked to test with systemd.  You're being asked to
>> > add LSB-standard sysvinit-specific headers to a sysvinit script.
>>
>> In my understanding, people were referring to two issues:
>>
>> 1) not working with systemd and what not compat modes. This is not
>> something I will test any soon.
>
> Other people already know it's causing the issues without LSB headers,
> so if you just add them, you don't need to test it with systemd, other
> people who care about systemd will do that for you or at least be OK
> with adding this script, because it will have LSB headers (so it should
> work fine in systemd world).

If someone is really interested in systemd, et al, unlike me at this
point, I guess it is not a big deal to get an LSB header from someone
to get it integrated into my change?

If no one cares about that, then why bother? So, if someone sends this
to me I will integrate it, otherwise there is no point since that
means no one cares.

But then again, this should not still block the change as it can be
added incrementally. I am not sure if it is a good idea to block a
feature because it does not provide another feature, too.
Laszlo Papp - July 25, 2014, 1:32 p.m.
Any reason why this feature has never got in? It was submitted more than
five months ago, and it would have added some feature to the system even if
not _everything_ right from the beginning?


On Sat, Mar 22, 2014 at 2:03 PM, Laszlo Papp <lpapp@kde.org> wrote:

> On Fri, Mar 21, 2014 at 2:39 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
> > On Fri, Mar 21, 2014 at 01:59:15PM +0000, Laszlo Papp wrote:
> >> On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross <ross.burton@intel.com>
> wrote:
> >> > On 20 March 2014 19:01, Laszlo Papp <lpapp@kde.org> wrote:
> >> >> This init script is adding support for sysv and no more. This is also
> >> >> indicated in the first line of the commit message. I am sorry, but I
> >> >> will not test it systemd and with other systems
> >> >
> >> > You're not being asked to test with systemd.  You're being asked to
> >> > add LSB-standard sysvinit-specific headers to a sysvinit script.
> >>
> >> In my understanding, people were referring to two issues:
> >>
> >> 1) not working with systemd and what not compat modes. This is not
> >> something I will test any soon.
> >
> > Other people already know it's causing the issues without LSB headers,
> > so if you just add them, you don't need to test it with systemd, other
> > people who care about systemd will do that for you or at least be OK
> > with adding this script, because it will have LSB headers (so it should
> > work fine in systemd world).
>
> If someone is really interested in systemd, et al, unlike me at this
> point, I guess it is not a big deal to get an LSB header from someone
> to get it integrated into my change?
>
> If no one cares about that, then why bother? So, if someone sends this
> to me I will integrate it, otherwise there is no point since that
> means no one cares.
>
> But then again, this should not still block the change as it can be
> added incrementally. I am not sure if it is a good idea to block a
> feature because it does not provide another feature, too.
>

Patch

diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 69b9b0c..653ab16 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -18,7 +18,7 @@  BUSYBOX_SPLIT_SUID ?= "1"
 export EXTRA_CFLAGS = "${CFLAGS}"
 export EXTRA_LDFLAGS = "${LDFLAGS}"
 
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock ${PN}-ntpd"
 
 FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
 FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog* ${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf* ${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
@@ -26,8 +26,9 @@  FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf"
 FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
 FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
 FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
+FILES_${PN}-ntpd = "${sysconfdir}/init.d/busybox-ntpd ${sysconfdir}/busybox-ntpd.conf"
 
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock ${PN}-ntpd"
 
 INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
 INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
@@ -35,6 +36,7 @@  INITSCRIPT_NAME_${PN}-mdev = "mdev"
 INITSCRIPT_PARAMS_${PN}-mdev = "start 03 S ."
 INITSCRIPT_NAME_${PN}-syslog = "syslog"
 INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd" 
+INITSCRIPT_NAME_${PN}-ntpd = "busybox-ntpd"
 
 SYSTEMD_PACKAGES = "${PN}-syslog"
 SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
@@ -264,6 +266,10 @@  do_install () {
                        install -m 644 ${WORKDIR}/mdev.conf ${D}${sysconfdir}/mdev.conf
                fi
 	fi
+    if grep "CONFIG_NTPD=y" ${B}/.config; then
+		install -m 0755 ${WORKDIR}/busybox-ntpd ${D}${sysconfdir}/init.d/
+		install -m 0644 ${WORKDIR}/busybox-ntpd.conf ${D}${sysconfdir}/
+	fi
 
     if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
         install -d ${D}${systemd_unitdir}/system
diff --git a/meta/recipes-core/busybox/busybox_1.22.1.bb b/meta/recipes-core/busybox/busybox_1.22.1.bb
index ffc9435..c513aa2 100644
--- a/meta/recipes-core/busybox/busybox_1.22.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.22.1.bb
@@ -27,6 +27,8 @@  SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
            file://inetd.conf \
            file://inetd \
            file://login-utilities.cfg \
+           file://busybox-ntpd \
+           file://busybox-ntpd.conf \
 "
 
 SRC_URI[tarball.md5sum] = "337d1a15ab1cb1d4ed423168b1eb7d7e"
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd b/meta/recipes-core/busybox/files/busybox-ntpd
new file mode 100644
index 0000000..e558973
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd
@@ -0,0 +1,39 @@ 
+#!/bin/sh
+DAEMON=/sbin/ntpd
+NAME=ntpd
+DESC="Busybox NTP Daemon"
+source /etc/busybox-ntpd.conf
+ARGS="-p $PEER"
+
+test -f $DAEMON || exit 0
+
+set -e
+
+case "$1" in
+    start)
+        start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
+        echo "done."
+        ;;
+    stop)
+        echo -n "stopping $DESC: $NAME... "
+        start-stop-daemon -K -n $NAME
+        echo "done."
+        ;;
+    restart)
+        echo "restarting $DESC: $NAME... "
+        $0 stop
+        $0 start
+        echo "done."
+        ;;
+    reload)
+        echo -n "reloading $DESC: $NAME... "
+        killall -HUP $(basename ${DAEMON})
+        echo "done."
+        ;;
+    *)
+        echo "Usage: $0 {start|stop|restart|reload}"
+        exit 1
+        ;;
+esac
+
+exit 0
diff --git a/meta/recipes-core/busybox/files/busybox-ntpd.conf b/meta/recipes-core/busybox/files/busybox-ntpd.conf
new file mode 100644
index 0000000..65665d8
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd.conf
@@ -0,0 +1 @@ 
+PEER=127.0.0.1