Re: [PATCH 0/7] Minor Alpha updates for 3.11

[Michael Cree]

On Mon, Jul 22, 2013 at 09:31:41PM -0500, Rob Landley wrote:
> On 07/16/2013 07:03:47 PM, Michael Cree wrote:
> >On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote:
> >> On 07/16/2013 12:04:33 PM, Richard Henderson wrote:
> >> >Here's a set of minor updates for arch/alpha that should not
> >> >be controversial.
> >>
> >> I also note that I had to do this to get busybox to build against
> >> uClibc:
> >> -#define __NR_umount		 22
> >> +#define __NR_umount2		 22
> >> -#define __NR_oldumount		321
> >> +#define __NR_umount		321
> >
> >I anticipate that this will likely break userspace.
> 
> Haven't seen it so far. It's the same semantics all the other
> targets have. Haven't built the whole of linux from scratch against
> it yet though. (Most of my package builds are native and I'm still
> tweaking my build environment to get a native toolchain built.)

[snip]

> I.E. nobody's tried to build busybox umount for Alpha (except me)
> for thirteen years.

That appears false to me.  Busybox builds OK on Debian-Ports [1], and it looks
like in the build log that umount is built.  A search in Debian busybox
sources does not return any hits for __NR_umount or __NR_umount2, but does
for umount2 which are library calls (admittedly ones that are just wrappers
for the kernel syscall). I also don't see any Debian patches in busybox that
change behaviour of busybox specifically for Alpha.  But IIRC Debian links
against glibc even for the installer where busybox is used.

So maybe the problem is in uClibc?  Yes, a quick look at the source shows
that uClibc does not test __NR_oldumount so presumably does not compile
correct umount and umount2 library calls on Alpha.

Maybe it's the case noone has compiled uClibc on Alpha until now?

> There are waaaaay more busybox installations out there than even
> _emulated_ alpha systems, and this is trivial to fix with a local
> patch to the kernel. So I'll just do that. Your idea of the
> "correct" thing to do to "fix" this seems entirely backwards to me.

I wondered if your proposal will break glibc as glibc checks for
__NR_oldumount and does different things based on that.  But maybe your
fix will not adversely affect glibc (I did not look particularly closely
to see if so), but even so, there is no guarantee that other software does
not directly access the oldumount syscall when compiled on Alpha, and your
change would likely break any such software.

Cheers
Michael

[1] http://buildd.debian-ports.org/status/package.php?p=busybox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/