From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Rafael Sisto <rafael.sisto@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: new file in kernel.
Date: Sat, 19 Jan 2008 18:57:13 +0100 [thread overview]
Message-ID: <479239F9.6020801@s5r6.in-berlin.de> (raw)
In-Reply-To: <ee3dc96c0801190815g1e658606ja982e2b9f1e82e70@mail.gmail.com>
Rafael Sisto wrote:
>> Did you already discuss your problems regarding design and
>> implementation with your teachers before turning to LKML for advice on
>> your homework?
>
> Yes, the thing is, that this is a research project, and we don't get
> much information from the teachers...
> We must research on our own.
Perhaps the teachers don't prepare you well enough but are not aware of
this issue. Also, if you go as far as asking people here to show you
example code (rather than for example posting your own draft code or
pseudo code and asking for comments), does this still count as
researching on your own?
[...]
> And I think this is a kernel development issue.
Yes, but AFAIU with the primary goal of you learning something, rather
than to advance the Linux program. So, kernelnewbies might be a better
list; but still, I am more irritated about /what/ you ask.
A few comments on your earlier posts:
>>>>> Or else, where can I find some more information about what the
>>>>> parameters mean?
To find out how things work in a complex C program like the kernel,
tools like LXR and cscope/ kscope can be quite helpful. In particular,
they help navigate between definitions and call sites.
http://lxr.free-electrons.com/
http://lxr.linux.no/linux
http://kscope.sourceforge.net/
>>> we have to build something
>>> like IPC, but simpler. we have a "get" system call (we thought we
>>> would just create a file in /tmp, not use it from the kernel, just
>>> create it) and then the users that want to access the shared memory
>>> will call the system call "attach". That will map the file into user
>>> space, as shared.
Why back the shared memory with a file? Wouldn't a memory buffer suffice?
--
Stefan Richter
-=====-==--- ---= =--==
http://arcgraph.de/sr/
next prev parent reply other threads:[~2008-01-19 17:57 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 [this message]
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
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=479239F9.6020801@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=acme@redhat.com \
--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
all inboxes | Powered by JetHome®