scan failure on one backend causes failures on all

[rgetz]

@mhennerich noticed that an ethernet scan failure causes a total scan failure...

I think this is a problem with bad actors on ethernet with a Windows clients.

But will need to check a little bit more...

[rgetz]

right now, we have iio_scan_context_get_info_list() which returns either:

 * @returns On success, the number of contexts found.
 * @returns On failure, a negative error number.

So, in the case we have a partial failure (usb works, but Ethernet does not), how do we want to return things?

• on partial success, just return the number of context found, and don't tell anyone Ethernet failed?

[tfcollins]

What is an Ethernet failure? Is that just it didn't find anything?

[commodo]

So, if it's a bad-actor on the network, we can consider it doesn't exist and continue with the rest that do exist?
We can probably identify a few error codes that make sense to ignore in the network iteration code.

Another option is to extend the API a bit, and add a iio_scan_context_allow_partial_results_set(true) [or some other function call that may be made more extensible, like an iio_scan_context_ioctl() or something], to allow for partial results.

This could probably be useful for local contexts as well [later] when stuff gets added/extended to the local context to do more validation in there.
Right now, local_context_scan() does something like:

static int check_device(void *d, const char *path)
{
        *(bool *)d = true;
        return 0;
}

int local_context_scan(struct iio_scan_result *scan_result)
{
        struct iio_context_info **info;
        bool exists = false;
        char *desc, *uri, *machine, buf[2 * BUF_SIZE], names[BUF_SIZE];
        int ret;

        ret = foreach_in_dir(&exists, "/sys/bus/iio", true, check_device);
        if (ret < 0 || !exists)
                return 0;
.........................

So, check_device() looks fine for a prototype code, but I think we can [probably] squeeze more sysfs ABI validation in there.
That could break some backwards compatibility [at first], so this should probably be kept as a backwards compatible behavior.

[rgetz]

What is an Ethernet failure? Is that just it didn't find anything?

It's when something response that they do have a IIO device via dns-sd, but don't actually have iiod running.

This happens if you have an old install with a iio_services file in /etc/avahai/ ... but no iiod running. The Linux side handles this case, but the windows implementation doesn't like it, and returns a failure.

[rgetz]

I think the issue is - the Linux code actually port knocks, and the Windows code does not...

That is the easiest fix.