-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Matthew Orgass wrote:

> On 2005-09-06 ritter.alan@gmail.com wrote:
>
>> Right now I'm just focusing on getting a driver that is stable on
>> a single processor system (I want to get it tested and working on
>> a multiprocessor system eventually). Anyway I may be wrong, but
>> I was thinking that simplelock's only make a difference when
>> there's more than one processor that can run at a time.
>
>
> Yes, that is true. The spl changes are what is needed for single
> processor machines. However, you will need simple locks in exactly
> the places you need spl changes, so it makes sense to add them
> together. A combined macro is generally used for this. There was
> an effort to combine the two (the newlock branch), but this has
> been idle for years.

That's a good idea, I think I'll add a macro like you suggest.

>
> If you don't want to do the locking, then remove the locking calls
> entirely. It doesn't make sense to do partial locking.

I want to do it, as I'm very motivated to get stable NDIS drivers on
NetBSD.  Unfortunately I don't have a lot of experience with
threads/locking (I will be taking a Parallel Computing class this
coming quarter, however).  If anybody has NetBSD simplelock/lockmgr
experience, and would like to work on this with me I'd be very happy :-)

I just tried replacing the sleep (lockmgr) locks in kern_ndis.c with
simplelock's, and the driver seems to work just the same.  There's
some other areas where synchronization between interrupts is required,
and thus I'll need more simplelock's.  Anyway, I think my first order
of business will be to create macros for all the different locks.

Anyway, It's not very difficult for me to add simplelock's to the code
for multiprocessor support, the difficult thing (I think) is that I
need to synchronize between the top and bottom halves of the kernel in
the same code.  For instance the same critical section may be ran in
multiple threads in the top half of the kernel (although I don't think
this is a problem as NetBSD kernel threads aren't scheduled), and it
might be ran without a user context.  I'm not sure if I need to
restructure the code so that functions which access shared data either
get called exclusively from the top half, or the bottom, but not both?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFDHjeWdrBy3JhXjT8RAlXVAJ9Ot3JXsVYeoxCwnrGAsMNDAqvqegCaA8qY
FPcoYePXKeLBiFqWSHW2fag=
=ZdeE
-----END PGP SIGNATURE-----