Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a third party software (SDK) that uses a kernel module to drive an infrared camera. The software are 32bit libraries of which I have not source code. The driver (kernel module) in the other hand is provided as source code. Now I have tested without problem this system on 32 bit machine. For some reasons now I must make this work on 64 bit machine.
So I installed the 32 bit support libraries for Linux (Ubuntu). With this, the software runs. But I have issues trying the software to work with the driver.
>If I build the driver against the 64 bit kernel, modprobe loads the module, but the software throws a "segmentation fault (core dumped)". Obviously there is a mismatch between 32bit software and 64 bit driver.
>If I build the driver against the 32 bit kernel, modprobe fails with "ERROR: could not insert 'moduleName': Exec format error". A 32 bit module does not simply loads on 64 bit OS.
My question is what can i do to get this work. I supposed that if 32 bit software can run on 64 bit OS, a kernel module can too, but obviously is not so simple. Is there a way to achieve this?.
Your program is only allowed to touch memory that belongs to it. Any access outside of those areas will cause a segmentation fault. Maybe debugging will help?
Here's a few links that may help or at least get you pointed in the right direction.
Sorry I don't know more.
Generally it should work - but ... have a read of this. Opensuse, but generally applicable.
The 32-bit API should cover most cases as it says - else the vendor needs to supply compatible binaries.
If I build the driver against the 64 bit kernel, modprobe loads the module, but the software throws a "segmentation fault (core dumped)". Obviously there is a mismatch between 32bit software and 64 bit driver.
That "obvious" conclusion would not even be my first guess. More likely, the driver contains some portability error and simply doesn't work when compiled for 64-bit. Since you have the source code, it should be possible to find and correct that portability error.
32-bit applications work with 64-bit drivers in Linux (and other OS's). A correctly designed driver interfaces with the kernel in a way that should make the issue of the application bit size invisible to the driver. The kernel takes care of dealing with the 32-bit application.
So your guess that the 32-bit application is not compatible with 64-bit driver is not easy to completely rule out, but it is also not easy for me to believe.
Quote:
I supposed that if 32 bit software can run on 64 bit OS, a kernel module can too, but obviously is not so simple. Is there a way to achieve this?.
VM so you have a 32-bit kernel in which to use the 32-bit driver. Otherwise, I'm pretty sure your assumption that a 32-bit kernel module can run in a 64-bit kernel is wrong.
Quote:
Originally Posted by syg00
Generally it should work
Which "it" is that? In context you seem to be saying a 32-bit kernel module can work in a 64-bit kernel. But then you posted a link explicitly saying it can't.
A 64-bit driver and 64-bit kernel and 32-bit application should all play well together. So hopefully that is what you meant by "it".
It may also depend on any ioctls that may be implemented by the kernel module... These get translated by the 32bit ABI, but custom ioctls would not. This in turn would cause a segmentation fault in the 32bit libraries as the data being passed would be for 64 bit rather than 32 bit. The only way to find out is to trace the segmentation fault.
And 32 bit kernel modules DON'T WORK in a 64 bit kernel. The kernel internal APIs are 64 bit only.
It may also depend on any ioctls that may be implemented by the kernel module... These get translated by the 32bit ABI, but custom ioctls would not. This in turn would cause a segmentation fault in the 32bit libraries as the data being passed would be for 64 bit rather than 32 bit. The only way to find out is to trace the segmentation fault.
And 32 bit kernel modules DON'T WORK in a 64 bit kernel. The kernel internal APIs are 64 bit only.
Unfortunately my knowledge regarding C++, and driver development is limited for making a complete diagnostics. The definitions that could be found in the header file are:
Code:
#define USB_FJVEINCAM_IOCTL_CTRLMSG _IOWR(0xB4,0x01,struct fjveincam_cmsg)
#define USB_FJVEINCAM_IOCTL_CHECK _IO(0xB4,0x02)
#define USB_FJVEINCAM_IOCTL_INFO _IOR(0xB4,0x03,struct fjveincam_info)
#define USB_FJVEINCAM_IOCTL_CONFIRM _IO(0xB4,0x04)
/* for USB_FJVEINCAM_IOCTL_CTRLMSG */
struct fjveincam_cmsg {
struct {
unsigned char bRequestType;
unsigned char bRequest;
unsigned short wValue;
unsigned short wIndex;
unsigned short wLength;
} req; /* USB device control request data */
void *data; /* response data area pointer */
};
/* for USB_FJVEINCAM_IOCTL_CHECK */
/* no structure */
/* for USB_FJVEINCAM_IOCTL_INFO */
/* Magic number for Fujitsu Palmsecure sensor driver. */
#define FJPV_MAGIC 0x464A5056
struct fjveincam_info {
int magic; /* Magic number for indicating Fujitsu Palmsecure sensor driver. */
int minor; /* minor number */
int o_timeout; /* counter of open time out */
int r_error; /* counter of read error */
int r_lasterr; /* read last error */
int w_error; /* counter of write error */
int w_lasterr; /* write last error */
unsigned char version[8]; /* device driver version string */
};
Just for the record, I am using this with a modified kernel. Installation instructions specify CONFIG_USB_DYNAMIC_MINORS should be disabled.
In a 32 bit binary that is a 32 bit address. The driver would be assuming it got a 64 bit address - which would be invalid, and possibly be the cause of your segmentation error. It would be if the fault is traced to the ioctl.
By far the simplest solution would be to ask the vendor for appropriate drivers. I'm not quite sure why "an infrared camera" has kernel requirements, anyway. How is this camera connected?
By far the simplest solution would be to ask the vendor for appropriate drivers. I'm not quite sure why "an infrared camera" has kernel requirements, anyway. How is this camera connected?
Even if the camera were connected via USB, there could be problems in that the application isn't using libusb to communicate with it...
I THINK (but not sure) the 32 bit version of libusb would work on a 64 bit system.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.