devel/linux-kmod-compat bit me

Fred Woods fred at
Thu Sep 11 04:17:37 UTC 2008

On Wed 08/09/10 23:08 , Fritz Katz frtzkatz at sent:
> I've often wondered about the differences between the Linux msleep and
> FreeBSD msleep -- I've actually lost some sleep thinking about it.  They
> appear to be the same in name only. Am I confused here? If so, jump in and
> correct me.
> The Linux msleep simply goes into a while spin-loop counting down a timeout
> on schedule_timeout_uninterruptible( ). It seems to be a closer match to
> the Standard C library call: usleep.
> The FreeBSD msleep seems to be a different beast entirely. A better name
> would be 'mutex_sleep' since that is what it does. In fact, we shouldn't
> use FreeBSD msleep since it has been depreciated, use mtx_sleep
> instead.
> For linux_kmod_compat would a better match to the Linux msleep be the
> FreeBSD kernel function pause?:
> void pause(const char *wmesg, int timo);
pause() is tsleep(). Linux msleep() is signal safe,
usleep() is not.  Presumably someone would use Linux
msleep() to delay accessing some device to allow for
its specified settle time.  One issue with trying to
map the Linux call into a FreeBSD call is the FreeBSD
side has functionality to handle multiple threads
and/or processes waiting on the same thing.  The Linux
side of the mapping does not have that functionality.

A key question then is: how inportant is it that the
FreeBSD side know exactly what it is the Linux side
is waiting for?

In the case of the device is being accessed exclusively
by the Linux side, then all that probably really
maters is that the mapping function does not
inadvertently make the FreeBSD side think the Linux
side is waiting on an ident used by something else.

In the case where the device is being accessed by both
sides, then it is inportant that the mapping function
know exactly what ident to use.  Given the additional
requirements this places on native FreeBSD drivers, it
might we wise to just not support this case.

More information about the freebsd-multimedia mailing list