LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices



Reply
 
Search this Thread
Old 06-23-2009, 12:03 AM   #1
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Rep: Reputation: 34
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
 
Old 06-23-2009, 12:11 AM   #2
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Original Poster
Rep: Reputation: 34
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

Last edited by Shingoshi; 06-23-2009 at 12:18 AM.
 
Old 06-23-2009, 09:31 AM   #3
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,455

Rep: Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172Reputation: 1172
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.
 
Old 06-23-2009, 12:44 PM   #4
marozsas
Senior Member
 
Registered: Dec 2005
Location: Campinas/SP - Brazil
Distribution: SuSE, RHEL, Fedora, Ubuntu
Posts: 1,393
Blog Entries: 1

Rep: Reputation: 64
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.
 
Old 06-23-2009, 01:48 PM   #5
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Original Poster
Rep: Reputation: 34
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
 
Old 06-23-2009, 01:54 PM   #6
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Original Poster
Rep: Reputation: 34
So what about having a combined kernel then...

Quote:
Originally Posted by sundialsvcs View Post
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.
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
 
Old 06-23-2009, 03:43 PM   #7
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Original Poster
Rep: Reputation: 34
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
 
Old 06-29-2009, 09:58 AM   #8
JimHughen
Member
 
Registered: Jun 2009
Location: Austin, Texas
Distribution: Ubuntu
Posts: 44

Rep: Reputation: 16
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.
 
Old 06-29-2009, 02:54 PM   #9
Shingoshi
Member
 
Registered: Oct 2006
Location: Cochise County, Arizona
Distribution: Gentoo-AMD64 / Slackware64-Current
Posts: 474
Blog Entries: 28

Original Poster
Rep: Reputation: 34
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware 64 Bit .. Needs 32 bit compatibility clowther Linux - Software 3 06-06-2009 01:55 PM
Slackware64 and 32-bit compatibility mattydee Slackware 24 05-23-2009 03:01 PM
32-bit compatibility on a 64-bit AMD box ?? Rod Butcher Linux - General 4 01-11-2007 06:10 PM
32 bit compatibility with 64 machine nozz Linux - Hardware 2 10-01-2005 10:33 AM
32 bit compatibility for 64 bit distros Phil Brooks Linux - Software 9 03-31-2005 07:27 PM


All times are GMT -5. The time now is 12:22 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration