From owner-freebsd-arch Tue Jun 20 9:43:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id DD65937BBBD for ; Tue, 20 Jun 2000 09:43:53 -0700 (PDT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id MAA04125; Tue, 20 Jun 2000 12:43:50 -0400 (EDT) Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 12:43:45 -0400 Message-ID: From: Christopher Sedore To: "'Alfred Perlstein'" , "'arch@freebsd.org'" Subject: RE: MORE: Re: kblob discussion. Date: Tue, 20 Jun 2000 12:43:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [...] >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. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message