Monday Oct 10, 2005

OpenSolaris User Group Meeting, Amsterdam, October 18th

I've arranged for an OpenSolaris User Group BOF at Euro OSCon in Amsterdam. While the primary focus would be to get a Dutch/Benelux OpenSolaris User Group in the air.

7.30pm (19:30 for those of you who can tell time properly :-) in the Krasnapolsky Hotel in Amsterdam

I have a suitcase full of SWAG so come and get some.

Information over the BOFs and the conference can be found here

Laptop community live!

As promised, the OpenSolaris laptop community went live somewhere in the last few days.

The first wireless driver is available (Supporting some Atheros MiniPCI and cardbus cards; but Cardbus support will have to wait until the Solaris cardbus driver is released)

Watch that space for further announcement of exciting drivers which will make your laptop much more usable.

Oh, I've finally refreshed the powernow driver to be a bit more lenient with broken BIOSes and initial CPU configs which are a bit off.

Thursday Sep 22, 2005


After advancing the state of Solaris on the Ferrari 3400 with frkit, someone suggested that I should one of all new laptops we at Sun may decide to standardize on. That's how it came to be that I now have both a Ferrari 3400 and a Ferrari 4000.

But today in the mail, I got a message telling me of yet another laptop heading my way. This time a lightweight Fujitsu s2110, again a AMD64 based laptop, as those are the ones we like best.

Perhaps should I make a plot of laptops I got and when and then see if I can estimate the curve; I think I got one in '96, one in 2000, another one in dec 2004 and then again 6 months later and yet again 3 months later; with this accelerating pace it'd be one a day at christmas and one per hour early next year. Hm, perhaps not likely.

Solaris keeps on improving rapidly when it comes to device support; and while in the laptop space things appear to be moving forward very rapidly, there also appears to be some gravitating toward common chipsets. Graphics are often an issue but the fact that the Ferrari 4000 comes with a ATI X700 has the consequence that the updating of the Xorg ati driver is done much more quickly than before.

The Ferrari 3400 is relatively well supported in S10, though I think you really need my powernow driver and even then it still runs fairly hot to the touch.

The Ferrari 4000 requires some external drivers, but then, so does most bleeding hardware, regardless of OS. For the Ferrari 4000, you'll need to download the ethernet driver "bcme" from and we're working hard on getting OSS sound to work nicely on it. The 4000 runs much cooler than the 3400, but the downside is that it always has its fan blowing, albeit quitely. Probably because of a device enumeration bug, the firewire does not yet work. The SD card reader is a special device and we do not support it, unfortunately.

Of course, we're working on getting our broadcom ethernet driver "bge" and the one by broadcom "bcme" to be merged and shipped as a single driver.

Cardbus support is coming for all laptops, as the cardbus interface is properly standardized and they all work more or less the same.

I haven't gotten the Fujitsu yet, so I can't tell how well that will run and/or whether tweaking is necessary.

I don't like to recommend any particular brand or kind of laptop; one recommendation which I can make is this: run Solaris Express on it. It will get all the laptop features you may want much sooner. Such features include new drivers, Xorg support for new hardware, ACPI support, newboot, bug fixes (in some cases the difference between a device working and not working is just a small fix in an existing driver).

S10 was a huge leap forward and brought Solaris for x86/x64 to a point where it again runs on lots of (server) hardware. In Solaris Express, there is much more room for desktop/laptop innovation. We now ship several different x64 desktop platforms, so the x64 desktop/laptop space has much more visibility inside Sun.

If you want performant OpenGL, the only choice you have now is buying a laptop with an nVidia graphics chip and installing the nVidia "closed source" driver.

On the wireless front, things are moving but slowly, but more soon here. So watch this space.

Bluetooth is still a barren landscape when it comes to Solaris; I can't use the bluetooth rodent that came with the Ferrari 4000 (I'm saying rodent because it's quite a bit bigger than a mouse)

Note: I've just started the laptop-discuss list at

Tuesday Jun 28, 2005

First Installment (of frkit)

I've teased people before about the nifty hacks I've been doing for my Ferrari 3400 laptop.

The hacks I did and the tool I wrote to make the distribution easier were so well liked that there was this "meme" propagating that whenever we got even cooler laptops, I should get the first one. And so it happened, I literally got the first Ferrari 4000 shipped to Sun.

