According to that criterium you can drop a LOT of code, e.g. not fixing rare
races that only happen if you do some unlikely thing ("don't do that then")
Basically it's not the kernel's business to try to outguess the semantics I'm
putting on IP-addresses, so it's a bugfix.
>
> 2. Its on a common code path. Sum the number of times that path is taken
> by the number of users of Linux versus the 3 or 4 who actually need it.
mm, it's an ARP patch. If your ARP is not being done rarely, something is
very wrong in your setup. So it might be commong code for ARP, but the ARP
code itself isn't very common, so who cares ? (Does answering arp even
belong in the kernel ?)
Also, I usually have more network cards than computers (network cards are
cheap, computers arent't). And I have in fact been trying to determine if
a network card was broken or not on a single computer with a loopback cable,
being very surprised with the results. That is also lost time that should be
counted in an argument like this.
>
> There isnt anything wrong with the patch, its just not relevant to the
> userbase as a whole and its on a regularly executed path
I'm sorry to see you falling for the:
"it's rarely usefull, so it's not worth it"
that I see far too often on this list.
UNIX is such a nice system since it tries to cover most corner cases. So when
you try to do something "uncommon", it tends to work.
Sure, keeping the common code path fast is very important, and in that case
you should compare time loss/utility. But that hardly seems the case here, so
I would vote going for correctness
Ton, hoping you will reconsider.
-- The Linux WordPerfect sucks dead bunnies through a straw, and you don't want to know how the bunnies died. graydon@lara.on.ca (Graydon) in rec.arts.sf.written .- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/