On Sun, Jun 21, 2020 at 9:02 PM Jason A. Donenfeld wrote:
> This commit broke userspace. Bash uses ESPIPE to determine whether or
> not the file should be read using "unbuffered I/O", which means reading
> 1 byte at a time instead of 128 bytes at a time. I used to use bash to
> read through kmsg
On Mon, Jun 22, 2020 at 10:32:51AM -0700, Linus Torvalds wrote:
> On Mon, Jun 22, 2020 at 10:10 AM Bruno Meneguele wrote:
> >
> > Although both options are pretty fine by me too, I "fear" (not really)
> > we can end up stacking special behavior interfaces, forcing userspace to
> > keep a "table
On Mon, Jun 22, 2020 at 10:10 AM Bruno Meneguele wrote:
>
> Although both options are pretty fine by me too, I "fear" (not really)
> we can end up stacking special behavior interfaces, forcing userspace to
> keep a "table of special case files". Personally, I prefer to return
> something _valid_
On Mon, Jun 22, 2020 at 09:42:25AM -0700, Linus Torvalds wrote:
> > 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
On Mon, Jun 22, 2020 at 6:38 AM Bruno Meneguele 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
On Sun, Jun 21, 2020 at 08:50:09PM -0700, Linus Torvalds wrote:
> On Sun, Jun 21, 2020 at 8:02 PM Jason A. Donenfeld wrote:
> >
> > This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809.
> >
> > This commit broke userspace. Bash uses ESPIPE to determine whether or
> > not the file should
On Sun, Jun 21, 2020 at 8:02 PM Jason A. Donenfeld wrote:
>
> This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809.
>
> This commit broke userspace. Bash uses ESPIPE to determine whether or
> not the file should be read using "unbuffered I/O", which means reading
> 1 byte at a time
This reverts commit 8ece3b3eb576a78d2e67ad4c3a80a39fa6708809.
This commit broke userspace. Bash uses ESPIPE to determine whether or
not the file should be read using "unbuffered I/O", which means reading
1 byte at a time instead of 128 bytes at a time. I used to use bash to
read through kmsg in a
8 matches
Mail list logo
