linux-gpib-general — linux-gpib package mailing list

[Linux-gpib-general] Prologic GPIB-USB adaptors

[John <su...@qc...>]

Are there any plans to add support for the Prologix GPIB adapter, USB
or ETHERNET to the linux-gpib library?

I am currently working on a project with a Prologix adapter and there
seems to be no support under Linux, which I found odd. I was
considering writing a driver for sigrok, but was advised that sigrok
depends on linux-gpib for its GPIB support. I couldn't find a mention
of the Prologix in the hardware list.

Regards.

-- 
John.

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

I've added support in svn for selecting devices by sysfs device path,
or serial number.  The new gpib_config options are --sysfs-device-path
and --serial-number.  The device path should work for usb or pci
devices.  The serial number only works for usb devices.

-- 
Frank

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

On Thu, Dec 6, 2018 at 8:33 PM Frank Mori Hess <fm...@gm...> wrote:
>
> On Thu, Dec 6, 2018 at 2:46 AM dave penkler <dpe...@gm...> wrote:
> >
> > BTW there is support for multiple cards in the USB hotplug scripts. See cut and paste from INSTALL below:
> >
> > Using multiple-boards of the same type with hotplug requires
> > udev support: In the hotplug scripts you can use either the
> > serial number $SERIAL or the device path $DEVPATH to decide
>
> It doesn't seem robust though, for example during boot when two
> devices may appear nearly simultaneously.  Really, the SERIAL/DEVPATH
> should be passed to gpib_config and the driver would use them to
> verify it has found the correct board.

Ok, I looked into this a bit more, the drivers can use
kobject_get_path() to get the DEVPATH on the kernel side.  I'm
thinking of just replacing the "device tree path" stuff I added with a
more generic support for specifying hardware by DEVPATH.  Probably no
one has started using the "device tree path" stuff yet (it only works
with the fmh_gpib driver) so changing it won't break anyone's code.

-- 
Frank

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

On Thu, Dec 6, 2018 at 2:46 AM dave penkler <dpe...@gm...> wrote:
>
> BTW there is support for multiple cards in the USB hotplug scripts. See cut and paste from INSTALL below:
>
> Using multiple-boards of the same type with hotplug requires
> udev support: In the hotplug scripts you can use either the
> serial number $SERIAL or the device path $DEVPATH to decide

It doesn't seem robust though, for example during boot when two
devices may appear nearly simultaneously.  Really, the SERIAL/DEVPATH
should be passed to gpib_config and the driver would use them to
verify it has found the correct board.

Re: [Linux-gpib-general] ni_usb with multiple devices

[dave p. <dpe...@gm...>]

BTW there is support for multiple cards in the USB hotplug scripts. See cut
and paste from INSTALL below:

Using multiple-boards of the same type with hotplug requires
udev support: In the hotplug scripts you can use either the
serial number $SERIAL or the device path $DEVPATH to decide
which board is to be associated with which minor in your
gpib.conf.  Using serial number it does not matter which usb
ports you use.  Using device path the association will be made
with the physical usb port in your system. To obtain the
serial numbers or device paths for your boards plug the boards
in and check the syslog for the output from the default
hotplog script. The order of the messages will correspond to
the order in which you plugged the boards in. Edit the hotplug
scripts to setup the serial numbers/device paths and minors
that correspond to your system.

On Thu, Dec 6, 2018 at 7:21 AM Frank Mori Hess <fm...@gm...> wrote:

> On Tue, Dec 4, 2018 at 5:42 AM Frank Mori Hess <fm...@gm...> wrote:
> >
> > On Mon, Dec 3, 2018 at 2:48 AM Manuel Mommertz <man...@de...>
> wrote:
> > >
> > > Just to make it clear: My patch selects the hardware by serial but
> (mis-)uses
> > > the config entry for device path to hold the wanted serial. That is
> the reason
> > > I call it quick and dirty.
> > >
> >
> > Oh, I missed that!  I'm going to fix it so it actually compares with
> > the device path.
> >
>
> Ok, now I see I was confused, thinking Linux had a universal device
> path for all buses.  But the device tree path on applies to devices
> coming from the device tree and doesn't apply to usb devices
> generally.  So, I reverted the whole deal.  The usb bus has it's own
> idea of a hardware path, but that should be selected by adding a
> different but similar ioctl to the one which specifies a device tree
> path.  Same goes for choosing by serial number.
>
>
> --
> Frank
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

