Adding System Calls (an OpenBSD Example)

BSD Forums writes "Kernel programming sometimes feels like a dark art where application programmers should never venture, but sometimes it's the right way to solve a problem. (Oh, and it's also very interesting.) One of the easiest places to start is by adding a new system call to a kernel. Kevin Lo explains how and why, with the OpenBSD kernel in this OnLamp article."

Comments

other examples

[fred ugly]

A simple Google search brings up plenty of info on how to do this in Linux as well...

Re:other examples

[smittyoneeach]

A useful first post. An hour later, it's still lonely. Why?

Re:other examples

[fred ugly]

yeah, i know... and i didn't even think to mention that it was a FP. oh well, my karma shouldn't suffer terribly.

Re:other examples

[Anonymous Coward]

A useful first post. An hour later, it's still lonely. Why?
Because it is about BSD which is dead and that's why this discussion is dead.

Interesting, however....

[Anonymous Coward]

I think my last attempt at 'hello-world' may have introduced a local root hole. Kernel hacking is probably knowledge I shouldn't have ... I'm sure I'm not alone =)

Sometimes this is more trouble then it seems.

[John Sokol]

I have done this several times in the past and what happens is you then have an application trapped on a non-standard system. Any system that it runs that application will need your kernal patch with the new calls.

This gets even worse when the OS keeps upgrading and you are forced to migrate your changes up to be able to use current hardware. (this is need when all of the supported hardware is no longer available new)

In practice it turn into a major undertaking everytime a new OS release came out.

It's is a cool thing to have fun with. But think twice before you base a product or application on a kernel change. (unless you can get the main development tree to adopt it.) Or have the resources to maintain your own OS development team.

Adding new syscontrols and sockopts are also great fun.

At one point we had a versions of FreeBSD that could run DES encrypted Binaries, access the hard driver serial numbers and Mount a CD from HTTP or FTP connection, transmit Datagrams masquerading as TCP connections and be able to process Router Alert packets.

John

Re:Sometimes this is more trouble then it seems.

[SuperFrink]

An excellent point.

I wrote patches to the linux kernel and apache to allow all PHP and CGI requests to run as the owner of the file being requested. Actually the UID changes for each request, even static pages. So long as a stat() can be done it should work. This means the files don't have to be readable by the webserver.

The system stores the user ID on a stack and returns to the webserver user ID when the request has been served so no forking or set-uid files are needed. (Yes root needs to configure permissions at boot time or at least before switching users will work.)

I was explaining the system to someone at work (where we look after several webservers used by different people). When asked weather I intended to install this on the work servers. My reply was no, if it were my company I would definitely consider it but I did not want to saddle the next admin after me with the job of keeping a custom kernel patch in line with future releases.

That said I say if you think you might be interested in operating systems then doing some reading and eventually playing with kernel code can be a valuable experience. (I also wrote the first result from the above google search. The second link is the more current version.)

-Chad

PS: the DES binaries sound like a neat project. for that mater so does mounting over http.

What we can learn from BSD.

[Anonymous Coward]

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo deRaadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureacratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

Re:What we can learn from BSD.

[Anonymous Coward]

Great piece of work from a anonymous coward.
The more funny is about incompatibilities between *BSD. Each BSD user know the fact that his systeme is able to use binaries from other systems including other BSDs AND even linux. Where is the BSD support in linux ?

IMHO the linux advocacy will always be 90% of people who does not even understand what they speak about.

couldn't you make that stuff public now?

[Anonymous Coward]

-nt-

Syscalls

[wazlaf]

Awesome, we'll get even more syscalls! Linus is going to love this..

Re:Syscalls

[Homology]

Awesome, we'll get even more syscalls! Linus is going to love this..

The article is about syscalls in the OpenBSD kernel. I don't think that Linus is very interested in recieving patches for new syscalls in a BSD kernel.

*BSD is dying

[Anonymous Coward]

Fact: *BSD is dying

It is common knowledge that *BSD is dying, that ever hapless *BSD is mired in an irrecoverable and mortifying tangle of fatal trouble. It is perhaps anybody's guess as to which *BSD is the worst off of an admittedly suffering *BSD community. The numbers continue to decline for *BSD but FreeBSD may be hurting the most. Look at the numbers. The loss of user base for FreeBSD continues in a head spinning downward spiral.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major marketing surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.

Fact: *BSD is dying

Kernel patching for Hello World!

[Anonymous Coward]

Wow! And I thought I had it bad "when I were a lad".

OpenBSD

[Anonymous Coward]

Hello Theo,
I've got this great Hello World system call, can I make it into the next release?

Many thanks and kisses
Fred
xxxx

Eternal pet peeve

[Emil Brink]

Now, I know the code in the article is only sample code, and as such need not be perfect as long as it gets its point across. I'd say it does that just fine, it was an interesting read. But I can't help feel a bit saddened by code such as this snippet:

size_t len;
char buffer[1024]; /* must bounds check all user values */
if (SCARG(uap, len) > (size_t)1024)
return(EINVAL);

Here, the author needlessly repeats the "1024" constant, which introduces a fine opportunity to make an error by only changing the buffer definition and not the constant, later on. In my world, cases such as these is where you really want to use the sizeof operator, and simply write that check like so:

if (SCARG(uap, len) > sizeof buffer)
return EINVAL;

Also note that this gets rid of the cast, since the sizeof creates a value of type size_t. There are no parens involved, since neither sizeof nor return are function calls. This seems to be a matter of personal style, though. Of course, sizeof is properly used in the copying call, so I guess this is just a minor point anyway. I also suspect there's an off-by-one error lurking in there, but am not familiar enough with the OpenBSD copying semantics to be sure.

Re:Eternal pet peeve

[Viol8]

" There are no parens involved, since neither sizeof nor return are function calls. This seems to be a matter of personal style, though"

Its not just a case of personal taste , using sizeof with parenthesis will only work for types that only have a 1 token declaration

Eg: sizeof int

works fine , whereas

sizeof int * sizeof struct foo

will give an error with most compilers. So in this sense the sizeof operator is not treated
syntatically in an equivalent way to the return operator. Just another of C's little foibles.

Re:Eternal pet peeve

[Viol8]

Missed out a newline

sizeof int *
sizeof struct foo

should have been seperate.

Re:Eternal pet peeve

[Emil Brink]

I wasn't being complete since I wanted to, er, not sound too dorky. The sizeof operator takes a single argument, that's true. If the argument is to be a type name, such as int or your struct foo, then that type name needs to be a cast expression, which as we all know is simply the type name in parens. Using a type name without parens is, as far as I know, a syntax error.