[no subject]

[users-errors@xxxxxxxxxxxxxxxxxxxxxxx]

@gsicomp.on.ca> <45A838AA.9030008@fs.ei.tum.de> <200701130306.l0D36JX8007342@apollo.backplane.com> <45A87472.3040108@fs.ei.tum.de> <45A879FF.8060407@exemail.com.au> <200701130649.l0D6nE8j008759@apollo. backplane.com> <009301c73746$cdce3470$1200a8c0@gsicomp.on.ca> <200701132000.l0DK0QsA020885@ap ollo.backplane.com> <00b101c738e5$dd925710$1200a8c0@gsicomp.on.ca> <200701152301.l0FN1BR5039049@apollo.backplane.c om> <008801c7390d$66ffd9b0$1200a8c0@gsicomp.on.ca> <200701160313.l0G3DnsH040505!
 @apollo.backplane.com> <003201c°ù¿¿©â>O¯LïS(O
From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: Request for swapcontext and getcontext to be ported to our libc [ revision 3 ]
Date: Mon, 15 Jan 2007 23:19:48 -0800 (PST)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:users@crater.dragonflybsd.org>
List-Subscribe: <mailto:users-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:users-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:users-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-users@crater.dragonflybsd.org>
Sender: users-errors@crater.dragonflybsd.org
Errors-To: users-errors@crater.dragonflybsd.org
Lines: 29
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1168933394 crater_reader.dragonflybsd.org 833 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.users:8626

:I revisited these two kernel files and agree partially with your assessment:
:- machdep.c fixed a missing linebreak; the other change (mc_len) was cruft.
:- ucontext.h contains the protos for the *context routines; they still need
:to be somewhere so autoconf can find them, and I felt that this was the best
:place for them.  The other stuff (uc_flags, UCF_SWAPPED) was cruft.
:
:--
:Matt Emmerton

    Ok, I restored those bits.

    I have implemented the assembly and done some other cleanups and a 
    bit of testing.  I am committing the completed work now.

    I have not yet implemented the floating point save/restore.  I will
    check save-used for FP registers and see if I can optimize what gets
    saved.  When switching occurs synchronously I don't think the FP regs
    need to be saved/restored unless the prorgam is compiled to use 
    FP regs and general regs so this may be good enough for the moment.

    Switching from a signal dispatch is more problematic.  That almost
    certainly requires FP save/restore.

    Now we need some comprehensive testing with packages that actually
    use this beast!

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>