Friday Jun 15, 2007

The next step for packet interception in [Open]Solaris

The packet filtering hooks project (PSARC/2005/334) delivered a first take on a framework to deliver the ability to intercept packets inline with the processing flow without requiring any additional STREAMS modules to be inserted between IP and the network device driver. Whilst this has been successful in improving performance for IPFilter, the other primary goal of exposing an interface for external use has not yet been achieved. The rest of this blog entry will summarise what the state of play is here and what we need to be doing for the future. The design document for PSARC/2005/334 can be found at: Packet Filtering Hooks Design, 3 Sep 2006

Interface Changes

The goal of software engineering fot the Solaris kernel is have all of the Committed public APIs become stable, so that code can osentsibly be recompiled, or even reused as binary blobs, on any later release. This means that it is necessary to understand in great depth how the interface is going to be used.

For the packet filtering hooks, the design presented for PSARC/2005/334 was for a world without IP Instances (PSARC/2006/366.) IP Instances introduced something very important that was previously absent: a pointer that was the context in which all of the networking code needed to run. For packet filtering, this impacts the interface at which packets are delivered to IPFilter. It also impacts the initialisation/teardown as IPFilter was changed to provide a seperate set of rules for each IP Instance. This one change, introducing context for IP, would have meant an incompatible change was required to the kernel interfaces published - not a position we would ever want to be in by design.

Life being what it is, the existing documentation for PSARC/2005/334 was written without taking into account the changes from PSARC/2006/336, so at this point in time, the documentation of the interfaces is not 100% correct in describing the function calls and parameter lists. Looking forward, we need to revisit this area and update internal drafts of documentation to better reflect these changes so that they can be included in the distribution and published at the appropriate point in time.

Functionality Changes

The biggest problem with PSARC/2005/334 as it existed going into PSARC review was how to manage multiple hooks for the same event, especially when hooks are given license to change the contents of a packet. The first proposal was to use a numbering system that implemented a priority mechanism, similar to what Linux uses today, but this was rejected. The current thoughts on how to proceed with this are to allow two different mechanisms:

  • When registering a callback for a particular hook event, allow one of following attributes to be specified:
    • first - put the callback at position #1 in the list
    • last - put the callback at end of position the list
    • before - require that this callback be before another callback
    • after - require that this callback be after another callback
  • Allow a command line utility to specify a more absolute ordering, such as "a,ipf,\*,y" that overrides the above

Without a final design that is accepted to answer this capability, it is not possible to promote the current API to being suitable for public use. This is one of the major issues that is outstanding today - only one callback can be registered for hooks such as inbound IP packets.

Kernel Socket Interface

At the time the first design was put togehter, there was no work being done on an interface to present an API for kernel socket programming, so some functionality that exists in user space via ioctls was implemented internally with direct function calls instead. An easy example of this is obtaining an IP address from a network interface. Fast forward to today where we do have a project underway to deliver Kernel Sockets, we need to reconsider whether or not it is necessary to retain that direct function call interface or discard it because it duplicates functionality.

Summary of the state of play today

So where are we at today?

Today we have a programming interface that exists in [Open]Solaris where the primary user is IPFilter. The API used is considered to be private (or internal), so strictly speaking it is not available to programmers outside of Solaris development. However, because it will result in various header files being shipped and that the source code can be easily observed, it seems like it is there, ready, waiting to be used.

At this point, the best we can say is that people should look at the PDF above, look at the header files and start to experiment with it, get a feel for how the interface works, how to integate it into your greater source code tree, etc, with the knowledge that whilst it may compile and work cleanly for you now, the programming interface will change, it will fail if another hooks beats you to registering and most importantly, it is unsupported, meaning if someone else outside of Sun has a problem (i.e panic) using it, Sun is not in any way obliged to either fix the problem or provide a patch.

Invitation to ISVs

If you're reading this blog entry and you work for an ISV that is intending to target Solaris for your product or you're working to build a product on top of Solaris and wish to make use of this interface at some point in the future, the best advice is to contact your local Sun sales office and get in contact with someone from our MDE team.

Discussion on changes

If you would like to either comment on the above design doucment for PSARC/2005/334, have some requirements that are currently not being met by this or planned future work, or anything else you'd like to discuss relating to this topic, please join us in the OpenSolaris networking community in the networking-discuss forum.

Monday Apr 30, 2007

Installing operating systems

On the weekend, I completed an installation of 10 operating systems in under an hour, all by hand. All of them were Unix, all of them using media I had downloaded and burnt to CD.

The operating system of choice? FreeBSD. In less time than it takes me to do 1 install of OpenSolaris, I did 10 of another open source platform. Granted the other install didn't include java and GNOME and StarOffice \*but\* what it did include was the X-Windows utilities (xterm, etc), the base FreeBSD operating system AND the kernel source code.

Each installation used less than 2GB of disk, delivered me a working envionment for software development (compiler - gcc, editors - vi, debugger - gdb) that needed less than 64MB of RAM to run in a remote fashion where I could launch Xterms back at my main console.

That is what you call a low barrier to entry for someone who wants to install and play around with an operating system.

Tuesday Mar 06, 2007

What is OpenSolaris success?

Now that opensolaris has been progressing for almost 2 years, some people are starting to ask the question "is it a success?"

Which begs the question of how do you measure its success?

Is it by the number of developers who subscribe to be a part of OpenSolaris?

