search

LabVIEW-DCAF / TDMSModule

A background datalogger for TDMS files
https://decibel.ni.com/content/projects/reference-designs-for-distributed-control-systems
Apache License 2.0
6 stars 3 forks source link

Add x64 Targets as Supported #31

Closed Beazurt closed 7 years ago

Beazurt commented 7 years ago

You can't currently add the TDMS module to 64 Linux targets.

pollockm commented 7 years ago

...is an alternate solution to this simply to remove the distinction? We don't have 32 vs 64 on any other target type, and we don't actually check the target to see if the remote system matches this value. Maybe just a LinuxRT option?

ryanpoulos commented 7 years ago

That's strange, because I just used TDMS on a 9036 the other day. Unless, something else has changed since then.

Beazurt commented 7 years ago

Are there cases where we would need to deploy different types of built code to the target depending on whether it was 32 or 64-bit? If so it might be better to leave the distinction. That is the only case I can think of that could matter though.

On Wed, Mar 22, 2017 at 9:51 AM, pollockm notifications@github.com wrote:

...is an alternate solution to this simply to remove the distinction? We don't have 32 vs 64 on any other target type, and we don't actually check the target to see if the remote system matches this value. Maybe just a LinuxRT option?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LabVIEW-DCAF/TDMSModule/issues/31#issuecomment-288423253, or mute the thread https://github.com/notifications/unsubscribe-auth/AH79OMge6mCrF4_TBUH5ILwICp3WBBvyks5roTVkgaJpZM4MlTmC .

pollockm commented 7 years ago

@ryanpopo - the runtime code works fine on x64, but the editor node is not available if you manually switch the type of the cRIO target from Linux RT ARM (default) to Linux RT 64

pollockm commented 7 years ago

@beazurt - there are, usually in cases where we call into an SO file. For example, syslog. In that case I actually push over BOTH the arm and x64 versions of the SO to the target and do a runtime check of which one to call (mainly because I don't trust that a user picked the right option in the DCAF editor, as it is easy to miss). @ryanpopo - how did you handle this for the shared memory?

ryanpoulos commented 7 years ago

Well, we never got to the point to using DCAF to push over the .so files, and now we don't use any. But I previously would put both libraries on the target, and a conditional disable would use the correct version depending on if it detected 32 or 64 bit, and which CPU type (ARM or x64) it detected.

ryanpoulos commented 7 years ago

So on the editor side, we didn't care about the target type. Runtime would just handle it.

Beazurt commented 7 years ago

Makes sense to deploy both and decide at runtime based on the target type. Honestly the less a user needs to care about the OS and architecture the better. It should be OK to try changing the enum and make sure nothing goes terribly wrong.

smithed commented 7 years ago

If you're deploying you could technically check the 64/32 distinction when you connect to the target and decide on the appropriate binaries to deploy then. I think we only added the distinction so that the callback to get any files to deploy could check that its sending the right one.

Probably easier to just send all of them, though, like you are :)

jwgorman commented 7 years ago

Acceptance Criteria