RE: ash: "source " makes ash exit?

[Cathey, Jim]

"source" comes from the C shell.
The Bourne shell (and the Korn shell
successor) did not have it.

Bash was probably the first to suck in
both.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On 
Behalf Of Harald Becker
Sent: Friday, March 15, 2013 5:02 PM
To: Mike Frysinger
Cc: busybox@busybox.net
Subject: Re: ash: "source " makes ash exit?

Hi Mike !

>"source" is not in POSIX and thus is not technically portable.

Not in POSIX? Wow, who removed this? Even old AT&T systems did
understand the "source".

... and just a hint about technically portable:

alias source=.

... and even dash shall understand "source"

--
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: ash: "source " makes ash exit?

[Cathey, Jim]

So if I should type, manually, ". oopsImisspelledIt"
my session is supposed to go away?

Not cool.

-- Jim

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

RE: [PATCH] ping: try SOCK_DGRAM if no root privileges

[Cathey, Jim]

A separate suid-exec relay utility is in fact exactly what
we use on our BB installation in our product, and have
for years.  BB itself is not suid, I/we didn't trust it
enough.  Here it is:

/*
** Relay execution program to setuid-root selected busybox functions.
** (We are expected to be suid-root, busybox is not.)
*/

#include 
#include 
#include 

int
main(int argc, char **argv, char **envp)
{
   int ii;
   char **nargv, *cp;

   for (ii=0; argv[ii]; ii++)
  ;
   nargv = calloc(ii + 2, sizeof *nargv);
   while (ii >= 0) {
  nargv[ii + 1] = argv[ii];
  ii--;
   }
   nargv[0] = "busybox";
   if ((cp = strrchr(argv[0], '/')))
  nargv[1] = cp + 1;

   execve("/bin/busybox", nargv, envp);
   return 1;
}

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On 
Behalf Of Laurent Bercot
Sent: Thursday, January 09, 2014 12:10 PM
To: Denys Vlasenko
Cc: busybox
Subject: Re: [PATCH] ping: try SOCK_DGRAM if no root privileges


> They were order of magnitude more problematic
> when multi-user machines were the norm.

  True enough, but it is still the case, for a good definition of "user".
  Most machines today only have one human user, but there are a lot
of uids and gids used to run daemons with separate privileges. It is
just as likely that an exploitable hole will be found in some daemon
code than in some code directly run under the human user's uid - and
there, a "user" exploit won't be a major problem, whereas a root
exploit will.


> It is not logical anymore to see root exploits as orders of magnitude
> more dangerous than user-level ones, and spend much more efforts
> to prevent specifically these exploits to be used.
>
> If you are afraid that ping may have a bug, spend time auditing ping,
> not making it more ugly just because you can make such bug
> impact "only lowly user".

  I understand what you're saying, and agree with it, but my point is
that my solution:

  * isn't much more effort. I probably spent 5-10 minutes writing the
additional 4 lines of C code. And theoretically, the privileged applet
list could be automatically generated from the Kconfig, to avoid any
additional configuration effort.
  * isn't more ugly. Actually, there's less code in total than with the
busybox setuid-then-drop-privileges thing, and the general case execution
path is shorter.

  It could totally be integrated into busybox itself and benefit everyone.
I just don't have time to work on a patch right now, so I'm just mentioning
the idea around.

-- 
  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: [PATCH] ping: try SOCK_DGRAM if no root privileges

[Cathey, Jim]

This is on a read-only root filesystem that is built the way we want it.
(Squashfs, I believe.)  There aren't any, and can't be, any links to names
we don't wish to give suid permission to.

-- Jim

-Original Message-

Where's the check for what applets are allowed? What stops you from
running wrapper ash?

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

RE: [PATCH] ping: try SOCK_DGRAM if no root privileges

[Cathey, Jim]

Doesn't really do you much good since BB is still doing
its own name checks.

No, it's not perfect.  Making this kind of relay program a real part
of BB, as a user-selectable option probably, would be best.

-- Jim

-Original Message-
From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
Sent: Thursday, January 09, 2014 12:46 PM
To: Cathey, Jim
Cc: Laurent Bercot; Denys Vlasenko; busybox
Subject: Re: [PATCH] ping: try SOCK_DGRAM if no root privileges

>>>>> "Cathey," == Cathey, Jim  writes:

 > This is on a read-only root filesystem that is built the way we want it.
 > (Squashfs, I believe.)  There aren't any, and can't be, any links to names
 > we don't wish to give suid permission to.

And no writable storage anywhere (E.G. a tmpfs for /tmp or similar)
where you can add a handy symlink to the wrapper?

-- 
Bye, Peter Korsgaard
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: [PATCH] ping: try SOCK_DGRAM if no root privileges

[Cathey, Jim]

Oh, and it helps to know that users on this particular system
do not get access to shells.  Or rather, the account shell _is_ our
custom application.  Bash (or ash) is there, but not exposed.
It's used by admin scripts, booting, etc.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On 
Behalf Of Cathey, Jim
Sent: Thursday, January 09, 2014 1:24 PM
To: Peter Korsgaard
Cc: busybox
Subject: RE: [PATCH] ping: try SOCK_DGRAM if no root privileges

Doesn't really do you much good since BB is still doing
its own name checks.

No, it's not perfect.  Making this kind of relay program a real part
of BB, as a user-selectable option probably, would be best.

-- Jim

-Original Message-
From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
Sent: Thursday, January 09, 2014 12:46 PM
To: Cathey, Jim
Cc: Laurent Bercot; Denys Vlasenko; busybox
Subject: Re: [PATCH] ping: try SOCK_DGRAM if no root privileges

>>>>> "Cathey," == Cathey, Jim  writes:

 > This is on a read-only root filesystem that is built the way we want it.
 > (Squashfs, I believe.)  There aren't any, and can't be, any links to names
 > we don't wish to give suid permission to.

And no writable storage anywhere (E.G. a tmpfs for /tmp or similar)
where you can add a handy symlink to the wrapper?

-- 
Bye, Peter Korsgaard
___
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

