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().


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to