From owner-freebsd-arch Tue Jun 20 9:49:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5DC2937BBBF for ; Tue, 20 Jun 2000 09:49:55 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5KGnrF17108; Tue, 20 Jun 2000 09:49:53 -0700 (PDT) Date: Tue, 20 Jun 2000 09:49:53 -0700 From: "'Alfred Perlstein'" To: Christopher Sedore Cc: "'arch@freebsd.org'" Subject: Re: MORE: Re: kblob discussion. Message-ID: <20000620094953.R17420@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from cmsedore@maxwell.syr.edu on Tue, Jun 20, 2000 at 12:43:34PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Christopher Sedore [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