From: Shanti Katta <shanti_katta@ho...> - 2002-09-04 22:50:07
I started out with sparc32 port, but ultimately migrated to sparc64 port. I
am currently building 64-bit binaries on Ultrasparc I. UML version I am
currently working on is UM-22. I started out initially with Iain's work The
code _almost_ compiles now, just that it still gives few undefined
references for functions that I need to provide implementation for. I hope
within a week, I'll be able to sumbit a patch to Jeff Dike.
>From: Iain Young <iain@...>
>To: Jeff Dike <jdike@...>
>Subject: Re: [uml-devel] UML on sparc
>Date: Wed, 4 Sep 2002 20:41:09 +0100
>On Wed, Sep 04, 2002 at 10:42:02AM -0400, Jeff Dike wrote:
> > Shanti's port is ongoing. She has about got UML/sparc64 compiling.
> > getting it debugged and working might very well be appreciated :-)
>Oooh. It compiles ? Thats good. I have something to play with at the
>Is the code in the main UML patch, or do I need an extra patch ?
>Anyone know if the ptrace/rewriting of syscalls issue is fixed ?
>Or is that a "Still To Do" ?
>Oh and Shanti, can you confirm if it's sparc64, or sparc32 ? I thought
>it was sparc32, but Jeff seems to think its sparc64. Probably me being
>out of touch again :)
>All the Best
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone? Get a new here for FREE!
>User-mode-linux-devel mailing list
- Shanti Katta
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From: Jeff Dike <jdike@ka...> - 2002-09-10 22:25:59
> That interrupt a thread's execution and send it off into a handler
> routine? No.
Hmmm, I find that slightly unbelievable. Oh well.
> I guess I could avoid the locking issue by allowing the polling thread
> to suspend the running process when a signal comes in, calling the
> handler in the polling thread, then resuming the currently-running
> process. I'll look into that when I get the win32 event model a
> little more solid.
Yeah, something like that could work. I don't think it's a good idea to
force UML/win32 to be SMP just to make interrupts to work.
A potential problem there is that some handlers want to refer to current,
which in 2.4 is at the base of the stack, and whose address is calculated
by zeroing the low bits of a convenient stack address. In this scheme, the
two threads would have to share the stack somehow.
In 2.5, things are simpler, since there's a thread_info struct on the stack
which points to current. So, you'd just need to make sure that you copy
the appropriate thread_info onto the signal stack before running the interrupt
The 2.5 scheme might be able to be backported to 2.4 if necessary.