On Tue, Dec 4, 2018 at 5:42 AM Frank Mori Hess <fm...@gm...> wrote:
>
> On Mon, Dec 3, 2018 at 2:48 AM Manuel Mommertz <man...@de...> wrote:
> >
> > Just to make it clear: My patch selects the hardware by serial but (mis-)uses
> > the config entry for device path to hold the wanted serial. That is the reason
> > I call it quick and dirty.
> >
>
> Oh, I missed that!  I'm going to fix it so it actually compares with
> the device path.
>

Ok, now I see I was confused, thinking Linux had a universal device
path for all buses.  But the device tree path on applies to devices
coming from the device tree and doesn't apply to usb devices
generally.  So, I reverted the whole deal.  The usb bus has it's own
idea of a hardware path, but that should be selected by adding a
different but similar ioctl to the one which specifies a device tree
path.  Same goes for choosing by serial number.


-- 
Frank

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[Tomislav I. <tom...@gm...>]

Great, thank you!

Tomislav

On Wed, Dec 5, 2018 at 12:19 PM dave penkler <dpe...@gm...> wrote:

> Applied
>
> On Tue, Dec 4, 2018 at 8:05 PM Tomislav Ivek <tom...@gm...>
> wrote:
>
>> It turns out Python bindings do not expose the iblines() functionality.
>> This would be most useful for pyvisa-py to test if REN is asserted.
>>
>> I've been using the attached pach to call iblines() from Python. It adds
>> one new function, gpib.lines(), and line-related constants to the gpib
>> module. It also introduces the corresponding method Gpib.lines() to the
>> object-oriented Gpib module.
>>
>> Cheers,
>> Tomislav
>>
>> On Wed, Nov 28, 2018 at 3:49 PM Tomislav Ivek <tom...@gm...>
>> wrote:
>>
>>> Great, thank you!
>>>
>>> Tomislav
>>>
>>>
>>> On Wed, Nov 28, 2018, 15:37 dave penkler <dpe...@gm... wrote:
>>>
>>>> Patch applied. Thanks.
>>>>
>>>> On Wed, Nov 28, 2018 at 1:52 PM Tomislav Ivek <tom...@gm...>
>>>> wrote:
>>>>
>>>>> Hi Frank, thanks for the reply. Attached is the patch that introduces
>>>>> a safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a
>>>>> look.
>>>>>
>>>>> Cheers,
>>>>> Tomislav
>>>>>
>>>>>
>>>>> On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <
>>>>>> tom...@gm...> wrote:
>>>>>> >
>>>>>> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
>>>>>> double-close situation with linux-gpib's Python class Gpib.Gpib:
>>>>>> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to
>>>>>> a design point in Gpib.Gpib which cleans up its GPIB handle only on
>>>>>> Python's GC cycle. This is not guaranteed to run when the programmer
>>>>>> expects it to and in extreme cases might even leak resources. It appears
>>>>>> Gpib.Gpib has no other user-facing method to close its GPIB handle.
>>>>>> >
>>>>>> > This can be resolved by adding a Gpib.close() method for
>>>>>> user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a
>>>>>> cross-platform GPIB binding that aims to be compatible with linux-gpib (
>>>>>> https://pypi.org/project/gpib-ctypes/). I would be happy to send a
>>>>>> patch for linux-gpib's Python lib.
>>>>>> >
>>>>>> > Please let me know what you think about that.
>>>>>>
>>>>>>
>>>>>> I'm no python expert, but your change sounds reasonable to me.
>>>>>>
>>>>> _______________________________________________
>>>>> Linux-gpib-general mailing list
>>>>> Lin...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>
>>>>

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[dave p. <dpe...@gm...>]

Applied

On Tue, Dec 4, 2018 at 8:05 PM Tomislav Ivek <tom...@gm...>
wrote:

> It turns out Python bindings do not expose the iblines() functionality.
> This would be most useful for pyvisa-py to test if REN is asserted.
>
> I've been using the attached pach to call iblines() from Python. It adds
> one new function, gpib.lines(), and line-related constants to the gpib
> module. It also introduces the corresponding method Gpib.lines() to the
> object-oriented Gpib module.
>
> Cheers,
> Tomislav
>
> On Wed, Nov 28, 2018 at 3:49 PM Tomislav Ivek <tom...@gm...>
> wrote:
>
>> Great, thank you!
>>
>> Tomislav
>>
>>
>> On Wed, Nov 28, 2018, 15:37 dave penkler <dpe...@gm... wrote:
>>
>>> Patch applied. Thanks.
>>>
>>> On Wed, Nov 28, 2018 at 1:52 PM Tomislav Ivek <tom...@gm...>
>>> wrote:
>>>
>>>> Hi Frank, thanks for the reply. Attached is the patch that introduces a
>>>> safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a look.
>>>>
>>>> Cheers,
>>>> Tomislav
>>>>
>>>>
>>>> On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...>
>>>> wrote:
>>>>
>>>>> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...>
>>>>> wrote:
>>>>> >
>>>>> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
>>>>> double-close situation with linux-gpib's Python class Gpib.Gpib:
>>>>> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
>>>>> design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
>>>>> GC cycle. This is not guaranteed to run when the programmer expects it to
>>>>> and in extreme cases might even leak resources. It appears Gpib.Gpib has no
>>>>> other user-facing method to close its GPIB handle.
>>>>> >
>>>>> > This can be resolved by adding a Gpib.close() method for
>>>>> user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a
>>>>> cross-platform GPIB binding that aims to be compatible with linux-gpib (
>>>>> https://pypi.org/project/gpib-ctypes/). I would be happy to send a
>>>>> patch for linux-gpib's Python lib.
>>>>> >
>>>>> > Please let me know what you think about that.
>>>>>
>>>>>
>>>>> I'm no python expert, but your change sounds reasonable to me.
>>>>>
>>>> _______________________________________________
>>>> Linux-gpib-general mailing list
>>>> Lin...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>
>>>

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[Tomislav I. <tom...@gm...>]

It turns out Python bindings do not expose the iblines() functionality.
This would be most useful for pyvisa-py to test if REN is asserted.

I've been using the attached pach to call iblines() from Python. It adds
one new function, gpib.lines(), and line-related constants to the gpib
module. It also introduces the corresponding method Gpib.lines() to the
object-oriented Gpib module.

Cheers,
Tomislav

On Wed, Nov 28, 2018 at 3:49 PM Tomislav Ivek <tom...@gm...>
wrote:

> Great, thank you!
>
> Tomislav
>
>
> On Wed, Nov 28, 2018, 15:37 dave penkler <dpe...@gm... wrote:
>
>> Patch applied. Thanks.
>>
>> On Wed, Nov 28, 2018 at 1:52 PM Tomislav Ivek <tom...@gm...>
>> wrote:
>>
>>> Hi Frank, thanks for the reply. Attached is the patch that introduces a
>>> safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a look.
>>>
>>> Cheers,
>>> Tomislav
>>>
>>>
>>> On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...>
>>> wrote:
>>>
>>>> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...>
>>>> wrote:
>>>> >
>>>> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
>>>> double-close situation with linux-gpib's Python class Gpib.Gpib:
>>>> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
>>>> design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
>>>> GC cycle. This is not guaranteed to run when the programmer expects it to
>>>> and in extreme cases might even leak resources. It appears Gpib.Gpib has no
>>>> other user-facing method to close its GPIB handle.
>>>> >
>>>> > This can be resolved by adding a Gpib.close() method for
>>>> user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a
>>>> cross-platform GPIB binding that aims to be compatible with linux-gpib (
>>>> https://pypi.org/project/gpib-ctypes/). I would be happy to send a
>>>> patch for linux-gpib's Python lib.
>>>> >
>>>> > Please let me know what you think about that.
>>>>
>>>>
>>>> I'm no python expert, but your change sounds reasonable to me.
>>>>
>>> _______________________________________________
>>> Linux-gpib-general mailing list
>>> Lin...@li...
>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>
>>

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

On Mon, Dec 3, 2018 at 2:48 AM Manuel Mommertz <man...@de...> wrote:
>
> Just to make it clear: My patch selects the hardware by serial but (mis-)uses
> the config entry for device path to hold the wanted serial. That is the reason
> I call it quick and dirty.
>

Oh, I missed that!  I'm going to fix it so it actually compares with
the device path.

-- 
Frank

Re: [Linux-gpib-general] ni_usb with multiple devices

[Manuel M. <man...@de...>]

On Freitag, 16. November 2018 21:42:37 CET Frank Mori Hess wrote:
> On Thu, Oct 25, 2018 at 2:07 AM Manuel Mommertz <man...@de...> 
wrote:
> > we want to use multiple GPIB-adapter from NI on one host. But there is
> > currently no way to fix the association between a GPIB-board and an
> > NI-GPIB- adapter. With each reboot we get a random mapping. To fix this
> > quick and dirty I prepared the attached patch against
> > linux-gpib-modules-4.2.0-rc1.
> Thanks, I applied your patch.  Really, all the drivers should support
> selection by device path.  I was just too lazy to update them all.
> 
> > To fix it the right way, I think there should be another config entry,
> > like
> > 'usb_serial'. Would be nice if you can include support for this in future
> > versions.
> 
> Selecting the hardware by serial number would be fine too (for the
> hardware/drivers that provide serial numbers).  There's nothing wrong
> with selecting by device path though.

Just to make it clear: My patch selects the hardware by serial but (mis-)uses 
the config entry for device path to hold the wanted serial. That is the reason 
I call it quick and dirty.

Manuel

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[Tomislav I. <tom...@gm...>]

Great, thank you!

Tomislav


On Wed, Nov 28, 2018, 15:37 dave penkler <dpe...@gm... wrote:

> Patch applied. Thanks.
>
> On Wed, Nov 28, 2018 at 1:52 PM Tomislav Ivek <tom...@gm...>
> wrote:
>
>> Hi Frank, thanks for the reply. Attached is the patch that introduces a
>> safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a look.
>>
>> Cheers,
>> Tomislav
>>
>>
>> On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...>
>> wrote:
>>
>>> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...>
>>> wrote:
>>> >
>>> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
>>> double-close situation with linux-gpib's Python class Gpib.Gpib:
>>> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
>>> design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
>>> GC cycle. This is not guaranteed to run when the programmer expects it to
>>> and in extreme cases might even leak resources. It appears Gpib.Gpib has no
>>> other user-facing method to close its GPIB handle.
>>> >
>>> > This can be resolved by adding a Gpib.close() method for
>>> user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a
>>> cross-platform GPIB binding that aims to be compatible with linux-gpib (
>>> https://pypi.org/project/gpib-ctypes/). I would be happy to send a
>>> patch for linux-gpib's Python lib.
>>> >
>>> > Please let me know what you think about that.
>>>
>>>
>>> I'm no python expert, but your change sounds reasonable to me.
>>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[dave p. <dpe...@gm...>]

Patch applied. Thanks.

On Wed, Nov 28, 2018 at 1:52 PM Tomislav Ivek <tom...@gm...>
wrote:

> Hi Frank, thanks for the reply. Attached is the patch that introduces a
> safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a look.
>
> Cheers,
> Tomislav
>
>
> On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...> wrote:
>
>> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...>
>> wrote:
>> >
>> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
>> double-close situation with linux-gpib's Python class Gpib.Gpib:
>> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
>> design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
>> GC cycle. This is not guaranteed to run when the programmer expects it to
>> and in extreme cases might even leak resources. It appears Gpib.Gpib has no
>> other user-facing method to close its GPIB handle.
>> >
>> > This can be resolved by adding a Gpib.close() method for
>> user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a
>> cross-platform GPIB binding that aims to be compatible with linux-gpib (
>> https://pypi.org/project/gpib-ctypes/). I would be happy to send a patch
>> for linux-gpib's Python lib.
>> >
>> > Please let me know what you think about that.
>>
>>
>> I'm no python expert, but your change sounds reasonable to me.
>>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[Søren K. <sq...@dt...>]

Hi again.


I have just tested on a fresh CentOS7 and the suggested fix works!


Thank you so much for your fast response and help.


Yours

Søren koch


On 11/28/18 11:13 AM, Frank Mori Hess wrote:
> On Tue, Nov 27, 2018 at 11:28 PM Søren Koch via Linux-gpib-general
> <lin...@li...> wrote:
>> I have just tried to install linux-gpib-4.2 on a new CentOS 7 system
>> (after running yum update to get latest packages)
>>
>> When I try to compile the kernel driver i get the following error:
>>
> Easiest thing is to go into drivers/gpib/Makefile and disable the
> fmh_gpib driver by removing the line that says
>
> obj-y += fmh_gpib/
>
> Your 3.10 kernel probably needs some extra compatibility code to
> compile the device tree related code in the fmh_gpib driver.  I don't
> think your kernel configuration is wrong.

-- 
Søren Koch
Senior Development Engineer
DTU Energy, Risø Campus
-------------------------------------------
Technical University of Denmark
Department of Energy Conversion and Storage
Frederiksborgvej 399
Building 227, 1.sal
4000 Roskilde
Direct +45 46775816
sq...@dt...
http://www.ecs.dtu.dk

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[Tomislav I. <tom...@gm...>]

Hi Frank, thanks for the reply. Attached is the patch that introduces a
safe Gpib.Gpib.close() which will ensure proper cleanup. Please take a look.

Cheers,
Tomislav


On Wed, Nov 28, 2018 at 11:15 AM Frank Mori Hess <fm...@gm...> wrote:

> On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...>
> wrote:
> >
> > The pure-Python VISA backend pyvisa-py has recently stumbled upon a
> double-close situation with linux-gpib's Python class Gpib.Gpib:
> https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
> design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
> GC cycle. This is not guaranteed to run when the programmer expects it to
> and in extreme cases might even leak resources. It appears Gpib.Gpib has no
> other user-facing method to close its GPIB handle.
> >
> > This can be resolved by adding a Gpib.close() method for user-controlled
> cleanup. I hav ealready tested the fix in gpib_ctypes, a cross-platform
> GPIB binding that aims to be compatible with linux-gpib (
> https://pypi.org/project/gpib-ctypes/). I would be happy to send a patch
> for linux-gpib's Python lib.
> >
> > Please let me know what you think about that.
>
>
> I'm no python expert, but your change sounds reasonable to me.
>

Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[Søren K. <sq...@dt...>]

Hi Frank.


Thanks a lot.

That fix solved the issue, and I can now compile the driver and our gpib application appears to work!


I still need to do a fresh CentOS install and check (to make sure that it is not the already installed 4.1 driver which makes things work), but so far your suggested fix solved the issue 😊


Dave: When I look in the kernel source I can not find a file called of.h in include/linux directory

(There is no .h files there, just a lot of sub directories)


Yours


Søren koch


________________________________
From: Frank Mori Hess <fm...@gm...>
Sent: Wednesday, November 28, 2018 11:13:55 AM
To: Søren Koch
Cc: lin...@li...
Subject: Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

On Tue, Nov 27, 2018 at 11:28 PM Søren Koch via Linux-gpib-general
<lin...@li...> wrote:
> I have just tried to install linux-gpib-4.2 on a new CentOS 7 system
> (after running yum update to get latest packages)
>
> When I try to compile the kernel driver i get the following error:
>

Easiest thing is to go into drivers/gpib/Makefile and disable the
fmh_gpib driver by removing the line that says

obj-y += fmh_gpib/

Your 3.10 kernel probably needs some extra compatibility code to
compile the device tree related code in the fmh_gpib driver.  I don't
think your kernel configuration is wrong.

Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[Frank M. H. <fm...@gm...>]

On Wed, Nov 28, 2018 at 2:20 AM dave penkler <dpe...@gm...> wrote:
>
> Hi Søren,
> Thanks for raising this. As Frank has said, suspect that the issue is related to the implementation of device tree support in your kernel.
> Specifically that of_find_node_by_path() is not defined if CONFIG_OF is not defined.
> Please check /include/linux/of.h in your 3.10.xx kernel source whether there is a definition for
> of_find_node_by_path() in the case that CONFIG_OF is *not* defined:
>
> static inline struct device_node *of_find_node_by_path(const char *path)
> {
>        return NULL;
> }
>

Browsing the code at bootlin:

https://elixir.bootlin.com/linux/v3.10/source/include/linux/of.h

shows 3.10 failed to provide a stub implementation of
of_find_node_by_path when CONFIG_OF is not defined.

Re: [Linux-gpib-general] make install not using DESTDIR for modules_install

[Frank M. H. <fm...@gm...>]

On Tue, Nov 27, 2018 at 8:03 AM Derek Kozel <der...@gm...> wrote:

> During the linux-gpib-kernel make install process the kernel modules_install command is run bit the DESTDIR argument is not passed in meaning that it will always try to install to the system directory rather than a custom directory. Adding INSTALL_MOD_PATH="$(DESTDIR)" to the command correctly passes the information.
>
> I've tested on Ubuntu 18.10 with and without a DESTDIR specified in the make install step and the results look correct to me. Attached is a patch adding the additional argument.

Thanks, applied.

Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[dave p. <dpe...@gm...>]

Hi Søren,
Thanks for raising this. As Frank has said, suspect that the issue is
related to the implementation of device tree support in your kernel.
Specifically that *of_find_node_by_path() *is not defined if CONFIG_OF is
not defined.
Please check /include/linux/of.h in your 3.10.xx kernel source whether
there is a definition for
*of_find_node_by_path()* in the case that CONFIG_OF is *not* defined:

static inline struct device_node *of_find_node_by_path(const char *path)
{
       return NULL;
}

We may need to create a compat/include/linux/of.h for this.
cheers,
/d

On Wed, Nov 28, 2018 at 8:28 AM Søren Koch via Linux-gpib-general <
lin...@li...> wrote:

> Hi all.
>
>
> I have just tried to install linux-gpib-4.2 on a new CentOS 7 system
> (after running yum update to get latest packages)
>
> When I try to compile the kernel driver i get the following error:
>
>
> >
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:
> > In function ‘fmh_gpib_device_match’:
> >
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:928:4:
> > error: implicit declaration of function ‘of_find_node_by_path’
> > [-Werror=implicit-function-declaration]
> >     of_node = of_find_node_by_path(config->device_tree_path);
> >     ^
> >
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:928:12:
> > warning: assignment makes pointer from integer without a cast [enabled
> > by default]
> >     of_node = of_find_node_by_path(config->device_tree_path);
> >             ^
> > cc1: some warnings being treated as errors
> > make[5]: ***
> >
> [/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.o]
> > Error 1
> > make[4]: ***
> >
> [/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib]
> > Error 2
> > make[3]: ***
> >
> [_module_/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib]
> > Error 2
> > make[2]: [all-local] Error 2 (ignored)
>
> uname -r gives 3.10.0-862.14.4.el7.x86_64
>
>
> configure gave the following output:
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking Linux kernel directory... ok
> checking Linux kernel compile flags... ok
> checking for depmod... /sbin/depmod
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating drivers/Makefile
> config.status: creating config.h
> config.status: config.h is unchanged
>
> I have included the the full output from make:
>
>
> make  all-recursive
> make[1]: Entering directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
> Making all in drivers
> make[2]: Entering directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers'
> make -C /lib/modules/3.10.0-862.14.4.el7.x86_64/build/ V=1 modules\
>         CC="gcc
> -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0
> -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/compat/include"
> \
>         CONFIG_GPIB_ISA="no" \
>
>
> SUBDIRS="/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib"
> make[3]: Entering directory `/usr/src/kernels/3.10.0-862.14.4.el7.x86_64'
> test -e include/generated/autoconf.h -a -e include/config/auto.conf ||
> (                \
> echo >&2;                                                       \
> echo >&2 "  ERROR: Kernel configuration is invalid.";           \
> echo >&2 "         include/generated/autoconf.h or
> include/config/auto.conf are missing.";\
> echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to
> fix it.";      \
> echo >&2 ;                                                      \
> /bin/false)
> mkdir -p
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/.tmp_versions
> ; rm -f
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/.tmp_versions/*
> make -f scripts/Makefile.build
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib
> make -f scripts/Makefile.build
>
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b
> (cat /dev/null;   echo
>
> kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b/agilent_82350b.ko;)
> >
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b/modules.order
> make -f scripts/Makefile.build
>
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a
> (cat /dev/null;   echo
>
> kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a/agilent_82357a.ko;)
> >
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a/modules.order
> make -f scripts/Makefile.build
>
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210
> (cat /dev/null;   echo
>
> kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210/cb7210.ko;)
> >
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210/modules.order
> make -f scripts/Makefile.build
>
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec
> (cat /dev/null;   echo
>
> kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec/cec_gpib.ko;)
> >
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec/modules.order
> make -f scripts/Makefile.build
>
> obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib
>   gcc -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0
> -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/compat/include
>
> -Wp,-MD,/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/.fmh_gpib.o.d
> -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
> -I./arch/x86/include -Iarch/x86/include/generated  -Iinclude
> -I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi
> -I./include/uapi -Iinclude/generated/uapi -include
> ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common
> -Werror-implicit-function-declaration -Wno-format-security
> -fno-delete-null-pointer-checks -std=gnu89 -O2 -m64 -mno-mmx -mno-sse
> -mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone
> -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
> -Wframe-larger-than=2048 -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
> -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe
> -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
> -mno-sse2 -mno-3dnow -mno-avx -mindirect-branch=thunk-extern
> -mindirect-branch-register -DRETPOLINE -Wframe-larger-than=2048
> -fstack-protector-strong -Wno-unused-but-set-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -pg -mfentry
> -DCC_USING_FENTRY -fno-inline-functions-called-once
> -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
> -fconserve-stack -DCC_HAVE_ASM_GOTO
>
> -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/include
> -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fmh_gpib)"
> -D"KBUILD_MODNAME=KBUILD_STR(fmh_gpib)" -c -o
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/.tmp_fmh_gpib.o
>
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c
> make[3]: Leaving directory `/usr/src/kernels/3.10.0-862.14.4.el7.x86_64'
> make[2]: Leaving directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers'
> make[2]: Entering directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
> make[2]: Leaving directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
> make[1]: Leaving directory
> `/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
>
> and it appears that the kernel configuration is wrong, however I have
> not been able to determine why as it is a freshly installed and fully
> updated CentOS7
>
> I have tried reinstalling CentOS but that did not give a different result.
>
>
> Installing linux-gpib-4.1 on the same system works fine (which is a good
> thing as we need GPIB for our data acquisition systems).
>
> Anyone have any ideas?
>
>
> --
> Søren Koch
> Senior Development Engineer
> DTU Energy, Risø Campus
> -------------------------------------------
> Technical University of Denmark
> Department of Energy Conversion and Storage
> Frederiksborgvej 399
> Building 227, 1.sal
> 4000 Roskilde
> Direct +45 46775816
> sq...@dt...
> http://www.ecs.dtu.dk
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Python bindings and a suggestion for improvement

[Frank M. H. <fm...@gm...>]

On Tue, Nov 27, 2018 at 4:19 PM Tomislav Ivek <tom...@gm...> wrote:
>
> The pure-Python VISA backend pyvisa-py has recently stumbled upon a double-close situation with linux-gpib's Python class Gpib.Gpib: https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a design point in Gpib.Gpib which cleans up its GPIB handle only on Python's GC cycle. This is not guaranteed to run when the programmer expects it to and in extreme cases might even leak resources. It appears Gpib.Gpib has no other user-facing method to close its GPIB handle.
>
> This can be resolved by adding a Gpib.close() method for user-controlled cleanup. I hav ealready tested the fix in gpib_ctypes, a cross-platform GPIB binding that aims to be compatible with linux-gpib (https://pypi.org/project/gpib-ctypes/). I would be happy to send a patch for linux-gpib's Python lib.
>
> Please let me know what you think about that.


I'm no python expert, but your change sounds reasonable to me.

Re: [Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[Frank M. H. <fm...@gm...>]

On Tue, Nov 27, 2018 at 11:28 PM Søren Koch via Linux-gpib-general
<lin...@li...> wrote:
> I have just tried to install linux-gpib-4.2 on a new CentOS 7 system
> (after running yum update to get latest packages)
>
> When I try to compile the kernel driver i get the following error:
>

Easiest thing is to go into drivers/gpib/Makefile and disable the
fmh_gpib driver by removing the line that says

obj-y += fmh_gpib/

Your 3.10 kernel probably needs some extra compatibility code to
compile the device tree related code in the fmh_gpib driver.  I don't
think your kernel configuration is wrong.

[Linux-gpib-general] Linux-gpib-4.2 can not compile on CentoOS 7

[Søren K. <sq...@dt...>]

Hi all.


I have just tried to install linux-gpib-4.2 on a new CentOS 7 system
(after running yum update to get latest packages)

When I try to compile the kernel driver i get the following error:


> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:
> In function ‘fmh_gpib_device_match’:
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:928:4:
> error: implicit declaration of function ‘of_find_node_by_path’
> [-Werror=implicit-function-declaration]
>     of_node = of_find_node_by_path(config->device_tree_path);
>     ^
> /root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c:928:12:
> warning: assignment makes pointer from integer without a cast [enabled
> by default]
>     of_node = of_find_node_by_path(config->device_tree_path);
>             ^
> cc1: some warnings being treated as errors
> make[5]: ***
> [/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.o]
> Error 1
> make[4]: ***
> [/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib]
> Error 2
> make[3]: ***
> [_module_/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib]
> Error 2
> make[2]: [all-local] Error 2 (ignored)

uname -r gives 3.10.0-862.14.4.el7.x86_64


configure gave the following output:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking Linux kernel directory... ok
checking Linux kernel compile flags... ok
checking for depmod... /sbin/depmod
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating drivers/Makefile
config.status: creating config.h
config.status: config.h is unchanged

I have included the the full output from make:


make  all-recursive
make[1]: Entering directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
Making all in drivers
make[2]: Entering directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers'
make -C /lib/modules/3.10.0-862.14.4.el7.x86_64/build/ V=1 modules\
        CC="gcc
-I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0
-I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/compat/include" \
        CONFIG_GPIB_ISA="no" \
       
SUBDIRS="/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib"
make[3]: Entering directory `/usr/src/kernels/3.10.0-862.14.4.el7.x86_64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf ||
(                \
echo >&2;                                                       \
echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or
include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to
fix it.";      \
echo >&2 ;                                                      \
/bin/false)
mkdir -p
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/.tmp_versions
; rm -f
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/.tmp_versions/*
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b
(cat /dev/null;   echo
kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b/agilent_82350b.ko;)
>
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82350b/modules.order
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a
(cat /dev/null;   echo
kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a/agilent_82357a.ko;)
>
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/agilent_82357a/modules.order
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210
(cat /dev/null;   echo
kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210/cb7210.ko;)
>
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cb7210/modules.order
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec
(cat /dev/null;   echo
kernel//root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec/cec_gpib.ko;)
>
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/cec/modules.order
make -f scripts/Makefile.build
obj=/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib
  gcc -I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0
-I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/compat/include
-Wp,-MD,/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/.fmh_gpib.o.d 
-nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
-I./arch/x86/include -Iarch/x86/include/generated  -Iinclude
-I./arch/x86/include/uapi -Iarch/x86/include/generated/uapi
-I./include/uapi -Iinclude/generated/uapi -include
./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -std=gnu89 -O2 -m64 -mno-mmx -mno-sse
-mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
-Wframe-larger-than=2048 -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -mindirect-branch=thunk-extern
-mindirect-branch-register -DRETPOLINE -Wframe-larger-than=2048
-fstack-protector-strong -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g -pg -mfentry
-DCC_USING_FENTRY -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO
-I/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/include 
-DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fmh_gpib)" 
-D"KBUILD_MODNAME=KBUILD_STR(fmh_gpib)" -c -o
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/.tmp_fmh_gpib.o
/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers/gpib/fmh_gpib/fmh_gpib.c
make[3]: Leaving directory `/usr/src/kernels/3.10.0-862.14.4.el7.x86_64'
make[2]: Leaving directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0/drivers'
make[2]: Entering directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
make[2]: Leaving directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'
make[1]: Leaving directory
`/root/Downloads/linux-gpib-4.2.0/linux-gpib-kernel-4.2.0'

and it appears that the kernel configuration is wrong, however I have
not been able to determine why as it is a freshly installed and fully
updated CentOS7

I have tried reinstalling CentOS but that did not give a different result.


Installing linux-gpib-4.1 on the same system works fine (which is a good
thing as we need GPIB for our data acquisition systems).

Anyone have any ideas?


-- 
Søren Koch
Senior Development Engineer
DTU Energy, Risø Campus
-------------------------------------------
Technical University of Denmark
Department of Energy Conversion and Storage
Frederiksborgvej 399
Building 227, 1.sal
4000 Roskilde
Direct +45 46775816
sq...@dt...
http://www.ecs.dtu.dk

[Linux-gpib-general] Python bindings and a suggestion for improvement

[Tomislav I. <tom...@gm...>]

The pure-Python VISA backend pyvisa-py has recently stumbled upon a
double-close situation with linux-gpib's Python class Gpib.Gpib:
https://github.com/pyvisa/pyvisa-py/pull/171 This bug is related to a
design point in Gpib.Gpib which cleans up its GPIB handle only on Python's
GC cycle. This is not guaranteed to run when the programmer expects it to
and in extreme cases might even leak resources. It appears Gpib.Gpib has no
other user-facing method to close its GPIB handle.

This can be resolved by adding a Gpib.close() method for user-controlled
cleanup. I hav ealready tested the fix in gpib_ctypes, a cross-platform
GPIB binding that aims to be compatible with linux-gpib (
https://pypi.org/project/gpib-ctypes/). I would be happy to send a patch
for linux-gpib's Python lib.

Please let me know what you think about that.
Tomislav

[Linux-gpib-general] make install not using DESTDIR for modules_install

[Derek K. <der...@gm...>]

Hello,

After a few months I've looped around again to making Debian packages for
linux-gpib-kernel and linux-gpib-user. A big thanks to all the work that
has been done since May, it was much easier this time around and only one
patch is necessary to get started.

During the linux-gpib-kernel make install process the kernel
modules_install command is run bit the DESTDIR argument is not passed in
meaning that it will always try to install to the system directory rather
than a custom directory. Adding INSTALL_MOD_PATH="$(DESTDIR)" to the
command correctly passes the information.

I've tested on Ubuntu 18.10 with and without a DESTDIR specified in the
make install step and the results look correct to me. Attached is a patch
adding the additional argument.

Regards,
Derek

Re: [Linux-gpib-general] ni_usb with multiple devices

[Frank M. H. <fm...@gm...>]

On Thu, Oct 25, 2018 at 2:07 AM Manuel Mommertz <man...@de...> wrote:
> we want to use multiple GPIB-adapter from NI on one host. But there is
> currently no way to fix the association between a GPIB-board and an NI-GPIB-
> adapter. With each reboot we get a random mapping. To fix this quick and dirty
> I prepared the attached patch against linux-gpib-modules-4.2.0-rc1.

Thanks, I applied your patch.  Really, all the drivers should support
selection by device path.  I was just too lazy to update them all.

>
> To fix it the right way, I think there should be another config entry, like
> 'usb_serial'. Would be nice if you can include support for this in future
> versions.

Selecting the hardware by serial number would be fine too (for the
hardware/drivers that provide serial numbers).  There's nothing wrong
with selecting by device path though.

-- 
Frank