From: Arjan van de Ven <arjanv@redhat.com>
To: bidulock@openss7.org
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: export of sys_call_table
Date: 04 Oct 2002 13:31:27 +0200 [thread overview]
Message-ID: <1033731087.1853.11.camel@localhost.localdomain> (raw)
In-Reply-To: <20021004051932.A13743@openss7.org>
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]
On Fri, 2002-10-04 at 13:19, Brian F. G. Bidulock wrote:
> > Why ?
> > Adding "unknown" syscalls is I doubt EVER a good idea.
> > LiS has *known* and *official* syscalls, they can easily live with a
> > stub like nfsd uses.... few lines of code and it's safe.
>
> Well, nfsd does something like this:
>
> struct nfsd_linkage *nfsd_linkage = NULL;
>
> long
> asmlinkage sys_nfsservctl(int cmd, void *argp, void *resp)
> {
> int ret = -ENOSYS;
>
> lock_kernel();
>
> if (nfsd_linkage ||
> (request_module ("nfsd") == 0 && nfsd_linkage))
> ret = nfsd_linkage->do_nfsservctl(cmd, argp, resp);
>
> unlock_kernel();
> return ret;
> }
> EXPORT_SYMBOL(nfsd_linkage);
>
> I take it that this system call is not in nsfd's main data flow
> (probably write() and read are()). Taking the big kernel lock is
> excessive across every putpmsg() and getpmsg() operation and would
> seriously impact LiS performance on multiple processors. In effect,
> only one processor would run for LiS. A reader/write lock would be
> better.
The kernel has such locks too, no big deal
>
> Also, LiS does not require module loading on system call, but
> (questionably) needs unloading protection -- LiS does not really
> need to unload once loaded. This turns into something more like:
>
> static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
> static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
> static int (*do_spipe) (int *) = NULL;
> static int (*do_fattach) (int, const char *) = NULL;
> static int (*do_fdetach) (const char *) = NULL;
>
> static rwlock_t streams_call_lock = RW_LOCK_UNLOCKED;
>
> static long asmlinkage sys_putpmsg(int fd, void *ctlptr,
> void *dataptr, int band, int flags)
> {
> int ret = -ENOSYS;
> read_lock(&streams_call_lock);
> if (do_putpmsg)
> ret = do_putpmsg(fd, ctrptr, dataptr, band, flags);
> read_unlock(&streams_call_lock);
> return ret;
> }
not to bad...
>
> static long asmlinkage sys_spipe(int *fd)
> {
> int ret = -ENOSYS;
> read_lock(&streams_call_lock);
> if (do_spipe)
> ret = do_spipe(fd);
> read_unlock(&streams_call_lock);
> return ret;
> }
ehm sys_spipe doesn't exist, neither do all but 2 of the others you
showed.
>
> The module (LiS or iBCS) calls register_streams_calls after it loads and calls
> unregister_streams_calls before it unloads.
iBCS is dead. It's called linux-abi nowadays.....
> But this is repetative and doesn't solve replacement of existing
> system calls for profilers and such.
Profilers don't actually NEED this.... OProfile is fixed for this for
example in the 2.5 branch.
Taking over "random" unimplemented system calls really sounds bad..... I
mean, for the next minor release of the kernel Linus can assign that
number to something official and different......
Greetings,
Arjan van de Ven
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2002-10-04 11:22 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-03 21:39 export of sys_call_table Brian F. G. Bidulock
2002-10-03 22:02 ` Alan Cox
2002-10-03 23:06 ` Brian F. G. Bidulock
2002-10-04 9:10 ` Arjan van de Ven
2002-10-04 11:19 ` Brian F. G. Bidulock
2002-10-04 11:31 ` Arjan van de Ven [this message]
2002-10-04 11:55 ` Brian F. G. Bidulock
2002-10-04 13:00 ` Alan Cox
2002-10-03 23:10 ` Michal Jaegermann
2002-10-04 0:32 ` Andy Pfiffer
2002-10-04 9:20 ` Arjan van de Ven
2002-10-06 14:17 ` Kasper Dupont
2003-01-03 8:28 ` Eric W. Biederman
2002-10-04 21:06 ` David S. Miller
2002-10-04 21:44 ` Brian F. G. Bidulock
2002-10-12 5:43 ` Eric Blade
2002-10-03 22:14 ` Robert Love
2002-10-03 22:23 ` Robert Love
2002-10-03 22:24 ` Patrick Mochel
2002-10-03 22:15 ` Greg KH
2002-10-03 22:27 ` Dave Jones
2002-10-03 22:27 ` Robert Love
2002-10-03 22:58 ` John Levon
2002-10-03 23:10 ` Alexander Viro
2002-10-03 23:14 ` John Levon
2002-10-04 4:05 ` Muli Ben-Yehuda
2002-10-04 4:46 ` Greg KH
2002-10-04 4:53 ` Muli Ben-Yehuda
2002-10-03 23:35 ` Dave Jones
2002-10-03 23:50 ` John Levon
2002-10-04 0:17 ` Brian F. G. Bidulock
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com>
2002-10-04 4:03 ` Pete Zaitcev
2002-10-04 5:32 ` Brian F. G. Bidulock
2002-10-04 11:42 ` John Levon
2002-10-04 12:03 ` Brian F. G. Bidulock
2002-10-04 13:02 ` Alan Cox
2002-10-04 17:36 ` Pete Zaitcev
2002-10-05 1:39 ` John Levon
2002-10-04 13:58 ` Christoph Hellwig
2002-10-04 15:15 ` Brian F. G. Bidulock
2002-10-04 15:28 ` Christoph Hellwig
2002-10-04 16:19 ` Brian F. G. Bidulock
2002-10-04 16:25 ` Christoph Hellwig
[not found] <20021003153943.E22418@openss7.org.suse.lists.linux.kernel>
[not found] ` <1033682560.28850.32.camel@irongate.swansea.linux.org.uk.suse.lists.linux.kernel>
[not found] ` <20021003170608.A30759@openss7.org.suse.lists.linux.kernel>
[not found] ` <1033722612.1853.1.camel@localhost.localdomain.suse.lists.linux.kernel>
[not found] ` <20021004051932.A13743@openss7.org.suse.lists.linux.kernel>
2002-10-04 13:01 ` Andi Kleen
2002-10-04 13:11 ` Brian F. G. Bidulock
2002-10-04 13:15 ` Andi Kleen
2002-10-04 13:22 ` Brian F. G. Bidulock
2002-10-04 14:11 ` Andi Kleen
2002-10-04 14:31 ` Brian F. G. Bidulock
[not found] ` <20021003221525.GA2221@kroah.com.suse.lists.linux.kernel>
[not found] ` <20021003222716.GB14919@suse.de.suse.lists.linux.kernel>
[not found] ` <1033684027.1247.43.camel@phantasy.suse.lists.linux.kernel>
[not found] ` <20021003233504.GA20570@suse.de.suse.lists.linux.kernel>
[not found] ` <20021003235022.GA82187@compsoc.man.ac.uk.suse.lists.linux.kernel>
[not found] ` <mailman.1033691043.6446.linux-kernel2news@redhat.com.suse.lists.linux.kernel>
[not found] ` <200210040403.g9443Vu03329@devserv.devel.redhat.com.suse.lists.linux.kernel>
[not found] ` <20021003233221.C31444@openss7.org.suse.lists.linux.kernel>
[not found] ` <20021004133657.B17216@devserv.devel.redhat.com.suse.lists.linux.kernel>
2002-10-04 18:14 ` Andi Kleen
2002-10-04 18:46 ` Alan Cox
2002-10-04 18:45 ` Alexander Viro
2002-10-04 19:15 ` Brian F. G. Bidulock
2002-10-04 19:26 ` Andi Kleen
2002-10-04 19:37 ` Pete Zaitcev
2002-10-04 19:43 ` Robert Love
2002-10-04 22:21 ` David S. Miller
2002-10-04 22:41 ` Brian F. G. Bidulock
2002-10-04 22:38 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2002-10-04 21:54 Mark Veltzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1033731087.1853.11.camel@localhost.localdomain \
--to=arjanv@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bidulock@openss7.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox