Liane Praza's Weblog

Liane Praza's Weblog

All | General | Solaris

Main | Next page »
20080310 Monday March 10, 2008

VirtualBox on Indiana

I've taken the leap and converted my desktop to run Indiana Developer Preview 2. It's looking pretty nice so far, but as the Preview title suggests, running this as a primary development machine is still a bit on the bleeding edge. So, I'm filing or updating bugs at http://defect.opensolaris.org as they pop up.

Getting VirtualBox running was one of my top priorities so that it remains easy to test in-development bits on Nevada too. So, I downloaded and installed VirtualBox for my amd64 system, and got this: 

$ /usr/bin/VirtualBox
ld.so.1: VirtualBox: fatal: libX11.so.4: open failed: No such file or directory
Killed

So, I found (well, David pointed me at) Indiana bug 512, which describes the missing symlink. Since it's just a missing link, I was easily able to work around it. 

  # cd /usr/lib/amd64
  # ln -s ../../X11/lib/64/libX11.so.6 libX11.so.4

Now I can launch /usr/bin/VirtualBox, and am installing Nevada right now.

(2008-03-10 17:38:00.0) Permalink Comments [2]

20070731 Tuesday July 31, 2007

playa programming -- OpenSolaris at Burning Man

For my eighth year at Burning Man, the two-by-four of inspiration whacked me upside the head and stole away my summer free time. On evenings and weekends I've been working feverishly on an art installation called The Belligerent Blooms. With lots of help and indulgence from Jan, Bart, and encouragement from the rest of my campmates, the project is starting to take shape. There's been plenty of programming, hacking, drilling, sawing, soldering, and even a little bit of welding. The whole project is centered around an OpenSolaris-based system driving audio for this embedded application. There's no electricity out at Burning Man, and generators are noisy -- so with a bit of begging, we've managed to borrow 2 solar panels to charge the battery which runs the whole installation. For those playing along at home, that means we'll be running Sun on the Sun.

This post will (hopefully) be the first in a series about how the software and hardware of this art project was put together. The series will likely come in fits and starts as time before the event is precious -- we depart on August 26, so blogs may have to wait until we return. But, before I begin the series, there's some more begging to do...

The Belligerent Blooms need your audio contributions!

The Belligerent Blooms are a garden of cranky electro-mechanical flowers, accosting passers-by with their deeply rooted beliefs. We need your unique voices to contribute to the cacophony.

Consider what you'd say if you were a belligerent bloom -- share your experiences as part of nature, opinions about humanity in general or Burning Man participants in particular, or any other flowery invective you have to offer. Try to keep the comments short and pithy. Get a giggle, challenge world views, add your voice! Above all, be belligerent!

Contribute your flowery invective by sending mail to belligerent.blooms@gmail.com and including .wav (preferred, and easily generated by audiorecord(1)) or other audio files. Putting your quips in separate files will greatly please the gardeners. Contributions made by August 19, 2007 will be included.

If you, or someone you know attend Burning Man, the Belligerent Blooms make their home at the 'Blacklight Aquarium' theme camp. Habitat and 7:30; just look for the big spinning fish sign in the sky.

Technorati Tags: , , , and .

(2007-07-31 20:56:05.0) Permalink Comments [1]

20070726 Thursday July 26, 2007

zone out and speed up your development cycles

The other day, as an aside in a conversation about how often developers use certain OS features, I was asked how often I use Solaris Zones. At least weekly, and daily if I'm lucky enough to be spending my time on code.

Surprised? Userland developers on Solaris shouldn't be.

I spend a great deal of time modifying libraries and daemons started really early in the Solaris boot process. While SMF tries to dump you at an sulogin prompt if you've introduced a bug, it's still a bit of a pain to recover from some nasty failure or hang you've coded into init(1M), svc.startd(1M), or libscf(3LIB). Zones make the deploy and reboot cycle go really really fast, and recovery from late-night programming errors is a breeze!

