OpenBSD Journal

AMD64, UltraSparc III and SMP support in -current?

Contributed by jose on from the more-hardware-support dept.

anonymous writes: "Just saw this at http://www.openbsd.org/press.html . To quote the text:

"An interview with Theo ....... He describes a "very complex and intense climate" and points out that support for AMD Hammer, UltraSPARC III, SMP and Mozilla was done."

Anybody have more info on this?"

The hackathon which ended a month or so ago saw a lot of this work done. The Hammer chip is something that OpenBSD has been interested in due to the security friendly architecture. We wrote about SMP here some time ago (search the archives), and Mozilla is also a known issue. Anyone have any Hammer info they can share?

(Comments are closed)

Comments

  1. By henning () henning@openbsd.org on mailto:henning@openbsd.org

    well. to pin the four:
    1) mozilla works in -current.
    2) the SMP branch works okay with a biglock on i386
    3) UltraSPARC III goes singleuser now (without sun docu)
    4) hammer: kernel works so far, toolchain/compiler stuff in the works now

    Comments

    1. By Motley Fool () motely@dieselrepower.org on mailto:motely@dieselrepower.org

      Henning, I know to pull down the SMP tree you use the cvs SMP tag, are there any other undocumented tags?

      Comments

      1. By Martin Reindl () wildweasel@bsdcow.net on mailto:wildweasel@bsdcow.net

        -rUBC src/sys; but i think it is not really in sync with -current.

        Comments
        1. Comments

          1. By Martin Reindl () wildweasel@bsdcow.net on mailto:wildweasel@bsdcow.net

            I know. He asked for "other undocumented tags". UBC is one of them.

      2. By henning () henning@cvs.openbsd.org on mailto:henning@cvs.openbsd.org

        all cvs tags (should) show up via cvsweb etc.
        you are after -rSMP indeed.

    2. By Anonymous Coward () on

      "the SMP branch works okay with a biglock on i386" -- does that mean it's useable, but not as efficient as it could be, or am I wrong here?

      Also, is SMP for sparc/sparc64 also in the workings, or is that something for the very distant future?

      Comments

      1. By henning () henning@openbsd.org on mailto:henning@openbsd.org

        > "the SMP branch works okay with a biglock on i386" -- does that mean it's useable, but not as efficient as it could be, or am I wrong here?

        you're mostly right. it works mostly. it hasn't been tested thoroughly, and exclusively on one machine afaik, so it might be flaky.

      2. By ajax () on

        yes. "with a biglock" means that only one CPU can be executing kernel-mode code at once. if two programs try to do a system call at the same time, one will win and the other will block until the first returns. this is the first step in getting SMP working, and is similar to how linux' SMP worked in the 2.0 timeframe.

        the next issue is fine-grained locking, so that if two processes ask the kernel to do something unrelated (say, one disk access and one network access), they can both execute at once. you can think of this as having multiple threads of execution within the kernel, the same way you can have a multithreaded application. since threads share their address space and data, you need to be careful that the data structure you're currently processing doesn't change out from under you. you do this by associating a "lock" variable with each of the major structures or subsystems.

    3. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

      1) Bloatzilla and Bloatzilla-firebird still only work on i386.
      2) The SMP branch is far from being "useable".
      3) ... so UltraSPARC III is still useless.
      4) I'm working on new binutils issues which should eventually allow us to import the new binutils in-tree and we'll be a bit closer to having newer archs like amd64, mips64 (sgi), ia64 (supposedly something is in the works), hppa64 (keep poking mickey@) and can you say maybe powerpc64. There is also plans of having some GCC 3.x release (most likely 3.3.x) in-tree for use by the majority of the archs since some really need this badly (sparc64, amd64 for example) and others just benifit from improvements.

    4. By Anonymous Coward () on

      I just tried the -current port on a -stable system (yeah, I know one shouldn't normally do this, but I couldn't wait :p), and it's working great!
      Finally the last thing that kept OpenBSD from being a kickass workstation OS is resolved. I guess it's time to say goodbye to linux now :)

  2. By Anonymous Coward () on

    So you mean that there will eventually be support for the US3 _without_ sun docs? Hmm, I knew there are some pretty good coders in the OpenBSD team, but this is beyond all imagination.
    How do you even start such work without proper docs?

    Comments

    1. By mnemonic () on

      solaris reverse engineering may be ?

    2. By Anonymous Coward () on

      The linux code is there to be read, and understood.

      Comments

      1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

        The Linux code is completely useless. How many
        times does it have to be said?

        Comments

        1. By Anonymous Coward () on

          Why is it completely useless? After all, it works for linux... Different APIs on the kernel side, perhaps?

          Comments

          1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

            The code doesn't tell you how the processor works and why it does certain things a certain way, it only tells you how Linux wants things to work and the fact that a lot of their code is "magic numbers" thrown around which you have no idea what they do since nothing is documented.

          2. By JonMartin () jmartin@ugrad.cs.ualberta.ca on mailto:jmartin@ugrad.cs.ualberta.ca

            GPL issues? I wouldn't even look at GPLed code if I was planning on writing similar functionality in a BSD.

            Comments

            1. By RC () on

              No, you can look at GPL'd code for "inspiration", you just can't copy the code.

              What would the world be like if you weren't allowed to write a book, using some ideas you read from another book? Surely the movie A.I. would never have been made if they were not allowed to use the ideas they got from Pinocchio and Blade Runner.

              Disclaimer: IANAL

              Comments

              1. By Anonymous Coward () on

                (Offtopic) you describe my problem with patents here.

    3. By Anonymous Coward () on

      Actually, I've heard that the right docs are there.

      Comments

      1. By henning () heninng@openbsd.org on mailto:heninng@openbsd.org

        > Actually, I've heard that the right docs are there.

        you heard wrong.

        to my knowledge there was no reverse engineering of the solaris code nor linux code checks involved.

        Comments

        1. By Anonymous Coward () on

          Ask Theo. The problem is that the docs where not given properly by Sun. Using them might be asking for trouble.

        2. By Apollonius () who@cares.org on http://www.xakep.ru/

          also sagt henning:
          to my knowledge there was no reverse engineering of the solaris code nor linux code checks involved.
          ..................................................

          Divine Providence then... Kidz, make it a real mystery, would ya?

    4. By Anonymous Coward () on

      Out of curiosity what is involved? It sounds a great feat, how great really is it? How difficult is it? What is involved?

  3. By Anonymous Coward () on

    I am looking forward to migrating my little server to something _fast_ with good memory protection. Something like hammer :)

    Now, what is happening with UBC?

    Comments

    1. By Anonymous Coward () on

      yeah, with smp and ubc, i'll be a happy little camper, and will be migrating all the systems i have had to put freebsd on back to openbsd. hallelujah!

      Comments

      1. By Anonymous Coward () on

        What? Does nobody but me need ACPI? Power management is important, and many notebooks don't even support APM any longer. No more wasted watts for me, I prefer a reasonable electric bill.

        Not to mention also needing firewire on a handful of machines, but those few can do fine with other OSes for now.

        Comments

        1. By Anonymous Coward () on

          So why don't you start coding?

          Comments

          1. By Anonymous Coward () on

            Not all of us are programmers. In fact, I dare say programmers are in the minority, even in the select group of OpenBSD users.

            Comments

            1. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

              Oh well, doesn't change the fact that ACPI is a pile of crap and no one even has the time to start working on support for it.

        2. By FeanoR/var () on

          ACPI can also be usefull for otherthing than power management on laptop.

          I use ACPI to put some network cards "wakable" after shutdown (to do "wake on lan"). This can't be done without ACPI (and more, we need a patch on linux kernel to do this).

        3. By Anonymous Coward () on

          you wuss

          my electric bill
          oh no!

  4. By Anonymous Coward () on

    That's great. What next? DRI?

    Comments

    1. By henning () henning@openbsd.org on mailto:henning@openbsd.org

      asking "what's next" is really funny. I think it was clear that these items aren't really finished - amd64 aka hammer isn't even in the tree yet, and US III in single user mode is not too usefull. mozilla and derivates don't work on !i386 yet. SMP is _far_ from finished.

      Comments

      1. By Anonymous Coward () on

        Nobody said the referred features were finished, just curious as to what other things the OpenBSD team is thinking of working on in the future.

        Comments

        1. By tedu () on

          whatever they want to. :)

    2. By Brad () brad at comstyle dot com on mailto:brad at comstyle dot com

      DRI is being worked on, DRM (Direct Rendering Module) which is the kernel portion of the work is the last piece of the puzzle. wcobb@ has a DRM module for Matrox G200/G400 series cards but we still need DRM modules for ATI, 3dlabs and Intel cards.

    3. By Anonymous Coward () on

      And how 'bout the new Apple G5?

      Comments

      1. By Henning () henning@openbsd.org on mailto:henning@openbsd.org

        > And how 'bout the new Apple G5?

        you donate the hardware?

        Comments

      2. By Anonymous Coward () on

        That would be such a total waste. I'm sorry, OpenBSD rocks, and is a great OS, but using a G5 to run it makes no sense whatsoever. It is kind of like running OpenBSD on a modern SGI Workstation!

        Z.

        Comments

        1. By Anonymous Coward () on

          I disagree. That would be like saying that getting it to run on the PMac G3 NewWorld boxes was a waste (a friend of mine was a part of that port), or on Sun Ultras, which is how I use it. Getting it to run on a PMac G5 would help out in at least a few ways that I can think of:

          1.) It would be yet another 64-bit platform to work on and make sure OpenBSD stays good on 64-bit systems in general, since that seems where things are going.

          2.) The Xserve is basically a PMac G4 SMP that fits in a 1u rack. Terra Soft Solutions (yes, a GNU/Linux vendor) has made a business out of that to (mostly) commercial research labs and universities. I wouldn't put it past Apple to come out with an "Xserve G5" based on the PMac G5. Imagine OpenBSD on a full rack of those....

          3.) One of the reasons the PowerPC line has been successful in the imbedded market in particular is because of its high performance/power ratio. You don't even need a fan to cool, say, a 400MHz G3 (try that with any 400MHz non-Cyrix x86 chip). I would imagine that the G5 would have a similar performance/power ratio over Intel. Imagine a Cisco PIX Firewall-type device, using a G5 and OpenBSD instead of Pentium III's and PIX OS.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]