[OpenIndiana-discuss] nonblocking i/o problem
Based on an assurance
[https://wiki.illumos.org/display/illumos/illumos+FAQs, Is illumos
compatible with Solaris/OpenSolaris?] that OI-hipster was upward
binary-compatible with S10 and that any discrepancies were to be
reported, and some S10 exploits becoming more widely known, I upgraded
from Solaris S10XU8 to OI-hipster-2016.10. There was some teething,
and one thing I still haven't resolved is an S10 binary that works right
in S10 and wrong in OI regarding non-blocking reads of stdin. It
happens to be my main project, of course...
truss, in short, says:
Solaris X86 S10U8
fcntl(0, F_GETFL) = 2
fcntl(0, F_SETFL, FWRITE|FNONBLOCK) = 0
read(0, 0xFD7FFF0C0028, 4096) Err#11 EAGAIN
fcntl(0, F_SETFL, FWRITE|FOFFMAX) = 0
Openindiana-hipster 2016.10
fcntl(0, F_GETFL) = 8194
fcntl(0, F_SETFL, FWRITE|FOFFMAX|FNONBLOCK) = 0
read(0, 0xFD7FFF0C0028, 4096) = 0
fcntl(0, F_SETFL, FWRITE|FOFFMAX) = 0
Does anybody know why the behavior is different, and how to get the
former under OI. I expect there is some library difference somewhere.
I've been poking at tcsetattr to tweak this, and the best I can do is
see 4 characters get queued up before the program gets them (S10U8 does
that with different termios flags, too). read() returning 0 instead of
EAGAIN is interpreted as EOF and the program quits, rather clumsily.
--
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel. -Crow on solitaire
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] nonblocking i/o problem
On 04/ 5/17 10:16 AM, Jeff Woolsey wrote: Based on an assurance [https://wiki.illumos.org/display/illumos/illumos+FAQs, Is illumos compatible with Solaris/OpenSolaris?] that OI-hipster was upward binary-compatible with S10 and that any discrepancies were to be reported, and some S10 exploits becoming more widely known, I upgraded from Solaris S10XU8 to OI-hipster-2016.10. There was some teething, and one thing I still haven't resolved is an S10 binary that works right in S10 and wrong in OI regarding non-blocking reads of stdin. It happens to be my main project, of course... You can first state What Openindiana are you using, since reporting bugs or RFEs is best done installing/updating to Openinidiana hipster rolling-release and updating to newest hipster, that includes newest illumos and oi-userland. Then you can figure what osnet-incorporation and userland-incorporation is installed (pkg list | grep) so that eventually bug can be reproduced if there is one. That notice on illumos FAQ is a bit old, and you can post a bug report to illumos itself to clarify it. Probably that goes for illumos as far as illumos part is concerned, but not for Openindiana. What is known to work is that you can count on Solaris 10 compatibility only if you run S10 Branded Zone (Solaris Zones), and as I know BZ for S10 is left at the state of S10 at the time when Opensolaris is forked to not-source-releasing. (u8 I think but don't hold my word). It would be actually needed and interesting to try out S10 branded Zone in newest Openindiana /hipster and to document it so to know how and does it works today. Openindiana that exists in old "/dev" publisher, used to be compiled with SunStudio compiler, and since availability of proprietary compiler good enough for both illumos and userland compilation is problematic, everything moved afterwards to GNU compiler. So another possible target for creating Branded Zone for compatibility is actually "old /dev" Openindiana releases that could also provide some level of compatibility with older (Open)Solaris binaries. (beside obvious ways of running older OSes in VirtualBox or under Intel EPT/KVM) So you can try using S10 Branded Zone under OI/ipster (system/zones/brand/s10), and crating new BZ for OI/old dev, would be happy to try to document it if it works right. Otherwise, if you think it is only illumos-related, after reproducing on newest illumos coming throught OI /hipster , report it to illumos. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] nonblocking i/o problem
On Wed, Apr 5, 2017 at 9:16 AM, Jeff Woolsey wrote: > Based on an assurance > [https://wiki.illumos.org/display/illumos/illumos+FAQs, Is illumos > compatible with Solaris/OpenSolaris?] that OI-hipster was upward > binary-compatible with S10 We probably need to fix the FAQ clarify the conditions under which that is actually true. As an aside, there are limitations. The conditions were always pretty strict, so that compatibility only applies to (a) Solaris itself, and (b) only those interfaces explictly marked as being compatible. This explicitly excludes any 3rd-party applications and libraries that are shipped with Solaris, and as of Solaris 10 there were a *lot*. In particular, link with the system openssl and you're in trouble. What I've found in general is that older (pre-S10) applications tend to be fine, S10-native applications can be problematic. There's also the fact that we don't claim compatibility with any version of Solaris after the fork. So S10U10 is OK, S10U11 is problematic, S11 is essentially a no-go area. > and that any discrepancies were to be > reported, and some S10 exploits becoming more widely known, I upgraded > from Solaris S10XU8 to OI-hipster-2016.10. There was some teething, > and one thing I still haven't resolved is an S10 binary that works right > in S10 and wrong in OI regarding non-blocking reads of stdin. It > happens to be my main project, of course... > > truss, in short, says: > > Solaris X86 S10U8 > > fcntl(0, F_GETFL) = 2 > fcntl(0, F_SETFL, FWRITE|FNONBLOCK) = 0 > read(0, 0xFD7FFF0C0028, 4096) Err#11 EAGAIN > fcntl(0, F_SETFL, FWRITE|FOFFMAX) = 0 > > Openindiana-hipster 2016.10 > > fcntl(0, F_GETFL) = 8194 > fcntl(0, F_SETFL, FWRITE|FOFFMAX|FNONBLOCK) = 0 > read(0, 0xFD7FFF0C0028, 4096) = 0 > fcntl(0, F_SETFL, FWRITE|FOFFMAX) = 0 > > > Does anybody know why the behavior is different, and how to get the > former under OI. I expect there is some library difference somewhere. > I've been poking at tcsetattr to tweak this, and the best I can do is > see 4 characters get queued up before the program gets them (S10U8 does > that with different termios flags, too). read() returning 0 instead of > EAGAIN is interpreted as EOF and the program quits, rather clumsily. > I don't suppose you have the source? (I guess you may not have, as if you did then you could just recompile it.) Where does stdin come from, because it's different in the 2 cases (under OI it's largefile enabled, from your truss output)? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] nonblocking i/o problem
On 04/ 9/17 02:08 AM, Peter Tribble wrote: As an aside, there are limitations. The conditions were always pretty strict, so that compatibility only applies to (a) Solaris itself, and (b) only those interfaces explictly marked as being compatible. Specifically those whose man pages have an attributes section listing them as "Committed" or "Uncommitted" - anything that's "External", "Volatile", "Private" or undocumented may break even between Solaris releases, as well as between Solaris and illumos. In particular, link with the system openssl and you're in trouble. Especially as the original S10 openssl was 0.9.8 which is no longer supported or receiving security fixes, which is why Oracle's patching everything in S10 to use the not-completely-compatible 1.0.1 instead. What I've found in general is that older (pre-S10) applications tend to be fine, S10-native applications can be problematic. Drivers that stick to the documented DDI interfaces should also be good, but other kernel modules, such as filesystems, that rely on undocumented or private kernel interfaces may really break your system. -alan- ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
