From owner-freebsd-hackers@freebsd.org Sun Dec 3 22:53:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 016FCE6AF2C for ; Sun, 3 Dec 2017 22:53:19 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B79966D191 for ; Sun, 3 Dec 2017 22:53:18 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id s4so13271595ote.4 for ; Sun, 03 Dec 2017 14:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ofaUXsI0sl7e2RotCQt2CrphjHE7Q1TDV5Y8mnTt7DM=; b=PoNjMj+hEd7K3m7NarYKKFhnbi2TX+I4fV5G5ojRWfxrMX5fo3ZiZD9P7zs2/OZ/w1 8uRd00nJ7ftI3400OAYOvZqu0Q0bJEZwVme5SGvEm3uiq/h5qOuNh5EU/ELOxPI/jFCa 9dmo7tuFggrzMfsT9TJUw4jIGE/czLSUe7XNNjWq4AgT13yfp/B7xR+Af/+bzOXlPsT0 0YovwMZJRqxV+DEpCeBFDixOpsDAvKrbLr3hVyXuGxeK+3eiuRFFtId/o9E32ouKOAMw srGmhqFnaEJ8T4126ghwVNrCjrVuS3s48MfZLVTXnzcmw528gYeXDjkCjSxAN6YV6CMi /TMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ofaUXsI0sl7e2RotCQt2CrphjHE7Q1TDV5Y8mnTt7DM=; b=sStLtl+I9L+6SLkfMWo8Lnxpvk++niffGlDLrDotygjcIf7j6PLGy7sIGvQJpWux/Y a/PZ1Hm6F+ZdQ8/wVfx+DcCOS33gmxamJ3mFrwF7eNbdbb+JpSsa+lYvXrCz8Y4gZPO3 heslVhUdhIJnoo8m1Q67AXOUTEDox+qiipT1dlh2FU27fWLU40ujNpU7oUONea6tSs5p O50Qvy/2Bmo1X6IlOUaF/V7QbKe8ZL1kWnkQV/uB/H8wASdo1Mwd+aKYuKcK4/9t86Db S+aNBX5vLNIVTlo+WC3aIM4YVc1TZPCUw0nUQQKCS4DpJ3HC2lsoEYQCjjBflBErYh3F IuUQ== X-Gm-Message-State: AJaThX5jYv/X92ftHTm3qPXntJD//QeGmgN74umEmMphCqvgX806UeS2 rGCcL6HGfF0SuLyYnzkPPHNULhidmE5o6V3u9BU= X-Google-Smtp-Source: AGs4zMbeCSOKkq0Vme+tY0ZN35vRHywREtWMc+zjB4nHJP6Y67nY0xN1URN56dwiKVXvpG71o7tHwFT5ltI9rnENfTI= X-Received: by 10.157.42.9 with SMTP id t9mr14435025ota.233.1512341597847; Sun, 03 Dec 2017 14:53:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.47 with HTTP; Sun, 3 Dec 2017 14:52:37 -0800 (PST) In-Reply-To: <20171203173205.GL2272@kib.kiev.ua> References: <20171203173205.GL2272@kib.kiev.ua> From: Lee D Date: Sun, 3 Dec 2017 17:52:37 -0500 Message-ID: Subject: Re: How do I make my device driver respond to lseek? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 22:53:19 -0000 On Sun, Dec 3, 2017 at 12:32 PM, Konstantin Belousov wrote: > On Sun, Dec 03, 2017 at 12:13:16PM -0500, Lee D wrote: >> Hi, >> >> I've been trying to figure out how to make my device driver respond to >> lseek(). There doesn't seem to be an appropriate entry in the cdevsw >> structure (in src/sys/sys/conf.h). >> >> Obviously I can make an ioctl() call for this (and I have, in the >> interim), but I'd like to do it it the right way. >> >> I have a feeling like I am misunderstanding some critical abstraction >> layer... But at some point the device driver must be told what >> position to start reading from/writing to, right? >> >> FWIW, this is a device driver interface to a SPI flash in my custom >> ARM embedded system. I need to be able to locate to a point in the >> flash to read and write my app config info, without disturbing my boot >> loader. >> >> I want to be able to write code like this: >> >> int fd = open ("/dev/my_spi_flash0", O_RDWR); >> lseek(fd, 0x10000, SEEK_SET); >> write(fd, buf, 100); >> close(fd); >> >> Does anyone know the proper way to implement lseek? > > You did not say which driver you implement. > > It could be devfs cdev, with only supported d_read/d_write methods. In > this case, io request parameters are packed into struct uio, including > the offset where io starts. > > Or you might implement it as proper block-oriented device by providing > d_strategy. Then struct bio contains the block number. > > Or your driver might be geom disk, see geom/geom_disk.h, in which case > disk_strategy method takes struct bio as well. > > Last reasonable variant is to have driver implementing CAM SIM, then > sim_action processes ccb's, also holding all needed information about > io request parameters. It is a devfs cdev, which is what I am using for everything. uio->uio_offset is exactly what I was looking for. My driver now works perfectly with lseek. thanks!