[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

[Cathey, Jim]

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.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 
mailto: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#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

[Cathey, Jim]

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: /proc//cmdline and udhcpcd

[Cathey, Jim]

This long predates Linux.  Some small
percentage of programs rely upon being
able to modify the argv array.  This
is especially valuable to programs
that fork heavily but that do not exec.
The individual tines may thus be labeled
with their roles so that they can be
identified in ps, for example.  Our big
server process does this.

Handy if you want to, oh, say _debug_
one of them, or even kill it.

Obliteration of sensitive information has
already been mentioned.  There may be
other reasons.

-- Jim

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

RE: wget: progress doesn't work with BusyBox v1.22.1 on flash memory

[Cathey, Jim]

>I'll fix the bug, but why your writes are so slow?

Flash _is_ slow.

>Kernel is supposed to buffer writes to filesystems.

That only works, to a point.  Perhaps write-through
is engages on this _system_, for fitness of purpose
reasons?  The point is, you can't _count_ on buffering
to hide bugs!

-- Jim

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

RE: [PATCH] memset 0 in obscure is optimized away by compiler

[Cathey, Jim]

Generally C compilers assume that an address
passed to a function (free(p)) _might_ be dereferenced,
and so would not optimize away the memset(p,...)

If a particular C compiler thinks it knows what
free() is, and that it doesn't dereference its argument,
then it might think it was justified in doing this.

That's a broken C compiler if you ask me, unless
you _can_ tell it not to make assumptions about what
particularly-named functions do.  (Else cross-compiling,
or developing in/for peculiar environments is impossible.)

A C compiler that _knows_ free() doesn't dereference its
argument _is_ entirely justified in eliminating the
memset.  The tool to tell the C compiler that there
are other factors operating behind the C compiler's
back is "volatile", which basically tells it "you don't
know everything here, so stop screwing around and do exactly
what I say."  It's an overlarge hammer in this case, though.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On 
Behalf Of Denys Vlasenko
Sent: Wednesday, April 16, 2014 10:52 AM
To: Tito
Cc: busybox
Subject: Re: [PATCH] memset 0 in obscure is optimized away by compiler

On Wed, Apr 16, 2014 at 6:47 PM, Tito  wrote:
> Hi,
> while reading some interesting stuff about memset being optimized
> away by compilers if the variable is not read after the memset call
> I recalled there was something similar in libbb/obscure.c file:
>
> static int string_checker(const char *p1, const char *p2)
> {
> int size, i;
> /* check string */
> int ret = string_checker_helper(p1, p2);
> /* make our own copy */
> char *p = xstrdup(p1);
>
> /* reverse string */
> i = size = strlen(p1);
> while (--i >= 0) {
> *p++ = p1[i];
> }
> p -= size; /* restore pointer */
>
> /* check reversed string */
> ret |= string_checker_helper(p, p2);
>
> /* clean up */
> memset(p, 0, size);
>
> free(p);
>
> return ret;
> }

$ make libbb/obscure.s

and I see the memset (inlined by compiler):

cld
xorl%eax, %eax  # tmp76
movl%ebx, %edi  # p.101,
movl%esi, %ecx  # D.7349, D.7349
rep
stosb

Perhaps because compiler doesn't know that free(p) doesn't use
the contents of *p.

>
> -   /* clean up */
> -   memset(p, 0, size);
> +   /* clean up, don't use memset as it is optimized away by compiler */
> +   /*memset(p, 0, size);*/
> +   nuke_str(p);
> free(p);

This may be unnecessary wrt correctness (memset isn't eliminated),
but it is also _fewer bytes of code_!

Applied to git, thanks!
___
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: [PATCH] memset 0 in obscure is optimized away by compiler

[Cathey, Jim]

>  char pwd[64];
>
>  memset(pwd, 0, sizeof(pwd));
>  if (pwd[0] != '\0') {
>   printf("memory not zeroed");

>or would the compiler see that we read just first char
>and zero only that and force us to check every
>char of pwd?

If CC knows what memset does (and I believe they
generally do these days), _none_ of the code above
will be left after optimization.  That's the whole
point of lifetime analysis in a code optimizer.

Source code that is depending upon side-effects is
broken.  If, as in the original case, you are intending
that a free'd buffer be zeroed by application code
as a debugging aid, you _must_ teach the compiler that
it cannot 'know' what free does, else its optimizer is
entirely justified in eliminating the zeroing code.
Either declare (cast?) the buffer as volatile, eliminate
the smarts associated with the free function, or put
the clearing in a separate function outside of the
scope of the C compiler optimizer's reach.

Or, best yet, rebind the free function to one that
clears its buffer before returning it to the pool.
That's what you really wanted anyway.

-- Jim

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

RE: [PATCH] memset 0 in obscure is optimized away by compiler

[Cathey, Jim]

>Even if optimizer throws out the call to memset function the
>compiler shall create code to fill the pwd array before it's
>freed. Otherwise I consider the optimizer behaving wrong.

If the compiler is 'smart' enough to know what memset() does,
what's from preventing it from also knowing what free() does?  If
it proceeds based upon _standard_ definitions of both of these
functions it _is_ justified in eliminating the memset() altogether.

Standard definition of free is: "I will no longer use this memory
buffer for _anything_."  The optimizer can then roll up the code
backwards 'til the point where it decides you last did 'use' it.

Mind you, I don't think I like my compiler being quite that 'smart'.
I would hope there was a knob someplace to tell it not to be quite
so, umm, _free_ with free()!

-- Jim

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

RE: [PATCH] memset 0 in obscure is optimized away by compiler

[Cathey, Jim]

>What do you call observable?

C has a pretty exact definition of this.

>Replacing the content of a memory region by a constant value is
>an observable effect by itself.

No, it's not.  Where did you _get_ the address to observe?
That's the essence of the observability question.

The C compiler knows that globals are observable outside of
the scope it is generating code for.  But auto variables
are not.  Likewise heap variables, if it knows that the scope
of the _address_ (malloc return value) never leaves the building,
so to speak.

Taking your argument to a ridiculous level, should the compiler
be _forbidden_ to keep variables in address-less machine registers
_unless_ you used the register keyword?  It's all the same thing,
really.  Lifetime, scope, and observability: the essential trinity...

(The TI 9900 is the only machine I know of where you would
 be able to take the address of a 'register' variable, for real,
 but the definition of C prohibits this.  Perhaps a C compiler
 for a 6502 could do the same, but only because it doesn't _have_
 any registers so far as C is concerned; that keyword could be
 ignored.)

-- Jim

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

RE: keeping as much persistent log-data as will possibly fit

[Cathey, Jim]

Another issue that is often not thought about by
many embedded developers, is that flash devices
slow down with wear.  Excessive logging to flash
eventually results in a device that might no longer
meet its performance objectives.  The flashes I'm
most familiar with have something like a 20:1 speed
ratio between factory fresh and device death.
That's usually pretty significant.

-- Jim


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

RE: [PATCH] Add coreutils/unlink.c

[Cathey, Jim]

The entire point of unlink, the reason it even
exists, is that it never takes _any_ options.
Anything you feed it is a filename, and it
will delete it.

-- Jim

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

RE: [PATCH] Add coreutils/unlink.c

[Cathey, Jim]

Coreutils was not first.  IMHO, if it takes options
of any sort it is broken.  You only use unlink when
you _don't_ want options.

-- Jim

-Original Message-
From: Denys Vlasenko [mailto:vda.li...@googlemail.com] 
Sent: Monday, June 23, 2014 10:44 AM
To: Cathey, Jim
Cc: busybox@busybox.net
Subject: Re: [PATCH] Add coreutils/unlink.c

On Mon, Jun 23, 2014 at 7:24 PM, Cathey, Jim  wrote:
> The entire point of unlink, the reason it even
> exists, is that it never takes _any_ options.
> Anything you feed it is a filename, and it
> will delete it.

coreutils disagree:

$ unlink --version
unlink (GNU coreutils) 8.17
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Michael Stone.

$ unlink -qwerty
unlink: invalid option -- 'q'
Try 'unlink --help' for more information.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: [PATCH] top: fix parsing of /proc/meminfo

[Cathey, Jim]

>Am I missing something here?  There is no structure, just a character 
>pointer.  If you leave off "static" it will be compiled as an 
>instruction that pushes a constant onto the stack, by any/every compiler.

Which is probably _larger_ code than just referring to something
stored in the .text/.data segment.  It's copying something that is
found in text/data into the stack space, then referring to that
address thereafter.  The compiler has to do:

Copy A->B
Then use &B.

-vs-

Use &A.

You do this when you want the ability to modify B.
If A is fixed and inviolate, you mark it static const
and be done with it.  What this turns into, exactly,
depends upon your compiler, CPU, and ABI, but I can't
think of any case where the extra copy is going to
turn out _better_ than the simpler case.

-- Jim

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

RE: Re: Re: missing format string in applets/usage_pod.c

[Cathey, Jim]

I don't like warnings on perfectly legal C.
Promoting them to errors is even worse.

That said, even with all this crap, provided
that the strings are constant and don't contain
substitutions the compiler has nothing to
complain about.

-- Jim

From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On 
Behalf Of Tanguy Pruvot
Sent: Thursday, August 14, 2014 6:45 AM
To: Laszlo Papp
Cc: wald...@gmx.de; busybox
Subject: Re: Re: Re: missing format string in applets/usage_pod.c

its the same with bionic libc (arm)

printf("test") is ok but not printf(buf) with char buf[] = "test"; printf("%s", 
buf) is ok

2014-08-14 15:29 GMT+02:00 Laszlo Papp mailto:lp...@kde.org>>:
Sorry, the list was left out at some point due to my mistake ... See below.

On Thu, Aug 14, 2014 at 2:28 PM, Laszlo Papp 
mailto:lp...@kde.org>> wrote:
On Thu, Aug 14, 2014 at 2:04 PM, mailto:wald...@gmx.de>> wrote:
Hi Laszlo,

> Cannot reproduce with -Wall -Wpedantic -Wextra.
Did you notice:
applets/usage_pod.c:74:3: error: format not a string literal and no format 
arguments
[-Werror=format-security]
?

Hmm, yes, but I got used to that -Wall -Wpedantic -Wextra would cover the cases 
that need to be checked. I am not sure this option respects the C language 
though.

Anyway, I guess I learnt something new today, thanks. :-)


___
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: [PATCH] taskset: support more than 64 cores

[Cathey, Jim]

>Embedded != consumer electronics.

Indeed.  Our products use Busybox,
and with some of them it's not
impossible to push the per-unit price
into seven figures (USD).  They
are flash-based, not disk-based,
and file space is at a modest premium,
which is why BB is being used to
begin with.

Only eight cores per CPU, though.

-- Jim

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

RE: What's the easiest way to make Busybox keep correct time?

[Cathey, Jim]

I don't know how all this is put together on your
particular system, but I had experience once where
an ill-advised attempt to keep the HW clock in sync
resulted in destruction of the system's EEPROM in
which the time offset and first-order drift correction
factors were kept.  The adjustment was designed, by
the system's authors, to be applied MANUALLY, after
a sufficient amount of time had passed to develop a
good baseline for drift.  By jinking it automatically,
rather often, the 10,000-write-cycle EEPROM was destroyed
in a matter of weeks, as I recall.

Soldering on replacement parts was required to resurrect
the affected systems.

The moral is, don't go messing with stuff if you don't
understand how it works.

I am still running one of these systems in my basement,
it's been running for close to twenty years and without
connection to the internet, and its clock is as spot-on
as one could expect.  (Its cron is running sprinklers and
outdoor lighting, so it's easy to verify the clock by
observation.)  I've adjusted the clock only a handful of
times, it learns and refines the drift every time I
correct it.  Which is not often!

-- Jim

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

RE: What's the easiest way to make Busybox keep correct time?

[Cathey, Jim]

>I would HOPE that flash memory has improved in the past 20 years,

The underlying physics really hasn't.  Some devices are more
robust, but the less expensive ones aren't.  They're a lot bigger,
is all.  You need to KNOW where and what is kept, if you want to
have any confidence in the long-term reliability of your system.

>would you care to share the procedure you have used to
>get the time that accurate?  And do you have to run something at every
>reboot to do the time correction, or is this a "set it once and forget it"
>type of thing?

This is/was part of a proprietary system, but I do know that it
kept track of _when_ a time correction was applied, and how much
was applied, from which it extrapolated the amount of drift the
clock would have at any point.  In practice it worked out very well,
provided you did not try to 'correct' the time too much!  The
main secret is that the HW clock's own time was NEVER changed!
That gave you the long-term baseline from which you could calculate
the inherent drift in the system.  The longer you waited before giving
it a correction, the better the correction was.  Because the HW
time was never changed, a later correction's timebase was not
just from the prior correction, but from time zero.

This corrected HW value was applied to the kernel at startup, which
would also add/withhold a microtick every so often (based on the
calculated drift) in order to apply the correction.

You would only have to change the HW clock's stored base time if there
was a battery change, or something like an ESD event wiped out the
clock itself or the clock crystal was changed out.  But then you'd
have to start the recalibration cycle all over again.

Our NTP was tweaked to work with this system.  In fact, it was the
early NTP implementation that was responsible for destroying the
clock EEPROM hardware.  Faces were red.

-- Jim

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

RE: rm -r fails to delete entire hierarchy when path goes in and out of it

[Cathey, Jim]

Pretty sure 'our' upstream rm (in a prior life) expressly
prohibited -r on starting paths that contained .. members.
Too many weirdo cases where you would get into trouble.

-- Jim

-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Ralf Friedl
Sent: Wednesday, September 17, 2014 2:02 AM
To: Gian Ntzik; busybox@busybox.net
Subject: Re: rm -r fails to delete entire hierarchy when path goes in and out 
of it

Gian Ntzik wrote:
> It seems that using rm -r with a path that goes into the hierarchy
> intended for removal (and back up e.g. using dot-dots) fails to remove
> the entire hierarchy.
>
> For example,
>
> $ mkdir -p /tmp/a/b/c
> $ mkdir -p /tmp/a/e
> $ rm -r /tmp/a/b/../../a
> rm: can't remove 'a/b/../../a/e': No such file or directory
> rm: can't remove 'a/b/../../a': No such file or directory
GNU rm does this:
$ mkdir -p /tmp/a/b/c /tmp/a/e
$ rm -r /tmp/a/b/../../a
rm: cannot remove '/tmp/a/b/../../a': No such file or directory

In general I think it is not a good idea to pass such arguments to rm.

___
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: [PATCH 0/5] Fix ntpd to not poll frequently

[Cathey, Jim]

>Somehow it seemed to its authors
>that "we need several minutes to sync the clock" is resonable.
>It is not. Think about it. If you are setting the mechanical clock
>by looking at another, (presumably) correct clock, how long does it take?
>Few seconds, not minutes.

That depends upon your tolerance for _rate_ changes to the
clock, or even non-monotonic time behavior.  Traditionally, the
clock is 'eased' into place over time, so that _while_ the time
is adjusting things that are _using_ the time aren't disturbed.
25-second minutes could wreak havoc, depending on what you were
doing.

These things generally operate not by yanking the clock around,
but by adding creep factors that operate over time.  If the
creep factor were well-calculated, you wouldn't need to check to
see if you were right all that often.

The implementation I was most familiar with would only do a
clock jump if it was sufficiently 'far' from correct.

-- Jim

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

RE: Accuracy/reliability of "top" CPU usage numbers

[Cathey, Jim]

Things like 'top' have _always_ had issues with processes
that are clock-synchronized.  Very few OS's (and I don't
think Linux is one of them) actually account CPU time
by use of things like the PPC TBR register (for example).
Most do it via statistical sampling in a clock interrupt.

The top-analog we had on our OSE products was _very_ accurate,
because it accumulated CPU consumption via the TBR deltas
on context switches.

-- Jim

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

RE: Accuracy/reliability of "top" CPU usage numbers

[Cathey, Jim]

Again, I'm not speaking as to what Linux does, exactly.
But in general, things that are triggered on clocks and
that _end_ before the next clock interrupt tend to be
unnoticed when statistical sampling is used.  If, for
example, my clock-synchronized task consumes 90% of the
CPU time before the next clock tick, but then finishes
and goes idle, the sampler will never see it, and can
report that the machine is 100% idle, when in fact it
is only 10% idle.

Samplers work pretty well for tasks that run
longer than that.  If the tasks end up synchronized
with the sampler, that's when the lies can creep in.
(But it's not necessarily wrong, either.  The true
answer is: it depends.)

If a task is still running when the sample is taken,
then the accounting is a lot more accurate.

Clock-driven sampling is simple and highly portable,
and has been used in Unix since Day 1.  To use things
like TBR instead is a highly machine-dependent. An OS
like Linux, which is also targeted for machines that
do _not_ have a TBR or equivalent, probably does not
use two or more entirely different implementations
internally.  (But ask an expert.)

Yes, 'idle' is the balance of time.  Idle + used will
add up to 100%.

-- Jim

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

RE: Accuracy/reliability of "top" CPU usage numbers

[Cathey, Jim]

If you can't modify the kernel to collect more accurate
data (like we did with our top-oid in OSE), you have to
get a lot smarter.  Set up some 'offline' processing of
bulk data, NON-clock synchronized, and characterize that.
(i.e. I can process 1000 records/second in a non-clock-synced
loop, therefore each record takes 1msec.  Normal clock-synced
behavior is 1 record per clock invocation.)

Etc.  It's a pain.

-- Jim

-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Grant Edwards
Sent: Friday, November 14, 2014 2:26 PM
To: busybox@busybox.net
Subject: Re: Accuracy/reliability of "top" CPU usage numbers

On 2014-11-14, Grant Edwards  wrote:

> Almost all of the "real" work done on this target is clock
> synchronized, so how does one determine how much CPU is being used
> and by whom?

The short answer is that the values shown by top are almost completely
useless in this scenario.  There isn't anything top can do about it,
since the limitation is in the data gathered by the kernel itself.
What may be surprising (until you think about it for a few seconds),
is that running a single clock-driven app can completely throw off the
values shown for "normal" programs.

A low-priority idle program can be used to determine how much idle CPU
time is available, but determining who is using how much seems to be
limited to watching the idle program output change as you start/stop
programs about which you want info.

-- 
Grant Edwards   grant.b.edwardsYow! Here I am in 53
  at   B.C. and all I want is a
  gmail.comdill pickle!!

___
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: [PATCH] udhcpd: Handle auto_time timeout overflow

[Cathey, Jim]

While 68 years does seem a stretch, who in their right
mind wants to code implicit time-bombs into their stuff?
A vendor wants to be able to say "I'm game if you are."
(I.e., totally NOT a microsoft mentality!  Which is to
say, reboot every few days else it stops working right.)

Handling monobased timer overflow is well understood, and
has been since computing was invented.  If the difference
looks negative (a physical impossibility, so any such is an
arithmetical artifact) you just flip it around and proceed
with the (correct) positive difference.  The only time this
breaks down is if the true timeout interval approaches the
wraparound time.  Very few bits of code will try to schedule
a non-calendrical event 68 years into the future!

-- Jim

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

RE: [PATCH] udhcpd: Handle auto_time timeout overflow

[Cathey, Jim]

>Because we don't expect machines to run for 68 years without reboot.

Certain nameless-but-large customers out in the world, running certain
nameless Linux/busybox-based products, have experienced abject system
failures after longer runtimes.  Two years is one such number.  These
are generally sign-overflow types of bugs.  Kernel bugs, libc bugs,
etc.  Some products are intended to run for years, if not decades,
at a time.

-- Jim

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

RE: ntpdate-like functionality in ntpd

[Cathey, Jim]

>I doubt having the boot process continue with the wrong time would be
>acceptable. File timestamps will be wrong until the background process
>completes. You really want to wait synchronously for an answer.

That, of course, is not the tool-maker's call.  The _system_
designer gets to decide how important early timestamping is.
In some cases I could think of, not at all!  (Pre-pivot on a
ROFS, etc.)

-- Jim

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

RE: [PATCH] udhcpd: Handle auto_time timeout overflow

[Cathey, Jim]

At the bottom, some of C's arithmetical rules
are 'stupid'.  Especially as regards type
promotion.  At least they're well-defined.

Absolutely true in a mathematical sense is that
the difference between two unsigned numbers is
SIGNED!  But that's not what C does.  You can get
around this, easy enough, but you do have to
understand exactly what is going on.  It helps
if you are working on a 2's-complement machine.

Off the cuff, I think this works:

unsigned int a, b;
int delta;
...
delta = (int)a - (int)b;
if (delta < 0) delta = (int)b - (int)a;

-or maybe-

if (delta < 0) delta = -delta;

-- Jim

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

RE: [PATCH] udhcpd: Handle auto_time timeout overflow

[Cathey, Jim]

Because mathematically, differences are always signed!

2 - 1 ==  1
1 - 2 == -1

Doesn't matter what the size, or sign-ability of the LHS
operands are.  C, however, absolutely stinks at mathematical
relations that change the nature of the calculation.  Precision
changing (like integer multiplication and division), sign invention
(like subtraction), etc.

You can work with it, but you must understand what is going on.

-- Jim

From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Guillermo 
Rodriguez Garcia
Sent: Tuesday, January 27, 2015 2:10 PM
To: Tim Hentenaar
Cc: busybox; Rich Felker
Subject: Re: [PATCH] udhcpd: Handle auto_time timeout overflow

El martes, 27 de enero de 2015, Tim Hentenaar 
mailto:t...@hentenaar.com>> escribió:
Perhaps it wrongly assumes that since the operands for the subtraction
are 32-bit unsigned integers, that the result will be also unsigned.

Uhm, why would that be a wrong assumption ?

Guillermo


--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: [PATCH] udhcpd: Handle auto_time timeout overflow

[Cathey, Jim]

Oh, and carry bits.  Addition/subtraction are also precision-changing!

-- Jim

From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Cathey, Jim
Sent: Tuesday, January 27, 2015 2:19 PM
To: Guillermo Rodriguez Garcia; Tim Hentenaar
Cc: busybox; Rich Felker
Subject: RE: [PATCH] udhcpd: Handle auto_time timeout overflow

Because mathematically, differences are always signed!

2 - 1 ==  1
1 - 2 == -1

Doesn't matter what the size, or sign-ability of the LHS
operands are.  C, however, absolutely stinks at mathematical
relations that change the nature of the calculation.  Precision
changing (like integer multiplication and division), sign invention
(like subtraction), etc.

You can work with it, but you must understand what is going on.

-- Jim

From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Guillermo 
Rodriguez Garcia
Sent: Tuesday, January 27, 2015 2:10 PM
To: Tim Hentenaar
Cc: busybox; Rich Felker
Subject: Re: [PATCH] udhcpd: Handle auto_time timeout overflow

El martes, 27 de enero de 2015, Tim Hentenaar 
mailto:t...@hentenaar.com>> escribió:
Perhaps it wrongly assumes that since the operands for the subtraction
are 32-bit unsigned integers, that the result will be also unsigned.

Uhm, why would that be a wrong assumption ?

Guillermo


--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com<mailto:guille.rodrig...@gmail.com>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: RFD: Rework/extending functionality of mdev

[Cathey, Jim]

>Stream-writes [pipe] are not atomic, and your message can theoretically get
>cut in half and interleaved with another process writing the same fifo.

Any pipe, whether named or not, IS atomic so long as the datagrams
in question are smaller than PIPE_BUF in size.  This has been true
since Day 1, in every Unix worthy of the name.  You have to be
careful on the reads, though: you need to embed the size of the
datagram into itself so that you can be sure you don't get them
packed together.  If the datagrams are of fixed size, then
you don't even need this.

Most of the pipes I use this way have a datagram whose first
field is the size.  Atomic write(2) of each datagram into
the pipe.  The reader does a read(2) of the size field, followed
by a read sized to get the rest of the datagram.  No muss,
no fuss, and pretty darned fast, too.  And it works _everywhere_,
on every Unix/Linux/whateverix version known to Man.

-- Jim

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

RE: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

[Cathey, Jim]

>For this case I generally cast the param to the biggest possible type.
>printf("llu", (uint64_t) val);

That's nearly as parochial as what you are changing from.  C doesn't
have a printf-name to _size_ mapping.  What if my C compiler has a
128-bit scalar type, and _that_ is long-long?  The best thing you should
do is use names, no sizes:

printf("%llu", (unsigned long long) val);

_That_ had better match!

-- Jim


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

RE: How to compare two floats?

[Cathey, Jim]

Unless you need the enhance dynamic range abilities of
floating point, you shouldn't be using it at all.  That's
just a general principle.  Devcie temperatures are well
handled by fixed-point (integer) routines.

-- Jim

-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of bifferos
Sent: Sunday, May 24, 2015 4:05 AM
To: Lauri Kasanen; busybox@busybox.net
Subject: Re: How to compare two floats?

Thanks for all the responses to this, it's given me some ideas.


regards,
Biff.

>
> From: Lauri Kasanen 
>To: busybox@busybox.net 
>Sent: Sunday, 24 May 2015, 8:40
>Subject: Re: How to compare two floats?
> 
>
>> On Saturday 23 May 2015 21:41:51 bifferos wrote:
>> > I'm trying to write a thermostat using busybox shell, however the only way 
>> > I
>> > could think to compare two float temperatures (without adding awk) was to
>> > multiply them up in dc and then compare as integers. In the end I modified
>> > dc to add a comparison operator, which probably breaks the spirit of dc
>> > somewhat.  I'm interested if I missed a trick somewhere.  Is there another
>> > way to do this?  Is this considered a heinous thing to do to dc?
>
>a - b
>
>Then you check if the sign is negative, using the shell's string ops.
>
>- Lauri
>
>-- 
>http://www.fastmail.com - Access all of your messages and folders
>  wherever you are
>
>
>
>
>
>___
>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

Bug in find -xdev

[Cathey, Jim]

I believe the implementation of find -xdev is incorrect
(in BB V1.19.4 tested on a MIPS), in that it is doing the
device crossing exclusion incorrectly.

The short description is that some files can get processed
more than once.  We are using find to make a file tree map,
for debugging purposes, and we don't want it to process
some devices.  (Especially /proc and /sys virtual FS's.)
Simplified, our system has a read-only root filesystem,
with /tmp mounted as a ramdisk.  We run:

find / /tmp -xdev >/tmp/ftw.txt

The purpose of this is to see all 'normal' space-consuming
files in the system, so that extraneous files may be detected.
(This is a forensic tool, part of a much larger state capture
system.  Our find invocation is actually quite a bit more
elaborate than this, as is the filesystem map, but this
simplified version illustrates the point.)

Using upstream gnu findutils find, this works perfectly.
Using BB find, we get the files in /tmp _twice_!

The reason is the way BB find implements xdev.  Upstream xdev,
IIRC, does what one would expect: if it finds a directory with
a _different_ st_dev field than its parent, and -xdev is on,
it does not recurse down it.  BB find, instead, makes a list
of the st_devs of the start-points given it, and any st_dev
on that list is A-OK with it whenever it finds it, else it
skips the directory.

That fails, because it's not unusual for multiple starting
points in -xdev world to be mounted on each other in some
fashion.  If so, they'll get processed twice: once because
it was told to start there, and once when it finds that
mount point elsewhere.

-- Jim

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

RE: Bug in find -xdev

[Cathey, Jim]

I am not set up to do so, but I have examined the sources
in 1.24 (current?) and the -xdev handling code is unchanged
from what I am testing.

-- Jim

-Original Message-
From: Bastian Bittorf [mailto:bitt...@bluebottle.com] 
Sent: Tuesday, December 01, 2015 11:45 AM
To: Cathey, Jim
Cc: busybox@busybox.net
Subject: Re: Bug in find -xdev

* Cathey, Jim  [01.12.2015 20:13]:
> (in BB V1.19.4 tested on a MIPS), in that it is doing the

this version is nearly 4 years old. please test if
this still is the case with current git or stable.

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

RE: cron usage

[Cathey, Jim]

> Is anyone is this list anymore?

No.  :-)

-- Jim

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

RE: why are init's arguments wiped ?

[Cathey, Jim]

Some history, as I recall it:

Unix hard-coded "init" as PID 1, and (I believe) hard-coded the
initial search path to "/bin" and "/usr/bin".

Unix didn't pass any command-line arguments _to_ init, because
there was no environment from which they could come.  Most especially,
the concept of run-level is an init concept, not a kernel concept, and it
got it only from the inittab file, and not from the kernel in any way.

Linux only supports command-line arguments because _uboot_ (et al.) does,
and between the two of them they conspire to have arguments that are
meaningful to the kernel.  Which, as part of that, chooses to be able to
pass some of them off to init.  This is all new behavior, when compared
to Unix and several of its successors.

So, traditionally there weren't any command-line arguments to init,
and it certainly didn't rely upon them.  I do not know who decided that
(probably for compatibility) this newer system should mimic the
appearance of the older, but there it is nonetheless.

There are numerous reasons for a program to choose to mangle its own
command-line arguments, given that "ps" has always been able to
show them to you.  Some reasons:

1) Fork faces.  Forks without exec would be indistinguishable from each other,
   if not for this.

