[PATCH] mcookie applet
I have this applet lying around in my tree for some time now. Denys, ok for me to install this one? An alternative would of course be to start a multicall shell script, say busybox.sh, installed as /bin/busybox.sh, linked to e.g. /usr/bin/mcookie like: ---8<--- #!/bin/sh # Copyright (c) 2012 Bernhard Reutner-Fischer # Licensed under GPLv2 or later case $0 in *mcookie) dd if=/dev/urandom bs=16 count=1 2>/dev/null | hexdump -e '"%08x"' ;; *) cat <<-EOH BusyBox v1.24.0.git (2015-01-21 19:22:23 CET) multi-call shell script BusyBox is copyrighted by many authors between 1998-2015. Licensed under GPLv2 or later. See source distribution for detailed copyright notices. EOH ;; esac ---8<--- I can whip up the needed infrastructure to host this "applet" and other such helpers that can be implemented ontop of existing C applets if you prefer.. thanks, Bernhard Reutner-Fischer (1): mcookie: new applet include/dump.h | 2 +- libbb/dump.c| 8 +++- miscutils/mcookie.c | 54 + 3 files changed, 62 insertions(+), 2 deletions(-) create mode 100644 miscutils/mcookie.c -- 2.1.4 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia wrote: > Hello Denys, > > El martes, 27 de enero de 2015, Denys Vlasenko > escribió: > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia >> wrote: >> > Hello all, >> > >> > Is there a way to make ntpd work just like ntpdate (just use the first >> > response received to set the time)? This is to set the approximate >> > time at boot as quickly as possible before starting other time sensitive >> > services. >> > >> > The closest I can get is ntpd -nqp but this seems to need >> > 5 valid samples in order to set the time. >> >> Would it work for you if you simply background it >> and let it do its work in parallel with the rest of the boot? > > > Not in this particular case; I don't need time to be extremely accurate but > I need "approximate" time to be set as quickly as possible before starting > other services. That is (was) the typical use case of ntpdate: set the time > quickly to an approximate value, then let ntpd do it's job. I think the best way to achieve this is to implement a sntp applet http://linux.die.net/man/8/sntp It can reuse ntpd's code. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Good idea +1 Le jeu. 29 janv. 2015 11:04, Denys Vlasenko a écrit : > On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia > wrote: > > Hello Denys, > > > > El martes, 27 de enero de 2015, Denys Vlasenko > > > escribió: > > > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > >> wrote: > >> > Hello all, > >> > > >> > Is there a way to make ntpd work just like ntpdate (just use the first > >> > response received to set the time)? This is to set the approximate > >> > time at boot as quickly as possible before starting other time > sensitive > >> > services. > >> > > >> > The closest I can get is ntpd -nqp but this seems to need > >> > 5 valid samples in order to set the time. > >> > >> Would it work for you if you simply background it > >> and let it do its work in parallel with the rest of the boot? > > > > > > Not in this particular case; I don't need time to be extremely accurate > but > > I need "approximate" time to be set as quickly as possible before > starting > > other services. That is (was) the typical use case of ntpdate: set the > time > > quickly to an approximate value, then let ntpd do it's job. > > I think the best way to achieve this is to implement a sntp applet > > http://linux.die.net/man/8/sntp > > It can reuse ntpd's code. > > -- > vda > ___ > 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: ntpdate-like functionality in ntpd
Does this warrant a separate applet? I thought that perhaps a command line option to the existing ntpd applet would be enough -- but I am no expert in this field. Guillermo 2015-01-29 11:03 GMT+01:00 Denys Vlasenko : > On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia > wrote: > > Hello Denys, > > > > El martes, 27 de enero de 2015, Denys Vlasenko > > > escribió: > > > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > >> wrote: > >> > Hello all, > >> > > >> > Is there a way to make ntpd work just like ntpdate (just use the first > >> > response received to set the time)? This is to set the approximate > >> > time at boot as quickly as possible before starting other time > sensitive > >> > services. > >> > > >> > The closest I can get is ntpd -nqp but this seems to need > >> > 5 valid samples in order to set the time. > >> > >> Would it work for you if you simply background it > >> and let it do its work in parallel with the rest of the boot? > > > > > > Not in this particular case; I don't need time to be extremely accurate > but > > I need "approximate" time to be set as quickly as possible before > starting > > other services. That is (was) the typical use case of ntpdate: set the > time > > quickly to an approximate value, then let ntpd do it's job. > > I think the best way to achieve this is to implement a sntp applet > > http://linux.die.net/man/8/sntp > > It can reuse ntpd's code. > > -- > vda > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Thu, Jan 29, 2015 at 11:14 AM, Guillermo Rodriguez Garcia wrote: > Does this warrant a separate applet? > > I thought that perhaps a command line option to the existing ntpd applet > would be enough -- but I am no expert in this field. Having sntp would be more compatible than adding a bbox-specific option to ntpd. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 07:27:18PM +0100, Guillermo Rodriguez Garcia wrote:
> Is there a way to make ntpd work just like ntpdate (just use the first
> response received to set the time)? This is to set the approximate
> time at boot as quickly as possible before starting other time sensitive
> services.
By default, ntpdate actually makes 4 measurements before it sets the
clock, but older versions didn't wait between queries so it appeared
like there was only one. With current versions, which use 2s polling
interval, it takes at least 6 seconds.
> The closest I can get is ntpd -nqp but this seems to need
> 5 valid samples in order to set the time.
It seems it waits for the burst mode to end before it tries to select
a source. I'm not sure that is necessary.
--- a/networking/ntpd.c
+++ b/networking/ntpd.c
@@ -1084,7 +1084,7 @@ select_and_cluster(void)
num_points = 0;
item = G.ntp_peers;
- if (G.initial_poll_complete) while (item != NULL) {
+ while (item != NULL) {
double rd, offset;
p = (peer_t *) item->data;
With this change ntpd -q will set the clock with just two samples,
that's about 1-2 seconds total time.
--
Miroslav Lichvar
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.23.0 FreeBSD build fails: 1 showstopper mempcpy(), 1 sendfile() incompat.
On Wed, Jan 28, 2015 at 10:50 PM, Matthias Andree wrote: >> Matthias, please get current git, uncomment this line, >> and confirm that it builds for you. Let me know the version >> of FreeBSD which needs it (newer ones may grow their own >> mempcpy(), we need to be ready for that). > > That works. > > Additionally: > > 1. You need to add #include to obtain memcpy() in the > replacement, and Ok... > 2. also add -fno-builtin-mempcpy to the compiler flags to quench > -Wshadow warnings that the mempcpy() shadows a GCC built-in. I'm confused. Do you _have_ mempcpy (the gcc-builtin one) provided by your toolchain, or do you NOT have mempcpy? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: control-c
Thanks for the heads up. - Original Message - From: "Ron Yorston" To: m...@grounded.net, busybox@busybox.net Cc: r...@tigress.co.uk Sent: Wednesday, January 28, 2015 2:33:20 AM Subject: Re: control-c "m...@grounded.net" wrote: >I fire up either a cmd or power shell in windows 7. >I start 'busybox bash' and get into a shell. >I run a script then can never kill it unless I close the powershell window. > >How do I kill this process if control-c won't work? Not easily. Signals in Windows are sufficiently different from POSIX that support in the WIN32 port is rudimentary. You could try using ps to find out which processes need to be killed, but they're all called sh.exe, which makes it difficult. Note that the WIN32 port of BusyBox isn't in mainline. This mailing list may not be an appropriate place to discuss it. You can either mail me directly or use the issue tracker on GitHub: https://github.com/rmyorston/busybox-w32 No guarantees, though. Ron ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.23.0 FreeBSD build fails: 1 showstopper mempcpy(), 1 sendfile() incompat.
Am 29.01.2015 um 16:40 schrieb Denys Vlasenko: > On Wed, Jan 28, 2015 at 10:50 PM, Matthias Andree wrote: >>> Matthias, please get current git, uncomment this line, >>> and confirm that it builds for you. Let me know the version >>> of FreeBSD which needs it (newer ones may grow their own >>> mempcpy(), we need to be ready for that). >> >> That works. >> >> Additionally: >> >> 1. You need to add #include to obtain memcpy() in the >> replacement, and > > Ok... > >> 2. also add -fno-builtin-mempcpy to the compiler flags to quench >> -Wshadow warnings that the mempcpy() shadows a GCC built-in. > > I'm confused. > Do you _have_ mempcpy (the gcc-builtin one) provided by your toolchain, > or do you NOT have mempcpy? > Denys, that got me stumped for a moment, too. GCC knows the mempcpy() builtin (depends on the language settings, default -std=gnu90 as of GCC 4.8), but FreeBSD's libc does not offer the mempcpy() implementation (depends on its libc). Now, GCC builtins reserve the right to resort to library callsif there is no optimization gained. Official wording cited below. (Remember that GCC defaults to -std=gnu90 which is why the mempcpy() extension/builtin is visible internally within the compiler, triggering the warning.) So, upon actual code generation, GCC figures the code doesn't benefit from the builtin and emits a regular call to memcpy() instead. I confirmed that by compiling with -save-temps and reading the resulting .s assembly file, by looking at the nm -s output, and it's evident the linker error we were getting. I have not found a way to force GCC to use its builtin and avoid the call. -ffreestanding suggests itself, but is insufficient. Even patching the source to read ... = __builtin_memcpy() causes GCC to emit a call to memcpy. Where it is an adequate substitute, FreeBSD has been providing stpcpy() for over 13 years (since FreeBSD 4.4, released in 2001-09) and all supported FreeBSD releases carry it. It is part of The Open Group Base Specifications since Issue 7. Quoting the GCC 4.8.4 info pages: > 3.4 Options Controlling C Dialect [...] > `-fno-builtin' > `-fno-builtin-FUNCTION' > Don't recognize built-in functions that do not begin with > `__builtin_' as prefix. *Note Other built-in functions provided > by GCC: Other Builtins, for details of the functions affected, > including those which are not built-in functions when `-ansi' or > `-std' options for strict ISO C conformance are used because they > do not have an ISO standard meaning. > > GCC normally generates special code to handle certain built-in > functions more efficiently; for instance, calls to `alloca' may > become single instructions which adjust the stack directly, and > calls to `memcpy' may become inline copy loops. The resulting > code is often both smaller and faster, but since the function > calls no longer appear as such, you cannot set a breakpoint on > those calls, nor can you change the behavior of the functions by > linking with a different library. [...] > With the `-fno-builtin-FUNCTION' option only the built-in function > FUNCTION is disabled. FUNCTION must not begin with `__builtin_'. > If a function is named that is not built-in in this version of > GCC, this option is ignored. [...] > 6.55 Other Built-in Functions Provided by GCC [...] > GCC includes built-in versions of many of the functions in the standard > C library. The versions prefixed with `__builtin_' are always treated > as having the same meaning as the C library function even if you > specify the `-fno-builtin' option. (*note C Dialect Options::) Many of > these functions are only optimized in certain cases; if they are not > optimized in a particular case, a call to the library function is > emitted. > Outside strict ISO C mode (`-ansi', `-std=c90', `-std=c99' or > `-std=c11'), the functions `_exit', `alloca', `bcmp', `bzero', [...] > `jnf', `jnl', `jn', `lgammaf_r', `lgammal_r', `lgamma_r', `mempcpy', [...] > `strcasecmp', `strdup', `strfmon', `strncasecmp', `strndup', `toascii', > `y0f', `y0l', `y0', `y1f', `y1l', `y1', `ynf', `ynl' and `yn' may be > handled as built-in functions. All these functions have corresponding > versions prefixed with `__builtin_', which may be used even in strict > C90 mode. Hope that helps. signature.asc Description: OpenPGP digital signature ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: 1.23.0 FreeBSD build fails: 1 showstopper mempcpy(), 1 sendfile() incompat.
On Thursday 29 January 2015 19:09:33 Matthias Andree wrote:
> Am 29.01.2015 um 16:40 schrieb Denys Vlasenko:
> > On Wed, Jan 28, 2015 at 10:50 PM, Matthias Andree
> > wrote:
> >>> Matthias, please get current git, uncomment this line,
> >>> and confirm that it builds for you. Let me know the version
> >>> of FreeBSD which needs it (newer ones may grow their own
> >>> mempcpy(), we need to be ready for that).
> >>
> >> That works.
> >>
> >> Additionally:
> >>
> >> 1. You need to add #include to obtain memcpy() in the
> >> replacement, and
> >
> > Ok...
> >
> >> 2. also add -fno-builtin-mempcpy to the compiler flags to quench
> >> -Wshadow warnings that the mempcpy() shadows a GCC built-in.
> >
> > I'm confused.
> > Do you _have_ mempcpy (the gcc-builtin one) provided by your toolchain,
> > or do you NOT have mempcpy?
> >
>
> Denys,
>
> that got me stumped for a moment, too. GCC knows the mempcpy() builtin
> (depends on the language settings, default -std=gnu90 as of GCC 4.8),
> but FreeBSD's libc does not offer the mempcpy() implementation (depends
> on its libc).
>
> Now, GCC builtins reserve the right to resort to library callsif there
> is no optimization gained. Official wording cited below.
>
> (Remember that GCC defaults to -std=gnu90 which is why the mempcpy()
> extension/builtin is visible internally within the compiler, triggering
> the warning.)
>
> So, upon actual code generation, GCC figures the code doesn't benefit
> from the builtin and emits a regular call to memcpy() instead. I
> confirmed that by compiling with -save-temps and reading the resulting
> .s assembly file, by looking at the nm -s output, and it's evident the
> linker error we were getting.
>
> I have not found a way to force GCC to use its builtin and avoid the
> call. -ffreestanding suggests itself, but is insufficient. Even
> patching the source to read ... = __builtin_memcpy() causes GCC to emit
> a call to memcpy.
>
>
> Where it is an adequate substitute, FreeBSD has been providing stpcpy()
> for over 13 years (since FreeBSD 4.4, released in 2001-09) and all
> supported FreeBSD releases carry it. It is part of The Open Group Base
> Specifications since Issue 7.
>
>
> Quoting the GCC 4.8.4 info pages:
>
> > 3.4 Options Controlling C Dialect
> [...]
> > `-fno-builtin'
> > `-fno-builtin-FUNCTION'
> > Don't recognize built-in functions that do not begin with
> > `__builtin_' as prefix. *Note Other built-in functions provided
> > by GCC: Other Builtins, for details of the functions affected,
> > including those which are not built-in functions when `-ansi' or
> > `-std' options for strict ISO C conformance are used because they
> > do not have an ISO standard meaning.
> >
> > GCC normally generates special code to handle certain built-in
> > functions more efficiently; for instance, calls to `alloca' may
> > become single instructions which adjust the stack directly, and
> > calls to `memcpy' may become inline copy loops. The resulting
> > code is often both smaller and faster, but since the function
> > calls no longer appear as such, you cannot set a breakpoint on
> > those calls, nor can you change the behavior of the functions by
> > linking with a different library.
> [...]
> > With the `-fno-builtin-FUNCTION' option only the built-in function
> > FUNCTION is disabled. FUNCTION must not begin with `__builtin_'.
> > If a function is named that is not built-in in this version of
> > GCC, this option is ignored.
>
> [...]
>
> > 6.55 Other Built-in Functions Provided by GCC
> [...]
> > GCC includes built-in versions of many of the functions in the standard
> > C library. The versions prefixed with `__builtin_' are always treated
> > as having the same meaning as the C library function even if you
> > specify the `-fno-builtin' option. (*note C Dialect Options::) Many of
> > these functions are only optimized in certain cases; if they are not
> > optimized in a particular case, a call to the library function is
> > emitted.
>
> > Outside strict ISO C mode (`-ansi', `-std=c90', `-std=c99' or
> > `-std=c11'), the functions `_exit', `alloca', `bcmp', `bzero',
> [...]
> > `jnf', `jnl', `jn', `lgammaf_r', `lgammal_r', `lgamma_r', `mempcpy',
> [...]
> > `strcasecmp', `strdup', `strfmon', `strncasecmp', `strndup', `toascii',
> > `y0f', `y0l', `y0', `y1f', `y1l', `y1', `ynf', `ynl' and `yn' may be
> > handled as built-in functions. All these functions have corresponding
> > versions prefixed with `__builtin_', which may be used even in strict
> > C90 mode.
>
> Hope that helps.
>
>
>
Hi,
maybe we could try it the in another way:
use bb_memcpy in the code
and put in libbb.h or another .h file
#ifdef HAVE_MEMPCPY
#define bb_mempcpy mempcpy
#else
void bb_mempcpy(void *dest, const void *src, size_t len)
{
return memcpy(dest, src, len) + len;
}
#endif
just my 0.2 cents.
Ciao,
Tito
busybox-1.23.0-r1 does not set /dev/snd group properly
I've been running Gentoo using busybox-mdev instead of udev on my desktop PC for quite a while. I'm the guy who started up https://wiki.gentoo.org/wiki/Mdev Last night, I ran a system update, mostly to get the latest Adobe Flash security update. Along the way, busybox also got upgraded from 1.23.0 to 1.23.0-r1. Now, it does not set /dev/snd properly [d531][root][~] ll /dev/snd total 0 drwxr-xr-x 2 root root 160 Jan 29 12:12 . drwxr-xr-x 16 root root3400 Jan 29 17:12 .. crw-rw 1 root root 116, 2 Jan 29 12:12 controlC0 crw-rw 1 root root 116, 4 Jan 29 12:12 pcmC0D0c crw-rw 1 root root 116, 3 Jan 29 12:12 pcmC0D0p crw-rw 1 root root 116, 5 Jan 29 12:12 pcmC0D2c crw-rw 1 root root 116, 1 Jan 29 12:12 seq crw-rw 1 root root 116, 33 Jan 29 12:12 timer The result is that a regular user can't play sound at all, unless I manually chown -R the /dev/snd directory to root:audio. busybox 1.23.0 is no longer in the Gentoo tree. I reverted to busybox 1.22.1 and it sets up /dev/snd properly to root:audio. I'm sticking with that version for the time being. The following entries in /etc/mdev.conf did not change between the versions of busybox... # alsa sound devices and audio stuff pcm.* root:audio 660 =snd/ control.* root:audio 660 =snd/ midi.* root:audio 660 =snd/ seq root:audio 660 =snd/ timer root:audio 660 =snd/ Any ideas? -- Walter Dnes ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