Now, this is a whole different beast than the Ferrari 3400 and I haven't yet gotten quite to the same comfort level yet.

I've long promised to make all of the neat stuff available, but legalities are the difficult part of such a venture. But now with OpenSolaris and a supported license scheme (plus management buy-in), I now feel comfortable to release the stuff which I wrote or was derived from source now available under the CDDL)

The first installment includes my single CPU "PowerNow!(tm)" driver and my battery driver and utility.

What the heck, let's throw in the mdb scripts which enable the additional keys on the Acer keyboards (mail, www, P1, P2, audio control). Some of these appear standard controls and may work for internet keyboards as well.

The tar.gz files all come with an install script which will take care of all the details of the installation; the battery driver requires ACPICA; that is only included in Solaris Nevada (11) build 14 and later.

I'll see what I can do about the GNOME battery utility we've done as well; oh, sorry for the somewhat lacking documentation.

Update: I've added acpipowertool, a small graphic battery meter by Matt Simmons, and fixed some installation issues for root user's without "nm" in $PATH.

Update2: (2005/7/31) Ive upgraded powernow so it works for more systems and to better integrate powernowadm with SMF; apcidrv is also updated to do a little bit more of thermal zone handling.

acpidrv only works for Solaris express build 14 and later; powernow should work with Solaris 10 GA also.

Update3: frkit is for some time now available as runnable script at in the

Permanent link to this entry | Comments [19] | Comments have been disabled.

Tuesday Jun 14, 2005

User Credentials and all that

Peter Harvey's story reminds me of the unforeseen consequences of creating the ucred in Solaris 10. The ucred was motivated by two factors: the introduction of privileges and a way to propagate information about process credentials through the system in userland.

Before Solaris 10, we had several mechanisms, some internal, some public, all propagating a subset of that information.

in sys/door.h:

 \* Structure used to return info from door_cred
typedef struct door_cred {
        uid_t   dc_euid;        /\* Effective uid of client \*/
        gid_t   dc_egid;        /\* Effective gid of client \*/
        uid_t   dc_ruid;        /\* Real uid of client \*/
        gid_t   dc_rgid;        /\* Real gid of client \*/
        pid_t   dc_pid;         /\* pid of client \*/
        int     dc_resv[4];     /\* Future use \*/
} door_cred_t;

in sys/tl.h:

#define TL_OPT_PEER_CRED 10
typedef struct tl_credopt {
        uid_t   tc_uid;         /\* Effective user id \*/
        gid_t   tc_gid;         /\* Effective group id \*/
        uid_t   tc_ruid;        /\* Real user id \*/
        gid_t   tc_rgid;        /\* Real group id \*/
        uid_t   tc_suid;        /\* Saved user id (from exec) \*/
        gid_t   tc_sgid;        /\* Saved group id (from exec) \*/
        uint_t  tc_ngroups;     /\* number of supplementary groups \*/
} tl_credopt_t;

in rpc/svc.h:

 \* Obtaining local credentials.
typedef struct __svc_local_cred_t {
        uid_t   euid;   /\* effective uid \*/
        gid_t   egid;   /\* effective gid \*/
        uid_t   ruid;   /\* real uid \*/
        gid_t   rgid;   /\* real gid \*/
        pid_t   pid;    /\* caller's pid, or -1 if not available \*/
} svc_local_cred_t;

and in the project I missed this one in sys/stropts.h:

