[email protected] said: > I suggested thinking critically about if it's necessary.
"normal" user applications should not need to know or care if they are running atop Xen, KVM/Bare Metal or something else. However, as Wei Liu's case with building Xen libxc on rumprun-xen shows, some "low-level" applications do need to make these decisions. > Now that I look at your list, the same goes for the autoconf vendor > string. Actually, the autoconf string is in need of even more critical > thinking, since we can always add -D__RUMPRUN_XEN__ later, but if > there's some case where need "xen" in the autoconf string, we're out of > luck. > > That said, I'd prefer to see just a generic rumprun identifier in both > cases, if critical thinking does not yield other results. I think using just the generic identifier will be enough. Most build systems can make decisions on whether or not to build specific modules based on the presence of a preprocessor define. Therefore, the presence of "xen" (or "bmk") in the autoconf target string is redundant. Regarding -D__RUMPRUN_XEN__, I would like to keep this as I can see it being useful for configuration/provisioning code common to both xen and bare metal. > While you're renaming, should we start calling app-tools rumprun-tools? Not sure. It feels better to say "app-tools for rumprun-xen needs X" as opposed to "rumprun-tools for rumprun-xen needs X". Martin ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
