M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Sergey Babkin <[EMAIL PROTECTED]> writes:
: Maybe it can be fixed in the kernel without
: too much trouble.
It already is in libthr and libposix. They already use execution
contexts to map M threads onto N contexts. libc_r is be
Sergey Babkin wrote:
From: "M. Warner Losh" <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: >
: > On 11/03/05 03:12 Warner Losh said the following:
: >
: >> Yes. if you tsleep with signals enabled, the periodic timer will go
: >> off, and you'
In message: <[EMAIL PROTECTED]>
Sergey Babkin <[EMAIL PROTECTED]> writes:
: Maybe it can be fixed in the kernel without
: too much trouble.
It already is in libthr and libposix. They already use execution
contexts to map M threads onto N contexts. libc_r is being retired
and not wort
>From: "M. Warner Losh" <[EMAIL PROTECTED]>
>Scott Long <[EMAIL PROTECTED]> writes:
>: Dinesh Nair wrote:
>: >
>: >
>: > On 11/03/05 03:12 Warner Losh said the following:
>: >
>: >> Yes. if you tsleep with signals enabled, the periodic timer will go
>: >> off, and you'll return earl
On Thu, Nov 03, 2005 at 04:55:10AM +0800, Dinesh Nair wrote:
>
> On 11/03/05 04:27 M. Warner Losh said the following:
> >that this is the case: sleep in an ioctl, and the entire process hangs
> >until the ioctl returns.
>
> which is probably what's happening in my case. i've got 4 threads spun of
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: >
: > On 11/03/05 03:12 Warner Losh said the following:
: >
: >> Yes. if you tsleep with signals enabled, the periodic timer will go
: >> off, and you'll return early. This typically i
On 11/03/05 05:15 Scott Long said the following:
before the ioctl call runs. But it does work. Look at the aac(4)
driver for my example of this.
i will, it sounds like a good solution.
The other option is to use rfork, aka 'linuxthreads' to similate threads
i could try with linuxthreads
On 11/03/05 05:17 M. Warner Losh said the following:
this is to create a helper program that gets the ioctl request over a
pipe or socket, does the call to the kernel and then returns the
results. Not idea, I'll grant, but it is an alternative worth
no, that wont work. the userland app is ast
In message: <[EMAIL PROTECTED]>
Dinesh Nair <[EMAIL PROTECTED]> writes:
:
:
: On 11/03/05 03:12 Warner Losh said the following:
: > Yes. if you tsleep with signals enabled, the periodic timer will go
: > off, and you'll return early. This typically isn't what you want
: > either.
:
Dinesh Nair wrote:
On 11/03/05 03:12 Warner Losh said the following:
Yes. if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early. This typically isn't what you want
either.
looks like i've got a lot of work to do, poring thru all the ioctls for
the d
On 11/03/05 04:27 M. Warner Losh said the following:
that this is the case: sleep in an ioctl, and the entire process hangs
until the ioctl returns.
which is probably what's happening in my case. i've got 4 threads spun off,
and one thread reads what the other writes and vice versa. after wri
On 11/03/05 03:12 Warner Losh said the following:
Yes. if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early. This typically isn't what you want
either.
looks like i've got a lot of work to do, poring thru all the ioctls for the
device and trying to us
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Julian Elischer <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
:
: >
: >
: > On 10/28/05 10:52 M. Warner Losh said the following:
: >
: >> libc_r will block all other threads in the application while an ioctl
: >> executes. li
In message: <[EMAIL PROTECTED]>
Julian Elischer <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
:
: >
: >
: > On 10/28/05 10:52 M. Warner Losh said the following:
: >
: >> libc_r will block all other threads in the application while an ioctl
: >> executes. libpthread and libthr won't
Dinesh Nair wrote:
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
so if the userland thread does an ioctl, and the the driver goes to
tsleep(
From: Dinesh Nair <[EMAIL PROTECTED]>
Subject: Re: locking in a device driver
Date: Thu, 03 Nov 2005 02:23:32 +0800
>
>
> On 10/28/05 10:52 M. Warner Losh said the following:
> > libc_r will block all other threads in the application while an ioctl
> > executes.
Dinesh Nair wrote:
On 11/02/05 06:12 Julian Elischer said the following:
depends on what they are using it for..
if it's a WAN interface, then splimp. (INTR_TYPE_NET)
if ppp or several other moduels are loaded, teh tty and net masks are
combined anyhow..
it's a quad-span E1/T1 line card
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
so if the userland thread does an ioctl, and the the driver goes to
tsleep() when the ioctl is rec
On 11/02/05 06:16 Julian Elischer said the following:
also, why do you need a pseudo device AND a device? The device driver
can do all the things you have
suggested on its own.
this is so userland apps wont need to change when different devices are
used. the pseudo device is the front for a
On 11/02/05 06:12 Julian Elischer said the following:
depends on what they are using it for..
if it's a WAN interface, then splimp. (INTR_TYPE_NET)
if ppp or several other moduels are loaded, teh tty and net masks are
combined anyhow..
it's a quad-span E1/T1 line card which would be carryin
Dinesh Nair wrote:
On 11/02/05 03:51 Scott Long said the following:
INTR_TYPE_TTY and spltty
[..snipped..]
You'll also want to use an spl in the top half of the pseudo driver to
cover where the pointers are read and changed.
thanx a bunch. i'll rewrite the portions affected based on yo
Scott Long wrote:
Dinesh Nair wrote:
On 11/02/05 03:02 Julian Elischer said the following:
drops to splzero or similar,..
woken process called,
starts manipulating "another buffer"
collides with next interrupt.
that makes a lot of sense, i'll try with using splxxx() in the pseudo
driv
On 11/02/05 03:51 Scott Long said the following:
INTR_TYPE_TTY and spltty
[..snipped..]
You'll also want to use an spl in the top half of the pseudo driver to
cover where the pointers are read and changed.
thanx a bunch. i'll rewrite the portions affected based on yours and
julian's suggest
Dinesh Nair wrote:
On 11/02/05 03:02 Julian Elischer said the following:
drops to splzero or similar,..
woken process called,
starts manipulating "another buffer"
collides with next interrupt.
that makes a lot of sense, i'll try with using splxxx() in the pseudo
driver, to block out the r
On 11/02/05 03:02 Julian Elischer said the following:
drops to splzero or similar,..
woken process called,
starts manipulating "another buffer"
collides with next interrupt.
that makes a lot of sense, i'll try with using splxxx() in the pseudo
driver, to block out the real driver. it's curre
Julian Elischer wrote:
Dinesh Nair wrote:
On 11/02/05 00:03 Scott Long said the following:
I think this thread has gone too far into hyperbole and conjecture.
What is your code trying to do, and what problems are you seeing?
apologies, scott. i'm actually trying to get a driver written
Dinesh Nair wrote:
On 11/02/05 00:03 Scott Long said the following:
I think this thread has gone too far into hyperbole and conjecture.
What is your code trying to do, and what problems are you seeing?
apologies, scott. i'm actually trying to get a driver written for
freebsd 5.x backporte
On 11/02/05 00:03 Scott Long said the following:
I think this thread has gone too far into hyperbole and conjecture. What
is your code trying to do, and what problems are you seeing?
apologies, scott. i'm actually trying to get a driver written for freebsd
5.x backported to 4.x. the driver wo
In message: <[EMAIL PROTECTED]>
Dinesh Nair <[EMAIL PROTECTED]> writes:
:
:
: On 10/28/05 16:40 Dinesh Nair said the following:
: >
: >
: > On 10/28/05 10:52 M. Warner Losh said the following:
: >
: >> libc_r will block all other threads in the application while an ioctl
: >> execu
Dinesh Nair wrote:
On 10/28/05 16:40 Dinesh Nair said the following:
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
which is a Good Thing(
On 10/28/05 16:40 Dinesh Nair said the following:
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
which is a Good Thing(tm) indeed for me on 4
On 10/27/05 22:00 Scott Long said the following:
If you need to protect your pseudodriver from being interrupted by the
real driver then you'll need to use the same spl() as the driver. Note
that you shouldn't be using splhigh() unless you really know what you
the driver currently is set to u
On 10/28/05 10:52 M. Warner Losh said the following:
libc_r will block all other threads in the application while an ioctl
executes. libpthread and libthr won't. I've had several bugs at work
which is a Good Thing(tm) indeed for me on 4.x.
--
Regards, /\_/\ "All
In message: <[EMAIL PROTECTED]>
Dinesh Nair <[EMAIL PROTECTED]> writes:
: the userland application uses pthreads, and works like a charm both on 4.x
: and 5.x without using the device. however, when the device is used, it
: somehow has synchronization errors on 4.x, leading to timers
On 10/27/05 22:00 Scott Long said the following:
are doing. Other than that, there likely isn't anything that you need
to do for 'locking' in 4.x. The kernel is non-reentrant there, so you
don't need to worry about synchronizing multiple threads.
thanx a bunch, scott. it's been a nightmare t
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: > carrying on this discussion, what would be a good locking mechanism to
: > use to protect tsleep() and other sensitive areas in a driver in freebsd
: > 4.x ?
:
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: > carrying on this discussion, what would be a good locking mechanism to
: > use to protect tsleep() and other sensitive areas in a driver in freebsd
: > 4.x ?
: >
: > the current code
Dinesh Nair wrote:
carrying on this discussion, what would be a good locking mechanism to
use to protect tsleep() and other sensitive areas in a driver in freebsd
4.x ?
the current code for the driver in 5.x uses mtx_lock and mtx_unlock with
some parts even being protected by mtx_lock(&Gian
38 matches
Mail list logo