Here's what I do:

  • Create a whole root zone. Takes up more disk space, but allows me to replace any system binary: 

            # zonecfg -z test
        test: No such zone configured
        Use 'create' to begin configuring a new zone.
        zonecfg:test> create -b
        zonecfg:test> set zonepath=/test-zone
        zonecfg:test> commit
        zonecfg:test> exit
        # zoneadm -z test install
        # zoneadm -z test boot
        # zlogin -C test
           ... answer sysid questions, and log in

  • Make sure the bits I'm compiling are relatively close to the bits installed on my desktop. Live Upgrade and I are close friends so that I can keep my desktop as up-to-date as my workspaces.

  • Create a script to dump my modified bits into the zone root. Something like this fragment: 

            gate="/net/coupe/builds/lianep/templates/usr/src"
        zone="/test-zone/root"
        if [ ! -d $zone ]; then
            echo "no zone root here: $zone"
            exit 1
        fi
        cp  ${gate}/lib/libscf/i386/libscf.so.1 ${zone}/lib
        cp  ${gate}/lib/libscf/amd64/libscf.so.1 ${zone}/lib/amd64

  • Compile, run script, test, debug, fix, repeat.

After my code is all basically working, then I move on to testing on the bare metal. But, the fast reboot times of zones and the easy ability to replace a broken library with a library broken in a new and different way is invaluable to making very rapid progress. I've rebooted my zone at least 15 times today. Compiling the library takes longer than the zone deployment and reboot! Every few months I mismatch libraries and commands from different workspaces and foul up my zone badly enough that it needs to be re-installed. But, zoneadm -z test uninstall; zoneadm -z test install provides a convenient excuse to go get coffee and then I'm back in business.

Technorati Tags: , , , and .

(2007-07-26 21:07:45.0) Permalink Comments [3]

20060627 Tuesday June 27, 2006

starting ssh early in boot

It's nice that as of Solaris 9, ssh is included in Solaris. We've always started it late, though. That's a conscious decision made by the ssh team to include dependencies which mean that it won't start until all local and network services any user might need, including remote filesystems, are available.

This is great for interactive environments with many home directories stored on the network. Your users don't end up with spurious and surprising home directory not available messages if you try to log in too early during the boot process. But, if you've got a server stranded in a co-lo many miles away, this might not be what you want. You may want ssh to start up as soon as the root filesystem and basic networking are available, and be available if you boot to single-user mode. Here's how for Solaris 10 and similar releases (no guarantee of fitness for more recent bits):

  • Remove the ssh dependencies on services you don't need. The full dependency list for ssh is:

       $ svcs -d ssh
   STATE          STIME    FMRI
   online         Dec_19   svc:/network/loopback:default
   online         Dec_19   svc:/network/loopback:default
   online         Dec_19   svc:/network/physical:default
   online         Dec_19   svc:/system/filesystem/usr:default
   online         Dec_19   svc:/system/cryptosvc:default
   online         Dec_19   svc:/system/filesystem/local:default
   online         Dec_19   svc:/system/utmp:default
   online         Dec_19   svc:/system/filesystem/autofs:default

    Since I said I wanted just the network and the root filesystem to be available (oh, yeah, and the crypto services we need to do proper encryption), I'll delete everything else. That means I first look at the dependency property group names: 

       # svccfg -s ssh listpg
   config_data     dependency
   cryptosvc       dependency
   net             dependency
   fs-local        dependency
   fs-autofs       dependency
   net-loopback    dependency
   net-physical    dependency
   utmp            dependency
   [...]

    Dependencies are helpfully named here and have type dependency, so I'm not looking much futher to see the ones to delete. Deleting the dependency on utmpd is a little risky, but I'm willing to live with the risk to commands like last(1). So, I go ahead and delete the property groups which configure those dependencies. 

       # svccfg -s ssh delpg fs-local
   # svccfg -s ssh delpg fs-autofs
   # svccfg -s ssh delpg utmp
   # svcadm refresh ssh

   # svcs -d ssh
   STATE          STIME    FMRI
   online         Dec_19   svc:/network/loopback:default
   online         Dec_19   svc:/network/loopback:default
   online         Dec_19   svc:/network/physical:default
   online         Dec_19   svc:/system/cryptosvc:default
   online         Dec_19   svc:/system/filesystem/local:default

