Date: Fri, 20 Sep 2002 10:11:26 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Julian Elischer <julian@elischer.org>, Edwin Culp <eculp@encontacto.net>, <current@FreeBSD.ORG> Subject: Re: slapd dumping core with today's current. Message-ID: <20020920100759.C3660-100000@gamplex.bde.org> In-Reply-To: <3D8A5338.363AEF4B@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020920100759.C3660-100000>