[email protected] said: > On 28/01/15 11:47, Martin Lucina wrote: > > [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. > > Can you point to the line(s) of code where __RUMPRUN_XEN__ is required?
No, I can't. Lets drop it. > > 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. > > No, we cannot feasibly take it out after it goes in without breaking an > unknown amount of code outside of our jurisdiction. Having an excessive > amount of unnecessary platform macros leads to sloppy code (I keep > fixing things in NetBSD due to the abuse of _RUMPKERNEL). So let's not > put __RUMPRUN_XEN__ in until there is _one_ case demonstrating the need > for it. Ok. So, do we have consensus on the following names? Macros: -D__RUMPRUN__ -D__NetBSD__ Autoconf: $ARCH-rumprun-netbsd App-tools: rumprun-xen-* Ok to rename or shall we wait some more to see if anyone else speaks up? It should not affect osstest builds since AFAIK those don't use app-tools. 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