None of this is endorsement to go around deleting dependencies willy-nilly on your system. All of them are there for a reason, and deleting them without understanding their purpose is guaranteed to lead to pain. If you have any problems with a service where you've deleted dependencies, the first step is to put them back! There are no places in which we've added dependencies to services for fun. Some of the dependencies you might see that seem superfluous are the ones that we added only after finding some very subtle breakage without them.

(2006-06-27 09:20:30.0) Permalink Comments [4]

20060516 Tuesday May 16, 2006

Towards a SANE SMF

SANE 2006

Thanks to a very kind invitation from the conference organizers, I'm at SANE 2006 and finished up a half-day SMF tutorial earlier today. The room was pretty full, and there were plenty of good questions to keep me on my toes. I promised to post the slides on my blog, so here they are. The conference provided Certificates of Completion for anyone who stayed in my session until the end, so I'd also like to present an honorary and virtual Certificate of Completion for David Bustos and Bob Netherton, from whom I borrowed some of the slide material. :)

As this is my first time in the Netherlands, it seems necessary to include a tourist snapshot. There's a lovely old church (indeed, Oude Kerk) visible out my window; no reference to Vermeer was originally intended, but given that he's interred at Delft's Oude Kerk perhaps it was inevitable (though inappropriate for such a poorly lit photograph). The charming half-hourly bells would be more so if they weren't conspiring with my current state of jet lag to limit sleep to nap-length increments.

(2006-05-16 15:25:27.0) Permalink Comments [1]

20051004 Tuesday October 04, 2005

Manifest collecting

In case you're not reading Stephen's blog, I wanted to mention that we're collecting smf(5) manifests for all sorts of software over on the OpenSolaris smf(5) community. We're getting through our backlog of manifests to include slowly but surely, so if you've written a manifest you want to share, or even just know of an interesting manifest or two out on the web, come on over and give us a pointer.

(2005-10-04 09:01:01.0) Permalink Comments [5]

20050826 Friday August 26, 2005

Another year on the playa

I'm headed out for yet another year at Burning Man. I'm rather new from some perspectives -- I've only been attending since 2000, but have been there religiously since my inaugural year. This is the first time since that first year I have the luxury of arriving on Sunday and staying the whole week. Hurrah! Seeing an essentially empty plot of land grow to a city of 35,000+ (complete with roller coasters(!), churches, mail delivery, roller rinks, bars, pools, an opera, newspapers, radio stations, an incredible array of art, and most anything else you can imagine) and then all completely disappear within 7 days is an experience that's hard to replicate elsewhere.

Plenty of people have drawn parallels between open source communities and the Burning Man community. What Burning Man has that most open source software projects don't have is that tear-it-apart moment. The transient nature of the physical community is part of the appeal. At the end, you watch lots of incredible things literally go up in flames, and the rest of it disappear overnight. Walking around the last night is incredibly surreal; the landmarks you used for navigation all week have vanished and you're left a little lost and confused as the ephemeral community precipitates back into their everyday lives. While it's a crucial part of playa life, I expect to never have that moment with OpenSolaris.

All of this is a pretty long winded way of saying that I'm taking a vacation, and will return to blogging after I dig myself out of the overwhelming email backlog that accompanies any sort of time away.

Technorati Tags: and

(2005-08-26 15:55:37.0) Permalink Comments [0]

20050825 Thursday August 25, 2005

How does :kill work?

The :kill method token is kind of cool. Rather than maintaining a pid file or using some grungy invocation of pkill (which almost always is incorrect for services that may run on a system with zones) to find all the processes required to stop your service, you can use the :kill token in your method to simply say "kill off all the processes in this service". Works great with contract type services in startd (but not so much with transient services). You can see smf_method(5) and the developer intro for more details about :kill from the service developer's point of view.

