Re: [MiNT] MiNTNet

[tlang@dialup.becom.net (Torsten Lang)]

Hi,
> 
> He is very occupied, that's it.  I'm also waiting for news from him. ;-)
> 
> Maybe I should repeat here what I already proposed to Torsten:  IMHO
> opinion the MiNTNet package should be divided into three or four distinct
> parts.  The socket drivers should go into the kernel, the socket library
> should go into the MiNTLib, the admin tools (ifconfig, route, ...) should
> make the core part of the stripped MiNTNet package and hardware and
> software drivers (plip, slip, ppp, ...) should either go into small
> packages or into one big driver package for MiNT.
> 
> I appreciate Torsten's work on MiNTNet very much but I think it is too
> much work for him alone and this has led to some stagnation.  Furthermore
> the separation of MiNTNet from the other two "central instances" of MiNT,
> the kernel itself and the MiNTLib, is unnatural (because networking is a
> central part of every Unix system) and impedes progress that is long
> overdue.
> 
> In fact, almost everybody that is running MiNT is also running the socket
> interface.  It is mostly even the main reason for running MiNT at all.
> But then the sockets should go into the kernel.  This will not only
> increase the portability of MiNT but it will also enhance the sockets.
> For example Frank and I have already started to work on a true random
> number generator for the kernel.  This is not only useful for crypto
> software that likes to see /dev/random but also for generating secure
> sequence numbers for the TCP/IP stack.
> 
> I must admit that the main reason for my proposal is the development of
> the MiNTLib: I have Kay Roemer's ok to integrate the portlib into the
> MiNTLib (which will avoid a lot of problems when porting software) but I
> currently can't do that.  The portlib requires the socket lib (because it
> needs the header files) but I don't think that it would be a good idea to
> make the MiNTLib (the "base lib" of our system) depend on any other
> library.
> 
> There are also some functions in the MiNTLib that would work more reliable
> if the code could rely on the socket lib (at least its header files), some
> functions cannot be properly implemented because of that.  For example,
> the MiNTLib can never #include <paths.h> because that header file belongs
> to the portlib.  Or take MAXHOSTNAMELEN.  The MiNTLib and the socket lib
> should have a common notion of the maximum hostname length but this is not
> guaranteed as long as they don't share a common set of header files.
> 
> It is possible to keep all socket lib sources in a separate subdirectory,
> it is even possible to still build a separate lib for it instead of
> integrating it into the libc (although I don't see any good reason for
> that).
> 
> I would propose that Torsten tries to do a release soon (no matter
> if it is stable or not) and we then chop MiNTNet into palatable pieces.
> For the MiNTLib this is really somewhat urgent now.
> 
this sounds very sensible to me. I would propose to first integrate the
ip masquerading feature and the preliminary bugfix for the land problem
(and maybe a new ethernet driver where I will get hw within the next days) and
then freeze the functionality to do the splitting. Things like IPV6 are too
heavy to implement now and an autodialer (also an important item on my wish list)
will go into the ppp-driver itself which I would do after splitting the package.

Regards,
    Torsten

BTW, I'm reading my personla mailbox once every upto every two weeks, so there's
no reason to be impatiant/impolite. Important things concerning MiNT-Net should
go not only to the mailing list but also to my private address since it may
happen that I sort out mails from the list concerning me simply because I can't
take a very close look to every of ~200mails I find regularly in my box...