2) Security.  What if sensitive information had been passed on the command-line?
   Hide it.

3) Advertisement.  Cheesy way to make known things discovered at runtime.

-- Jim

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

RE: Implement "dG" in vi

[Cathey, Jim]

So what's wrong with:

.,$d

-- Jim

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

RE: why are init's arguments wiped ?

[Cathey, Jim]

>of course, when you say 1992, that is still "new" compared to
>UNIX systems that existed at the time.

Indeed.  Unix/init had been running for about 20 years by that time.

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

RE: [PATCH] Compress common substrings in applet names to save space

[Cathey, Jim]

>Collisions are impossible: hash is chosen at compile time
>so that all applet names hash to unique integers. All defined applets
>will always work correctly, without aliasing.

But there's another potential collision source: the searching
for a randomly-typed string for a match.  That's the "rwok" case.
Without an explicit match test, usually the final stage of
a hash-index search, you can get a false hit.  Unless you are
using something like MD5 where any hash failure is extraordinarily
unlikely.

-- Jim

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

RE: [PATCH] getrandom: new applet

[Cathey, Jim]

>I have a personal grudge against blocking system calls.

As do I, they're evil, evil, evil if you're trying to
write anything more involved/interactive than a pipeline
component.

-- Jim

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

RE: More insane patch behavior.

