Friday, May 29, 2009

audiocmi webrev posted

I've posted a webrev for the audiocmi driver. This driver supports CMI 8738 and similar parts. This is for Boomer, and I hope to get it integrated into build 117. If you want to test a binary, drop me an e-mail!

Thursday, May 28, 2009

spwr opensource and GLDv3?

If you'd like the spwr driver to be open sourced and GLDv3 compliant (with VLAN support, link notification, dladm and ndd support, and the rest of the goodies), and have a few spare cards that you can give me, please feel free to contact me. I'm willing to do the work as a side project.

I'm also interested in obtaining 100Base-X fiber cards, and fiber cables (VF45 format), especially if someone also has access to the 3M VOL-N100VF+TX card (which is theoretically supported by "afe", but which I'm not entirely convinced works properly because I've never actually had a card on hand that I could test!) I need cards and cable... at the moment I have neither.

Note that this is not Sun commissioned work, but an interesting side project that caught my interest. If nobody replies with hardware, then its unlikely that I'll do any of the work.

Wednesday, May 27, 2009

Going to CommunityOne After All

Well, it appears that I'll be at CommunityOne (Monday only) after all! This is going to be a fairly big event -- the big event for OpenSolaris this year, I think. I'm looking forward to the chance to meet a bunch of folks that I didn't get the chance to meet previously. Hope to see you there!

Monday, May 11, 2009

hme for x86 RTI submitted

I've just submitted the RTI for hme. If the RTI advocate approves it in time, it will be in build 115, otherwise in build 116. This will allow you to use your old PCI qfe boards with OpenSolaris on x86 systems.

It also represents a significant simplifications of the code. Thanks to the folks who've helped with testing!

audio1575 driver for x86

This driver, with surround sound (5.1) support is pushed into Build 115. Stay tuned.

iprb suspend/resume and quiesce support in b115

I've just pushed an updated iprb with suspend/resume and quiesce support. Its still in the closed tree, but even so this improvement should help out folks who are stuck with one of these on their system board. Enjoy.

on the evils of auto-bounce/discard mailing lists

Some of you have already seen this rant from me. But I think its important enough to bring to the greater attention of the community.

Some mailing lists in OpenSolaris are configured to automatically bounce or discard messages sent from a mailing list that is not subscribed to that list. This is, IMO, a fairly toxic configuration.

At first glance, the idea seems good -- if your list only accepts member submissions, then you'll not have to deal with all the spam, and you don't have to moderate. The list can basically run from that point completely unadministered. Sounds good, doesn't it.

The problem is that this configuration is toxic to many discussions and to some users. As an example, I tend to get involved in many cross discipline conversations -- partly as a result of my membership on ARC.

And yet, my replies, often to important discussions about cases that might be interesting to certain communities, are often bounced back, because I simply am not subscribed to those lists. I don't want to subscribe to every list -- and I shouldn't have to in order to be an effective ARC member. A lot of times I just give up -- so communities are missing out on relevant conversation because of these configurations. This is a serious impediment to collaboration.

But it goes beyond that -- I'm also known by at least four different e-mail address -- one personal address, one, one, and one People know me by all of those addresses -- so I'll be CC'd on conversations using any one of those addresses. When I reply, unless I am careful to remember to use the address I've subscribed to the list as, it will bounce on certain lists. Now its been pointed out that I can fix this by subscribing all of my addresses to the mailing lists I'm member of -- but who wants to subscribe to every list they're on 4 times? This is a serious impediment to collaboration.

The other situation is when someone has some new bit of information that they would like to bring to attention to a group of individuals, or ask a question, without having to be a member of the group. If I think I've found a bug in the TCP stack, should I have to be a member of networking-discuss@ in order to ask the group about it, or post the information? I suspect many such newbies hit the auto-bounce barrier for some of these groups, and just give up. The threshold for participation is simply too great. This is a serious impediment to collaboration.

So, all of these issues seem like they are negatively impacting collaboration. What is the solution?

Easy: moderate your lists properly. For heavily trafficked lists, it might take a few minutes a day to do this, but configure the lists to hold posts from non-members for moderation. If you identify a couple of volunteers to share the list password with, you can spread the chore, so that it is not too onerous for any one individual.

Those of you list owners with auto-discard/bounce set, please consider changing to a regular moderated list format. As attractive as the idea of a configuration where you don't have to do any work is, such configurations are actually hurting the group.

I'm done ranting about this for now. Thank you.

Saturday, May 9, 2009

giving up on iprb

Due to snafus with the various legal departments involved, we seem to have hit another roadblock getting iprb open sourced. (Why is it that whenever lawyers get involved, everything seems to take five times longer than it otherwise would? Do corporate lawyers bill by the hour just like their normal "free-agent" counterparts?)

Rather than continue to wait for this to get resolved, I've decided to move forward and get some of the important fixes into iprb even though it is still closed source. Most notably, my changes allow iprb to support suspend-to-ram, and fast reboot.

I've submitted the RTI for these changes, so hopefully this will be in either build 115 or (more likely) build 116. As far as opening the actual source up -- even though there is nothing in the source that is not already made public by Intel -- I'm not holding my breath.

Friday, May 8, 2009

audio1575 driver for x86

I'm getting ready to submit an RTI to add M1575 (Acer/Uli) support to OpenSolaris. As part of the work, I've taken the M1575 driver from OpenSolaris (which was used for the SPARC Ultra 25, and 45 workstations) and added quiesce() and multichannel surround support. I'm told it works nicely with 5.1 channel surround. If you have this chip (e.g. an ATI SB200 motherboard), let me know and I'll see if I can get a binary to you. (You'll need to have Boomer RC3 or build 115 installed, though.)

7zip saves the day

I recently received a document that was LHA archived. I was struggling to find a suitable decompressor, since Gnome archive-manager complained that the format was unsupported.

Nicely, though, 7zip had no trouble uncompressing the file. And, 7zip is stock on all recent builds of OpenSolaris. Very cool. :-)

Tuesday, May 5, 2009

hme/qfe x86 and SPARC binaries

hme (and by extension qfe) cards can be used on x86 systems if you download the test driver that I've supplied. Just download, extract, and follow the directions in the README file.

I'm also interested in verification that the driver performs properly on SPARC; binaries are in the same archive. The code was significantly simplified, and I need to know it works properly.

Finally, I'm seriously in need of code reviewers. I can't integrate the changes without a proper review. If you can volunteer to help, check out the webrev that I have posted.


(Note: on x86 qfe cards will show up as "hme" devices... this is normal and expected. The "qfe" name is an artifact only found on SPARC systems for historical reasons... the actual qfe card consists of 4 hme devices behind a PCI bridge.)

Via Rhine driver integrated

Joost Mulders last night integrated his Via Rhine "vr" driver. While I don't personally have this hardware, I know it is very common. I did code review his driver, which I found to represent very tight and well-written code. Congratulations Joost!

Saurabh Misra is working on a home-grown "bfe" (Broadcom Fast Ethernet) driver as well, which also looks very good and should be integrating soon.