I am currently developing a module which I would like to configure
via a simple text file.
I cannot seem to find any information on accessing files via a kernel module.
Is this possible and if so how is it done ?
Many Thanks
Simon.
On Thu, 14 Aug 2003, Simon Haynes wrote:
> I am currently developing a module which I would like to configure
> via a simple text file.
>
> I cannot seem to find any information on accessing files via a kernel module.
>
> Is this possible and if so how is it done ?
>
> Many Thanks
>
> Simon.
This has become a FAQ. You make your module accept parameters
from an ioctl(). Then you use a user-mode task to read file(s)
and configure your module.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, Aug 14, 2003 at 12:32:18PM +0100, Simon Haynes wrote:
> I am currently developing a module which I would like to configure
> via a simple text file.
>
> I cannot seem to find any information on accessing files via a kernel
> module.
>
> Is this possible and if so how is it done ?
Yes, but it is rather complicated business, and really should not
be done in kernel. It can be done, but like Richard said, defining
your own set of IOCTLs for the device is better. The complicated
configuration file parsing can then reside in the user-space utility
program.
> Many Thanks
> Simon.
/Matti Aarnio
On Thu, Aug 14, 2003 at 03:19:17PM +0300, Matti Aarnio wrote:
> On Thu, Aug 14, 2003 at 12:32:18PM +0100, Simon Haynes wrote:
> > I am currently developing a module which I would like to configure
> > via a simple text file.
> >
> > I cannot seem to find any information on accessing files via a kernel
> > module.
> >
> > Is this possible and if so how is it done ?
>
> Yes, but it is rather complicated business, and really should not
> be done in kernel. It can be done, but like Richard said, defining
> your own set of IOCTLs for the device is better. The complicated
> configuration file parsing can then reside in the user-space utility
> program.
Indeed, do it in user space. But don't use ioctl unless it fits the
problem better than the other solutions. Use read / write on a device
file, or a special purpose file system, or sysfs, or even /proc. The
exact mechanism you should use depends on the nature of the user space
- kernel space communications.
--
Muli Ben-Yehuda
http://www.mulix.org
I actually had a character interface which I use for on the fly
configuration. I have now implemented some code which uses a user process to
pass the configuration to the driver. I have however run into problems trying
to write files from the driver. I have tried implementing a user process
which performs a blocking read. The user process is blocked with
interruptible_sleep_on and is woken by the main part of the driver when it
needs to write. The problem is I then need to stall the main part of the
driver while the data gets written out. My problem is that this write needs
to happen from an interrupt handler or a timer process. I cannot seem to
block these with interruptible_sleep_on, the kernel crashes. I guess you
cannot use this in these cases ? I have also tried semaphores without much
success. I have looked for the howto but failed there also.
Could you please tell me where I could find this FAQ.
Many Thanks
Simon.
On Thursday 14 Aug 2003 1:07 pm, Richard B. Johnson wrote:
> On Thu, 14 Aug 2003, Simon Haynes wrote:
> > I am currently developing a module which I would like to configure
> > via a simple text file.
> >
> > I cannot seem to find any information on accessing files via a kernel
> > module.
> >
> > Is this possible and if so how is it done ?
> >
> > Many Thanks
> >
> > Simon.
>
> This has become a FAQ. You make your module accept parameters
> from an ioctl(). Then you use a user-mode task to read file(s)
> and configure your module.
>
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
> Note 96.31% of all statistics are fiction.
On Tue, 19 Aug 2003, Simon Haynes wrote:
> I actually had a character interface which I use for on the fly
> configuration. I have now implemented some code which uses a user process to
> pass the configuration to the driver. I have however run into problems trying
> to write files from the driver. I have tried implementing a user process
> which performs a blocking read. The user process is blocked with
> interruptible_sleep_on and is woken by the main part of the driver when it
> needs to write. The problem is I then need to stall the main part of the
> driver while the data gets written out. My problem is that this write needs
> to happen from an interrupt handler or a timer process. I cannot seem to
> block these with interruptible_sleep_on, the kernel crashes. I guess you
> cannot use this in these cases ? I have also tried semaphores without much
> success. I have looked for the howto but failed there also.
>
> Could you please tell me where I could find this FAQ.
>
> Many Thanks
>
> Simon.
>
You may want to post this somewhere. I don't have a web-page.
We are treated like prisoners here ;;;)) Just kidding, Thor
(network spy).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Tue, 19 Aug 2003, Simon Haynes wrote:
> Thanks I have looked at the attached file and I would really not like to
> access a file from the kernel but I cannot seem to get the user land app to
> work with writing. If you consider a kernel module which, in some event,
> needs to save some information in a file. The usr app is blocked in a read
> with interruptible_sleep_on. When the first write occurs the module calls
> wake_up_interruptible to write the data. Before the module can write the next
> chunk of data it needs to stall until the user process has finished.
> I can not find a method of stalling the module so it seems my only solution
> is to write the file from the kernel or dump the data somewhere manually.
>
> Cheers
No. SOP in user mode:
pf.fd = fd;
pf.revents = 0;
pr.events = POLLIN|OTHER_STUFF;
if(poll(&pf, 1, NR) > 0)
if(pf.revents & POLLIN))
read(fd, buf, BUF_LEN);
In the kernel module:
static wait_queue_head_t pwait;
static size_t global_poll;
static spinlock_t mylock;
// Remember to initialize both pwait and mylock;
static size_t poll(struct file *fp, struct poll_table_struct *wait)
{
size_t poll_flag;
size_t flags;
poll_wait(fp, &pwait, wait);
spin_lock_irqsave(&mylock, flags);
poll_flag = global_poll | POLLRDNORM|POLLWRNORM;
global_poll = 0;
spin_lock_irqrestore(&mylock, flags);
return poll_flag;
}
static void ISR(int irq, void *v, struct pt_regs *sp)
{
spin_lock(&mylock);
do_stuff_to_read_data_into_a_buffer();
spin_unlock(&mylock);
global_poll = POLLIN;
wake_up_interruptible(&pwait);
}
So. You have a user-task sleeping in poll() or select().
The kernel is interrupted. It calls your ISR where
you take data from wherever and put it into a buffer.
Then your ISR code, which knows that data are now available,
signals the sleeping task via wake_up_interruptible() and
then returns. The kernel scheduler now knows that your
task should be put into the run-queue and your task gets
the CPU via a return from poll(). You read the status
and now your task knows that data are available. Your
task calls read() to get the data.
There are no 'stalls'. You can be interrupted at any time.
Any time you switch buffers or manipulate pointers within
the module-code, where your code could get 'confused'
if an interrupt occurred, you use a spin-lock. This
prevents an interrupt from occurring at that time. You
release the lock as soon as it is safe to do so.
If data are streaming, you may need several buffers. You
need to synchronize your read() and the data source (the
ISR) so that old data are never overwritten. This, too, is
SOP. Just do it. It works. It's the basic stuff that makes
Unix work. There are lots of examples in the modules
supplied with the kernel sources.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Thanks I have looked at the attached file and I would really not like to
access a file from the kernel but I cannot seem to get the user land app to
work with writing. If you consider a kernel module which, in some event,
needs to save some information in a file. The usr app is blocked in a read
with interruptible_sleep_on. When the first write occurs the module calls
wake_up_interruptible to write the data. Before the module can write the next
chunk of data it needs to stall until the user process has finished.
I can not find a method of stalling the module so it seems my only solution
is to write the file from the kernel or dump the data somewhere manually.
Cheers
Simon.
On Tuesday 19 Aug 2003 1:17 pm, Richard B. Johnson wrote:
> On Tue, 19 Aug 2003, Simon Haynes wrote:
> > I actually had a character interface which I use for on the fly
> > configuration. I have now implemented some code which uses a user process
> > to pass the configuration to the driver. I have however run into problems
> > trying to write files from the driver. I have tried implementing a user
> > process which performs a blocking read. The user process is blocked with
> > interruptible_sleep_on and is woken by the main part of the driver when
> > it needs to write. The problem is I then need to stall the main part of
> > the driver while the data gets written out. My problem is that this write
> > needs to happen from an interrupt handler or a timer process. I cannot
> > seem to block these with interruptible_sleep_on, the kernel crashes. I
> > guess you cannot use this in these cases ? I have also tried semaphores
> > without much success. I have looked for the howto but failed there also.
> >
> > Could you please tell me where I could find this FAQ.
> >
> > Many Thanks
> >
> > Simon.
>
> You may want to post this somewhere. I don't have a web-page.
> We are treated like prisoners here ;;;)) Just kidding, Thor
> (network spy).
>
> Cheers,
> Dick Johnson
>
>
> Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
> Note 96.31% of all statistics are fiction.