Slashdot Mirror


IRIX Multithreading Emulation on NetBSD

GrosBill writes "Onlamp publishes one more paper about IRIX binary compatibility implementation on NetBSD. This time, this is about emulating IRIX native multithreading capabilities on NetBSD, which is quite interesting since NetBSD does not support native multithreading for its native binaries yet. The paper also covers some reverse engineering tricks: how to use a debugger to discover everything about IRIX multithreading."

18 comments

  1. Give them some credit by mhesseltine · · Score: 4, Insightful

    They figured out a way to make a feature work on a platform that doesn't support that feature. That's called innovation, and not in the terms that Microsoft would use it.

    Furthermore, since this has been reverse engineered, they might be able to work this into NetBSD, thus fixing the problem of NetBSD not supporting multi-threading. I say, "congratulations."

    --
    Overrated / Underrated : Moderation :: Anonymous Coward : Posting
  2. Hack. by Anonymous Coward · · Score: 1

    A better way to implement this would be adding proper threading support in the first place...

    1. Re:Hack. by Anonymous Coward · · Score: 0

      Real multi-threading (Scheduler Activations) is currently in progress... in fact I think the first round of code is already in the -current code. As is SMP.

    2. Re:Hack. by Anonymous Coward · · Score: 0
      I don't think that you actually understand the problem. This announcement is that NetBSD's IRIX emulation layer supports multi-threaded binaries. So, how exactly is it a hack?
      A better way to implement this would be adding proper threading support in the first place...
      Adding proper threading support would not affect the IRIX emulation layer at all. You see, thread support involves both kernel and userland code. Now, if NetBSD is running a native IRIX binary then the userland code is fixed and written by SGI. So, the NetBSD kernel has to provide the syscalls and behaviours that the IRIX userland code expects which is likely to not be exactly what native threads would expect.

      So, emulated threads and native threads are actually two disjoint projects which have different implementation strategies and different goals. They just share a small amount of code in the kernel.

    3. Re:Hack. by Anonymous Coward · · Score: 0

      A better way to implement this would be adding proper threading support in the first place...
      What the hell kind of logic is that?? If we designed everything for problems that hadn't even arisen yet we'd never get anything out into actual production. Right when we'd get close they'd just throw another "problem" that we could "easily" solve before rolling out.