On Fri, Nov 23, 2001 at 05:28:14PM -0500, Roland McGrath wrote: > As Marcus explained, this is just historical cruft. For your project, I > think you would be better off starting with oskit-mach. I have cleaned up > and removed a lot of random cruft there.
Do you really think I would be better off starting with oskit-mach? Note I do not assume that I must fork the code base. What I've built so far on GNU Mach has been carefully non-destructive. Mach seems fairly content to be ported from the i386 to the OTOP "systype". I'm not so sure whether OSKit-Mach will allow itself to be ported away from the OS Kit. Are you willing to consider patches that abstract out all OSKit dependencies into the oskit directory or conditional sections? To quote Pavel Roskin: forks are bad. What else have you cleaned up, apart from deleting the Linux and Mach device support? I kind of like the Mach support, since I can be confident that most of what's outside of i386/ is generic. Essentially all I've had to change has been related to header clashes. > Also, the oskit module interfaces > are designed for exactly the kind of different-hosting concept that you are > working on. Do you mean that I should reimplement the interfaces, essentially porting the OSKit to POSIX instead of porting Mach to POSIX? Then it would be Hurd/Mach/OsKit/GNU/Linux. This may be viable if your OSKit-using code makes as few assumptions about "kernel mode" and i386 as do the generic parts of GNU Mach. But I have essentially completed this work already using GNU Mach. What is the big picture for oskit-mach? Right now it lets you use newer drivers, so it effectively extends the Hurd's hardware compatibility (as would Mach OTOP). But my impression is that the deliverable Hurd "product" that is our ostensible goal has no plans for OSKit-Mach. In other words, OSKit-Mach is a tool for facilitating development (like Mach OTOP, potentially), and all of this development works towards creating a viable platform on GNU Mach. (Unless L4 makes big strides.) (Of course, Mach OTOP expects to be slower than OSKit Mach. But it also expects to be apt-get runnable. No more rebooting for native-install, perhaps?) I'll be happy to modify the oskit-mach branch to support OTOP, but only if doing so will improve the likely ease of benefitting from future improvements, as compared to the GNU Mach approach. Thanks for your help. -John -- John Tobey <[EMAIL PROTECTED]> _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
