>>> To the extent that it's impossible, it's impossible only because
>>> the APIs provided by the kernel to userland don't have any way to
>>> represent such a thing. This would border on trivial to fix,
>>> except that it would be difficult to get much userland code to use
>>> the resulting APIs
On Wed, May 10, 2023 at 10:11:31AM +, Taylor R Campbell wrote:
> > > (In general, erroring in I/O is a whole additional can of worms; it's
> > > wrong to not report back however much work happened before the error
> > > when it can't be undone, but also impossible to both report work and
>
If we think too hard about making this precise we'll wind up with
names like uiosimulateviolatingnocloningtheorem and uiowavecollapse.
uioskip serves either to discard data without consuming it, or to
advance the pointer after using the data with uiopeek.
peek is in contrast to get, like
>> - uiopeek leaves uio itself untouched ([...]).
> Hmâ?? Iâ??m having second thoughts about uiopeek(), as well. It implies a d$
That is a good point. But would it be a problem to have uiopeek
(works only to move from uio to buffer) and uiopoke (the other way)?
I've never liked the way uiomove
On 2023-05-10 14:00, Jason Thorpe wrote:
On May 9, 2023, at 3:09 PM, Taylor R Campbell
wrote:
- uiopeek leaves uio itself untouched (it may modify the source/target
buffers but it's idempotent).
Hm… I’m having second thoughts about uiopeek(), as well. It implies a
direction (“peek”
> On May 9, 2023, at 3:09 PM, Taylor R Campbell
> wrote:
>
> - uiopeek leaves uio itself untouched (it may modify the source/target
> buffers but it's idempotent).
Hm… I’m having second thoughts about uiopeek(), as well. It implies a
direction (“peek” feels like “read”, and “write” would
> Date: Tue, 9 May 2023 23:03:27 -0400 (EDT)
> From: Mouse
>
> > (In general, erroring in I/O is a whole additional can of worms; it's
> > wrong to not report back however much work happened before the error
> > when it can't be undone, but also impossible to both report work and
> > raise an
> (In general, erroring in I/O is a whole additional can of worms; it's
> wrong to not report back however much work happened before the error
> when it can't be undone, but also impossible to both report work and
> raise an error. [...])
To the extent that it's impossible, it's impossible only
On Tue, May 09, 2023 at 09:21:38PM +, Taylor R Campbell wrote:
> I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
> together are equivalent to successful uiomove(buf, n, uio).
>
> This allows a driver to separately:
> 1. transfer data into a buffer (uiopeek) first, and
>> I'm not a fan of uioskip() as a name - [...]
> I agree. "skip" seem to have wrong connotations (cf. dd(1)).
I'm not sure I agree. (The dd analogy is weak; dd has no peek
operation, and uioskip - under whatever name - would border on useless
without uiopeek.)
For uioskip, it _is_ skip
On Tue, May 09, 2023 at 14:33:26 -0700, Jason Thorpe wrote:
> I'm not a fan of uioskip() as a name - I think uioadvance() would be
> better. Skip implies, to my brain, that the data is being thrown
> away (even if you're already consumed it).
I agree. "skip" seem to have wrong connotations
> On May 9, 2023, at 2:21 PM, Taylor R Campbell
> wrote:
>
> tl;dr
>
> I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
I’m not a fan of uioskip() as a name … I think uioadvance() would be better.
Skip implies, to my brain, that the data is being thrown away (even if
> I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
> together are equivalent to successful uiomove(buf, n, uio).
For what it may be worth, I like this. I don't _think_ I've ever run
into issues caused by this issue before, but I have trouble seeing it
as anything other than a bug
tl;dr
I propose adding uiopeek(buf, n, uio) and uioskip(n, uio) which
together are equivalent to successful uiomove(buf, n, uio).
This allows a driver to separately:
1. transfer data into a buffer (uiopeek) first, and then
2. advance the uio (uioskip) only after determining how much of the
14 matches
Mail list logo
