From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Rafael Sisto <rafael.sisto@gmail.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: new file in kernel.
Date: Sun, 20 Jan 2008 02:29:34 +0100 [thread overview]
Message-ID: <20080120012934.GE9896@lug-owl.de> (raw)
In-Reply-To: <ee3dc96c0801190712v56bcfde5qa015888f2bcbde98@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
On Sat, 2008-01-19 12:12:10 -0300, Rafael Sisto <rafael.sisto@gmail.com> wrote:
> Dear Jan,
>
> The idea of the indirection is to make it transparent for the user.
> The idea is to do almost the same as what IPC does. The user calls
> "get", then "attach". In the "get" syscall I create a tmp file and
> return some id. Then the user calls an "attach" syscall with the
> returned id.
>
> The result is that he gets a shared memorymapped to his vma.
So my understanding is that you want to get a "IPC shared memory for
dummies" API. You're already willing to use custom-numbered system
calls, requiring to recompile the Linux kernel, having to add these
system calls to libc (or putting _syscallX macros into the
application's code) and loosing all portability for the application
using this API.
My point of view is that this is a planed nightmare :)
I'd suggest to dig into "Unix Network Programming, Volume 2.
Interprocess Communications" and implement that API as a library
instead of using a set of new kernel system calls. That way, the
applications using it will use that API and only that. They won't
require operatins system specific modifications afterwards. OTOH, this
library will probably quite portable by itself and shouldn't need
any kernel changes, independent of the underlying kernel.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: http://perl.plover.com/Questions.html
the second :
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-01-20 1:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-19 13:42 Rafael Sisto
2008-01-19 13:48 ` Arnaldo Carvalho de Melo
2008-01-19 14:21 ` Rafael Sisto
2008-01-19 14:30 ` Jan-Benedict Glaw
2008-01-19 14:57 ` Rafael Sisto
2008-01-19 15:26 ` Stefan Richter
2008-01-19 16:15 ` Rafael Sisto
2008-01-19 16:23 ` Arnaldo Carvalho de Melo
2008-01-19 17:57 ` Stefan Richter
2008-01-19 13:49 ` Jan Engelhardt
2008-01-19 14:08 ` Rafael Sisto
2008-01-19 14:30 ` Jan Engelhardt
2008-01-19 15:12 ` Rafael Sisto
2008-01-20 1:29 ` Jan-Benedict Glaw [this message]
2008-01-21 13:00 ` Rafael Sisto
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=20080120012934.GE9896@lug-owl.de \
--to=jbglaw@lug-owl.de \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.sisto@gmail.com \
/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
Powered by JetHome