Subject: Re: Syscall number space
To: Darren Reed <darrenr@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 08/26/2007 23:29:28
On Sun, Aug 26, 2007 at 07:54:04PM -0700, Darren Reed wrote:
> 
> Why are we limited to 512 ?

Because that's the currently configured limit in syscalls.master.  In
any event, given that there are several regions in the syscall space
commented as being for vendors -- but we've fragmented most of them so
it's one free here, one free there, by using them for NetBSD system
calls in the past, or to give emulation calls for "close" emulations
the same syscall number in the hope that it will all just work -- it
seems sensible enough to reserve a contiguous region of decent size
for vendor use.

> Do we have any idea of how many system calls vendors need ?

My employer's tree currently extends FreeBSD with six system calls;
the largest contiguous region in syscalls.master in NetBSD is four,
and I have no particular confidence that if I used that one, it wouldn't
get stomped by some developer in the future who noticed the convenient
four-syscall hole and decided to be "economical".  I suspect others
extending NetBSD would find a significantly larger region convenient
(perhaps someone should ask Force 10, since they're sponsoring a major
NetBSD development effort at the moment).

> Has any vendor said they were using X number of system calls ?

Well, I can attest to six, which there isn't space for unless I put
them all scattershot across the file, which seems silly.

> What do we do when we run out of system calls available to us?
> (ie 0-512 is all "allocated")

I assume we increase the limit, which probably adds a very slight cost
to every system call on some architectures (actually, since 512 doesn't
fit in a byte, I'm not sure that's even true).  But that's not the real
issue; the issue is there's no decent-sized contiguous region vendors
can count on using in their private trees, because we've fragmented all
the ones allocated so far.  There's no reason to leave it that way.

> And lastly...
> Have any of the said vendors contributed back to NetBSD ?
> (Or in other words, why should we care about *them* ? >:-)

If you really really think that's the right attitude to take, you might
be happier in a GPL project -- though given our past history with some
vendors I can understand the response!  ;-)

From my point of view, one of the things keeping NetBSD alive and
interesting is that it's readily available to be packaged up and shipped
in vendor products without all the GPL nonsense.  Generally, I think,
NetBSD gets something back from those efforts (certainly we are getting
quite a bit back right now, in terms of Andy's paid kernel work).  We
could do better, but there's no point making things harder than they
need to be, and the current state of syscalls.master is a bit of a
pointless nuisance.  There was clearly supposed to be space in there for
private extensions, all the way back from the CSRG days; we've just slowly
broken it over time.

Thor