Dear forum,
can anybody help me with this issue?
How do I create a new file in kernel mode?
I am trying to create a file in a system call I am building.
thanks in advance,
Rafael Sisto.
Em Sat, Jan 19, 2008 at 10:42:40AM -0300, Rafael Sisto escreveu:
> Dear forum,
> can anybody help me with this issue?
>
> How do I create a new file in kernel mode?
> I am trying to create a file in a system call I am building.
Look at how NFS does.
fs/nfsd/nfs3proc.c
nfsd3_proc_create
- Arnaldo
On Jan 19 2008 10:42, Rafael Sisto wrote:
>Dear forum,
>can anybody help me with this issue?
>
>How do I create a new file in kernel mode?
>I am trying to create a file in a system call I am building.
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
Even then, you are a bit too unspecific. A syscall could
very well call a filesystem's create function and create
a file that way, though it is a very different use-case.
Dear Jan,
I had already read that webpage, but I dont need to change the data on
that file. I just want to create a new file and then close it, so I
can use it later in another system call, to mmap it to a user space.
Is it clearer now?
Can you please give me some code snippet?
Thanks again in advance and greetings!
Rafael Sisto.
(Jan, Sorry for the last mail, I answered to your personal mail only)
On Jan 19, 2008 10:49 AM, Jan Engelhardt <[email protected]> wrote:
>
> On Jan 19 2008 10:42, Rafael Sisto wrote:
> >Dear forum,
> >can anybody help me with this issue?
> >
> >How do I create a new file in kernel mode?
> >I am trying to create a file in a system call I am building.
>
> http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
>
> Even then, you are a bit too unspecific. A syscall could
> very well call a filesystem's create function and create
> a file that way, though it is a very different use-case.
>
Dear Arnaldo, I didnt see your mail before.
I read some of the code you suggested, but it seems so complicated! I
just need to create a file named "file" on the path /tmp/.. Isn't
there an easier way?
Or else, where can I find some more information about what the parameters mean?
(struct svc_rqst *rqstp, struct nfsd3_createargs *argp, struct
nfsd3_diropres *resp)
It seems that with the "argp" parameter, I could pass all my
information, but I dont see what to put on the other parameters...
I would greatfuly thank some link where to find some information, please.
greetings,
Rafael Sisto.
On Jan 19, 2008 10:48 AM, Arnaldo Carvalho de Melo <[email protected]> wrote:
> Em Sat, Jan 19, 2008 at 10:42:40AM -0300, Rafael Sisto escreveu:
> > Dear forum,
> > can anybody help me with this issue?
> >
> > How do I create a new file in kernel mode?
> > I am trying to create a file in a system call I am building.
>
> Look at how NFS does.
>
> fs/nfsd/nfs3proc.c
> nfsd3_proc_create
>
> - Arnaldo
>
On Jan 19 2008 11:08, Rafael Sisto wrote:
>
>I had already read that webpage, but I dont need to change the data on
>that file. I just want to create a new file and then close it, so I
>can use it later in another system call, to mmap it to a user space.
>Is it clearer now?
>Can you please give me some code snippet?
I don't get what your indirection is supposed to do.
userspace -> sys_open -> kernel space -> create file
-> sys_close -> kernel space -> close it
vs
userspace -> sys_mycall -> kernelspace -> sys_open -> create_file
-> sys_close -> create_file
As for code snippets:
asmlinkage logn sys_mycall(const char __user *filename,
unsigned int flags, unsigned int mode)
{
long ret;
ret = sys_open(filename, flags, mode);
if (ret < 0)
return ret;
return sys_close(fd);
}
You see, this is currently just too trivial to make sense, but if
it helps you, no problem.
>Sorry for the last mail, I answered to your personal mail only)
Here, we use Reply-to-all.
On Sat, 2008-01-19 11:21:11 -0300, Rafael Sisto <[email protected]> wrote:
> Dear Arnaldo, I didnt see your mail before.
> I read some of the code you suggested, but it seems so complicated! I
> just need to create a file named "file" on the path /tmp/.. Isn't
> there an easier way?
In my opinion, you're heading totally into the wrong direction. Nobody
will help you solving your problem with a given fixed method (file
accessing in kernel mode) unless you describe your problem in detail.
There's probably a much better and cleaner way. But unless you
describe your application and the overall goal in detail, please don't
expect too much help.
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: Wenn ich wach bin, träume ich.
the second :
Dear Jan,
I wrote a mail 10 hours ago with the subject "create a file in kernel
mode. help please!" explaining what I want to do but nobody answered,
so I decided to write a short mail with a specific question.
I don't doubt there's a much cleaner and better way to do it, because
I am a beginner in kernel programming...
The thing is, it is for a college project. 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.
The problem is that we are not successfuly creating the file, and when
some user calls the system call "attach" and then uses the memory, he
gets a "Bus Error" message. (We tried creating the file not with a
system call, but with "vi", then calling our system call "attach" to
the file created, and it worked fine)
So, my question is how to successfully create a file in kernel mode,
for later use... (I read the implementation of IPC, and it seems they
create a file in tmpfs, on the "get" system call, so my idea was to do
something similar)
I hope it is much clearer now, and would gratefuly accept any answer,
with new ideas, or an approach to make me realise what I am doing
wrong..
Thanks in advance,
Greetings, Rafael Sisto.
On Jan 19, 2008 11:30 AM, Jan-Benedict Glaw <[email protected]> wrote:
> On Sat, 2008-01-19 11:21:11 -0300, Rafael Sisto <[email protected]> wrote:
> > Dear Arnaldo, I didnt see your mail before.
> > I read some of the code you suggested, but it seems so complicated! I
> > just need to create a file named "file" on the path /tmp/.. Isn't
> > there an easier way?
>
> In my opinion, you're heading totally into the wrong direction. Nobody
> will help you solving your problem with a given fixed method (file
> accessing in kernel mode) unless you describe your problem in detail.
>
> There's probably a much better and cleaner way. But unless you
> describe your application and the overall goal in detail, please don't
> expect too much help.
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw [email protected] +49-172-7608481
> Signature of: Wenn ich wach bin, tr?ume ich.
> the second :
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHkgmbHb1edYOZ4bsRAmvTAJ0RXMAnOfFUApNNaPO7Gl+pdkrUvwCcDsJd
> +hpuhG9WunLb5rIAlwvWP6Q=
> =Orr2
> -----END PGP SIGNATURE-----
>
>
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.
Is my idea clearer now?
As for the snippet, thank you. But I read somewhere that it is not
recommended to call system calls inside another system call, right?
So, I think somthing like this code would do, right?
asmlinkage long sys_my_shmget(int size)
{
long ret;
ret = sys_open("/tmp/shmfile", O_CREAT | O_RDWR , 777);
if (ret < 0)
return ret;
sys_close(fd);
return 0;
}
what do you think??
Greetings, Rafael Sisto
On Jan 19, 2008 11:30 AM, Jan Engelhardt <[email protected]> wrote:
>
> On Jan 19 2008 11:08, Rafael Sisto wrote:
> >
> >I had already read that webpage, but I dont need to change the data on
> >that file. I just want to create a new file and then close it, so I
> >can use it later in another system call, to mmap it to a user space.
> >Is it clearer now?
> >Can you please give me some code snippet?
>
> I don't get what your indirection is supposed to do.
>
> userspace -> sys_open -> kernel space -> create file
> -> sys_close -> kernel space -> close it
>
> vs
>
> userspace -> sys_mycall -> kernelspace -> sys_open -> create_file
> -> sys_close -> create_file
>
> As for code snippets:
>
> asmlinkage logn sys_mycall(const char __user *filename,
> unsigned int flags, unsigned int mode)
> {
> long ret;
>
> ret = sys_open(filename, flags, mode);
> if (ret < 0)
> return ret;
>
> return sys_close(fd);
> }
>
> You see, this is currently just too trivial to make sense, but if
> it helps you, no problem.
>
> >Sorry for the last mail, I answered to your personal mail only)
>
> Here, we use Reply-to-all.
>
>
Rafael Sisto wrote:
> The thing is, it is for a college project. we have to build something
> like IPC, but simpler.
Did you already discuss your problems regarding design and
implementation with your teachers before turning to LKML for advice on
your homework?
--
Stefan Richter
-=====-==--- ---= =--==
http://arcgraph.de/sr/
> 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. I read some bibliography, searched a lot
in internet, but this problem is becoming a headache. That's why i'm
trying to get some help in the LKML.
I read the book Linux Kernel Development Second Edition, By Robert
Love, and he higly recommends to suscribe to this Mailing List, when
it is about kernel development issues. And I think this is a kernel
development issue.
If you know a better mailing list, or forum that could help me with
these issues, I would be thankfuly. I'm sorry if this is not the right
ML to ask these questions concerning "linux kernel development"...
Greetings, Rafael Sisto.
Em Sat, Jan 19, 2008 at 01:15:52PM -0300, Rafael Sisto escreveu:
> > 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. I read some bibliography, searched a lot
> in internet, but this problem is becoming a headache. That's why i'm
> trying to get some help in the LKML.
>
> I read the book Linux Kernel Development Second Edition, By Robert
> Love, and he higly recommends to suscribe to this Mailing List, when
> it is about kernel development issues. And I think this is a kernel
> development issue.
>
> If you know a better mailing list, or forum that could help me with
> these issues, I would be thankfuly. I'm sorry if this is not the right
> ML to ask these questions concerning "linux kernel development"...
http://kernelnewbies.org
http://kernelnewbies.org/MailingList
- Arnaldo
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/
On Sat, 2008-01-19 12:12:10 -0300, Rafael Sisto <[email protected]> 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 [email protected] +49-172-7608481
Signature of: http://perl.plover.com/Questions.html
the second :
I would like to Thank everybody for the quick answers!!
I also want to apologise all the unnecessary noise done in the mailing
list, maybe it wasn't the right place to post (I must say it was worth
the posting). I got some nice ideas and advices...
Lastly, I would like to answer some questions, and discuss some points told.
Stefan, what you said:
"Why back the shared memory with a file? Wouldn't a memory buffer suffice?"...
That was discarded at the beginning, because we didn't want to spend
kernel memory, so the user would have the freedom of asking as much
memory as he'd want. The fact is that we would be using IO on the
kernel, and it has been told, that it shouldn't be done...
Jan, our idea obviously wasn't that the user program used the syscalls
directly, instead he would use a library to ask for memory, attach,
etc (It wouldn't loose that much portability). Thanks for the book
suggestion.. I will try to read it!
Greetings, Rafael Sisto.
On Jan 19, 2008 10:29 PM, Jan-Benedict Glaw <[email protected]> wrote:
> On Sat, 2008-01-19 12:12:10 -0300, Rafael Sisto <[email protected]> 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 [email protected] +49-172-7608481
> Signature of: http://perl.plover.com/Questions.html
> the second :
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHkqP9Hb1edYOZ4bsRAtUzAKCKvKPIgc58hDSL4V1XXny2x6VBgACeNxGF
> nbkSbVGVuP1G6kOM91xrvn4=
> =XzNR
> -----END PGP SIGNATURE-----
>
>