How about ... for instance merging this thing ... ?
On Mon, Mar 24, 2014 at 3:13 AM, Isaac Dunham wrote:
> On Sun, Mar 23, 2014 at 03:06:08PM +0100, Denys Vlasenko wrote:
>> On Saturday 22 March 2014 23:46, Isaac Dunham wrote:
>> > On Sat, Mar 22, 2014 at 08:40:48PM +0100, Harald Becker wrote:
>>
On Mon, Mar 24, 2014 at 2:15 AM, Harald Becker wrote:
>>+ bb_error_msg("skipping %s:%u:
>>unimplemented command '%s'",
>>+ "/etc/ntp.conf",
>>parser->lineno, token[0]
>>+ );
>
> Bad idea to do this! The default ntpd.conf contai
In the 2.6 and 3.x kernels, you annotate your init functions with the
__init macro, like so:
static int __init myinit( void ) { return 0; }
No more hoops are needed, but no fewer. It's simple, and it works well for
the kernel.
Mike Dean
md...@emacinc.com
http://www.emacinc.com/
Engineer
EMA
On Sun, Mar 23, 2014 at 03:06:08PM +0100, Denys Vlasenko wrote:
> On Saturday 22 March 2014 23:46, Isaac Dunham wrote:
> > On Sat, Mar 22, 2014 at 08:40:48PM +0100, Harald Becker wrote:
> > > Hi Isaac !
> > >
> > > Your program will fail on lines starting with the word server
> > > (eg. serverxyz)
Hi Denys !
>+ bb_error_msg("skipping %s:%u:
>unimplemented command '%s'",
>+ "/etc/ntp.conf",
>parser->lineno, token[0]
>+ );
Bad idea to do this! The default ntpd.conf contains other options
than just server lines. All those
On Saturday 22 March 2014 23:46, Isaac Dunham wrote:
> On Sat, Mar 22, 2014 at 08:40:48PM +0100, Harald Becker wrote:
> > Hi Isaac !
> >
> > Your program will fail on lines starting with the word server
> > (eg. serverxyz), that is it does not check for clear word
> > boundary and gives wrong resu
On Saturday 22 March 2014 23:46:44 Isaac Dunham wrote:
> On Sat, Mar 22, 2014 at 08:40:48PM +0100, Harald Becker wrote:
> > Hi Isaac !
> >
> > Your program will fail on lines starting with the word server
> > (eg. serverxyz), that is it does not check for clear word
> > boundary and gives wrong re
On Sat, Mar 22, 2014 at 08:40:48PM +0100, Harald Becker wrote:
> Hi Isaac !
>
> Your program will fail on lines starting with the word server
> (eg. serverxyz), that is it does not check for clear word
> boundary and gives wrong results in that case.
...which are not legitimate entries in ntp.con
On 22 March 2014 21:27:51 Rich Felker wrote:
On Sat, Mar 22, 2014 at 08:59:28PM +0100, Ralf Friedl wrote:
> Harald Becker wrote:
> >Your program will fail on lines starting with the word server
> >(eg. serverxyz), that is it does not check for clear word
> >boundary and gives wrong results in t
On Sat, Mar 22, 2014 at 08:59:28PM +0100, Ralf Friedl wrote:
> Harald Becker wrote:
> >Your program will fail on lines starting with the word server
> >(eg. serverxyz), that is it does not check for clear word
> >boundary and gives wrong results in that case.
> The program will not fail for serverx
Harald Becker wrote:
Your program will fail on lines starting with the word server
(eg. serverxyz), that is it does not check for clear word
boundary and gives wrong results in that case.
The program will not fail for serverxyz, it will add a server "xyz".
This may be a bug or a feature :-)
w
Hi Isaac !
Your program will fail on lines starting with the word server
(eg. serverxyz), that is it does not check for clear word
boundary and gives wrong results in that case.
>while (cbuf[i] > 35) i++;
Unwise to do this in a not poor ASCII environment, as most
systems are nowadays. This way y
Hello,
I got tired of hearing numbers thrown around without basis in a 4-5 day old
thread
when the subject was probably trivial, so I wrote a parser for ntp.conf
this morning.
This version falls back to /etc/ntp.conf when -p is not specified; if -p
is specified, ntp.conf is ignored. Only lines st
On Sat, Mar 22, 2014, at 1:57, Laurent Bercot wrote:
> On 21/03/2014 23:10, Cathey, Jim wrote:
> > The only thing BB would need would be to isolate initialization
> > into separate functions that would be grouped together by the
> > linker. (And an associated link control file.) The usual demand-
Mike Dean wrote:
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
mess
Gcc has an attribute you can assign, I'm using it
to push some .idata into .text that I want read-only.
#ifndef TEXTSEG
# ifdef __GNUC__
#define TEXTSEG __attribute__((section (".text#")))
# else
#define TEXTSEG
# endif
#endif
...
const Type instance[] TEXTSEG = {...};
...
You could us
On 21/03/2014 23:10, Cathey, Jim wrote:
The only thing BB would need would be to isolate initialization
into separate functions that would be grouped together by the
linker. (And an associated link control file.) The usual demand-paged
kernel will take care of the rest.
Yes, that would defi
On Sat, Mar 22, 2014 at 12:01 AM, Mike Dean wrote:
> You should've read the full thread. The suggestion was to use dlopen() to
> fix busybox keeping init code for *everything* in memory when it's not
> needed, not just for a parser for an ntpd config file.
For the umpteen time: busybox DOES NOT
c: busybox
Subject: Re: Ntpd config file support
You should've read the full thread. The suggestion was to use dlopen() to fix
busybox keeping init code for *everything* in memory when it's not needed, not
just for a parser for an ntpd config file.
Mike Dean
md...@emacinc.com<mailto:
You should've read the full thread. The suggestion was to use dlopen() to
fix busybox keeping init code for *everything* in memory when it's not
needed, not just for a parser for an ntpd config file.
Mike Dean
md...@emacinc.com
http://www.emacinc.com/
Engineer
EMAC, Inc.
618-529-4525 Ext. 330
6
Are you seriously suggesting to add dlopen()ed libraries to busybox
to offset the bloat of adding a config file parser to ntpd ?
This is the exact kind of "design" that busybox is fighting.
Please readhttp://busybox.net/FAQ.html#goals and
http://busybox.net/FAQ.html#tips_memory , as well as
I agree completely. I was just trying to show a simple example.
Mike Dean
On Fri, Mar 21, 2014 at 11:37 AM, Bernd Petrovitsch <
be...@petrovitsch.priv.at> wrote:
> On Fre, 2014-03-21 at 10:50 -0500, Mike Dean wrote:
> []
> > pseudo-code:
>
> A real patch would have been a step in the righ
On Fre, 2014-03-21 at 10:50 -0500, Mike Dean wrote:
[]
> pseudo-code:
A real patch would have been a step in the right direction.
BTW the Linux kernel achieves that feature by annotating
init-only-functions (and their data) explicitly so that these can end up
in separate segments (which are f
Incorrect? How so? Show me how, when manually directed, my statement is
incorrect.
pseudo-code:
int main( int, char ** )
{
...
// Figure out my identity (run as ls, ifplugd, ntpd, etc.)
...
if( my_identity->not_initialized )
{
myptr = dlopen( mylibname, myflags );
sym = dlsym( h, init_f
On Thu, Mar 20, 2014 at 8:15 PM, Mike Dean wrote:
> 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
Hi guys,
to come back to the original discussion: I think providing an own config
file for ntpd is too much. You could put a script into the Busybox
sources parsing the original ntpd config file and handing the data
gained that way over to the Busybox ntpd, as discussed much earlier on
this thread
On 20 March 2014 18:47:55 Mike Dean wrote:
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 l
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
On Thu, Mar 20, 2014 at 6:47 PM, Mike Dean 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 kern
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 to
On Thu, Mar 20, 2014 at 5:28 PM, Mike Dean 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 L
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
mes
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 c
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
On Thu, Mar 20, 2014 at 2:01 PM, Harald Becker 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 compil
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 othe
On Thu, Mar 20, 2014 at 12:44 PM, Denys Vlasenko
wrote:
> On Thu, Mar 20, 2014 at 12:02 PM, Laszlo Papp wrote:
>> On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
>> wrote:
>>> On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp wrote:
On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
wrote
On Thu, Mar 20, 2014 at 12:02 PM, Laszlo Papp wrote:
> On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
> wrote:
>> On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp wrote:
>>> On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
>>> wrote:
With ntpd configuration file feature, in many cases you a
On Thu, Mar 20, 2014 at 10:53 AM, Denys Vlasenko
wrote:
> On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp wrote:
>> On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
>> wrote:
>>> With ntpd configuration file feature, in many cases you are likely
>>> to still need a script such as this to regenerat
On Thu, Mar 20, 2014 at 11:50 AM, Laszlo Papp wrote:
> On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
> 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 a
On Thu, Mar 20, 2014 at 10:47 AM, Denys Vlasenko
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 re
On Tue, Mar 18, 2014 at 11:37 AM, Laszlo Papp 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
On Tue, Mar 18, 2014 at 10:15:21PM +0100, Harald Becker wrote:
> Hi Mike !
>
> On 18-03-2014 15:12 Mike Dean 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 th
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 o
On Tue, Mar 18, 2014 at 8:29 PM, Harald Becker 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 i
On Wed, Mar 19, 2014 at 03:37:25AM +, Laszlo Papp wrote:
> On Tue, Mar 18, 2014 at 10:46 PM, Xabier Oneca -- xOneca
> wrote:
> > Hello Laszlo,
> >
> > 2014-03-18 22:28 GMT+01:00 Laszlo Papp :
> >>> If you want a configuration file
> >>> only for the time servers, this script will give you co
On Tue, Mar 18, 2014 at 10:46 PM, Xabier Oneca -- xOneca
wrote:
> Hello Laszlo,
>
> 2014-03-18 22:28 GMT+01:00 Laszlo Papp :
>>> 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=
On Tue, Mar 18, 2014 at 10:30 PM, Xabier Oneca -- xOneca
wrote:
> Hello,
>
> 2014-03-18 22:17 GMT+01:00 Ralf Friedl :
>>> > 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 t
On Tue, Mar 18, 2014 at 10:03 PM, Laurent Bercot
wrote:
> 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
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 her
Hello Laszlo,
2014-03-18 22:28 GMT+01:00 Laszlo Papp :
>> 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
>> \
Hello,
2014-03-18 22:17 GMT+01:00 Ralf Friedl :
>> > 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
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.
___
b
Laszlo Papp wrote:
On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl 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 car
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 cu
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
htt
On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl 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 ab
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 convinc
Hi Mike !
On 18-03-2014 15:12 Mike Dean 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,
the
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 s
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
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 po
On Tue, Mar 18, 2014 at 8:58 PM, Harald Becker 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 yo
Hi Andreas,
On Tue, Mar 18, 2014 at 8:41 PM, Andreas Oberritter
wrote:
> On 18.03.2014 21:11, Laszlo Papp wrote:
>> On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
>> wrote:
>>> Usually scripts in /etc/init.d use /etc/default/* as config values
>>> (some distros, even using them as mai
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
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 understa
On 18.03.2014 21:11, Laszlo Papp wrote:
> On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
> 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 q
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 argum
On Tue, Mar 18, 2014 at 3:15 PM, Harald Becker 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 gru
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
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
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 e
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 su
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 con
On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
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
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
dist
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. H
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
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 fo
I couldn't agree more, Laszlo.
Sent from my iPhone
> On Mar 18, 2014, at 2:44 PM, Laszlo Papp 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, S
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)
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
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
wrote:
> Hi Mike et.al,
>
> I have just finished reading through this thread and yet I have not seen
Hi Bryan !
On 18-03-2014 19:10 Bryan Evenson 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 an
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 pract
On Tue, Mar 18, 2014 at 7:10 PM, Bryan Evenson 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; A
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 !
>
> &
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.
On Tue, Mar 18, 2014 at 6:51 PM, Harald Becker 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-
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
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
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 !
>
Hi Mike !
On 18-03-2014 12:52 Mike Dean 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 ... th
Hi Bryan !
On 18-03-2014 18:02 Bryan Evenson 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
> -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
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, to
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
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
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 adju
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
cod
1 - 100 of 112 matches
Mail list logo
