Alexei, That's build time check, and it solves the problem with building on 2.4.x kernels. I'm proposing the way we could detect the kernel version at the _build_ time and avoid compiling against non-existing API: let preprocessor detect version and replace epoll code with some message that "we have failed to find appropriate api during build, please rebuild us on 2.6.x kernel!" if necessary.
I don't know how to make a runtime check yet, and runtime check is really nice-to-have feature that does not break anything seriously. In contrary, lack of build-time check will lead to failure while compiling on 2.4. Thanks, Aleksey. On 10/12/07, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > Alexei, > > I fully support your course of taking advantage of new OS features. > Who now recalls what DOS/4GW [1] is? > > Your patch is a bit confusing. Do you intend to add a runtime check or > a compile-time one? The compile time check is much simpler, but in > this case #error looks much more suitable then print. The runtime > check requires runtime comparison, and it will work with pre-built > binaries. > > Thanks. > > [1] http://en.wikipedia.org/wiki/DOS4GW > > On 10/12/07, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > > Alexei, > > > > Thanks! The patch was applied OK. > > > > So now we have two main issues: > > 1. We need to detect the kernel at the build time and prevent > > breaking the compilation due to lack of epoll kernel API. > > 2. We need to detect the kernel at the run time and switch on > > EpollSelectorProviderImpl. > > > > For (1) I propose to include <linux/version.h> and then: > > > > #if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0)) > > // do some epoll activity here > > #else > > printf("Error: epoll facility is not implemented, please rebuild on > > newer kernel\n"); > > #endif > > > > If it sounds right, I will go ahead and make the patch for it. > > > > Thanks, > > Aleksey. > > > > On 10/11/07, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > FYI yesterday I've committed Aleksey's patch for HARMONY-4879. > > > However, I afraid in spite of the fact that new epoll-based provider > > > is disabled by default corresponding native sources simply cannot be > > > compiled if kernel's version is less than 2.5.44 because of unresolved > > > references to epoll_ctl. According to manual: " epoll(7) is a new API > > > introduced in Linux kernel 2.5.44. Its interface should be finalized > > > in Linux kernel 2.5.66." Thus, it looks like we should detect kernel > > > version during the build time via "uname --kernel-release" or > > > something like it. Did I miss something? > > > > > > Thanks, > > > Alexei > > > > > > 2007/10/11, Tim Ellison <[EMAIL PROTECTED]>: > > > > Apologies for the late response ... still catching up. > > > > > > > > Aleksey Shipilev wrote: > > > > > Hi, Paulex, > > > > > > > > > >> Amazing work, Aleksey! > > > > > Thanks, I was waiting for it :) > > > > > > > > > >> Seems RI[1] is adapative here, i.e., use epoll when 2.6 kernel is > > > > >> detected, > > > > >> is it possible for Harmony to implement in similar way? Of course > > > > >> this can > > > > >> be further work and doesn't necessary to prevent this patch to be > > > > >> applied. > > > > > I believe it could be done in launcher which could detect the kernel > > > > > where Harmony starts and then instantiate right SelectorProvider. I > > > > > don't know the details for Harmony launcher though, it's just the > > > > > guess. This is in some way contrary with portlib implementation - we > > > > > could even implement optimized versions for Selector for Windows and > > > > > Linux separately. > > > > > > > > The launcher would not be the right place to detect the kernel version, > > > > since we would want this to work in all places that the NIO code is > > > > used, even when people are not using our launcher. > > > > > > > > Regards, > > > > Tim > > > > > > > > -- > With best regards, > Alexei, > ESSD, Intel >
