(I am not Linus, but..)
Sergei, Do you mean that you are compiling code in
pre-GLIBC-2.0 environment which uses <linux/msg.h>
in user programs ?
In GLIBC 2.0/2.1 the <linux/msg.h> header should *not* be
included by user-space software, and thus you should not have
any grievances about this issue. (See <sys/msg.h> )
The new interface even is binary compatible with old *binaries*.
What happens to the 'u_short' fields when the amount of data
in IPC queue exceeds 'u_short' value range is that apparently
the real value is stored there modulo 'u_short' value range..
(e.g. 128k+10 bytes will appear to your old binaries as 10 bytes.
Not as - for example - USHORT_MAX value.)
Yeah, suboptimal, somewhat dangerous even.
> If the changes are included, the whole bunch of programs are broken. It's
> fixable, but I don't want to waste my time on an unnecessary work. If the
> changes are NOT included, the acXX patches has to be reworked to get the old
> IPC back...
Where did it go ? I see it still.
> Can you inform us of your decision ?
> =======================================================================
> Serguei Koubouchine aka the Tamer < > The impossible we do immediately.
> e-mail: ksi@gu.net SK320-RIPE < > Miracles require 24-hour notice.
/Matti Aarnio <matti.aarnio@sonera.fi>
Anybody interested in files over 2G in size in i386 systems ?
Contact me, dangerous work-in-progress code soon available
for brave experimenters for 2.1.131+ at:
ftp://mea.tmt.tele.fi/linux/lfs-patches-21131ac-v**.diff
(old stat() yields ULONG_MAX for filesizes exceeding 4G-1 at
32-bit systems..)
-
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/