so should i hold rtnl across add/remove atm addresses on atm dev's?
(but iw ouldnt hold rtnl across people just reading the list of
atm addresses right?)
>Hmmm, this is not how RTNL works on netdevs. The SMP lock is held
>around all walking, and at the very precise moment where we are
>doing the actual device unlink from dev_base. rtnl is acquired at
>top-level when we will change something.
>This is very different from how you are using the lock+rtnl scheme
>for your ATM stuff.
ok, i was thinking i could use rtnl to protect readers. this makes the
connect(dev = ANY) rather icky. some of the abuse by me in other places
might be moot in the future. i am planning (or have done) to move all
the vcc's onto a global list (ala many of the other protocol stacks).
this makes the code for proc (and others) much cleaner since you just grab
a read lock on the global vcc sklist instead of locking and interating
each atm device. further, this will let atm interrupt handlers block
a race with vcc close/removal. is this a bad plan?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/