RE: [**EXTERNAL**] HOME variable in init/init.c

[Cathey, Jim]

>I would expect it to be "/root" considering that USER has been set to "root"...

Who says there has to _be_ a "/root" directory?

-- Jim

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

RE: [**EXTERNAL**] Re: [PATCH] ash: make bash_source command search current directory after PATH

[Cathey, Jim]

>I fought through the bash startup scripts almost 20 years ago in 
>college, and still have "source .bashrc" in my ~/.bash_profile that >I've  
>been carrying from system to system ever since :-)
>and my PATH has never had '.' in it.  Your explanation makes
>perfect sense though.

My understanding predates bash.  :-)
But is it correct?  I'd have a hard time testing one of THOSE
systems now!

-Mike

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

RE: [**EXTERNAL**] Re: [PATCH] ash: make bash_source command search current directory after PATH

[Cathey, Jim]

My understanding, from years past, is that "source " (or ". ") is 
_exactly_ the same as "", except that it's running in _this_ shell rather 
than in a subshell.  Thus it is able to affect environment variables that 
subsequent commands can inherit, etc.

If "." is not in your PATH, and you want to source a file that's right there, 
you have to ". ./" just as you'd expect.  If that's not what bash is 
doing, then it's wrong.

-- Jim

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

RE: [**EXTERNAL**] SV: Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

[Cathey, Jim]

The rule is pretty simple:  If you die, and your parent is still in the process 
list (regardless of its state), then you're a zombie until your parent reaps 
you.  If you die and your parent is not in the process list, then init(8) reaps 
you at its earliest convenience.  If you're a zombie and then your parent dies 
without reaping you, the kernel adopts you to init(8), who then reaps you at 
its earliest convenience.  A process ALWAYS has a parent, either its original 
parent or init(8), and that parent is always responsible for reaping you upon 
your death.  This is part of the very definition of Unix, and all its 
descendants.  If this isn't happening, there is a bug in init(8), and/or the 
kernel.

In no way are you required to reap your own children before death, whether 
deliberate or accidental, and you never have been.

However, there are no particular time constraints upon this reaping by init(8). 
 It could be busy doing something, even something as innocuous as logging to a 
file, that causes a delay.  If your system is designed to require a fast reap 
somehow, then you must reap your own children.  But that's a particular system 
issue, not a generic problem.  I could argue that perhaps this is an 
ill-designed system, if it's relying upon unspecified behavior.

-- Jim

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

RE: [**EXTERNAL**] Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

[Cathey, Jim]

>Unconditionally sleeping when signals may arrive is a no-no.

It used to be that sleep(3) was interruptible.  Is this no longer the case?  
Who broke libc, and when?

-- Jim

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

RE: [**EXTERNAL**] Re: Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.

[Cathey, Jim]

I concur.  If a process's parent dies, that process will NOT be a zombie, no 
way no how, unless either the system's init(8) process is broken, or there is 
some kind of bug in the kernel.  You do not need to reap your own children 
before dying, and you never have, not on any flavor of Unix since 1972 or 
thereabouts.

-- Jim

From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Emmanuel Deloget
Sent: Wednesday, January 03, 2018 3:04 PM
To: Markus Gothe 
Cc: busybox 
Subject: [**EXTERNAL**] Re: Re: [PATCH] Fix runsvdir so it reaps children and 
avoid zombi processes when killed.

Hello,

On Wed, Jan 3, 2018 at 11:04 PM, Markus Gothe 
> wrote:
Can you run strace on a process invoked from the inittab? I surely have issues 
with doing that.

​This is definitely possible, but thou shall not forget -ff to follow forks 
(and prepare for an awfull lot of output, so maybe you should redirect that in 
some log file). ​



As far as killing the processes it doesnt matter which signal you use; 
processes will become zombified forever without the patch.


​I, too, don't get how runsvdir children can be zombified if runsvdir is 
killed. ​When runsvdir dies, the children are reparented to /bin/init which is, 
AFAIK, reaping them.

I won't disagree with you (you say you have zombies all over the place) but 
maybe the problem - and the right fix - lies somewhere else.

Best regards,

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

RE: Reboot implemention

[Cathey, Jim]