Is it by the number of projects?

Is it by the activity in the OpenSolaris discussion groups?

Or something else?

I'd argue that none of the above are good measures for judging its success.

When the question of how to measure its success came to my mind, I started to think about how long it would take for OpenSolaris communities to be able to contribute in a worthwhile manner and the rationale goes something like this:

  • for most college students, by the time they're past the first half of their first year, if they're the type of student who will become involved in the open source movement then they've already chosen an allegience.
  • college students seem to be (roughly speaking) the set of people with most time on their hands to dedicate to work on open source projects.
  • a college student is ordinarily going to require 2-3 years of learning before being ready to contribute to OpenSolaris in a meaningful manner.
  • given the 2-3 year lag and wipe out the first year of OpenSolaris (2005), this establishes a period of 3 years before we can expect to see meaningful input from college students.
  • to attract the dedicated geeks who start hacking in their teens, we've a longer wait, possible 4 or 5 years, for someone to emerge from either starting out playing with OpenSolaris and run with it and/or for OpenSolaris to gain a big enough name amongst those who work on open source things to be worthy of attention.

As an example of the problem here, although I've seen multiple people (and in different areas) invite outsiders to be a part of an OpenSolaris project to provide new functionality, I've yet to see anyone step up to the plate to do more than provide just bug fixes.

Is this a problem? Not directly. What's more important is that stake holders in the OpenSolaris project, inside Sun, need to understand that it may take a length period of time (my estimate is 3-8 years, with anything meaningful inside 5 years a bonus) before there is a start to any real return on the investment in it as an open source project.

The problem for Sun, entering the open source space with OpenSolaris today is that many of those who it would like to have contributing are already at work elsewhere on other projects. Sun is somewhere between 10 and 15 years "late" and that in being "late" it faces a much harder job of being successful. Kind of like how it would be that much more difficult to start up a new ISP or search engine or internet auction web site, today, and compete with the giants that exist already.

What about other contributors? The number of people who will "defect" from one open source project to another is small but not 0. In general the reasons for this are:

  • becoming disenchanted with where the project is going
  • personal conflict issues

Neither of these are common events.

Against all of this, in the background there is the "problem" that OpenSolaris is a product of Sun and that anyone who works on an OpenSolaris project is quite clearly going to be contributing work, "for free", to a company that will directly benefit. That this is the case is driven home by the agreement required to participate in OpenSolaris forums. The agreement spells out that you grant Sun any rights required to use any ideas you discuss in its forums. For Sun, this is a natural requirement and as an employee, I agree 100% that it needs to be present. That it isn't enforced through the mailing lists is something of a glaring loophole and could be a problem in the future. Is OpenSolaris and Sun the only people who do this? No. The NetBSD project also requires developers to assign copyright to The NetBSD Foundation for all code committed there and submitting code changes to some FSF projects (such as gcc, gdb) requires additional paperwork to assign copyright. Why is this an issue? Well, the lack of there being a single person having copyright over the Linux kernel means that no one person can decide to change it from being GPLv2 to GPLv3 or something else.

Although there are constant complaints about the licence choice (CDDL vs GPL), this is not likely to be a deciding factor for anyone. OpenSolaris needs to be "cool" in the minds of those who have time to burn, first. Won't changing the licence make it "cool"? I have my doubts about this. Being "cool" will mean making it easy to do different things with OpenSolaris (i.e. use it on something with 32MB of RAM and a 32MB CF card), being able to get your name inside a .c file for submitting a driver patch for a new card you have, etc.

So what does this discussion have to do with OpenSolaris succeeding? Because for OpenSolaris to succeed, it needs to become bigger than just what it is at Sun. And it can only do that by attracting more people to it than just from at Sun.

Recently on one of the forums I added the comment that OpenSolaris will be successful when it is in a position to exist without Sun. The reason for is are somewhat obvious: if Sun folds then OpenSolaris goes with it as all of the infrastructure (servers, people updating the source code tree, etc) comes from Sun. Without Sun, there is no way for OpenSolaris to continue evolving. On top of infrastructure, it is also a reference to the developer base. So long as the majority of projects committed (or putback) into the OpenSolaris code base come from within Sun, if Sun goes away then so does the majority of the activity behind OpenSolaris - there would be a high risk of OpenSolaris just withering and dieing at that point.

How does Sun address this?

Firstly it needs to assist in making the project function independently of the work that happens inside Sun. In other open source projects, there is no concept of the role "gatekeeper". At Sun this role needs to be focused on bringing code in from OpenSolaris, to build the product called "Solaris" rather than controlling what gets putback into OpenSolaris.

Secondly, management at Sun needs to step back, to the point where managers, directors, VPs, etc, should have no involvment with the project as an employee or agent of Sun. Successful open source projects are managed/run/driven by the folks who do the technical work, not their "managers/minders/directors".

Thirdly, Sun needs to create a non-profit organisation that "owns" OpenSolaris and donate money/equipment to that and invite other individuals/companies to do the same.

But most of all, patience is required. The success of OpenSolaris cannot be measured like normal projects.

So, at the end of all of that, if I weren't a Sun employee, would I register with the OpenSolaris community? No and primarily because of the intellectual rights issue. I would limit myself to being a subscriber to the mailing lists. There are other issues but they're less tangible and more to do with the "feeling" of the OpenSolaris community forums when compared to others, elsewhere.




« February 2017