# 64-bit Kernel and 32-bit Userland

## bLUEbYTE84

Hello,

I would like to know what would be the disadvantage for having 64-bits kernel and a purely 32-bit userland. For instance, I use kernel ALSA modules, when I compile a 64-bit kernel, the ALSA libs are obviously are still in 32-bits, should I expect a problem here? 

Would such configuration give better performance than 32-bit kernel?(More registers etc)

----------

## depontius

I've played with this idea a little, though not a complete 64-kernel/32-userland split. Instead I've toyed with the idea of an "xdm32", so that logins are 32-bit, which is another solution to the fact that some amount of user-code isn't available in 64-bit versions, we're always searching for -bin's, etc. This method would keep init.d services (including ssh) running in 64-bit mode, it would just be the X logins that would be 32-bit.

So far I haven't been able to get linux32/chroot to work in a script. Excerpted from: https://forums.gentoo.org/viewtopic-t-536669-highlight-.html

* Move the user sessions to 32-bit. I've done a little fiddling, and found that I can indeed start a complete 32-bit X session on top of the 64-bit kernel and services. Unfortunately so far this has been strictly manual, and I haven't been able to script the "linux32 chroot" commands. This script doesn't work:

```
#!/bin/bash

if   [ "x86_64" = `uname -m` ]

then

  echo "I'm currently in 64-bit mode"

  linux32 dchroot /home/dale/bin/fun

  echo "I'm back in 64-bit mode"

elif [ "i686" = `uname -m` ]

then

  echo "Now I'm in 32-bit mode, press 'Enter' to continue"

  read idiot

  echo "Leaving 32-bit mode"

else

  echo "Where the heck am I?"

fi

echo "DONE!"
```

Obviously a ditzy script, I would expect it to print:

```
I'm currently in 64-bit mode

Now I'm in 32-bit mode, press 'Enter' to continue

...(press Enter here)...

Leaving 32-bit mode

I'm back in 64-bit mode

DONE!
```

What it really does is:

```
I'm currently in 64-bit mode

I'm back in 64-bit mode

DONE!
```

It appears to completely ignore the attempt to change to 32-bit mode. If I could just get linux32/chroot/dchroot working in a script, I believe I could scare up some sort of xdm32 or gdm32, and effectively move the desktop into 32-bit on top of the 64-bit system.

----------

## thedangerouscrew

depontius I might be a little off base here, but I had a situation were I needed to chroot into 32bit in a script.

Maybe this thread will help you

https://forums.gentoo.org/viewtopic-t-380742-start-0-postdays-0-postorder-asc-highlight-.html

----------

## selig

I would advise against doing this for performance reasons. When you boot a 32-bit kernel, the CPU works in 32 bit mode natively. When you boot a 64-bit kernel and run 32-bit userspace programs, they run in an emulation mode of the CPU and they are slower than if run natively (the CPU is capable of executing 32-bit x86 code, but with some overhead). I do not know how much speed you would gain on I/O, etc. operations done by a 64-b kernel when compared to 32-b, but I would say that it is quite probable that this gain would be lower than the emulation overhead penalty. If you need 32-bit userspace and do not need a 64-bit kernel for its registers (e.g. when handling filesystems, memory etc.), compile all of it for 32-b.

It would be the same as installing 64-bit WinXP only to find out that practically all programs are 32-bit only and work slower.

Moreover, the CPU is unable to execute 16-bit code in 64-bit mode, but that really should not matter.  :Laughing: 

----------

## depontius

Thanks for the bump. I looked at your reference, looked again at my script, and made a few changes. Basically I probably wasn't using dchroot correctly, but since my end goal is to run this thing as root, it just didn't matter. I changed the script simply use chroot:

