On 06/28/2013 09:42 PM, Stas Sergeev wrote: > Well, but you wanted to embed slirp anyway, and haven't > started that yet. So maybe it would be the same cost to > evaluate the embedding of slirp and the cost of embedding > vde? :)
In fact, I don't think embedding slirp is a good thing anymore. I finally managed to compile the latest version of slirp on my system, by changing a few declarations here and there, but turning it into a self-contained library is not as simple as one might think - there are plenty of global variables and alike, which would potentially bring chaos to dosemu. Also, embedding it just for the sake of having a single binary is probably not a reason good enough (that's why I was suggesting keeping a separate binary). Anyway, embedding vdeslirp might be a good direction for DOSemu (from what I have read it does at least as much as librouter do), but since I am personally not interested in it, I will let other contributors contribute in this direction. :) >> For example having files like: >> /usr/bin/dosemu.bin >> /usr/bin/dosemu.slirp > We can also package slirp separately and ask the user > to install an extra package if he needs slirp. This makes sense, too. Actually, it would be a matter of providing a generic 'slirp' package (not necessarily related to dosemu). As you noticed yesterday, very few distros provide such slirp package, which is really unfortunate. > dosemu.slirp is not extremely good, as there can then > appear also qemu.slirp, vbox.slirp etc. Yes, I agree that redundancy is wrong here. It's better to keep things clearly identified, and use the right tool for the right job (as dictates the unix philosophy). :) cheers, Mateusz ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