>Is there a reason why BusyBox's [reboot] implementation is different, or is it 
>a bug?
None of the above?  A sync(2) call, wherever found, is not the be-all and 
end-all of filesystem cleanup.  It just gets the fs cache-cleaning party 
started.  More than one is just fine, even zero is fine.  It's mostly just 
trying to help provide data-loss insurance against an unlikely kernel crash 
during the shutdown phase.  The final fs cleanup, and the only one that really 
counts, is what the kernel does after init(8) exits.

-- Jim

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

RE: [PATCH] dd: fix corrupted/incomplete reads/skips.

[Cathey, Jim]

Anybody here ever actually used dd to read from an actual _tape_ drive?  Short 
reads are the norm, there.  (Or were.)  The bs= size was the _maximum_ record 
size, but the records could be, and often were, shorter.  Please don't break dd 
so that it can only work on 'b'lock devices, and not 'c'har devices.

-- Jim

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

RE: getty hidden process

[Cathey, Jim]

>If you've got a command prompt, then getty isn't running -- the shell is.

Yes.

>If you've got a _login_ prompt, then getty is running.

Close!  Getty _might_ be running, or perhaps /bin/login
is.  Could be either, depending on how you got there.

-- Jim

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

RE: Compiling busybox for ARM-V7

[Cathey, Jim]

"VAR=value make..." is 100% identical to
"export VAR=value; make...", from the point
of view of make and its children.  Perhaps
try that?

-- Jim

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

RE: copying multiple files

[Cathey, Jim]

>I want to make this the shortest command possible is because I don't want to 
>add 60 lines of code to a script just to copy
>10 files (with error control and so forth).

This sounds like an excellent opportunity to make a function,
or to feed an embedded pipe with a list...

while read f; do
  cp -f $f dest || error oops
done 

RE: copying multiple files

[Cathey, Jim]

So you've written a shell script that relies upon non-POSIX
behavior, specifically GNU bash extensions, and it doesn't
work in POSIX-ey ash.  No big surprise.  You will have to
do it differently, or install bash on your target.  Same
dilemma everybody else faces when dealing with 'small' targets.

What's _wrong_ with this kind of thing:

P=/tmp/test cp -f $P/a $P/b $P/c ... dest/

