[newbie] timer in module

[newbie] timer in module

[sebastien person]

Hi,

I have a network module that need to regularly get data from network
adaptater.
But I don't know if it safe to do a loop with a timer in the module.
e.g. I want to do something like that after ifconfig call :

while(1)
{
	timer call()
	get data()	//	these datas are specific to device
}

but I'm scared that will block the driver.
I've no experience of a regularly call that let the hand to the module.
My aim is to do a get data call every x seconds (x is variable).

Is it better to let an external program executing timer call and get data
call
via ioctl ?

In the case of a network module wich is able to send and receive data,
whats happen if the driver is sollicited when he received or send data ?
the tbusy bit is it designed to avoid this case ?

The module is it able to execute two different parts of the module code
at the same time ? (receiving data and handle a higher layer request)

thanks for any comments.

sebastien person

Re: [newbie] timer in module

[Bart Trojanowski]

On Fri, 18 May 2001, sebastien person wrote:

> I have a network module that need to regularly get data from network
> adaptater.
> But I don't know if it safe to do a loop with a timer in the module.

First off you have to decide where you want to run your 'get data'.  There
are three context you can pick from: user priority or from the kernel.  If
you run the loop below from a user context then you will have a very
unresponsive system but at least other things will still run.  If you run
that from a kernel context nothing else will run... unless you explicitly
call the scheduler.

> My aim is to do a get data call every x seconds (x is variable).

You mentioned a timer... it runs in kernel context but at least it
will not end up hanging your system up.  This is how you would use one:

struct tq_struct timer;
init_timer(&timer);
timer.routine = func;
timer.data = something;
mod_timer(&timer, 5*HZ); // 5 seconds from now

void func( unsigned long something ) {
	get_data( something );
	mod_timer(&timer, 5*HZ); // again in 5 seconds
}

Make sure you call 'del_timer_sync' once you are done.

> Is it better to let an external program executing timer call and get data
> call via ioctl ?

Since you are getting data every 5 seconds you may as well use a user
space program.  It does not seem like you are looking for phenomenal
responsiveness here.

Bart.

-- 
	WebSig: http://www.jukie.net/~bart/sig/

Re: [newbie] timer in module

[Alan Cox]

> I've no experience of a regularly call that let the hand to the module.
> My aim is to do a get data call every x seconds (x is variable).

	init_timer()
	add_timer()
	del_timer()

are your frinnds.

> In the case of a network module wich is able to send and receive data,
> whats happen if the driver is sollicited when he received or send data ?
> the tbusy bit is it designed to avoid this case ?

Your timer is like an interrupt (in fact it runs from one) so you will need
to lock it against transmit, receive, multicast list loads and get_stats
all of which can happen at the same time.

tbusy on 2.2 (its replaced on 2.4 with nicer stuff) is for write path locking,
and the kernel ensures your send packet routine wont be re-entered by another
send packet. It ensures you wont get an IRQ while handling the IRQ

The rest is up to you

Re: [newbie] timer in module

[sebastien person]

Le Fri, 18 May 2001 13:43:21 +0100 (BST)
Alan Cox <alan@lxorguk.ukuu.org.uk> a ecrit :

> > I've no experience of a regularly call that let the hand to the
module.
> > My aim is to do a get data call every x seconds (x is variable).
> 
> 	init_timer()
> 	add_timer()
> 	del_timer()
> 
> are your frinnds.
> 
> > In the case of a network module wich is able to send and receive data,
> > whats happen if the driver is sollicited when he received or send data
?
> > the tbusy bit is it designed to avoid this case ?
> 
> Your timer is like an interrupt (in fact it runs from one) so you will
need
> to lock it against transmit, receive, multicast list loads and get_stats
> all of which can happen at the same time.

So I must disable interrupt when I handle another function like receive
etc ...

> 
> tbusy on 2.2 (its replaced on 2.4 with nicer stuff) is for write path
locking,
> and the kernel ensures your send packet routine wont be re-entered by
another
> send packet. It ensures you wont get an IRQ while handling the IRQ
> 
> The rest is up to you

Thanks

Re: [newbie] timer in module

[Alan Cox]

> > Your timer is like an interrupt (in fact it runs from one) so you will
> need
> > to lock it against transmit, receive, multicast list loads and get_stats
> > all of which can happen at the same time.
> 
> So I must disable interrupt when I handle another function like receive
> etc ...

That depends on the nature of your hardware. Well designed hardware keeps
the various functional modules apart. On older or poorly designed hardware
that may not be the case - eg ythe old NE2000 cards have register windows
and the various code paths lock the chip so that somebody does not change
register window on someone else.

Re: [newbie] timer in module

[sebastien person]

Le Fri, 18 May 2001 08:32:33 -0400 (EDT)
Bart Trojanowski <bart@jukie.net> a ecrit :

> On Fri, 18 May 2001, sebastien person wrote:
> 
> > I have a network module that need to regularly get data from network
> > adaptater.
> > But I don't know if it safe to do a loop with a timer in the module.
> 
> First off you have to decide where you want to run your 'get data'. 
There
> are three context you can pick from: user priority or from the kernel. 
If
> you run the loop below from a user context then you will have a very
> unresponsive system but at least other things will still run.  If you
run
> that from a kernel context nothing else will run... unless you
explicitly
> call the scheduler.

