Date: Sun, 13 Nov 2011 10:54:27 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: perryh@pluto.rain.com Cc: tim@kientzle.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call Message-ID: <15483.1321181667@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 12 Nov 2011 20:57:03 PST." <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com>, perryh@pluto.rain .com writes: >Warner Losh <imp@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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15483.1321181667>