From owner-svn-src-all@FreeBSD.ORG Sat Dec 20 17:07:19 2008 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D89431065677; Sat, 20 Dec 2008 17:07:19 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD728FC14; Sat, 20 Dec 2008 17:07:19 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id mBKH7HGJ006511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Dec 2008 09:07:18 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <494D2603.9000001@FreeBSD.org> Date: Sat, 20 Dec 2008 09:06:11 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Kostik Belousov References: <200812192020.mBJKKEIo081792@svn.freebsd.org> <494C097C.1020604@FreeBSD.org> <20081220115505.GZ2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20081220115505.GZ2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "David E. O'Brien" Subject: Re: svn: head/usr.sbin/burncd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2008 17:07:20 -0000 Kostik Belousov wrote: > On Fri, Dec 19, 2008 at 12:52:12PM -0800, Maxim Sobolev wrote: >> Should not it be better to implement this on the kernel side when the >> device is closed abruptly? > The state that is kept is not accumulated on any particular filedescriptor, > it is associated with the physical state of the device. > > Therefore, I think that kernel shall not be charged with cleanup, and > userspace calls should deal with resetting device back to the pristine > state. It may not be associated with any particular descriptor, still you can count number of opens for write compared to count of closes in the kernel. And it should be trivial to track when this number goes down to 0 and clean up any leftover mess. Check dev/md/md.c for example, function g_md_access(). -Maxim