anyway?  (I used $P to cut down the source line length, but
it's totally unnecessary to the functionality.)  It's not
like you have to get everything done in one command, either.
The cp command is not some kind of atomic operation.  Are you
after a fewest-line-count award?

-- Jim

-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of David Henderson
Sent: Monday, November 21, 2016 2:07 PM
To: Grant Edwards
Cc: busybox@busybox.net
Subject: Re: copying multiple files

Thanks again for your continued help Grant.  Unfortunately the file
names are not actually similar as in the example (e.g. help.txt,
world.png, ...) so using braces won't help either.  Any other
thoughts?  Currently I'm forced to use a combination of find and cp -
ugh - just to reduce the number of lines necessary for the
operation...

Thanks,
Dave


On 11/21/16, Grant Edwards  wrote:
> On 2016-11-21, David Henderson  wrote:
>> On 11/21/16, Grant Edwards  wrote:
>>> On 2016-11-21, David Henderson  wrote:
>>>
 cp -f /tmp/test/{a.txt,b.txt,c.txt} /tmp/test2/{1.txt,2.txt,3.txt}
 /tmp/dest
>>>
 This keeps failing.  Is this implemented in BB?
>>>
>>> Try this:
>>>
>>>$ busybox ash
>>>~ $ echo /tmp/test/{a.txt,b.txt,c.txt}
>>>/tmp/test/{a.txt,b.txt,c.txt}
>>>
>>> It appears that the busybox shell does not implement bash/C shell
>>> alternation (aka "brace expansion").  None of the busybox builds I
>>> have on hand do anyway, and I don't see any options in the config file
>>> to enable such a feature...
>
>> Hey Grant, thanks for the reply!  Unfortunately that command will just
>> echo what you type to the screen, not actually copy anything.
>
> I know.  I was showing you how to determine if alternation (brace
> expansion) wasn't happenning.  It doesn't on any of my builds of
> busybox.
>
>> Any other thoughts?
>
> Don't try to use alternation:
>
>   cp -f /tmp/test/[abc].txt /tmp/test2/[123].txt /tmp/dest
>
> --
> Grant Edwards   grant.b.edwardsYow! ... I think I'd
>   at   better go back to my
> DESK
>   gmail.comand toy with a few
> common
>MISAPPREHENSIONS ...
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: [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: 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: 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: 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: 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 <jcat...@ciena.com> [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: 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 cur...@operamail.com
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

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: 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] 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 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: [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: 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]

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 
t...@hentenaar.commailto: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.commailto: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 
t...@hentenaar.commailto: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.commailto:guille.rodrig...@gmail.com
___
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]

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 grant.b.edwa...@gmail.com 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: 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: 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: 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 lp...@kde.orgmailto: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 
lp...@kde.orgmailto:lp...@kde.org wrote:
On Thu, Aug 14, 2014 at 2:04 PM, wald...@gmx.demailto: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.netmailto:busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

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

RE: [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: [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: [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 jcat...@ciena.com 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: 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] 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 farmat...@tiscali.it 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]

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: 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: /proc/pid/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: 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.commailto:md...@emacinc.com
http://www.emacinc.com/

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


On Fri, Mar 21, 2014 at 4:16 PM, Laurent Bercot 
ska-dietl...@skarnet.orgmailto:ska-dietl...@skarnet.org wrote:

 Are you seriously suggesting to add dlopen()ed libraries to busybox
to offset the bloat of adding a config file parser to ntpd ?

 This is the exact kind of design that busybox is fighting.
 Please 
readhttp://busybox.net/FAQ.html#goalshttp://busybox.net/FAQ.html#goals  and
http://busybox.net/FAQ.html#tips_memory  , as well as
http://en.wikipedia.org/wiki/KISS_principle .

--
 Laurent


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

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

RE: Ntpd config file support

[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: 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: [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 unistd.h
#include malloc.h
#include string.h

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 jcat...@ciena.com 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 jcat...@ciena.com 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: ash: source nonexistent file 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: ash: source nonexistent file 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 nonexistent file 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 ATT 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: utmp fix for mips64 uClibc systems

[Cathey, Jim]

I'd really be interested in knowing how you
could mess up close() that bad...

At a guess:

int
close(int fd)
{
if (array[fd].isOpen) {
...
}
}

Rich
___
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: [BUG] vi does not recognize changed permissions on read only files

[Cathey, Jim]

Of course this also has down-sides, such as losing extended attributes
and other file properties the application is not aware of, and not
being able to preserve ownership.

It also breaks hard links.  Keeping FD's open is not
normal for most Unix tools of this sort.

-- Jim

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

RE: [PATCH] udhcpc: add support IETF RFC2131 section-4.1 retransmission strategy

[Cathey, Jim]

I would hope large corporate or university networks have proper
backup power so that power failures don't occur.

That is absolutely nothing that a protocol should be
designed to rely upon!  Network restart scenarios should
_always_ be reliable, no matter what the provocation.

-- Jim

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

RE: utmp fix for mips64 uClibc systems

[Cathey, Jim]

This is a uLibc fault.  A common idiom,
from way back, is:

close(creat(...));

Close is supposed to be able to survive being
given a negative number.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Waldemar Brodkorb
Sent: Monday, September 24, 2012 12:12 PM
To: busybox@busybox.net
Subject: utmp fix for mips64 uClibc systems

Hi Developers,

I have some strange problem with getty, init and login on mips64
uClibc (0.9.33.2) systems:
qemu-system-mips64, big endian, n64 
lemote yeelong, little endian, n32

Following test code segfaults:
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h

int main() {
int n;
n=open(/dev/nul, O_RDWR);
close(n);
return(0);
}
 
When close get a -1 as argument, it segfaults.

Suggested patch for libbb/utmp.c to avoid this in the mentioned apps:

best regards
 Waldemar

---

From f1b662fe3a847c190c46f93c0f13002ee3ca6c0c Mon Sep 17 00:00:00
2001
From: Waldemar Brodkorb w...@openadk.org
Date: Mon, 24 Sep 2012 21:10:52 +0200
Subject: [PATCH] close(-1) segfaults on mips64 uClibc systems


Signed-off-by: Waldemar Brodkorb w...@openadk.org
---
 libbb/utmp.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libbb/utmp.c b/libbb/utmp.c
index 09443fb..c56fdb3 100644
--- a/libbb/utmp.c
+++ b/libbb/utmp.c
@@ -10,8 +10,14 @@
 
 static void touch(const char *filename)
 {
-   if (access(filename, R_OK | W_OK) == -1)
-   close(open(filename, O_WRONLY | O_CREAT, 0664));
+int c = 0;
+
+if (access(filename, R_OK | W_OK) == -1) {
+c=open(filename, O_WRONLY | O_CREAT, 0664);
+if (c  0) {
+close(c);
+}
+}
 }
 
 void FAST_FUNC write_new_utmp(pid_t pid, int new_type, const char
*tty_name, const char *username, const char *hostname)
-- 
1.7.10.4


___
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: Telnet and carriage return.

[Cathey, Jim]

 Another solution would be to use sed 's/$/^M/' | telnet ...
you don't want sed to buffer the data...not implemented in busybox sed

The canonical cr-lf translation is to use tr, not sed.

-- Jim

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

RE: switch_root and mount move

[Cathey, Jim]

  mkdir(sub, 0700);
  chroot(sub);
  chdir(../../../../../../../../..);
  chroot(.);

If that works, the kernel is broken IMHO.
Or is this predicated on the CWD not being
somewhere in the chroot path to begin with?

-- Jim

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

RE: [PATCH] arpping in udhcpc

[Cathey, Jim]

Is not one of the ways to manage delta-time
timeouts to use uptime() instead of time()?
You don't care what time it is, you only want
to manage a timeout on the order of seconds,
so a monotonic time source like uptime() is
actually preferable.

It seems to me that 64-bit math is unnecessarily
punitive, especially for many embedded processors.

Also, DST doesn't affect the value of time()
et al. at all, or should not.

-- Jim

-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Adrian Szyndela
Sent: Wednesday, April 11, 2012 1:41 AM
To: busybox@busybox.net
Subject: [PATCH] arpping in udhcpc

Hi,

I'm attaching a patch for way too long wait on poll() during arpping
after IP address acquiring over DHCP.

It happens on a platform which starts with Epoch time. Then, at some
point, a correct time source appears, and an actual time is set.

If an actual time is set during wait on poll(), computing of a timeout
overflows on unsigned type. The patch just changes types to stay with
long long computing.

Before applying the patch the side effect of setting an actual time is
close to hangup - with no IP address assigned. After applying the patch
the side effect of time change is that poll() might wait shorter than
desired 2 seconds in case of socket activity.

I found a comment /* We don't expect to see 1000+ seconds delay,
unsigned is enough */ in networking/arping.c (which probably is affected
by the problem as well). The above case introduces 10+ seconds
delay :). 3600 seconds at daylight saving time change is a piece of
cake.

Regards,
Adrian

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

RE: Amusing article about busybox

[Cathey, Jim]

My (lay) understanding of this is that there are two separate
issues:

1) Company contributes (back) to the project.
2) Company provides sources of whatever they did.

Obviously #1 is preferable, assuming the mods are palatable,
but only #2 is required.  It would take an interested (and
possibly third) party to fold #2's back to #1's.

