-----Original Message-----
From: kernelnewbies-bounce@xxxxxxxxxxxx [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Bhanu Kalyan Chetlapalli
Sent: Wednesday, March 22, 2006 8:30 AM
To: George Joseph
Cc: kernelnewbies@xxxxxxxxxxxx
Subject: Re: Accessing a File System/ Files from kernel space
On 3/22/06, George Joseph <george_linuxprogrammer@xxxxxxxxx> wrote:
Hello Robert and All,Well the real purpose of the driver / set of drivers is to read packet data from a file and process this data in kernel space. For example, I have a device - XYZ which reads the data from the file on HDD and then processes this data to see if its valid . Once this is done we feed this data to another driver ABC which further works on it and filters it.I have a couple of doubts in this context:1) How to read the file from kernel space - yes, the fact as to whether the file name etc can be changed are yet to be resolved and hence I am still considering opening the file from userspace and then feeding the driver data wtih copy_to_user.You can read files from the kernel, using filp_open() and calling methods from the file structure (as shown in the sample code recently posted), but this is not recommended. It is best to read the file in user space and push it up to the kernel using netlink sockets, relayfs, or a virtual file system.2) Feeding(rather the method of feeding) other drivers in the kernel with the processed data - I am still contemplating doing this in user space or kernel space .I could rather do an Interconnect at User Land and hence do a copy_from_user in which case . But then in this case I would rather do a stack at user land than implement them as drivers. Please do suggest me any other method I could use to transfer data between drivers.Hmmm. It sounds like what you are describing is a process that really needs to be performed in user space. The video/audio drivers in the kernel are not really intended to be driven from the kernel. They are intended to be driven from user space. Maybe I'm missing something.BTW the project once complete will allow me to read a MPEG File and drive the video/audio drivers in the kernel - which would effectively make it work like a DVD Player.If you are trying to process this stuff in the kernel, then Have you considered the floating point operations that will be done (generally associated with audio/video formats)? Coz doing Floating point ops in the kernel is an absolute no-no.
The project is not targetted at doing something new but to gain some expertise in Linux Kernel programming.If you're trying to gain some valuable experience in Kernel programming, it might be good to start with something more conventional.Thanks,G.Bhanu.
"Bennett, Robert P" <Robert.Bennett@xxxxxx> wrote:
> -----Original Message-----
> From: kernelnewbies-bounce@xxxxxxxxxxxx
> [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Fawad Lateef
> Sent: Tuesday, March 21, 2006 1:28 PM
> To: Gaurav Dhiman
> Cc: George Joseph; Avishay Traeger; kernelnewbies@xxxxxxxxxxxx
> Subject: Re: Accessing a File System/ Files from kernel space
>
>> On 3/21/06, Gaurav Dhiman wrote:
> > On 3/21/06, Fawad Lateef wrote:
> > >
> > > What you can do is:
> > >
> > > 1) From user application read the file and provide the data to
> > > driver through sysfs, this is secure (I think its fast too)
> > > 2) Directly call the file system functions to access the file (I
> > > think its difficult)
> > > 3) Directly call the user space file accessing functions through
> > > doing system-calls from kernel (its the worst thing to do)
> >
> > Can you explain, why the 3rd point is not recommended.
> whats the harm
> > in doing that, why we say it to be a worst thing to do. I
> only reason
> > I can find for that is, just because we are using the user
> > applications unused fd for opening our file without letting
> the user
> > application know about it. Whenever we opena file in kernel, using
> > sys_open() systemcall, we would be using the unused fd of an
> > application in context of which the driver is executing, and the
> > application wont come to know about it. Is there any harm
> in doing so,
> > if yes, please explain.
> >
>
> Hello Gaurav,
>
> I don't think that sys_open can be called from kernel rather
> accessing a file in kernel can be done through
> filp_open/close, struct file *file->f_op->read/write etc and
> for doing this have to use get_ds/set_fs thing (making
> get_fs() == KERNEL_DS) which actually bypasses arguments
> validity (see
> http://sosdg.org/~coywolf/lxr/source/include/asm-i386/uaccess.h#L18 ).
> And I think this is creating a security risk as file is
> accessing without checking and wrong content in file can do
> things bad. This is my understanding which might be
> completely wrong :) So, CMIIW
I think we need to understand what George is trying to do before
we try to solve his problem. I am still not clear on what his goal is.
He has something in the kernel which is reading packet data written to a
file, but what exactly is he doing with this data once it is read? What
is he really trying to accomplish? Is this something that can not be
accomplished running entirely in user space? If not, why?
Bob
>
>
> --
> Fawad Lateef
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
--
The difference between Theory and Practice is more so in Practice than in Theory.
