Are linux x86_64 drivers forthcoming?

[EricBayer]

I see that in 2005 there were not x86_64 bit PCI GPIB drivers.  It appears as if there still aren't any.  Are these going to be available soon?  Is there any plan whatsoever to have them?  What about PCIe GPIB?

    -Eric

[Shawn B.]

64 bit processors are just recently becomming the "standard" for desktop systems.  Operating systems are still mainly 32 bit.  Linux has supported 64 bit machines almost since day one however, at this time most users are not using the bennifits that 64 bit computers provide.  I would love to hear about your application, and your need for 64 bit Linux.

Does your system have more than 4 GB of RAM?
Are you performing large computations requiring 64 bit numbers?

I would also love to hear about the requirements of your specific application.

Do you need a 64 bit user mode API, or would a 32 bit API suffice?
What language are you using LabVIEW, or C?

I can't comment on the time line of 64 bit Linux drivers, but customer demand as well as trends from the computer industry drive our time lines.

Shawn B.
National Instruments

[EricBayer]

Shawn,

Currently we are attempting to really have 4GB of RAM.  The application is 32-bit for the time being, but in the near future we will be porting it.  The problem we are experiencing is that we use GPIB as well as a VME controller.  The VME controller uses a lot of PCI space which isn't allocated on boot as it is dynamic.  Thus in a fully populated memory space on 32-bit kernels you have very little space left with which to map windows.  The only space left is in the old ISA ranges and it is small (we need like 50MB of PCI space to be mapped at once, and the ISA space is 128k at best.)  In a 64-bit kernel (especially with an AMD processor due to the presence of an IOMMU)  this is perfectly acceptable as IO and memory can be mapped around (without bounce buffers on AMD) to allow both to coexist happily.

The application is C/C++, we are porting from Solaris (where we used 64-bit kernel, 32-bit app), and we have users who are using around 3GB of memory in our software.  This dictates that we can't really drop back to 3GB (by taking out memory sticks) or 3.5GB (some BIOSes can throw away 512MB optionally) as in either case the OS is eating up a few hundred meg.  That still puts us at a deficit and would leave us no room for expansion.   As for the API, I'm not sure... I suspect for the short run 32-bit would work as we have a 32-bit app.  But if I understand the distinction right, in the near future we'd need a 64-bit one (when we ported our actual application to 64-bit.)  Am I making the right distinction on what API would be needed or is there some other deciding factor?

    -Eric

[Shawn B.]

Eric,

It does sound like you have a valid use case for a 64 bit OS.

---

As for the API, I'm not sure... I suspect for the short run 32-bit would work as we have a 32-bit app.  But if I understand the distinction right, in the near future we'd need a 64-bit one (when we ported our actual application to 64-bit.)  Am I making the right distinction on what API would be needed or is there some other deciding factor?

---

Exactly right.  If you had a 64 bit app, then we would need to have 64 bit user-mode libraries available.

As I mentioned previously our 64 bit Linux drivers will be driven by customer demand, and the computer industry.  Unless demand increases, we will likely have 64 bit Linux drivers when you can actually put more than 4 GB of RAM in a desktop class machine (currently you have to buy a workstation or better to get a motherboard that even supports more than 4 GB), and/or 64 bit Operating Systems become the standard.  Of course this may not be too far off.

My current recommendation if you need something now, or in the short term would be to check out the Linux GPIB Package.  This is an open source driver that is not provided by NI, but it supports most of our GPIB devices (from their release notes it even looks like they just added PCIe GPIB).

Shawn B.
National Instruments

[EricBayer]

Shawn,

---

Unless demand increases, we will likely have 64 bit Linux drivers when you can actually put more than 4 GB of RAM in a desktop class machine (currently you have to buy a workstation or better to get a motherboard that even supports more than 4 GB), and/or 64 bit Operating Systems become the standard.

---

Things have changed in the last few months.  Several of the AMD desktop boards (high end, but not really slanted towards servers) support 8GB now.  For instance:

ASUS M2N32 WS Professional - http://www.asus.com/products4.aspx?modelmenu=2&model=1207&l1=3&l2=101&l3=0
ASUS M2N-E - http://www.asus.com/products4.aspx?modelmenu=2&model=1181&l1=3&l2=101&l3=0
ASUS M2V - http://www.asus.com/products4.aspx?modelmenu=2&model=1171&l1=3&l2=101&l3=0

If you look around there's a few others that released recently.  I think it may be realted to the AM2 socket/memory controller.   Not trying to twist your arm or anything, just letting you know you can now find them off the shelf at several computer stores.

    -Eric

PS - I noticed the opensource GPIB project and will likely got that route for the time being.  It seems to compile/load under x86_64 without any problem.  Unfortunately I'm not the one who knows how to test it, so I'll have to wait till next week sometime to be sure it is working successfully.  I've got no qualms using it, but generally I prefer using provided drivers if I can help it.

[JasonSmith]

Eric,

Could you please visit our Product Suggestion Center and submit this as a suggestion?  This helps us to keep track of customer demand for new features such as this.

Thanks,

Jason S.
GPIB Software
National Instruments