I found out recently that I didn't talk about how the :kill method token works when I talked about general fault isolation in smf(5). It's just so simple that I forgot to mention it. But still, you need to know the key...

Since contracts already take care of grouping the processes for us into services, and extended the appropriate kernel interfaces to allow operations on contracts, we can actually just send a signal to all processes in the contract easily with sigsend(2). So, the contract kill function in svc.startd(1M) is mind-bogglingly simple. All you need is a contract id.

int
contract_kill(ctid_t ctid, int sig, const char *fmri)
{
        if (sigsend(P_CTID, ctid, sig) == -1 && errno != ESRCH) {
                log_error(LOG_WARNING,
                    "%s: Could not signal all contract members: %s\n", fmri,
                    strerror(errno));
                return (-1);
        }

        return (0);
}

Nice, huh? Having contracts as a well-supported kernel feature makes some previously impossible things now possible, and generally makes the life of the restarter author easier. This is, to me, one of the truly significant benefits of having a kernel that evolves in concert with its userland tools.

Technorati Tags: , , and .

(2005-08-25 18:01:29.0) Permalink Comments [3]

20050819 Friday August 19, 2005

A few OSCON pics

Well, I've passed the expiration date for a useful trip report of OSCON. I'll keep this short and sweet and get a few pictures posted. It was my first time at OSCON, and I'm glad I went. It was great to go and talk about OpenSolaris and Solaris in general; among the fun was our rockstar-style suite (complete with getting admonished by the hotel for talking about OpenSolaris too loud on Wednesday night), the booth, a number of good talks by Bryan and Keith, and a small but fun BoF.

From an smf(5) point of view, I got to chat with one of Apple's launchd guys, which was definitely interesting. launchd had a very different design center and problem definition than the smf(5) team was working with, but ended up with strong similarities to smf(5) in their solution. We also have some diverging functionality too, but the similarities often generate comment. And to dispel any myths... launchd wasn't yet out when we were releasing smf(5) in Solaris 10, and the launchd guys say they didn't see our stuff until they were nearly complete. Chalk it up to "great minds think alike", if you're feeling charitable. :)


Jon Masters, Devon O'Dell, and I showed our stripes and shared a drink at the OpenSolaris suite.


Sara Dornsife, Patrick Finch, and Claire Giordano from OpenSolaris marketing.


Some dorky-looking geek with Teresa Giacomini of the OpenSolaris team and Casper Dik: CAB member, security guru, and Solaris expert.


Technorati Tags: , , and .

(2005-08-19 18:37:59.0) Permalink Comments [4]

20050801 Monday August 01, 2005

Off to OSCON

As folks like Keith and Bryan have already noted, there are plenty of OpenSolaris happenings at OSCON this year. I'll be at the OpenSolaris BOF at 8:30pm Wednesday evening, so stop by if you're around.

I'll also be knocking about the conference/Portland in general Tuesday night through Friday. Leave a message for me at my hotel (503-222-0001) if you'd like to meet up for a beer and talk about OpenSolaris, Solaris, or smf(5). I'll even be happy to help you write an smf(5) manifest for any open source or commercial service; conditional only on your willingness to publish the manifest for others to use. :)

Technorati Tags: , , and .

(2005-08-01 17:34:42.0) Permalink Comments [1]

20050727 Wednesday July 27, 2005

rpc/bind in single-user mode

A really simple tip today. If you want rpcbind(1M) or any other service started while in single-user mode (boot -s) or netbooted to single-user for repairs, all you need to do is temporarily enable the service. Using temporary enable (svcadm enable -t) gets around the repository not yet being writable -- after all, you weren't looking for your change to take effect outside of your maintenance environment.

You may also find that the service you want requires other services. svcs -l will show you the complete dependency list with current states displayed. Rather than going through and doing manual enables of everything, you can use the -r option for svcadm enable to tell it to recursively enable all services that are required. So, to temporarily enable rpcbind(1M) and all the services it requires while in single-user mode, use:

   # svcadm enable -rt rpc/bind

As promised, pretty simple. Someone commented this isn't well covered in our current documentation set. I've filed a bug, so you should see a similar task in the System Administration Guide in a future release.

