Re: more question about porting/gcc

[hyc@troy.la.platsol.com (Howard Chu)]

Just some offhand thoughts in reaction to this ...

As has been pointed out (by Peter Rottengatter, of all people!) we're not
trying to be a 100% Unix clone here. If you want that, then just boot up Linux
or NetBSD instead of TOS/MiNT.

Just because you can't port identd doesn't mean the MiNT kernel is broken.
MiNT isn't really intended as a multi-user OS. Multi-tasking, fine. I dunno
about you, but I sure am not gonna share my Ataris with anyone else. I already
own six machines; obviously just one wasn't enough for me, why would I want
to go sharing it with other users.... 

The case of identd in particular is really meaningless in the MiNT environment.
Before you set out to "port" software, you need to understand *why* you want
that software in the first place; what function does it serve? Identd tries to
tell a remote system what userid has invoked a particular network connection.
This information is inherently unreliable; when you talk to an identd server
you have no guarantee that you will get either a meaningful or a truthful
answer, even if the server is on a Unix box. Quite simply, the remote system
doesn't have to tell the truth, and you have no way to verify one way or the
other. As such, the ident protocol is pretty much worthless, in *ANY* setting.
On an Atari box, or any other single-user machine, all you need is a simple
server that always hands out the same name to every query. E.g., I could write
a server in about 15 lines of C code that always answers "hyc" to every ident
query. No mucking about in the kernel required, no intense system knowledge
necessary at all. All that's required is an understanding of the basic problem
space. This particular problem space is a worthless one, because the
information it seeks to provide is unverifiable and therefore also worthless.

  I have tried a lot of port, some fine, some NOT fine.
  The most problem I have, which I think shoudl be fixed at the lib
  level are:

  size_t in the socket.h 
  I often have (just to remove a stupid warning) have to precise
  (_SIZE_T *) for the last parameter.

  Signal() big problem most of the time.

This is the case on many Unix systems, no surprise here.

  Missing define in errno.h  such as the eternal EAGAIN, or FNDELAY.
  (and few others).

  Totally missing err.h file, so I need to hack that for every port that
  will call err.h include.

I've never heard of err.h. What standard is it specified in?

  What's the latest part of being 100% posix? are we far? VERY FAR? 
  We have the chance that mint gets updated quite often now, and the
  libs are being redone. so why not combine that to really make it 100
  posix? I understood that mint kernal had to follow, not just the libs.

  As precised in my previous email, stdarg.h is somewhat not really hmm
  reliable to work with for porting.

stdarg.h works fine. The warnings are meaningless.

  Why aren't we people trying to take a project from netbsd for example,
  and try to fix the kernal / mintlib according to that? The best we
  can.

Why indeed... Well, for starters, netbsd is a Unix OS. That's not a bad
thing, of course, I like BSD Unix quite a lot. But it certainly isn't TOS
compatible, and MiNT is. Now, if you're proposing that we go about building
a TOS-compatible runtime environment inside netbsd, I'd say, sounds like a
great idea, let's do it. But don't expect results overnight...

In fact, given something like oAESis to start from, you could probably
build a TOS/MiNT runtime environment on top of 68k Unix. Almost all of the
MiNT extensions were derived from Unix, and could be mapped directly to
Unix system calls. A lot of the GEMDOS calls could map directly as well,
leaving the usual hardware-specific crap in BIOS and XBIOS to deal with.
Being able to run TOS executables as standard Unix processes would be a
nice thing...

  A good start is ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/
  EVerything is there basically. 
  The idea being, for example:
  indentd (authd), can not compile righ out the box. Some users, I know
  will try to write personal code in there to make it to work, of course
  that will work, but didn't improve a whole lot. What I say is to try
  to adjust the libs to make netbsd (or closest os) source to compile
  with VERY little effort, without having the need to hack the whole OS<
  or by calling some personal routine to make this thing to work.

  what would it require to have fchmod?
  I mean at this level we are pretty much open. The kernal can be
  adjusted, and same regarding the libs.

  How about someone working on some libs like libutil.a ?

  Thanks 
  _____________________________________________________________________________
 ___
  Email:Kellis@primenet.com
  Web http://www.primenet.com/~kellis/
  _____________________________________________________________________________
 ___