Re: Ntpd config file support
On 20 March 2014 18:47:55 Mike Dean md...@emacinc.com 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 look at how much better it has worked out for them than it has for you. Did it? Are we back to 600kb kernel images by now, uncompressed, like we had some time ago? Sent with AquaMail for Android http://www.aqua-mail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
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. And I suggest to paint it blue. Manuel On Fri, Mar 21, 2014 at 08:52:55AM +0100, Bernhard Reutner-Fischer wrote: On 20 March 2014 18:47:55 Mike Dean md...@emacinc.com 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 look at how much better it has worked out for them than it has for you. Did it? Are we back to 600kb kernel images by now, uncompressed, like we had some time ago? Sent with AquaMail for Android http://www.aqua-mail.com ___ 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
ash Posix standards
Hello everyone, I really would like have a reference for the ash shell provided in the busybox package, reading the README inside the shell/ folder I can see : http://www.opengroup.org/onlinepubs/9699919799/ Open Group Base Specifications Issue 7 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Shell Utilities [..] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [..] Is then ash compliant to those ? Best Regards, Pietro. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: 3 shells (ash, dash, bash), 3 different behaviours
On Thu, 20 Mar 2014, Cristian Ionescu-Idbohrn wrote: On Thu, 20 Mar 2014, Denys Vlasenko wrote: Did you find a real-world script which does depend on previous value of local variable? Please show it. Alright. See attached. Run it with: $ dash /path/to/foo.sh $ bash /path/to/foo.sh $ /path/to/busybox ash /path/to/foo.sh I probabably owe an explanation for the script example attached to the previous message. Variable 'foo' contains the output from a dbus-send command. Function `f' is supposed to return the 'fps' of an mjpeg video stream with a 1920x1080 resolution. Running the script under dash does that for me and so did busybox ash, until recently. What I now have to do is to identify all scripts that do things like: IFS=:$IFS and replace the marked part with verbatim spacetabnewline. And that will keep me busy for a while, with the uncertainty that I didn't locate all such places. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
On Thu, Mar 20, 2014 at 8:15 PM, Mike Dean md...@emacinc.com 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 time. The above statement means that you have some incorrect ideas how Linux virtual memory works. If there's no need for the code, it won't be read back in again. That's how it works already, and was working this way for decades. Pages in file-backed mappings are loaded on access, not when mapping is created. Later, if a loaded unmodified page is dropped due to memory pressure, it will be reloaded only if/when accessed again. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
hwclock: Tracking down uinterruptable sleep error
All,
I'm on busybox-1.20.2 and I am tracking down an issue on hwclock. After my
system is running for a long time, I will see a hwclock process in the process
list that is stuck in an uninterruptable sleep. If that occurs, any command
line calls to hwclock returns:
Can't open '/dev/misc/rtc': No such file or directory
And the command line hangs until I kill it with a CTRL+C. I took a look at the
source code and I see that after opening the rtc dev interface with
rtc_xopen(), hwclock doesn't verify the file opened successfully before trying
to use it. I changed it so that all calls to rtc_xopen() verify the returned
file descriptor is valid before trying to use it. I also enabled
CONFIG_FEATURE_CLEAN_UP on my configuration so that the file descriptor is
closed at the end of the fuction. Now at least if I get the above error
message, the hwclock call exits back on the command line. However, I'm still
getting the uninterruptable sleep on one instance of hwclock. Looking through
the code I don't see an obvious place that could be causing a problem. Anyone
else have any ideas?
Here's the script I'm using to reproduce the problem:
#!/bin/sh
while [ 1 ]; do
/sbin/hwclock -w -u
sleep 1
done
Run two copies of the above script in the background. On my system within
seconds I will get the Can't open '/dev/misc/rtc': No such file or directory'
error popping up in the console and there will be one instance of /sbin/hwclock
-w -u that will be stuck in an uninterruptable sleep and cannot be killed.
If you're interested in my changes so far, below is a copy of my patch on
busybox-1.20.2:
From 0cdf61c5a7b56135e7809c01fea1ebe4fb201a50 Mon Sep 17 00:00:00 2001
From: Bryan Evenson beven...@melinkcorp.com
Date: Fri, 21 Mar 2014 08:43:18 -0400
Subject: [PATCH 1/1] hwclock: Verify RTC file descriptor
If the RTC is in use by another process or if the RTC dev interface
is not properly established, calling rtc_xopen will fail. However,
hwclock does not check the result of rtc_xopen, causing hwclock
to hang indefinitely when it attempts to use the bad file
descriptor. This also prevents future calls to hwclock from
succeeding, thus making it impossible to read or set the RTC until
the system is rebooted.
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
util-linux/hwclock.c |9 +
util-linux/rtcwake.c |4
2 files changed, 13 insertions(+)
diff --git a/util-linux/hwclock.c b/util-linux/hwclock.c
index 379eeb2..f959bc6 100644
--- a/util-linux/hwclock.c
+++ b/util-linux/hwclock.c
@@ -35,6 +35,10 @@ static time_t read_rtc(const char **pp_rtcname, struct
timeval *sys_tv, int utc)
fd = rtc_xopen(pp_rtcname, O_RDONLY);
+ /* Verify we can access the RTC before continuing */
+ if (fd 0)
+ return 0;
+
rtc_read_tm(tm_time, fd);
#if SHOW_HWCLOCK_DIFF
@@ -114,6 +118,11 @@ static void from_sys_clock(const char **pp_rtcname, int
utc)
int rtc;
rtc = rtc_xopen(pp_rtcname, O_WRONLY);
+
+ /* Verify we can access the RTC before continuing */
+ if (rtc 0)
+ return;
+
gettimeofday(tv, NULL);
/* Prepare tm_time */
if (sizeof(time_t) == sizeof(tv.tv_sec)) {
diff --git a/util-linux/rtcwake.c b/util-linux/rtcwake.c
index 735a298..e295885 100644
--- a/util-linux/rtcwake.c
+++ b/util-linux/rtcwake.c
@@ -177,6 +177,10 @@ int rtcwake_main(int argc UNUSED_PARAM, char **argv)
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = rtc_xopen(rtcname, O_RDONLY);
+ /* Verify we can access the RTC before continuing */
+ if (fd 0)
+ return EXIT_FAILURE;
+
if (strcmp(suspend, on) !may_wakeup(rtcname))
bb_error_msg_and_die(%s not enabled for wakeup events,
rtcname);
--
1.7.9.5
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
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 freed eventually). Adding an additional shared lib costs elsewhere and the added code to load it at run-time explicitly too. The Linux kernel's way seems more usefull: Mark init-only functions as such, add linker magic so that that ends up in a separate segment (and thus separate pages which can be evicted on their own) ans it should work with any additional dlopen() Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
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 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 freed eventually). Adding an additional shared lib costs elsewhere and the added code to load it at run-time explicitly too. The Linux kernel's way seems more usefull: Mark init-only functions as such, add linker magic so that that ends up in a separate segment (and thus separate pages which can be evicted on their own) ans it should work with any additional dlopen() Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
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 http://en.wikipedia.org/wiki/KISS_principle . -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
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 http://www.emacinc.com/ Engineer EMAC, Inc. 618-529-4525 Ext. 330 618-457-0110 Fax 2390 EMAC Way Carbondale, Il 62901 On Fri, Mar 21, 2014 at 4:16 PM, Laurent Bercot ska-dietl...@skarnet.orgwrote: 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 http://en.wikipedia.org/wiki/KISS_principle . -- 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
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. Page granularity is large enough that, without grouping like with like, you'd probably end up with other non-init references mixed within the same page(s), resulting in more .text pages remaining resident. Whether or not that was a problem would depend upon your system architecture. (When using direct-mapped NOR flash, for example, you wouldn't care even then. With IDE-accessed flash, or rotating media, or a compressed filesystem, resident text pages would consume valuable RAM.) -- Jim From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On Behalf Of Mike Dean Sent: Friday, March 21, 2014 4:02 PM To: Laurent Bercot Cc: 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.commailto: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 Fri, Mar 21, 2014 at 4:16 PM, Laurent Bercot ska-dietl...@skarnet.orgmailto:ska-dietl...@skarnet.org wrote: 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#goalshttp://busybox.net/FAQ.html#goals and http://busybox.net/FAQ.html#tips_memory , as well as http://en.wikipedia.org/wiki/KISS_principle . -- Laurent ___ busybox mailing list busybox@busybox.netmailto: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 Sat, Mar 22, 2014 at 12:01 AM, Mike Dean md...@emacinc.com 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 keep init code in memory (as in: actual RAM, not virtual memory). ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: Ntpd config file support
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 use an INIT segment, and then have the linker
put all attributed functions (in it) together. I'm assuming
you can bludgeon gcc into labeling functions with a segment.
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: ash Posix standards
On Fri, Mar 21, 2014 at 09:07:27AM +, Pietro Paolini wrote: Hello everyone, I really would like have a reference for the ash shell provided in the busybox package, reading the README inside the shell/ folder I can see : http://www.opengroup.org/onlinepubs/9699919799/ Open Group Base Specifications Issue 7 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Shell Utilities [..] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [..] Is then ash compliant to those ? It's intended to be, as long as CONFIG_ASH_BASH_COMPAT is not selected at build time. Turning on that option alters the shell grammar to be non-conforming to POSIX. In particular, gets interpreted as one token instead of two. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
