Hi Antti, [email protected] said: > 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?
I used the rump_sys_foo() system calls directly, that seemed like the most straightforward approach. I could call the kernel UDF driver directly, but for that I'd (presumably) need to understand the NetBSD VFS layer APIs and provide upcalls for the kernel UDF driver to be able to access the image data/block device -- is that what you meant by the latter approach? The latter would definitely be smaller -- currently using the "full kernel" approach gives me a ~1.4MB increase in size for a stripped amd64 debug build of the application -- but would increase the amount of work I need to do and space is not that much of a concern for this project. > 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). That's an interesting approach, I can see how it might be useful for other projects, and how porting the NetBSD rump kernel to Win32 would let people easily do all sorts of cool stuff. My application needs a GUI, so if I were to split off the core into a "rumprun" module I'd then need a communication channel to the GUI. This could be done with something like nanomsg or plain IPC, debatable whether it is worth the effort. > 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. That would be neat and looks like it wouldn't be too much work. It'd certainly please the HN hipsters :-) As it stands I've found the rumpkernel concept and implementation project is easy to work with and well documented, better than many FOSS projects, *especially* those involving complex build systems and components. > Anyway, that was food for thought and fancy pie-in-the-sky abstractions. > Working code is still #1. Indeed. Cheers, Martin ------------------------------------------------------------------------------ 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
