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 _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
