Re: export of sys_call_table

[Pete Zaitcev]

> Date: Thu, 3 Oct 2002 23:32:21 -0600
> From: "Brian F. G. Bidulock" <[e-mail]>

> > GPLed code has no problem linking with sys_call_table.

> The code in question (LiS) is LGPL and open source.  The iBCS
> packge is GPL and open source.

I looked at the code scene a little here, and I do not think
there's anything that needs the syscall table.

The oprofile author seems to have things fixed already,
though the change did not filter down yet. He's also thin
skinned and was fuming a little, but I expect technical merit
to take the upper hand in his clueful head. I remember being
seriously rattled by DaveM in similar circumstances, and coming
out just fine.

LiS is crap and has to die, so it's not a problem. We actually
had a *very* big customer who used it, got a relatively decent
performance too (as much as could be expected from, ahem, the
framework :-), but it kept crashing all the time. Took a little
work to move them off LiS, but it was worth it.

iBCS is interesting for vendors, which I think, are cool with
shipping a patch. That's something SCO will happily sell to you
if you want to run old binaries casually. A standalone person who
risks running complicated UNIX binaries and debugs when they fail
can do the patch too, there's no chilling effect.

This leaves syscalltrack, which is pretty interesting in general,
but I think Mulix suffers from CVS mentality a little here.
He should aim at getting the hooking mechanism into the kernel.
I do not think his attempts to act remora and make it transparent
are safe. Anyway, it's a code which needs to mature and sort it
out with other hooking mechanisms, we already have dozens of them.
Let the Darwinean process to work here a little, then we'll see.

> And what about AFS?  I see that it uses a sys_ni_syscall slot as
> well...

Dhowell's kafs will take care of it. It should not need to overwrite
syscalls anyway.

-- Pete