All this discussion seems to be focused on #1, but Sony
is (?) in the #2 camp.  Unless maybe they're in #3:

3) Company takes sources and never exhibits its modifications.

I thought that only #3's were liable.  #2's are merely annoying.

Free means free.  Free to be a bit of a jerk about it, if that's
what they want to do.  Free to obfuscate all the code, free to
rot13 all the non-keyword vowels in the code, etc.  So long as
they make the results available.

-- Jim

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

RE: Ping: [PATCH] make pidfile permissions 644, not 666

[Cathey, Jim]

Aren't most uses of 0666 implicitly assuming
some umask activity?  I know that the common
umask of 022 will turn this into 0644, which
is usually what you want.

However, we have a system where U=G almost always
in order to have the desired functionality,
and there the default umask is 02, resulting in
0664, which is what is necessary there.

The point is that the 0666 is not to be assumed
to be the final value.  Also the point is that
to use this proposed new code in our system we
would have had to find it, and change it to something
else in the source, rather than relying on umask.
(Which is what umask is for.)

Seems like a bad patch to me.

-- Jim



-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Ian Wienand
Sent: Wednesday, August 24, 2011 3:29 PM
To: busybox@busybox.net
Subject: Ping: [PATCH] make pidfile permissions 644, not 666

ping on this ... I still think there's no valid reason to create a
pidfile with 666 permissions.

-i

