Subject: Re: semconfig(2) and ipcs [sommerfeld@netbsd.org: CVS commit: syssrc]
To: None <sommerfeld@netbsd.org>
From: Simon Burge <simonb@netbsd.org>
List: tech-kern
Date: 05/29/2000 17:30:22
Bill Sommerfeld wrote:

> > Is it worth blowing away the semconfig() syscall altogether?  If the
> > only reasonable user was ipcs(1), then we may not even have to worry
> > about keeping the syscall for backwards compat either...
> 
> Yes, but regardless of how obscure the system call is, I wanted to
> make this change in a way that didn't break kernel-user binary
> compatibility.
> 
> My intention here was to:
>  0) fix what was left of the wedging problem ASAP 
> and then, when i had a chance to do this under less time pressure:
>  1) tweak ipcs(1) to stop using it
>  2) move the syscall under COMPAT_14

Tis cool, just wondering.  I see you've nuked the calls to semconfig in
ipcs already.

> > Also, is it worth sysctl'ing the retrieval of SysV IPC info?  ...
> > Yet another setgid bit gotten rid of, and if new need to do any locking
> > to ensure the integrity of the results it can be done in-kernel...
> 
> Doing this would be great.  At the moment I've got a bunch of other
> things to deal with..  be my guest..

I see one biggish problem so far - there's pointers and some other nasty
unfixed-size types like size_t (unsigned long on some arch's) and key_t
(long everywhere) inside the 'struct *id_ds' structures, which break the
compat32 scenario.  There's three ways that I can see to attack this:

 1) Leave structures as-is - ipcs(1) may not run under compat32 emulation
    on 64 bit CPUs.
 2) Sanitize the sysctl return data ala what I did with the KERN_PROC2
    sysctl.
 3) Change the contents to fixed size components - could be painful
    because the contents of these are exported to userland.

1 is easiet (!) and 3 is probaby the most work.  It's interesting to
note that we typedef msgqnum_t as an 'unsigned long' and msglen_t as a
size_t, but the manpages on www.opengroup.org say to use 'unsigned int'
for both.  Here we win because int is 32 bits even on 64 bit machines
(will this ever change?).  Also, at least 'shm_segsz' has to be a
size_t which isn't compat32 clean on say sparc/sparc64 where size_t is
'unsigned long'.  Any work done this path will probably involve lots of
syscall renaming and other fun.

2 means we end up with some goo like

	struct msqid_ds_sysctl {
		uid_t		uid
		gid_t		gid
		uid_t		cuid
		gid_t		cgid
		mode_t		mode
		u_int64_t	key

		u_int64_t	msg_qnum;
		u_int64_t	msg_qbytes;
		pid_t		msg_lspid;
		pid_t		msg_lrpid;
		time_t		msg_stime;
		time_t		msg_rtime;
		time_t		msg_ctime;
		u_int64_t	msg_cbytes;
	};

in each of the SysV IPC header files.  However, I'm thinking that this
is the best option at the moment - I don't want to leave the compat32
case out in the cold...

Comments?


Also, is it sufficent to wrap anything visible from these headers in

	#if !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)
	...
	#endif /* !_POSIX_C_SOURCE && !_XOPEN_SOURCE */

?

Simon.