Re: Is there any interest in Dynamic API

Re: Is there any interest in Dynamic API

[Richard J Moore]

>> I was wondering whether the kernel community had any interest in seeing
a
>> dynamic api capability in the kernel. What I have in mind the ability
for a
>
>We have one. Its called devices and file systems 8)
>-


Thanks Alan, that's clear - syscalls for kernel only.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK

Re: Is there any interest in Dynamic API

[Alexander Viro]

On Thu, 23 Aug 2001, Richard J Moore wrote:

> 
> 
> On Thu, 23 Aug 2001, Alexander Viro <viro@math.psu.edu>:
> 
> > s/ioctl/read() and write()/, please.
> 
> Why not ioctl?

Because use of read() and write() forces at least some thinking about
making the API you add reasonably clean - ioctl() is "anything goes"
junkpile by design.

Re: Is there any interest in Dynamic API

[Mike Castle]

On Thu, Aug 23, 2001 at 02:58:44PM +0100, Richard J Moore wrote:
> 
> 
> On Thu, 23 Aug 2001, Alexander Viro <viro@math.psu.edu>:
> 
> > s/ioctl/read() and write()/, please.
> 
> Why not ioctl?


You can script things with read/write.  You have to write one off utilities
for ioctl.

Think having to require specialized tools like stty, hdparm, setserial, and
so on.  (Historical question:  Since IP sockets were originally /dev/* based,
was ifconfig essentially a wrapper around ioctls?)

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: Is there any interest in Dynamic API

[Keith Owens]

On Thu, 23 Aug 2001 14:58:44 +0100, 
"Richard J Moore" <richardj_moore@uk.ibm.com> wrote:
>
>
>On Thu, 23 Aug 2001, Alexander Viro <viro@math.psu.edu>:
>
>> s/ioctl/read() and write()/, please.
>
>Why not ioctl?

Oh no, not the ioctl bad, read/write good flamewar again.  Please leave
me off this one.

Re: Is there any interest in Dynamic API

[Richard J Moore]

On Thu, 23 Aug 2001, Alexander Viro <viro@math.psu.edu>:

> s/ioctl/read() and write()/, please.

Why not ioctl?

Re: Is there any interest in Dynamic API

[Alexander Viro]

On Thu, 23 Aug 2001, Richard J Moore wrote:

> 
> 
> 
> On Thu, 23 Aug 2001 10:21:25 +0100,
> "Keith Owens" <kaos@ocs.com.au> wrote:
> >>Thanks, these are good areguments for not pursuing this. We'll proceed
> with
> >>conversion of dprobes to a device driver rather than a kernel module.
> >
> >I presume you meant a device driver rather than a syscall interface.
> >Obviously a driver can be a module.
> 
> Yes, kernel_mod+syscall to ddev+ioclt instead of kmod+syscall

s/ioctl/read() and write()/, please.

Re: Is there any interest in Dynamic API

[Richard J Moore]

On Thu, 23 Aug 2001 10:21:25 +0100,
"Keith Owens" <kaos@ocs.com.au> wrote:
>>Thanks, these are good areguments for not pursuing this. We'll proceed
with
>>conversion of dprobes to a device driver rather than a kernel module.
>
>I presume you meant a device driver rather than a syscall interface.
>Obviously a driver can be a module.

Yes, kernel_mod+syscall to ddev+ioclt instead of kmod+syscall

Re: Is there any interest in Dynamic API

[Keith Owens]

On Thu, 23 Aug 2001 10:21:25 +0100, 
"Richard J Moore" <richardj_moore@uk.ibm.com> wrote:
>Thanks, these are good areguments for not pursuing this. We'll proceed with
>conversion of dprobes to a device driver rather than a kernel module.

I presume you meant a device driver rather than a syscall interface.
Obviously a driver can be a module.

Re: Is there any interest in Dynamic API

[Richard J Moore]

"Kieth Owens" <kaos@ocs.com.au> wrote:
>"Richard J Moore" <richardj_moore@uk.ibm.com> wrote:
>>I was wondering whether the kernel community had any interest in seeing a
>>dynamic api capability in the kernel. What I have in mind the ability for
a
>>kernel module to request a system call entry be added by supplying a call
>>name to a create_dynamic_api service.
>
>Why does this remind me of SVCUPDTE?

Damn! I've been rumbled.

>
>You will have problems on architectures where indirect function calls
>require extra handling.  IA64 has to load a global data pointer (gp) as
>well as the function address for an indirect call.  The existing
>syscall table avoids this overhead because all system calls are in the
>kernel with a constant gp.  To allow syscalls to modules you either
>load a gp for each entry point (which slows down all syscalls) or you
>need arch specific trampoline code to enter and exit a syscall in a
>module.  PPC64 looks like it has the same problem.
>
>There is also the problem of generating syscalls in userspace pic code.
>Each arch is different, look at all the hassles glibc goes through to
>create syscall interfaces.  It is not surprising that _syscall[0-5] are
>deprecated interfaces.  It is much easier to use a device or fs interface.

Thanks, these are good areguments for not pursuing this. We'll proceed with
conversion of dprobes to a device driver rather than a kernel module.


Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


Keith Owens <kaos@ocs.com.au> on 23/08/2001 03:44:22

Please respond to Keith Owens <kaos@ocs.com.au>

To:   Richard J Moore/UK/IBM@IBMGB
cc:   linux-kernel@vger.kernel.org
Subject:  Re: Is there any interest in Dynamic API


On Wed, 22 Aug 2001 18:44:27 +0100,
"Richard J Moore" <richardj_moore@uk.ibm.com> wrote:
>I was wondering whether the kernel community had any interest in seeing a
>dynamic api capability in the kernel. What I have in mind the ability for
a
>kernel module to request a system call entry be added by supplying a call
>name to a create_dynamic_api service.

Why does this remind me of SVCUPDTE?

You will have problems on architectures where indirect function calls
require extra handling.  IA64 has to load a global data pointer (gp) as
well as the function address for an indirect call.  The existing
syscall table avoids this overhead because all system calls are in the
kernel with a constant gp.  To allow syscalls to modules you either
load a gp for each entry point (which slows down all syscalls) or you
need arch specific trampoline code to enter and exit a syscall in a
module.  PPC64 looks like it has the same problem.

There is also the problem of generating syscalls in userspace pic code.
Each arch is different, look at all the hassles glibc goes through to
create syscall interfaces.  It is not surprising that _syscall[0-5] are
deprecated interfaces.  It is much easier to use a device or fs interface.

Re: Is there any interest in Dynamic API

[Keith Owens]

On Wed, 22 Aug 2001 18:44:27 +0100, 
"Richard J Moore" <richardj_moore@uk.ibm.com> wrote:
>I was wondering whether the kernel community had any interest in seeing a
>dynamic api capability in the kernel. What I have in mind the ability for a
>kernel module to request a system call entry be added by supplying a call
>name to a create_dynamic_api service.

Why does this remind me of SVCUPDTE?

You will have problems on architectures where indirect function calls
require extra handling.  IA64 has to load a global data pointer (gp) as
well as the function address for an indirect call.  The existing
syscall table avoids this overhead because all system calls are in the
kernel with a constant gp.  To allow syscalls to modules you either
load a gp for each entry point (which slows down all syscalls) or you
need arch specific trampoline code to enter and exit a syscall in a
module.  PPC64 looks like it has the same problem.

There is also the problem of generating syscalls in userspace pic code.
Each arch is different, look at all the hassles glibc goes through to
create syscall interfaces.  It is not surprising that _syscall[0-5] are
deprecated interfaces.  It is much easier to use a device or fs interface.

Re: Is there any interest in Dynamic API

[Alan Cox]

> I was wondering whether the kernel community had any interest in seeing a
> dynamic api capability in the kernel. What I have in mind the ability for a

We have one. Its called devices and file systems 8)

Is there any interest in Dynamic API

[Richard J Moore]

I was wondering whether the kernel community had any interest in seeing a
dynamic api capability in the kernel. What I have in mind the ability for a
kernel module to request a system call entry be added by supplying a call
name to a create_dynamic_api service. This service would assign a system
call number by looking for an unused slot (not from the beginning of the
syscall table but from a defined location so as to avoid reserved calls).
It would create a /proc/dynapi/api_name - the content of this file would
contain the call number.

It seems like a harmless enough idea. And I sort of like the idea of using
a system call rather than turning a kernel module into a device driver just
for the sake of a user communication mechanism.  I envisage this being of
use to projects where they need a user-kernel interface but not a generic
one.

Comments please.


Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK