Monday Jun 11, 2007

The Irregular X11 DTrace Companion: Issue 2

In response to a Solaris 10 7/07 beta tester question last week, I updated the Xserver provider for DTrace web page to point out that besides the original method of patching the Xorg sources and rebuilding, pre-built binaries are now included directly in Solaris...

Getting an X server with DTrace probes built in

The Xserver dtrace providers are now included in the regular X server binaries (including Xorg, Xsun, Xvfb, Xephyr, Xnest, & Xprt) in recent Solaris releases, including:

For those who still want to build from source, the provider is integrated into the X.Org git master repository for the Xserver 1.4 release, planned to be released in August 2007 with X11R7.3, and into the OpenSolaris X code base for Nevada builds 53 and later.

Sunday Jun 10, 2007

Kinda like microblogging meets slow-mo IRC...

I was trying to explain twitter to my wife and the best I could come up with is “kinda like microblogging meets slow-mo IRC,” which didn't make any sense to her. After a bit more trying, “like a web forum with short posts” made more sense to her, but my personal dislike of web forums kept me from thinking of them like that. Fortunately more prolific and more widely read bloggers than I have spent a lot of time describing twitter and it's impact, so you can go read them for a better description.

Twitter is starting to gain popularity at Sun too, both as a new communications method to explore, and as a Solaris-hosted Web 2.0 service. They even have recently been a example of using DTrace to improve the performance of their Ruby-on-Rails platform.

So now you can also find me at http://twitter.com/alanc . I can't promise anything profound or in-depth in 140 characters, but it should get updated a bit more often than this long-form blog.

Thursday May 17, 2007

The Irregular X11 DTrace Companion: Issue 1

All the cool kids are doing unscheduled update newsletters now, and I had a collection of X11 Dtrace things to post about piling up, so I figured I'd give it a whirl. (BTW, Nouveau guys - I'd read yours more if you had an RSS feed - having to go check the wiki on an irregular basis doesn't work so well.)

Doing newsletters on a regular basis is hard, as Glynn has learned, so don't expect updates too often...

Sample script for tracing events

Jeremy asked recently for an example DTrace script using the event probes in the Xserver DTrace provider. I had lost the ones I wrote when developing/testing that probe, but dug one out of my e-mail that was written by DTrace Master Guru Bryan Cantrill and posted it as ButtonPress-events.d.

He wrote this script when he'd upgraded to Nevada build 58 and found shift-click was no longer working. Using the script he was able to show that the Xserver was sending ButtonPress events without the ShiftMask set. I wrote a corresponding script to decode the VUID events the X server was getting from the kernel mouse and keyboard drivers to determine the keyboard wasn't giving us the shift key pressed events until another key was pressed, which wasn't happening for shift-clicks with the mouse. That script can be seen in the bug report I filed with the kernel keyboard team as Solaris bug 6526932.

Using DTrace to win a race

A bug was filed with X.Org recently stating “iceauth can dump a core in auth_initialize() if a signal is caught before iceauth_filename has been malloced.” As I was fixing bugs in iceauth anyway, I figured I'd look at it to see if I could roll in a fix to the new iceauth release I'd be making for those. Fortunately, iceauth is a small program, and I could see where I thought the race condition lied between the main code and the signal handler. Testing any race condition has always been a pain in the past, since if you don't get the timing just right you don't know if you really fixed it, or just changed the timing enough to not hit it.

So I pulled up the DTrace manual and DTrace wiki and created a one-liner to force the race condition by sending the signal when I knew it was in the right spot:

 # dtrace -w -c ./iceauth -n 'pid$target::IceLockAuthFile:return { raise(1); }'

For those who haven't memorized the DTrace manual, this can be broken down as:

  • -w - allows “destructive” actions - i.e. those that change the running of the program, and don't just monitor it - in this case, allows sending a signal to the process
  • -c ./iceauth - specifies the command to run with this script, and puts the process id of the command in $target in the script
  • pid$target::IceLockAuthFile:return - sets the probe we're looking for to be the return from any call to the function IceLockAuthFile in the process matching the pid $target
  • { raise(1); } - sets the action to be run when that probe is hit to send signal 1 (aka SIGHUP) to the target process

Ran that and a few seconds later had a nice core file to verify where the race was. Turned out I was right about where the signal had to come in for the race to cause a crash, but was slightly off about the point in the signal handler where it was crashing. The fix was easy, and thanks to DTrace, easy to verify, and is now in X.Org's git repository.

