tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


> There is no problem.  O_NOACCESS would be 3.  When converted from O_*
> to F* it becomes 0.

And that is indeed what I did.  FFLAGS() and OFLAGS() become more
complex than just adding and subtracting 1, but that's not difficult to
deal with.  (If anyone's curious exactly what I did, look at the three
commits ending with 5215f8f6551df407d7c87c8e6a80c7b04e9ee844 in the git
repo git://

> The fact that the O_ flags were not intelligently specified aeons ago
> so that a conversion is required is regrettable, but at this point
> unfixable.

Actually, I disagree.  It is totally fixable.

Well, it's unfixable in the sense that we can't change the past choice.
But it is fixable in that we do not have to be remain crippled by that

Quite aside from someone just having the courage to bite the bullet and
write off compatability with such ancient code (are there any known
extant examples?), it's possible to do something like

#define O_MODERN 4 /* or whatever */

In the libc open() stub, check O_MODERN.  If set, just call the
syscall.  If not, call _really_ancient_compat_open or some such (which
latter would be under the control of the relevant COMPAT_* option, and
would perform the historical mapping) - or, maybe, just do the mapping
in libc.

I'm not sure it's worth it, though, just for the sake of eliminating

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML      
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index