Re: [Lse-tech] Re: [PATCH] Updated sys_epoll now with man pages

[Randy.Dunlap]

On Mon, 28 Oct 2002, Andrew Morton wrote:

| Hanna Linder wrote:
| >
| >    sys_epoll-2.5.44-last.diff
|
| Folks,
|
| when I took a 15-minute look at this code last week I found several
| bugs, some of which were grave.  It's a terrible thing to say, but
| a sensible person would expect that a closer inspection would turn
| up more problems.
|
| Now, adding bugs to existing code is fine and traditional - people
| find them quickly and they get fixed up.
|
| But for *new* code, problems will take months to discover.  The only
| practical way to get this code vetted for inclusion is a close review.
|
| And that is a sizeable task.  The core implementation file is
| 1,600 lines.  And I wonder how many people have counted the
| number of comments in there?
|
| Well, I'll make it easy: zero.  Nil.  Nada.
|
| (Well, OK, a copyright header, and something which got cut-n-pasted
| from inode.c)
|
| In my wildly unconventional opinion this alone makes epoll just a hack,
| of insufficient quality for inclusion in Linux.  We *have* to stop doing
| this to ourselves!

I expect this to be unpopular, but I've been saying lately that
when new kernel APIs or syscalls or whatsoever are added to
Linux, there should be sufficient docs along with the patch(es)
explaining the patch and some intended uses of it, perhaps even
with examples.  Ingo does this sometimes.  Some people don't
bother to even come close.

Leading by example would be a nice thing to see here.

And "use the source Luke" is cool and is definitive.
But it's not the only way to get things done.
Well, maybe it is, but it shouldn't and needn't be.

| epoll seems to be a good and desirable thing.  To move forward I
| believe we need to get this code reviewed, and documented.
|
| I can do that if you like; it will take me several weeks to get onto
| it.  But until that is completed I would oppose inclusion of this
| code.
| -------------------------------------------------------

-- 
~Randy