[Mono-devel-list] Mono.Posix-OEE 0.2

[Jonathan Pryor]

Mono.Posix Over-Engineered Edition 0.2.

Now with complete coverage of everything that was in Syscall.

And then some.

For example, Syscall provides:

	string Syscall.getusername(int uid);

OEE 0.2 provides:

	Passwd Pwd.getpwnam (uid_t uid);

Passwd is a class which provides everything the man page says it should:
pw_name, pw_passwd, pw_uid, pw_gid, pw_gecos, pw_dir, pw_shell.

Ditto for Group, and lots of other nice things.

The same caveat in 0.1 still applies:

	- It's currently a stand-alone re-implementation.  As such, 
	  there is no support for the Syscall class.  This will be
	  done when I get off my duff and write a patch against CVS,
	  and not a stand-alone version.  Expect that after I fully
	  wrap all of CVS's exports and find good solutions to my
	  current list of questions (see the end).

The next step, obviously, is to write a patch against CVS.

Please, any questions or comments about the package would be
appreciated.


What is it?

It's an ABI-stable POSIX wrapper, which means that this Mono.Posix.dll
can be used on both 32-bit and 64-bit platforms.  It achieves this by
having a much larger libMonoPosixHelper.so library.

In short, any function which contains a non-pointer parameter whose size
is platform dependent is wrapped.  Which means anything containing
size_t, ssize_t, and off_t, among other types.  This constitutes a large
number of functions.  Furthermore, any function which uses a structure
which may have implementation-defined members and/or a non-standardized
member ordering is also wrapped (hence the passwd and group structure
support).


About the package

It has a makefile.  Unpack the archive, and build:

        $ tar xzf Mono-Posix-jp-0.2.tar.gz
        $ cd Mono.Posix-jp-0.2
        $ make

This will create a lot of .cs file, Mono.Posix.dll,
libMonoPosixHelper.so, and lots of test programs.

Main.exe is a badly cobbled test program, which calls stat(2) on all
command line arguments, printing out their information, and tries to
write "hello\n" to the file hello.txt using a PosixStream.

The write will likely fail, as the open(2) call doesn't specify O_CREAT,
so you need to touch(1) hello.txt in advance for the write to work.

mls.exe is a "managed ls" -- it's there to test readdir(3) and co.

lsui.exe "lists user information" -- dumps out the passwd structure for
a user provided as a command-line argument.

lsgi.exe "lists group information" -- dumps out the group structure for
a group provided as a command-line argument.

I wrote this on Fedora Core 2, so if it doesn't compile on your system,
please let me know so I know what portability issues to fix.  Thanks to
Charlie Ford for letting me know about problems compiling on Red Hat 9. 
These should be corrected.


Execution

Remember that Mono.Posix-OEE uses the same names as the current
Mono.Posix.  Consequently, you'll have to set LD_LIBRARY_PATH (or
equivalent) to find the newer library, and you'll have to explicitly
link against OOE's Mono.Posix.dll.


About the Implementation

The logic used is that "long" is assumed to change size between
platforms (32-bit or 64-bit), but "int" will always be 32-bits.  
Hopefully this is a sane assumption.  (Which apparently it is, except on
Crays.  I Which could get weird, portability-wise.)

As mentioned in my last email, functions are placed in classes named
after the header file they appear in.  So open(2) is in the Fcntl class.

Furthermore, C typedefs get their own types.  This feature is debatable,
and can be changed, but I thought it was cool.  Consequently, the C:

        typedef unsigned long size_t;

Becomes the C#:

        public struct size_t : IComparable, IFormattable...
        {
                private ulong value;
                // ...
        }

This can get rather tedious, so I have a Perl script which generates the
structure declarations, stub-vt.pl.  (This could also be a shell script,
or any other language, if that would be preferred.  I'm not sure what
the Mono policy regarding code generation is; I haven't heard of such a
policy, anyway.)

The "typedef" classes all support implicit conversions to their
underlying type, but require explicit conversions back.  Usage is thus:

        size_t a = (size_t) (1 + 2);
        size_t b = (size_t) (a + 42);
        // ...

I also have enough POSIX support in place to fully implement my
PosixStream class.

Enumerations now get two conversion functions instead of one from
make-map.cs: a ToManagedType, and a FromManagedType.  This allows
managed code to get unmanaged values and convert them to the proper
managed equivalent (useful for Error values, as we get the unconverted
value from Marshal.GetLastWin32Error()), as well as the previous code to
convert managed values to their unmanaged equivalent.

All API exports also follow a consistent naming convention
(Mono_Posix_whatever).

Open Questions (more to follow, I'm sure):

What's a good class to use for the conversion helper functions
(FromManagedType() and ToManagedType())?  I'm currently using Utils, but
that's likely a common name.  I'd prefer a name that's less likely to
clash with existing classes.

What's a good alternative name to use when wrapping <string.h>?  My
current naming convention would use a String class, but this is
obviously a bad choice, so currently I'm using String_h.  Any better
suggestions?  Should I modify the other classes to have a "_h" suffix
(for ".h")?  (Thus creating classes Fcntl_h, Unistd_h, Stdio_h, etc.)

I need some 64-bit OS advice.  Is it safe to assume (as I currently do)
that a 64-bit OS will provide the -64 API call?  I don't believe this is
actually safe, as open(2) and open64() should do the same thing on
64-bit platforms, so there isn't any need for open64() (except for
compatibility).

Thanks,
 - Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mono.Posix-jp-0.2.tar.gz
Type: application/x-compressed-tar
Size: 27313 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041002/cd1c562a/attachment.bin