DTrace Wiki: Topics: X

After last month's Silicon Valley OpenSolaris User Group meeting, Brendan asked if I'd work on the “X” topic on the DTrace Wiki. I agreed to, and have put up a small placeholder while I figure out what to flesh it out with - if you have any suggestions or requests for what you'ld like to see in a short introductory article to using DTrace to probe X, especially using, but not limited to, the Xserver DTrace provider, send me e-mail or leave a comment here.

Sunday Apr 29, 2007

3 years and still blogging...

Other Sun bloggers have been posting since Friday about the third anniversary of blogs.sun.com. Dilbert even had a very timely series of comics.

Today is actually the third anniversary of my first public blog post (though as you can see, I later migrated some earlier posts from my now abandoned internal blog to it), as I was traveling to the first X.Org Developer's Conference on the day of the initial launch, but signed up once I was there (back when signing up was simply e-mailing Will Snow to ask for an account), and started posting from there.

In my first post, I worried I wouldn't be able to find enough things to blog about - now I know I have too much to blog about, and time to write it all up is the limit - I was posting the changes in each Solaris Express release for a while, and more recently, the X ChangeLogs for each Solaris Nevada build, but both fell behind after a few months. I've got a list of links to other blogs and interesting sites that I want to post that keeps growing longer and longer as I fail to take enough time to post them here. I wasn't sure I would even get this post done during the b.s.c birthday celebration.

As some of the other bloggers mentioned, the effect has gone beyond just providing a way for any employee to post - the company's culture has changed. No longer do we complain about hearing about new announcements first in the press - blogs are now considered a crucial part of many announcement plans, especially around OpenSolaris, and bloggers are briefed in advance. I joked with Ben Rockwood at the SVOSUG last week about how much he's been yanking Sun's chain lately - how long ago would it be unimaginable that the CEO, VP's and Chief Architect get personally involved when a sysadmin at a startup complained about issues with Sun?

So much change in 3 short years - who knows where the next years will lead us?

Monday Apr 23, 2007

Compiz for Solaris

Erwann has posted Compiz 0.5.0 packages for Solaris Nevada/Express on x86 today - this is the latest step of several months of work to make this happen.

We've been working on this for several reasons. Our accessibility architect became very enthused after seeing Beryl's screen magnification support and talking to the Beryl developers at last fall's Ubuntu Developer's Summit. Our (now-former) director of Solaris Open Source (including OpenSolaris and the Solaris Desktop & X teams) became a fan after seeing the demos at the X.Org Developer's Conference Sun hosted in February. Even the Solaris CTO has jumped on the bandwagon for making the Solaris Express Developer's Edition look more modern.

We were dreading the tough choice of having to pick Beryl or Compiz - at first glance, compiz looked more stable, but beryl had more plugins/effects and the accessibility support we were interested in. Fortunately, the compiz and beryl communities solved this problem by re-uniting their efforts.

There's still work to do before this is seamless though. Compiz requires newer versions of various X components than we've had in Solaris - even February's Solaris Express Developer Edition is too old for this. We already upgraded from the X11R6.9 Xorg server to Xorg server 1.2 (from X11R7.2) in Nevada build 58 (the February SXDE was based on Nevada build 55b). I posted last week to desktop-discuss a list of where we are on the X library updates and additions needed for compiz.

