Hi,
can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
in 2.4 kernels while the sys_close() is there? And what is then the
preferred way of opening files from within a 2.4 kernel module?
Thank you,
Martin
On Tue, 4 Oct 2005, Martin Drab wrote:
> Hi,
>
> can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> in 2.4 kernels while the sys_close() is there? And what is then the
> preferred way of opening files from within a 2.4 kernel module?
Is it just pure filp_open()/filp_close() ?
Martin
On Tue, 4 Oct 2005, Martin Drab wrote:
> Hi,
>
> can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> in 2.4 kernels while the sys_close() is there? And what is then the
> preferred way of opening files from within a 2.4 kernel module?
>
> Thank you,
> Martin
There is no way to open files within the kernel. Any attempt is
just a hack. The kernel is designed to perform tasks on behalf
of the caller. It doesn't have a context. It uses the caller's
context. A file-descriptor is a number that relates to the
current context. i.e., STDIN_FILENO is __different__ for you
and somebody else, even though it has the same numerical value.
To open a file in the kernel requires either a task with a
context (like a kernel thread) or you have to steal the context
of somebody which can destroy some innocent task's context.
You are never supposed to use files inside the kernel; period!
If you need to obtain file-data for a driver or receive file-
data from a driver, we have read(), write(), mmap(), and ioctl()
to accomplish these things from user-mode. A user-mode program can
write data directly to your driver using mmap(), for instance.
Or it can use a function-code you define to upload/download data
using ioctl().
This is a FAQ. Many persons have rejected this advice, only
to later on modify their drivers to correspond to the correct
way of writing Unix/Linux device drivers. This, after they've
trashed many innocent tasks.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 4 Oct 2005, Martin Drab wrote:
> On Tue, 4 Oct 2005, Martin Drab wrote:
>
> > Hi,
> >
> > can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> > in 2.4 kernels while the sys_close() is there? And what is then the
> > preferred way of opening files from within a 2.4 kernel module?
>
> Is it just pure filp_open()/filp_close() ?
Now I see sys_open() is doing a strncpy_from_user() conversion, so that's
why it's not good for in-kernel use. So I assume the
filp_open()/filp_close() is OK then.
Martin
Martin Drab wrote:
> Hi,
>
> can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> in 2.4 kernels while the sys_close() is there? And what is then the
> preferred way of opening files from within a 2.4 kernel module?
Why do you need to open files from kernel space? There are usually
better alternatives like the firmware loader interface.
--
Brian Gerst
On Tue, 4 Oct 2005, Martin Drab wrote:
> On Tue, 4 Oct 2005, Martin Drab wrote:
>
> > On Tue, 4 Oct 2005, Martin Drab wrote:
> >
> > > Hi,
> > >
> > > can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> > > in 2.4 kernels while the sys_close() is there? And what is then the
> > > preferred way of opening files from within a 2.4 kernel module?
> >
> > Is it just pure filp_open()/filp_close() ?
>
> Now I see sys_open() is doing a strncpy_from_user() conversion, so that's
> why it's not good for in-kernel use. So I assume the
> filp_open()/filp_close() is OK then.
Still, there is no "preferred" way of opening files from
within the kernel. Do it in userspace.
--
~Randy
On Tue, 4 Oct 2005, linux-os (Dick Johnson) wrote:
>
> On Tue, 4 Oct 2005, Martin Drab wrote:
>
> > Hi,
> >
> > can anybody tell me why there is no sys_open() exported in kernel/ksyms.c
> > in 2.4 kernels while the sys_close() is there? And what is then the
> > preferred way of opening files from within a 2.4 kernel module?
> >
> > Thank you,
> > Martin
>
> There is no way to open files within the kernel. Any attempt is
> just a hack. The kernel is designed to perform tasks on behalf
> of the caller. It doesn't have a context. It uses the caller's
> context. A file-descriptor is a number that relates to the
> current context. i.e., STDIN_FILENO is __different__ for you
> and somebody else, even though it has the same numerical value.
I know.
> To open a file in the kernel requires either a task with a
> context (like a kernel thread) or you have to steal the context
> of somebody which can destroy some innocent task's context.
No this should have been a well controlled situation within an ioctl call.
But I guess i should probably transfer this into the user-space, even
though it means more data transfers to user-space from kernel space. OK, I
got it.
> You are never supposed to use files inside the kernel; period!
Yes, yes, I got it. :-)
> If you need to obtain file-data for a driver or receive file-
> data from a driver, we have read(), write(), mmap(), and ioctl()
mmap() is actually what i wanted to do automatically without the need to
transfer all the necessary data from the kernel to the user app, and then
let the app do it all on its own. But I see now there is probably no other
way but to let the app do it all. Especially given that I need to do some
things within the driver before the mmap() - I guess that should be
possibble to do from within the fops->mmap(), but I also need to do
something upon munmap()ping. Where should I place that? There doesn't seem
to be any function that would be called upon user munmap(). :(
> to accomplish these things from user-mode. A user-mode program can
> write data directly to your driver using mmap(), for instance.
> Or it can use a function-code you define to upload/download data
> using ioctl().
>
> This is a FAQ. Many persons have rejected this advice, only
> to later on modify their drivers to correspond to the correct
> way of writing Unix/Linux device drivers. This, after they've
> trashed many innocent tasks.
OK, sorry for bothering. I'll try rewritin it somehow.
Martin
On Tue, 4 Oct 2005, Martin Drab wrote:
...
> things within the driver before the mmap() - I guess that should be
> possibble to do from within the fops->mmap(), but I also need to do
> something upon munmap()ping. Where should I place that? There doesn't seem
> to be any function that would be called upon user munmap(). :(
Should this be placed at vmops->close()?
Martin
On Tue, 4 Oct 2005, Martin Drab wrote:
> On Tue, 4 Oct 2005, Martin Drab wrote:
> ...
> > things within the driver before the mmap() - I guess that should be
> > possibble to do from within the fops->mmap(), but I also need to do
> > something upon munmap()ping. Where should I place that? There doesn't seem
> > to be any function that would be called upon user munmap(). :(
>
> Should this be placed at vmops->close()?
Or does there have to be a separate ioctl call for that after the munmap()
anyway?
Martin
On Tue, 4 Oct 2005, Martin Drab wrote:
> On Tue, 4 Oct 2005, Martin Drab wrote:
>
>> On Tue, 4 Oct 2005, Martin Drab wrote:
>> ...
>>> things within the driver before the mmap() - I guess that should be
>>> possibble to do from within the fops->mmap(), but I also need to do
>>> something upon munmap()ping. Where should I place that? There doesn't seem
>>> to be any function that would be called upon user munmap(). :(
>>
>> Should this be placed at vmops->close()?
>
> Or does there have to be a separate ioctl call for that after the munmap()
> anyway?
>
> Martin
Just grin and bear it. Do the right things at the right time. If you
need ioctl() just do it. It will save you loads of development and
debugging time. Further, somebody else will be able to maintain the
code when you get promoted.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Tue, 4 Oct 2005, Brian Gerst wrote:
> Martin Drab wrote:
> > Hi,
> >
> > can anybody tell me why there is no sys_open() exported in kernel/ksyms.c in
> > 2.4 kernels while the sys_close() is there? And what is then the preferred
> > way of opening files from within a 2.4 kernel module?
>
> Why do you need to open files from kernel space? There are usually better
> alternatives like the firmware loader interface.
I was kind of working this out here a while ago. I am collecting data from
RTLinux driver (in Real-Time). I am filing DMA buffers and I need to
transfer their contents (preferably by mmap()ping) to the user space.
My first problem (that I was solving a while ago) was that I was unable to
mmap() the buffer using mmap() through the /dev/mem. I solved that by
creating my own device with its own fops->mmap() using vmops->nopage().
Problem is that this is not RT safe. So I wanted to do it all from
within the ioctl call to the RT-FIFOs, which are RT safe, since the
RT-FIFOs do not provide for the safe mmap() operation redefinition. I'm
not very sure it can be done in a safe way by calling the mmap() on that
new device from the user space.
Perhaps the only way then may be to do (from the user space):
0) read() from RT-FIFO the info about next available DMA buffer.
1) ioctl() to RT-FIFO to block the buffer and dispose it for the
user-space mmap() via the unsafe interface.
2) mmap() it from user space.
3) use the data from the mmap()ped buffer
4) munmap() the buffer.
5) ioctl() to the RT-FIFO to release the buffer for further reuse
Is that so?
Before I was kind of hoping I could do 2) from within 1) and 4) from
within 5), but evidently this was not a good idea.
Martin
On Tue, 4 Oct 2005, linux-os (Dick Johnson) wrote:
>
> On Tue, 4 Oct 2005, Martin Drab wrote:
>
> > On Tue, 4 Oct 2005, Martin Drab wrote:
> >
> >> On Tue, 4 Oct 2005, Martin Drab wrote:
> >> ...
> >>> things within the driver before the mmap() - I guess that should be
> >>> possibble to do from within the fops->mmap(), but I also need to do
> >>> something upon munmap()ping. Where should I place that? There doesn't seem
> >>> to be any function that would be called upon user munmap(). :(
> >>
> >> Should this be placed at vmops->close()?
> >
> > Or does there have to be a separate ioctl call for that after the munmap()
> > anyway?
> >
> > Martin
>
> Just grin and bear it. Do the right things at the right time. If you
> need ioctl() just do it. It will save you loads of development and
> debugging time. Further, somebody else will be able to maintain the
> code when you get promoted.
Right, OK.
Thanks,
Martin
On Tue, 04 Oct 2005 13:41:49 EDT, "linux-os (Dick Johnson)" said:
> You are never supposed to use files inside the kernel; period!
Usually true. However, feel free to look at kernel/acct.c and suggest
a way of implementing it in a backward-compatible way that doesn't use
filp_open() and filp_close(). Keep in mind you can't use the 'connector'
framework the way auditd and friends do, because the sys_acct() call has
semantics of writing directly to a file without a listening daemon....