On 04/29/2011 03:30 PM, Ian Wienand wrote:
 Hi,

 666 seems too permissive for default pidfile permissions.

 -i


 Signed-off-by: Ian Wienandi...@vmware.com

 ---
   libbb/pidfile.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/libbb/pidfile.c b/libbb/pidfile.c
 index a48dfc3..ef58159 100644
 --- a/libbb/pidfile.c
 +++ b/libbb/pidfile.c
 @@ -23,7 +23,7 @@ void FAST_FUNC write_pidfile(const char *path)
   if (!path)
   return;
   /* we will overwrite stale pidfile */
 - pid_fd = open(path, O_WRONLY|O_CREAT|O_TRUNC, 0666);
 + pid_fd = open(path, O_WRONLY|O_CREAT|O_TRUNC, 0644);
   if (pid_fd  0)
   return;


___
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: [OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Cathey, Jim]

I'd like to know how else, other than this ugly SIGCHLD handler, you
can create a child process without having the keep track of the pid
and have part of your code be responsible for waiting for it.

Just use the asynchronous waitpid.  Oh, sorry, we're not talking
about DNIX here are we?  :-)  Its kernel would satisfy waitpids
before more generic waits, if multiple wait requests were queued.
(Internally ALL requests are the same, asynchronous, the usual
synchronous API wait point was in the system-to-user transition
code.  Tres elegant.)

I already explained how this could lead to *unbounded* memory growth
through leaks that are nearly impossible to fix, unless all your
forking happens from a common parent that doesn't grow.

The only benefit of the fork helper we were forced to implement is
that the fork cost is less, since the massive application is no longer
the process that forks but rather its quite svelte first child.  These
forks, however, do not inherit any interesting memory state and so
are really only suitable for forks followed by exec.

-- Jim




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

RE: [OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Cathey, Jim]

Well yes, if poll() keeps lying about event availability, then your
program will loop a few times without doing any progress. But that is
not a problem in poll's design, it's a problem in the implementation.
Lying about event availability is not supposed to happen often.
According to Rich, it is not even supposed to happen at all.

I maintain that it _is_ a problem with poll's design, because
poll doesn't/can't know enough about what you wish to do in the
future to be 100% reliable, and CANNOT know about external factors
that destroy the orderly behavior you're counting on.  It's more
of a guideline, really...

These disruptive external factors (shared fd's) will or will not
damage what you're doing depending on the nature of the communication
on these fd's, but will almost certainly damage poll/select's ability
to maintain program responsiveness.  Unless you've managed to actually
change all fd's in the system to be non-blocking, and changed all
I/O routines to handle early returns, etc.  That's my point.  Because
poll/select is such a poor tool you have to change everything else in
the system to accommodate it.  With a better tool, you don't.

That is no difficulty at all. Compute a deadline for every event in
your program (unlike timeouts, deadlines do not change at every loop
invocation); the difference between now and the earliest deadline is

That's what I'm talking about, you have to subsume into your main
loop all the tiny details of all your program's logic.  Can be done,
most of the time perhaps, but unpleasant.

For people who are unable to do the minor computations involved, the
Linux guys went as far as providing them with as many individual timers
as they want: timerfd(). This is really encouraging excessive laziness.

That's actually a step in the right direction, too bad it's Linux-only.
Is certainly easy to abuse, I've seen it here.  Just because you _can_
have your own timer per-whatever, doesn't mean you _should_!  It's a
balancing act.  At least such abuse is usually only a performance
problem,
and can be cured without affecting anything else by rewriting that bit
of the application.

But you just can't justify
your dislike by pretending that it's not an event-driven paradigm API,
because it is.

It _is_ an event-driven paradigm, yes.  But a poor version!  That's
what I dislike.

the tools we have *can* already be used in
a clean way, so I don't see the need for an urgent fix, whereas some
other things (such as a per-fd nonblocking flag) do need one.

No, it's not urgent.  It's a shame though, to me, that here we are
20+ years later and still band-aiding the same poor tool that was
first conceived at Berkeley in (I guess) CS101.  The same guys that
invented file descriptors that weren't file descriptors (sockets)
brought you polling as the main paralleling API.  This crap's hanging
on longer than DOS did!

If people were accustomed to using a good, long-standing AIO
scheme then we wouldn't NEED a per-fd nonblocking flag, etc.
I submit that the whole mess would have stabilized years ago,
with no continuing need to tinker with the guts of the mechanism.

Threads are also purely a question of taste. Rich likes them. Lots
of people like them. I don't. Alan Cox doesn't. YMMV.

I'm torn.  Sometimes good, sometimes bad.  We're actually having
very good luck using them in our product at work, but that's because
it was a port from an OS whose processes were more like threads.
(Shared memory space.)  Also, our main synchronization mechanism is
message-passing (via Linx), which is quite clean.  We've had few
problems with this, but that's mostly because the gross bugs were
already shaken out years ago in the original OS.  Starting from
scratch I would _not_ have used threads.  Or very few threads at
least, rather than the 100+ that's in it now.

The most evil fallout from threads was the necessity to eliminate
all forks in our program.  99% of the time it worked just fine,
but every once in awhile it crashed.  We wasted man-months chasing
that, it was some kind of conflict with glibc fork vs malloc.  Ugh.
So I had to invent a fork server (the Blue Rajah: Master of Cutlery,
Forks a Specialty :-), and get rid of all system/fork/popen calls.
What a nightmare, there's still a bit of fallout from that two years
later.

I bet your dear foolproof completion queues can also be misused in
horrible ways, too. But I'm not going to start a contest. ;)

Not foolproof, but somewhat harder to misuse IMHO.  How does that
famous phrase go?  Never underestimate the stupidity of the
computing public?  Or something like that...

-- 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]

