Robert Watson wrote:
>
> On Wed, 16 Oct 2002, Maxim Sobolev wrote:
>
> > What about source-level compatibility, which IMO is a good thing, at
> > least if it doesn't add too much complexity (it clearly doesn't in this
> > case)? Also, handling single flag should be easier from the coding
> > perspective than a load of new values, after all we can do something
> > like:
>
> I'm not convinced there's any value to providing the backward
> compatibility that has to be asked for: the only benefit to the current
> short-based API is that it allow serious security holes while not
> following the standard API offered by other platforms (except Linux).
> Freshly compiled applications should be using the proper types to
> represent uid's and gid's -- if they're not doing that in the existing
> code, they'll get truncated to the right size for "bug compatibility". If
> they are using the correct size, they'll work correctly. To be able to
> run properly on other platforms (vis Solaris), they already should be
> using those types.
Actually I am not proposing to keep the current short-based API. As I
stated in my previous message, with such system in place all
freshly-recompiled apps will use the new ABI automagically.
> And it's not like the approach you've described makes it any easier to
> implement: you still have to break out the old and new structures since
> changing ipc_perm breaks the ABI for all of the System V interfaces,
> rewrite the kernel code, etc. You might as well have added the
> compatibility system calls since you still have to do all the mapping.
I don't quite understand what you are trying to say. Linux does the
following on the beginning and the end of each {shm,sem,msg}ctl call:
{shm,sem,msg}ctl(...)
{
if (IPC_64 flag is not set) {
convert user-supplied structure to a new 64-bit format
}
proceed as usual using 64-bit structure
if (IPC_64 flag is not set) {
convert result to be transferred back to user into old format
}
return
}
This is apparently much more compact, ABI-safe and easier to implement
and maintain since we don't have two versions of mostly the same code.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
