subject:"Re\: Ntpd config file support"

On Tue, Mar 18, 2014 at 11:37 AM, Laszlo Papp lp...@kde.org wrote:
 it seems that the ntpd util currently does not support config files.
 Currently, it means that I need to work this around in Yocto for my
 purposes, but as I see Zoltan Gyarmati here (*) also tried to do
 similar things in buildroot.

I don't understand the problem.

The way I use ntpd can be seen in this file:

busybox/examples/var_service/ntpd/run

In the real system, ntpd/ sits in /var/service/ directory.

Network configuration tools such as DHCP drop configuration files
into /var/run/service/ntpd directory. For example, my machine has
dhcp_em1.ntpconf file with this content:

let cfg=cfg+1
ntpip[$cfg]='10.5.26.10'
let cfg=cfg+1
ntpip[$cfg]='10.5.27.10'

(sorry, bashisms). When they do that, they restart ntpd service,
which runs this script.

The script sources these config files:

cfg=-1
for f in rundir/*.ntpconf; do
test -f $f || continue
. $f
done

Then it builds a list of -p PEER options:

p_opt=
cfg=0
while test x${ntpip[$cfg]} != x; do
p_opt=$p_opt -p ${ntpip[$cfg]}
let cfg=cfg+1
done

If there were none, we fall back to default
pool=us.pool.ntp.org
default_p_opt=-p 0.$pool -p 1.$pool -p 2.$pool -p 3.$pool

And finally, we exec ntpd:
ntpd -nNl -S ./ntp.script $p_opt


Anyway, the basic idea is that you run a script such as this one instead
of running ntpd directly, which allows you to be smart, and
system/distro-specific in selecting peers.

With ntpd configuration file feature, in many cases you are likely
to still need a script such as this to regenerate the config file.
Where is the win?

-- 
vda
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
vda.li...@googlemail.com wrote:
 With ntpd configuration file feature, in many cases you are likely
 to still need a script such as this to regenerate the config file.

I would not need any script to do that and I am likely not alone. For
the win, you can look into the real ntpd executable and ask them why
they implemented a simple config interface. Furthermore, you could
check if the users actually do not use because they think it is not a
win.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 With ntpd configuration file feature, in many cases you are likely
 to still need a script such as this to regenerate the config file.

 I would not need any script to do that and I am likely not alone.

How are you going to get DHCP-supplied ntp servers' addresses
supplied to the ntpd?

 For the win, you can look into the real ntpd executable and ask them why
 they implemented a simple config interface.

They also implemented encryption, IIRC. Think about it.
Encrypted packets containing highly secret information
such as ... current time?

The standard ntpd has good time keeping code.
The quality/sanity of other code there is not a given.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
vda.li...@googlemail.com wrote:
 On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 With ntpd configuration file feature, in many cases you are likely
 to still need a script such as this to regenerate the config file.

 I would not need any script to do that and I am likely not alone.

 How are you going to get DHCP-supplied ntp servers' addresses
 supplied to the ntpd?

Denys,

I am not sure what you mean. If you re-read the thread, the simple
_optional_ configuration interface was meant to be an alternative for
the peer and server option. It was not meant to be much more than
that. That is why some people thought it would fit busybox quite well.
When people start going beyond the boundaries, like signal handling
all that kind of crazy complexity for busybox, then you can argue that
it is better to left out, but we are not trying to discuss that.

 For the win, you can look into the real ntpd executable and ask them why
 they implemented a simple config interface.

 They also implemented encryption, IIRC. Think about it.
 Encrypted packets containing highly secret information
 such as ... current time?

Denys, this has not been discussed. We are discussing the
configuration interface.

PS.: If you wish to reply to me, please keep in the CC. I will be
unsubscribing from this list, soon.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 12:02 PM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 With ntpd configuration file feature, in many cases you are likely
 to still need a script such as this to regenerate the config file.

 I would not need any script to do that and I am likely not alone.

 How are you going to get DHCP-supplied ntp servers' addresses
 supplied to the ntpd?

 I am not sure what you mean. If you re-read the thread, the simple
 _optional_ configuration interface was meant to be an alternative for
 the peer and server option. It was not meant to be much more than
 that.

If you want to add optional support for parsing /etc/ntp.conf
compatible with standard ntpd (perhaps only server
and peer directives), it is acceptable.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 12:44 PM, Denys Vlasenko
vda.li...@googlemail.com wrote:
 On Thu, Mar 20, 2014 at 12:02 PM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp lp...@kde.org wrote:
 On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
 With ntpd configuration file feature, in many cases you are likely
 to still need a script such as this to regenerate the config file.

 I would not need any script to do that and I am likely not alone.

 How are you going to get DHCP-supplied ntp servers' addresses
 supplied to the ntpd?

 I am not sure what you mean. If you re-read the thread, the simple
 _optional_ configuration interface was meant to be an alternative for
 the peer and server option. It was not meant to be much more than
 that.

 If you want to add optional support for parsing /etc/ntp.conf
 compatible with standard ntpd (perhaps only server
 and peer directives), it is acceptable.

Hmm, ok, thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-20 Thread Harald Becker

Hi Denys !

If you want to add optional support for parsing /etc/ntp.conf
compatible with standard ntpd (perhaps only server
and peer directives), it is acceptable.

If optional compiled in, ok ... but this shouldn't be compiled in
on default binaries. It's just pure bloat without any other
benefit for other users of Busybox. All can be done with some
filtering on scripts (examples already given in thread).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 2:01 PM, Harald Becker ra...@gmx.de wrote:
 Hi Denys !

If you want to add optional support for parsing /etc/ntp.conf
compatible with standard ntpd (perhaps only server
and peer directives), it is acceptable.

 If optional compiled in, ok ... but this shouldn't be compiled in
 on default binaries. It's just pure bloat without any other
 benefit for other users of Busybox. All can be done with some
 filtering on scripts (examples already given in thread).

I don't know... I still feel compat is important.
It means growth of user base.

Most of features are bloat. CONFIG_FEATURE_FIND_DELETE
is bloat - you can easily code it with -exec instead, right?

But it defaults to yes, because most people want
more compatible behavior. They don't enjoy finding out
why make clean in project foo doesn't work with busybox find.

The things which default to n usually are:
- speed optimizations,
- support of very old kernels
- support for unusual features (e.g. fdisk for AIX)
- rare internationalization quirks (wide chars, bidi input)
- support for paranoid levels of compat (grep of NUL byte)
- unusual build options (static, PIE, NOMMU)

Ordinary compat features are not in this list.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-20 Thread Harald Becker

Hi Denys !

I don't know... I still feel compat is important.
It means growth of user base.

Compatibility with what? Busybox ntpd is not exactly modeled as
upstream ntpd ... and it's the reason why I use BB ntpd, as I
like it's simplicity, and dislike the upstreams complexity for a
minimalistic operation.

Most of features are bloat. CONFIG_FEATURE_FIND_DELETE
is bloat - you can easily code it with -exec instead, right?

Wow this is a completely unfair compare.

You compare a feature which is heavily used by many users in
many scripts and many command line usages, with a feature for a
few admins not willing to read some config in scripts and create
there command line correct.

Think of this twice, before throwing in such kind of bloat. BB
ntpd has all features required to do it's job. Every parameter
can be set on command line. The request to have a config file is
only from those not willing to read such config from compatible
config file and place it in command line during daemon startup.

Examples of how this compatibility can be achieved without adding
the bloat has bean given in the thread. So if you add this kind
of config it is not like other heavily used features (e.g. find
-delete). It will add bloat for a few people not willing or able
to get a single start script right and add a hand full of lines
to read values from compatible config file on daemon startup.

As this I consider it highly optional *AND* *NOT* part of a
default build.

Don't misunderstand. I don't want to block the feature, if you
like to add it, but optional and only included if system
creature explicitly selects it, and not part of a default build.

- support for paranoid levels of compat (grep of NUL byte)

IMO a paranoid level of compatibility, for those not willing to
write a hand full of lines in a daemon startup script (a single
script on a system). This is what I call this ntpd config file
feature. So let it default to NO.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Harald,

you would not use the minimal config, so your workflow would not
change anyway, and it is not like the complex use case you suggested
with all the signals and all that. It is a reasonable compromise in my
opinion. Parsing those two variables from a file is trivial, and would
increase the code size probably only with a few KB?

As for the -exec, I currently do not understand why it would be as
common as you seem to indicate it. Perhaps, you can show the many
uses as you imply?

I see a config file issue resolved bigger gain than avoiding -exec.
Thereby, I personally think Denys' comparison was fair.

On Thu, Mar 20, 2014 at 3:11 PM, Harald Becker ra...@gmx.de wrote:
 Hi Denys !

I don't know... I still feel compat is important.
It means growth of user base.

 Compatibility with what? Busybox ntpd is not exactly modeled as
 upstream ntpd ... and it's the reason why I use BB ntpd, as I
 like it's simplicity, and dislike the upstreams complexity for a
 minimalistic operation.

Most of features are bloat. CONFIG_FEATURE_FIND_DELETE
is bloat - you can easily code it with -exec instead, right?

 Wow this is a completely unfair compare.

 You compare a feature which is heavily used by many users in
 many scripts and many command line usages, with a feature for a
 few admins not willing to read some config in scripts and create
 there command line correct.

 Think of this twice, before throwing in such kind of bloat. BB
 ntpd has all features required to do it's job. Every parameter
 can be set on command line. The request to have a config file is
 only from those not willing to read such config from compatible
 config file and place it in command line during daemon startup.

 Examples of how this compatibility can be achieved without adding
 the bloat has bean given in the thread. So if you add this kind
 of config it is not like other heavily used features (e.g. find
 -delete). It will add bloat for a few people not willing or able
 to get a single start script right and add a hand full of lines
 to read values from compatible config file on daemon startup.

 As this I consider it highly optional *AND* *NOT* part of a
 default build.

 Don't misunderstand. I don't want to block the feature, if you
 like to add it, but optional and only included if system
 creature explicitly selects it, and not part of a default build.

- support for paranoid levels of compat (grep of NUL byte)

 IMO a paranoid level of compatibility, for those not willing to
 write a hand full of lines in a daemon startup script (a single
 script on a system). This is what I call this ntpd config file
 feature. So let it default to NO.

 --
 Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-20 Thread Mike Dean

Harald,

I'm curious.  You mentioned earlier that code is never freed from memory.
 If you're this concerned with bloat, why don't you fix your problem of
never deallocating the init code instead of worrying about some small
feature like this?  The Linux kernel does this; that's why you see the
message about Freeing xxKB of memory late in the boot process.  The freed
memory is the memory that was used by the initialization code.  This trick
isn't limited to kernelspace.  You can dynamically link libraries with init
code, and you can unlink them at runtime as well.  If you really want to
reduce bloat, you can take a page from the kernel devs and free all that
init code after the binary is up and running.  If you really are concerned
with bloat, that is.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Thu, Mar 20, 2014 at 10:11 AM, Harald Becker ra...@gmx.de wrote:

 Hi Denys !

 I don't know... I still feel compat is important.
 It means growth of user base.

 Compatibility with what? Busybox ntpd is not exactly modeled as
 upstream ntpd ... and it's the reason why I use BB ntpd, as I
 like it's simplicity, and dislike the upstreams complexity for a
 minimalistic operation.

 Most of features are bloat. CONFIG_FEATURE_FIND_DELETE
 is bloat - you can easily code it with -exec instead, right?

 Wow this is a completely unfair compare.

 You compare a feature which is heavily used by many users in
 many scripts and many command line usages, with a feature for a
 few admins not willing to read some config in scripts and create
 there command line correct.

 Think of this twice, before throwing in such kind of bloat. BB
 ntpd has all features required to do it's job. Every parameter
 can be set on command line. The request to have a config file is
 only from those not willing to read such config from compatible
 config file and place it in command line during daemon startup.

 Examples of how this compatibility can be achieved without adding
 the bloat has bean given in the thread. So if you add this kind
 of config it is not like other heavily used features (e.g. find
 -delete). It will add bloat for a few people not willing or able
 to get a single start script right and add a hand full of lines
 to read values from compatible config file on daemon startup.

 As this I consider it highly optional *AND* *NOT* part of a
 default build.

 Don't misunderstand. I don't want to block the feature, if you
 like to add it, but optional and only included if system
 creature explicitly selects it, and not part of a default build.

 - support for paranoid levels of compat (grep of NUL byte)

 IMO a paranoid level of compatibility, for those not willing to
 write a hand full of lines in a daemon startup script (a single
 script on a system). This is what I call this ntpd config file
 feature. So let it default to NO.

 --
 Harald
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean md...@emacinc.com wrote:
 I'm curious.  You mentioned earlier that code is never freed from memory.
 If you're this concerned with bloat, why don't you fix your problem of never
 deallocating the init code instead of worrying about some small feature like
 this?  The Linux kernel does this; that's why you see the message about
 Freeing xxKB of memory late in the boot process.  The freed memory is the
 memory that was used by the initialization code.  This trick isn't limited
 to kernelspace.  You can dynamically link libraries with init code, and you
 can unlink them at runtime as well.

People who are concerned with size just link statically.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-20 Thread Mike Dean

Michael, Denys,

I'm sorry; it seems you don't understand.  I wasn't referring to depending
on gcc to do the linking for you, but rather doing it yourselves.  I'm
aware that you guys are used to depending on compilers, linkers and the
kernel to do the hard work for you, but really, it's not that tough to do.
 There's no reason you would have to load init code just because the
busybox process was started.  You load that on demand, not by default.
 That way, you don't waste memory by loading init code that has nothing to
do with the task busybox was launched to perform.  I can foresee your
complaints about the bloat this would introduce in determine what to load
and when, but therein lies another challenge: how to minimize this.
 Arguing until you're blue in the face about bloat as a knee jerk reaction
to requests for small features won't solve the problem for you, though;
you'll have to put some thought into the root cause to fix this issue.  The
kernel developers did, and look at how much better it has worked out for
them than it has for you.


Mike Dean



On Thu, Mar 20, 2014 at 12:30 PM, Denys Vlasenko
vda.li...@googlemail.comwrote:

 On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean md...@emacinc.com wrote:
  I'm curious.  You mentioned earlier that code is never freed from memory.
  If you're this concerned with bloat, why don't you fix your problem of
 never
  deallocating the init code instead of worrying about some small feature
 like
  this?  The Linux kernel does this; that's why you see the message about
  Freeing xxKB of memory late in the boot process.  The freed memory is
 the
  memory that was used by the initialization code.  This trick isn't
 limited
  to kernelspace.  You can dynamically link libraries with init code, and
 you
  can unlink them at runtime as well.

 People who are concerned with size just link statically.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Thu, Mar 20, 2014 at 6:47 PM, Mike Dean md...@emacinc.com wrote:
 Michael, Denys,

 I'm sorry; it seems you don't understand.  I wasn't referring to depending
 on gcc to do the linking for you, but rather doing it yourselves.  I'm aware
 that you guys are used to depending on compilers, linkers and the kernel to
 do the hard work for you, but really, it's not that tough to do.  There's no
 reason you would have to load init code just because the busybox process was
 started.  You load that on demand, not by default.

In fact I don't understand what init code you are talking about.

 That way, you don't
 waste memory by loading init code that has nothing to do with the task
 busybox was launched to perform.

The text pages  (pages contaning machine code) are read-only, and
on MMU architectures they are shared.

Meaning, in fact there is only one copy of each text page in RAM
even if I run a thousand of busybox processes; and if there is
memory pressure, kernel will find least used text pages
and unmap them, freeing RAM for other use - because
if they will be needed again, they can be read back
from filesystem.

IOW, for all intents and purposes RAM consumption by code
can't be reduced by unloading parts of code by hand -
kernel already does almost everything possible in that area.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-20 Thread Mike Dean

The key word is, can, as in your statement, can be read back in again.
 If it's designed to only ever be loaded the first time it's executed after
boot, then there will be no reason to load it back in again when executed
after that first time.  If there's no need for the code, it won't be read
back in again.  You would have to specifically request it to be loaded upon
subsequent executions in order for it to be read in again.

This is why the kernel *does* successfully reduce RAM consumption by code
when it unloads the initialization code.  It just requires proper design.
 It's not some sort of kernel black magic which requires ring 0 or special
hardware support.  It's just good design.


Mike Dean



On Thu, Mar 20, 2014 at 1:08 PM, Denys Vlasenko vda.li...@googlemail.comwrote:

 On Thu, Mar 20, 2014 at 6:47 PM, Mike Dean md...@emacinc.com wrote:
  Michael, Denys,
 
  I'm sorry; it seems you don't understand.  I wasn't referring to
 depending
  on gcc to do the linking for you, but rather doing it yourselves.  I'm
 aware
  that you guys are used to depending on compilers, linkers and the kernel
 to
  do the hard work for you, but really, it's not that tough to do.
  There's no
  reason you would have to load init code just because the busybox process
 was
  started.  You load that on demand, not by default.

 In fact I don't understand what init code you are talking about.

  That way, you don't
  waste memory by loading init code that has nothing to do with the task
  busybox was launched to perform.

 The text pages  (pages contaning machine code) are read-only, and
 on MMU architectures they are shared.

 Meaning, in fact there is only one copy of each text page in RAM
 even if I run a thousand of busybox processes; and if there is
 memory pressure, kernel will find least used text pages
 and unmap them, freeing RAM for other use - because
 if they will be needed again, they can be read back
 from filesystem.

 IOW, for all intents and purposes RAM consumption by code
 can't be reduced by unloading parts of code by hand -
 kernel already does almost everything possible in that area.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-19 Thread Laszlo Papp

On Tue, Mar 18, 2014 at 8:29 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

Yet, it did not get any feedback from anyone yet. Hopefully, it
is not getting lost in the noise.

 Will try to hop on this tomorrow, to late for today ... saved
 your original message.

OK, thanks. I removed the export in my local file, so any other
constructive feedback is welcome.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-19 Thread Harald Becker

Hi Laszlo !

Let us see if we can more productive then!

Sorry, I haven't been able to pick up this earlier, due to lack of
time here.

Your approach is to unify things in different projects. Right?
I completely agree, it is a good approach to have common
solutions, to be used in different kinds of systems, if those
solutions fit there needs.

The only disagreement is the way you like to force a special
solution (which can be solved in different ways) going into the
main Busybox binary. All your request can be done using some
scripting, when thinking carefully.

Busybox ntpd allows all systems to provide all required
information during start of the daemon. There is no need to add
any extra code to the binary. To unify things just define in
which file and how information is placed there ... and request
(ask) all projects to accept and use this definition. That is the
main part.

From there it is the system/distro maintainers job to provide
scripts to pick the information and call BB ntpd with the right
arguments. Even if the scripts between systems differ, you are
fine, when all those projects agree and use the information from
the file you defined. It is up to the system maintainers if they
use a common template and throw in there own stuff, or decide to
write there own scripts.


As you have seen, there are different approaches to store the
information, so I try to give you some background on how
things are handled in the good old Unix way.

In principle there a two different kinds of solutions to store
and retrieve config information in the controlling scripts.
Either you write your config in the shell style and source the
config file, or you put this in your own format and use any kind
of filter to pick the required information. Both approaches have
there pros and cons.


The simple way is to use shell style in config files, that is
basically the VARNAME=value style, but using some clever
function definitions you may create your own syntax.

file /etc/timeserver:

timeserver my.local.server
timeserver ntp1.ptb.de atom.uhr.de


the controlling script:

TIME_SERVER=
timeserver() {
  local arg
  for arg
do if valid_addr $arg
  then TIME_SERVER=$TIME_SERVER -p '$arg'
fi
  done
}
source /etc/timeserver
eval ntpd $TIME_SERVER


Beside this you may have any number of comments in your config
file and you may use shell style substitutions to build some
variable content from values of other configured values. On the
other hand the big problem is, the config files are sourced, that
is a shell executes every command in those files, even if one
enters a line with rm -rf / it is executed as is, so you need to
carefully watch, whom you give write access to such kinds of
config files.

To avoid this you can use any kind of filter to pick the
information from the file you like. I gave you the very simple
`cat FILENAME` example, someone else provided an sed filter to
pick the server name from a default ntpd.conf file. It just
depends on complexity of your filter on how you can define and
pick the information from your file(s). For simple solutions you
do not need to use other filters except some shell scripting:

while read line
  do case $line in
'' | \#* )
  ;;
timeserv\ * | timeserver\ * | server\ * )
  set -- $line
  shift 1
  for arg
do if valid_address $arg
  then TIME_SERVER=$TIME_SERVER -p '$arg'
fi
  done
  ;;
  esac
done /etc/ntpd.conf


How about the following two files:

Details have already been discussed. The files may or may not fit
project needs, we can't tell you. Only the system maintainers
can decide if such scripts fits there system policy.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support (sample sed)

2014-03-19 Thread ibid . ag

On Tue, Mar 18, 2014 at 10:15:21PM +0100, Harald Becker wrote:
 Hi Mike !
 
 On 18-03-2014 15:12 Mike Dean md...@emacinc.com wrote:
 # Put your ntp nameservers here
 
 To clarify: It's not a name server, it's a time server (NTP =
 network time protocol).
 
 ... and what makes it difficult to write such things in a file,
 use an sed filter to read that config into a script variable,
 then use the arguments from variable when invoking Busybox ntpd?
 
 With some clever sed rules you can filter out empty lines and
 comments, pick lines which start with timeserver then add the
 required -p parameter prefix to any such lines

Here's what that sed could look like:

[ -e /etc/ntp.conf ]  NTP_SERVERS=`sed -ne 's/#.*//' -e 
's/^timeserver/-p/p'`

Just saying this because it's not even clever.


HTH,
Isaac Dunham
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

it seems that the ntpd util currently does not support config
files.

The Busybox ntpd applet get all information it needs via command
line, so it doesn't need to read any config file. The config
files Zoltan mentioned are part of his distribution, not
Busybox. So what kind of config file feature do you need?

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Harald,

I am working on an init script which I will submit soon to the Yocto
project if everything goes alright.

The idea is that I have an application on the embedded system where
the user can configure the ntp peer. The application would then re-run
and also enable the ntp daemon from busybox if it is not yet done so.

I think the standard way to do it would be to use initscripts (sysv or
systemd). It is not a problem to run busybox's ntpd with the right
command line parameters on the fly, but automatically on boot, it is
getting a bit more important if you know what I mean.

It would be basically consistent with several other applets, namely:

* syslogd
* crond
* httpd
* udhcpcd
* inetd

... etc. As for Zoltan, yes, I understood, and that is why I also
mentioned he would be doing it in buildroot, which is somewhat similar
to Yocto, but not quite. :) The point is that ntpd could be run from
initscripts with a config file dedicated for it, but perhaps there are
better solutions for this out there?

Cheers, L.



On Tue, Mar 18, 2014 at 12:43 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

it seems that the ntpd util currently does not support config
files.

 The Busybox ntpd applet get all information it needs via command
 line, so it doesn't need to read any config file. The config
 files Zoltan mentioned are part of his distribution, not
 Busybox. So what kind of config file feature do you need?

 --
 Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

The idea is that I have an application on the embedded system
where the user can configure the ntp peer. The application would
then re-run and also enable the ntp daemon from busybox if it is
not yet done so.

All that is not part of Busybox. So you are free to put this to
your distro.

I think the standard way to do it would be to use initscripts
(sysv or systemd). It is not a problem to run busybox's ntpd
with the right command line parameters on the fly, but
automatically on boot, it is getting a bit more important if you
know what I mean.

The only difficulty at boot time I know is the order of startup.
ntpd may only be activated when network is up.

It would be basically consistent with several other applets,
namely:

But all those applets do need more configuration. ntpd needs so
less info, all can be given on command line. And if there is a
config file feature, next cry will be, how to reload config when
things change? So either you need to watch modification time of
config file or handle any signals ... much code to handle this
all. So do we really need a configuration file option for ntpd
just to select the peer? It's so easy to put this in init
scripts, to stop and restart ntpd.

... etc. As for Zoltan, yes, I understood, and that is why I also
mentioned he would be doing it in buildroot, which is somewhat
similar to Yocto, but not quite. :) The point is that ntpd could
be run from initscripts with a config file dedicated for it, but
perhaps there are better solutions for this out there?

Sorry, I'm not sure, if I'm able to follow your intention.

My intention is to keep things small, so if you are going to add
config file support for ntpd, make it at least a build time
configurable option (as I think syslogd did). So things won't
change or add any extra code, when you do not enable ntpd config
file support. This is my personal opinion, so lets here what
others mean.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 1:24 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

The idea is that I have an application on the embedded system
where the user can configure the ntp peer. The application would
then re-run and also enable the ntp daemon from busybox if it is
not yet done so.

 All that is not part of Busybox. So you are free to put this to
 your distro.

The point of the thread is to avoid people putting the same into their
own projects. Note that neither Yocto, nor buildroot is a
distribution, however.

I think the standard way to do it would be to use initscripts
(sysv or systemd). It is not a problem to run busybox's ntpd
with the right command line parameters on the fly, but
automatically on boot, it is getting a bit more important if you
know what I mean.

 The only difficulty at boot time I know is the order of startup.
 ntpd may only be activated when network is up.

That is not much of a difficulty today. Systemd can probably do this for one.

It would be basically consistent with several other applets,
namely:

 But all those applets do need more configuration. ntpd needs so
 less info, all can be given on command line. And if there is a
 config file feature, next cry will be, how to reload config when
 things change? So either you need to watch modification time of
 config file or handle any signals ... much code to handle this
 all. So do we really need a configuration file option for ntpd
 just to select the peer? It's so easy to put this in init
 scripts, to stop and restart ntpd.

The main concern is not whether or not it is easy. It could be easy
the same way to put it into the source code. The problem is that
people keep reinventing the same in different projects. That is a sign
of something not going well in my opinion. I am not sure what much
code you are speaking of. Reading a simple config file in should be
the matter of few lines (in C, at least).

... etc. As for Zoltan, yes, I understood, and that is why I also
mentioned he would be doing it in buildroot, which is somewhat
similar to Yocto, but not quite. :) The point is that ntpd could
be run from initscripts with a config file dedicated for it, but
perhaps there are better solutions for this out there?

 Sorry, I'm not sure, if I'm able to follow your intention.

 My intention is to keep things small, so if you are going to add
 config file support for ntpd, make it at least a build time
 configurable option (as I think syslogd did). So things won't
 change or add any extra code, when you do not enable ntpd config
 file support. This is my personal opinion, so lets here what
 others mean.

It is not a good intention to keep things small just for the sake of
being small. Currently, I believe most of the cases will be when ntpd
is run as a daemon and not a one-shot process. You could hard code a
default value, but yet, the end users would like to configure it via
some easy configurable means, not messing with init script internals,
etc, IMHO.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

That is not much of a difficulty today. Systemd can probably do
this for one.

Not everybody like to use systemd ... I hate it and will NEVER
use it on a system of mine!

The main concern is not whether or not it is easy. It could be
easy the same way to put it into the source code. The problem is
that people keep reinventing the same in different projects.
That is a sign of something not going well in my opinion. I am
not sure what much code you are speaking of. Reading a simple
config file in should be the matter of few lines (in C, at
least).

... but the running daemon need to know when to read the file.

Reading info only on startup makes not much sense in your term, a
script may read the config and put it in command line. Done, and
so simple.

... in any other case there need to be code to tell the daemon
the right time to (re)read the config and (re)configure it's
behavior, which is much more difficult than just a few lines of
reading a file. Have you ever done this?

It is not a good intention to keep things small just for the
sake of being small.

One of the primary goals of Busybox was, to have a SMALL code
space for systems with less resources. IMO for this it's
important to ask before adding extra code ... and it's more than
just a few lines of reading a file (see above).


Currently, I believe most of the cases will be when ntpd is run
as a daemon and not a one-shot process. You could hard code a
default value, but yet, the end users would like to configure it
via some easy configurable means, not messing with init script
internals, etc, IMHO.

Put NTP peer address in a config file, let your init script pick
this file and put it in command line. What's wrong with this?
Average user just needs to know how to put peer address in a
file. Why do we need to blow up an otherwise small daemon with
this config file handling stuff? ... just to configure a single
peer name?

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 1:52 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

That is not much of a difficulty today. Systemd can probably do
this for one.

 Not everybody like to use systemd ... I hate it and will NEVER
 use it on a system of mine!

Yes, it is possible to do it without systemd, although pretty much
everyone seems to be switching across, really, even Ubuntu itself.

The main concern is not whether or not it is easy. It could be
easy the same way to put it into the source code. The problem is
that people keep reinventing the same in different projects.
That is a sign of something not going well in my opinion. I am
not sure what much code you are speaking of. Reading a simple
config file in should be the matter of few lines (in C, at
least).

 ... but the running daemon need to know when to read the file.

 Reading info only on startup makes not much sense in your term, a
 script may read the config and put it in command line. Done, and
 so simple.

 ... in any other case there need to be code to tell the daemon
 the right time to (re)read the config and (re)configure it's
 behavior, which is much more difficult than just a few lines of
 reading a file. Have you ever done this?

Yes, along with many people.

I have no idea why you would like to make it so complex. The config
file is sourced on start, which is not equal to system start up, which
you may be confusing it with. Start means when you start the daemon,
including restart. Your assumption would make it complex, but that was
not suggested.

It is not a good intention to keep things small just for the
sake of being small.

 One of the primary goals of Busybox was, to have a SMALL code
 space for systems with less resources. IMO for this it's
 important to ask before adding extra code ... and it's more than
 just a few lines of reading a file (see above).

It is not. It is literally a few lines. If you want small code, do not
write anything, and you are done. :) I can just reiterate my opinion
here, if something is common (like specifying the peer), it makes
sense to add a few lines which is probably (much) less than 5% of the
code. But if it is such a big concern, it  could be made a built time
decision, yeah.



Currently, I believe most of the cases will be when ntpd is run
as a daemon and not a one-shot process. You could hard code a
default value, but yet, the end users would like to configure it
via some easy configurable means, not messing with init script
internals, etc, IMHO.

 Put NTP peer address in a config file, let your init script pick
 this file and put it in command line. What's wrong with this?

Hmm, you do not seem to have understood the issue. Currently, Yocto
will do it differently, so will Buildroot, OpenWrt, and what not. This
is not nice.

 Average user just needs to know how to put peer address in a
 file. Why do we need to blow up an otherwise small daemon with
 this config file handling stuff? ... just to configure a single
 peer name?

Again, I have no idea why you think reading 1-2 variables from a file
is a Why do we need to blow up an otherwise small daemon with this
config file handling stuff? situation.

Please be considerate to the use cases, not pre-mature optimization.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: Ntpd config file support

All,

 -Original Message-
 From: busybox-boun...@busybox.net [mailto:busybox-
 boun...@busybox.net] On Behalf Of Harald Becker
 Sent: Tuesday, March 18, 2014 9:53 AM
 To: Laszlo Papp
 Cc: busybox@busybox.net; Adam Tkáč
 Subject: Re: Ntpd config file support

 Hi Laszlo !

 That is not much of a difficulty today. Systemd can probably do this
 for one.

 Not everybody like to use systemd ... I hate it and will NEVER use it on a
 system of mine!

 The main concern is not whether or not it is easy. It could be easy the
 same way to put it into the source code. The problem is that people
 keep reinventing the same in different projects.
 That is a sign of something not going well in my opinion. I am not sure
 what much code you are speaking of. Reading a simple config file in
 should be the matter of few lines (in C, at least).

 ... but the running daemon need to know when to read the file.

 Reading info only on startup makes not much sense in your term, a script
 may read the config and put it in command line. Done, and so simple.

 ... in any other case there need to be code to tell the daemon the right time
 to (re)read the config and (re)configure it's behavior, which is much more
 difficult than just a few lines of reading a file. Have you ever done this?

 It is not a good intention to keep things small just for the sake of
 being small.

 One of the primary goals of Busybox was, to have a SMALL code space for
 systems with less resources. IMO for this it's important to ask before adding
 extra code ... and it's more than just a few lines of reading a file (see 
 above).

 Currently, I believe most of the cases will be when ntpd is run as a
 daemon and not a one-shot process. You could hard code a default value,
 but yet, the end users would like to configure it via some easy
 configurable means, not messing with init script internals, etc, IMHO.

 Put NTP peer address in a config file, let your init script pick this file 
 and put it
 in command line. What's wrong with this?
 Average user just needs to know how to put peer address in a file. Why do
 we need to blow up an otherwise small daemon with this config file handling
 stuff? ... just to configure a single peer name?

I'm also using ntpd with a Yocto Project based system, and I had switched to 
using the full ntp package instead of the Busybox supplied ntpd because of 
configuration.  Within this build framework, I didn't see an easy way to adjust 
the ntpd command line or to set its configuration for the final built image.  
At the same time, I can understand the resistance to adding another 
configuration file that needs to be maintained.

How about a set of ntpd menuconfig options to build the command line?  We could 
configure the default ntpd settings at build time, it wouldn't add anything to 
the size of the final ntpd binary.

Regards,
Bryan
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Cristian Ionescu-Idbohrn

On Tue, 18 Mar 2014, Bryan Evenson wrote:

 How about a set of ntpd menuconfig options to build the command
 line?  We could configure the default ntpd settings at build time,
 it wouldn't add anything to the size of the final ntpd binary.

How about using a resource file the initscript would source:

---[ rc-file ]---
NTPD_OPT1='-f foo'
NTPD_OPT2='-b bar'
NTPD_OPT3=
-

---[ initscript ]---
#!/bin/sh

. /path/to/rc-file
...
command line to start ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3
...



Cheers,

-- 
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

Yes, it is possible to do it without systemd, although pretty
much everyone seems to be switching across, really, even Ubuntu
itself.

... and I'm never going to use Ubuntu again, for there decisions.
 
I have no idea why you would like to make it so complex. The
config file is sourced on start, which is not equal to system
start up, which you may be confusing it with. Start means when
you start the daemon, including restart. Your assumption would
make it complex, but that was not suggested.

Your explanation does not make sense. Either the config file is
read (only) during startup of ntpd (then all info can be passed
from command line) or the running daemon need to be signaled when
it's time to read the config file.

Hmm, you do not seem to have understood the issue. Currently,
Yocto will do it differently, so will Buildroot, OpenWrt, and
what not. This is not nice.

All those systems are not Busybox. It is not wrong to share your
work, but do we need to blow up the existing Busybox code for
this? Why can't you share your work with other projects, without
adding code to the Busybox binary.

It is not wrong to have a common solution for a problem, but I
ought you going to do it at the wrong place. 


Again, I have no idea why you think reading 1-2 variables from a
file is a Why do we need to blow up an otherwise small daemon
with this config file handling stuff? situation.

Have you ever written such a daemon with config file option? I
did several and know what is required. Either it makes no sense
to read config file in ntpd code, due to the fact you can pass
all info on command line, or you need all the extra code to
reread config lines when the configuration change.

... else give exact info on how you want to add this to ntpd.

Please be considerate to the use cases, not pre-mature
optimization.

It is not premature optimization. It's the question of resource
consumption and if things are necessary to be included in a (per
definition) small tool box like Busybox.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

That is the fourth solution I see now in a raw... after Yocto,
Buildroot and OpenWrt...

This is what I was referring to. It is inconsistent across projects. :)

That being said, it seems that Harald is objecting to this heavily for
some reason (may be miscommunication between us). Thereby, I will not
insist on this. If the developers feel happier without that feature,
let it be so.

On Tue, Mar 18, 2014 at 2:32 PM, Cristian Ionescu-Idbohrn
cristian.ionescu-idbo...@axis.com wrote:
 On Tue, 18 Mar 2014, Bryan Evenson wrote:

 How about a set of ntpd menuconfig options to build the command
 line?  We could configure the default ntpd settings at build time,
 it wouldn't add anything to the size of the final ntpd binary.

 How about using a resource file the initscript would source:

 ---[ rc-file ]---
 NTPD_OPT1='-f foo'
 NTPD_OPT2='-b bar'
 NTPD_OPT3=
 -

 ---[ initscript ]---
 #!/bin/sh

 . /path/to/rc-file
 ...
 command line to start ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3
 ...
 


 Cheers,

 --
 Cristian
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

That is the fourth solution I see now in a raw... after Yocto,
Buildroot and OpenWrt...

This is what I was referring to. It is inconsistent across
projects. :)

That being said, it seems that Harald is objecting to this
heavily for some reason (may be miscommunication between us).

I told you, it's not wrong to find a common solution, but
changing Busybox binary for this seams to be the wrong place.
Find a way to provide a script that may be used by all those
projects. Not every modification needs to affect the main BB
binary.

As a kind of miscommunication it looks to me you do not really
know how much code it requires to let a daemon reread it's config
when things change ... and config file support without rereading
makes no sense, as you can set all parameters on the command
line and script may acquire the configured options in so many
comfortable ways (not increasing BB binary size).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

I think that adding this feature is an excellent idea.  I don't understand
where all the resistance is.  If there's code bloat from parsing a simple
config file, then perhaps Busybox isn't well designed.  I don't know, I
haven't worked with it's code; perhaps I'm just used to the Linux kernel's
code, but considering the number of utilities (including daemons) that
Busybox replaces, why doesn't it have generic library code for parsing
configuration files?  If you want to cast stones regarding bloating code
with configuration parsing, you should at least cast them in the right
direction.  If each individual tool that Busybox replaces has its own code
for parsing a configuration file (if it uses one), then *that* is the
problem, not the desire of users to have this feature.  I really don't
understand this resistance to meeting the needs of the end users.
 Personally, I think this type of resistance will only lead to people
eventually forking Busybox due to disagreements with the decisions made
regarding these types of features.  #ifdefs work very well for selectively
leaving out features like this, as I imagine you know, without leaving
behind and code bloat in binaries which have the feature disabled.  One of
the previous respondents to this chain suggested making it a menuconfig
option; that sounds very reasonable to me.

Looking back through this e-mail chain, it appears to be a 4:1 ratio so far
of people for this feature to people against.  If 4 people want it, and
only 1 person doesn't, doesn't that sound like a feature that *should* be
implemented?  It sure does to me.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 9:49 AM, Laszlo Papp lp...@kde.org wrote:

 That is the fourth solution I see now in a raw... after Yocto,
 Buildroot and OpenWrt...

 This is what I was referring to. It is inconsistent across projects. :)

 That being said, it seems that Harald is objecting to this heavily for
 some reason (may be miscommunication between us). Thereby, I will not
 insist on this. If the developers feel happier without that feature,
 let it be so.

 On Tue, Mar 18, 2014 at 2:32 PM, Cristian Ionescu-Idbohrn
 cristian.ionescu-idbo...@axis.com wrote:
  On Tue, 18 Mar 2014, Bryan Evenson wrote:
 
  How about a set of ntpd menuconfig options to build the command
  line?  We could configure the default ntpd settings at build time,
  it wouldn't add anything to the size of the final ntpd binary.
 
  How about using a resource file the initscript would source:
 
  ---[ rc-file ]---
  NTPD_OPT1='-f foo'
  NTPD_OPT2='-b bar'
  NTPD_OPT3=
  -
 
  ---[ initscript ]---
  #!/bin/sh
 
  . /path/to/rc-file
  ...
  command line to start ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3
  ...
  
 
 
  Cheers,
 
  --
  Cristian
  ___
  busybox mailing list
  busybox@busybox.net
  http://lists.busybox.net/mailman/listinfo/busybox
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Rich Felker

On Tue, Mar 18, 2014 at 01:59:37PM +, Bryan Evenson wrote:
 I'm also using ntpd with a Yocto Project based system, and I had
 switched to using the full ntp package instead of the Busybox
 supplied ntpd because of configuration. Within this build framework,
 I didn't see an easy way to adjust the ntpd command line or to set
 its configuration for the final built image. At the same time, I can
 understand the resistance to adding another configuration file that
 needs to be maintained.
 
 How about a set of ntpd menuconfig options to build the command
 line? We could configure the default ntpd settings at build time, it
 wouldn't add anything to the size of the final ntpd binary.

How is it hard? Just wrap ntpd with your own shell script called
ntpd that parses your config file and passes the options on the
command line to busybox ntpd... Or am I missing something?

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Mike !

 If there's code bloat from parsing a simple config file, then
 perhaps Busybox isn't well designed.

Same misunderstanding as Laszlo. It is not only parsing a simple
config file. AFAIK libbb has functions to do this. The problem
is, it makes no sense to blow up the BB binary size for only
reading the peers address on daemon startup, without implementing
that right and rereading/reconfiguring the running daemon when
the configuration changes. And the code to handle this is more
than trivial.

In my eyes bloat to the binary - as other (simpler) changes to BB
has bean neglected with the code size argument in the past. None
of the mentioned changes improves operation of the current ntpd
applet. Every parameter of ntpd can be given at the command line,
reading the info from any (config) file is simple within scripts
and does not increase BB binary size. So there would be extra BB
code for no extra functionality, because there are a some people
who don't get there calling scripts right (asking for extra binary
code, for things simple to handle in scripting). 

Why don't you provide a script with common solution, we can add
this to the contribution directory, for those who like to use it.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

I just implemented such code for a project I'm working on, and I viewed it
as pretty trivial.

In any case, Busybox is king of going half way with features, so why not
make it just parse the config on startup and not worry about trapping
signals?  If you do wish to implement signal handling, then a well written
signal handler should make this easy; again, this boils down to the
existing design, since I'm sure Busybox already handles signals.  If the
struct you're passing a pointer to for your signal handler function
includes a list of function pointers to handle the event, then it should be
trivial to add; if not, then why bother?  The busybox version of vi doesn't
implement many features, so why should the ntpd config file parsing be
fully featured?


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 12:29 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

  If there's code bloat from parsing a simple config file, then
  perhaps Busybox isn't well designed.

 Same misunderstanding as Laszlo. It is not only parsing a simple
 config file. AFAIK libbb has functions to do this. The problem
 is, it makes no sense to blow up the BB binary size for only
 reading the peers address on daemon startup, without implementing
 that right and rereading/reconfiguring the running daemon when
 the configuration changes. And the code to handle this is more
 than trivial.

 In my eyes bloat to the binary - as other (simpler) changes to BB
 has bean neglected with the code size argument in the past. None
 of the mentioned changes improves operation of the current ntpd
 applet. Every parameter of ntpd can be given at the command line,
 reading the info from any (config) file is simple within scripts
 and does not increase BB binary size. So there would be extra BB
 code for no extra functionality, because there are a some people
 who don't get there calling scripts right (asking for extra binary
 code, for things simple to handle in scripting).

 Why don't you provide a script with common solution, we can add
 this to the contribution directory, for those who like to use it.

 --
 Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Yes, I agree with Mike that we do not need complex signal handling for
starter. My question was more about a start config file parsing. I
still stick by that it would be simple and useful to add (open, read,
get value, close), but that being said, I am fine with a contribution
directory entry, too, as a compromise to avoid the arguing and get
this done. :)

On Tue, Mar 18, 2014 at 5:52 PM, Mike Dean md...@emacinc.com wrote:
 I just implemented such code for a project I'm working on, and I viewed it
 as pretty trivial.

 In any case, Busybox is king of going half way with features, so why not
 make it just parse the config on startup and not worry about trapping
 signals?  If you do wish to implement signal handling, then a well written
 signal handler should make this easy; again, this boils down to the existing
 design, since I'm sure Busybox already handles signals.  If the struct
 you're passing a pointer to for your signal handler function includes a list
 of function pointers to handle the event, then it should be trivial to add;
 if not, then why bother?  The busybox version of vi doesn't implement many
 features, so why should the ntpd config file parsing be fully featured?


 Mike Dean

 md...@emacinc.com
 http://www.emacinc.com/

 Engineer
 EMAC, Inc.
 618-529-4525 Ext. 330
 618-457-0110 Fax
 2390 EMAC Way
 Carbondale, Il 62901



 On Tue, Mar 18, 2014 at 12:29 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

  If there's code bloat from parsing a simple config file, then
  perhaps Busybox isn't well designed.

 Same misunderstanding as Laszlo. It is not only parsing a simple
 config file. AFAIK libbb has functions to do this. The problem
 is, it makes no sense to blow up the BB binary size for only
 reading the peers address on daemon startup, without implementing
 that right and rereading/reconfiguring the running daemon when
 the configuration changes. And the code to handle this is more
 than trivial.

 In my eyes bloat to the binary - as other (simpler) changes to BB
 has bean neglected with the code size argument in the past. None
 of the mentioned changes improves operation of the current ntpd
 applet. Every parameter of ntpd can be given at the command line,
 reading the info from any (config) file is simple within scripts
 and does not increase BB binary size. So there would be extra BB
 code for no extra functionality, because there are a some people
 who don't get there calling scripts right (asking for extra binary
 code, for things simple to handle in scripting).

 Why don't you provide a script with common solution, we can add
 this to the contribution directory, for those who like to use it.

 --
 Harald


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: Ntpd config file support

 -Original Message-
 From: Rich Felker [mailto:dal...@aerifal.cx]
 Sent: Tuesday, March 18, 2014 1:12 PM
 To: Bryan Evenson
 Cc: Harald Becker; Laszlo Papp; busybox@busybox.net; Adam Tkáč
 Subject: Re: Ntpd config file support

 On Tue, Mar 18, 2014 at 01:59:37PM +, Bryan Evenson wrote:
  I'm also using ntpd with a Yocto Project based system, and I had
  switched to using the full ntp package instead of the Busybox supplied
  ntpd because of configuration. Within this build framework, I didn't
  see an easy way to adjust the ntpd command line or to set its
  configuration for the final built image. At the same time, I can
  understand the resistance to adding another configuration file that
  needs to be maintained.

  How about a set of ntpd menuconfig options to build the command line?
  We could configure the default ntpd settings at build time, it
  wouldn't add anything to the size of the final ntpd binary.

 How is it hard? Just wrap ntpd with your own shell script called ntpd that
 parses your config file and passes the options on the command line to
 busybox ntpd... Or am I missing something?

Within my build framework this was not easy.  At least for me when I was just 
starting to use the Yocto Project for building my entire system image.  Within 
this framework it's not too hard to alter build configuration parameters or 
override userspace files for particular package.  I had assumed there was an 
init script provided by BusyBox (and I still had thought that up until Laszlo 
started this thread), so I first had an issue trying to find a non-existent 
file to override.

My next issue is that I look at this page: 
http://www.busybox.net/downloads/BusyBox.html when trying to figure out what 
command line options are available for a BusyBox command.  I'll do this before 
I change the BusyBox build to get an idea of what I need to do to control it.  
If you take a look at that page, ntpd is not listed.  So I didn't know how to 
start ntpd, and I didn't know what options were available for ntpd.  Given that 
start, I decided to use the full ntpd package instead of the Busybox-provided 
ntpd.

Harald had suggested an example startup script (I'm assuming under the 
examples/ directory of the Busybox source?).  With a working example and an 
easy place to find the ntpd command line options, I'd probably give the 
Busybox-provided ntpd a try.

Regards,
Bryan

 Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Bryan !

On 18-03-2014 18:02 Bryan Evenson beven...@melinkcorp.com wrote:

Harald had suggested an example startup script (I'm assuming
under the examples/ directory of the Busybox source?).  With a
working example and an easy place to find the ntpd command line
options, I'd probably give the Busybox-provided ntpd a try.

Have you ever tried busybox ntpd --help? If Busybox has bean
compiled with full usage messages (the default) this shall give
you all necessary info about ntpd command line options:

from my 1.19.0 version this gives: (may have changes on newer
versions)

Usage: ntpd [-dnqNw] [-S PROG] [-p PEER]...

NTP client/server

Options:
-d  Verbose
-n  Do not daemonize
-q  Quit after clock is set
-N  Run at high priority
-w  Do not set time (only query peers), implies -n
-S PROG Run PROG after stepping time, stratum
change, and every 11 mins
-p PEER Obtain time from PEER (may be repeated)


So normal Daemon startup is just:

ntpd -p PEERADDRESS


A (very) simple script solution:

ntpd -p `cat /etc/timeserver`

This however does not check for parameter mistakes, but with some
awk or sed scripting you can parse and check your config file and
even allow for multiple time server specification (adding extra
-p options).


All that without increasing Busybox binary size, which would give
us no extra functionality (when just reading config file on ntpd
startup).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Mike !

On 18-03-2014 12:52 Mike Dean md...@emacinc.com wrote:
I just implemented such code for a project I'm working on, and I
viewed it as pretty trivial.

So why don't you provide an example for a patch to implement the
function you request ... with full bloat check output and
description of benefits ... then we can see if it makes sense to
implement this. 

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

 My question was more about a start config file parsing.

Which makes no sense, as it is mostly the time server address you
will pass in (and configure). Get your scripts right and you can
pass in your time server address(es) as much configurable as
you like. With no need to add any code to BB binary.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: Ntpd config file support

Harald,

 -Original Message-
 From: Harald Becker [mailto:ra...@gmx.de]
 Sent: Tuesday, March 18, 2014 2:31 PM
 To: Bryan Evenson
 Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
 Subject: Re: Ntpd config file support

 Hi Bryan !

 On 18-03-2014 18:02 Bryan Evenson beven...@melinkcorp.com wrote:

 Harald had suggested an example startup script (I'm assuming under the
 examples/ directory of the Busybox source?).  With a working example
 and an easy place to find the ntpd command line options, I'd probably
 give the Busybox-provided ntpd a try.

 Have you ever tried busybox ntpd --help? If Busybox has bean compiled
 with full usage messages (the default) this shall give you all necessary info
 about ntpd command line options:

With my setup, busybox was not being compiled with the full usage messages, so 
this just returns ntpd: applet not found on my system.  My initial Busybox 
build did not have ntpd included in its configuration.  This meant I would have 
had to re-build Busybox with ntpd included just to figure out how to use it 
(and to see if the options I wanted to use were available), or to start looking 
through the source code.  In retrospect, the source code isn't that bad to look 
through and would have been my best bet.

 from my 1.19.0 version this gives: (may have changes on newer
 versions)

 Usage: ntpd [-dnqNw] [-S PROG] [-p PEER]...

 NTP client/server

 Options:
   -d  Verbose
   -n  Do not daemonize
   -q  Quit after clock is set
   -N  Run at high priority
   -w  Do not set time (only query peers), implies -n
   -S PROG Run PROG after stepping time, stratum
 change, and every 11 mins
 -p PEER   Obtain time from PEER (may be repeated)

 So normal Daemon startup is just:

 ntpd -p PEERADDRESS

 A (very) simple script solution:

 ntpd -p `cat /etc/timeserver`

 This however does not check for parameter mistakes, but with some awk or
 sed scripting you can parse and check your config file and even allow for
 multiple time server specification (adding extra -p options).

 All that without increasing Busybox binary size, which would give us no extra
 functionality (when just reading config file on ntpd startup).

 --
 Harald

Regards,
Bryan
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Bryan !

With my setup, busybox was not being compiled with the full
usage messages,

A problem of your build system. The default config include the
full usage messages. 

 so this just returns ntpd: applet not found

Why didn't you grab a precompiled default BB binary, just to do
the tests (like: busybox ntpd --help)

 This meant I would have had to re-build Busybox with ntpd
 included just to figure out how to use it ...

Is an argument for what? Adding extra code to Busybox binary
without getting extra functionality?

 In retrospect, the source code isn't that bad to look through
 and would have been my best bet.

If you didn't note before: There exist precompiled Busbox
binaries for most platforms. Nice place to start testing with. In
addition there is the mail list ... if usage of an applet is
unclear, just ask ... if you need help to setup required
scripts, just ask ... but don't change code of binary without
real need or giving extra benefit.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 6:51 PM, Harald Becker ra...@gmx.de wrote:
 if usage of an applet is
 unclear, just ask ... if you need help to setup required
 scripts, just ask ...

Let us see if we can more productive then!

How about the following two files:

diff --git a/meta/recipes-core/busybox/files/busybox-ntpd
b/meta/recipes-core/busybox/files/busybox-ntpd
new file mode 100644
index 000..3e0b32d
--- /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-ntp.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 000..a1470ef
--- /dev/null
+++ b/meta/recipes-core/busybox/files/busybox-ntpd.conf
@@ -0,0 +1 @@
+export PEER=127.0.0.1
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Harald,

I would but I'm busy porting existing device drivers to Device Tree and
writing some new drivers.  Our last release used a kernel version that
didn't have Device Tree, so getting support for all the hardware on all of
our boards for this new kernel version is a substantial amount of work.

I will give you a use case where this feature makes sense, though: we build
embedded Linux images using Yocto, but unlike many people, we make our
images generic and add additional tools and a fully featured SDK.  We build
our distribution for customers who don't know how to do this themselves,
and don't have the inclination or approval to spend the time learning how
to.  We work hard to make things easy for them.  One of the stumbling
blocks our customers have had in the past is how to configure ntpd to use
their internal ntp servers.  Helping them with this usually results in
grumbling about it being overcomplicated to perform what should be such a
simple task.  Most of them have no idea how to write bash scripts, so this
task represents a real learning curve for them.  What makes this worse is
that they have no interest in learning bash; as soon as they finish this,
they go back to C++ (or C) to finish their work.

Now, personally, I've been writing software since the mid-1980's, so to me,
all software is much easier to write than it used to be, and the library
functions keep the code size small.  I personally don't see how this tiny
addition represents any significant increase to the size of the source tree
or the compiled binary.  I will tell you, however, that we'll just continue
use the full version of ntp for our upcoming distribution (we already made
the switch in our recipes) if this isn't added.  It's not worth the time or
effort for me to edit your code to add this.  I've simply been trying to
point out that catering to your users is the most important thing to do if
you want to keep them from jumping ship.  This may be one small portion of
Busybox, but it's one of about 20 that we've already replaced with full
versions for our upcoming release; the shortcomings in the busybox versions
aren't worth the savings in size in the days of GHz processors and 512MB+
RAM on small cheap embedded systems.  They're not even worth the savings on
our lowest end 200 MHz models; even those have a minimum of 128MB of RAM.
 I hope I'm not coming off as stubborn, annoying, or similar; that's not my
intention.  I'm just trying to get you to see things from the standpoints
of the people in this chain who've all clamored in favor of the feature.
 It honestly doesn't bother me either way, because as I said, I'll just use
the full version instead and not worry about it.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 1:35 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

 On 18-03-2014 12:52 Mike Dean md...@emacinc.com wrote:
 I just implemented such code for a project I'm working on, and I
 viewed it as pretty trivial.

 So why don't you provide an example for a patch to implement the
 function you request ... with full bloat check output and
 description of benefits ... then we can see if it makes sense to
 implement this.

 --
 Harald

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: Ntpd config file support

Harald,

 -Original Message-
 From: Harald Becker [mailto:ra...@gmx.de]
 Sent: Tuesday, March 18, 2014 2:51 PM
 To: Bryan Evenson
 Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
 Subject: Re: Ntpd config file support

 Hi Bryan !

 With my setup, busybox was not being compiled with the full usage
 messages,

 A problem of your build system. The default config include the full usage
 messages.

  so this just returns ntpd: applet not found

 Why didn't you grab a precompiled default BB binary, just to do the tests
 (like: busybox ntpd --help)

  This meant I would have had to re-build Busybox with ntpd included
  just to figure out how to use it ...

 Is an argument for what? Adding extra code to Busybox binary without
 getting extra functionality?

No, it's not really an argument for anything.  You asked me if I tried calling 
busybox ntpd --help, and I was responding with what I did and my results.  If 
anything, it'd be an argument to update 
http://www.busybox.net/downloads/BusyBox.html.

  In retrospect, the source code isn't that bad to look through and
  would have been my best bet.

 If you didn't note before: There exist precompiled Busbox binaries for most
 platforms. Nice place to start testing with. In addition there is the mail 
 list ... if
 usage of an applet is unclear, just ask ... if you need help to setup required
 scripts, just ask ... but don't change code of binary without real need or 
 giving
 extra benefit.

 --
 Harald

Regards,
Bryan
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 7:10 PM, Bryan Evenson beven...@melinkcorp.com wrote:
 Harald,

 -Original Message-
 From: Harald Becker [mailto:ra...@gmx.de]
 Sent: Tuesday, March 18, 2014 2:51 PM
 To: Bryan Evenson
 Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
 Subject: Re: Ntpd config file support

 Hi Bryan !

 With my setup, busybox was not being compiled with the full usage
 messages,

 A problem of your build system. The default config include the full usage
 messages.

  so this just returns ntpd: applet not found

 Why didn't you grab a precompiled default BB binary, just to do the tests
 (like: busybox ntpd --help)

  This meant I would have had to re-build Busybox with ntpd included
  just to figure out how to use it ...

 Is an argument for what? Adding extra code to Busybox binary without
 getting extra functionality?

 No, it's not really an argument for anything.  You asked me if I tried 
 calling busybox ntpd --help, and I was responding with what I did and my 
 results.  If anything, it'd be an argument to update 
 http://www.busybox.net/downloads/BusyBox.html.

That would be a really great thing to do! Update it automatically by
some script from the man pages and/or help output. ntpd is not even on
that list!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: Ntpd config file support

2014-03-18 Thread Sven-Göran Bergh

Hi Mike et.al,

I have just finished reading through this thread and yet I have not seen
any substantial explanation _why_ BB should include this feature.

Both Harald and Cristian have suggested reasonable solutions for this.
The concept of sourcing a config file from an initscript is common practice
for most init systems whether it be sysvinit, systemd, or whatever. Sure
they all differ in details, but the principal stays the same.

So please explain what is so unique about your setup that this methods
cannot be used. A flame war on how this could be done is not a satisfying
answer to _why_. Convenience?

Brgds
/S-G
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Bryan !

On 18-03-2014 19:10 Bryan Evenson beven...@melinkcorp.com wrote:

 If anything, it'd be an argument to update
 http://www.busybox.net/downloads/BusyBox.html.

Ok, first useful hint here, the Web-Page seams to be rather old.

The Busybox.html in the docs subdirectory (after build?) is much
more up to date and gives the expected info. May be the Web-Page
on busybox.net shall be automatically updated whenever a new
version is released (or during build of binary packages)?

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Sven, you totally missed the whole point of the thread in my opinion.
At least three people expressed that it is about convenience, a useful
one.

On Tue, Mar 18, 2014 at 7:36 PM, Sven-Göran Bergh
svengbergh-busy...@yahoo.com wrote:
 Hi Mike et.al,

 I have just finished reading through this thread and yet I have not seen
 any substantial explanation _why_ BB should include this feature.

 Both Harald and Cristian have suggested reasonable solutions for this.
 The concept of sourcing a config file from an initscript is common practice
 for most init systems whether it be sysvinit, systemd, or whatever. Sure
 they all differ in details, but the principal stays the same.

 So please explain what is so unique about your setup that this methods
 cannot be used. A flame war on how this could be done is not a satisfying
 answer to _why_. Convenience?

 Brgds
 /S-G
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

 No, it's not really an argument for anything.  You asked me if
 I tried calling busybox ntpd --help, and I was responding
 with what I did and my results.  If anything, it'd be an
 argument to update
 http://www.busybox.net/downloads/BusyBox.html.

That would be a really great thing to do! Update it
automatically by some script from the man pages and/or help
output. ntpd is not even on that list!

The Busybox.html (and the man page) in the docs subdirectory of
packages is already auto updated. The only missing part is to
update the web page ... and you are right, it would be nice to
have an auto update of this info.

Beside this you can always ask for usage information on mail list
or IRC channel.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Michael Conrad


On 3/18/2014 3:09 PM, Mike Dean wrote:
Helping them with this usually results in grumbling about it being 
overcomplicated to perform what should be such a simple task.


IMHO, the plethora of unix config file syntaxes are much harder to learn 
than reading a quick manpage (or --help in this case) of the tool you 
want to run.  Where are they going to learn the syntax? Your 
documentation? Random Internet documentation for the real ntpd?  The man 
page for the real ntp.conf is 1700 lines long!


On 3/18/2014 3:09 PM, Mike Dean wrote:
 I personally don't see how this tiny addition represents any 
significant increase to the size of the source tree or the compiled 
binary.


What syntax should be used?  the full ntpd syntax?  Should busybox emit 
errors or warnings on directives it doesn't support?  I can't imagine 
you could add this feature properly in less than 300 bytes, and that is 
significant for busybox.


On 3/18/2014 2:31 PM, Harald Becker wrote:

ntpd -p `cat /etc/timeserver`


I'm inclined to side with Harald that this is the best solution. Can't 
be much simpler for the user than that...


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

I couldn't agree more, Laszlo. 

Sent from my iPhone

 On Mar 18, 2014, at 2:44 PM, Laszlo Papp lp...@kde.org wrote:
 
 Sven, you totally missed the whole point of the thread in my opinion.
 At least three people expressed that it is about convenience, a useful
 one.
 
 On Tue, Mar 18, 2014 at 7:36 PM, Sven-Göran Bergh
 svengbergh-busy...@yahoo.com wrote:
 Hi Mike et.al,
 
 I have just finished reading through this thread and yet I have not seen
 any substantial explanation _why_ BB should include this feature.
 
 Both Harald and Cristian have suggested reasonable solutions for this.
 The concept of sourcing a config file from an initscript is common practice
 for most init systems whether it be sysvinit, systemd, or whatever. Sure
 they all differ in details, but the principal stays the same.
 
 So please explain what is so unique about your setup that this methods
 cannot be used. A flame war on how this could be done is not a satisfying
 answer to _why_. Convenience?
 
 Brgds
 /S-G
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Xabier Oneca -- xOneca

Hello all,

I'm with Sven-Göran, Harald, Cristian, et al.

I see the point of Harald that if the config file is implemented, then
someone will want it to be reloaded whitout quitting the daemon, and
what not! That's a lot of (byte)code!

Maybe Busybox could be shipped with an example init script for ntpd,
and other daemons that usually need it. (Laszlo, did you suggest this
in one of your last mails, where you posted a script + config file?)

Usually scripts in /etc/init.d use /etc/default/* as config values
(some distros, even using them as main config files). The scripts that
Laszlo posted fit that pattern.

I work with buildroot and never had a problem with ntpd and its lack
of config file. Anyways, in spite of no seeing benefit, I don't refuse
to implement it if it can be selected from KConfig...

Cheers,
Xabier Oneca_,,_
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

So you're telling me that a plain text script which takes more than 300 bytes 
is a better solution than an option that could be configured out?  But your 
full text option, enabled by default, takes less than 300 bytes I suppose?

Sent from my iPhone

 On Mar 18, 2014, at 2:49 PM, Michael Conrad mcon...@intellitree.com wrote:
 
 On 3/18/2014 3:09 PM, Mike Dean wrote:
 Helping them with this usually results in grumbling about it being 
 overcomplicated to perform what should be such a simple task.
 
 IMHO, the plethora of unix config file syntaxes are much harder to learn than 
 reading a quick manpage (or --help in this case) of the tool you want to run. 
  Where are they going to learn the syntax? Your documentation? Random 
 Internet documentation for the real ntpd?  The man page for the real ntp.conf 
 is 1700 lines long!
 
 On 3/18/2014 3:09 PM, Mike Dean wrote:
 I personally don't see how this tiny addition represents any significant 
 increase to the size of the source tree or the compiled binary.
 
 What syntax should be used?  the full ntpd syntax?  Should busybox emit 
 errors or warnings on directives it doesn't support?  I can't imagine you 
 could add this feature properly in less than 300 bytes, and that is 
 significant for busybox.
 
 On 3/18/2014 2:31 PM, Harald Becker wrote:
 ntpd -p `cat /etc/timeserver`
 
 I'm inclined to side with Harald that this is the best solution. Can't be 
 much simpler for the user than that...
 
 -Mike
 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Michael Conrad


On 3/18/2014 3:54 PM, Mike Dean wrote:

So you're telling me that a plain text script which takes more than 300 bytes 
is a better solution than an option that could be configured out?  But your 
full text option, enabled by default, takes less than 300 bytes I suppose?


I'm not sure I follow.  Harald suggested adding 23 bytes to your 
existing script, and adds the convenience of a config file where there 
wasn't before.


You could add that same minimal config file in C, and it would take a 
lot more than 23 bytes.


Either way, the config file will be a thing specific to busybox ntpd 
and you will have the exact same documentation problem in teaching 
people how to use it, then they have learning about the -p command 
line switch.


If you want to be compatible with a standard tool, and support 
ntp.conf, then you gain the popularly-available documentation, but add 
a significant amount of code.


Neither way is really ideal.  So if you want to add a non-ideal 
solution, it should be done in a distro-specific script.


-Mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support



 Just chiming in to support Harald.

 Busybox provides a usable ntpd interface. Calling ntpd with the
suitable arguments is the job of the init scripts, not Busybox;
if people have trouble starting ntpd, it's the responsibility of
their distribution packagers, not of Busybox; if they are the
distribution packagers, then it shouldn't be hard to write scripts
that use command line arguments. Turning to upstream to do
something that's normally handled at the distribution level is the
wrong way to go. Especially when it's about adding config files;
config files are a horrible idea overall and only pay for themselves
when configuration is *really* tough, which clearly isn't the case
with ntpd.

 But everyone has to do it their own way, we need to unify this is
a flawed argument. Distributions will find their own way to package
things and run daemons anyway. (And most of them suck: the mainstream
view of how init should be done went directly from System V scripts
to systemd, i.e. out of the frying pan and into the fire.)
 There are 3 inevitable things in the universe: death, taxes, and the
gratuitous repackaging of stuff with subtly incompatible changes from
one integrator to another. Changing the way ntpd reads its options
isn't going to unify jack.

 I agree that the world needs some unified way to launch things, but
unfortunately, it's not going to happen in the next decade or two.
This is the time it's going to take for most people to finally get fed
up with systemd enough to look for alternatives again. In the meantime,
choose your own way, the one that's going to give you the least
headaches, and work with it.

 (Of course, the best initscripts system out there is clearly s6. But
one could argue that I'm partial.)

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca  --  xOneca
xon...@gmail.com wrote:
 Hello all,

 I'm with Sven-Göran, Harald, Cristian, et al.

 I see the point of Harald that if the config file is implemented, then
 someone will want it to be reloaded whitout quitting the daemon, and
 what not! That's a lot of (byte)code!

 Maybe Busybox could be shipped with an example init script for ntpd,
 and other daemons that usually need it. (Laszlo, did you suggest this
 in one of your last mails, where you posted a script + config file?)

Yet, it did not get any feedback from anyone yet. Hopefully, it is not
getting lost in the noise.

 Usually scripts in /etc/init.d use /etc/default/* as config values
 (some distros, even using them as main config files). The scripts that
 Laszlo posted fit that pattern.

Not quite; actually /etc/default is more like a Debian, et al,
pattern. OpenWrt will use something. Yocto uses something else, etc.
And for what it is worth, buildroot is also strange with
/etc/default/ntpd without any busybox indication.

 I work with buildroot and never had a problem with ntpd and its lack
 of config file. Anyways, in spite of no seeing benefit, I don't refuse
 to implement it if it can be selected from KConfig...

Absolutely; you do not need a few lines to spare init script files,
you could disable it, but then again, some people have very strong
opinion about things, so it is better to move on IMHO.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

So it's difficult to provide and document a configuration file like this?

---
# Put your ntp nameservers here
#  Example:
# nameserver ntp.busybox.net
nameserver ntp.example.com
nameserver ntp2.example.com
---

I can see that we'll be using the full version of ntpd on our distro.
 You've fully convinced me that it's the most wise choice to make.

Thank you,

Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 3:00 PM, Michael Conrad mcon...@intellitree.comwrote:

 On 3/18/2014 3:54 PM, Mike Dean wrote:

 So you're telling me that a plain text script which takes more than 300
 bytes is a better solution than an option that could be configured out?
  But your full text option, enabled by default, takes less than 300 bytes I
 suppose?


 I'm not sure I follow.  Harald suggested adding 23 bytes to your existing
 script, and adds the convenience of a config file where there wasn't before.

 You could add that same minimal config file in C, and it would take a lot
 more than 23 bytes.

 Either way, the config file will be a thing specific to busybox ntpd and
 you will have the exact same documentation problem in teaching people how
 to use it, then they have learning about the -p command line switch.

 If you want to be compatible with a standard tool, and support ntp.conf,
 then you gain the popularly-available documentation, but add a significant
 amount of code.

 Neither way is really ideal.  So if you want to add a non-ideal solution,
 it should be done in a distro-specific script.

 -Mike

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Mike !

... We work hard to make things easy for them.  One of the
stumbling blocks our customers have had in the past is how to
configure ntpd to use their internal ntp servers.  Helping them
with this usually results in grumbling about it being
overcomplicated to perform what should be such a simple task.

This clearly a failure of your system/distro NOT Busybox. Your
build system shall provide a script to read address of your time
server from a file and use this address when calling the ntpd
daemon applet. So customers can be pointed to changing a line in
a file.

isn't added.  It's not worth the time or effort for me to edit
your code to add this.  I've simply been trying to point out
that catering to your users is the most important thing to do if
you want to keep them from jumping ship.  This may be one small
portion of Busybox, but it's one of about 20 that we've already
replaced with full versions for our upcoming release;

You are always free to replace Busybox functionality with full
versions. Busybox is neither a system nor a build system nor a
distro. It is a collection of smaller and simpler counterparts
than the usual full GNU and other utilities (Beside that there
exist other alternatives). The intention here is to have SMALL
binaries using the KISS (keep it simple and small) principle.
Adding unnecessary config file functionality without other
benefit violates this KISS principle. Everything can be achieved
with setting up your right script ... not by the customer, by
the system/distro maintainer.

shortcomings in the busybox versions aren't worth the savings in
size in the days of GHz processors and 512MB+ RAM on small cheap
embedded systems.  They're not even worth the savings on our
lowest end 200 MHz models; even those have a minimum of 128MB of
RAM.

I know ... 640 kByte RAM ought to be enough for everybody ???

... think of there are still more small systems out there, e.g.
small router boxes with very limited resources. Busybox shall
give small and simple tools for most users not a versatile system
for your customers.

If you use Busybox, make it versatile to your customers by
creating right control scripts and system setups including
full documentation, and not pointing them around to collect
information from other places, e.g. up to date version of
Busybox.html from build (not from Web-Page).

 I'm just trying to get you to see things from the standpoints
 of the people in this chain who've all clamored in favor of
 the feature.

I don't say you are wrong, but you are at the wrong place to
bother. Busybox is not a complete and easy to use system, it is
just a collection of small and simple alternatives of other
tools. Use it, when you like and build your system with it, but
don't add useless code to main binary (for thing easily being
achieved by other ways).

 ... I'll just use the full version instead and not worry about
 it.

Fine, you are always free to do this. Depending on kind of system
I replace from 30 to 75% of Busybox with full or alternative
versions, using Busybox versions as small and fast scripting
versions. 

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

 At least three people expressed that it is about convenience, a
 useful one.

Any people arguing for your request, missed the explanation why
they can't live with the already available version and some
scripting. That is now one has given a real argument why it is
necessary to add extra code for no extra benefit.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Harald, I think you do not get the meaning of convenience in here as
it was meant.

Let me give you an example: sure, people can live without convenience.
The people had not needed computers for the 99.99% of the ages and
time, but that does not mean it does not make a difference in the
world!

I would ask this question from myself if I were you: what do I gain or
lose with such a feature added or rejected? If it is rejected, there
will be some unhappier users. If it is accepted, even as an optional
feature, would anyone stop using busybox as it happens on the
counterpart? I would not stop using busybox just for this either way,
but someone apparently decided so.

Anyway, please comment on the init script that I posted earlier when
you get around to it, as well as the corresponding config file..

On Tue, Mar 18, 2014 at 8:21 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

 At least three people expressed that it is about convenience, a
 useful one.

 Any people arguing for your request, missed the explanation why
 they can't live with the already available version and some
 scripting. That is now one has given a real argument why it is
 necessary to add extra code for no extra benefit.

 --
 Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

Yet, it did not get any feedback from anyone yet. Hopefully, it
is not getting lost in the noise.

Will try to hop on this tomorrow, to late for today ... saved
your original message.

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 3:15 PM, Harald Becker ra...@gmx.de wrote:

 Hi Mike !

 ... We work hard to make things easy for them.  One of the
 stumbling blocks our customers have had in the past is how to
 configure ntpd to use their internal ntp servers.  Helping them
 with this usually results in grumbling about it being
 overcomplicated to perform what should be such a simple task.

 This clearly a failure of your system/distro NOT Busybox. Your
 build system shall provide a script to read address of your time
 server from a file and use this address when calling the ntpd
 daemon applet. So customers can be pointed to changing a line in
 a file.

 So the deficiency of your software can always be blamed on your software's
userbase?  Sounds like a winning philosophy.


 isn't added.  It's not worth the time or effort for me to edit
 your code to add this.  I've simply been trying to point out
 that catering to your users is the most important thing to do if
 you want to keep them from jumping ship.  This may be one small
 portion of Busybox, but it's one of about 20 that we've already
 replaced with full versions for our upcoming release;

 You are always free to replace Busybox functionality with full
 versions. Busybox is neither a system nor a build system nor a
 distro. It is a collection of smaller and simpler counterparts
 than the usual full GNU and other utilities (Beside that there
 exist other alternatives). The intention here is to have SMALL
 binaries using the KISS (keep it simple and small) principle.
 Adding unnecessary config file functionality without other
 benefit violates this KISS principle. Everything can be achieved
 with setting up your right script ... not by the customer, by
 the system/distro maintainer.

 shortcomings in the busybox versions aren't worth the savings in
 size in the days of GHz processors and 512MB+ RAM on small cheap
 embedded systems.  They're not even worth the savings on our
 lowest end 200 MHz models; even those have a minimum of 128MB of
 RAM.

 I know ... 640 kByte RAM ought to be enough for everybody ???

 ... think of there are still more small systems out there, e.g.
 small router boxes with very limited resources. Busybox shall
 give small and simple tools for most users not a versatile system
 for your customers.

 If you use Busybox, make it versatile to your customers by
 creating right control scripts and system setups including
 full documentation, and not pointing them around to collect
 information from other places, e.g. up to date version of
 Busybox.html from build (not from Web-Page).

  I'm just trying to get you to see things from the standpoints
  of the people in this chain who've all clamored in favor of
  the feature.

 I don't say you are wrong, but you are at the wrong place to
 bother. Busybox is not a complete and easy to use system, it is
 just a collection of small and simple alternatives of other
 tools. Use it, when you like and build your system with it, but
 don't add useless code to main binary (for thing easily being
 achieved by other ways).

  ... I'll just use the full version instead and not worry about
  it.

 Fine, you are always free to do this. Depending on kind of system
 I replace from 30 to 75% of Busybox with full or alternative
 versions, using Busybox versions as small and fast scripting
 versions.

 --
 Harald


My choice to switch stems not from having any difficulty scripting an
alternative, but rather from the lack of trust I have in the busybox
version given my opinion of the decision made by the developers regarding
something that should be a clear cut easy choice.  In my job, when the
customers want something, you find a way to give it to them.  If adding the
feature outright would bloat the system, you make it a configurable choice
so that it won't add bloat where that bloat is unwelcome, but will aid
those who value the convenience more than the space savings.  You already
have the means to do this easily, so why not do it?

When was the last time this mailing list received so many e-mails in one
day?  Especially about just one topic?  That alone should have been a red
flag to you that the users of your software feel that this is important.
 Religious zealotry about a development concept has never led to good
products; engineering (and any software development) is all about trade
offs.  Your unyielding zealotry, instead of facing the challenge of make
the trade off to satisfy the needs of your userbase, combined with you
blaming others for your own shortcomings, is what inspired me to make the
switch.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support


On 18/03/2014 20:12, Mike Dean wrote:

So it's difficult to provide and document a configuration file like this?


 It's not difficult.
 But it conflicts with some of the goals of Busybox.

 Parsing a config file has several drawbacks:
 - It is much more complicated than reading command-line arguments. It
requires *a lot* more code, and parsing code is error-prone. In the
grand scheme of things, a simple parser might not seem much, but when
a tool tries to be as small and simple as can be, adding an unneeded
parser is not the way to go.
 - It adds state in the filesystem. When you run the ntpd command line,
what happens now depends on your config file. Also, it adds a burden on
the programmer: what if the state changes? And now he wants to add
signal handling to the small tool to gracefully handle config change
notifications via SIGHUP. Your program is now using a parser and the
signal stack, for no obvious benefit. Again, this might not seem much,
but changing from stateless to stateful should not be done lightly,
especially for a Busybox applet.

 You are the distributor. If you feel your users will be more at ease
with a configuration file, by all means, write a program that parses
a configuration file into command-line arguments and launches ntpd with
those arguments. It's not difficult, you said so yourself; and everyone
will be happy. But that's your job as a distributor, it's not upstream's.



I can see that we'll be using the full version of ntpd on our distro.
 You've fully convinced me that it's the most wise choice to make.


 ... oh. Well, if you feel that switching to full ntpd will be less work
for you than writing a trivial config parser, and you can live with
eating 20 times as much resources, it is indeed the wise choice to make.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Laurent,

I am currently having difficulties to understand your reply. It seems
that you have skipped some of the previous emails. Both me and Mike
were suggesting a simple config parser without signals to see how it
goes, and add that later if really needed.

More importantly, as far as I understand, Mike is suggesting a compile
time option for this. Please correct me if I am wrong. So, your claim
of eating 20 times much resources is moot. If you do not need it, it
will eat as much resource.

The whole idea of being minimal just for the sake of being minimal
without even optional configurability is unreal when it makes people
use different software than YOURS. Unfortunately, it seems to be a
loss for everyone involved in my opinion.

That being said, I will try hard to move on with my initscript. :)

On Tue, Mar 18, 2014 at 8:33 PM, Laurent Bercot
ska-dietl...@skarnet.org wrote:
 On 18/03/2014 20:12, Mike Dean wrote:

 So it's difficult to provide and document a configuration file like this?


  It's not difficult.
  But it conflicts with some of the goals of Busybox.

  Parsing a config file has several drawbacks:
  - It is much more complicated than reading command-line arguments. It
 requires *a lot* more code, and parsing code is error-prone. In the
 grand scheme of things, a simple parser might not seem much, but when
 a tool tries to be as small and simple as can be, adding an unneeded
 parser is not the way to go.
  - It adds state in the filesystem. When you run the ntpd command line,
 what happens now depends on your config file. Also, it adds a burden on
 the programmer: what if the state changes? And now he wants to add
 signal handling to the small tool to gracefully handle config change
 notifications via SIGHUP. Your program is now using a parser and the
 signal stack, for no obvious benefit. Again, this might not seem much,
 but changing from stateless to stateful should not be done lightly,
 especially for a Busybox applet.

  You are the distributor. If you feel your users will be more at ease
 with a configuration file, by all means, write a program that parses
 a configuration file into command-line arguments and launches ntpd with
 those arguments. It's not difficult, you said so yourself; and everyone
 will be happy. But that's your job as a distributor, it's not upstream's.



 I can see that we'll be using the full version of ntpd on our distro.
  You've fully convinced me that it's the most wise choice to make.


  ... oh. Well, if you feel that switching to full ntpd will be less work
 for you than writing a trivial config parser, and you can live with
 eating 20 times as much resources, it is indeed the wise choice to make.

 --
  Laurent


 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Andreas Oberritter

On 18.03.2014 21:11, Laszlo Papp wrote:
 On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca  --  xOneca
 xon...@gmail.com wrote:
 Usually scripts in /etc/init.d use /etc/default/* as config values
 (some distros, even using them as main config files). The scripts that
 Laszlo posted fit that pattern.
 
 Not quite; actually /etc/default is more like a Debian, et al,
 pattern. OpenWrt will use something. Yocto uses something else, etc.
 And for what it is worth, buildroot is also strange with
 /etc/default/ntpd without any busybox indication.

Speaking of Yocto, our Yocto-based firmware contains 9 config files by
default in /etc/default, one of which is /etc/default/busybox-syslog.
The latter may have disappeared in more recent versions of Yocto, but
anyway, I just want to show you that /etc/default isn't used by Debian only.

Actually, it isn't important which location you use for these files. As
long as you use a simple KEY=VALUE format, you can use them in
shell-based initscripts, systemd and upstart, at least.

Regarding the script you posted, I'd remove the export statement from
the config file to make it look less like a shell script (and to match
the format above).

Regards,
Andreas
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Laszlo !

 ... If it is rejected, there will be some unhappier users.

Beside you are not giving any arguments, you are at the wrong
place. Again: Busybox is a set of tools which may be used to
build a small and simple system. Convince for users is the
job of system or distro maintainers, which use Busybox for there
system.

Even giving full init scripts is not the job of the Busybox
maintainers, as those scripts and config files belong to the
systems/distros infrastructure.

Nevertheless you may ask for help creating scripts, and
functionalities using Busybox tools. I ought you will get a lot
of info here when you ask the right questions ... but not when
you try to force a specific change without giving real
benefit ... that just creates a shit storm which no one likes
(big chance of getting deleted by filters).

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Andreas,

On Tue, Mar 18, 2014 at 8:41 PM, Andreas Oberritter
o...@opendreambox.org wrote:
On 18.03.2014 21:11, Laszlo Papp wrote:
On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
xon...@gmail.com wrote:
Usually scripts in /etc/init.d use /etc/default/* as config values
(some distros, even using them as main config files). The scripts that
Laszlo posted fit that pattern.

Not quite; actually /etc/default is more like a Debian, et al,
pattern. OpenWrt will use something. Yocto uses something else, etc.
And for what it is worth, buildroot is also strange with
/etc/default/ntpd without any busybox indication.

Speaking of Yocto, our Yocto-based firmware contains 9 config files by
default in /etc/default, one of which is /etc/default/busybox-syslog.

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/busybox/busybox.inc#n24

It is the last fallback, but note that Yocto is not a distribution,
but distribution generator, so it has to support a wide variety of
things.

That being said, it is only the syslog applet, and only as the last
position in the order. You will not necessarily find the same for
others. It is nice from them they do this, but it is not how these
things are put in general. Check the aforementioned file further on
for details.

The latter may have disappeared in more recent versions of Yocto, but
anyway, I just want to show you that /etc/default isn't used by Debian only.

No, it has not disappeared. It has been like that for a while. OpenWrt
will use something else, and buildroot does not even bother to
indicate busybox in the name!

Actually, it isn't important which location you use for these files. As
long as you use a simple KEY=VALUE format, you can use them in
shell-based initscripts, systemd and upstart, at least.
Regarding the script you posted, I'd remove the export statement from
the config file to make it look less like a shell script (and to match
the format above).

Yes, I agree. It was used so that I could test it quickly from shell,
too. I should probably add come comment into the config file, however.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 8:58 PM, Harald Becker ra...@gmx.de wrote:
 Hi Laszlo !

 ... If it is rejected, there will be some unhappier users.

 Beside you are not giving any arguments, you are at the wrong
 place.

Harald, there is a difference between not giving any arguments and
giving a few that you may disagree with, I hope you realize. It may
have just been improper wording.

 Again: Busybox is a set of tools which may be used to
 build a small and simple system. Convince for users is the
 job of system or distro maintainers, which use Busybox for there
 system.

I do not follow. The busybox user is the distro and maintainer in this
case, really. The end user is not necessarily even aware of busybox,
just some configuration application well hiding even the fact that is
a linux box.

 Even giving full init scripts is not the job of the Busybox
 maintainers, as those scripts and config files belong to the
 systems/distros infrastructure.
 Nevertheless you may ask for help creating scripts, and
 functionalities using Busybox tools. I ought you will get a lot
 of info here when you ask the right questions ... but not when
 you try to force a specific change without giving real
 benefit ... that just creates a shit storm which no one likes
 (big chance of getting deleted by filters).

I would really appreciate more respect here towards end users. No one
is forcing anything. The end users have raised their opinion how they
would like to see your software behaving. It is not the right tone to
tell that their opinion is a shit storm. In fact, as an end user it
feels quite scary to hear, I must confess.


 --
 Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support


On 18/03/2014 20:29, Mike Dean wrote:

So the deficiency of your software can always be blamed on your software's 
userbase?  Sounds like a winning philosophy.


 The fact that you still think using command-line arguments instead of
a config file is a deficiency shows that you are missing the point.
Not having a config file when a config file is not needed is not a
deficiency, it's a design decision - and a pretty sound one.
 The fact that your tools apparently cannot easily work with command-line
arguments is not Busybox's problem, it's a severe misdesign of your tools.
Command-line arguments are the very basis of the Unix API; you've been
working with it since the 80s, you should know that by now. :P

 If you want to extend ntpd's interface for your users and add a config
file, you're free to do so. It's not hard. But, again, this is a job for
*you* as an integrator: do not try to shift the burden of doing it to
upstream, because it's not where it belongs. You are of course free to
contribute and submit patches: maybe they'll be accepted, maybe not.
But coming to the list asking people to do your job for you and getting
all haughty when your request is politely denied probably isn't the best
way to get things done.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Mike !

 If adding the feature outright would bloat the system, you make
 it a configurable choice so that it won't add bloat where that
 bloat is unwelcome, but will aid those who value the
 convenience more than the space savings.  You already have the
 means to do this easily, so why not do it?

You are at the wrong place. It's not a question of having
configuration or not. Send your convenience request to your
system/distro maintainer. It's clearly there job to use tools to
build a system. And to have configurations to satisfy user needs.

Nothing is wrong with this, all can be done with current Busybox
versions. There is no need to add extra code to configure one or
two time servers.

When was the last time this mailing list received so many
e-mails in one day?  Especially about just one topic?  That
alone should have been a red flag to you that the users of your
software feel that this is important.
 Religious zealotry about a development concept has never led to
 good
products; engineering (and any software development) is all
about trade offs.  Your unyielding zealotry, instead of facing
the challenge of make the trade off to satisfy the needs of your
userbase, combined with you blaming others for your own
shortcomings, is what inspired me to make the switch.

You left the path of qualified arguments. Don't going further on
this ...

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Actually, I didn't come to the list to ask for the feature.  Someone else
came here to ask for it; I just seconded this person.  You, much like
Harald, are blaming the deficiencies of your design decisions on your
users.  The haughty attitude, from our standpoint, comes from you, not from
us.  To start with, we don't design the tools; we are in the business of
designing hardware, writing device drivers, contributing to the Linux
kernel and getting Linux up and running on our hardware; then, we customize
the embedded Linux distro until everything is sane.  Then we add features
that we know our customers want.  It is this last part that you're missing
the point of.  We pick the sane tools, and configure them properly.  When a
tool isn't sane, we find an alternative that is.  That's why I have now
chosen to use the normal ntpd over the busybox implementation.


Mike Dean

md...@emacinc.com
http://www.emacinc.com/

Engineer
EMAC, Inc.
618-529-4525 Ext. 330
618-457-0110 Fax
2390 EMAC Way
Carbondale, Il 62901



On Tue, Mar 18, 2014 at 4:05 PM, Laurent Bercot ska-dietl...@skarnet.orgwrote:

 On 18/03/2014 20:29, Mike Dean wrote:

 So the deficiency of your software can always be blamed on your
 software's userbase?  Sounds like a winning philosophy.


  The fact that you still think using command-line arguments instead of
 a config file is a deficiency shows that you are missing the point.
 Not having a config file when a config file is not needed is not a
 deficiency, it's a design decision - and a pretty sound one.
  The fact that your tools apparently cannot easily work with command-line
 arguments is not Busybox's problem, it's a severe misdesign of your tools.
 Command-line arguments are the very basis of the Unix API; you've been
 working with it since the 80s, you should know that by now. :P

  If you want to extend ntpd's interface for your users and add a config
 file, you're free to do so. It's not hard. But, again, this is a job for
 *you* as an integrator: do not try to shift the burden of doing it to
 upstream, because it's not where it belongs. You are of course free to
 contribute and submit patches: maybe they'll be accepted, maybe not.
 But coming to the list asking people to do your job for you and getting
 all haughty when your request is politely denied probably isn't the best
 way to get things done.

 --
  Laurent


 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

Hi Mike !

On 18-03-2014 15:12 Mike Dean md...@emacinc.com wrote:
# Put your ntp nameservers here

To clarify: It's not a name server, it's a time server (NTP =
network time protocol).

... and what makes it difficult to write such things in a file,
use an sed filter to read that config into a script variable,
then use the arguments from variable when invoking Busybox ntpd?

With some clever sed rules you can filter out empty lines and
comments, pick lines which start with timeserver then add the
required -p parameter prefix to any such lines, giving a
roughly checked with no increase of binary file (binary file
always use memory, scripts are read as files by line/buffer and
don't need to be completely in memory, file space is cheap
compared to working memory -- rough explanation why script size
matters less than binary size, details depend on many factors). 

--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Ralf Friedl


Hi Laszlo

First, please either write your message below the quotes, or omit the 
quotes. Especially don't quote parts that are not relevant to your message.


Laszlo Papp wrote:

At least three people expressed that it is about convenience, a useful
one.
Well, all of them didn't provide a convincing argument. And most others 
on this list wonder why you make such a big deal about something that 
can be solved with a few lines in a shell script. If you want a 
configuration file only for the time servers, this script will give you 
compatibility to the ntp.org config file:

#!/bin/sh
NTPD_OPTIONS=...
exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p 
\1/g'/etc/ntp.conf )



Anyway, please comment on the init script that I posted earlier when
you get around to it, as well as the corresponding config file..

I'm not Harald, but I will comment on it anyway.
Short version:
It's a very nice script. Use it. Be very happy with it.

Long version:
I guess it fits into your distibution, but it's useless for most others. 
That was one of the points Harald made, you want things specific to your 
distibution in Busybox, where they don't belong. You could place it 
somewhere in the contrib directory, but it would probably be a waste of 
space and bandwidth.
Most distributions come with a template for such a script, and it 
shouldn't take more than a few minutes to adapt such a template.
You use start-stop-daemon. Why do you think everybody would even have 
the program, or want to use it?
Your script has a reaload case, where you send SIGHUP. What should ntpd 
do on SIGHUP? Reload the config file? You said that reloading the config 
is not necessary when it was about code size, so why send SIGHUP?

Finally, the export in the configuration file is not necessary.

In one email in this thread someone suggested to make the configuration 
hardcoded as the compile time configuration. I just hope that was meant 
as a joke.



 Usually scripts in/etc/init.d use /etc/default/* as config values
 (some distros, even using them as main config files). The scripts that
 Laszlo posted fit that pattern.
Not quite; actually /etc/default is more like a Debian, et al,
pattern. OpenWrt will use something. Yocto uses something else, etc.
And for what it is worth, buildroot is also strange with
/etc/default/ntpd without any busybox indication.
Which again shows that distributions are different, so which distibution 
style should Busybox pick? It is up to the distribution to provide the 
right information to the program.



I would ask this question from myself if I were you: what do I gain or
lose with such a feature added or rejected? ...
That is a good question if maximizing the number of users is the top 
priority.


Also someone suggested that devices today have GHz CPUs and at least 
512MB RAM. Well, maybe they are not the target audience of busybox. 
There are also devices with 16MB RAM and 4MB flash.



I do not follow. The busybox user is the distro and maintainer in this
case, really. The end user is not necessarily even aware of busybox,
I would really appreciate more respect here towards end users.
The end users have raised their opinion how they
would like to see your software behaving.
I hope you realize that you are contradicting yourself here, within a 
few lines of a single email.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl ralf.fri...@online.de wrote:
 Hi Laszlo

 First, please either write your message below the quotes, or omit the
 quotes. Especially don't quote parts that are not relevant to your message.

I have no idea what point you are trying to make in here, sorry, nor
do I care about the details 'cause the thread is already huge.

 At least three people expressed that it is about convenience, a useful
 one.

 Well, all of them didn't provide a convincing argument. And most others on
 this list wonder why you make such a big deal about something that can be
 solved with a few lines in a shell script. If you want a configuration file
 only for the time servers, this script will give you compatibility to the
 ntp.org config file:
 #!/bin/sh
 NTPD_OPTIONS=...
 exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p
 \1/g'/etc/ntp.conf )

I wonder if you are serious about this compared to the alternative way:

/etc/busybox-ntpd/busybox-ntpd.conf
foo=bar

I guess you are trying to be smart in here without actually realizing
significant difference between the two versions. I would not even
bother to use busybox's ntpd if I had to write such ugly lines that is
much more difficult to maintain than needed to.

 Anyway, please comment on the init script that I posted earlier when
 you get around to it, as well as the corresponding config file..

 I'm not Harald, but I will comment on it anyway.
 Short version:
 It's a very nice script. Use it. Be very happy with it.

 Long version:
 I guess it fits into your distibution, but it's useless for most others.
 That was one of the points Harald made, you want things specific to your
 distibution in Busybox, where they don't belong. You could place it
 somewhere in the contrib directory, but it would probably be a waste of
 space and bandwidth.
 Most distributions come with a template for such a script, and it shouldn't
 take more than a few minutes to adapt such a template.
 You use start-stop-daemon. Why do you think everybody would even have the
 program, or want to use it?

Seriously though, you did not get the point of the thread, have you?
*No one* has suggested to add initscripts to busybox. Please do
re-read the thread. A short configuration file was just suggested. You
are the first one indicating that initscript would need to be added.

 Your script has a reaload case, where you send SIGHUP. What should ntpd do
 on SIGHUP? Reload the config file? You said that reloading the config is not
 necessary when it was about code size, so why send SIGHUP?

Sorry, I cannot follow your logic in here. There is no any need for
signal handling in order to load a config on start, really.

 Finally, the export in the configuration file is not necessary.

It was already discussed, I am afraid.

 In one email in this thread someone suggested to make the configuration
 hardcoded as the compile time configuration. I just hope that was meant as a
 joke.

Not at all, no. It was serious, at least from my side.

  Usually scripts in/etc/init.d use /etc/default/* as config values

  (some distros, even using them as main config files). The scripts that
  Laszlo posted fit that pattern.
 Not quite; actually /etc/default is more like a Debian, et al,
 pattern. OpenWrt will use something. Yocto uses something else, etc.
 And for what it is worth, buildroot is also strange with
 /etc/default/ntpd without any busybox indication.

 Which again shows that distributions are different, so which distibution
 style should Busybox pick? It is up to the distribution to provide the right
 information to the program.

Exactly the opposite. You really missed the point of this thread. The
whole point about configuration file is to unify it, for me at least.

 I would ask this question from myself if I were you: what do I gain or
 lose with such a feature added or rejected? ...

 That is a good question if maximizing the number of users is the top
 priority.

Dropping users do not make any sense without gaining more which seems
to be the case here so far.

 Also someone suggested that devices today have GHz CPUs and at least 512MB
 RAM. Well, maybe they are not the target audience of busybox. There are also
 devices with 16MB RAM and 4MB flash.

Actually, the compilation time option has already been said, but let
us consider that for a second it has not... Are you telling me that a
simple open/read/close will saturate the flas because it is complex.
You better stop writing software then because you exceed the limit
very quickly. :-)

 I do not follow. The busybox user is the distro and maintainer in this
 case, really. The end user is not necessarily even aware of busybox,
 I would really appreciate more respect here towards end users.
 The end users have raised their opinion how they
 would like to see your software behaving.

 I hope you realize that you are contradicting yourself here, within a few
 lines of a single email.

No, I do not. I still stick by my

RE: Ntpd config file support

2014-03-18 Thread Cathey, Jim

I think that a project's charter should define
what it does _not_ do just as much as what it _does_.
That can help avoid feeping creaturism that ends
up rendering it unsuitable for its main use(s).

-- Jim

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support


On 18/03/2014 21:28, Laszlo Papp wrote:


Exactly the opposite. You really missed the point of this thread. The
whole point about configuration file is to unify it, for me at least.


 But what makes you think a configuration file would unify the way
distributions run busybox ntpd more than the current command-line
arguments do ? It would certainly cater to your use case, and certainly
not to others.

 Again: packagers will repackage - right or wrong, that's what they do -
and not give a flying duck about your dream of unified ntpd scripts.
All Busybox can do is provide sensible interfaces and do its job of
being small, and all you can do is use it and work with it in the way
you like best.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Ralf Friedl


Laszlo Papp wrote:

On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl ralf.fri...@online.de wrote:

First, please either write your message below the quotes, or omit the
quotes. Especially don't quote parts that are not relevant to your message.

I have no idea what point you are trying to make in here, sorry, nor
do I care about the details 'cause the thread is already huge.

I should have guessed so.


If you want a configuration file
only for the time servers, this script will give you compatibility to the
ntp.org config file:
#!/bin/sh
NTPD_OPTIONS=...
exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p
\1/g'/etc/ntp.conf )

I wonder if you are serious about this compared to the alternative way:

/etc/busybox-ntpd/busybox-ntpd.conf
foo=bar

I guess you are trying to be smart in here without actually realizing
significant difference between the two versions. I would not even
bother to use busybox's ntpd if I had to write such ugly lines that is
much more difficult to maintain than needed to.
I have no preference either way, and there are advantages and drawbacks 
to both approaches. I didn't say that there are no differences, so no 
need for you to imply that such a statement would have been wrong.

Seriously though, you did not get the point of the thread, have you?
*No one* has suggested to add initscripts to busybox. Please do
re-read the thread. A short configuration file was just suggested. You
are the first one indicating that initscript would need to be added.
Well, someone using your email adresse has posted an init script and 
asked for opinions about it. And no, I won't re-read the thread, it 
would be more waste of time.
Anybody who seriously considers making a distribution should be able to 
put such a script tugether within a few minutes without asking here for 
help.



Your script has a reaload case, where you send SIGHUP. What should ntpd do
on SIGHUP? Reload the config file? You said that reloading the config is not
necessary when it was about code size, so why send SIGHUP?

Sorry, I cannot follow your logic in here. There is no any need for
signal handling in order to load a config on start, really.
You can't follow, or you don't want to. It is about these lines in the 
init script someone proposed in your name:


+reload)
+echo -n reloading $DESC: $NAME... 
+killall -HUP $(basename ${DAEMON})



In one email in this thread someone suggested to make the configuration
hardcoded as the compile time configuration. I just hope that was meant as a
joke.

Not at all, no. It was serious, at least from my side.
It thought it was from someone else, but if you are serious about it, 
just do it.

I do not follow. The busybox user is the distro and maintainer in this
case, really. The end user is not necessarily even aware of busybox,
I would really appreciate more respect here towards end users.
The end users have raised their opinion how they
would like to see your software behaving.

I hope you realize that you are contradicting yourself here, within a few
lines of a single email.

No, I do not. I still stick by my opinion in here I am afraid.
I will try to explain it slowly. In the first sentence you say the end 
user is not even aware of busybox. Then you say that end users have here 
raised their opinion about config files and ntpd.

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Aaro Koskinen

On Tue, Mar 18, 2014 at 01:43:43PM +0100, Harald Becker wrote:
 The Busybox ntpd applet get all information it needs via command
 line, so it doesn't need to read any config file.

I agree, it would be overlapping functionality and not needed.

A.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Xabier Oneca -- xOneca

Hello,

2014-03-18 22:17 GMT+01:00 Ralf Friedl ralf.fri...@online.de:
  Usually scripts in/etc/init.d use /etc/default/* as config values

  (some distros, even using them as main config files). The scripts that
  Laszlo posted fit that pattern.
 Not quite; actually /etc/default is more like a Debian, et al,
 pattern. OpenWrt will use something. Yocto uses something else, etc.
 And for what it is worth, buildroot is also strange with
 /etc/default/ntpd without any busybox indication.

 Which again shows that distributions are different, so which distibution
 style should Busybox pick? It is up to the distribution to provide the right
 information to the program.

Just to note, OpenSUSE also uses /etc/default, and not only for
daemons (e.g. in my computer are grub, nss, splashy, su and useradd
config files in there). I'm not saying it is the best place for config
files, but I usually use it (not in buildroot) to store similar config
files loaded from init scripts.

Cheers,
Xabier Oneca_,,_
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Xabier Oneca -- xOneca

Hello Laszlo,

2014-03-18 22:28 GMT+01:00 Laszlo Papp lp...@kde.org:
 If you want a configuration file
 only for the time servers, this script will give you compatibility to the
 ntp.org config file:
 #!/bin/sh
 NTPD_OPTIONS=...
 exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p
 \1/g'/etc/ntp.conf )

 I wonder if you are serious about this compared to the alternative way:

 /etc/busybox-ntpd/busybox-ntpd.conf
 foo=bar

I think you didn't see what Ralf did there. He is actually parsing an
(standard?) ntp.conf file and picking the 'server ' lines to pass
as -p  options to BB ntpd.

There. You don't have to invent another config file for ntpd. He
parsed the original format for Busybox to understand it!

Cheers,
Xabier Oneca_,,_


P.S. Please guys, calm down..!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

2014-03-18 Thread Cristian Ionescu-Idbohrn

On Tue, 18 Mar 2014, Laszlo Papp wrote:

 I would really appreciate more respect here towards end users. No one
 is forcing anything.

You're barking at the wrong tree, Laszlo.

 The end users have raised their opinion how they would like to see
 your software behaving.

Who's the end user here?  The end user may want to be able to
configure.  The distribution may want to provide the means.

 It is not the right tone to tell that their opinion is a shit
 storm. In fact, as an end user it feels quite scary to hear, I must
 confess.

Boy, oh boy.  Incredible how much effort went into this thread.  But
it should be ok.  It's hopefully part of the process.


Cheers,

-- 
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support

On Tue, Mar 18, 2014 at 10:30 PM, Xabier Oneca  --  xOneca
xon...@gmail.com wrote:
 Hello,

 2014-03-18 22:17 GMT+01:00 Ralf Friedl ralf.fri...@online.de:
  Usually scripts in/etc/init.d use /etc/default/* as config values

  (some distros, even using them as main config files). The scripts that
  Laszlo posted fit that pattern.
 Not quite; actually /etc/default is more like a Debian, et al,
 pattern. OpenWrt will use something. Yocto uses something else, etc.
 And for what it is worth, buildroot is also strange with
 /etc/default/ntpd without any busybox indication.

 Which again shows that distributions are different, so which distibution
 style should Busybox pick? It is up to the distribution to provide the right
 information to the program.

 Just to note, OpenSUSE also uses /etc/default, and not only for
 daemons (e.g. in my computer are grub, nss, splashy, su and useradd
 config files in there). I'm not saying it is the best place for config
 files, but I usually use it (not in buildroot) to store similar config
 files loaded from init scripts.

I think you missed the et al part. I explicitly said Debian, et
al, but let us not play name games. The main message is that we saw
four different ways right in the beginning of the thread, and guess
what: the complete ntpd implementation unified it. They were able to
make it!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Ntpd config file support