sysv IPC and shminfo ABI

Christian S.J. Peron csjp at
Tue Feb 12 02:00:28 UTC 2008


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

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

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

(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

More information about the freebsd-current mailing list