cruft and forks

[John Tobey]

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 <jtobey@john-edwin-tobey.org>