```
me@localhost /home/me/bin $ cat fun 

#!/bin/bash

if   [ "x86_64" = `uname -m` ]

then

  echo "I'm currently in 64-bit mode"

  linux32 chroot /mnt/gentoo32 /bin/bash -c "/home/me/bin/fun"

  echo "I'm back in 64-bit mode"

elif [ "i686" = `uname -m` ]

then

  echo "Now I'm in 32-bit mode, press 'Enter' to continue"

  read idiot

  echo "Leaving 32-bit mode"

else

  echo "Where the heck am I?"

  uname -m

fi

echo "DONE!"
```

and when I run this as root, now I get:

```
localhost ~ # /home/me/bin/fun 

I'm currently in 64-bit mode

Now I'm in 32-bit mode, press 'Enter' to continue

Leaving 32-bit mode

DONE!

I'm back in 64-bit mode

DONE!
```

Now I just need to figure out how to use this capability in a new "xdm32" init script. My wish is to have a complete 64-bit machine, and start a 32-bit xdm on it, which will start 32-bit userland stuff, particularly media-oriented plugins. My other option might be to start 64-bit xdm and X, but do the chroot as I execute the session manager or window manager. (This system runs xfce and icewm) Right now in /etc/rc.conf I have XSESSION="Xsession" so that user-level .Xclients/.xsession gets executed. I HATE the way Linux distributions have taken away user control by default, moving such things back to root-level "session control" functionality, in a very Windows-like way. Every new installation I have to tweak the system so that user-level wishes are respected! Looking at the problem as I explain it, I guess what I can really do is create /etc/X11/Xsession32 that does the linux32 chroot and calls /etc/X11/Xsession. (In the chroot, obviously.) I'll probably still need to fiddle to get Xauthority properly respected. I'd really rather avoid xhost.

----------

## thedangerouscrew

I never had any luck with dchroot (i think it's a scam).  

Your sulution might be as simple as adding an & at the right place or

breaking it up into mutiple script. I also se a posible error in your script.

I will take a further look when I get time.

----------

## depontius

thedangerousscrew:

The script works, and if what I posted doesn't look like it would, I must have made a mistake as I 'sanitized' it. It's not meant to do anything real, just to hop between 64 and 32 bit modes in an automated fashion.

selig:

My earlier post came before yours was available to me. Any idea how bad the emulation hit is? I actually have both 64 and 32 bit installs laying around on this machine, and normally run the 64-bit. But my wife has a bunch of trouble with web and media stuff. It can work, but that doesn't mean it always does. In practice I can make it work, as I can make nspluginwrapper work. But everything has to be done just right, and when my wife simply wants to click on a link in Thunderbird and have Firefox work, it generally does the wrong thing. (64/32/plugin/wrapper-wise)

As for just going 32, I suppose I could. Part of me likes the "hybrid" approach for the oddity, and to leave mythtv, its commercial flagging, transcoding, etc running in 64-bit mode. With the hybrid approach, I could also set my wife and kids up in 32-bit mode and stay in 64-bit, myself.

----------

## whig

I get no noticeable slowdown running apps/games in a 32 bit chroot, if it's there it's tiny. My 64 bit Thunderbird opens links in 32 bit Firefox - if the latter is already open.

----------

## depontius

I have 64-bit Thunderbird, and both 64 and 32 bit Firefox, the latter being a binary install. The 64-bit Firefox is required by a GNOME package which is required by gnucash, which is the only end-user GNOME package I've got installed. (Except for gdm, I figured I've got so much GNOME for gnucash that gdm looks better and is more functional than xdm, and is just a nit at this point.) I've also got nspluginwrapper installed and working.

It's like this...

If either the 32-bit or 64-bit Firefox is simply started, most everything works, flash and streaming media.

If my wife is in Thunderbird, and clicks on a link someone sent her, and Firefox isn't already started NOTHING WILL WORK. Even though I've gone into prefs.js and told Thunderbird to start /opt/firefox/firefox, something there is SOOOOOOOOOOO smart that it doesn't start the 32-bit binary Firefox, which I was very careful to specify. Instead it starts the 64-bit Firefox. What's more, to add insult to injury, when it starts the 64-bit Firefox which I didn't want, it somehow manages to strip out nspluginwrapper, so NONE of the media stuff has any chance of working.