Technorati Tags: , , and .

(2005-07-27 09:22:13.0) Permalink Comments [0]

20050714 Thursday July 14, 2005

smf(5) fault/retry models

Someone asked on an internal Sun alias how svc.startd(1M) determines whether there was a fault in the service and when to put the service in maintenance. Unfortunately, this is not well-described in our existing manpages, but I'm working on that. Still, it takes a little while for manpage changes to propagate into the mainline Solaris release so I figured I'd include my description from email here. A more formal version will be coming, and I'll update this post if subsequent questions yield a better description.

It is important to mention first that svc.startd(1M) offers three separate service models: contract, transient, and wait. These are described in the Service Developer Introduction. I'll only touch on the fault/retry models for the common ones, contract and transient here.

Next, I'd like to point out that there's a distinction between method failures and service failures, from svc.startd(1M)'s point of view. So, I'll go over each type of failure and how it is handled.

svc.startd(1M) believes a method has failed if it returns a non-zero exit code. Method failures cause a service to go into the maintenance state immediately if the exit code is $SMF_EXIT_ERR_CONFIG or $SMF_EXIT_ERR_FATAL. All other failures will cause the service to go back to offline. Remember, as smf(5) describes, if a service is offline and its dependencies are satisfied, we try to start the service. But, if 3 method failures happen in a row, or if the service is restarting too quickly, that service will go into maintenance.

A service failure is determined by a combination of the service model (transient or contract) and the value of the startd/ignore_error property.

A contract type service is considered to have failed if any of the following conditions occur:

  • all processes in the service exit

  • any processes in the service coredump

  • a process outside the service sends a service process a fatal signal (e.g. an admin pkills a service process)

The latter two of these conditions may be ignored by the service by specifying core and/or signal in startd/ignore_error. All of these service failures are detected by contract events. I've talked earlier about contracts and fault isolation in smf(5) too.

Defining a service as transient means that svc.startd(1M) doesn't track processes for that service, so none of the service errors above matter. Thus, a transient service only goes to maintenance if a method failure occurs.

Technorati Tags: , , and .

(2005-07-14 13:34:02.0) Permalink Comments [1]

20050624 Friday June 24, 2005

assembling services for boot with smf(5)

In order to deal with some pretty stringent backwards compatibility requirements for install, smf(5) attempts to self-assemble services during boot. I won't go into the vagaries of why it is so helpful to avoid having to write the smf(5) repository during install/upgrade now, and instead stick to the tactical details of what happens in Solaris/OpenSolaris. Most of this focuses on the behaviour of smf(5) during the first boot.

Some background details

First, a refresher (or an introduction, depending on your perspective). The delivery mechanism for services in Solaris smf are Service Manifests. They're a bunch of XML goo which describe metadata and optionally data about a service: how do I start it, what's the service model, is it an inetd service, etc. If you're interested in how to write a manifest, see the Service Developer Introduction. However, the system doesn't really know anything about a service described by a manfest until it is imported with svccfg import. At import time, the data is copied from the manifest and put into the smf(5) repository. (I wrote a bit about the design choices we made when creating the repository in another post.)

Once a service is in the repository, all of the smf(5) framework kicks in for that service -- displaying it with svcs(1), starting it during boot, restarting on failure, etc. But, until the service has been imported into the repository, smf(5) knows nothing about it. The persistent repository information is stored as a data file in /etc/svc/repository.db.

The seed repository

As I already mentioned, smf(5) only cares about the repository, so we need to generate enough of a repository to get the system to the point where it can import more manifests. What's required for that? Essentially, the / and /usr filesystems must be mounted and writable. We need the utilities from /usr and obviously we can't write to /etc/svc/repository.db without a writable root filesystem. We call this repository the seed.

When you build OpenSolaris (and when we build Solaris internally) in addition to compiling all of the smf(5) source code, we also assemble the seed repository. Essentially, what goes in the seed is what's required to start svc:/system/manifest-import:default. You can see how we assemble this during the build in usr/src/cmd/svc/seed/Makefile. We build a seed for both the global zone and the non-global zones, since the non-global zones require fewer services to get to manifest-import.

