Products > Test Equipment
Open source lxi-tools and liblxi v1.0 released for GNU/Linux
lundmar:
--- Quote from: glarsson on November 06, 2017, 09:08:34 pm ---True, but the non-portable code can be located in separate files to make it easier to port to different platforms.
--- End quote ---
True, especially if there is a lot of it. Conditional ifdefs will do fine for smaller code bits, which is the case here.
--- Quote from: glarsson on November 06, 2017, 09:08:34 pm ---I was looking at adding code to sigrok or port lxi-tools to macOS (a certified UNIX with a marketshare larger than Linux) but did get the feeling that contributions to lxi-tools supporting platforms other than Linux was not welcome.
--- End quote ---
Any contributions to improve lxi-tools or liblxi are welcome. Yes, it is initially made for and tested on GNU/Linux systems but that is mainly because I don't have the bandwidth nor access to test and support other platforms. In other words, I'm not opposed to supporting other platforms but only if someone would like to contribute/help maintain that support. That being said, not much is required to make it work on most platforms.
If you want to help make lxi-tools and liblxi work on macOS I welcome it :-+
lundmar:
--- Quote from: rhb on November 06, 2017, 05:10:30 pm ---Other than not being portable to non-Gnu/Linux systems, I don't see what this does
--- End quote ---
vxi11_discover() iterates through the broadcast addresses of all available network interface. For each iteration it calls discover_devices() using the broadcast address to find the instruments.
Using getifaddrs() etc. is technically not portable code as it is not blessed by posix, it is however available on most platforms, including Linux, macOS, *BSD, and even Solaris 11+.
If you are not satisfied I invite your to contribute a variant of vxi11_discover() that works on your platform. Making it 100% portable is likely not possible since platforms like Linux are fading away their IOCTL support for retrieving network interface information (broadcast addresses etc.) in favor of a more efficient netlink mechanism.
By the way, you are looking at some old code there. See https://github.com/lxi/liblxi for latest.
rhb:
FWIW I started porting it to Solaris 10 u8. It's actually nicely written code from the little I've looked at. The code I'm using was downloaded from github as a tarball after you started this thread. So I'm not sure how you can call it old. Once I've got it running on Solaris, it will work on MacOS and *nix in general.
if_nameindex() returns all the network interfaces and *is* part of POSIX and on Solaris 10 u8 which is so ancient I keep it off the Internet. It's the last Sun released version before it became So Larry's. So as a rough guess, 10 years old. But nothing can match the Sun/Forte debugger. Everything else is "flint knives and stone axes". And I've used probably a dozen different *nix debuggers.
At the moment I've got lxi_discover() commented out while I deal with other Gnuisms. Once I've got it to run, I'll fix lxi_discover().
Yes, I'm a grumpy old man. I've supported over 2 million lines of badly written code that other people inflicted upon the world. I'm really tired of seeing the same mistakes made over and over again. IBM created JCL to fix the problem of hard coded filenames. And of course, *everyone* using JCL knew that everything after a space was a comment because that was the 360 assembler convention. Then 10-20 years later the Motif mob hard coded xkeysymdb. After 20+ years I've finally forgotten where. We now have a version of xclock that consumes more memory than most of the computers I've used had available. Your phone needs more horsepower than a Cray YMP. Ain't progress grand!
lundmar:
--- Quote from: rhb on November 07, 2017, 01:45:07 am ---FWIW I started porting it to Solaris 10 u8. It's actually nicely written code from the little I've looked at. The code I'm using was downloaded from github as a tarball after you started this thread. So I'm not sure how you can call it old. Once I've got it running on Solaris, it will work on MacOS and *nix in general.
--- End quote ---
Sounds good :-+
Sorry, I meant old as in 5 days old ... the code your are looking at is from before I did some rearrangements to support configurable communication backends (VXI11/TCP vs. RAW/TCP).
--- Quote from: rhb on November 07, 2017, 01:45:07 am ---if_nameindex() returns all the network interfaces and *is* part of POSIX and on Solaris 10 u8 which is so ancient I keep it off the Internet.
--- End quote ---
Yes, however, getting interface names is not the problem. The problem is going from an interface name or index to actually retrieving the broadcast address in a portable way. I can't find any APIs for this except doing using ioctl() requests which is fine but not really well supported on recent Linux kernels anymore. From the little digging I've done this far I expect we need to do platform handling for this piece of code. I don't recall but I think this is the very reason I did what I did when I wrote this 2-3 years ago, I went with the seemingly most portable implementation.
--- Quote from: rhb on November 07, 2017, 01:45:07 am ---Yes, I'm a grumpy old man. I've supported over 2 million lines of badly written code that other people inflicted upon the world. I'm really tired of seeing the same mistakes made over and over again. IBM created JCL to fix the problem of hard coded filenames. And of course, *everyone* using JCL knew that everything after a space was a comment because that was the 360 assembler convention. Then 10-20 years later the Motif mob hard coded xkeysymdb. After 20+ years I've finally forgotten where. We now have a version of xclock that consumes more memory than most of the computers I've used had available. Your phone needs more horsepower than a Cray YMP. Ain't progress grand!
--- End quote ---
Well, I guess you earned your right to be grumpy ;)
Please bear in mind that I'm doing this open source project among quite a few other open source projects that I maintain in the little spare time I have available, so don't expect everything to be perfect. I simply don't have the time to put the same rigor in this as I do in my professional software projects. That being said, I think it is in a fair shape and with the help from your guys (contributors) I'm sure we can steadily improve it and maybe add some interesting features along the way.
Also, I think we have more views in common than you might think. For example, I share your lack of enthusiasm for perl and python. This is one of the very reasons I created lxi-tools/liblxi - I wanted a proper implementation in C for my LXI instrument control needs.
lundmar:
There have been lots of changes and bug fixes recently so I'm pushing new releases which are available for download at https://lxi.github.io
For a summary of changes see:
https://github.com/lxi/lxi-tools/releases/tag/v1.6
https://github.com/lxi/liblxi/releases/tag/v1.4
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version