RE: [PATCH] [SYSVIPC] Change shm_tot from int to size_t

[Makhlis, Lev]

Andries Brouwer wrote:
> On Fri, Jun 25, 2004 at 04:56:32PM -0500, Makhlis, Lev wrote:
> 
> > What do you think about following the example of sys_statfs 
> in sys_shmctl?
> 
> I don't mind. It is fairly unimportant - just the informative stuff
> printed by
> 
> % ipcs -m -l
> 
> ------ Shared Memory Limits --------
> max number of segments = 4096
> max seg size (kbytes) = 32768
> max total shared memory (kbytes) = 8388608
> min seg size (bytes) = 1
> 
> (but it seems a pity to deny user space this information if only
> one field is large).
> 

Yes, I thought it might be a little heavy-handed, but I figured, if it's
good enough for statfs...  Also, the values in "ipcs -m -l"
(1) come from IPC_INFO shmctl (separate from SHM_INFO) and
(2) are also available in /proc/sys/kernel (except for shmmin, which is
constant anyway).

On a tangential issue, I think it would be nice if an app could get the
actual values it wants, rather than just know that they are unreliable.
With statfs, that's possible thanks to the existence of statfs64, which
is 64-bit wide even in 32-bit world.
With {shm,sem,msg}ctl, we do have struct shminfo64 etc., but I'm not
sure why they exist at all, as they seem always to have the same bitness
as the default structures.
On the other hand, sys_shmctl() has forever had a comment about replacing
it with a /proc interface.  This has been done for {SHM,SEM,MSG}_STAT calls
(/proc/sysvipc/{shm,sem,msg}), but not for {IPC,SHM,SEM,MSG}_INFO calls.
Some of the *_INFO values are exposed in /proc, but only the sysctl-able
ones.
So I'm writing a patch to create /proc/sysvipc/{shm,sem,msg}info.  This
will allow ipcs and anyone else to access the values using a
bitness-agnostic
interface.  (But exactly because these values aren't that important, I'm
afraid no one may care enough to apply it.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/