All, A while ago, I committed a patch which changed what was a kernel private structure 'shminfo'. In order to access this structure, you must define _KERNEL which suggests to me we should not be making guarantees about it's size. See /usr/src/sys/shm.h The change was incomplete, as the intent of the change was to allow us to use more then 2 Gigs of shared memory. jkim has some patches which completes the change, but they have not been committed yet. However, we do export IPC_INFO which can be used in shmctl(), and we pass this structure to userspace, which to be implies that this change can break the ABI, even though the user has to define _KERNEL to acces the structure. System V IPC is tricky like this. So I guess I have a few questions: (1) Is struct shminfo considered a sys V standard structure that has a predefined size that should be maintained across all architectures? (2) Is this an ABI breakage that we care about? Usually whether or not we want to break the ABI is clear, however in this case I am confused, because we offer IPC_INFO, implement it in the kernel, however we don't expose the details of the structure that shmctl(IPC_INFO) will export. I've done some pretty extensive searching and I can't seem to find any FreeBSD code which implements this. I know that this is late in the release engineering cycle for RELENG_7_0 to be bringing this up, but I want to make sure this isnt going to be a problem moving forward. As I see it, we have a few options: (1) Back the change out now before any damage is done (assuming we care) (2) Apply this safety patch to RELENG_7 and RELENG_7_0 http://people.freebsd.org/~csjp/sysv_shm.1202744975.6_abi_fix.diff (3) Leave things as they are, as we are going to be getting support for large shared memory allocations in the future. (This is why I asked if the structure supposed to be a standard size). I apologize for this, I understand this is probably the last thing we need before the release, but I just want to make sure that we are doing the right thing.Received on Tue Feb 12 2008 - 01:00:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC