>>> 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 01:08:27AM +, Taylor R Campbell wrote:
> I propose to add new config_*_acquire/release functions:
> dev = config_found_acquire(...);
> ...
> config_detach_release(dev);
Seems reasonable...
(note, haven't read the diff carefully yet)
--
David A. Holland
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
