>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
