On Fri, Feb 16, 2007 at 08:54:11PM -0800, Ray Lee ([EMAIL PROTECTED]) wrote: > (This is probably why, by the way, most people are staying silent on > your excellent kevent work. The kernel side is, in some ways, the easy > part. It's getting an interface that will handle all users [ users == > producers and consumers of kevents ], that is the hard bit.)
Kevent interface was completely changed 4 (!) times for the last year after kernel developers request without any damage to its kernel part. > Or, let me put it yet another way: How do you prove to the rest of us > that you, or Ingo, or whomever, are not building another dnotify? (Maybe > you're smart enough in this problem space that you know you're not -- > that's actually the most likely possibility. But you still have to prove > it to the rest of us. Sucks, I know.) I only want to say that when system is designed correctly there is no problem to change interface (yes, I again said 'to change' just because I hope everyone understand that I'm talking about time when system is not yet committed to the tree). Btw, dnotify had problems in its design highlighted at inotify statrt - mainly that watchers were not attached to inode. It is right now the time to ask users what interface they expect from AIO - so I asked Linus and proposed three different ones, two of them were designed in a way that user would not even know that some allocation/freeing was done - and as a result I got 'you suck' response exactly the same as was returned on the first syslet release - just _anly_ fscking _just_ because it had ugly interface. > > Situations when system is designed from interface down to system ends up > > with one thread per IO and huge limitations on how system is going to be > > used at all. > > The other side is you start from the goal in mind and get Ingo's state > machines with loops and conditionals and marmalade in syslets which > appear a bit baroque and overkill for the majority of us userspace folk. Well, I designed kevent AIO in the similar way, but it has even more complex one which is built on top of internal page population functions. It is complex a bit, but it works fast. And it works with any type (if I would not be lazy and implement bindings) of AIO. Interface of syslets is not perfect, but it can be changed (I said it again? I think we all understand what I mean by that already) trivially right now (before it is included) - it is not the way to throw thing just because it has bad interface which can be extended in a moment. > (No offense intended to Ingo, he's obviously quite a bit more conversant > on the needs of high speed interfaces than I am. However, I suspect I > have a bit more clarity on what us normal folk would actually use, and > kernel driven FSMs ain't it. Userspace often makes a lot of contextual > decisions that I would absolutely *hate* to write and debug as a state > machine that gets handed off to the kernel. I'll happily take a 10% hit > in efficiency that Moore's law will get me back in a few months, instead > of spending a bunch of time debugging difficult heisenbugs due to the > syslet FSM reading a userspace variable at a slightly different time > once in a blue moon. OTOH, I'm also not Oracle, so what do I know?) > > The truth of this lies somewhere in the middle. It isn't kernel driven, > or userspace interface driven, but a tradeoff between the two. > > So: > > > Userspace_API_is_the_ever_possible_last_thing_to_ever_think_about. > > Period > > Please listen to those of us who are saying that this might not be the > case. Maybe we're idiots, but then again maybe we're not, okay? > Sometimes the API really *DOES* change the underlying implementation. It is exactly the time to say what interface sould be good. System is almost ready - it is time to make it looks cool for users. > Ray -- Evgeniy Polyakov - 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/