[Cathey, Jim]

>busybox used to modify the arguments that showed in ps, but I 
>suppose it went out of its way to do so at the time.
>(I just did a quick test program and writing to argv[0] didn't do it.

We're doing this.  You don't overwrite argv[0], you overwrite
*argv[0] and its neighbors!  (Don't go too far!)

-- Jim

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

RE: shell 'trap' woodoo :)

[Cathey, Jim]

> Oh, I missed this: hitting C-c while 'sleep 5' executes will not interrupt
> the sleep (ash and hush).  Seems C-c is ignored.  Both SIGINT and SIGTERM
> are ignored.

We found this recently, where BB login (?) was turning off SIGINT, and where
bash deliberately preserves this setting 'forever'.  The symptom was that
^C would not interrupt a sleep.  No amount of trap settings, options, etc.,
would affect this.  There were no workarounds, you HAD to get that signal
turned back on before executing the login bash.

-- Jim

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

RE: [PATCH] Avoid side effects in putc(), which may be implementedas a macro

[Cathey, Jim]

This is specifically mentioned in K&R, it's been around
a LONG time.  The macro putc (et al.) are not safe to
use with arguments that have side-effects, because of
the nature of the implementation of such a macro.
Nothing new here, nothing Linux-special either.

You could blame the authors of libc, I suppose, for
violating the then-convention that all macros be in
uppercase so that one knew they needed special attention.

Probably what really happened is that there was a libc
function that was a bottleneck, and so they macro-ized
it for speed, and kept the old spelling so that they wouldn't
have to go through the massive pain of changing all ten (?)
programs that called it.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Ralf Friedl
Sent: Wednesday, September 15, 2010 9:06 AM
To: busybox@busybox.net
Subject: Re: [PATCH] Avoid side effects in putc(), which may be
implementedas a macro

Dan Fandrich wrote
> On Wed, Sep 15, 2010 at 12:01:00PM +0200, Alessandro Rubini wrote:
>   
>> But putchar and fwrite cannot evaluate the arguments more than once.
>> So the patch is fine for putc (the part I don't quote here), but
>> is wrong (i.e., unneeded) for the two hunks above.
>> 
>
> OpenWatcom for one, defines putchar() as a macro in some
configurations,
> so there, at at least, it's not wrong. I changed the fwrite() loop
only
> for consistency with the putc() loop immediately below.
>   
The Linux man-page says:

   putc() is equivalent to fputc() except that it may be implemented

as a macro which evaluates stream more than once.

   putchar(c); is equivalent to putc(c,stdout).

There is no mention of c being evaluated more then once, but that may be

part of the Linux implementation.

Ralf Friedl
___
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: Question about symlinking to busybox

[Cathey, Jim]

Why not just use hardlinks then?
You can replace your binary by...
replacing your binary.

-- Jim



-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Harald Becker
Sent: Thursday, September 16, 2010 8:46 AM
To: busybox@busybox.net
Subject: Question about symlinking to busybox


 Hi!

On installation busybox creates either hardlinks for every applet or a
separate symlink for each applet, which means you you use around 200
symlinks = inodes for this. Why don't you create a single symlink
pointing to the absolute path of busybox and do hardlinks to the symlink
for the remaining applets? Would be fine if busybox could install it in
this way. You get the advantage of both types of linking. Flexibility
(you can just replace your binary without reinstalling links) and space
saving on filesystem (needs just 2 inodes, one for the binary and one
for the symlink).

Comments?

--
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: Build doesn't fail if od not installed

[Cathey, Jim]

I guess that it puzzles me that the build _completes_, yet
builds a bad executable if od is missing.  That just seems
wrong.  Myself, I'd expect the build to just fail in the middle
somehow, like make would.  I wouldn't expect it to hold your
hand any more than that.

-- Jim

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

RE: [PATCH] xmkstemp: safe mkstemp (-65 bytes)

[Cathey, Jim]

>Do you think it makes sense to extend the xmkstemp() to take flags for
>that, or make it another function or do that in place in those
>applets that need it?

I think that manipulation of umask in general should be done
at the application level.  That is, it's inappropriate for
service subroutines to be mucking with that at all, especially
if there's any chance they'll be used in a multithreaded app!

There _is_ already an appropriate function:  umask(2).

In general apps themselves don't usually manipulate umask
much, because the _system_ often has restrictions related
to its security policy.  (Our system, for example, has umask
generally set to 002 rather than the more customary 022.)

-- Jim




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

RE: BB growth and shrinkage; musings

[Cathey, Jim]

>perfection is achieved not when there's nothing more
>to add but nothing more to take away...

Linux/BB gets heavier and heavier, and it's not really
BB's fault.  I blame the tools/environment.  :-)

I did a quick peek, and the old DNIX system I used to
spend all my time on was pretty lean.  (SVR2 work-alike.)
Here are some of the /bin entries:

  dr-xr-xr-x   2 jcathey  root0 Dec 26  1997 .
  drwxrwxrwx   2 jcathey  root0 Dec 31  1969 ..
  -r--r--r--   1 jcathey  root  892 Oct  3  1993 basename
  -r--r--r--   1 jcathey  root 9560 Mar 31  1994 cat
  -r--r--r--   1 jcathey  root13116 Jul  3  1995 chany
  -r--r--r--   1 jcathey  root13116 Jul  3  1995 chgrp
  -r--r--r--   1 jcathey  root13116 Jul  3  1995 chmod
  -r--r--r--   1 jcathey  root13116 Jul  3  1995 chown
  -r--r--r--   1 jcathey  root 9472 Sep 13  1995 cmp
  -r--r--r--   1 jcathey  root 8452 Nov  2  1995 cp
  -r--r--r--   1 jcathey  root17640 Mar  7  1996 date
  -r--r--r--   1 jcathey  root10716 Jun 19  1996 dd
  -r--r--r--   1 jcathey  root 9584 Nov 19  1993 df
  -r--r--r--   1 jcathey  root  892 Oct  3  1993 dirname
  -r--r--r--   1 jcathey  root14152 Mar  9  1995 du
  -r--r--r--   1 jcathey  root 6092 Oct  6  1993 env
  -r--r--r--   1 jcathey  root 6600 Apr 12  1996 hd
  -r--r--r--   1 jcathey  root 6528 Mar  9  1995 head
  -r--r--r--   1 jcathey  root 2616 Aug  2  1994 kill
  -r--r--r--   1 jcathey  root 8452 Nov  2  1995 ln
  -r--r--r--   1 jcathey  root30700 Jan  1  1996 ls
  -r--r--r--   1 jcathey  root 4384 Oct  1  1993 mkdir
  -r--r--r--   1 jcathey  root 8452 Nov  2  1995 mv
  -r--r--r--   1 jcathey  root 2664 Apr 13  1994 nice
  -r--r--r--   1 jcathey  root 1768 Jul  8  1996 nkill
  -r--r--r--   1 jcathey  root18908 Mar 23  1996 ps
  -r--r--r--   1 jcathey  root 6428 Mar  9  1995 pwd
  -r--r--r--   1 jcathey  root 3460 Mar 19  1996 renice
  -r--r--r--   1 jcathey  root 6924 Jul  3  1995 rm
  -r--r--r--   1 jcathey  root 4204 Oct  2  1993 rmdir
  -r--r--r--   1 jcathey  root  988 Dec  2  1993 sleep
  -r--r--r--   1 jcathey  root 5040 Apr 20  1994 sum
  -r--r--r--   1 jcathey  root  788 May 26  1995 sync
  -r--r--r--   1 jcathey  root 8760 Sep 20  1994 tail
  -r--r--r--   1 jcathey  root 3856 Jan 26  1995 tee
  -r--r--r--   1 jcathey  root11228 Mar  9  1995 time
  -r--r--r--   1 jcathey  root 6236 Sep  1  1993 tty
  -r--r--r--   1 jcathey  root 5596 Sep 28  1995 uname
  -r--r--r--   1 jcathey  root 5040 Apr 20  1994 wc

The hard links (like the cp/ln/mv triad and ch* quartet)
don't appear right because this was extracted from a CD,
not a live system.  Likewise the permissions and ownership
are wrong.

I bring this up because this system was also the target of
an extensive squeezing effort, but rather than the swiss army
knife approach of BB I spent effort on eliminating unnecessary
code.  (There was a lower barrier to entry this way.)  Chiefly
this meant getting rid of printf where it wasn't really necessary.

This system was 68K-based, with a non-shared highly granular
libc.  (Original Unix in structure, in other words.)  Removing
printf in this world got rid of the buffered I/O library, and
the floating point library, neither of which are of any real
use for something like sync, say.  What was left was usually
interestingly small.  The tools themselves were not really
'stripper' versions of larger tools, like BB vs Gnu now,
but they did tend to be on the lean and mean side, feature-wise.
(The full development system had less resources than the usual
embedded 'toaster' now.  My, how things have changed!)

The drive for this was to get a 1.44MB rescue floppy that had
a pretty full toolset as well as a full kernel on it, and that
project was quite successful.

I wonder how a BB would fare against this other approach,
in that environment.  In this one, too, except that as
shared glibc is nigh impossible to ditch it really skews things.
The more I use shared libraries the less I like 'em.  This
system had two: a graphics imaging library and a WAN link
data compressor.  They were trials in that sort of line, at
a time when everyone was experimenting with them, and weren't
entirely successful in that they really didn't buy much.
(Typically only one client program each used them.)  Fortunately
the runtime overhead was very lightweight, unlike now.

In that environment I think a hybrid approach of the existing
shrunk utilities, combined with a BB for all the ones that
_did_ need printf et al., would probably yield the best overall
shrinkage.  It's hard to see how utilities that mostly only
use libc(2) can benefit a great deal from a commune executable.

Well, my ramble is over.  I just enjoy thinking about different
ways to do things.

-- Jim

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

RE: Should BusyBox and uClibc also make a "flag version" likeEmbedded Linux?

[Cathey, Jim]

>My fear is that often the reason for using very outdated
>version of busybox is different: it's simply lack of
>time/resources to migrate.

Mixed with a healthy serving of "if it ain't broke,
don't fix it".  Usually the charter of the target is
not "deploy BB to the customer base", it's "deploy a
toaster to the customer base".  The fact that BB is
helpful in some way towards making toast is nice, and
that's why it's there, but evolution of BB isn't usually
necessary for the cooking of bread.  A stable product
doesn't usually welcome gratuitous updates.

It's when BB can be blamed for burnt toast that the
'lid comes off the box', and then one may reasonably
consider updating.  But if BB v20 is notably bigger
than BB v2, as configured, that could be a problem.
Especially if the toaster were quite resource-constrained.
And spending more ROM bytes on infrastructure like BB is
usually much less attractive than spending them on direct
features.

'Stale' software is a fact of life in embedded world.
We prefer to pronounce it 'stable', however!

-- Jim

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

RE: BB growth and shrinkage; musings

[Cathey, Jim]

>Getting rid of printf means avoiding bb_error_msg().
>Which is everywhere. Currently, even in xmalloc.

It would not be useful to do this in BB, even in
that other world, because the whole purpose of BB
is to _share_ the bulkier junk.  If you amortize
all of printf over a dozen applets, all of which
make significant use of it, then you've made a worthy
trade.

>Open-coding it without printf will quickly make code bigger
>and harder to understand.

Most of these tiny apps had a myprintf() function that
I wrote, which took care of %d %s and %c.  Nothing more,
nor was anything more needed for most of these small apps.
They only wanted to print an error-type message anyway,
then exit.

>That is one reason why things get bloated: programs
>tend to fill all available storage. IIRC it's one of Murphy laws.

Sure is, and helps ensure that there _are_ no more tiny
bits of hardware.  If there are no tools or infrastructure
available to support a watch-battery-powered dingus, who's
going to bother to develop one if they have to roll it _all_
from scratch?

>Your files total to 243284 bytes (counting hardlinks
>only once), and have 37 executables.

It was a 30-second extraction from /bin, showing some of the
more common ones, as well as the tiniest.  Some of them, like
ps, time, and ls, did _not_ get the treatment, and are in their
bloaty size.  That skews things a bit.  This project was motivated
by the desire to have a usable boot/rescue floppy.  Fixed in size,
the only way to get more onto it was to shrink things.  Every time
I wanted a new tool on the floppy I went byte-hunting.  I almost
always targeted the easiest ones first.  (Sync was an early one!)
Hard stuff, like ls, I never did get to.

(I did a few other things like invoking a 512-byte block size
on the floppy, and re-coding device files to not use more than
the inode. [don't ask!]  All these files are stripped, they have
no symbol tables nor relocation entries.  They're static, they
don't need any of that stuff.  Load, and jump.  That's exec!
Small, small, small... it was actually a lot of fun.)

All that's readily available to me is the archive CD, so I can't
show a find/ls from the boot floppy itself.  It would probably take
me days to resurrect the system itself, though it is in theory
still possible.

>I built busybox with 34 applets from that list
>(I don't know what are chany, hd, and nkill).

Chany was a micro-BB of chown/chmod/chgrp done by one of the guys.
hd is a hex-od, modeled after the Xenix tool of that name.  Nkill
(named kill) seems to be called 'killall' these days.

It should be noted that all of these _were_ the 'upstream'
versions, for us.  They weren't strippers in any sense, though
in functionality they probably lay between BB and GNU somewhere.

># size busybox.shared busybox.static (w/ulibc)
>   text   data bss dec hex filename
>  55692   13948416   65502ffde busybox.shared
>  65477   15748440   75491   126e3 busybox.static

Those are some pretty interesting numbers!  The 10k difference
for a static libc may well be compensated for by other means.
Such as, removing entirely the dynamic linker from the 'rescue
floppy', the shared libc itself, etc.  The extra linkage pages
required for a shared lib also factor into there, depending on
what you're going for, when making a decision.

If I'd thought of, or heard of, Busybox back then it might have
caught my interest enough to try rolling it myself to see if I
could save some space.  I'd probably have called it 'vicky'.
(Short for Victorinox.)

-- Jim

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

RE: [PATCH] gen_build_files.sh: rewrite with sed

[Cathey, Jim]

>> well, this is a convention mostly destroyed by LookOut.
>I have no idea what "LookOut" is ...

One of the many pejorative nicknames for a certain
Microsoft product of questionable quality.  Another
notable one (my favorite) being "Outhouse".

-- Jim




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

RE: manipulating/testing file times.

[Cathey, Jim]

>Possibly a bad place to ask, but I'm trying to do stuff in busybox/ash
>which involves time delays, or rather "alarms".
>I could do it with lots of little processes just sitting there going
>"sleep 34600", but it isn't very elegant.

Pity that BB cron doesn't seem to support "at" jobs.  It combines
the entire system's array of "little sleeps" into one.

Your approach sounds like polling.  How often do you wake
something up to stat your file?  I hate polling.

Maybe your system should deploy a more full-featured cron?

-- Jim

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

RE: manipulating/testing file times.

[Cathey, Jim]

>m that would be nice - though it's still useful during debugging to
>be able to peer at the file times - if I used "job at" I haven't looked
>into how to get a list of future 'pending events'.

On the systems I used (SVR2-4) it was via "atq".  I think there were
also options to "at" itself that would tell you what was scheduled.
You could also dig it out of the files that cron left for itself in
case of a system reboot.  (The at jobs _would_ be executed, but late
if the system were not actually running at the scheduled time.  The
periodic cron jobs would be skipped unless the system were running at
the scheduled time.)

>I hate polling too, but I feel the need to run shepherd and watchdog
>functions, and that is inherently a sort of polling.

It is.  The trick is to be able to combine everything down to _one_
poll, and to keep that small.  For example, relying on an underlying
X.25 transport's keepalive function to notify you when a connection
goes down, which gets propagated via read/write failure to _all_ clients
using the transport, rather than burdening each and every user of the
transport with its own heartbeat, as we had to do once when we moved a
product from X.25 to IP WAN transports.  (Bitter?  Not I!)

Minimize the polling to the absolute minimum, and convert everything
else to event-driven.  That's the secret to efficiency.

The worst crons I've seen wake up every second and run their control
file to see if there's anything to do.  The best ones (and the original
Unix one) calculate a delay list from the control file, and go to sleep
until the next scheduled event.

-- Jim

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

RE: manipulating/testing file times.

[Cathey, Jim]

>We have a hardware watchdog, but at present it is tickled simply by a
>single simple process...

Badness, as you suspect.  Rearrange to periodically survey
your system's health at the highest possible level and use
that status to kick the dog.  Then if anything fails it'll
go down and restart.  Naturally you don't factor into the
dog-kicking decision anything for which a reboot is _not_
the correct action!

-- Jim

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

RE: sendmail

[Cathey, Jim]

"sendmail for dummies", isn't that postfix?  :-)

-- Jim

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

RE: Why does login need to be suid by root to work?

[Cathey, Jim]

>When I make the busybox executable setuid by root, login is accesible
>by non-root users. However, I don't understand the need for this? Why
>is login being required to get root permissions. It isn't this way on
>typical linux installs.

Because "typical Linux installs" are wrong!  login is very old,
predating Linux by all the time there is.  You used to be able to
"login", and choose who you were going to be.  Or "login "
and give it the user's password when prompted.  Only way for
that to happen is if login itself is running privileged.  For
normal box access methods (telnet, ssh, getty) the parent of
login was already privileged, so login doesn't need to be suid,
and so the installation error isn't easily noticed.  People usually
use "su" instead.  But if you want interactive (re-)login to work,
it has to be suid root.

-- Jim




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

RE: Was Re: Ping - pstree + minor patch

[Cathey, Jim]

> > > - } else if (*here >= ' ' && *here <= '~') {
> > > + } else if (*here >= ' ' && *here < 0x7f) {
> > > 
> > > This makes it less readable. Why replace the char with a hex 
> > value?
> > 
> > It is less obvious that '~' is the last ASCII character.

IMHO, it is equally un-obvious that ' ' is the _first_ ASCII
character, of the printables.  If one wants to go all pedantic
on the code, isprint() might be better.  But I would probably
have left it as the original author had, as a quoted character.

-- Jim

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

RE: Can I rely absolutely on what happens when a process dies.

[Cathey, Jim]

> I enabled the "write your pid to this file" option... but of course
the
> file persists after the process dies... so if you look in the file for
a
> pid... and some other process has started up in the meantime with the
> SAME pid, you will send your signal to the wrong flipping process.

The whole PID-in-a-file thing was designed back in a day when it might
have taken _days_ for a PID to get reused.  Pretty safe.  The faster
systems get, which encourages process churn exacerbating the problem,
the worse the problem gets.

-- Jim

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

RE: call halt/reboot as user

[Cathey, Jim]

>There is just one open question: What is the disadvantage or
>side-effect of setting busybox to be setuid.

Our appliance needed this stuff too, and rather than scrub
through busybox to see if making it suid was sufficiently
'safe', we just wrote a wrapper program that was itself
suid, and that chained in BB.  This program is what is
linked into the filesystem as su, login, ping, traceroute,
etc.  We called it suidexec.c, and it looks something like:

int
main(int argc, char **argv, char **envp)
{
   int ii;
   char **nargv, *cp;

   nargv = calloc((ii=argc) + 2, sizeof *nargv);
   while (ii >= 0) {
  nargv[ii + 1] = argv[ii];
  ii--;
   }
   nargv[0] = "busybox";
   if ((cp = strrchr(argv[0], '/')))
  nargv[1] = cp + 1;

   execve("/bin/busybox", nargv, envp);
   return 1;
}

-- Jim

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

RE: something to warry about...

[Cathey, Jim]

networking/ifplugd.c: In function 'detect_link_priv':
networking/ifplugd.c:163: warning: dereferencing pointer 'mii' does
break strict-aliasing rules
networking/ifplugd.c:155: note: initialized from here

Here's the code:

static smallint detect_link_priv(void)
{
struct ifreq ifreq;
struct mii_ioctl_data *mii = (void *)&ifreq.ifr_data;  <==
LINE 155

set_ifreq_to_ifname(&ifreq);

if (network_ioctl(SIOCDEVPRIVATE, &ifreq, "SIOCDEVPRIVATE") < 0)
{
return IFSTATUS_ERR;
}

mii->reg_num = 1; <= LINE 163

if (network_ioctl(SIOCDEVPRIVATE+1, &ifreq, "SIOCDEVPRIVATE+1")
< 0) {
return IFSTATUS_ERR;
}

return (mii->val_out & 0x0004) ? IFSTATUS_UP : IFSTATUS_DOWN;
}

As given, "mii" isn't actually used for much.  Why not
eliminate it and use "ifreq." instead of "mii->" everywhere?

-- Jim

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

RE: svlogd - can I prove it's reading the config file?

[Cathey, Jim]

>fascinating - so the rubbish in the man pages about allowing
>comment and blank lines is horse-poop!

Small ones!

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdout has beentransmitted

[Cathey, Jim]

>> +/* Wait up to 5 seconds for the output buffer to drain */
>> +signal(SIGALRM, record_signo);
>> +alarm(5);
>> +tcdrain(STDIN_FILENO);
>> +alarm(0);
>> +signal(SIGALRM, SIG_DFL);

>How does this work? Normally plain signal sets SA_RESTART and won't be
>interrupting. You need sigaction without SA_RESTART, or the BB
>wrapper, to get the interrupting behavior that's desired. Was this
>code tested?

Perhaps I missed something, but wasn't the purpose to ensure the
flush happened before the program exited?  In that case, wouldn't:

signal(SIGALRM, exit);
alarm(5);
tcdrain(STDOUT_FILENO); // Stdout, not stdin, isn't it?
alarm(0);
signal(SIGALRM, SIG_DFL);

do it?  Restart bits don't matter if you're not coming back.
There is no recovery strategy for the tcdrain anyway.  All signals
_are_ interrupting, you _will_ take the signal no matter where
you are in the flow of execution.

Or is all this just before closing the transmitting fd,
but _not_ exiting?  In which case what happens after the
alarm signal hits _does_ matter?

-- Jim




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

RE: [PATCH] getty: Wait until all output written to stdout has beentransmitted

[Cathey, Jim]

>As far as I can tell, a proper version of
>those program should not have any of the 1989 code still in it.  Call
>stty to set the terminal parameters, wait for somebody to hit enter,
>maybe "cat /etc/issue", then run the login command.
>What else does it do?

One of the big jobs of getty (which didn't exist in the very
beginning) was to try to figure out the baud rate of the
incoming serial session.  The only reason it managed the "login:"
prompt, which was/is part of login's job, was so that it had
something to work with on the serial line.  Most of the rest
of the crap (like uppercase-only) was to deal with nasty serial
terminals that had pretty much died out by the late 70's.  (But
they were very expensive, and nobody was going to throw them away
until they'd gotten their money's worth.  I had the pleasure of
using a few in college.  "I want my Hazeltine!")

Most of the weird serial terminal stuff is gone, but I'd think
that serial data rate detection would still be important in some
places, especially some classes of embedded systems.  And modems
aren't gone everywhere, not yet.

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdout has beentransmitted

[Cathey, Jim]

>No, this is while starting up, so we don't want to exit. The only
reason
>for the alarm() is that tcdrain() might hang because of flow control
>issues according to Denys, and if that happens we just want to fall
>through and tcflush().

Forgive my lack of paying attention, but then what is the point
of the drain at all?  It'll drain in its own time.  The usual
need for a drain is to prevent race conditions with a device
close or mode change (like baud rate) that might chop off or
mangle the pending output.  Or is there some other race here?

>And yes, STDOUT_FILENO would be somewhat clearer (but wouldn't matter
as
>we just did xdup2(0, 1)), but I kept it as STDIN to match the tcflush
>just below.

But tcflush of stdin throws away pending _input_, does it not?
The fact that the two devices are connected together doesn't
affect the semantics of fiddling with input versus output streams.

I find it confusing to apply output ops to input streams, but
that just happen to work given the setup circumstances.  Makes
things seem like they're trickier than they actually are, which
is usually not a good thing.

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdout has beentransmitted

[Cathey, Jim]

>This thread started by Michal, who's trying to use a very slow
>serial-over-jtag setup on microblaze, and had issues with characters
>getting lost when getty started up (because of the tcflush), so we
>wanted to add a tcdrain() instead.

A design problem?  Why even issue the tcflush(stdout) (in essence)
if you _don't_ want to discard pending output?

Putting a drain first to avoid the flush seems silly.
Perhaps the real fix is to modify the tcflush to not flush
the output stream at all?  Or maybe just for the first time
around, if it's inside a loop of some sort?

If the flush problem is from stuff sent by a process that
preceded getty, rather than getty's own early output, then
the lack of the flush is _its_ problem, not getty's, given
that getty's charter is to program the serial port (if only
partially) in the first place!  Perhaps the parent shouldn't
even be calling getty, but rather login instead?

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdout has beentransmitted

[Cathey, Jim]

I'm just trying to point out that it seems to me that
the iceberg has knocked a big ol' hole in the side of
the ship, the deck chair placement isn't really going
to matter in the end.

There's a fundamental conflict between how the serial
port is being used in this scenario, versus how the
getty tool was designed to be used.  Getty assumes that
it owns the serial port, and that what preceded it does
not matter.  In large part to avoid getting stuck due
to flow control, big wads o' crap that were sent at the
wrong baud rate, etc.

If the _system_ assumes that the kernel (uboot, etc.) has
already set up the port and has perhaps issued tres important
stuff out it, then it should either not call getty, arrange
to wait for drainage before it does, or give getty an
argument that tells it never to discard anything.  No amount
of tinkering with delays and such will make all such
(mis-)uses happy, attention should be focused on solving
the underlying problem.  (Which is that getty throws this
stuff away for a reason!)

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdout hasbeentransmitted

[Cathey, Jim]

To put it another way, sessions begin with getty.
One of its jobs is to ensure that there's no leftover
crap from a previous session that could hang over and
cause problems for the next one.  (Think malicious
user queuing nasty things up on the serial port and
then logging out, in an environment where the flow
control would keep the stuff pending output.)

It's not the _first_ session on a port that is the
reason that getty does the discard!

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdouthas beentransmitted

[Cathey, Jim]

>That is, it takes more than 20 seconds to transmit the buffer contents
>... so that 1 second delay doesn't make much difference.

Exactly why trying to fix this system-specific problem
within getty itself is doomed to failure.  His _system_
design is incorrect, if there's an important message
to get out before beginning to use normal sessions
(getty) on that port, then his _system_ configuration,
probably via init scripts or whatever, needs changing.

Whenever you try to fix a problem in the wrong place,
it usually breaks something else.  If you're lucky,
immediately.

-- Jim

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

RE: [PATCH] getty: Wait until all output written to stdouthas beentransmitted

[Cathey, Jim]

> why is it required? as the tty should have been 
> closed and reopened before, the queues should already be empty.

It is entirely possible for the system to be configured
with something that holds the port open.  Used to use stty
(or something else, I forget) started by init to set the port
baud rate, for example.  It'd hold the port open forever, so
there was no close-induced flush.  A flush was still needed,
so getty does it.

>I don't know what output gets truncated. I assume it's kernel
>console output.

I believe it was init script output that is being considered here.
(The kernel should be responsible for taking care of its own
business; not getty's job at all.)

>"Thanks for informing us that it is important.
>It would be awesome if we would also be informed
>WHY it is important..."

Agreed.  Hayes-style modems litter the input/output
streams with various in-band messages for out-of-band
functions, flushes are entirely appropriate.  As I recall,
you would get something like "CONNECT 1200\r\n" to let you
know what baud rate you should be setting the port to, and
it wasn't too cool to feed that crud on to getty or login!

> old init processes sometimes delayed spawning of new (getty)
> processes for several seconds (resulting in tty close - delay - open)

This was (is) to prevent burning up the CPU time if there is some kind
of hardware configuration problem that results in a looping close/open
kind of thing.  The delay is harmless in normal use, and essential
when things fail in a certain way.

-- Jim




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

RE: [PATCH] getty: Wait until all output written to stdout hasbeentransmitted

[Cathey, Jim]

>sleep(1) isn't sleep for 1 second, it's sleep for 1 milisecond.

Que?  man 3 sleep

SLEEP(3)   Linux Programmer's Manual
SLEEP(3)

NAME
   sleep - Sleep for the specified number of seconds

SYNOPSIS
   #include 

   unsigned int sleep(unsigned int seconds);

DESCRIPTION
   sleep()  makes  the  calling  process  sleep until seconds
seconds have
   elapsed or a signal arrives which is not ignored.

...

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

Multiple group membership?

[Cathey, Jim]

We're having a problem with multiple group membership.
(I thought it was working at one point, but at the
moment it appears not to be.)

Our appliance's privilege strategy involves all
higher-privilege users automatically being a member
of all lower-privilege groups.  To wit (simplified):

> cat /etc/passwd
root:x:0:0:root:/:/bin/sh
one:x:500:503::/tmp/users/one:/bin/sh
two:x:503:502::/tmp/users/two:/bin/sh
three:x:502:501::/tmp/users/three:/bin/sh
four:x:501:500::/tmp/users/four:/bin/sh
> cat /etc/group
root:x:0:root,one,two,three
a:x:503:one,two,three
b:x:502:one,two,three
c:x:501:one,two,three
d:x:500:one,two,three,four
>

If you are "root", say, and switch to "one",
given the above database you should automatically
be a member of the root,a,b,c,d groups.  But we're not:

> id -a
uid=0(root) gid=0(root)
> su -s /bin/sh - gss
> id -a
uid=500(one) gid=503(a)
>

This is Busybox 1.14.2, and id 7.4 from coreutils.
I _expect_ output like:

uid=500(one) gid=503(a) groups=root(0),a(503),b(502),c(501),d(500)

Even if you login (Busybox) it's the same.  I was looking
at initgroups() in pwd_grp.c, and it looked fairly plausible,
except that it looked to me like getgrouplist_internal()
was _excluding_ group lines that matched your target (primary?)
group (OK) or one that had your name in it (not OK?).

Am I way off base here?  This _is_ supposed to work, innit?
The appliance generally has g=u permissions, which relies
upon the group lists being there.  It's having trouble, a
high-privileged (a) user is unable to manipulate
0664 root/root files, etc.

I could have sworn this worked when we released the first
appliance, several years ago, but recently selected admin
tasks are failing on new pending releases.

-- Jim




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

RE: Strange echo behaviour

[Cathey, Jim]

The error, such as it is, is in the implementation of the gpio/export
proc handler.  The Unix file paradigm is that there is no difference
in function between writing bulk data as individual bytes or not,
except for performance and interleaving.  For those rare cases where
the blocking matters, tools like dd exist.

Perhaps your command should properly be:

echo 56 | dd obs=3 >/sys/class/gpio/export

given that you're talking to an inflexible 'device'?

-- Jim

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

RE: Strange echo behaviour

[Cathey, Jim]

The 'errors' EBUSY and EAGAIN are _temporary_ conditions,
often the correct response is to try again.  (Even EACCESS,
ENOSPC, EEXIST, etc. could be considered temporary, depending
on circumstances, and a delayed retry could be considered the
right thing to do.  Not commonly, of course.)  Nowhere I know
of is it required that a retry be exactly the same as a
rejected attempt, one could even argue that trying it again
a different way might even be superior under certain conditions.
(Not, of course, when speaking to devices that have blocking
requirements, whether advertised or unadvertised.)

I still submit that if you are communicating with something
that has a specific blocking requirement then _you_ are
responsible for ensuring that you're using a tool that has
control over the blocking.  DD is the main shell-level tool
for that.

I will also argue that though /proc and /sys were intended
to offer the ease of using normal shell-level ops to control
the system, the implementation of the drivers in the kernel
is flawed if there are blocking requirements, especially
since I've never seen mention anywhere in man pages that
multi-byte writes must be atomic!

The fact that it doesn't often bite doesn't make it right!

-- Jim

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

RE: Limitations on a command line

[Cathey, Jim]

>I have some rubbish code I've inherited and don't have time to rewrite,
>which can spit out
>
>   tar file1 file2 file3 
>   
>where each of the file names is up to 100 chars, and there could be up
to
>2000 of them in theory.

This is what xargs is for.  (Hint: use tar -r)

find glop | xargs -r tar -r archive

or maybe:

http://lists.busybox.net/mailman/listinfo/busybox

RE: Limitations on a command line

[Cathey, Jim]

>I've worked out that while the code uses full paths to move the files
>about, it uses relative paths in the zip command.
>
>so that's 2000 * 50 in the absolute worst case.
>
>It would be nice to know what length of command might break busybox,
but
>failing that I'll stick an xargs in the command line and pray loudly
:-)

There's _two_ places that can croak: busybox, and
the kernel's argument buffer.  Xargs is supposed to
keep it to a manageable level so far as the kernel is
concerned, it's up to busybox (and any other shell)
to handle that system-defined size.

For any kind of a system script that can't know what it
can reasonably expect to see (i.e. worst case scenarios)
you should never use shell globbing, but rather find
and xargs.  They will never fail.

e.g. What does "rm -f /tmp/*" do if there are 12,000,000
files in the /tmp directory?  (Hint: nothing good!)
Whereas "find /tmp -mindepth 1 -maxdepth 1 ! -type d -print0 \
  | xargs -r0 rm -f" will succeed.  More
complicated, to be sure, but more robust.

-- Jim




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

RE: idle (or inactivity) timeout in ash

[Cathey, Jim]

>I notice that getty has a timeout - does this take care of inactivity
>in the shell?

No.

>And I also noticed that ash has no timeouts in the source at all.

Completely normal.

>I can code an idle timeout into ash, but I wanted to check...

Please don't.

Idle timeouts are always implemented outside the shell.
Otherwise, consider how one can circumvent them by typing
something highly secret, like "ed".  (Pick your favorite
interactive tool here.)

The idle timeout program (and I forget the name of the common
one) just watches the TTY accessed times, and if they stop moving
they kill the session.

-- Jim




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

RE: idle (or inactivity) timeout in ash

[Cathey, Jim]

> The idle timeout program (and I forget the name of the common
> one) just watches the TTY accessed times, and if they stop moving
> they kill the session.

Oh yeah, it's "idled", the Idle Daemon.

-- Jim

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

RE: idle (or inactivity) timeout in ash

[Cathey, Jim]

>Using busybox utilities, is their a way to list idle TTY sessions?

Is "w" part of BB?  "who" also shows it.  You have to infer
idleness yourself from the idle time field.

-- Jim

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

RE: Limitations on a command line

[Cathey, Jim]

>> Whereas "find /tmp -mindepth 1 -maxdepth 1 ! -type d -print0 \
>>   | xargs -r0 rm -f" will succeed.  More
>> complicated, to be sure, but more robust.

>Jim - I'm quite interested in this issue - a customer has just forced
us
>to up the spec on our data logger so it may have to delete 1000+ files
at
>once from a log area. I guess that will have the possibility to run
into
>this issue.

Absolutely the sort of area where find/xargs will not run into
trouble, yet other methods might have trouble.  find -exec will
work, but will be slower than find in conjunction with xargs.

>I've just done a pile of googling and now vaguely understand that line!
>is the -r0 a typo?

Nope!  -r tells xargs not to run the target command if there are
no additional arguments fed from the pipe.  Avoids things like "rm -f"
being executed at the end.  One could argue that this should have
been xargs' default behavior from the very beginning, but for
whatever reason it is not.

The -0 works in conjunction with -print0 to handle filenames with
spaces in them.  There are only two characters that literally cannot
be part of a filename: a slash (which is a path separator), and a NULL.
By using the NULL as a delimiter, literally _any_ weird-ass character
found in a filename will still be properly processed.

I just happen to use -r0 canonically, always have.  Getopt likes it
just fine.

-- Jim




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

RE: empty archive

[Cathey, Jim]

>busybox refuses to play nicely with
>
>tar -cf test -T /dev/null
>or
>tar -cf test /dev/null
>
>so is there any other way to get there?

As with all unixen there's always another way!
Once upon a time tar files were simple enough
that you could concatenate them.  Perhaps that
is no longer true?  You could experiment, then
compress the cat result later.

An alternative:

find . | tar zcfT outfile /proc/self/fd/0

-- Jim

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

RE: empty archive

[Cathey, Jim]

># find . -depth -print | pax -wd > outfile.tar
>
>That would be more portable (not all systems have /proc)

Not all systems have a nice place you can safely write
a list file, either.  One would also need to arrange to clean
up this file afterwards, and to make sure it was not included
in the list itself, or else is given to tar as an exclusion.
Ideally the list file is auto-generated, and's a name that can
never collide.  mktemp stuff.

Either way, potential complications.  I'm still trying
to get used to /proc/self/fd/0 versus /dev/stdin!

-- Jim




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

RE: idle (or inactivity) timeout in ash

[Cathey, Jim]

>In Denys' fix, he closes STDIN when the inactivity timer pops. I
>wonder why that messes up the terminal?

Perhaps because shells routinely mess up the terminal
in normal operation, and this interfered with its trying
to put it back?  (Also routine.)

-- Jim

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

RE: idle (or inactivity) timeout in ash

[Cathey, Jim]

>... hey Denys, could you try to close only stdin on alarm and do the
>terminal restore on stdout/stderr instead? ... just as a hint for a
>possible solution.

Shells have historically always used STDIN for the
tty settings, due to the extremely common cases where
stdout/stderr are redirected.

Y'all are starting to swim in some pretty shark-infested waters...

-- Jim

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

RE: complaint from svlogd

[Cathey, Jim]

>Anyone else may hold the writing
>end of the pipe in an open state ... which shouldn't be the intention
on
>a simple pipe like:
>
>"message_producer_process  | message_logger_process"

BTDT.

Yes, use fuser (or rummage in /proc/X/fd) to find out
who's still got the writer side of the pipe open once
the producer is dead and gone.  It's real easy to leak
pipe fd's if you're not careful, but the shell (creater
of all |'s) shouldn't have such a weakness in it.

-- Jim

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

RE: complaint from svlogd

[Cathey, Jim]

>then any kind of kill, including SIGKILL, on fred should send svlogd an
>EOF and it should shut down pronto.

Specifically: any kind of _death_, whether caused by a signal
or not, will give svlogd an EOF.  (Plenty of signals don't
necessarily cause death, for example.)  Unless somebody else
has pipe[1] open.  The famous bug is to leave a copy in the
reader, in which case it'll hang around forever.

-- Jim

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

Proposed More patch

[Cathey, Jim]

Please forgive the un-real patch-oid format, but we're not
set up to do it better right now.  We've got a script that
pipes GNU ls -C into BB more, and it really messes up the
tabs.  I made a quick patch to more.c which seems to help.
Any reason this shouldn't be permanent?  The crude conversion
is hardly less crude than the original, but works a lot better.

/* Crudely convert tabs into spaces, which are
* a bajillion times easier to deal with. */
if (c == '\t') {
--- spaces = CONVERTED_TAB_SIZE - 1;
+++ spaces = CONVERTED_TAB_SIZE - (len % CONVERTED_TAB_SIZE)
- 1;
c = ' ';
}

-- Jim

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

RE: update a running busybox

[Cathey, Jim]

>When you unlink a binary that is being executed (for instance:
>/bin/busybox), said binary is not deleted at once, because it is still
>in use (processes executing it have a fd open on it). The binary is
>just marked for deletion; when all processes executing it have exited,
>the real deletion occurs.

One system I used, DNIX, would push an unlinked executing binary
into swap space, then do the FS deletion.  Was actually pretty nice,
it 'just worked'.  Once the last executing process died the swap
space was released.  There was very little extra kernel code
involved, it just exploited existing mechanisms.  I'm surprised
that Linux doesn't do this, actually.

-- Jim

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

RE: update a running busybox

[Cathey, Jim]

>This is somewhat difficult or impossible to do in a conformant way.
>Each open file has a device and inode number which cannot change for
>its lifetime, which are important identifiers that may be used in
>security-critical ways.

In this (DNIX) system the file was not 'open' at the user level,
and as a resident of swap space it didn't really have a device or
an inode.  (As data/bss segments did not.  Just memory pages backed
to a blocking store.)  Even if it were required to have dev/inode,
perhaps to support /proc/X/exe, why could it not get a new assignment
on the swap device? (Essentially automating what we all have to do
by hand now.)

Perhaps there is some esoteric security protocol that would be confused
by this, but one could argue that that protocol was overly
system-sensitive.
What ongoing security check would be required for an already-executing
process?

-- Jim

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

RE: update a running busybox

[Cathey, Jim]

>A better approach in my mind would be to move the orphaned inodes to
>an invisible directory whose contents are automatically deleted at the
>next mount (by the mount utility or the kernel). The kernel could also
>wipe them when the last reference is closed, but only if the device is
>mounted for write still.

Can't unmount a device with processes executing off of it.
I believe DNIX could.

>the general semantics for deleted open files are important to security

DNIX did this, not on a file being deleted necessarily, but also on it
being opened for write.  And it _only_ did this for executing images,
anything being used as a regular file continued to behave as before.
Basically it noted whenever it could no longer rely on the original
executable file to feed the in-memory execution cache, and arranged
to move the contents to a private place that it _could_ rely on,
releasing the original reference.  It worked pretty slick.  Want
to get a new program?  Cp or tar it, no special precautions.  Want
to force a resident program to start using the new version?
Then restart it.

-- Jim

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

RE: rewriting config_*, xmalloc_fget*

[Cathey, Jim]

There are exactly two characters (of an unsigned char)
that cannot be in a Unix filename: '/', which is the
path component separator, and '\0'.  Everything else,
including newlines and spaces, is perfectly legal
in a filename, though perhaps incredibly annoying
to deal with if present.  The \0 delimiter was really
the only choice for -print0.  Don't really see a context
where _both_ delimiters are meaningful in the same file
stream, though.

-- Jim




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

RE: rewriting config_*, xmalloc_fget*

[Cathey, Jim]

>Actually, xargs (the standard one, without -0) accepts a shell-quoted
>list of filenames, so rather than -print0, find could have just been

Maybe now they do, but when they were first written
they did not.  (Or so I understand.)  The -print0 solution
was the easy/obvious choice, especially given that the NUL
character couldn't be found in a filename.  It required near
zero change to the existing code, and handled all weirdo
filenames with ease.

-- Jim




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

RE: rewriting config_*, xmalloc_fget*

[Cathey, Jim]

>There's no point in C programs reading the output of find -print0.

Agreed.  It was for find|xargs pretty much alone, and there it
works wonderfully well.  Shell quoting, in the early days, was
perhaps not so 100% foolproof as a utility to clean up directories
might need.  The NUL-delimiter eliminated the need to consider
all that crap, in that context.  Fast, too.

-- Jim




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

RE: login shell when using CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS

[Cathey, Jim]

Once upon a time login shell activity was triggered
by the first character of argv[0] (to the shell) being
a '-' character.  Strange, and maybe stupid, but that's
how it was done.  The "-l" option was just to trigger
(manually) the automatic '-/bin/sh' behavior, when you
needed it in scripts.

Our busybox system is still using that leading '-'
character, why isn't yours?

-- Jim



-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Sam Gandhi
Sent: Thursday, June 30, 2011 6:20 AM
To: busybox@busybox.net
Subject: login shell when using CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS

I am running busybox with option
CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS, I need to run with this option
because of SELinux.

Only issue I am running into is when I login /etc/profile or
~/.profile are not getting run. I see that busybox has option to run
shell with -l option.

But if I modify my /etc/passwd file to refer to shell as /bin/sh -l ,
login works fine but other programs such as dropbear don't work.

Before I start patching those programs wanted to find out if there is
some other way I can invoke shell to let it know that its login shell
v/s non-login shell?

-Sam
___
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: "kill -HUP `pidof inetd`" fails

[Cathey, Jim]

Looks like whatever it was that tried to invoke
the kill command didn't use a shell to parse it
first.

-- Jim



-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Gilles
Sent: Wednesday, July 06, 2011 4:19 PM
To: busybox@busybox.net
Subject: "kill -HUP `pidof inetd`" fails

Hello

An application uses the following command to restart inetd:
=
root:/var/tmp> kill -HUP `pidof inetd`
kill: bad pid '`pidof'
kill: bad pid 'inetd`'
=

pidof is actually compiled in Busybox:
=
root:/var/tmp> which pidof
/sbin/pidof

root:/var/tmp> ls -al /sbin/pidof
lrwxrwxrwx1 root root 7 Jul  4  2011 /sbin/pidof
-> busybox
=

Inet is running OK:
=
root:/var/tmp> ps aux| grep inetd
   55 root   484 S/sbin/inetd -f
  196 root   692 Sgrep inetd

root:/var/tmp> pidof inetd
55
=

I don't understand the cause for the error. Anybody has an idea?

Thank you.

___
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: No brace expansion for ash?

[Cathey, Jim]

>These 3 examples do the same thing...

And a fourth, which tends to be the way I do
such things:

(P=/usr/local/people/ mkdir -p $P && cd $P && mkdir me you others)

-- Jim




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

RE: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground

[Cathey, Jim]

>Some state needs to be shared. But the blocking/non-blocking flag
>should not; the flag should be attached to every copy of the
descriptor,
>not to the file.

Agreed.  If a non-blocking flag needs to exist (and I think it
shouldn't) it should be part of the fcntl set, private to the
process and not shared.

-- Jim




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