On Sun, 14 Aug 2005, Chuck Ebbert wrote:
>
> GCC warns about using llseek and suggests lseek64 instead. That works
> for me, but up till 2.6.11 plain lseek worked too. I guess it really
> shouldn't have?
Well, we have had various special-cases for /dev/[k]mem to try to make it
work even wit
On Sun, 14 Aug 2005 09:24:02 -0700 (PDT), Linus Torvalds wrote:
> Yes, the thing needs to be opened with O_LARGEFILE and you need to use
> "llseek()" to seek into it, but once you do that, everything should be
> fine.
GCC warns about using llseek and suggests lseek64 instead. That works
for m
On Sun, 14 Aug 2005, Chuck Ebbert wrote:
>
> It's ugly but so is the existing code. And it won't fix 64-bit
> archs AFAICT. Tested on 2.6.11, patch offsets fixed up for 2.6.13-rc6.
Btw, if you really want to allow negative ("huge positive") loff_t, then
you should do it the way we did "file
On Sun, 14 Aug 2005, Chuck Ebbert wrote:
>
> The first thing drivers/char/mem.c:read_kmem does is convert the
> loff_t it gets as the offset for reading into an unsigned int. This
> patch makes the kmem driver's llseek operator do that up-front, so
> that fs/read_write.c:rw_verify_area doesn't
On Sun, Aug 14, 2005 at 12:12:52PM -0400, Chuck Ebbert wrote:
> The first thing drivers/char/mem.c:read_kmem does is convert the
> loff_t it gets as the offset for reading into an unsigned int. This
> patch makes the kmem driver's llseek operator do that up-front, so
> that fs/read_write.c:rw_ve
The first thing drivers/char/mem.c:read_kmem does is convert the
loff_t it gets as the offset for reading into an unsigned int. This
patch makes the kmem driver's llseek operator do that up-front, so
that fs/read_write.c:rw_verify_area doesn't return -EINVAL when
we try to read from higher addre
6 matches
Mail list logo
