From owner-freebsd-current Thu Sep 19 17: 3:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B0037B401 for ; Thu, 19 Sep 2002 17:03:15 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D398243E75 for ; Thu, 19 Sep 2002 17:03:14 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA05167; Fri, 20 Sep 2002 10:02:46 +1000 Date: Fri, 20 Sep 2002 10:11:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Daniel Eischen , Julian Elischer , Edwin Culp , Subject: Re: slapd dumping core with today's current. In-Reply-To: <3D8A5338.363AEF4B@mindspring.com> Message-ID: <20020920100759.C3660-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 19 Sep 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > That's kind of the point of adding the fields that we did > > (mc_len, mc_fpformat). They can be used to help validate > > the contents and to allow extensions. We also have some > > spare slots, but the last incarnation of ucontext_t also > > had spare slots and it wasn't nearly enough for what we > > now need. > > I was thinking more along the lines of: > > struct extend { > struct extend *next; /* Next extension in list */ > int32_t id; /* extension ID */ > char crap[1]; /* extension specific data */ > }; > > And then adding: > > struct extend *extensions; > > Yeah, if it's non-NULL, it means a linear list traversal to find > relevent extensions, but that's better than non-working. > > String-to-id translation is a seperate function, and can also use > a linear list traversal to find the string, get an ID back, and > then subsequqnetly use the ID. Yeah, it's an extra contents > dereference, but it's better than non-working. Some of the extensions need to be understood by userland, so I think you don't want it that complicated. Setting up userland pointers in the kernel is hard enough without having to keep it backwards compatible. The kernel would also have to worry about userland clobbering the pointers before it follows them in sigreturn(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message