Thor Lancelot Simon wrote:
> 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.
>   

So if I recompile the NetBSD kernel with nsysent=65536 in syscalls.conf, 
will it die?
If I was a smart vendor and I cared about what my system call numbers were,
I'd put them out of reach.  Maybe start at 2^16-1 and work down or 
2^15-1 and
work down or 2^32-1 and work down - you get the idea.

Because you never know, someone might want to add 100 system calls for 
whatever
it is they're doing and the small space you're suggesting we set aside 
just won't cut it.

> > 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.
>   

Right.  So my take on this is we should say any system call # with bit X set
is a private system call that belongs to a vendor (where X >= 10 and is
preferably 15 or more.)

Darren