Date: Thu, 11 Sep 2008 00:17:36 -0400 From: Fred Woods <fred@comment.icecreamhasnobones.org> To: <freebsd-multimedia@freebsd.org>, Fritz Katz <frtzkatz@yahoo.com> Subject: Re: Re: devel/linux-kmod-compat bit me Message-ID: <57988.1221106656@comment.icecreamhasnobones.org>
next in thread | raw e-mail | index | archive | help
On Wed 08/09/10 23:08 , Fritz Katz frtzkatz@yahoo.com sent: >=20 > 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 an= d > correct me. > The Linux msleep simply goes into a while spin-loop counting down a timeo= ut > 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); >=20 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57988.1221106656>