[uClibc] Hyperstone E1-32X Port for uClibc-0.9.19

[George Thanos]

Dear Erik, list,

I would like to announce the porting of uClibc v 0.9.19 for the 
Hyperstone's E1-32X architecture. A parallel port of uClinux-2.4.x and 
uClibc took place by Hyperstone (www.hyperstone.com) and GDT 
(www.gdt.gr). The uClinux E1-32X sources are already in the uClinux CVS 
repository under the name "e1nommu".

We would also like to publicise our uClibc port by uploading it to the 
uClibc CVS. How this can be done? Should I send a patch file or a 
tarball with the architecture dependent files?

There are are also two(2) minor changes in architecture independent 
files. How should we handle them? Should we provide an additional patch 
for those files along with a README file for the end user on how to 
apply the patch.

Downloading a recent version of uClibc-0.9.19 (We have been working for 
a long time with an older CVS instance) I found a error related to the 
open system call.

While the prototype of open in include/fcntl.h takes a variable number 
of parameters the actual implementation receives a fixed number of 
parameters. In some architectures that the compiler handles differently 
a fixed and a variable list of arguments both in the calling and the 
called function this can be a problem and parameter passing can be 
totally wrong.

To be a little more specific on the problem, our architecture affords 
two separate stacks in the same user level process. When using a fixed 
number of parameters the compiler passes arguments through the 1st 
stack, while when using a variable number of parameters the compiler 
passes arguments through the second stack.

When the prototype indicates a variable parameter list the calling 
function passes parameters through the second stack, but the called 
function that is build with a fixed number of parameters receives 
parameters through the first stack. This gives an impression of the 
mess. The result is an unexpected and severe kernel crash.

In the previous instance of uClibc both open's prototype and 
implementation took a variable number of parameters and did not cause 
any problem!

Are there any other system calls that have a variable number of 
parameter list in their prototype but a fixed list in their 
implementation? I would like to check similar problems before we provide 
our sources along with the required patches for the architecture 
independent files.

Cheers,

- George