[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MiNT] MiNTNet
- To: MiNT mailing list <mint@fishpool.com>
- Subject: [MiNT] MiNTNet
- From: "Guido Flohr" <gufl0000@stud.uni-sb.de>
- Date: Wed, 26 May 1999 21:10:34 +0200
- In-reply-to: <Pine.MNT.4.05.9905270142010.108-100000@tos>; from Mario Becroft on Thu, May 27, 1999 at 01:51:10AM +1200
- Mail-followup-to: MiNT mailing list <mint@fishpool.com>
- References: <Pine.MNT.4.05.9905270142010.108-100000@tos>
- Sender: owner-mint@fishpool.com
Hi,
On Thu, May 27, 1999 at 01:51:10AM +1200, Mario Becroft wrote:
> On Wed, 26 May 1999, Frank Naumann wrote:
>
> > That's wrong. If he doesn't interested we make our own version.
>
> I am not sure what you mean. Are you saying that Torsten is not interested
> because he is making his own version of IP masquerading ?? Or are you
> saying that you will distribute your own version of MiNTNet?
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.
Ciao
Guido
--
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de