parameters for tsleep(9)

Roman Kurakin rik at cronyx.ru
Sun Dec 26 13:28:37 PST 2004


Hi,

1) man tsleep

2) tsleep is just msleep with NULL mutex.

 if you check sys/kern/kern_synch.c you will
 see KASSERT (ident != NULL && ...

 ident is exactly the first parameter.

rik

Norbert Koch:

>Hello.
>
>I am just writing a device driver for the i82527 (can-bus) chip.
>For testing I need the driver to poll the chip instead of running
>in interrupt mode.
>
>My dev_t read function basically looks like this:
>
>for (;;)
>{
>  while (chip_has_data(...))
>  {
>    read_chip_data(...);
>    error = do_uiomove(...);
>    if (error || enough_read(...))
>    {
>      return error;
>    }
>  };
>  if (do_not_block_on_read(...))
>  {
>    return EWOULDBLOCK;
>  }
>  error = tsleep (XXX, PCATCH|PWAIT, "canrd", hz / 10);
>  if (error != EWOULDBLOCK)
>  {
>    return error;
>  }
>}
>
>XXX should be 'something' which could be used
>as parameter to wakeup(9), I read in tsleep(9).
>In the kernel source tree I found one
>place where tsleep _only_ sleeps: in sys/isa/ppc.c
>(which already seems to be in the attic [?] but
>still is in my computer's source tree).
>Here, the first parameter was set to NULL.
>Doing this I found, that tsleep immediately
>returns 0 (which means: wakueup was called)
>_without_ waiting. I even crashed or
>froze the kernel by calling tsleep (NULL, ...)
>for a random number of times. After changing
>this to the address of the read-function itself,
>all worked fine. No more crashes.
>
>Just for my understanding: Is this a bug?
>Does the first parameter have to point to
>something useful?
>Is it allowed to point it to a code position?
>Or should I use some kind of dummy data in
>the softc structure instead?
>
>What about the second parameter: Is PWAIT
>ok here or should I use PZERO or whatever?
>
>(And btw, why has ppc.c been removed?)
>
>Thank you.
>_______________________________________________
>freebsd-hackers at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>  
>




More information about the freebsd-hackers mailing list