Davide Libenzi wrote:
On Wed, 2 May 2007, Davi Arnaut wrote:
So in this case I may borrow some signalfd code :-) I really like the
signalfd approach, but IMHO the code is quite ugly and duplicates
a lot of hairy code.
Ugly, really? Please ...
+ while (!mutex_trylock(&evs->mutex))
+ cpu_relax();
I would call that a "creative way to spin a mutex" .
So, let's see. The whole things adds an unneeded (read "empty") extra
layer of indirections over the existing file_operations.
"Empty" ? It handles the non-blocking code, event waiting, filp
setup. It's a affordable extra thin layer.
Timerfd added the
return of the structure (because "developer may need it"), that wants
extra compat too.
I bet the pltimer/plsignal compat code will be smaller/cleaner then
the timerfd/signalfd. Will post soon.
Your signal code does not handle things that is supposed
to be handling (easy to write clean code when the code does not actually
do what is supposed to be doing), and you'll be sucking code from
signalfd.
As if sucking code from signalfd is a bad thing.
On top of that, it returns a structure that needs compat too.
AIO code added an extra unnecessary wrapper over AIO native calls (by
literally calling sys_io_*). And the compat on sys_read/sys_write I
guess will be funny to watch.
I hope you enjoy it :-)
So what does your code effectively adds that
is useful in some way? Undocumented and testcase-less code?
As I see it, your code badly copies exiting one, and adds uneeded
infrastrcture/functionality.
If you don't remember i mailed you the patches back on 03/08/2007.
It's definitely not a copy.
See, I really wouldn't care, if you'd keep the "ugly" word for yourself.
its a matter of taste and i'm entitled to a bad one every once in a
while :-)
Actually, I really care only about the functionality, so I leave the whole
ball into Andrew's hands ;)
Anyway, I didn't expect to move forward with your blessing but your comments
are appreciated.
Andrew, If you see fit, go ahead with signalfd. Anyway, i will cook up a
a new version
for tomorrow.
--
Davi Arnaut
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
