From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oris.opensource.gr.jp (oris.opensource.jp [218.44.239.73]) by dsl2.external.hp.com (Postfix) with ESMTP id CC0AC4834 for ; Thu, 24 Oct 2002 03:56:14 -0600 (MDT) Date: Thu, 24 Oct 2002 18:56:09 +0900 Message-ID: <80u1jcp3d2.wl@oris.opensource.jp> From: GOTO Masanori To: Randolph Chung Cc: John Marvin , parisc-linux@lists.parisc-linux.org Subject: Re: [parisc-linux] Re: EWOULDBLOCK vs. EAGAIN In-Reply-To: <20021022155435.GB5602@tausq.org> References: <200210221534.JAA28679@udlkern.fc.hp.com> <20021022155435.GB5602@tausq.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: parisc-linux-admin@lists.parisc-linux.org Errors-To: parisc-linux-admin@lists.parisc-linux.org List-Help: List-Post: List-Subscribe: , List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: At Tue, 22 Oct 2002 08:54:35 -0700, Randolph Chung wrote: > In reference to a message from John Marvin, dated Oct 22: > > OK, I should have checked the archives first. It looks like this issue > > has already come up. In that case we fixed the app. But I'm not comfortable > > with the fact that we are different from every other architecture here. > > John, I was refering to the suggestion Carlos made that we can "fix up" > the return value in the syscall return path in glibc. Looks like there > is already precedence for this sort of thing, and that way we retain > binary compatibility with both hppa-linux and potentially with hpux. I wonder it's not important changing EWOULDBLOCK -> EAGAIN to keep hpux (or old sysv) compatibility... Now SusV3 says EWOULDBLOCK may be same as EAGAIN, a conforming implementation may assign the same values. Are there any reasons to retain this? I don't know whether hpux binary can run on hppa-linux or not, but if EWOULDBLOCK is not same as EAGAIN, serious problem is occured? I think keeping compatibity to other linux is more important than hpux binaries... (Well, I'm not hppa-linux user, so please tell me these status/circumstance). > > P.S. I know most of you don't care, but the broken app in this case is > > telnetd. It drops connections if you blast too much to stdout. > > heh, now that you mention it, this explains some things...:-) So, telnetd should be fixed...? Regards, -- gotom