Date: Tue, 20 Aug 2002 16:36:50 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxime Henrion <mux@freebsd.org> Cc: arch@freebsd.org, bright@mu.org, bde@freebsd.org, iedowse@freebsd.org, gallatin@freebsd.org Subject: Re: Solving the stack gap issue Message-ID: <3D62D292.D0F3FEE6@mindspring.com> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> <20020820184624.GB86074@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxime Henrion wrote:
> I've already started working on this in my mux_giant branch. I was very
> busy with nmount these days so I didn't touch it since quite long, but I
> knon jhb has been IFC'ing it not so long ago. This branch removes the
> acquiring and releasing of Giant in syscall() and let the syscalls lock
> it if they need to. It also removes the 'M' prefix from the
> syscalls.master file. Feel free to use that branch if you want to work
> on this stuff.
I thought this was already do-able on a call by call basis? From
sysent.h:
struct sysent { /* system call table */
int sy_narg; /* number of arguments */
sy_call_t *sy_call; /* implementing function */
};
#define SYF_ARGMASK 0x0000FFFF
#define SYF_MPSAFE 0x00010000
It seems to me that SYF_MPSAFE is the flag you want to look at to
decide whether you want to grab giant or not? If not, it'd be
really easy to add up to 15 more flags... one I had been considering
was interruptability, and another was a 2 bit hint as to whether the
call was non-blocking, might block, or would block (for use by the
new threads code, to decide on whether to allocate a fake, delayed,
or up-front blocking context).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D62D292.D0F3FEE6>