Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2434523pxb; Sun, 28 Feb 2021 00:54:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJzdfGkvdii0PC/tMkxmlJzNBc0d2rBl7SbkdxO+h3lVrrw2BsLMMZwk9vjWJSt/yJuIlnZi X-Received: by 2002:a17:906:2ad8:: with SMTP id m24mr11052915eje.512.1614502466022; Sun, 28 Feb 2021 00:54:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614502466; cv=none; d=google.com; s=arc-20160816; b=zs6F1+rAq/0EOoeI6Ruv6iiKO8E1uH64Scyw9Vr1zbrwJyQPI1r1VNbiIibdquWWQ7 Bkqw7f2n6akH9u2sKsLBDQ0cngyxG1g1BhWr9J+m2iX355C8DR6a/qrUzOZry0Rl+pgp /i36Guixygd2W4l4Rt+Ourb0W9qQB/VKzoorJzoQSNfiQHTLNIPqiGdyT5ZwHkMgImBq fQEAOXsWD9RyqKFhpDrtuZu9B8bTuWL0S1sDyXHwdhW5XtKlOQ1L9fLDRnRnte3NpiYa NJhMhIjJLk4K07rDZQoxgUhpBeWmGtNKmJXh1CEfLMCN+NtpXhfppJqtZQnt1HkecGeW kVhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=8E7c/Z1a3sjaUgQcFNKtXe/vCdCcKhkLNcrSGUpc+Dc=; b=i1NC2cAA/puN6Vap2DuwT7Z/gZwGHa182X8i5wCC/N3bBr6JwmXntWHtVj/OInDWVG uNPSPMsrnOcFrECnZh1dVH430sCio5jpbda+WD+vOAXRWlwxdv1zFR20gJhUEVhUsXQY i+P+4yOZsqj41q9nUcQZeABiKKpfPA5Gk5YDVRXOfb1Zzz3LfgoIM4XOTywjXKmJTQw+ nGEU94chYhnDhguv3QIlA2eiMjDB36EkV1KCHD8GC23+wJUbl728cprpGaPvWErauiEO gJOCHVskZxhj2JmPIf0EszEw9Yt9xYMEifdjwHzFytwaz2mIQIQSXN1bgdttC5n2hCUI Lhxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metafoo.de header.s=default2002 header.b=b9CDjPxR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gf2si9252020ejb.736.2021.02.28.00.54.02; Sun, 28 Feb 2021 00:54:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@metafoo.de header.s=default2002 header.b=b9CDjPxR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230423AbhB1IwW (ORCPT + 99 others); Sun, 28 Feb 2021 03:52:22 -0500 Received: from www381.your-server.de ([78.46.137.84]:51004 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230299AbhB1IwV (ORCPT ); Sun, 28 Feb 2021 03:52:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=8E7c/Z1a3sjaUgQcFNKtXe/vCdCcKhkLNcrSGUpc+Dc=; b=b9CDjPxRY25Ro8Z29cvKdM1Zhq u4SL10j/hWm5n21f5KIfQumem74DS8D9zrmeOwSfC99+/CPAoXf/9UZec0U1WZ2XEFvn8cpmX5Rb/ zi4k2aeZVsc0ACX3yNjZoR1cjcFFrbcc+ikpLS5oj7siHXWF2z4hS1gLQlnUqw+LlFcZEW4JLjyLL iPBZN5O0Wj36a+if0HS/+1fDgRrNOptynwvrvofK27oNWE5WWHsvKXz3TPTaoggsizSW8Hgc5z+9X mMMQmci/3yDvUpoDdJeRi79i1ZJlvAZiZN5QwByssMJkhm6+m1Tbg4MsEg8mZk7t46beplMhNX4x3 boxMcTTA==; Received: from sslproxy06.your-server.de ([78.46.172.3]) by www381.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lGHne-0009ch-KT; Sun, 28 Feb 2021 09:51:38 +0100 Received: from [62.216.202.180] (helo=[192.168.178.20]) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGHne-000N8B-Em; Sun, 28 Feb 2021 09:51:38 +0100 Subject: Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support opening extra buffers for IIO device To: Alexandru Ardelean , linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org Cc: Michael.Hennerich@analog.com, jic23@kernel.org, nuno.sa@analog.com, dragos.bogdan@analog.com References: <20210215104043.91251-1-alexandru.ardelean@analog.com> <20210215104043.91251-21-alexandru.ardelean@analog.com> From: Lars-Peter Clausen Message-ID: <877ca331-1a56-1bd3-6637-482bbf060ba9@metafoo.de> Date: Sun, 28 Feb 2021 09:51:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210215104043.91251-21-alexandru.ardelean@analog.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.102.4/26093/Sat Feb 27 13:05:31 2021) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/15/21 11:40 AM, Alexandru Ardelean wrote: > With this change, an ioctl() call is added to open a character device for a > buffer. The ioctl() number is 'i' 0x91, which follows the > IIO_GET_EVENT_FD_IOCTL ioctl. > > The ioctl() will return an FD for the requested buffer index. The indexes > are the same from the /sys/iio/devices/iio:deviceX/bufferY (i.e. the Y > variable). > > Since there doesn't seem to be a sane way to return the FD for buffer0 to > be the same FD for the /dev/iio:deviceX, this ioctl() will return another > FD for buffer0 (or the first buffer). This duplicate FD will be able to > access the same buffer object (for buffer0) as accessing directly the > /dev/iio:deviceX chardev. > > Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as the > index for each buffer (and the count) can be deduced from the > '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of > bufferY folders). > > Used following C code to test this: > ------------------------------------------------------------------- > > #include > #include > #include > #include > #include #include > > #define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int) > > int main(int argc, char *argv[]) > { > int fd; > int fd1; > int ret; > > if ((fd = open("/dev/iio:device0", O_RDWR))<0) { > fprintf(stderr, "Error open() %d errno %d\n",fd, errno); > return -1; > } > > fprintf(stderr, "Using FD %d\n", fd); > > fd1 = atoi(argv[1]); > > ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &fd1); > if (ret < 0) { > fprintf(stderr, "Error for buffer %d ioctl() %d errno %d\n", fd1, ret, errno); > close(fd); > return -1; > } > > fprintf(stderr, "Got FD %d\n", fd1); > > close(fd1); > close(fd); > > return 0; > } > ------------------------------------------------------------------- > > Results are: > ------------------------------------------------------------------- > # ./test 0 > Using FD 3 > Got FD 4 > > # ./test 1 > Using FD 3 > Got FD 4 > > # ./test 2 > Using FD 3 > Got FD 4 > > # ./test 3 > Using FD 3 > Got FD 4 > > # ls /sys/bus/iio/devices/iio\:device0 > buffer buffer0 buffer1 buffer2 buffer3 dev > in_voltage_sampling_frequency in_voltage_scale > in_voltage_scale_available > name of_node power scan_elements subsystem uevent > ------------------------------------------------------------------- > > iio:device0 has some fake kfifo buffers attached to an IIO device. For me there is one major problem with this approach. We only allow one application to open /dev/iio:deviceX at a time. This means we can't have different applications access different buffers of the same device. I believe this is a circuital feature. It is possible to open the chardev, get the annonfd, close the chardev and keep the annonfd open. Then the next application can do the same and get access to a different buffer. But this has room for race conditions when two applications try this at the very same time. We need to somehow address this. I'm also not much of a fan of using ioctls to create annon fds. In part because all the standard mechanisms for access control no longer work.