tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PROPOSAL: Split uiomove into uiopeek, uioskip
>>> 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 because of their lack of portability to other
>>> UNIX variants.
> Since write(2) is one of the oldest interfaces in Unix the chances of
> any change taking hold are vanishingly small...
Oh, I'm not suggesting that write(2) change. What I'm suggesting is
the creation of some alternative interface, write_extended(2) let's
call it for the sake of concreteness[%], which is just like write(2)
except that it _does_ provide some way to unambiguously return "wrote
N, then error E". (Exactly how is pretty much irrelevant; I'm sure
practically everyone here can imagine plenty of possible alternatives.
If it comes to arguing choices for that, I'd paint the bikeshed a dark
forest green.) But write(2) would continue to exist, with more or less
its traditional semantics. Only if - and only when - write_extended
becomes so popular that nobody uses plain write(2) any longer would I
propose removing it.
[%] If anything like this happens I certainly hope someone will invent
a better name.
But userland uptake for write_extended will be minimal, especially
initially; that's the portability issue I was talking about.
> All of this is not _independent_ of fixing uiomove callers, [...],
> but it's largely orthogonal to the original problem of incorrectly
> rolling back partial uiomoves. :-(
Agreed.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index