For something like this, instead of trying to do a high fidelity mapping of the low level APIs that you would call from C# and then do the abstraction work from C#, I would instead do the heavy lifting in C, provide the abstraction there and surface a simple API to C# which you invoke there.
Miguel On Friday, January 1, 2016, Jason Curl <jcurln...@arcor.de> wrote: > > On 2016-01-01 13:17, Miguel de Icaza wrote: > >> Re-reading your original question makes me wonder if you really need >> something as heavy handed as the approach on Mono.Posix. >> > > Specifically I will port my .NET implementation > http://serialportstream.codeplex.com to Mono on Linux, but why stop > there? I would further consider BSD socket networking code which is much > more complicated (especially obtaining interface names). > >> >> The challenge that Mono.Posix faces is that the structures exposed in >> each Unix is slightly different (different location for fields, different >> data types for fields), so Mono.Posix resorts to defining its own >> interface, say instead of using "struct stat" and trying to have one >> universal implementation that works across many different Unix systems - it >> instead defines a "struct MyStat" which has well known fields at well known >> locations with well known sizes. >> >> I've experience in writing portable code with the help of Autotools on > Solaris, FreeBSD, Linux, Cygwin and QNX, all of which have their own quirks > as you've needed to solve with Mono.Posix. > > Then the C glue maps between those two. >> >> But in your case, it is not clear if you are trying to bind libc and >> their structures, or trying to bind your own C library that already has a >> stable ABI. If you are coping with the latter, you do not need a setup as >> tedious as the one that Mono.Posix does, you merely need to ship your >> native library for each platform you intend to support and your C# code >> that calls into it. >> > > I've not started the port of my project to Unix and so have no library > already. I will write one though, as it seems the solution that Mono.Posix > has taken. It also appears the only /portable/ way that I can take without > having to make assumptions about structure layouts. > >> >> Miguel >> > > I took a further look at DllMaps, and while I haven't started/tested yet, > I believe this can simplify effort by allowing me to having one native lib > per architecture and a single .NET class that "standardizes" the interfaces > I need. > > I'm still researching the best way. Right now, I'm planning on having a > Cmake/Autotools project to build my library for the platform, use DllMaps > to let the Mono runtime pick the appropriate native library when running if > OSVersion is Unix (etc.) > > Do you have time to highlight how the MapAttribute works in Mono.Posix? > > Thankyou for your support, > Jason. > >> >> On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl <jcurln...@arcor.de <mailto: >> jcurln...@arcor.de>> wrote: >> >> Thank you Mr. Icaza. >> >> Is there more information on what uses the MapAttribute than >> what's in Syscall.cs? Even though it's internal and I won't use >> it, I'd like to understand how you solve the problem of ABI >> compatibility. >> >> I'd like to set up a solution where copying the files from one >> architecture to another simply works (assuming all dependencies >> from the runtime are present), and the runtime/mylib chooses the >> most appropriate native library (based on OSVersion and >> Syscall.uname) for all supported platforms. Something like: >> * MyLib.dll (assembly) >> * MyNativeLib.Linux.x86.so <http://MyNativeLib.Linux.x86.so> >> * MyNativeLib.Linux.x64.so <http://MyNativeLib.Linux.x64.so> >> * MyNativeLib.FreeBSD.x86.so <http://MyNativeLib.FreeBSD.x86.so> >> * MyNativeLib.Darwin.x86.so <http://MyNativeLib.Darwin.x86.so> >> * MyNativeLib.Win.x86.dll (windows native) >> * MyNativeLib.Win.x64.dll (windows native) >> * MyNativeLib.[dll|so] (backup for local builds) >> >> Your solution (Mono.Unix.Native) looks different, more compact, >> but I'm not sure if/how it supports side-by-side. My solution >> requires a lot of work, duplicate code with small changes in >> defining the structs/DllImports with different offsets and library >> names. >> >> I've yet to look into the Dll mapping mechanism of Mono if that's >> also suitable. >> >> Thank you very much and for giving me the opportunity to use Mono. >> >> Regards, >> Jason. >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list