[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: IP changes in 2.3.4x make things wierd?
> It's not meant to, IP_RECVERR works differently.  You set the
> MSG_ERRQUEUE flag in a recvmsg call and this is how you obtain
> the IP_RECVERR descriptor blocks.

What if I have hundreds of sockets to check? The old way select/poll
let me know which ones to read/recv from and I could take it from
there. Because, select/poll do no return here, I have to wait for a
timeout then try recvmsg on each one -- which slows the process down.

Am I doing this wrong?

> Look folks. All of these arguments are going on deaf ears, because
> the old behavior is not coming back without a solution to the problem
> which was solved. The problem we have fixed is several orders of
> magnitude _worse_ than hostname or username lookups stalling for 30
> seconds on a misconfigured system.

I'm not going to get involved in this either way, I don't have the
experience -- but I would like to know how I can make existing code
work with the new kernels (if possible).

> As for all the "distribution X is broken now" arguments. Have any
> of you tried to use RARP with 2.3.x using the tools shipped by
> any vendor in any release? It won't work, because we tossed rarp
> from the kernel because it belongs in user space. Yet I hear nobody
> crying about that.

No, people do bitch about RARP from time to time, just as I've heard
complaints about proxy ARP being broken.

> 2.4.x is about moving on and fixing the problems of our past, not
> being stuck with them forever.

I completely agree -- I just want to know what there exists a recipe
for fixing existing applications that depend on the old behavior if
at all possible. I'm more than happy to document this for other people
if someone can explain it to me.

> Someone mentioned that Solaris deals with dead NIS servers etc.
> It would be interesting for someone to find out (with strace or
> something similar) how they detect the NIS server being down,
> I would not be surprised if they used a timeout mechanism of
> some sort.

I can probably do this tomorrow if I can figure out something simple
to truss -- I don't want to do it from remote in case bad things
happen. Do you have in mind what you want truss'd -- or will
something like "main(){getpwent()};" suffice?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.087 / U:2.152 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site