[Simh] ANDROID 7.0 .... simh "make vax" error....

[Mark Pizzolato]

On Sunday, September 2, 2018 at 12:20 PM, Johnny Billquist wrote:
> On 2018-09-02 20:09, Mark Pizzolato wrote:
> > On Saturday, September 1, 2018 at 7:31 PM, Mark Abene wrote:
> >> Yes. Depending on context, one would use either of FNDELAY,
> >> O_NDELAY, or O_NONBLOCK, for clarity.
> >> In reality, they all mean the same thing. See
> >> /usr/include/x86_64-linux-gnu/bits/fcntl-linux.h to see why
> >> that is.  In the case of android, try O_NONBLOCK, or try using
> >> ioctl instead of fcntl (FNDELAY doesn't exist on android, so use
> >> one of the other names).
> >
> > Thanks for that pointer.  Implied there is that the FNDELAY comes
> > from some desire for BSD compatibility which it seems reasonable
> > for Android not to be too worried about.
> 
> Not only that, FNDELAY is supposed to be kernel internal only.
> Apparently there was some version who accidentally exposed it, and to be
> compatible, it's been defined/exposed since, but no code should really
> ever use this.

There was a difference section of code in sim_console.c which explicitly is
#ifdef'd for BSD using fcntl and ioctls instead of the termios that is used in 
Linux.   The BSD code goes back to 2001.

> Linux seems to think it should be mapped to O_NDELAY, while looking at
> NetBSD, it is mapped to O_NONBLOCK.

On Linux (at least for Intel), FNDELAY, O_NDELAY and O_NONBLOCK are all 
the same value (0x800).  On NetBSD 7.0 and OS X they are all the same value (4)
.
> I think it's wise to totally remove any reference to FNDELAY. It is
> never the correct value.
> 
> One could then argue what the different is between O_NDELAY and
> O_NONBLOCK, but that's a different story.
> 
> > The recent change (adding FNDELAY) was added to accommodate
> > a different Linux platform which didn't honor the termio setting of
> > VMIN=0 and VTIME=0 settings which define non blocking I/O.
> 
> How about instead using O_* macros, which are the ones intended to be
> used here...
> You must have dug around some to even find FNDELAY...

Well, I saw the BSD code and just copied the fcntl() logic and it worked (i.e. 
had no negative effects on the Ubuntu Linux I tried) and the resulting
binary worked on the Ubuntu Linux and in the 'other Linux' platform.
The 'other Linux' platform was WSL (Windows Subsystem for Linux).
This is a Windows facility which can run Linux user mode code binaries
directly with an internal implementation of many/most/all system calls.

Now that I've looked closer at the definitions of O_NDELAY and 
O_NONBLOCK, using O_NONBLOCK seems most appropriate since the 
code that calls read() a expects -1 return when read doesn't return 
anything.  

It has now been change to O_NONBLOCK in both the BSD specific and 
Linux code, and for the BSD code, if O_NONBLOCK isn't defined it defines 
O_NONBLOCK as FNDELAY which is potentially the right thing for any older
BSD that might not define O_NONBLOCK.  Additionally, the status return 
checks now only look for 1 indicating a successful read, so either 0 or -1 
means no data read.

- Mark