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

[Jonathan Pryor]

Mono.Posix Over-Engineered Edition 0.5.

Major Changes since 0.4:
	- 64-bit oversights (oops).
	- Overhaul the Enum Mapping Mechanism (again!)
	  - Previously, if there wasn't a mapping from a managed enum
	    to a native value, the managed value was passed through
	    unchanged.
	  - Now, we explicitly check (as much as possible) for a correct
	    mapping between managed <-> native.
	  - This allows managed code to use platform-specific values
	    (e.g. O_LARGEFILE), and determine at runtime if those values
	    are actually supported.
	  - I *really* need to clean up make-map soon.  It's unreadable.
	- getgrent(3) wrappers
	- Re-organize PosixFile and PosixDirectory to be more similar to
	  System.IO.
	  - There's now a PosixFileSystemInfo, PosixFileInfo, 
	    PosixDirectoryInfo, and PosixSymbolicLinkInfo classes.
	  - PosixFileSystemInfo basically a .NET-like wrapper for 
	    struct stat, with some sensible methods (SetOwner, etc.)
	  - PosixFile and PosixDirectory are simple wrappers of these.
	- Did the same to PosixUser and PosixGroup.
	- Exception mapping.  This still needs work, but error numbers
	  are mapped to a managed exception.  For example, ENOENT is
	  FileNotFoundException.
	- Wrap more POSIX functionality (PosixEnvironment.MachineName,
	  GetConfigurationValue (sysconf), 
	  GetConfigurationString (confstr), etc.
	- Wrap posix_fadvise in PosixFile, PosixStream
	- lsui.exe and lsgi.exe now list all local users/groups if no
	  command arguments specified.

Mono.Posix OEE should now offer all the functionality (and then some!)
of Mono.Posix 1.0.

The Future

I should integrate this into CVS.  I keep saying that, then adding more
improvements...

At present, it looks like minimal compatibility will be maintained with
Mono.Posix 1.0.  Why?  Sanity and correctness.

POSIX declares getuid(2) as:

	uid_t getuid(void);

Mono.Posix 1.0 declared getuid(2) as:

	public static extern int getuid ();

However, under GLibc uid_t is an unsigned 32-bit integer.  OEE declares
it as:

	public static extern uid_t getuid ();

As uid_t is a struct, if `uint' is found to be non-portable in the
future, we can change the uid_t declaration without breaking API
compatibility.

There are similar collisions to getuid(2) (getiuid(2), getegid(2), plus
name collisions, such as Stat and Passwd...)

If we wish to maintain compatibility with Mono.Posix 1.0, we would need
to find some way of avoiding the conflicts.  This involves one of:

	- Different class names.  Syscall seems to be preferred.
	- Different method name.  What would be a good convention?
	  getuid2()?  getuidEx()?

I discussed this to some extend on #mono, and no adequate solution was
found.  (Lots of interesting solutions, such as using standard names for
class names, e.g. Unix98, were suggested, with inheritance between
classes, so Unix03 : Unix98, but this was deemed too cute.)

Furthermore, miguel stated that we could claim that Mono.Posix wasn't
really ready to begin with, providing an argument to dump Mono.Posix 1.0
compatibility.

An alternate approach is to provide Mono.Posix OEE in a different
assembly, and deprecate Mono.Posix.  I'm open to new assembly name
suggestions if this is the preferred approach.


About the package

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

        $ tar xzf Mono-Posix-jp-0.4.tar.gz
        $ cd Mono.Posix-jp-0.4
        $ 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, most functions are placed in Syscall, while C
standard library functions are in Stdlib.  In the interest of
"cuteness", Syscall derives from Stdlib, so all Stdlib methods are
present in Syscall (allowing you to use Syscall.free(), and permitting a
flat namespace which some have requested).

If you don't like this convention, *please* suggest a better one.  (One
header : One class wasn't liked by many, and Miguel doesn't seem to like
everything in Syscall, so I'm flying by ear here...)


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

Thanks,
 - Jon

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