everburning

I did a bit of work on OpenSolaris about a month and a half ago. I think I put a blog message up about it when I sent the patch. Well, I’m still waiting for it to be fully integrated back into the source tree.

I’m not taking big changes, I’m taking 5 lines to check if a file exists before using it. Nothing involving rockets nor science. The patch has been accepted by a sponsor and integrated into their tree already so it isn’t coding issues holding up the integration.

The Sun sponsor has been quite good at informing me of the state of the patch and where it currently is in the integration process, but geeze. A bloody month and a half?

If this is the kind turn around time that can be expected when contributing patches I can’t see the community of developers growing very fast. It’s just too long. I already got tired of waiting and have moved onto other things. It becomes hard to continue working on OpenSolaris as you don’t want to have to fix any new patches after the first is integrated.

In my opinion, open source projects have to be fairly agile. They need to be able to take patches and, either send them back for improvements, or get them integrated within a week or two. Much longer then that and you’ll start losing the tiny space you currently occupy in the developers brain. They’ll turn back to something where they can see their contributions actually getting accepted and integrated. I’m not saying just throw stuff in the tree at random, but taking weeks to wait for integration testing is a bit extreme.

I can see the problem being faced by the project. How do you maintain the quality standards required while allowing for quicker integration times? Honestly, I don’t know how to solve it. Most of the time I’ve been waiting seems to have been for the integration tests to be run. This process seems to take up a couple of weeks in and of itself.

Maybe it would be possible to open up the testing process a bit more? Maybe the test cases need to be split out more? (I was focusing on one userland application, svccfg, so if that specific set of tests could be run it would be a lot faster.)

Well, Nathan has done it again and sucked me back into doing Ewl work. I’ve been taking a break for a week or so as I was getting annoyed with various aspects of the Enlightenment project.

I’ve been off playing with OpenSolaris and submitted my second patch. We’ll see if it gets committed.

I’ve also been spending a lot of time playing Crackdown for the 360. It’s a lot of bloody fun. There is just something satisfying about running down criminals at high speeds and tossing grenades on their heads from the rooftops.

Anyway, as I said before, I’m back playing with Ewl. Nathan has been looking at a patch I created to split the Ewl_Text widget into several smaller source files. I commited one part of this previously, the Ewl_Text_Context code. The second part of the split is getting the formatting information into Ewl_Text_Fmt and hide the implementation a lot better. The code is all written, we’re just in the debug state. Nathan has been poking at it and asking me questions over the last week.

Tonight he managed to suck me back in. He tracked down the likely cause of the position counters going negative and I’ve got that part fixed. Other stuff still needs to be fixed up.

The longer you work on a project the more code you invest and the more mental state you invest. That investment makes it hard to sit back and watch as everything gets re-invented over and over again. Poisonious people pop up and drive the desire to work right out. On the other hand, the code’s still there, there are still bugs to fix, and some of the people are really cool. I think, every now and then, you just have to say ‘toss it’ and go away for a while. Just ignore the project. Wait for something to draw you back in and make it interesting again.

Well, I managed to get my first patch into OpenSolaris. It wasn’t anything major, just a couple simple script fixes but, it did get me to go through the entire process of contributing. A bit of a daunting task as there are a lot of things to keep in mind.

I also opened my big mouth and suggested an article for new developers.

I’ve decided to put some form of money where my mouth is. Possibly Monopoly money.

Anyway, here goes, some information to keep in mind when contributing to OpenSolaris.

OpenSolaris can be a bit of a frightening community. There is a lot of stuff going on over there. Some parts have a lot of activity, some have none. I guess like any community. The problem with this is it can be really daunting to get involved. Where do you start? What do you need to contribute? Hopefully this article will help.

Your first step on this road is to start getting involved in the communities. This really depends on what you want to help with but in general, signing up for OpenSolaris Discuss is probably a good place to start. After that it depends on what you want to do. If you’re looking to submit code patches it’s probably a good idea to sign up to the OpenSolaris Request Sponsor list which I’ll explain in a little bit. There are also lists relating to documentation, new users, system administrators, DTrace, ZFS and many others. Take a look through the OpenSolaris Forums page and see if anything strikes your fancy.

Ok, the rest of this article is going to be coming at this from the coding perspective as that’s where I’m coming from. Things are probably similar if you’re helping out in the other parts of the community.

Before you’ll be able to commit any code back to OpenSolaris you’ll need a contributor agreement. This is an agreement between you and Sun giving joint copyright on the code you submit. Without this agreement your code won’t be allowed back into OpenSolaris. You can learn more, and actually get the agreement on the agreement page. There is also a contributor agreement FAQ available.

When the agreements have been processed by Sun you will receive a contributor agreement number. Hold onto this number as you’ll need to reference it when submitting code.

While our agreement is off being reviewed by Sun we can go ahead and get ourselves setup to do some development. The first thing you’ll need is a base system to install OpenSolaris onto. You can get more information on getting setup here. The downloads page also gives some links to various distributions and build instructions.

Once you’ve got a base system installed you can either grab the current source code as a tarball or from the Mercurial repository. The tarballs are available at: http://dlc.sun.com/osol/on/downloads/current/ and Mercurial information is available on the project page.

The process to build and install the software is laid out in the README and in the Developers Reference Document.

When you get everything installed correctly, and if you’re like me this means doing it at least twice as the first install turned the computer into a brick, you can start fixing bugs and adding features.

There are a few different places you can look for stuff to work on if you don’t have something in mind already. The OSS Bite Sized list is a good place to start. These are bugs that are considered small and good starting points. Before embarking on any of these you might want to check the Request Sponsor list to see if anyone is working on the bug yet.

