Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Quite frankly, I have _never_ever_ seen a good reason for talking
to the kernel with some idiotic packet interface. It's just a fancy
way to do ioctl's, and everybody knows that ioctl's are bad and
evil. Why are fancy packet interfaces suddenly much better?
-- Linus Torvalds on netlink
I've yet to see any believable and complete explanation for these
gains. I've asked about these things multiple times and nothing
happened.
-- Andrew Morton on per-BDI writeback
I suspect that what happened over time was that previously-working code got broken, then later people noticed the breakage but failed to analyse and fix it in favour of simply ripping everything out and starting again. So for the want of analysing and fixing several possible regressions, we've tossed away some very sensitive core kernel code which had tens of millions of machine-years testing. I find this incredibly rash.
-extern void refrigerator(void);
+extern void refrigerator(void) __cold;
(Log in to post comments)
netlink Posted Sep 24, 2009 8:04 UTC (Thu) by smurf (subscriber, #17840) [Link]
netlink has one huge advantage: you can tell the kernel "send me any changes" on the netlink socket and then simply select() on the file descriptor. That doesn't work with any random ioctl interface.
Not requiring programs to poll is good.
netlink Posted Sep 28, 2009 6:03 UTC (Mon) by neilbrown (subscriber, #359) [Link]
Even better: export the data via sysfs attribute file, and use select/poll on those.
(though to be fair to ioctl: it is quite possible to have an ioctl that blocks until new state is available - see DM_DEV_WAIT_CMD).
|
|||||||||||||