> Fourth, being able to initialize dynamic variables is not 'just' a
> performance optimization, it's a requirement.
Ingo what are you smoking???
You _can_ initialze a dynamic variable at runtime using:
sem = MUTEX;
or
sem = MUTEX_UNLOCKED;
I _don't_ need sema_init(). You can remove sema_init() and I'll run _fine_
using MUTEX and MUTEX_LOCKED instead. In 2.2.0-pre9 sema_init() when it's
used, it's used _only_ as a performance optimization because the code
where it's used knows _how_ sema_init() works and __just__ depends on
semaphore internals, it knows that all other fields of the semaphore has
to be zero (and are just zero by the memset(dst, 0, sizeof(struct)) done
a bit before) and set the only thing that need to be 1 to 1.
My patch only want to not hurt performances but avoiding other developers
to get mistakes using sema_init() thinking that it's a sane semaphore
initializer, while instead is only a trick to set to 1 only a field in a
long just zeroed struct.
My patch is _sure_ not worse than 2.2.0-pre9 with the differences that
there won't be further mistakes for _sure_. The policy is, if you want to
do tricky things to handle performances, do it by hand instead of simulate
to do clean things while instead they are still tricky.
Maybe I am wrong but I assure you that this is exactly what I understood
so far about sema_init() reading it and where it's used. Please tell me if
I am missing something. Excuse me if I caused waste of time to you.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/