| Message ID | 7b86ec9f26dd9a18e7fae7a39e6a3382@tuxicoman.be (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Thu, Jan 16, 2014 at 11:17 AM, Guy Martin <gmsoft@tuxicoman.be> wrote: > On Linux, only parisc uses a different value for EWOULDBLOCK which > causes a lot of troubles for applications not checking for both values. > Since the hpux compat is long dead, make EWOULDBLOCK behave the same as > all other architectures. > > Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> > --- > arch/parisc/include/uapi/asm/errno.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/parisc/include/uapi/asm/errno.h > b/arch/parisc/include/uapi/asm/errno.h > index f3a8aa5..c0ae625 100644 > --- a/arch/parisc/include/uapi/asm/errno.h > +++ b/arch/parisc/include/uapi/asm/errno.h > @@ -106,7 +106,7 @@ > > #define EALREADY 244 /* Operation already in progress */ > #define EINPROGRESS 245 /* Operation now in progress */ > -#define EWOULDBLOCK 246 /* Operation would block (Linux > returns EAGAIN) */ > +#define EWOULDBLOCK EAGAIN /* Operation would block (Not HPUX > compliant) */ > #define ENOTEMPTY 247 /* Directory not empty */ > #define ENAMETOOLONG 248 /* File name too long */ > #define ELOOP 249 /* Too many symbolic links > encountered */ This is an ABI break. You can't do this without rebuilding userspace. You need debian an gentoo onboard to do this ABI break. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1/16/2014 3:02 PM, Carlos O'Donell wrote: > On Thu, Jan 16, 2014 at 11:17 AM, Guy Martin <gmsoft@tuxicoman.be> wrote: >> On Linux, only parisc uses a different value for EWOULDBLOCK which >> causes a lot of troubles for applications not checking for both values. >> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as >> all other architectures. >> >> Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> >> --- >> arch/parisc/include/uapi/asm/errno.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/parisc/include/uapi/asm/errno.h >> b/arch/parisc/include/uapi/asm/errno.h >> index f3a8aa5..c0ae625 100644 >> --- a/arch/parisc/include/uapi/asm/errno.h >> +++ b/arch/parisc/include/uapi/asm/errno.h >> @@ -106,7 +106,7 @@ >> >> #define EALREADY 244 /* Operation already in progress */ >> #define EINPROGRESS 245 /* Operation now in progress */ >> -#define EWOULDBLOCK 246 /* Operation would block (Linux >> returns EAGAIN) */ >> +#define EWOULDBLOCK EAGAIN /* Operation would block (Not HPUX >> compliant) */ >> #define ENOTEMPTY 247 /* Directory not empty */ >> #define ENAMETOOLONG 248 /* File name too long */ >> #define ELOOP 249 /* Too many symbolic links >> encountered */ > This is an ABI break. > > You can't do this without rebuilding userspace. > > You need debian an gentoo onboard to do this ABI break. This would take about a month on Debian, so I'm against. Various bits of kernel code traditionally return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK would fail. Dave
On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin <dave.anglin@bell.net> wrote: >> This is an ABI break. >> >> You can't do this without rebuilding userspace. >> >> You need debian an gentoo onboard to do this ABI break. > > This would take about a month on Debian, so I'm against. Various bits of kernel code traditionally > return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK would fail. That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's only true on hppa, and that's the problem. The kernel is completely inconsistent about returning EWOULDBLOCK or EAGAIN, and the standards do dictate one or the other so the kernel and glibc are correct to use one or the other to match the standard. However, user applications are equally sloppy about checking the right value. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/16/2014 10:05 PM, Carlos O'Donell wrote: > On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin <dave.anglin@bell.net> wrote: >>> This is an ABI break. >>> >>> You can't do this without rebuilding userspace. >>> >>> You need debian an gentoo onboard to do this ABI break. >> >> This would take about a month on Debian, so I'm against. Various bits of kernel code traditionally >> return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK would fail. > > That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's > only true on hppa, and that's the problem. > > The kernel is completely inconsistent about returning EWOULDBLOCK or > EAGAIN, and the standards do dictate one or the other so the kernel > and glibc are correct to use one or the other to match the standard. > > However, user applications are equally sloppy about checking the right value. Guy, do you have actual programs which are currently broken and which don't check for both? My feeling is, that most programs were fixed, but I might be wrong... Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 16 January 2014 16:15:33 Helge Deller wrote: > On 01/16/2014 10:05 PM, Carlos O'Donell wrote: > > On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin wrote: > >>> This is an ABI break. > >>> > >>> You can't do this without rebuilding userspace. > >>> > >>> You need debian an gentoo onboard to do this ABI break. > >> > >> This would take about a month on Debian, so I'm against. Various bits > >> of kernel code traditionally return EWOULDBLOCK, so any application > >> code that just checks EWOULDBLOCK would fail. > > > > That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's > > only true on hppa, and that's the problem. > > > > The kernel is completely inconsistent about returning EWOULDBLOCK or > > EAGAIN, and the standards do dictate one or the other so the kernel > > and glibc are correct to use one or the other to match the standard. > > > > However, user applications are equally sloppy about checking the right > > value. > > Guy, do you have actual programs which are currently broken and which don't > check for both? My feeling is, that most programs were fixed, but I might > be wrong... my guess is memcached: https://bugs.gentoo.org/show_bug.cgi?id=498262 -mike
On 2014-01-16 22:15, Helge Deller wrote: > On 01/16/2014 10:05 PM, Carlos O'Donell wrote: >> On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin >> <dave.anglin@bell.net> wrote: >>>> This is an ABI break. >>>> >>>> You can't do this without rebuilding userspace. >>>> >>>> You need debian an gentoo onboard to do this ABI break. >>> >>> This would take about a month on Debian, so I'm against. Various >>> bits of kernel code traditionally >>> return EWOULDBLOCK, so any application code that just checks >>> EWOULDBLOCK would fail. >> >> That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's >> only true on hppa, and that's the problem. >> >> The kernel is completely inconsistent about returning EWOULDBLOCK or >> EAGAIN, and the standards do dictate one or the other so the kernel >> and glibc are correct to use one or the other to match the standard. >> >> However, user applications are equally sloppy about checking the right >> value. > > Guy, do you have actual programs which are currently broken and which > don't check for both? > My feeling is, that most programs were fixed, but I might be wrong... As Mike pointed out, memcached had a test which failed only on hppa. Fixing the test is easy but that lead me to check the code of libmemcache, client counterpart of memcached. The same problem was there too. Only EAGAIN was being checked. I agree that this change will break the ABI. However it will only affect applications checking solely for EWOULDBLOCK and not EAGAIN. I believe that on linux, most if not all applications check for EAGAIN and few check for EWOULDBLOCK as well. The problem currently is that finding out which applications are not checking for EWOULDBLOCK requires analyzing the code. Most of the time, failure to correctly check for EWOULDBLOCK will be quite stealth depending on how the application handles it. So despite the fact that this will break the ABI, the breakage should be minimal if non existent while it will fix a lot of hard to find and identify issues. Guy -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17-Jan-14, at 3:55 AM, Guy Martin wrote: > So despite the fact that this will break the ABI, the breakage > should be minimal > if non existent while it will fix a lot of hard to find and identify > issues. Have you tested the change? Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin <dave.anglin@bell.net> wrote: > > On 17-Jan-14, at 3:55 AM, Guy Martin wrote: > >> So despite the fact that this will break the ABI, the breakage should be minimal >> if non existent while it will fix a lot of hard to find and identify issues. > > > Have you tested the change? This is a good point. If you can make this change and still boot your system with a rebuilt kernel, then there is hope that your claims are true. The basic argument would be: * Change kernel header to make EWOULDBLOCK == AGAIN. * Rebuild kernel. * Boot system. * Verify system is semifunctional, networking, IO, disk, XVnc, etc. That would go a long way to showing that most of the system works. Then if you emerge the world against those changed headers and it goes well, then we might be talking about it being a low-impact change. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-01-17 15:08, Carlos O'Donell wrote: > On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin > <dave.anglin@bell.net> wrote: >> >> On 17-Jan-14, at 3:55 AM, Guy Martin wrote: >> >>> So despite the fact that this will break the ABI, the breakage should >>> be minimal >>> if non existent while it will fix a lot of hard to find and identify >>> issues. >> >> >> Have you tested the change? > > This is a good point. > > If you can make this change and still boot your system with a rebuilt > kernel, then there is hope that your claims are true. > > The basic argument would be: > * Change kernel header to make EWOULDBLOCK == AGAIN. > * Rebuild kernel. > * Boot system. > * Verify system is semifunctional, networking, IO, disk, XVnc, etc. > > That would go a long way to showing that most of the system works. > > Then if you emerge the world against those changed headers and it goes > well, then we might be talking about it being a low-impact change. > I've rebuilt the kernel with the change and I can't see any impact. NFS/SSH works fine and upgrading a few packages doesn't show any issue. I don't have X on that box. Guy -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/17/2014 04:11 PM, Guy Martin wrote: > On 2014-01-17 15:08, Carlos O'Donell wrote: >> On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin >> <dave.anglin@bell.net> wrote: >>> >>> On 17-Jan-14, at 3:55 AM, Guy Martin wrote: >>> >>>> So despite the fact that this will break the ABI, the breakage >>>> should be minimal if non existent while it will fix a lot of >>>> hard to find and identify issues. >>> >>> >>> Have you tested the change? >> >> This is a good point. >> >> If you can make this change and still boot your system with a >> rebuilt kernel, then there is hope that your claims are true. >> >> The basic argument would be: * Change kernel header to make >> EWOULDBLOCK == AGAIN. * Rebuild kernel. * Boot system. * Verify >> system is semifunctional, networking, IO, disk, XVnc, etc. >> >> That would go a long way to showing that most of the system works. >> >> Then if you emerge the world against those changed headers and it >> goes well, then we might be talking about it being a low-impact >> change. >> > > I've rebuilt the kernel with the change and I can't see any impact. > NFS/SSH works fine and upgrading a few packages doesn't show any > issue. I don't have X on that box. Just a comment: If we do an ABI break, we maybe should take other topics into account at the same time as well, e.g. - increasing number of signals for systemd - dropping some HP-UX signals - maybe something needed to better support 64bit userspace ? - ... Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/16/2014 05:17 PM, Guy Martin wrote: > On Linux, only parisc uses a different value for EWOULDBLOCK which > causes a lot of troubles for applications not checking for both values. > Since the hpux compat is long dead, make EWOULDBLOCK behave the same as > all other architectures. > > Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> What's our final decision regarding this patch now? Shall we target it for inclusion into 3.14 ? If yes, I can include it with my next push request... Please speak up now...! Helge > --- > arch/parisc/include/uapi/asm/errno.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h > index f3a8aa5..c0ae625 100644 > --- a/arch/parisc/include/uapi/asm/errno.h > +++ b/arch/parisc/include/uapi/asm/errno.h > @@ -106,7 +106,7 @@ > > #define EALREADY 244 /* Operation already in progress */ > #define EINPROGRESS 245 /* Operation now in progress */ > -#define EWOULDBLOCK 246 /* Operation would block (Linux returns EAGAIN) */ > +#define EWOULDBLOCK EAGAIN /* Operation would block (Not HPUX compliant) */ > #define ENOTEMPTY 247 /* Directory not empty */ > #define ENAMETOOLONG 248 /* File name too long */ > #define ELOOP 249 /* Too many symbolic links encountered */ -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 31, 2014 at 11:53 AM, Helge Deller <deller@gmx.de> wrote: > On 01/16/2014 05:17 PM, Guy Martin wrote: >> On Linux, only parisc uses a different value for EWOULDBLOCK which >> causes a lot of troubles for applications not checking for both values. >> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as >> all other architectures. >> >> Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> > > What's our final decision regarding this patch now? > Shall we target it for inclusion into 3.14 ? > If yes, I can include it with my next push request... > > Please speak up now...! > > Helge > >> --- >> arch/parisc/include/uapi/asm/errno.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h >> index f3a8aa5..c0ae625 100644 >> --- a/arch/parisc/include/uapi/asm/errno.h >> +++ b/arch/parisc/include/uapi/asm/errno.h >> @@ -106,7 +106,7 @@ >> >> #define EALREADY 244 /* Operation already in progress */ >> #define EINPROGRESS 245 /* Operation now in progress */ >> -#define EWOULDBLOCK 246 /* Operation would block (Linux returns EAGAIN) */ >> +#define EWOULDBLOCK EAGAIN /* Operation would block (Not HPUX compliant) */ >> #define ENOTEMPTY 247 /* Directory not empty */ >> #define ENAMETOOLONG 248 /* File name too long */ >> #define ELOOP 249 /* Too many symbolic links encountered */ I think we should do it and fix the userspace fallout by rebuilding. This is just like non-zero locks were in linuxthreads, a pain and constant source of bugs. I'll fixup glibc. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, January 31, 2014 12:24:10 Carlos O'Donell wrote: > On Fri, Jan 31, 2014 at 11:53 AM, Helge Deller <deller@gmx.de> wrote: > > On 01/16/2014 05:17 PM, Guy Martin wrote: > >> On Linux, only parisc uses a different value for EWOULDBLOCK which > >> causes a lot of troubles for applications not checking for both values. > >> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as > >> all other architectures. > >> > >> Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> > > > > What's our final decision regarding this patch now? > > Shall we target it for inclusion into 3.14 ? > > If yes, I can include it with my next push request... > > > > Please speak up now...! > > > > Helge > > > >> --- > >> > >> arch/parisc/include/uapi/asm/errno.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/parisc/include/uapi/asm/errno.h > >> b/arch/parisc/include/uapi/asm/errno.h index f3a8aa5..c0ae625 100644 > >> --- a/arch/parisc/include/uapi/asm/errno.h > >> +++ b/arch/parisc/include/uapi/asm/errno.h > >> @@ -106,7 +106,7 @@ > >> > >> #define EALREADY 244 /* Operation already in progress */ > >> #define EINPROGRESS 245 /* Operation now in progress */ > >> > >> -#define EWOULDBLOCK 246 /* Operation would block (Linux returns > >> EAGAIN) */ +#define EWOULDBLOCK EAGAIN /* Operation would block > >> (Not HPUX compliant) */>> > >> #define ENOTEMPTY 247 /* Directory not empty */ > >> #define ENAMETOOLONG 248 /* File name too long */ > >> #define ELOOP 249 /* Too many symbolic links encountered */ > > I think we should do it and fix the userspace fallout by rebuilding. i'm not sure userspace will break ? we've got two classes of code: - stuff that checks both EAGAIN & EWOULDBLOCK and treats them the same - stuff that checks EAGAIN only (and probably should check both, but doesn't) both of those will continue to work after we change EWOULDBLOCK i don't think there's really any code out there that only looks at EWOULDBLOCK (or does so differently from EAGAIN). if there is, then they'd break. but if they never sh*t in the woods in the first place, then who cares if they would have made noise ? :) -mike
diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h index f3a8aa5..c0ae625 100644 --- a/arch/parisc/include/uapi/asm/errno.h +++ b/arch/parisc/include/uapi/asm/errno.h @@ -106,7 +106,7 @@ #define EALREADY 244 /* Operation already in progress */ #define EINPROGRESS 245 /* Operation now in progress */ -#define EWOULDBLOCK 246 /* Operation would block (Linux returns EAGAIN) */ +#define EWOULDBLOCK EAGAIN /* Operation would block (Not HPUX compliant) */ #define ENOTEMPTY 247 /* Directory not empty */
On Linux, only parisc uses a different value for EWOULDBLOCK which causes a lot of troubles for applications not checking for both values. Since the hpux compat is long dead, make EWOULDBLOCK behave the same as all other architectures. Signed-off-by: Guy Martin <gmsoft@tuxicoman.be> --- arch/parisc/include/uapi/asm/errno.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) #define ENAMETOOLONG 248 /* File name too long */ #define ELOOP 249 /* Too many symbolic links encountered */