HEADSUP: cygserver now has MSG, SEM and SHM support

[Nicholas Wourms]

vinschen@redhat.com wrote:

> On Sat, Nov 29, 2003 at 11:21:01AM -0500, Nicholas Wourms wrote:
> 
>>  In this respect, I think compatibility should 
>>trump strict adherence to the SuSv3.  Perhaps the right approach to 
>>dealing with nonstandard stuff in the headers would be to use 
>>_POSIX_C_SOURCE #if's, i.e.:
>>#if _POSIX_C_SOURCE < 200112L
>>non-standard code...
>>#endif
> 
> 
> Could you be a bit more specific about what is wrong or missing from
> your point of view?

Nothing is wrong, per se.  Please keep in mind that these were only 
minor concerns, nothing to be overly concerned about.

What I was looking at I noticed that we also #ifdef'd out the member 
pointers msg_{first,last} of the structure msqid_ds.  However these are 
defined as public members on both bsd and solaris[1].  Furthermore, a 
number of manpages for list them in the public declaration of the 
structure. However, I am not an expert on SystemV IPC.  Much of what I 
do know is from reading "Advanced Unix Programming", which is admittedly 
FreeBSD-centric, so I could be wrong.

The more I think about it, your course of action makes sense to me, 
since there is nothing wrong with erring on the side of prudence.  We 
can always add "potential" missing elements to userland when and if the 
need arises.

> Ok, the struct msgbuf is defined in Linux but it's only defined if 
> __USE_GNU is given, which isn't by default.  If you like we can add
> the struct but only with an appropriate #ifdef as in Linux.  It's
> pretty clear from SUSv3 that the struct must be defined by the
> application itself and the definition in sys/msg.h is only a *template*.

I know, that's why I said it was a minor thing.  I think your idea to 
#ifdef __USE_GNU makes sense to me, and I stand corrected now that I've 
gone back and looked at it.  I encountered this while porting some of 
the ipc stress tests from the LTP, and I jumped the gun.

> Anything else?  Please keep in mind that all the stuff which is guarded
> by _KERNEL is either only for usage in the internal implementation or
> by ipcs.  Since we have our own ipcs, there's no reason to chnage this
> to be backward compatible with cygipc's ipcs.

I agree, my main concerns were about items, excluding those only for 
ipc{cs,rm}, which were public to BSD userland but made private to us.

Thanks for setting me straight on some of my misunderstandings.

Cheers,
Nicholas

[1] 
http://www.mit.edu/afs/athena/astaff/project/bootkit/solarisinstall/29/source/proto/usr/include/sys/msg.h