That's why I propose we don't multiply syscalls, but extend existing
socket I/O ops to work on non-sockets.

IMHO it cannot be more elegant.

Only in one way can it become more elegant.  Eliminate sockets
altogether, making them the fd's that they always should have been.  :-)

-- Jim




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

RE: [OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Cathey, Jim]

there are some fundamentally unsolvable issues
(like who owns a process-shared mutex after fork?

I should have been more clear.  Our problem was that the forking
multithreaded _parent_ died with a SEGV!  The children, single-threaded
and going on to an immediate exec, were just fine.

that, it was some kind of conflict with glibc fork vs malloc.  Ugh.

This is supposed to be fixed, but there are possibly some hideous
corner cases deriving from the fact that fork() is specified to be
async-signal-safe but now has to deal with malloc state/locks...

It was something like that, and it most certainly was NOT fixed
at the time we ran face-first full-on into it.  We had little choice
but to code around the problem.  We'd lost a lot of time trying to
'fix it right', and the original 500# canary customer was losing
patience...

We are ranging a bit far afield from the original subject regarding
the seemingly-endless tinkering with the kernel and possibly every
major application in order to keep select/poll working right.  It
does, however, illustrate the pitfalls of just use threads as
one solution to the problem.

-- 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]

It doesn't; it can't.  Hence my ranting.  A 100% safe
100% orthogonal, useful easy-to-use AIO mechanism should
have been designed

Would the hypothetical nonblock_read() and nonblock_write() system
calls suggested at http://cr.yp.to/unix/nonblock.html be a good
enough design, or do you think something more is needed?

No, that is just entrenching the polling methodology.
I am a proponent of true AIO design, with _no_ polling
facilities available at all.  (Well, they can be there
but on the same list as gets and friends, so far as
desirability of use goes...)

See: http://en.wikipedia.org/wiki/Asynchronous_I/O

also http://en.wikipedia.org/wiki/DNIX

for details on the AIO system I used and liked best.

-- Jim




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

RE: [OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Cathey, Jim]

I understand what you mean, but poll() loops, despite the misleading
name of the central primitive, are not doing any polling at all. poll()
works by notification, not by polling (... at least I hope that kernel
developers have the good sense to make it so).

The underlying OS details are, hopefully, not actual polling, but the
paradigm presented to the application program is still effectively
a poll, just as select is: the paradigm is mother-may-I followed
by an attempt to actually _do_ what is desired, repeat until done.
I.e., a poll.

The non-blockingness of the actual attempt is in no way guaranteed
in spite of the implication of the success of poll/select.  Also,
because it is effectively a poll the application tends to be written
in a non-event-driven fashion, which can make a real mess in a more
complex application.  (Not inherent, yet it seems to happen a lot.
Same as pointer abuse in C driving successor languages not to have
them at all.  If you don't provide a poll-oriented API then it's
MUCH harder to write a strung-out polling application.)

If you like DNIX's completion queues, there is
no reason you should dislike poll() loops, because it's the same
paradigm;

