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

[vince]

_______________________________________________
Simh mailing list
***@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Mark Abene]

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).
I can't see the surrounding code, so there may be a bit more work involved.

-Mark

can anybody help here ? ..... V
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Mark Pizzolato]

Post by Mark Abene
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.

I was surprised that Android's termios sys calls didn't support
TCSAFLUSH, so we had to switch to TCSANOW on Android.

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.

Post by Mark Abene
I can't see the surrounding code, so there may be a bit more
work involved.

Nope. The name change was all that was needed.

-Mark

Post by Mark Abene

can anybody help here ? ..... V

[Johnny Billquist]

Post by Mark Pizzolato

Post by Mark Abene
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.

Linux seems to think it should be mapped to O_NDELAY, while looking at
NetBSD, it is mapped to O_NONBLOCK.
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.

Post by Mark Pizzolato
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...

Johnny

[Mark Pizzolato]

Post by Johnny Billquist

Post by Mark Pizzolato

Post by Mark Abene
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.

Post by Johnny Billquist
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)
.

Post by Johnny Billquist
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.

Post by Mark Pizzolato
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

[Mark Pizzolato]

I have tried several other hardware platforms – Android (6, 7, ?), viz;
O Xiaomi M3 result: make vax works fine. Even tried to boot
vax – failed but that was because I have not figured out how to get the VMS.iso
in the environment
O Oukitel result: in discussion
O Samsung result: same as Oukitel

In all cases, if you get the >>> prompt, things are running fine.

As for getting your ISO file into your phone... Use wget, curl or some other network access method.

- Mark

On 3/9/18, 4:10 am, "Simh on behalf of Mark Pizzolato" <simh-

Post by Mark Abene
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.
I was surprised that Android's termios sys calls didn't support
TCSAFLUSH, so we had to switch to TCSANOW on Android.
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.

Post by Mark Abene
I can't see the surrounding code, so there may be a bit more work involved.

Nope. The name change was all that was needed.
-Mark

Post by Mark Abene

can anybody help here ? ..... V

_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh