Re: 2.4 in-kernel file opening

[Martin Drab <drab@kepler.fjfi.cvut.cz>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/