linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* correct use of lock_kernel() - help!  please
@ 2001-01-29 10:29 Iain Sandoe
  2001-01-29 11:05 ` Roman Zippel
  0 siblings, 1 reply; 4+ messages in thread
From: Iain Sandoe @ 2001-01-29 10:29 UTC (permalink / raw)
  To: linuxppc-dev


Hi,

In the driver I am working on (dmasound) someone has placed lock/unlock
_kernel() pairs around whole functions.

This means that (e.g.) if we release the sound device with a lot of
un-played samples at a low-ish sample rate...

AFACIT we could hold the kernel locked for *several seconds*

What do I really need to protect with lock/unlock pairs?

or am I missing something (it wouldn't be the first time ..) ;-?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: correct use of lock_kernel() - help!  please
  2001-01-29 10:29 Iain Sandoe
@ 2001-01-29 11:05 ` Roman Zippel
  0 siblings, 0 replies; 4+ messages in thread
From: Roman Zippel @ 2001-01-29 11:05 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: linuxppc-dev


Hi,

On Mon, 29 Jan 2001, Iain Sandoe wrote:

> AFACIT we could hold the kernel locked for *several seconds*

If you sleep inbetween, it's no problem. The kernel lock is released
automatically during sleep and reget after sleeping.

> What do I really need to protect with lock/unlock pairs?

SMP protection. Only a single processor can hold the kernel lock at the
same time. The preferred solution is of course to use semaphores /
spinlocks.

bye, Roman


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: correct use of lock_kernel() - help!  please
@ 2001-01-29 11:24 Iain Sandoe
  2001-01-29 13:39 ` Roman Zippel
  0 siblings, 1 reply; 4+ messages in thread
From: Iain Sandoe @ 2001-01-29 11:24 UTC (permalink / raw)
  To: Roman Zippel; +Cc: linuxppc-dev


Thanks Roman,
On  Mon, Jan 29, 2001, Roman Zippel wrote:
> On Mon, 29 Jan 2001, Iain Sandoe wrote:
>> AFACIT we could hold the kernel locked for *several seconds*
> If you sleep inbetween, it's no problem. The kernel lock is released
> automatically during sleep and reget after sleeping.

Ok. I think we are alright then.

>> What do I really need to protect with lock/unlock pairs?
> SMP protection. Only a single processor can hold the kernel lock at the
> same time. The preferred solution is of course to use semaphores /
> spinlocks.

I think my question was badly phrased:

Around the use of which kernel resources should a lock be applied?

tia,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: correct use of lock_kernel() - help!  please
  2001-01-29 11:24 correct use of lock_kernel() - help! please Iain Sandoe
@ 2001-01-29 13:39 ` Roman Zippel
  0 siblings, 0 replies; 4+ messages in thread
From: Roman Zippel @ 2001-01-29 13:39 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: linuxppc-dev


Hi,

On Mon, 29 Jan 2001, Iain Sandoe wrote:

> Around the use of which kernel resources should a lock be applied?

Depends on the resource, but most of it shouldn't need this anymore. If
the kernel lock is moved into the driver, it usually means that everything
else is safe, check now that the driver itself is smp safe, then you can
remove the kernel lock.

bye, Roman


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-01-29 13:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-29 11:24 correct use of lock_kernel() - help! please Iain Sandoe
2001-01-29 13:39 ` Roman Zippel
  -- strict thread matches above, loose matches on Subject: below --
2001-01-29 10:29 Iain Sandoe
2001-01-29 11:05 ` Roman Zippel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).