Tuesday Apr 19, 2011

A general update to force saving of blog

Just a short update

Tuesday Jun 14, 2005

Suppose I ought to introduce myself...

I'm Dana Myers, and I'm in the Solaris engineering organization where I spend most of my time leading the Solaris ACPI engineering effort. In my nearly 12 years at Sun, I've been a Solaris x86 engineer, a Consumer/Embedded engineer, a Java Wireless BizDev technologist, and once again a Solaris engineer. While my focus in on providing a high-quality ACPI sub-system based on Intel's excellent ACPI CA interpreter, you might find me tinkering with pretty much any system-board level thing. I still have a soft-spot for network device drivers - perhaps some of you are still using the PCnet-PCI driver in Solaris? I was pleasantly surprised to find a fair bit of the code I wrote at the end of 1994 is still visible in that driver. Coming back to Solaris engineering after a long absence, at a time with so much new energy and new development as we dramatically expand x86 and x64 support, this is such a rush! Just so I don't start thinking it is as good as it gets, I was fortunate to be able to join the Newboot development team - Newboot was my first customer for the new Solaris ACPI subsystem. My ACPI-team colleague David Chieu quickly developed the ISA-device enumeration code on top of the new interpreter, and we're pleased to have filled-in a key piece of Newboot. I'll be blogging a bit about the relatively few, relatively minor issues I've encountered since integrating ACPI CA into Solaris. In general, ACPI CA is working extremely well - the issues we've seen are generally related to how I've changed the way that Solaris interacts with the system. The biggest change is that we run the system in ACPI-mode now, not legacy mode - but I'll save that for another blog. Cheers!

Tuesday May 10, 2005

Dtrace: kool-aid worth drinking

So, a few days ago I installed an experimental Solaris kernel build, and my mouse stopped working. In the old days, before dtrace, this would have meant digging around in kernel source, building experimental modules and running the kernel debugger. This time, though, I wrote a few lines of "D" code, kicked-off dtrace and a few minutes later I'd located exactly where the error was occurring. It just took another couple of minutes to check to see if the source file had been recently modified - and I found the bug had just been fixed the day before, I just needed to grab the updated source. Start to finish, it took under 30 minutes to resolve this issue. dtrace is an \*amazing\* tool.
About

danasblog

Search

Categories
Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today
News
Blogroll