[Toybox] PM: code style, was: Re: New Subscriber

[Frank Bergmann]

Hi.

On Wed, Feb 08, 2012 at 11:59:43AM -0600, Rob Landley wrote:
> Somebody Else's Problem. I'd rather not have "libc's stdio sucks" on my

Just in case that you maybe misunderstood me: I'm trying to say that you
don't use the full power of stdio. Maybe you could enable at least line
buffering and read whole lines with scanf. Maybe it can substitue reading
one char at a time. I don't know, I'll have to read the stdio docs again.
I also don't know current implementations in C-libs.

> The actual cache lines faulted in are another matter, but if you make a
> lot of syscalls at least the entry point tends to stay in L1, and beyond

Ah! This is the answer. I thought that at least the entry point would be
seldom in l1 cache.

> CPU cycle counter.  Run it on a quiescent system and see how many cycles
> it took.  (The phrase to google for is "linux microbenchmark" or
> something like that.)

I know.
On all projects running on 32 but Intel I have this line in the central .h
file:
#define rdtscl(low) __asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx")
But you still have to do many test runs to get useful results on a system
with many tasks.

> You have to understand what the system is doing.  You also have to
> realize that different hardware works in different ways.

Running my software on different embedded platforms and getting
immediately errors like segfaults (i.e. on Linux/atmel) teached me some
experiences. ;-)

> The horror is indescribable.  But I tried in my blog...

I already thought of you as a fan of horror movies after the last post. ;-)

> I hate that error. There is nothing WRONG with type-punning a pointer,

One of the things programmers like is to satisfy compilers. ;-)

> my life.  (I don't care about the performance change, IT'S VALID C!)

Are you sure? For K&R I'm sure that it is but IMHO c99 "requires" the
usage of void in this case (using char** as char*).

> >> command line stuff.  It's only a win if you never have to do it more
> >> than once.
> > 
> > That's why I often used small internal output buffers and the nasty
> > stpcpy.
> 
> What's nasty?  It's in POSIX 2008.

You're not the only one who was surprised because of that.
("nasty" because I thought it was a GNU extension of the lib with msdos in
history.)

> The internal implementation of that syscall is disgusting, because it
> has to examine and potentially modify the state of every process on the
> system.

Sure but in i.e. initrd it means mostly two or three processes. Of course
it is disgusting and only useful in rare cirumstances but we have a
syscall and we are writing userspace software. :-)

>   http://landley.net/notes-2011.html#02-06-2011

http://www.tuxad.com/ngtx/ngtx-current/tools/breakout.asm
:-)
(Of course you need the capability to break out.)

> Note that adjusting the process-local mount tree wasn't possible until
> A) there was a process-local mount tree, B) --bind mounts had been
> invented so you can split a mount point.

*shudder* some weeks ago I had to deal with some big servers with dozens
of containers and even more bindmounts and kernel of the early 2.6.2x
series with no full bindmount support.

But what I doesn't understand right now: Are you fighting against
pivot_root? I just mentioned it as a starting point for me.

> I have plans for that one and would like to do it myself.

unmount is left. ;-) I'll peek into the list again.

> Note that the common thing about all three of those?  Available free on
> the web.  If it's not available free on the web, IT ISN'T A STANDARD.

... and it is expensive. ;-)

> Nope, it makes sense.  The implementation is trivial:

Of course. Before I "detected" it I'd written my own function. But like
you I searched for a "standard function".

>   http://landley.net/history/mirror

Bookmarked. I'm glad to see that you did mention "Space Travel" (not Space
Wars like Linus wrote). :-)

> Fabrice Bellard (the creator of tinycc and qemu) wrote i386 emulator,

He is already carved in stone in the history of computers. :-)

> You said that printf() violated an early unix maxim, but there's another
> one: "When in doubt, use brute force".  Implement, _then_ optimize.

It was MAYBE breaking a rule by Doug McIlroy! ;-)

BTW - if you're interested in computer history: Do you have a (valid)
source for this Kernighan citate? In the Bell Labs documents I did not
found it.

Frank

-- 
EDV Frank Bergmann                           Tel.     05221-9249753
LPIC-3 Linux Professional                    Fax      05221-9249754
Pödinghauser Str. 5                          email    iservice at tuxad.com
32051 Herford                                USt-IdNr DE237314606

 1328774781.0