On 25/09/14 08:41, Martin Lucina wrote: > This is all still up in the air but if it happens it'd be the former - > native win32. And yes, I anticipate that mucking with the build system / > object file format would be the boring bulk of the work.
Welcome to the club, 50% of my life is fighting with build systems ;) > In other news, it took me about a day to port from UDFtoolkit to using the > rump kernel UDF implementation, so far so good :-) Cool. Though, strictly speaking, we should call it the NetBSD UDF implementation. (the whole point of rump kernels is to make kernel drivers reusable in a variety of environments, otherwise no way we'd have the resources to provide even a fraction of the current drivers) Anyway, if I'm allowed to expand on the subject a bit, some food for thought. Did you port UDFtoolkit by replacing the system calls with rump_sys_foo()? Or do you actually directly call the kernel UDF driver? If the former, you could also consider to "rumprun" your software. What happens with rumprun is that you run the entire NetBSD software stack (libc included) on top of a rump kernel. For example, if your application would require a lot of #ifdef __WIN32__, those are rendered unnecessary, since the application is not running on win32. The rump kernel is of course still running on win32, and you need specific win32 support there (rumpuser, object format), but you'll need that in any case. What's cool about using the rumprun approach is that now your software will run directly anywhere where there is rump kernel support (including userspace, Xen, KVM, VirtualBox, bare metal, ....). Of course, there are still things to polish especially with the rumprun build systems, some extra limitations are placed on the application (no fork or exec), and some possible GUI limitations (which I haven't thought about at all). However, if rumprun suits your application, it's a pretty powerful paradigm. I'm hoping some day we can offer Docker-like icing for rump kernels, making all of what I described easy to accomplish for generic applications. Anyway, that was food for thought and fancy pie-in-the-sky abstractions. Working code is still #1. - antti ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