There we disagree, because the queued blocking operations are all
blocking in parallel!  With poll/select the blocking is all in
poll/select.  (Unless it isn't, oops.)  Oh, and you have to manage
the global poll/select timeout value yourself depending on everything
that is going on in your program, rather than queuing up autonomous
asynchronous timers, as many as needed, as just additional
asynchronous blocking operations.  Ugh.

the DNIX API probably just provides you with nice syntactic sugar to
hide
the gory details of adding and removing events and/or timers.

In a sense, yet that sugar (or salt, depending on your predilection
for event-driven programming) is what encourages the writing of a
paralleled application that doesn't have weird sticking points where
it goes non-responsive.  (And haven't we _all_ seen those!)

Other AIO paradigms mess with the program control flow. I personally
like having maximum control over the control flow, so I'm reluctant to
use such paradigms, but it's purely a question of taste.

I can see this, and I offer up an anecdote.  While developing this
system (for bank teller applications, in fact) we had two main GUI
applications, with two sets of authors.  One was a forms designer,
and one was the runtime data collector.  Both authors began by writing
their applications in the traditional way, with a sequential thread
of what to do next.  They were both having problems, naturally, making
a GUI application remain totally responsive to the user.  I was able to
convince the forms author to convert to an event-driven paradigm, using
AIO.  It took him a week or so to convert his rudimentary app.  I never
heard from him again, basically.  (I was the main GUI author, and was
always called in whenever anything went wrong.)  Occasionally he
thanked me for 'making' him convert, as he loaded up more and more
features onto the application and it Just Worked.  The other author(s)
were militant in their preservation of their traditional BSD-derived
select-style application, and claimed that they didn't have time
to convert.  For YEARS thereafter this application continued to
have weird responsiveness problems and other operational bugs, all
tied directly to the non-event-driven architecture of their program.

I even got a free trip to Rochester NY, with the other authors, just
to observe that a persistent problem the customer was having was due
to the operator occasionally hitting an unexpected key in one particular
place in the program.  (That particular event-get in the strung-out
code didn't know how to properly handle that particular key and so
ended up inadvertently recursing on the main application loop, resulting
in stack burn and eventual death once enough of those keys had been
hit during the day.)  Such are the perils of keeping a complex program's
state in the program counter rather than in a state table.

(very) pseudo-code of the good main application loop:

while (read(tqfd, event, sizeof event) == sizeof event)
switch (event) {
case keystroke: ...
case menu_item: ...
case mouse_click: ...
case window_refresh: ...
case timer_exp: ...
case read_done: ...
case write_done: ...
case connection_made: ...
case connection_died: ...
case child_exit: ...
default: ...
  }
exit(1);

This kind of application is ALWAYS ready to respond to the user, or
any other high-priority event, when combined with exclusively AIO,
never SIO.

The 'sugar', such as it is, wasn't what I normally consider sugar at all
but rather the notion that you asked servers to do stuff asynchronously,
and once they replied that they were done you moved 

RE: [OT] poll() vs. AIO (was: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

[Cathey, Jim]

No. The paradigm in wait until some event happens, then react on it.
The most important feature of select/poll is that they
*wait for something to happen*, and can wait for a set of events,
not just one event.

That is true, so far as it goes, but it's the nature of 'something'
that is one of the near-insoluble problems of select/poll.  The
go-ahead is decoupled from what you want to do, and can be out of
sync.  (Which is what started this whole discussion.)  That lie
is the unforgivable sin of polling, and when it's coupled with the
fact that with poll/select you only have one timeout, which you have
to manipulate depending on what is going on _everywhere_ else in
the program, you start to wonder why you're using that kind of a poor
tool to begin with.  My pursuance of event-driven AIO is just sugar
on top of NOT using polling in general, and poll/select in specific.
I am biased, but I believe I have good reason to be.

The heart of the issue is whether or not you can write a program
that truly has only ONE blocking point within it, or not.  If you
can it is guaranteed to be responsive.  Few systems indeed can do
this, but many can be fobbed off using LWP's or the like.  If you
have them, which admittedly DNIX (like most every other Un*x in
that era) did not.  (In single-CPU systems, which most DNIX boxes
were, LWP's are just a way to reorganize the problem and offer no
inherent performance or maintainability advantage over an AIO
approach, and might actually be a performance liability.)

AIO is slightly more efficient, but it's slightly more complex
to code and understand too.

Yes, but once that step is taken the program becomes,
and generally remains, robust.

This is nice in theory, but as soon as one of ... parts
requires blocking, you need to split it into two (or two dozen)
subparts and include them separately into this gigantic switch.

Possibly.  Some sugar that the system I was referring to had
was completion handles that were part of the events, you just
indirect-called via them to subpackage handling.  The main
loop didn't need 100% of the application logic within it
at all.  So long as all blocking I/O was done via AIO the
app remained responsive.  That was easy to code-review for.

Another bit of sugar DNIX had, which NO other system I am
aware of has, was that completion queues were themselves
usable via AIO by virtue of the fact that completion queues
were just regular file descriptors, and AIO was orthogonal
on ALL fd's.  We did not use this facility, but it meant
that complex autonomous event-handling packages could be
hosted inside a complex event-handling program, WITHOUT
having to merge the code into a single event loop.  Ad
infinitum, though I'm sure performance would suffer rather
quickly.  We found it sufficient to share a single completion
queue, using a common event-handling convention.

This becomes unwieldy very quickly. BTW, main loops based on
select/poll are no different: they have absolutely the same problem.

They do; if the app is structured to do this only in one place it's
nearly the same thing structure-wise.  The presence of poll semantics
seems to encourage NOT doing this in only one place, in which case
the potential problems multiply with the quantity of poll/select calls.

AIO or select loop, async programming is inherently more difficult.

Yes.  You wouldn't use it for a stdin/stdout pipeline type of tool
of course.  Interactive programs, multi-channel servers (same thing
really), yes it's worth the initial effort.

-- 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]

Doing asynchronous loops without O_NONBLOCK does not feel right.

Agreed.  Doing asynchronous loops with a true AIO structuring
feels _very_ right.  (Keep your program state in a control
block, not in the program counter.)  The problems just go away.

-- 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]

This discussion is an illustration of why nonblocking I/O
is itself inherently evil, and shouldn't even really exist.
(It is just busy-wait polling, in disguise.)

If complex programs are instead coded in an event-driven manner,
using AIO techniques, they can work with blocking (flow-control
friendly, aka standard Unix streams) input and still work correctly,
without ever disrupting simpler tools like pipeline components.

These are pet peeves of mine, of the same sort that led to
the creation of Plan 9.  (Aka Unix cleaned up.)  The O_NONBLOCK
flag should only apply to open(2), if it even exists at all.
Sockets should not exist as something distinct from regular
file descriptors; netcat would only exist as functionality
subsumed into dd.

I have used a Unix-ey system (DNIX) that in fact worked this way,
and supported a very nice networked GUI.  It did have a robust and
general asynchronous I/O mechanism, or else it would not have been
possible.  (Actually an asynchronous blocking operation mechanism,
of which I/O was but one component.  Other components were timers,
and wait(2) calls.)

I'm not sure which would be easier to do: simplify Unix down
to its essentials eliminating a lot of bugs and bad design
along the way, or balancing the US Federal budget.

I think, however, that I will continue to breathe while I await
these desirable things.

-- Jim



-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Denys Vlasenko
Sent: Wednesday, August 17, 2011 3:17 PM
To: busybox@busybox.net
Cc: Rich Felker
Subject: Re: [PATCH] ash: clear NONBLOCK flag from stdin when in
foreground

On Wednesday 17 August 2011 23:20, Rich Felker wrote:
 I hate it when fools who don't know what they're doing and don't
 respect standards lobby for nonstandard behavior in Linux, thereby
 making the portability landscape *worse* than it already it. Instead
 try to understand why things are the way they are and just stop
 insisting on doing stupid things (like setting nonblocking mode on a
 fd you inherited).

I already asked this question and you ignored it.
So here it is again:

How can I do nonblocking read from fd 0 without
affecting other processes which might share it?
___
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] ash: clear NONBLOCK flag from stdin when in foreground

[Cathey, Jim]

I ask you how to perform nonblocking reads safely.

You can't, not 100%.

Because from where I sit, current Unix API doesn't provide
for 100% safe (wrt races) way to do it.

It doesn't; it can't.  Hence my ranting.  A 100% safe
100% orthogonal, useful easy-to-use AIO mechanism should
have been designed, and poll/select should have stayed
a bad dream in CS101.  It _has_ been done, I've seen it.
Pity nobody else really got it right.  (I've seen some
close attempts, but none of these OS's had the balls to
actually eliminate the bad mechanisms.  Maybe Plan 9 did,
I don't know too much about it other than its charter.)

-- Jim




___
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: 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: 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: 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: 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

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: 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

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: 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]

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]

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:

big-assed-file xargs -r tar -r archive

Xargs' main job is to ensure that command lines don't end up 'too big',
assuming that the command can still work if split up some.

-- Jim

___
busybox mailing list
busybox@busybox.net
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: 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: [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