Date: Sun, 3 Dec 2017 17:52:37 -0500 From: Lee D <embaudarm@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: How do I make my device driver respond to lseek? Message-ID: <CANC_bnOZ=k0WVkjrP8HRqL-88sS%2BvbXy%2BHLQ3fzVAxB3CrOXzQ@mail.gmail.com> In-Reply-To: <20171203173205.GL2272@kib.kiev.ua> References: <CANC_bnNWfk3-QgwCEiRhMyjmQOBH%2Bt%2BXxW8zFp%2B=943nRWvJ4g@mail.gmail.com> <20171203173205.GL2272@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 3, 2017 at 12:32 PM, Konstantin Belousov
<kostikbel@gmail.com> 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANC_bnOZ=k0WVkjrP8HRqL-88sS%2BvbXy%2BHLQ3fzVAxB3CrOXzQ>