Re: intercepting syscalls

[Igor Shmukler <igor.shmukler@gmail.com>]

Randy,

> And 'nobody' has submitted patches that handle all of the described
> problems...
> 
> 1.  racy
> 2.  architecture-independent
> 3.  stackable (implies/includes unstackable :)
> 
> You won't get very far in this discussion without some code...

I agree that if races disallow safe loading unloading it's a serious
problem. I'll get there pretty soon and I would be very to submit a
patch. It makes sense to hide interface if currently there is no safe
way to use it. I understand.

I don't think that drivers have to be architecture independent. Why is
this a problem?

Same regarding stackability. We have a module that works well with
other modules that intercept system calls just not on Linux. There are
caveats - not every module will just work with every other module. But
same problem is with networking protocols. It took time until IPsec
vendors worked out glitches.

Usually, it's not necessary to load/unload module to/from the middle
of the stack all the time.

I would even agree that it might be beneficial to develop guidelines
for developing stackable modules that intercept system calls, but I
think that reasons beyond races are of less importance.

For RH or SuSE it's very different. If they need something like this
done, a patch to the kernel and they are good to go. Simple folk still
has to make software that works with standard kernels and we have to
be given API that allows us to do this.

Igor