Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 22 Jun 2020 09:42:25 -0700 | Subject | Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling" |
| |
On Mon, Jun 22, 2020 at 6:38 AM Bruno Meneguele <bmeneg@redhat.com> wrote: > > However, the issue with glibc is their fd checking on dprintf using: > > lseek(offset == 0, whence == SEEK_CUR) > > Which, technically, isn't a relative seek operation in my opinion, thus > I'm also not sure that returning EINVAL is correct.
Well, I'm not sure there is a "correct". Normal file descriptors are seekable or not, this is kind of a special one. It's not like you can read it byte for byte anyway.
There is a "historical behavior".
> Would it make sense to return the next buffer index instead? Basically > the same as SEEK_END does? The first "if (offset)" in the function would > prevent any real relative move while SEEK_CUR would return a valid > address following this buffer behavior of specific points it could seek > to.
Maybe. At the same time, the way we don't actually return a real position means that that's very dangerous too. We'll always return "we're at position zero".
And we never accept byte-by-byte reads and require a "get the whole record" model.
So I think we might as well accept "kmsg is special".
I don't have hugely strong opinions on it - I certainly agree that "SEEK_CUR with offset zero could be a no-op", but I also don't think there's a huge reason to try to change it, considering just _how_ special kmsg is.
Linus
| |