You can look at what's in the seed repository for your system. For something resembling current OpenSolaris bits, this looks like: 

    $ cp /lib/svc/seed/global.db /tmp/global.db
    $ svccfg     
    svc:> repository /tmp/global.db
    svc:> list
    system/boot-archive
    network/datalink
    network/physical
    system/device/local
    milestone/devices
    system/identity
    system/filesystem/local
    system/manifest-import
    system/filesystem/minimal
    [...]

If you look carefully at that Makefile, though, we don't place these in the normal repository location, we stash them at /lib/svc/seed/[non]global.db. This ensures that when folks use bfu, we don't over-write the local service configuration with the very limited seed repository! It is important to note that no /etc/svc/repository.db gets generated during the OpenSolaris build process.

Placing the seed

There's logic in both bfu and the i.manifest package class-action script which place the appropriate seed repository in /etc/svc/repository.db if the file doesn't already exist. Thus, if you're using bfu or the Solaris pkgadd(1M), we copy the seed to the correct location for you. The Solaris install CD/DVD/netinstall image also creates its own repository.db, based on the seed we generate during the ON build.

Finally, the boot discussion

OK, so now we have a system with a very very limited seed set of services as its repository. Those services are really limited, and don't even include essential things like ssh(1). But, the system is able to boot to the point of running the manifest-import service. We'll assume it does so successfully. Then the manifest-import start method kicks in. First we find all the manifests in /var/svc/manifest:

    423 nonsite_dirs=`/usr/bin/find /var/svc/manifest/* -name site -prune -o -type d \
    424 	-print -prune`
    425 
    426 nonsite_manifests=`/lib/svc/bin/mfstscan $nonsite_dirs`
    427 site_manifests=`/lib/svc/bin/mfstscan /var/svc/manifest/site`
    428 
    429 manifests="$nonsite_manifests $site_manifests"

