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

[Jonathan Pryor]

Mono.Posix Over-Engineered Edition 0.3.

OK, I lied.  I'm didn't integrate with CVS after 0.2.  Instead I kept
hacking on the current code base...  So sue me.

Major Changes since 0.2:
	- C code uses typedefs for managed/unmanaged mapping.
	  I should have done this in the first place...
	- Wrapper Classes.  More below.
	- Managed structs have operator==/!= defined
	- String_h class removed in a fit of inconsistency as suggested 
	  by Joshua Tauberer (because "String_h" is just too @#% ugly).
	  Error-related functions are in Errno, signal-related functions
	  are in Signal.  We'll deal with any other imports from 
	  <string.h> on an as-needed basis (on the hopes we won't need
	  anymore imports).
	- The "Utils" class, which contained conversion functions 
	  to/from the managed values, is now named PosixConvert.

Wrapper Classes:

As a proof-of-concept for my earlier RFC, there is a set of Posix*
wrapper classes, which follow .NET conventions (PascalCasing, exceptions
on errors, etc.).  In addition to the earlier PosixStream, we have:

	- PosixEnvironment (CurrentDirectory, GetConfigurationValue,
	  GetConfigurationString)
	- PosixFile (Open, Create, SetOwner, etc.)
	- PosixGroup (GetGroups, GetMembers)
	- PosixProcess (Id, ProcessGroupId, SessionId, etc.)
	- PosixUser (GetCurrentUser, GetName, GetGroupID, 
	  GetHomeDirectory, etc.)

These are not fully complete wrapper classes, but they should be
illustrative of plausible future design.

Please see the earlier RFC [1] for how the wrapper classes should be
structured.


About the package

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

        $ tar xzf Mono-Posix-jp-0.3.tar.gz
        $ cd Mono.Posix-jp-0.3
        $ 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.

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

As mentioned previously, 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):

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).

 - Jon

[1]
http://lists.ximian.com/archives/public/mono-devel-list/2004-October/008146.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mono.Posix-jp-0.3.tar.gz
Type: application/x-compressed-tar
Size: 30389 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041004/d54ff291/attachment.bin