So the fact to call the scheduler allow me to handle send request for
example ?

> 
> > My aim is to do a get data call every x seconds (x is variable).
> 
> You mentioned a timer... it runs in kernel context but at least it
> will not end up hanging your system up.  This is how you would use one:
> 
> struct tq_struct timer;
> init_timer(&timer);
> timer.routine = func;
> timer.data = something;
> mod_timer(&timer, 5*HZ); // 5 seconds from now
> 
> void func( unsigned long something ) {
> 	get_data( something );
> 	mod_timer(&timer, 5*HZ); // again in 5 seconds
> }
> 
> Make sure you call 'del_timer_sync' once you are done.
> 
> > Is it better to let an external program executing timer call and get
data
> > call via ioctl ?
> 
> Since you are getting data every 5 seconds you may as well use a user
> space program.  It does not seem like you are looking for phenomenal
> responsiveness here.
> 
> Bart.
> 
> -- 
> 	WebSig: http://www.jukie.net/~bart/sig/

Thanks for all these details

Re: [newbie] timer in module

[Richard B. Johnson]

On Fri, 18 May 2001, sebastien person wrote:

> Le Fri, 18 May 2001 08:32:33 -0400 (EDT)
> Bart Trojanowski <bart@jukie.net> a ecrit :
> 
> > On Fri, 18 May 2001, sebastien person wrote:
> > 
> > > I have a network module that need to regularly get data from network
> > > adaptater.
> > > But I don't know if it safe to do a loop with a timer in the module.
> > 
> > First off you have to decide where you want to run your 'get data'. 
> There
> > are three context you can pick from: user priority or from the kernel. 
> If
> > you run the loop below from a user context then you will have a very
> > unresponsive system but at least other things will still run.  If you
> run
> > that from a kernel context nothing else will run... unless you
> explicitly
> > call the scheduler.
> 
> So the fact to call the scheduler allow me to handle send request for
> example ?
> 
> > 
> > > My aim is to do a get data call every x seconds (x is variable).
> > 
> > You mentioned a timer... it runs in kernel context but at least it
> > will not end up hanging your system up.  This is how you would use one:
> > 
> > struct tq_struct timer;
> > init_timer(&timer);
> > timer.routine = func;
> > timer.data = something;
> > mod_timer(&timer, 5*HZ); // 5 seconds from now
> > 
> > void func( unsigned long something ) {
> > 	get_data( something );
> > 	mod_timer(&timer, 5*HZ); // again in 5 seconds
> > }
> > 
> > Make sure you call 'del_timer_sync' once you are done.
> > 
> > > Is it better to let an external program executing timer call and get
> data
> > > call via ioctl ?
> > 
> > Since you are getting data every 5 seconds you may as well use a user
> > space program.  It does not seem like you are looking for phenomenal
> > responsiveness here.
> > 
> > Bart.
> > 
> > -- 
> > 	WebSig: http://www.jukie.net/~bart/sig/
> 
> Thanks for all these details
> -
> 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/
> 

Errm... Something that happens every 5 seconds??? USER MODE. This
Is what Unix/Linux is very good at!

Generic device:

    fd = open("/dev/device", O_RDWR);
    for(;;)
    {
        read(fd, buf, sizeof(buf));
        ioctl(fd, GET_MY_PARMS, &params);
        sleep(5);
    }

Network modules use sockets.

   struct ifreq iq;
   memset(&iq, 0x00, sizeof(iq));
   strcpy(iq.ifr_name. "eth0");
   iq.ifr_data = pointer_to_a_place_to_put_get_stuff;
   s = socket(AF_INET, SOCK_DGRAM, 0);
   for(;;)
   {  
       ioctl(s, GET_MY_PARAMS, &iq);
       sleep(5);
    }

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

[newbie] timer in module

[sebastien person]

Début du message transféré :

Date: Tue, 22 May 2001 11:39:30 +0200
From: sebastien person <sebastien.person@sycomore.fr>
To: Bart Trojanowski <bart@jukie.net>
Subject: Re: [newbie] timer in module (fwd)


Le Mon, 21 May 2001 19:35:25 -0400 (EDT)
Bart Trojanowski <bart@jukie.net> a ecrit :

> 
> this was my first post on this thread.
> 
> I did miss one call and that was add_timer(), after that you can call
> mod_timer to change the next time the timer fires.

ok, to using mod_timer we must hace already used one time  add_timer ?

> Let me know if you need anything else.

So I've succeed to use a timer but with the struct timer_list.
I've found some example in rubini's book [oreilly], but I'm not sure
if the declaration of timer must be global ?
e.g If I do a timer call in a local function, whith a timer_list struct 
local, and when the scheduler handle the timer interrupt although I am
already out of local function... what's happen (oops ?)

And also I want to ensure that I can put whatever I want in the data
field.

thanks for all your advices.

> 
> Bart.