struct k_strrecvfd {    /\* SVR4 expanded syscall interface structure \*/
        struct file \*fp;
        uid_t uid;
        gid_t gid;
        char fill[8];

There was also the need to be able to enquire about other processes and perhaps network connections and packets; a getpeereid interface was requested.

Now, what information should such an interface return? Network interfaces often only allow you to shape requests as a blob of bytes. And that blob needs to have a predictable maximum size too. As you can see from the above examples, even declaring a number of filler elements is not sufficient; none of the above structures which include a filler have space for the full complement of 16 groups, let alone Pete's proposed 65536 maximum number of groups.

The most natural way of implementing a blob which such restrictions is using an opaque data structure with accessor functions (in <ucred.h>):

extern ucred_t \*ucred_get(pid_t pid);

extern void ucred_free(ucred_t \*);

extern uid_t ucred_geteuid(const ucred_t \*);
extern uid_t ucred_getruid(const ucred_t \*);
extern uid_t ucred_getsuid(const ucred_t \*);
extern gid_t ucred_getegid(const ucred_t \*);
extern gid_t ucred_getrgid(const ucred_t \*);
extern gid_t ucred_getsgid(const ucred_t \*);
extern int   ucred_getgroups(const ucred_t \*, const gid_t \*\*);

extern const priv_set_t \*ucred_getprivset(const ucred_t \*, priv_ptype_t);
extern uint_t ucred_getpflags(const ucred_t \*, uint_t);

extern pid_t ucred_getpid(const ucred_t \*); /\* for door_cred compatibility \*/

extern size_t ucred_size(void);

extern int getpeerucred(int, ucred_t \*\*);

extern zoneid_t ucred_getzoneid(const ucred_t \*);

extern projid_t ucred_getprojid(const ucred_t \*);

The ucred_t itself is defined in sys/ucred.h, a header which isn't installed on the system because programs are not supposed to use it; it is a private interface between the kernel and the library.
One function of note is perhaps ucred_size() which returns the maximum size of a credential on the system; it can be used to size credentials allocated on the stack or embedded in structures.
In many cases, the system will just allocate one for you and return the allocated one, but the interfaces have been structured so you can reuse ones returned earlier or ones you allocated yourself.

By now you may be asking yourself where you get creds; well, here are some examples in the OpenSolaris source code: nscd getting a door cred, rpcbind getting an rpc caller credential and the use of the TL option by RPC.

And your typical use of the function in an inetd started daemon:

#include <ucred.h>

main(int argc, char \*\*argv)
	ucred_t \*uc = NULL;

