| |||||||||||||
|
| |||||||||||||
A practical definition of bloatA practical definition of bloatPosted Nov 1, 2002 2:54 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)In reply to: Linus on what remains to be merged by Schneelocke Parent article: Linus on what remains to be merged 'bloat' is often used as a reason for not including this or that. And I've seen many with the attitude of "it's not bloat, it can be compiled out. And source code download size is not a problem", etc. But most of the current patch rejections, where 'bloat' is a factor, are due to feature bloat (orthogonal to size of executable, or size of download, or running size in memory, etc.) And feature bloat is the most important point (from Linus's perspective), because as was stated earlier, once it goes in, no matter what comes along that is better, it is hard to remove it. And maintaining features that are used by but a few, can be a REAL burden. With all the features being pushed for the deadline, even very technically sound patches can be justifiably dropped. I for one thought epoll() should have been held back a release, to see if an overall better API could be conceived. Just like vfork(), stat(), ioctl(), <other legacy crap>, etc. once it has users it cannot be dropped, and others will adopt it, even if a more elegant method comes along in a year. So, just keep that in mind when you see 'bloat', that whether or not something can be compiled in or not, whether it touches few parts of the core, or whether its run-time impact is low, it is still bloated if it creates a maintenance burden that is unjustified. Of course, agreeing on what is bloat or not is a whole other issue, separate from the shady definition of the word itself.
(Log in to post comments)
In defense of epoll Posted Nov 1, 2002 9:41 UTC (Fri) by Peter (guest, #1127) [Link] (+1, Insightful) - nice explanation of what bloat actually is in this context and why it must be avoided even when it doesn't directly affect the object code. But - I for one thought epoll() should have been held back a release, to see if an overall better API could be conceived. I disagree, in this instance. For one thing, epoll() isn't exactly new. A port of the Solaris /dev/poll first appeared somewhere in early 2.3.x, if I remember correctly. Linus shot it down on the spot - "we don't need no stinking device file", as it were - and thus the syscall approach was born. So this isn't someone's last-minute feature-freeze brainfart (like sendfile(), which was conceived, implemented and integrated all within about a week, just before 2.2.0) - it's been kicking around for quite awhile. For another thing, note that the epoll stuff is itself a second system, quite aside from the /dev/poll business. It is already a redesign of the classic select() and poll() interfaces. In fact, you can go further: midway through 2.1.x, Richard Gooch (I think) introduced poll() as an independent syscall; previously it had been emulated using select(), which is not as efficient in the case of a sparse fd set. So to summarise, epoll is a reimplementation of poll() which is a reimplementation of the select-emulation-based poll(), and people have been thinking about this interface for at least 2 years now. I for one rather like the epoll API as described by Jon on these pages. It seems to map rather well to the familiar FD_ZERO(), FD_SET(), etc. used with select() ... so converting code to use epoll should not be too hard. My only question is whether it would have been worthwhile to specify a way to pass a whole array of fd's rather than just a single fd per syscall, but I suspect it doesn't matter much - syscalls are cheap in Linux, and you only have to set up your epoll structure once (that being kind of the whole point!).
In defense of epoll Posted Nov 1, 2002 21:53 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link] Thanks. I don't mean to pick on epoll(), other than that it is a current example of a feature that is immediately useful, relatively small and unintrusive to add to the source, but could still be considered 'bloat' (rightly or wrongly), by those who might want the freedom to adopt yet another event delivery mechanism in the future.
|
|
||||||||||||