Re: [take12 0/3] kevent: Generic event handling mechanism.

["Randy.Dunlap" <rdunlap@xenotime.net>]

On Tue, 22 Aug 2006 15:58:12 -0700 Nicholas Miell wrote:

> On Tue, 2006-08-22 at 14:37 -0700, Randy.Dunlap wrote:
> > On Tue, 22 Aug 2006 14:13:02 -0700 Nicholas Miell wrote:
> > 
> > > On Wed, 2006-08-23 at 00:16 +0400, Evgeniy Polyakov wrote:
> > > > On Tue, Aug 22, 2006 at 12:57:38PM -0700, Nicholas Miell (nmiell@comcast.net) wrote:
> > > > > On Tue, 2006-08-22 at 14:03 +0400, Evgeniy Polyakov wrote:
> > > > > Of course, since you already know how all this stuff is supposed to
> > > > > work, you could maybe write it down somewhere?
> > > > 
> > > > I will write documantation, but as you can see some interfaces are
> > > > changed.
> > > 
> > > Thanks; rapidly changing interfaces need good documentation even more
> > > than stable interfaces simply because reverse engineering the intended
> > > API from a changing implementation becomes even more difficult.
> > 
> > OK, I don't quite get it.
> > Can you be precise about what you would like?
> > 
> > a.  good documentation
> > b.  a POSIX API
> > c.  a Windows-compatible API
> > d.  other?
> > 
> > and we won't make you use any of this code.
> 
> I want something that I can be confident won't be replaced again in two
> years because nobody noticed problems with the old API design or they're
> just feeling very NIH with their snazzy new feature.
> 
> Maybe then we won't end up with another in the { signal/sigaction,
> waitpid/wait4, select/pselect, poll/ppol,  msgrcv, mq_receive,
> io_getevents, aio_suspend/aio_return, epoll_wait, inotify read,
> kevent_get_events } collection -- or do you like having a maze of
> twisted interfaces, all subtly different and none supporting the
> complete feature set?
> 
> Good documentation giving enough detail to judge the design and an API
> that fits with the current POSIX API (at least, the parts that everybody
> agrees don't suck) goes a long way toward assuaging my fears that this
> won't just be another waste of effort, doomed to be replaced by the Next
> Great Thing (We Really Mean It This Time!) in unified event loop API
> design or whatever other interface somebody happens to be working on.
> 
> ---

OK, thank you for elaborating.

I suppose that I am more <choose one> {cynical, sarcastic,
practial, pragmatic}.  I don't have a crystal ball for 2 years
out and I don't know anyone who does.

IMO we do the best that we can given some human constraints
and probably some marketplace constraints (like ship something
instead of playing with it for 5 years before shipping it).


> This is made extraordinarily difficult by the fact kernel people don't
> even agree themselves on what APIs should look like anyway and Linus
> won't take a stand on the issue -- people with influence are
> simultaneously arguing things like:
> 
> - ioctls are bad because they aren't typesafe and you should use
> syscalls instead because they are typesafe
> 
> - ioctls are good, because they're much easier to add than syscalls,
> type safety can be supplied by the library wrapper, and syscalls are a
> (relatively) scarce resource, harder to wire up in the first place, and
> are more difficult to make optional or remove entirely if you decide
> they were a stupid idea.

Yes, I was recently part of that argument in Ottawa.

> - multiplexors are bad because they're too complex or not typesafe
> 
> - multiplexors are good because they save syscall slots or ioctl numbers
> and the library wrapper provides the typesafety anyway.

Multiplexors have already lost AFAIK.  Unless someone changes their
mind.  Which happens and will continue to happen.

> - instead of syscalls or ioctls, you should create a whole new
> filesystem that has a bunch of magic files that you read from and write
> to in order to talk to the kernel

Yep.  Some people like that one.  Not everyone.

> - filesystem interfaces are bad, because they're take more effort to
> write than a syscall or a ioctl and nobody seems to know how to maintain
> and evolve a filesystem-based ABI or make them easy to use outside of a
> fragile shell script (see: sysfs)

Ack.

> - that everything in those custom filesystems should ASCII strings and
> nobody needs an actual grammar describing how to parse them, we can just
> break userspace whenever we feel like it

sysfs requires one value per file.  Little parsing required.
But I don't know how to capture atomic values from N files with sysfs.

> - that everything in those custom filesystems should be C structs, and
> screw the shell scripts

Hm, I don't recall that one.

> - new filesystem metadata should be exposed by:
> 	- xattrs
> 	- ioctls
> 	- new syscalls
> 		or
> 	- named streams/forks/not-xattrs
>   and three out of four of these suggestions are completely wrong for
>   some critical reason
> 
> - meanwhile, the networking folks are doing everything via AF_NETLINK
> sockets instead of syscalls or ioctl or whatever, I guess because the
> network stack is what's most familiar to them

I sympathize with you on that one.  I don't care for netlink much
either.  To me it's still an ioctl, even though it is routable
and extensible.

> - and there's the usual arguments about typedefs verses bare struct
> names, #defines verses enums, returning 0 on success vs. 0 on failure,
> and lots of other piddly stupid stuff that somebody just needs to say
> "this is how it's done and no arguing" about.

That's all part of the open-source development process.  Sorry
you dislike it.

> Honestly, somebody with enough clout to make it stick needs to write out
> a spec describing what new kernel interfaces should look like and how
> they should fit in with existing interfaces.

I only know 2 people who could make it stick.

> It'd probably make Evgeniy's life easier if you could just point at the
> interface guidelines and say "you did this wrong" instead of random
> people telling him to change his design and random other people telling
> him to change it back.

I agree.  We went thru some of this at the kernel summit.
The ioctls dissent topic didn't really have many dissenters.
(That was a surprise to me.)

Anyway, thanks again for the additional details.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/