Date: Tue, 20 Jun 2000 09:49:53 -0700 From: "'Alfred Perlstein'" <bright@wintelcom.net> To: Christopher Sedore <cmsedore@maxwell.syr.edu> Cc: "'arch@freebsd.org'" <arch@freebsd.org> Subject: Re: MORE: Re: kblob discussion. Message-ID: <20000620094953.R17420@fw.wintelcom.net> In-Reply-To: <D006CCEB462FD411976100A0C9B413A139E5BB@EXCHANGE>; from cmsedore@maxwell.syr.edu on Tue, Jun 20, 2000 at 12:43:34PM -0400 References: <D006CCEB462FD411976100A0C9B413A139E5BB@EXCHANGE>
next in thread | previous in thread | raw e-mail | index | archive | help
* Christopher Sedore <cmsedore@maxwell.syr.edu> [000620 09:43] wrote: > > [...] > > >Last night I started thinking about making kblob more flexible, > >here's the problem I came across: > > > >All the papers that have been given to me make sure that once a > >0 copy buffer is shared across subsystems it is immutable until > >the data it's loaned has gone back to no references except by > >the user process. > > > >Not following the above system is _wrong_. > > I'm not sure I would put that level of emphasis on _wrong_. It deserves > that level of emphasis if it can cause kernel state (or other system) > corruption (which should be reason for _wrong_, though I'd call this a > problem with implementation more than anything else). If the > user/application can only screw up its own data/connections (in the sense of > undefined, possibly random data being sent/written), then why not state that > modifying the data causes undefined results (including TCP checksum errors, > whatever else) and let the programmer beware. Because it puts undue burden on the rest of the kernel to cope with a user's access to internals. What happens if we are using some sort of checksum offloading chipset or encryption/compression system that can't stand the data being ripped out from under it. What's the point of recalculating the checksum of a packet when we know it shouldn't have changed? It's wrong. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000620094953.R17420>