Is it possible to have a 32-bit compatibility driver?
 

After writing this, I was seriously considering not posting it. But I'm too curious to let this go. So please forgive me for asking a question that may not make any sense.

I'm asking this question based on very old experiences with the FreeBSD linux kernel emulation driver that was in wide usage. So here's the basic question:

Is there a way to have the kernel itself provide both 32-bit and 64-bit userspaces to the system? If I'm not using the correct terminology, I welcome anyone to help out here. The idea is to have the kernel be responsible for the execution of either (32 or 64) bit-wise structures. And to somehow have glibc compiled in such a manner that it interprets the commands sent to it by the kernel, using a single instruction set for executing all binaries on the system.

I don't know if the alternative would be to have one combined (biarch) kernel or not. But the objective here is to be able to run both 32-bit and 64-bit code on the same system. Is it more efficient to run 32-bit code on a 64-bit kernel, than it would be using native 32-bit code? I know that there is multilib versions of glibc. But I don't think this is what I'm asking about.

If this has already been addressed elsewhere in a formal manner, I would like to know what the outcome of any investigation concerning this was. Forgive me. But I'm trying to work this out as I type. I'm thinking of something like a relative to cross-compiling, where the code in the kernel exists and is capable of running at least the two most dominant architectures (x86 and x86_64), and any others if possible too.

If a 64-bit kernel can be compiled on a 32-bit system, why can't a 64-bit emulation kernel driver be created and function as well? And as implied by my opening question, the inverse as well. A 32-bit emulation kernel driver for a 64-bit system. Would there be any advantage in performance from doing so?

I admit. I don't know enough about this. That's precisely why I'm asking what may be a really crazy question. So if someone can explain why none of this makes sense, or if it does, please do so.

Thank you!
Shingoshi

A pratical application waiting to happen...
 

I'm imagining mobile users being able to load systems on removable disks (the type of which doesn't matter here), where they can have a single system which can be booted by either 32-bit or 64-bit processors. All of the applications would be compiled for a glibc that would behave like an interpreter. But then, I guess it would no longer be C, but something else like it. I don't know. That's where I'm headed with this.

Shingoshi

A compiler can run on "anything." It is merely a computer program, and the executable is merely its output.

Hardware-wise, a 64 bit processor can "step down" to 32 bit mode but not vice-versa.

Programs need to have access to standard-library versions that are compiled with the appropriate word-size. Generally speaking, these can be automagically selected... but they must be there, and correctly compiled and installed.

Yes, you can run 32-bits applications on a 64-bit linux kernel.
In fact I am just doing this now. I am running Fedora 11 64 bits (2.6.29.4-167.fc11.x86_64 #1 SMP) and I have 32 bits applications like wine, opera, jre, and picasa.
And it is not the kernel or glic which runs, or select the appropriated library. It is the application itself (if it is static linked to the libs) or it is dynamic linker/cache which provides the correct library version to the application.
BTW, it is a hell to have a system capable of run both 32 and 64 bits due to potential conflicts and the overhead of having both versions installed for every library that a programs needs to run.
For instance, to run the 32 bits versions of the programs above, I had to install 80 rpm packages (rpm -qa | grep -viE "x86_64|noarch" | wc -l) to satisfy the 32 bits dependencies. It is more than 3000 files !

For drivers it is more complicated. I **guess** you can not mix 32-bits/64-bits drivers/kernel.
Drivers will run in the kernel space and so, they must have the same architecture.

Clarifications needed... Confusion minimized...
 

marozsas,
I am aware of the ability to run 32-bit applications in a 64-bit environment. I'm doing it myself right now. What I was specifically asking for was a conceptual model whereby the kernel would be compiled in such a way as to present an artificial architecture to the system. All of the programs would then be compiled against that artificial architecture.

It had been suggested to me to try using mips for this purpose. There are other systems which I have investigated also. But many of them are not yet fully developed, and remain essentially research systems for experimentation.

But in a more practical application, the duplication of binaries is exactly what I'm trying to eliminate. No matter what package you have, the configuration, documentation and any scripts which run , are the same for every bit format the main binary is compiled for.

So I'm wondering if we take python or perl as examples, both of which I believe run scripts in an interpreted manner at runtime, could we have a single directory for the scripts which are then shared by both bit versions of a single package?

As far as libraries go, I'm committed to using /lib32 and /usr/lib32 to segregate them from the 64-bit libraries on the same system. And I'm not concerned here with what is orthodox. I'm only concerned with what works. Having multiple binaries in /bin and /usr/bin are not a problem, since each can have a suffix which identifies it from the other architecture existing on the same system.

I think sundialsvcs answer is more to the point here. And I will now answer it in my next post.

Shingoshi

So what about having a combined kernel then...
 

If stepping up from 32-bit to 64-bit is an impossibility, what about compiling the kernel to have both architectures supported. In my application, the size of the system is not so much a concern. Our disk storage is getting too large to consider what is now becoming a trivial point. I just read recently, that OCZ is going to release a 1TB device shortly. So size is irrelevant. No one who would want to do this, would attempt it on a system not suited (to small) for doing so. So having partially mirrored multiarch systems in a single filesystem is nothing to be considered.

Let's move on to how a single kernel could support multiarch, in such a way, that it could be booted on any systems it was compiled for.

Shingoshi

Could you create a kernel which would start loading as 32-bit, and then probe the processor to determine it's architecture, and if 64-bit switch over to running in that format instead? What would be required if that were possible?

Shingoshi

glibc connects/maps API calls (user programs) to system calls (kernel interface). It is part of the application build that makes application binaries special for 32/64 bits and each implementation.

However, the application code generated by gcc must also match 32/64 bits and the implementation. You can make a cross compile on a 32 bit machine for a 64 bit application, OK. But that application will not run (at all) on the build machine. If that binary is moved to another machine that matches the target implementation built by the cross compiler, it will then run naturally.

i.e. trying to mix 32/64 bit application build involves the application code generated by gcc as well as glibc.

I think that different versions of each application are required for each implementation.

A change of direction...
 

This topic has been continued in another location. I based the new topic on my last question asked here. I hope anyone seeing this thread, will look at the new one now:
http://www.linuxquestions.org/questi...kernel-735628/

Shingoshi