	if (getpeerucred(0, &uc) == 0) {
		/\* we know something about the caller \*/

        return (0);

And a slightly bigger example where we use XPG4 recvmsg to receive a UCRED control messages:

 \* Send a 1 byte UDP packet; print the response packet if one is
 \* received.

#include <sys/socket.h>
#include <sys/uio.h>
#include <sys/signal.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <stdlib.h>
#include <arpa/inet.h>

main(int argc, char \*\*argv)
        struct sockaddr_storage stor;
        struct sockaddr_in \*sin = (struct sockaddr_in \*)&stor;
        struct sockaddr_in6 \*sin6 = (struct sockaddr_in6 \*)&stor;
        ssize_t bytes;
        union {
                struct cmsghdr hdr;
                unsigned char buf[2048];
                double align;
        } cbuf;
        unsigned char buf[2048];
        struct msghdr msg;
        struct cmsghdr \*cmsg;
        struct iovec iov;
        int one = 1;

        msg.msg_name = &stor;
        msg.msg_iov = &iov;
        msg.msg_iovlen = 1;

        iov.iov_base = buf;

        setsockopt(0, IPPROTO_IP, IP_RECVDSTADDR, &one, sizeof (one));
        setsockopt(0, IPPROTO_IPV6, IPV6_RECVPKTINFO, &one, sizeof (one));
        setsockopt(0, SOL_SOCKET, SO_RECVUCRED, &one, sizeof (one));

        while (1) {
                char abuf[256];
                msg.msg_control = &cbuf;
                msg.msg_controllen = sizeof (cbuf);
                msg.msg_namelen = sizeof (stor);
                iov.iov_len = sizeof (buf);

                bytes = recvmsg(0, &msg, 0);

                if (bytes >= 0) {

                        if (msg.msg_namelen != 0 &&
                            connect(0, (struct sockaddr \*)&stor,
                            msg.msg_namelen) != 0)
                        printf("you connected from %s with the credential\\n",
                                    stor.ss_family == AF_INET ?
                                        (void \*)&sin->sin_addr :
                                        (void \*)&sin6->sin6_addr,
                                        abuf, sizeof(abuf)));
                        for (cmsg = CMSG_FIRSTHDR(&msg); cmsg;
                            cmsg = CMSG_NXTHDR(&msg, cmsg)) {
                                if (cmsg->cmsg_level == SOL_SOCKET &&
                                    cmsg->cmsg_type == SCM_UCRED) {
                                        ucred_t \*uc = (ucred_t \*)

                                        /\* We have a ucred here !! \*/

                        if (msg.msg_namelen != 0)
                                (void) connect(0, NULL, 0);
                } else {

But thinking back of Pete's problem, we see a problem when increasing max groups, even worse, this libnsl private datastructure is abused and multiple copies exist which need to be kept in sync (so parts of the system broke when I changed it in this one place). The bug is an illustration why cut & paste programming doesn't work and why even when you share a private defintion, you must use a proper header file. I filed the bug as soon as I did the quick fix for the Solaris Express respin, the bug is 4994017.

Technorati Tag:
Technorati Tag:

Tuesday May 31, 2005

Southpark Stdio

I guess we all have to do this now, so here's my self-portrait. After pointing my kids to this, they and their friends spend a whole afternoon creating images of themselves, their mothers and fathers. Well, I preempted them and did myself before they had a chance.

Saturday May 07, 2005

Open Solaris Release Date Set

Well, the Open Solaris "vaporware" release date is now set; and as the end of Q2 draws near this should be no surprise. It's only a few days after my dad's 73rd birthday, so I have two things to celebrate that week.

Wednesday Apr 27, 2005

The End of Realmode Boot

I've already mentioned two great new features in our current development release; ACPICA and USB hotplug.

But there's one change that's much more far reaching than that: Newboot.

Most Solaris x86 users will be familiar with the blue screen/device configuration assistant/boot sequence and how ancient some of that feels. Perhaps few are aware that the DCA is actually a realmode DOS like environment where each boot device requires its own realmode driver. These drivers needed to be compiled with a 16 bit compiler and 16 bit MASM, not available for ready money anywhere. While the official build environment required NT, I managed to build it on environments ranging from MS Windows 98 and 2000 on actual PCs to Caldera DOS 7 on a SunPCi card (which allowed for automatic building which was great fun). Now that this piece of shameful history lies in the past, I am not afraid to confess.

But as of last Sunday, April 17th, 2005, we have "legacy free" newboot. Newboot uses grub with ufs support so we now have native grub support and a menu we can edit from inside Solaris. Device enumeration completely done using ACPI

Because it skip the device configuration assistant and boot a single large file with all kernel device drivers which makes startup quite a bit quicker and allows us to boot from any bootable device as long as we also support it in the kernel so we can mount root.

And we've reverted back to white on black consoles; this again takes some getting used, surprisingly enough.

One thing to note is that before you may had to disable ACPI in the kernel and the BIOS; with Newboot + ACPICA, you actually stand a much better chance of the system working with all the default settings: ACPI on, ACPI 2.0 enabled. Even legacy USB enabled now has a much better chance of working than before.

But this is a radical change an PC BIOSes and hardware being like it is, interesting times ahead. SO please test drive when this hits Solaris Express in a few months time.

As of this writing, it's a bit in the balance whether you'll get to see the source first as part of OpenSolaris or the binaries as part of a Solaris Express.

Tuesday Apr 26, 2005

Netherlands/Benelux OpenSolaris/Solaris Usergroup

A few of our customers approached me to start a Solaris user group in the Netherlands (or perhaps a somewhat larger area)

Any takers? Perhaps offers of venues, talks wanted?

For those who don't know, I am based in the Netherlands.

Yet Another Desktop/Laptop Usability Step

"Solaris Nevada" build 14 is proving to be another quantum leap for Solaris desktop usability.

I discussed the new USB hotplug support in vold before, but in the last few days we've also gotten the virtual keyboard/mouse driver in the next Solaris release. People often complained about the fact that their laptop keyboard died until the next reboot when they plugged in a USB or other keyboard. Well, not anymore! We now have virtualized keyboard and mouse drivers which collect events from all available keyboards and present them through a single virtual keyboard and mouse. It is also still possible to use the devices as seprate devices in case you have a multi-head/multi-user environment, but for the common case of a single system with multiple keyboard (laptop + keyboard) this is another big step.

You can plug in the other keyboard at any time, running under X or the commandline, it just works.

Solaris FAQ Updated

For the first time in many years (2.5 years) I've updated the Solaris FAQ

Much more work is needed on it but at least this is a start. I'm hoping to update it more regularly now. It's also still here but it seems to be doing fine there.

Wednesday Apr 20, 2005

ACPICA in Solaris

With the long history of neglect that Solaris on x86 endured, quite a few components got to be extremely stale and fragile. And this wasn't just a lack of device drivers but also a lack of basic new functionality in the core OS.

This week saw another quantum leap; the induction of Intel's ACPI reference implementation (ACPICA) into the next Solaris release.

For years I wanted to have battery support on my old VAIO and later on my Ferrari. And I wanted a power button that did something, etc. I tried to make do with the old "acpi_intp" interpreter which was part of Solaris; but it leaked memory like a sieve and was limited in functionality. Integrating ACPICA looked daunting but fortunately someone made an actual project out of this and the end result is that we now have a state of the art ACPI interpreter in Solaris.

There are basically only two ACPI interpreters in widespread use: the Windows one and the Intel one; by leveraging Intel's source, we stand a fair chance of having Solaris work with more ACPI BIOSes. If our system required ACPI to be turned of for Solaris to work, you may find yourself forced to switch it on when you upgrade later this year.

I've been distributing acpica and a number of other useful Solaris binaries in a single internal kit called "frkit" (originally aimed at Ferrari's but now running on countless systems); frkit includes acpica, a powerbutton/battery handler, an AMD PowerNOW! powermanagement module, a GNOME battery monitor, and our development cardbus and wireless drivers + tools.

One of the more interesting parts of that is possibly the "NDISulator" port from FreeBSD which allows the Sun Ferraristi to use the builtin Broadcom wireless on their ACer Ferraris in 32 and 64 bit mode.

ACPICA is just phase one of a larger project; we have not yet bothered much with the "P" (for power) from ACPI; but we hope to leverage the new implementation to provide the necessary "S3" and "S4" sleep state support.

The speed at with new features work on my Ferrari which I've had now for 4 months is in stark contrast with my Vaio which I got not too long before S9 for x86 was postponed. It's clear that we needed a ramp-up after the wind-down, but it seems to be going more quickly than ever before.

Tuesday Apr 19, 2005

USB hotplug finally works

Today I was pleasantly surprised to see the latest putback to SNV, our next Solaris release (soon on a OpenSOlaris source server near you)

Before this putback you could hotplug/eject devices into devices (SD cards and such in card readers, floppies in floppy drives) but you had to restart vold to mount USB pen drives. But now, you can insert them, remove them, etc, and they're mounted and unmounted automatically.

This was really one of my most wanted features and its great to finally have it. Will it make an update? I certainly hope so; but you can always try Sun Express.

Thursday Apr 14, 2005

Solaris 10 Encryption Supplement download

The Solaris 10 encryption supplement is available for download here. Apparently, it's difficult to find going through the Sun download sides so I give a link here.

The supplement adds 256 bit AES and 448 bit Blowfish; DES, 3DES, 128 bit AES, blowfish and RC4 are already in the standard release. In other words, the standard release gets you what you would have gotten with the encryption supplement for older releases. And the S10 Encryption Supplement takes it one step further. The main reason for not making this part of the Solaris CDs is import restrictions, rather than export restrictions.

Tuesday Apr 12, 2005

Timezones and multi boot.

One of the things that has always been bothering me is the fact that on x86 systems you cannot really run multiple operating systems and survice the timezone change. That's because the clock runs in local time; and localtime is ambiguous. The system cannot tell whether the DST change has been or not so it needs to record this fact in the filesystem (that's why Solaris on x86 has the "rtc -c" cronjob). If you boot all your OSes in turn after the changeover, your system will be N hours off once they're all done adjusting time. The problem is probably best summarized here

On Unix this was long solved by running the clock in the UTC or GMT timezone; that clock is unambiguous, give or take a leap second, and allows multiple versions of the OS to coexist.

Last week, it was pointed out to me in comp.unix.solaris that there is a hidden registry key in later releases of MS-Windows. I already knew how to fix up Solaris, so I combined this to:

       Set the following registry key (it does not exist!)


       In the control panel with Day&Time settings, check the "automatically adjust" check box.

        Boot into Solaris and run:

              rtc -c -z UTC

        then correct the clock with date/rdate
        (if you use liveupgrade, lumount your other partition(s) and copy the
        /etc/rtc_config file to all of them)

        In Linux, you'll need to run "timeconfig" and select "RTC set to GMT".

Note that if you don't multiboot, it's probably also a good idea to run "rtc -c -z UTC" and then correct the date; for one you won't be bitten by the AMD64 timezone bug we had in Solaris 10.



« July 2016