On Tuesday, 21 March 2000 at 7:46:57 +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Wes Peters writes:
>> Poul-Henning Kamp wrote:
>>>
>>> In message <[EMAIL PROTECTED]>, Warner Losh writes:
>>>
I'd like to be able to do some simple spl locking in a driver that I'm
wr
Wes Peters wrote:
>
> A per-driver mutex, perhaps? This would save us from potential
> deadly embraces within a single driver, at least.
I'm surprised no one mentioned the following yet.
splFoo() is one of FreeBSD curses. While what we have is much better
than the older splFoo() stuff, it's st
In message <[EMAIL PROTECTED]>, Wes Peters writes:
>Poul-Henning Kamp wrote:
>>
>> In message <[EMAIL PROTECTED]>, Warner Losh writes:
>>
>> >I'd like to be able to do some simple spl locking in a driver that I'm
>> >writing. While I could go the splhigh() route, I'm concerned that
>> >spending
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, Warner Losh writes:
>
> >I'd like to be able to do some simple spl locking in a driver that I'm
> >writing. While I could go the splhigh() route, I'm concerned that
> >spending lots of time at splhigh could cause problems, and some of
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : > In message <[EMAIL PROTECTED]> Guido van Rooij writes:
> : > : perhaps we need some mutex mechanism?
> : >
> : > Yes. Right now the mutex mechanism that we have is blocking of
> : > interrupts when the bit is set in t
In message <[EMAIL PROTECTED]> Wes Peters writes:
: > In message <[EMAIL PROTECTED]> Guido van Rooij writes:
: > : perhaps we need some mutex mechanism?
: >
: > Yes. Right now the mutex mechanism that we have is blocking of
: > interrupts when the bit is set in the cpl. I guess I'm a little too
> > : perhaps we need some mutex mechanism?
> >
> > Yes. Right now the mutex mechanism that we have is blocking of
> > interrupts when the bit is set in the cpl. I guess I'm a little too
> > close to the mechanism and need to step back.
> >
> > You are right that I'm asking for a call that is
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Guido van Rooij writes:
> : perhaps we need some mutex mechanism?
>
> Yes. Right now the mutex mechanism that we have is blocking of
> interrupts when the bit is set in the cpl. I guess I'm a little too
> close to the mechanism and need to
In message <[EMAIL PROTECTED]> Guido van Rooij writes:
: perhaps we need some mutex mechanism?
Yes. Right now the mutex mechanism that we have is blocking of
interrupts when the bit is set in the cpl. I guess I'm a little too
close to the mechanism and need to step back.
You are right that I'
On Sat, Mar 18, 2000 at 01:31:28PM -0700, Warner Losh wrote:
>
> I'd like to be able to do some simple spl locking in a driver that I'm
> writing. While I could go the splhigh() route, I'm concerned that
> spending lots of time at splhigh could cause problems, and some of my
> critical sections
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>I'd like to be able to do some simple spl locking in a driver that I'm
>writing. While I could go the splhigh() route, I'm concerned that
>spending lots of time at splhigh could cause problems, and some of my
>critical sections look to be very
Shouldn't all of this should be properties of the newbus code? There should be
some value that is associated with any device that says "I need to disable
receiving interrupts from this device". This could then fold into an MP
spinlock case that honors device interrupts. What you're describing bel
12 matches
Mail list logo