Will we integrate this directly into Solaris in the future? We don't know yet, but it's definitely an option being considered. Until then, if you have nvidia graphics on Solaris x86, try it out! (Intel graphics will be an option as well soon, once the Solaris DRI team brings the Intel DRI drivers up to the level required by the X11R7.2 Xorg. We may even be able to get it running on SPARC in the not-to-distant future, once the current project to port XVR-2500 support to Xorg gets to the OpenGL stage - right now, it's mainly got the 2D portions of the driver running.)

Monday Apr 16, 2007

X11 API's for querying multi-head screen layout

I should probably stick this in the X.Org wiki or OpenSolaris/GenUnix wiki, but I'm being lazy and just summarizing to here now from an e-mail thread last week on one of the Sun internal lists...

There are now 4 sets of API's to query the layout of display screens in a logical X screen when using a setup such as Xinerama, TwinView, or MergedFB:

  1. the original X11R6.4 XPanoramiX\* API
  2. Sun's Xinerama API
  3. XFree86's Xinerama API
  4. Xrandr 1.2

The first is pretty much universally available, but also universally deprecated. The functions for it are defined in libXinerama on Linux, libXext on Solaris, but I don't think we've ever shipped the header for it on Solaris, since it was deprecated long ago.

The second Sun created and proposed to the old X.Org industry consortium to become the standard, but they did not adopt it, crafted a replacement in committee that was universally incompatible with everything and never adopted that either. It's what the <X11/extensions/xinerama.h> header in Solaris represents, and was never documented, but you can find a description of the API in PSARC 2000/036. The functions from it are found in Solaris libXext, but nowhere else in the world that I know of.

The third, aka libXinerama, is available on most XFree86 & Xorg based systems, and finally came to Solaris in nv_62 and soon in Solaris 10 patches & the next update release. It uses the <X11/extensions/Xinerama.h> (note the capitalization compared to the other) header and is documented in the man page we created for the Solaris integration and contributed back to X.Org.

The fourth is a very recent development, having been released after X11R7.2's release in February. X.Org is currently in the process of releasing version 1.3 of the Xorg server package (release candidate 5 is out now) - this will be the first Xorg server feature release not tied to one of the whole X Window System releases. (X11R7.2 had Xorg server 1.2, X11R7.3 is expected to have Xorg server 1.4.) The xf86-video-intel driver 2.0 release candidate 4 is also out, it is the first driver to support the new Xrandr 1.2 additions, though work is in progress on other drivers, including the Radeon and nvidia drivers. We don't have a definite roadmap for including this in Solaris yet - we'll probably do it once the X.Org releases are finished and we're passed the upcoming milestone of the second Solaris Express Developer Edition release in May.

Friday Mar 23, 2007

OGB Elections: Contributors and Voters

After some discussions on #opensolaris IRC today, I downloaded the lists of contributors from poll.opensolaris.org and ran some stats. Each OpenSolaris community was asked to name both Contributors and Core Contributors over the months leading up to the election - the Core Contributors are those eligible to vote. By my count, there's 268 unique Core Contributors across the communities.

First, the breakdown of Contributors by community - “unique” refers to those in each category which are not listed as either a contributor or core contributor by any other community:

CommunityCore ContributorsContributors
TotalUniqueTotalUnique
Academic and Research 3 2 3 1
Appliances 0 0 0 0
Approachability 1 0 14 8
Architecture Process and Tools 9 5 4717
BrandZ 4 1 4 3
Chinese Users 0 0 0 0
Community Advisory Board (CAB)14 8 3 0
DTrace 5 1 0 0
Databases 0 0 0 0
Desktop 8 8 6 4
Device Drivers 0 0 0 0
Documentation 5 2 12 8
Fault Management 6 1 3 0
GNU Solaris 0 0 0 0
Games on OpenSolaris 0 0 0 0
HPC Developer 0 0 0 0
Immigrants 2 0 1 1
Installation and Packaging10 6 4 1
Internationalization and Localization 5 2 11 8
Laptop11 4 0 0
Marketing 6 0 3 1
CommunityCore ContributorsContributors
TotalUniqueTotalUnique
Modular Debugger (MDB) 5 0 0 0
NFS 3 2 0 0
Networking 8 2 15 2
OS/Net (ON)4816 8 0
Observability 0 0 0 0
OpenSolaris Printing 0 0 0 0
Performance 8 4 1 0
PowerPC 4 2 11 5
Security 8 4 4 0
Service Management Facility (smf(5)) 8 1 16 8
Solaris Volume Manager 0 0 0 0
Storage 0 0 0 0
Systems Administrators 0 0 0 0
Testing 9 5 2 1
Tools22 8 20 6
Unix File Systems (UFS) 0 0 0 0
User Groups8866 1 1
X Window System 3 3 0 0
Xen15 7 1 0
ZFS14 8 1 0
Zones 7 2 3 1

As you can see 13 communities have named no contributors, which will probably result in the new OGB taking a close look at them to determine if they are really dormant or just need leaders to step up and organize them.

I also did counts of how many contributors were recognized by multiple communities as either a contributor or core contributor - these aren't necessarily the biggest contributors to OpenSolaris, just those with the widest breadth of contributions that were recognized:

# of Communities# of peopleContributors
7 2Adam H. Leventhal, James D. Carlson
6 2Casper H.S. Dik, Mike Shapiro
5 3Daniel B. Price, Eric Schrock, Stephen Hahn
4 9Bart Smaalders, Ben Rockwood, Bill Sommerfeld, Dan McDonald, Darren Reed, Kais Belgaied, Keith M. Wesolowski, Peter Memishian, Richard Lowe
3 25
2 68
1245

If you're active in one of the communities and didn't get named as a contributor, it's too late for this election, but for future status you should ask the leaders of the community what criteria they used to choose the contributors and how you can be considered for recognition.

If you were named a core contributor and haven't voted yet - hurry up! You've got a little less than 72 hours left, and while we've just passed 100 votes cast, approval of the constitution requires 50% of the eligible voters, so we need at least 30 more (and that's assuming most people voted yes on ratification). Instructions on voting are at http://opensolaris.org/os/project/website/poll_instructions/. Two tips from debugging problems reported by a pair of voters today:

  • The machine name is poll.opensolaris.org, not polls. Four engineers on IRC could not figure out why none of us could ssh to polls.opensolaris.org and were just getting mysterious connection closed messages, until stevel piped up that we were all misspelling the hostname and hadn't noticed, because the ssh/socks5 proxies we were all using didn't actually report hostname unknown errors.
  • If you copied and pasted your ssh key from a terminal window that caused line breaks to be inserted in the middle of all the ascii hex dump portion of the key, remove them - the web form allows you to put them in and doesn't warn you that it's invalid. (Again, thanks to stevel for coming to the rescue to solve that user's problem.)

Tuesday Mar 20, 2007

How to get better ATI drivers for Xorg

Just a quick note... Michael Larabel's post on “How To Get Better ATI Linux Support” is spot on with what we've heard from ATI and from others about ATI in various conversations — if you really want to get their attention, go through their OEM's and resellers, whether that be asking for improvements to their closed source drivers or ports of them to other OS'es, or even opening more specs/sources to the open source community.

(As for the competition, the same goes for them, and Sun is an nVidia reseller, so if there's something missing from their drivers that would encourage you to buy more Sun workstations with nVidia cards, let us know, and we can work it through our channels.)

[Technorati Tags: , , , , ]

Sunday Mar 11, 2007

OGB Elections: Proper Positioning

I haven't had a chance to write full position papers like some of the other candidates, so for my positions, you'll mainly have to rely on these answers I wrote to some of the questions submitted via e-mail to the candidates:

I did vote in the poll being used to test the OpenSolaris elections system, so will share my vote there, and explain some of my choices to help further show my positions on the issues facing the community.

The poll asked (and the order of these is the one I was shown - the order is randomized for each voter to reduce bias if people just start voting "1 2 3 4..."):

QUESTION 1.1: ("Priorities") Which of the following items, presented
in a randomized order, should be prioritized by the Governing Board in
order to promote OpenSolaris and increase its developer mindshare?

1 - Deploy a public defect management system ('Defect_Mgmt')
2 - Remove inactive Communities or Projects ('Remove_Inactive')
3 - Provide an x86/AMD64-based kernel/project build facility
    ('X64_Build')
4 - Deploy a public Request To Integrate (RTI) system ('RTI')
5 - Provide a SPARC-based kernel/project build facility
    ('SPARC_Build')
6 - Create an infrastructure project to run opensolaris.org
    ('Infrastructure')
7 - Replace or remove Jive forum interface ('No_Jive')
8 - Reorganize the existing Community/Project organization
    ('Reorganize_Community')
9 - Replace opensolaris.org tools with an open source CMS or wiki
    ('New_CMS')
10 - Deploy a public wiki on opensolaris.org ('Wiki')
11 - Deploy a public code review facility on opensolaris.org
    ('Code_Review')
12 - Eliminate reliability issues with opensolaris.org web pages
    ('Reliability')

My vote was:

RESPONSE 1.1 --> 1 6 9 8 4 5 3 11 10 2 7
VERIFY:  Your ballot is:
Priorities: [Defect_Mgmt Infrastructure New_CMS Reorganize_Community
 RTI SPARC_Build X64_Build Code_Review Wiki Remove_Inactive No_Jive ]

So why these?

Deploy a public defect management system

Right now bugs.opensolaris.org is not truly a two-way communication system - for people outside Sun, it's Write Once Read Many (WORM) - they can file a bug, search for bugs, and read bugs, but not update them or have them assigned to them to work on. Additionally many of the bugs and bug fields are still restricted to internal users only, though that's a harder nut to crack due to various legal and customer privacy issues.

This means projects with external contributors are at a gross disadvantage, and has led to projects such as ksh93 using a separate bug tracking system (Steve Lau graciously set up a bugzilla for them on his system), which segregates their bugs from the rest of the community, so bugs.os.o no longer has all the relevant data. This needs to be solved before non-Sun employees can be first-class members of the development community.

Create an infrastructure project to run opensolaris.org

Right now, too many improvements are stalled because the team running opensolaris.org can't keep up with the everything they need to do to implement them. Open it up now, let the community help you, and let us all move forward.

Replace opensolaris.org tools with an open source CMS or wiki

The current infrastructure is customized and weird - Project & Community Leaders are the only ones who can edit pages in their areas, so to add someone to edit anything, even just one project subpage, they have to be made a leader, even if they're not doing any leadership. The syntax is also strange and confusing to those used to just about any other wiki-like system in the world.

Reorganize the existing Community/Project organization

This has been discussed to death elsewhere already, and a big part is just cleaning up the original set of communities created before projects were done. The election confused many people since those doing the most work (projects) are not given voting rights, while those just interested in the technology (communities) are.

Deploy a public Request To Integrate (RTI) system

This is specific to the ON family of consolidations that use the RTI system (Desktop consolidations, including X, don't - I don't know about all the others), but once the code repository is outside, this will be the biggest obstacle to letting non-Sun people commit code on their own without any internal sponsor.

Provide a SPARC-based kernel/project build facility
Provide an x86/AMD64-based kernel/project build facility

SPARC is higher priority than x86, since more people have x86 system access on their own, but commits to most OpenSolaris consolidations require you to build and test on both platforms first, and that's hard to do if you aren't working at Sun or another place with both kinds of machines around and installed with the build environment.

Deploy a public code review facility on opensolaris.org
Deploy a public wiki on opensolaris.org

For both of these, while it would be nice to have on opensolaris.org, we've got community ones already that work fine - for instance, I'd be happy just making wiki.opensolaris.org redirect to http://www.genunix.org/wiki/ and declaring that one done.

Remove inactive Communities or Projects

These clutter up crowded pages and cause confusion, but don't stop any real work from being done.

Replace or remove Jive forum interface

Again, as much as it annoys me, it's not preventing real work, and can be mostly ignored if you truly hate it. (It would be nice if it didn't break threads and cross-posting and such for people who use the mailing lists instead.)

Eliminate reliability issues with opensolaris.org web pages

As much as I was tempted to vote for this just to tweak stevel, I just haven't seen enough of a reliability issue to declare this a major problem that needs attention, so I just left it off my choices completely.

Saturday Mar 10, 2007

OGB Elections: Biography of a Candidate

As you may have seen, I am a candidate for the OpenSolaris Governing Board, and as the other candidates are doing, I'm writing a bio to give background on myself. I've previously posted a more personal summary of my background, so I'll focus here on topics I believe are more relevant to being an OGB candidate. If you have no interest in the OGB elections, or in long rambling non-linear self-promoting stories, you can just move ahead to the next entry in your RSS feed reader now.

First the basics that all the candidates are stating: As you may have guessed from the URL this is posted at, Sun Microsystems, Inc. has been my employer for the past 8 years, but I have never built my own kernel. (I have designed, implemented, and integrated my own DTrace provider though.)

While attending the University of California, Berkeley I became involved in the running of Berkeley's Open Computing Facility, a somewhat unusual student group who provided access to Unix workstations and servers in a time when that was hard to come by for a non-engineering student. When I first started volunteering there in 1991, it was the only place most students on campus could get e-mail and Usenet access. Later it became the first place most students could host web pages, and continued to evolve over time. It was run by a completely volunteer student organization, in which I served first as a member of the system administration staff (their Apollo Domain/OS workstations were the first Unix machines I got root on, and the first time I got to have the account name alanc instead of just a class account name like cs60a-ej). I later joined the OCF's Board of Directors, who set the policies for the machines, and served a semester each as Site Manager (head sysadmin) and General Manager (head of the organization).

It was also at the OCF that I first started contributing to Open Source projects. My first major contributions were to the Gopher client/server software for Unix platforms from the University of Michigan, an early precursor to the world wide web. Of course, my most notable open source work has been through my job at Sun, contributing to the X Window System software that forms the foundation of all major Unix and Linux GUIs today. I participated in the old closed-membership industry consortium X.Org Group on behalf of Sun, and contributed to their irregular public code drops of the very closed development tree, and also contributed some of our code to the XFree86 Project, including the support I wrote for IPv6 in X11. When we were looking for ways to revitalize the stagnant X.Org Group at the same time that a group of current and former XFree86 developers were looking to create a more open development model to replace XFree86, I got to be one of the developers in at the very beginning of the transformation of both groups into the X.Org Foundation and it's Xorg software releases. I was elected to the short-lived X.Org Architecture Board, and was the release manager for the X11R6.9 release and one of the leads of the modularization project that resulted in X11R7.0. Through this I've experienced first hand how much more vibrant and productive a fully open development community can be than one in which a small core team holds the leash to all access, and all changes have to be funneled through them. (OpenSolaris isn't quite as bad, as there are several dozen “request sponsors” who can check in code from community members, but we still see requests that take much longer than they should because sponsors simply get too busy and become an unnecessary bottleneck. We've got several external contributors who have clearly proven they deserve commit access, but we haven't gotten the master repositories for anything besides JDS outside the Sun firewall yet so they can exercise that.)

When I took some time off from college, the Unix administration and end-user communication skills I got at the OCF, combined with the connections I had from that community, got me a position as a contractor in Sun's technical support center (then in Mountain View, California) answering Solaris system administration questions. Since I was more familiar then with other forms of Unix, and already had been addicted to Usenet for years, I looked for help in learning the Solaris specific methods to the comp.unix.solaris Usenet newsgroup, and returned the help I got by answering the questions that I could. (And even though I haven't posted as much lately, I just noticed Google still shows me in the top ten all-time posters to comp.unix.solaris, under my alum.calberkeley.org address.) It was through comp.unix.solaris that I first participated in the Solaris community, and first came in contact with current OGB members Rich Teer and Casper Dik, and of course, ksh93 for OpenSolaris project leader Roland Mainz.

After joining Sun I also started participating in the Solaris x86 YahooGroups mailing list, sticking with it even during the dark days in which Sun had declared Solaris 9 for x86 “indefinitely delayed.” After the “Secret Six” from that group convinced Sun to restore Solaris x86, one of the projects Sun started to restore relationship with the community was monthly meetings with a “Cabal” of community leaders. When we decided to ship the Xorg server in Solaris, I was asked to come to one of these meetings to talk about our plans, and given my involvement in the community already, was invited to become a permanent part of the group. That group didn't last long, as it ended when the participants, including me, became some of the original members of the OpenSolaris Pilot Program, so I've been part of the OpenSolaris community since the very beginning. Since the public launch of OpenSolaris I've served as a leader of the OpenSolaris X Window System Community and the representative of the X Consolidation to the OpenSolaris Program Team. (The OpenSolaris.org forum software says I've posted 1,190 times to OpenSolaris forums since the launch, but I don't know how many of those are duplicates from cross posts to multiple forums.)

At Sun, I've also served for about 6 years now on the Desktop C-Team, which oversees the various Desktop consolidations (X, GNOME, Mozilla, CDE, etc.) - approving integration of new projects, setting and enforcing various policies, and coordinating joint projects with other consolidations. For the past three years I've been part of the Layered Software Architecture Review Committee, first as an intern, and now as a full member. LSARC is the ARC which reviews software above the core platform - including the desktop environments, web browsers, compilers and developer tools, and various management tools. X itself is usually straddling the boundary between LSARC and the core platform ARC (PSARC) - cases interfacing with the hardware or kernel go to PSARC (including most updates to the X servers themselves), while client libraries that are mostly used by the desktop environments go to LSARC, so that they fit into the larger picture of those desktops. As such, even though I'm part of LSARC, from time to time I submit cases to PSARC and participate in relevant PSARC reviews.

So that's the long boring story of how I got to where am I today (if you've made it this far, thanks for sticking through it, and be glad that I didn't make it even longer and more boring with recounting my experience as editor of the high school newspaper or how bad I was at memorizing my lines in high school Drama Club productions). Now that we've covered the past, I'll save the topic of the future and my positions on various OGB issues for another post...

Monday Feb 19, 2007

What programmers look like...

Apparently, programmers look like me & Gary, according the Flickr title Alec put on the snapshot of us in his photos from last week's Sun Security Ambassador beerbash. At least I didn't get caught in a funny hat like the distinguished gentleman to our right (who was actually only a couple feet to our right when the photo was taken):

There's nothing like realizing you're surrounded by one of the inventors of public-key crypto and the architects of Trusted Solaris, having your photo taken by the developer of Crack, to make a X guy feel like he stepped into the wrong party. Though I wasn't feeling out of place for long, since just before Jim came down the hall and summoned me with the magic words “Free Beer” I had been working on the putback for the Xorg 7.2 vs. Trusted Extensions bug I'd been working on most of the week, so was answering questions about that, and then I got to meet a whole bunch of people who responded with “Oh! I know your posts on the [Sun internal] security-interest list.” In the end, I was once again feeling lucky to be able to work with such an amazing collection of talented and friendly engineers.

[If you couldn't tell, I'm the one just starting to show grey in his beard - or the one who is in most need of a trip to the gym. Maybe I should try Gman's new workout plan.]

Sunday Feb 04, 2007

Moving x86 video drivers into the kernel

Since Keith's recent talk on X at linux.conf.au, I've been asked a few times and seen discussion elsewhere (such as in the comments on the linked article) what Sun thinks about moving various portions of the Xorg video drivers from the current userspace shared objects into true kernel drivers, as most people assume this means Linux kernel drivers and reducing the portability of Xorg to non-Linux platforms such as Solaris/OpenSolaris and the BSD's.

While I'm of course too far down the food chain to claim to speak officially for Sun, as the lead engineer for the Xorg integration to Solaris and someone who has talked to a number of the other Solaris engineers about it, I'd say the Solaris engineering teams agree having in-kernel drivers for video cards is something we want and need.

On Solaris, we've long had in kernel graphics drivers for all our SPARC frame buffers, since that was a small and controlled set, and writing the driver for it was simply part of the cost of producing the card. On the x86 side though, we had for years the same model as most other x86 Unix-like OS'es - a generic set of kernel modules, and all device-specific logic in the X server. The Solaris x86 kernel modules were vgatext and xsvc. vgatext provides the text console, using standard/ancient VGA interfaces which virtually all PC graphics boards support. xsvc (which was closed source due to legal encumberances, but has recently been replaced with a newly written open source version by the Solaris Xen project team) provides the mappings to the PCI bus that allow Xorg to probe the bus hardware to find devices, and then map in the video card once it's found.

Recently, new kernel modules have started appearing in Solaris - the first two for 3-D rendering acceleration, nvidia's driver and the DRI driver for Intel graphics. Two more are coming soon from the Suspend-and-Resume project, to provide the hooks to save and restore necessary state across system suspends - they'll initially support the ATI Rage XL from the Sun Ultra 20 and ATI ES-1000 in the Ultra 20 M2. (Dave and Jay gave a talk on their implementation at last years' X Developer's Conference.)

Additionally, our security guys have been pushing for more kernel frame buffer drivers to reduce our need for running Xorg as root. They'd also like to find a way to close the now infamous Ring 0 security weakness. (We've invited them to drop in to this week's X.Org Developer's Conference to talk about this - they're planning to show up Thursday morning for the Secure X talk, so we may try to have a breakout session on this topic at that time to discuss this.)

Now, we still can't write drivers ourselves for every x86 video card on the market, which is one of the big reasons we chose to move from Xsun to Xorg on Solaris, so we'd still prefer if a model could be found that allowed sharing drivers between Solaris, Linux, and BSD (which means agreeing on both licensing and interfaces with the kernel), similar to what we already have in DRI. If we can work out a model like that, then I think Sun would support it - either way, we're going to have to have more graphics driver functionality in the kernel, and sharing would be better than going our own way.

[Technorati Tags: , , , , , , ]

Tuesday Jan 02, 2007

In honor of years of service

While the rest of the world has been paying tribute to James Brown & Gerald Ford, I have a much more mundane duo to pay respects to after many years of work which ended in December.

The first is John, who was the manager of the X engineering group at Sun for the past 5 years. He started at Sun long before that - so long ago that his first job in Solaris Desktop engineering was porting applications from SunView to XView. He later was part of Sun's Motif team, staying until he was the last member in the US after CDE & Motif development moved to Sun's Dublin, Ireland office. I can still remember him participating in the conference calls in which the CDE/Motif co-owners were trying to convince The Open Group to open source Motif, and only succeeding in convincing them to go halfway, cementing Motif's fate as a legacy toolkit and leaving the path clear for GTK+ and Qt to replace it as the toolkits of choice for new applications.

After nearly 8 years in the X group, first as an engineer and then a manager, he's decided to return to the academic life, which will be a big change for him and us. It will be interesting to see how things change around here once our new manager starts next week.

The second is the machine that has served as recipesource.com for the last 8 years. When it first went online in 1999, the Ultra 30 was intended to be a temporary machine, to be replaced soon by a more suitable server, but we never quite got around to that. During the 8 years since, we think it served almost half a billion http requests (we don't have all the logs, since we lost some to full disks, but that's about what the average hits from the logs we have would work out to). We've now moved the site to a hosted services provider, so that people with more time than us to do system administration can do so - one sign of how little time we had for that can be seen from this last set of commands I ran before the final shutdown:

# uname -a
SunOS amidala 5.8 Generic_108528-08 sun4u sparc SUNW,Ultra-30
# uptime
 1:08pm  up 1725 day(s),  9:41,  1 user,  load average: 0.07, 0.03, 0.02

Almost 5 years without even installing a kernel patch, much less an OS upgrade - but even though it was open to the internet at large, the network services were limited, and while we did get caught by spammers a few times who found ways to relay through us before we got sendmail patches updated, as far as we can tell, it was never broken into.

Thursday Dec 21, 2006

Military usage of FOSS

Sergey, while the thought of software I'm writing being potentially used in military applications to kill others is not pleasant, before you propose a license change to ban military use, have you considered how much they've given back to open source software? Will you be giving up all software that was funded by various national Defense Departments? Start by dropping TCP/IP from your life and let us know how it goes from there.

Tuesday Nov 28, 2006

My favorite new feature in Nevada build 53...

I wrote a couple of weeks ago about the then-upcoming Solaris Nevada build 53 in a mail to the Solaris x86 YahooGroups mailing list:

For desktop users, nv_53 should be awesome. Gnome 2.16, Firefox 2.0, Gnome System Tools, DRI for i845/i855/i865/i915, and, just integrated today, for the first time ever, the nvidia accelerated drivers/GL as part of the Solaris OS install. Attentive viewers may note that it also doesn't have kdmconfig run at install time anymore due to the replacement of Xsun with Xorg as the install-time X server.

Now that I've updated to nv_53 on my main desktop at work (which was actually a big jump from it's previous Solaris 10 6/06 install, but went smoothly via Live Upgrade) I've found my favorite new feature is one I didn't even know about in advance - a popup menu from the JDS toolbar clock that shows the time in different timezones:

Time Zone Popup Menu screen shot

I work with people from around the world - our desktop team is mostly split between Ireland and China, with outliers in New Zealand, Canada, and Illinois. The Architecture Review Committee I serve on at Sun has members on both coasts of the US, and in India and Isreal at the moment. Trying to keep track of what time it is where is more than I can remember most of the time, so I was constantly going to timeanddate.com to check the time in other parts of the world. Now I can add them to my menu for quick reference.

Unfortunately, it was something I discovered by accident and seems to be a little hidden - to get there, right-click on the panel clock and choose Preferences. In the Clock Preferences panel turn on Show time zones button. You should now have a big world/clock icon next to your clock like the one shown above (one that seems too large and out of place for the panel compared to the other icons there). Click on it to bring up the menu and choose Edit Time Zones. Now, you'll have to ignore the actual question shown in the next dialog:

Even though it's asking you to choose your nearest city, it really means “a city in the time zone and jurisdiction you want to see” — it's neither distance to you that matters or distance to the target, but which set of time zone rules and daylight savings change rules are in effect in the target location. For instance, if you want to know the time in Seattle, Washington, you need to choose Los Angeles, which is much farther away than Boise, Idaho or Vancouver, BC, Canada, but unlike Boise, is in the same time zone, and unlike Vancouver, follows the same national time-shifting schedule. It would be nice if it let you edit the name shown, since I normally think of needing to know the time in Beijing, not Shanghai, but it's still much nicer than what I previously did.

[Technorati Tags: , , , ]

About

Engineer working on Oracle Solaris and with the X.Org open source community.

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, the X.Org Foundation, or anyone else.

See Also
Follow me on twitter

Search

Categories
Archives
« April 2014
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
   
       
Today