[PATCH] fadvise(2) system call

[Kostik Belousov]

On Sun, Nov 13, 2011 at 10:54:27AM +0000, Poul-Henning Kamp wrote:
> In message <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh at pluto.rain.com>, perryh at pluto.rain
> .com writes:
> >Warner Losh <imp at bsdimp.com> wrote:
> 
> >> >> wrote:
> >> >>> ... seek(2) is badly broken on tape drives.
> >> >>> It does nothing and doesn't return an error ...
> >> >> 
> >> >> Honestly, I think we've got bigger problems to worry about
> >> >> than whether lseek() works on magnetic tape drives ...
> >> > 
> >> > True, but failing silently -- doing nothing but not returning an
> >> > error -- is a POLA violation.  Those are worth fixing simply on
> >> > principle.
> >>
> >> Early Unix layering made that kinda hard... :(
> >
> >and yet, it somehow manages to return an error if applied to a pipe.
> >There must be some point at which the inode type affects the result.
> 
> There is a big difference:  pipes operate at the fdesc level, devices
> sit behind what can best be explained as a symlink into a different
> name-space, and the cdevsw API does not pass the fdesc offset in.
I do not think this is true. Devfs does pass the file offset as
uio_offset to the cdevsw read and write methods. Also, the dev nodes
are marked as seekable.

Drivers can see the file offset and operate on them properly, but not at
the lseek(2) time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20111113/79d14add/attachment.pgp