You can also search the bug database for other bugs to work on. A couple of the possible search keywords include:

• oss-bite-sized
• speeling
• oss-request

When you’re change is complete you’ll need to make a diff of the change to send in for review. There are a couple of different ways to do this depending on what system you used to receive the code.

If you’re using Mercurial you can do something like (note my Mercurial usage sucks and there is probably a better way to do this):

hg commit
hg export tip

This will output a diff of the last change commited. You can also do hg diff and give it a revision number to get all the changes from that revision.

If you’re working with a tarball then you’ll probably want to resort to trusty diff. Before you start editing a file make a backup copy of the file and then something like diff -u file.old file should do what you need.

With your diff in hand you can now send it into the request sponsor mailing list. In order for your code to be put back into the main repository you require a sponsor within Sun. The request sponsor mailing list is where you can go to ask someone to sponsor your work. In order to make it simplest for the developers you can set your subject line to be the bugid and bug synopsis (eg: 6489619 *nightly* options list should be sorted) or, if the patch fixes multiple bugs, just list the bug ids in the subject.

The body of the email should contain, again, the bug id, the bug synopsis, your contributor agreement number and have the patch attached. Any other information you think is relevant, like why you fixed the bug in a specific fashion can also be helpful.

At this point, hopefully, a Sun engineer will pickup the bug and run with it. They’ll integrate your patch into their repository, do some testing, send out a request to get some reviewers and all the other dirty work. There is probably a good chance they’ll come back and ask for some changes to the patch. Nothing to worry about, this is normal. Make any needed fixups and send them a new diff.

If the patch changes something fundamental in Solaris then you might need to get ARC review. I’m not exactly sure how this works as I’ve never had to deal with it. Just listed here as a quick heads up.

That’s it. Hopefully at this point you’ve got something integrated back into OpenSolaris.

Resources

• OpenSolaris website
• Improving the OpenSolaris project
• Developer Reference
• Sun Contributor Agreement
• FAQ Center
• Getting Started FAQ
• Nevada Development Community

Well, I just spent about 30 minutes trying to figure out why the hell my nic wasn't working. SMF was yelling at it during boot.

What I discoved is this, if your getting a SIOCSLIFFLAGS assign requested address type error message there are a few things to check. First off, make sure the hostname that /etc/hostname.skge0 (skge0 will be different for you probably) mentions is the in /etc/hosts and only in there once. Make sure the hostname in /etc/hosts has the correct ip. And finally, the piece that killed me, make sure that same hostname isn't in /etc/inet/ipnodes file as this will cause it to screw up.

And just so I can remember, setting up a router is done by putting the ip address of the router in /etc/defaultrouter. Setting your domain name is putting the domain into /etc/defaultdomain. Finally, to set your hostname put it in /etc/nodename.

These pointers maybe all incorrect, or blatantly obvious, but their working for me, and all caught me up at one point or another, heh.

I was given a laptop by work the other day and told to put Solaris 10 on it. That in itself was simple enough, the trouble came with the wireless card. It didn't come up by default and took about a day to figure out how to get it working in Solaris. This is moslty me recording what I did so that if I have to do it again I can. So you know, the card is a Intel Pro/Wireless 2915ABG chipset. Without further ado, here's how it all went down.

1- Goto www.opensolaris.org/os/community/laptop/wireless/wificonfig and follow
   the installation instructions.

2- Goto www.opensolaris.org/os/community/laptop/wireless/iwi and follow the
   installations instructions.

3- run:
     update_drv -a -i '"pci8086,2711"' iwi
   (Note the quoting -- single then double quote -- these are required)
   (Note I'm assuming your pci id will be the same. I got this number by running
     prtconf -pv and it was under 'Network controller' there will also be
     an Ethernet controller this is the wired ethernet. So, take a look
     at prtconf -pv under 'Network controller' and see if the name is
     the same)

4- do a reconfigure reboot
     reboot -- -r

5- Get the sid of your wireless access point

6- execute
      wificonfig -i iwi0 connect gabriel
   (Note, gabriel is my sid, replace with yours) you'll see something like:
      wificonfig: no such profile, use the default setting

7- execute
      wificonfig -i iwi0 showstatus
   (Note this step isn't required, but will let you know if your connected
    to your sid) you'll see something like:
      linkstatus: connected
      active profile: none
      essid: gabriel
      encryption: none
      signal strength: strong(14)

8- Now it's time to setup your interface, execute:
     ifconfig iwi0 plumb

9- Assuming your using a dhcp server execute:
     ifconfig iwi0 dhcp

And that should be it. If your not using a dhcp server you'll have to do whatever
is needed to get all of the ipaddress, netmask and gateway stuff setup for the interface
at the end there.

If you don't know the sid if your local wireless hub you can execute:
  wificonfig -i iwi0 scan

and this will return information on all of the wireless hubs it finds.

# wificonfig -i iwi0 scan
essid   bssid             type          encryption      signallevel
gabriel 00:13:10:09:52:3f access point  none            13 

As a final side note, if you don't seem to have routing try doing:
  route add default 192.168.1.1
where 192.168.1.1 is replaced by the ip address of your gateway.

Update You may need to do the plumb for the wireless card before you'll be able to scan the network. Seems that the scan won't return anything till the card is plumbed (which makes sense). So, just move #8 up before #6 and it should all be good.

On a related side note, one of the guys here at work got the sound to work on the T43s, it's a simple matter of running:

  update_drv -i -a '"pci1014,567"' audio810

and unmuting your sound card. (If you're like me and don't run JDS you can add /usr/dt/bin to your path and run sdtaudiocontrol. You _have_ to have line out enabled in order to get sounds from the speakers.)k