Thanks for your comments!
> we cannot rename the user space structures:
> msqid_ds,... are predefined names from the SUS standard, we
> must rename the kernel structures.
The kernel headers should not be included in user applications, since
glibc provides its own headers defining msqid_ds, semid_ds, shmid_ds, etc.
This will only be a problem if someone wants to include the kernel headers
directly in his/her application (did the old libc5 do it this way,
though?)
> and: I don't know if the new version or the old version should
> be the default:
> Many applications don't care about the uid field,
> but with your patch applied, all recompiled programs
> would fail on 2.2 kernels.
My plan is to modify glibc to do the following:
- new applications should always compile to use the new structures
and 32-bit UIDs
- glibc will include code to convert between the old structures
and new structures in case it is running on an old kernel.
Once this is done, there will not be any problems. At present, my patch to
glibc doesn't make any changes to sysvipc at all, so the old 16-bit UID
structures are still being used.
> But I agree that we must change something (the user space
> code that I use to increase the message queue size > 64 kB
> is "interesting")
I could have stuck in the high UID and GID in a similar manner, but this
would mean breaking DIPC because there were only 2 32-bit words left in
the shmid_ds structure, and one was already claimed by DIPC. In any case,
I thought that it would be cleaner to just start over with new structures.
I haven't looked at the relevant standards committee documents (SuS), so
perhaps I should be leaving more space for other things...
> > rather than toss all the new code into the already hairy msgctl(),
> > semctl(), and shmctl() functions.
>
> or: we could replace the "copy_to_user()" functions.
> ie. "copy_semid_ds_to_user(src,dest,version)"
> version=0 -> automatically convert
> version=1 -> normal copy_to_user
I could do that as well. Another minor problem with the code right now is
that it uses more stack space than it potentially could (due to the fact
that both the old and new structures are allocated on the stack). I'll
look into fixing this in the next version of the patch.
(the simple fix, declaring a union of both the old and new structure,
doesn't work because when copying from user space, both an old and new
structure need to be around-- this will be a simple rewrite)
-Chris Wing
wingc@engin.umich.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/