>    Actually, OS people have done this A LOT.  Just look at L3.
>    Microkernel dudes have put out plethoras of papers on reducing system
>    call overhead, particularly since their system calls require two
>    kernel-boundary crossings.

Oh yeah, before someone corrects me, I meant 4 crossings total :)

> Then why are the BSD camps and the SVR4 based unices still doing it
> the original broken [sic] way if the literature makes it so obvious that
> this is not the way to do it as you have just mentioned?

Not sure.  Your question would be better answered by them, not me.
I'm not even much of a kernel hacker (yet) - just sort of reading
papers and "doing my homework" as it were - _before_ I start coding.

> You sir have not even glanced at our
> implementation and how it really works before making your statements.

You're right.  I was shooting from the hip based on flawed assumptions,
and didn't think I needed to check the source code.
I was under the impression that standard, compiled C pulled the arguments
from the stack under all situations.  I figured the trap code in BSD unix
was copying stuff into a stack that was set up for the call to the C
function.  This would not seem to be the case.  In fact, the unpacking
of the uap structure _is_ done manually.
Since it isn't the case, I guess there's no need to jump through hoops
to simulate passing arguments by register.  Oops :)

How's that for admitting defeat graciously?

> Larry McVoy has even stated the above publicly.

Not sure who this guy is.

> Yes, but the C standard allows extensions as long as the compiler
> allows one to specify that these extensions are all turned off and
> only ANSI C features are allows in the input code.

Yes, but a C compiler isn't non-compliant if it doesn't implement a
particular extension.  "broken" implies to me "non-compliance"
or at least "it doesn't work".  I think you're exaggerating
to prove your point.

> This says something about the corporate development model, it sucks
> and it does not work efficiently.  This is why the free software model
> is going at such a rapid pace and will indeed take over
> eventually. (mark my words, and there are many people, some of whom
> are in major corporations now, who defiantly agree whole heartedly
> with me on this)

In fact, I really like realeasing software free of any restrictions
on its use or distribution.  You're preaching to the choir, brother Dave.

> See above, the Linux method is portable.  You are wasting your time.
> We use the standard linkers and compiler output to do system calls the
> way we do.  No special magic at all, all of which is very straight
> forward and clean and portable.  Please, once again, I urge you to
> actually look at how Linux implements things before shooting off your
> mouth about what is so bad or wrong about it.  I have looked at the

Okay, fair enough.  I looked.  It looks more efficient.
It's cleaner and as portable as the other way.  I assumed the backends
were written in assembler partially because I didn't believe things
were done in an inefficient manner for no reason.

> I am too, but only if people are going to do their homework and not
> approach me with "Linux must be broken and unportable, lets come up
> with a new way without even checking out how the Linux implementation
> really works"  this is insulting to me and others who have looked
> deeply into these problems and have considered all existing ways
> including Linux's, such as Larry McVoy who has been doing this for
> years.

The Linux source wasn't handy from where I was when I composed the article.
Sorry you took it so personally.
You must have a lot of ego tied up in the operating system you use.

However, you should be aware that you are guilty of the same crime when
you stated:

>    You'd think that when people put together function call conventions
>    for a particular processor, the OS people would take a look at this
>    and find a way to take advantage of this.  In fact, believe it or
>    not, they have not to this very day.

But that's okay, I'm not insulted.

http://www.inf.tu-dresden.de/~mh1/l3/
  Jochen Liedtke: Improving IPC by Kernel Design (appeared at SOSP14)
  I think you'll find there's a fair amount of the same sort of measuring
  that you have done.  Focus is on IPC but many things apply to any
  system call.  Lots of x86 details.

There are several more, but the basic starting point should be:
http://www.cs.arizona.edu/people/bridges/oses.html