These changes were to conform to SUS. Also, as Linux/ia32 starts supporting
larger memory etc, apps would like to create larger shm segments, specially
on the upcoming ia64.
This is an API change, but that is expected during a major release.
Unfortunately, they end up breaking ABI on current 64bit kernels, but
we do not want to have the ia64 shmget() accept a int size and perpetuate
this limitation.
Alternatives are: create new [sub]syscall numbers, define the shm
"size" as platform dependent.
Coming to the shmctl(IPC_SET) problem, doesn't gcc pad out the structure
elements on 64 bit compiles to long (8 byte) sized? For shmid_ds, the
first field "shm_perm" fits in 2 longs, the old "shm_segsz" would have
taken up a long too, so all elemtns from "shm_atime" would have had their
offsets preserved. What am I assuming wrong here?
The shminfo breakage is probably unavoidable though ...
I am open to all suggestions towards improving the situation ...
Thanks.
Kanoj
> > The sysctl problems could be probably solved by changing the sysctl
> > number for shmmax.
>
> I don't know what we should do here:
> * if we don't change the sysctl number, then you would need kernel version
> specific code on 64-bit platforms (2.[34]: write a long value; 2.2: write an
> int).
> * if we change the sysctl number, then you need kernel version specific code
> on all platforms.
>
> --
> Manfred
>
>
-
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/