On Thu, Feb 23, 2012 at 23:47, P. Wilhelm <bearcat.pi...@gmail.com> wrote: > We use the old Solaris/Sparc in a medical device we produce where I work. > Since we can't get new Sparc hardware any longer (many countries no longer > accept "refurbished" devices - so we can't sell this product to them when we > use refurbish IT parts) that is reasonable cost for our application, we need > to find a way to continue to produce our product. The application is > moderately complicated and will take some effort/time to port to another OS > / processor. I was just evaluating the possibility of using an emulated > Sparc machine to replace the Solaris box. The thought behind using Qemu was > that we can reduce hardware obsolescence issues in the future with this > layer of abstraction. Conceivably, future hardware changes would be easier > to do with less regulatory overhead. My evaluation was exciting because I > was able to, with just a couple of days of work, get our application up and > running and talking to the other hardware associated our product. However, > given the maturity level of Qemu for Solaris on Sparc, we'll almost > certainly do a port of our application to other hardware and OS. With the > evaluation work, my interest was piqued, so I've continued to play around > with Solaris / Sparc on Qemu on my own time. Since I had a fairly well > encapsulated symptom, I thought I might be able to help identify a fix or > two for Qemu.
Another possibility is to make a Solaris/Sparc to Solaris/x86 user emulator like Linux, BSD and Darwin user emulators. They just translate CPU instructions and system call parameters instead of emulating a whole machine. The license of Solaris headers is not compatible with QEMU though but this could be avoided. I sent a quick patch once to the list which could be used as a starting point if you want to try this way. But I probably would not trust QEMU if my life depended on it, and as COPYING explains, there is also no warranty. > > Respectfully, > Paul > > On 2/21/2012 12:49 PM, Artyom Tarasenko wrote: >> >> Hi Paul, >> >> may I ask you why do you need Solaris 8/sparc? I spent really a lot of >> time on sparc emulation in qemu, it was fun and I would probably do it >> further, but I saw no projects where it would be useful. Somehow it >> looked that all the apps available for Solaris are available for >> Linux/Windows as well... Do you by any chance have an example of an >> app which would be worth the efforts? >> >> Artyom >> >> On Sun, Feb 19, 2012 at 4:45 PM, P. Wilhelm<bearcat.pi...@gmail.com> >> wrote: >> >>> I've been able to install Solaris 8 using CDs on the Sparc Softmmu client >>> system. Kudos to those responsible for Sparc development! >>> >>> I've been able to run a number of applications without problems on the >>> client machine. I noticed something odd, however, and have been trying to >>> isolate the cause. Hopefully, someone here will have an idea or two for >>> me >>> to try. >>> >>> The issue: >>> The syslogd seems to accept and post to the appropriate log file only a >>> small number of messages before no longer updating the log file when >>> further >>> messages are posted, the syslogd seems to hang. The symptom does not >>> appear >>> to be different when rebooting or restarting the syslog daemon. The >>> daemon >>> will post a couple of message to the log file and then stop accepting any >>> more. >>> >>> Why ask here? >>> I've done a couple of things to see if I can isolate the source of the >>> oddity and they seem to point to qemu. >>> >>> What I've done so far: >>> 1) I've tried using "logger" and a C program I wrote to use the syslog() >>> function. - Both have the same issue noted above. >>> 2) I've used both the OpenBios and SS5.bin bios. - Symptom does not >>> change >>> between the two. >>> 3) I checked my /etc/syslog.conf on real hardware running the same >>> version >>> of Solaris 8. Syslogging works as you'd expect there. (Note - I don't >>> have >>> real SparcStation 5 hardware. I've been using an old Sun4u machine, >>> Ultra-1 >>> -- hopefully, that does not invalidate my "real hardware" checks.). >>> 4) I ran syslogd in debug mode on both the client and the real hardware, >>> but >>> did not see anything in the output from each that gave a clue as to the >>> issue. Generally, the output confirmed that I had syslogd configured the >>> same way on both. >>> >>> How to proceed? >>> I am a reasonably adept software developer, however, I do not have >>> experience at the guts-level of Solaris OS or Sparc hardware. My work on >>> Solaris/Sparc has been at the application level, but I have worked at the >>> hardware level on other (proprietary) systems. If I had access to syslogd >>> source code, I'd be comfortable working from there, but I am fairly >>> certain >>> that is not available - let me know if I am wrong. I've thought about >>> looking for an open source syslog daemon and trying to use it instead of >>> the >>> Solaris version. >>> >>> Any thoughts about next steps are appreciated. >>> >>> >>> Respectfully, >>> Paul >>> >>> >> >> > >
