"Mike A. Harris" wrote:
> An invalid TCP/IP packet however does not permanently destroy the
> ethernet card, no matter how badly it is screwed up. Nor does it
> fry anything else.
>
> IMHO, if something violates a standard in some way in kernel, it
> should be fixed if for no other reason than that. If something
> is a potentially dangerous, and lesser used feature that is added
> to the kernel, it should be CONFIG_SOMETHING so that it isn't
> there if it isn't needed.
And what about video cards? You can easily program the clocks to a value that
is likely to destroy or damage your monitor. Intelligent monitors handle this.
Old ones get smokey. If the hardware allows destructive commands to destroy it,
you need to support a different manufacturer.
Notwithstanding, I'm sure there's a lot of other hardware that allows you to
destroy it. How much effort should be spent to ensure such silliness isn't
allowed?
After watching this thread for a while, I have to stand against adding code.
Perhaps I don't understand precisely what Andre is attending to, but I get the
gist of it. If it's something that can be patched up...well...do it and we'll
all go on happily with a new kernel version not even knowing or caring that
something changed. If it can't be fixed, why waste time running around in
circles?
-d
-- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."
--------------8B496A090CA528A2C13F1574 Content-Type: text/x-vcard; charset=us-ascii; name="david.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Ford Content-Disposition: attachment; filename="david.vcf"
begin:vcard n:Ford;David x-mozilla-html:TRUE org:<img src="http://www.kalifornia.com/images/paradise.jpg"> adr:;;;;;; version:2.1 email;internet:david@kalifornia.com title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
--------------8B496A090CA528A2C13F1574--
- 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/