OK, she can make sure Firefox is started first, and I've told her this. But the truth is, she shouldn't have to. She should be able to be in Thunderbird and simply click a link and it ought to work. There should be no "magic formulas" for a basic user to use this stuff, assuming someone has set it up for them.

Oh yeah, my wife likes the "glowy-green" skins on Thunderbird and Firefox. From what she's told me, things also crash quite often, though I haven't been able to get the specifics. I did mask Firefox-2.x because the skin was originally written against Firefox-1.x. It may have helped, but doesn't stop the crashing. I've looked, and haven't seen others griping about the reliability of "glowy" themes. I think it's all tied up in the 64/32 crap, and am looking to simplify it. Moving her back to 32-bit on a 64-bit kernel is hopefully my less-intrusive way to make things "just work" for her.

I have generally advised people against 64-bit installation with this set of caveats, unless they know they're going to need it, specifically. (I might, in the not-so-distant future.)

----------

## whig

Yip, Thunderbird would start 64 bit Firefox if none is running. Install a 32 bit Thunderbird so it starts the local Firefox perhaps?

----------

## depontius

 *whig wrote:*   

> Yip, Thunderbird would start 64 bit Firefox if none is running. Install a 32 bit Thunderbird so it starts the local Firefox perhaps?

 

As I said, to add insult to injury, in addition to starting the 64-bit Firefox, when it's started from Thunderbird for some reason nspluginwrapper and friends don't load.

I suppose I could try 32-bit Thunderbird binary. I just prefer building from source, when possible.

----------

## depontius

Over the past couple of nights, I've finally got a mixed 64/32 system, basically a complete 64-bit system running a 32-bit gdm. Since users start under the 32-bit gdm, their sessions are completely 32-bit.

This system was installed as 64-bit and has run that way for over a year. But on the side, I played with a bootable 32-bit install in a chroot. I've added an extra variable, "X32" to "/etc/conf.d/xdm" and act on that variable in "/etc/init.d/xdm" and "/etc/X11/startDM.sh". Specifically the init script exports X32 to make it available when it executes startDM.sh, and tests "X32" in the start-stop-daemon call that terminates xdm, doing so in the main session or in the chroot32, as required. In startDM.sh I test X32 to determine whether or not to chroot32 the desktop manager. 

It all appears to work. Moreover, I did a little performance work just as a sanity check. In a vanilla 64-bit system glxgears gets about 1759fps. With a 64-bit system and 64-bit X server, but in a chroot32 glxgears gets about 1752fps. With the current setup, since the chroot32 happens before starting the desktop manager, I've got a 64-bit system and a 32-bit X server, and glxgears gets about 1758fps. The only number missing here is a pure 32-bit figure, which I'll have to reboot specifically to get.

There are 2 problems, at the moment. First, "df" doesn't work, even though I have /proc mounted inside the chroot. There is even a stale /etc/mtab, though I should probably do a "cp -L" on that as I build the chroot. But it's not that "df" gives stale information, it gives no information at all, claims it can't find anything. The other problem is with shutdown. If I select shutdown from the 32-bit gdm, the system shuts down immediately, and not gracefully. In hindsight, that's because gdm is in the chroot32, and nothing was really started inside the chroot, so nothing needs to be stopped. I need to think my way out of this one, but the hard part is that I'd still like to preserve the ability to boot pure 32-bit. 

One solution and alternative implementation would be a sudo command inside .Xclients to keep gdm and X in 64-bit and just make the user session 32-bit. But part of the reason for doing all of this is that the 64-bit X has been significantly flakier than 32-bit X. But for the moment, my wife's plugins are working better and more reliably than before and she's happy, so I'll deal with the df and shutdown issues.

----------

