poll() function

I found this piece of code in the tipc- config.c file that is present in the TIPC-UTILS downloads.

Code:

---


  pfd.fd = sk;
        pfd.events = ~POLLOUT;
    if ((poll(&pfd, 1, 3000) != 1) || !(pfd.revents & POLLIN))
                fatal("no reply detected from Netlink\n");

---

POLL returns 1. So, no problem there. But, the pfd.revents is set to "768" which drives the bitwise product to be 0. Hence, the program terminates. I read in the man pages that the revents parameter is set by the kernel based on the events that occur. What could be goin wrong here?

And interestingly, when i do this :

Code:

---


  pfd.fd = sk;
        pfd.events = POLLOUT;
    if ((poll(&pfd, 1, 3000) != 1) || !(pfd.revents & POLLIN))
                fatal("no reply detected from Netlink\n");

---

Which makes a little more sense, as POLLOUT stands for a "non-blocking write",the pfd.revents is returned as 4. Still doesnt help my cause though.

No, the first makes more sense to me. It's waiting for a reply, so this is I think it wants to happen:
1) "Netlink" responds, sends data on the file descriptor (socket?) - poll() then returns, with revents set to something that includes the POLLIN flag. (Success)
2) "Netlink" is AWOL, in which case poll() times out, and POLLIN is not set. (Failure)

Just passing POLLOUT to poll() guarentees that POLLIN will never get set. The only possible thing I see wrong with ~POLLOUT is that perhaps some flag _other_ than POLLIN is getting set before or early during the call to poll(), causing poll() to return prematurely. Since you said it return's 1, there is some flag getting set, but which ones?

On my system (post if yours differs) 768 = POLLWRNORM | POLLWRBAND... so, the socket could be written to. Not what I think we want. I'd try: pfd.events = POLLIN, myself, and not ~SOMEFLAG, as you get flags you don't want/need...

4, btw, (again, on my box) is POLLOUT. You requested to know if you can write (POLLOUT) and it said yes. If you need to post flags, save us all the trouble of digging through headers, and post the binary ORs of the flags, not the numerical value. (As it could vary box-to-box.)

Well, i read and re-read your message, but I am totally confused right now. I forgot to add, i actually experienced a kernel panic when i tried to run "tipc-config" for the first time.
I was advised to use the TIPC that ships as a part of the kernel instead of downloading the it from source-forge,http://tipc.sourceforge.net/download.html.. I did a kernel compilation again to include the required changes but, there seems to be some mismatch between the kernel, TIPC and the netlink. I really have no other option but to switch to 2.6.16 version of the kernel and use the TIPC 1.6 version that is meant for 2.6.16.