On Wed, 24 Jun 2009 16:52:06 -0700 (PDT) Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote: > > umm, yes please, I believe the patches should be split. And I'm still > > not seeing the justification for forcing CONFIG_EVENTFD onto all > > CONFIG_AIO users! > > Eventfd notifications became part of the AIO API (it's not even delivered > through a new syscall, from the AIO side - same existing aiocb struct and > io_submit syscall) once we merged it, That was a regression for existing embedded AIO users ;) > so IMHO (AIO && !EVENTFD) would be > similar to split AIO in AIO_READ and AIO_WRITE and have (AIO && !AIO_WRITE). > Considering that the kernel config, once you unleash the CONFIG_EMBEDDED > pandora box, allows you to select (AIO && !EVENTFD) w/out even a warning > about possible userspace breakages, this makes it rather a confusing > configuration if you ask me. Sure. But we do assume that one someone sets CONFIG_EMBEDDED, they know what they're doing. We prefer to give them maximum flexibility and foot-shooting ability. As long as the maintenance cost of doing so in each case is reasonable, of course. > It's not a biggie from the kernel side, just a few ugly errors wrappers > around functions. For me AIO (or whatever userspace visible kernel > subsystem) should select all the components that are part of the userspace > API, but my argument ends here. Sure, it's not a biggie either way. Doubtful if many tiny systems are using AIO anyway. Heck, lots of them are running 2.4.18... But from the general this-is-the-way-we-do-things POV, it's preferred that the two features be separable under CONFIG_EMBEDDED if poss. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
