mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [newbie] timer in module
@ 2001-05-18 11:54 sebastien person
  2001-05-18 12:32 ` Bart Trojanowski
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: sebastien person @ 2001-05-18 11:54 UTC (permalink / raw)
  To: liste noyau linux

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 11:54 [newbie] timer in module sebastien person
@ 2001-05-18 12:32 ` Bart Trojanowski
  2001-05-18 12:43 ` Alan Cox
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 8+ messages in thread
From: Bart Trojanowski @ 2001-05-18 12:32 UTC (permalink / raw)
  To: sebastien person; +Cc: liste noyau linux

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/


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 11:54 [newbie] timer in module sebastien person
  2001-05-18 12:32 ` Bart Trojanowski
@ 2001-05-18 12:43 ` Alan Cox
  2001-05-18 13:28 ` sebastien person
  2001-05-18 13:33 ` sebastien person
  3 siblings, 0 replies; 8+ messages in thread
From: Alan Cox @ 2001-05-18 12:43 UTC (permalink / raw)
  To: sebastien person; +Cc: liste noyau linux

> 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 11:54 [newbie] timer in module sebastien person
  2001-05-18 12:32 ` Bart Trojanowski
  2001-05-18 12:43 ` Alan Cox
@ 2001-05-18 13:28 ` sebastien person
  2001-05-18 13:53   ` Alan Cox
  2001-05-18 13:33 ` sebastien person
  3 siblings, 1 reply; 8+ messages in thread
From: sebastien person @ 2001-05-18 13:28 UTC (permalink / raw)
  To: Alan Cox; +Cc: liste noyau linux

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 11:54 [newbie] timer in module sebastien person
                   ` (2 preceding siblings ...)
  2001-05-18 13:28 ` sebastien person
@ 2001-05-18 13:33 ` sebastien person
  2001-05-18 13:54   ` Richard B. Johnson
  3 siblings, 1 reply; 8+ messages in thread
From: sebastien person @ 2001-05-18 13:33 UTC (permalink / raw)
  To: Bart Trojanowski; +Cc: liste noyau linux

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 13:28 ` sebastien person
@ 2001-05-18 13:53   ` Alan Cox
  0 siblings, 0 replies; 8+ messages in thread
From: Alan Cox @ 2001-05-18 13:53 UTC (permalink / raw)
  To: sebastien person; +Cc: Alan Cox, liste noyau linux

> > 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.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [newbie] timer in module
  2001-05-18 13:33 ` sebastien person
@ 2001-05-18 13:54   ` Richard B. Johnson
  0 siblings, 0 replies; 8+ messages in thread
From: Richard B. Johnson @ 2001-05-18 13:54 UTC (permalink / raw)
  To: sebastien person; +Cc: Bart Trojanowski, liste noyau linux

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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* [newbie] timer in module
@ 2001-05-22 10:53 sebastien person
  0 siblings, 0 replies; 8+ messages in thread
From: sebastien person @ 2001-05-22 10:53 UTC (permalink / raw)
  To: liste noyau linux



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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2001-05-22 10:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-18 11:54 [newbie] timer in module sebastien person
2001-05-18 12:32 ` Bart Trojanowski
2001-05-18 12:43 ` Alan Cox
2001-05-18 13:28 ` sebastien person
2001-05-18 13:53   ` Alan Cox
2001-05-18 13:33 ` sebastien person
2001-05-18 13:54   ` Richard B. Johnson
2001-05-22 10:53 sebastien person

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®