Hello!
> Yes, I see. I did not realize before that the lock_sock and the
> sk->backlog framework are not two independent things. They really
> seem to be designed for team work only. Did I get this right?
Yes.
Actually, in 2.4 lock_sock() is also semaphore and in some cases
(f.e. for stateless datagram sockets) it is used as pure semaphore.
> applied seems to make socket propgramming as easy as in the old cli()/sti()
> days again.
What??? 8)8)
No, it makes it much easier. 8)
By the way:
1. lock_sock() is not much younger than cli()/sti().
2. cli()/sti() is not used by attended parts of networking for looong time,
they are deprecated not yesterday too.
> tcp also seems to use some additional protocol-global spinlocks
Of course.
> (like tcp_portalloc_lock).
And this is redundant, to be honest. 8)
> the spinlock. In that case, beeing preemptable would make a very essential
> difference.
Yes, of course.
> Anyway, it seems that I can already make use the lock_sock() infrastructure
> for fixing the output serialization, even without making the whole
> protocol stack SMP-aware at once.
Actually, the last task is not a rocket science as well.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
