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