Date: Thu, 19 Jun 2003 13:02:06 +0400 From: Dmitry Sivachenko <demon@freebsd.org> To: Gary Jennejohn <garyj@jennejohn.org> Cc: hackers@freebsd.org Subject: Re: struct ipc_perm Message-ID: <20030619090206.GC94651@fling-wing.demos.su> In-Reply-To: <200306190856.h5J8ufPJ002065@peedub.jennejohn.org> References: <20030618162547.GA91861@fling-wing.demos.su> <200306190856.h5J8ufPJ002065@peedub.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2003 at 10:56:41AM +0200, Gary Jennejohn wrote: > > Dmitry Sivachenko writes: > > On Wed, Jun 18, 2003 at 06:08:37PM +0200, Gary Jennejohn wrote: > > > > > > Dmitry Sivachenko writes: > > > > Hello! > > > > > > > > Is there any reason why struct ipc_perm is not protected by #ifdef _KERNE > > L > > > > in ipc.h? Is it supposed to be used from userland? > > > > > > > > > > It's needed by ipcs. > > > > > > > Ah, I see. It is visible via struct msqid_ds. > > > > I developed a patch which requires addition of custom field to ipc_perm. > > I am trying to imagine which problems can it cause to userland programs. > > > > Any ideas? > > > > The usual way to handle this sort of change is to put any new structure > elements at the end so that existing applications don't get confused. > They simply aren't aware the new elements were added. Yes, that is exactly how I did it. > > Of course, this can cause problems when the kernel does a copyout() > using the new size but the application passed a pointer to > storage which can only hold the old, smaller structure. I didn't guess that. Probably this is why X-server crashed on my machine after that change. Recompilation fixed the problem. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030619090206.GC94651>