mfstscan is a private command which finds any manifests in the subdirectories provided and checks to see if they've changed since last import. Then we import any manifests which have changed, keeping a running count so the user knows something is happening:

    443 	set -- $manifests
    444 	backup=`echo "$#/$#" | sed 's/.//g'`
    445 	fwidth=`echo "$#\c" | wc -c`
    446 
    447 	echo "Loading smf(5) service descriptions: \c" > /dev/msglog
    448 
    449 	i=1; n=$#
    450 	while [ $# -gt 0 ]; do
    451 		printf "%${fwidth}s/%${fwidth}s" $i $n > /dev/msglog
    452 		svccfg_import $1
    453 		i=`expr $i + 1`
    454 		shift
    455 		echo "$backup\c" > /dev/msglog
    456 	done

But how do services get enabled?

Some of you may have noticed, though, that OpenSolaris has most of the services specified as disabled in their service manifests. You can see this, for example, with the syslog manifest. The enabled='false' means that the service will be disabled after it is imported. But, on your running Solaris system, it is enabled.

What's happening after the manifest imports in the manifest-import start method is that profiles are being applied. As I described here, profiles are just a way to enable or disable a bunch of services. Solaris/OpenSolaris tries to deliver as many services as possible as disabled in their manifest, so that an administrator can choose carefully which services they want to enable, and when we add new ones, they won't be automatically enabled unless absolutely necessary to get to manifest-import. We look for the following profiles and apply them in order:

    /var/svc/profile/generic.xml
    /var/svc/profile/platform.xml
    /var/svc/profile/site.xml

generic.xml is created as a link to generic_open.xml both during the build process and by the Solaris packaging tools. The platform.xml profile is created as a link to the appropriate file during boot by the manifest-import start method:

    480 if [ ! -f /var/svc/profile/platform.xml ]; then
    481 	this_karch=`uname -m`
    482 	this_plat=`uname -i`
    483 
    484 	if [ -f /var/svc/profile/platform_$this_plat.xml ]; then
    485 		platform_profile=platform_$this_plat.xml
    486 	elif [ -f /var/svc/profile/platform_$this_karch.xml ]; then
    487 		platform_profile=platform_$this_karch.xml
    488 	else
    489 		platform_profile=platform_none.xml
    490 	fi
    491 
    492 	ln -s $platform_profile /var/svc/profile/platform.xml
    493 fi

Finally, site.xml is left entirely to the control of the administrator. If you're interested in re-visiting this boot order, take a look at smf_bootstrap(5). These profiles enable all of the services that were just added by manifest-import. If you want to use one of our limited profiles like generic_limited_net.xml, you can do the following before reboot (i.e. during jumpstart):

    $ ln -sf /var/svc/profile/generic_limited_net.xml /var/svc/profile/generic.xml

Or, you can just place your customizations into /var/svc/profile/site.xml, and they'll be applied after the Solaris/OpenSolaris-delivered profiles are applied.

Technorati Tags: , , and .

(2005-06-24 15:42:58.0) Permalink Comments [3]

20050620 Monday June 20, 2005

Where did all my blogs go?

I'm away from my mail and my blog for a few days, but realized that yesterday may have brought an unpleasant surprise for folks. The main OpenSolaris blogs page no longer contains the entire list of entries that appeared on Opening Day! Not to worry -- the OpenSolaris webmasters keep an archived list of posts. You can keep reading through the entire list of blogs from Opening Day, or start with one of the higher-level lists Bryan and I have been compiling. I'll return later this week and finish up the tour of smf(5) code I've been planning.

Technorati Tag:
Technorati Tag:

(2005-06-20 08:21:52.0) Permalink Comments [2]

20050615 Wednesday June 15, 2005

OpenSolaris blogs: networking, drivers, security, and standards

Looking through the huge number of blogs written yesterday about deep technical topics in the OpenSolaris source code, I'm again flattened by the depth of expertise that's represented in these entries. There's a lot to navigate, and Bryan and I will be trying to give some lists by subject area. I hope others will start their own as they find content that's useful to them. Even if you don't have a blog, del.icio.us allows you to create tagged lists of bookmarks.

Security:

Devices and Drivers:

  • Artem talks about 1394 (Firewire) and SCSI.
  • Sophia gives some details about Solaris' AGPgart.
  • Drivers are mentioned peripherally, but it's just a great entry so I won't leave out Jim's description of 4028137.
  • ATA and SATA from Mary.
  • Haik handles cfgadm, which isn't a driver per se, but is close enough to fit here.
  • Jerry handles failing faster for SVM (sounds strange, but is incredibly useful -- stopping retries early when hardware is truly dead decreases recovery times).
  • Dan talks about the Zones console and console driver.
  • SVM and RAID 0+1 and RAID 1+0.
  • New boot, described by Jan changes device interaction with system startup.
  • Mark gets pretty deep into DMA.
  • Dilpreet covers hardening a leaf device driver
  • ACPI is getting plenty of coverage on David's blog.
  • Fritz gives an overview of the USB architecture.
  • Alok mentions SVM diskset import, an its-about-time feature that appeared in Solaris 10.
  • The devid cache in Solaris 10 is covered by Jerry.

By the way, I threw in the towel early on collecting SVM entries for this section. There's a bunch of really great content that will deserve its own list at some point!

Networking:

Standards:

And, by the way, most of the entries above just wouldn't have been possible without the help of Chandan's incredible source browser for OpenSolaris.

If you're interested in seeing all the archived blog links, check out our opensolaris.org blogs page. I've tried to be really inclusive here and pick up entries that will suit many experience levels. The unifying factor is that every entry is by an expert in the area. If you have an entry I've missed in one of the topic areas, leave it on the comments for everyone to see.

Technorati Tags: and

(2005-06-15 16:48:27.0) Permalink Comments [2]

Calendar

« July 2008
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

RSS Feeds

XML
All
/General
/Solaris

Search

Links

Navigation


blogs.sun.com
Weblog
Login


Referers

Today's Page Hits: 252