From owner-freebsd-hackers@FreeBSD.ORG  Mon Jun 13 21:02:40 2005
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: freebsd-hackers@freebsd.org
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F17AD16A41C;
	Mon, 13 Jun 2005 21:02:39 +0000 (GMT)
	(envelope-from viro@www.linux.org.uk)
Received: from parcelfarce.linux.theplanet.co.uk
	(parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7418843D55;
	Mon, 13 Jun 2005 21:02:39 +0000 (GMT)
	(envelope-from viro@www.linux.org.uk)
Received: from viro by parcelfarce.linux.theplanet.co.uk with local (Exim 4.43)
	id 1Dhw5v-00080Z-T5; Mon, 13 Jun 2005 22:03:43 +0100
Date: Mon, 13 Jun 2005 22:03:43 +0100
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Scott Long <scottl@samsco.org>
Message-ID: <20050613210343.GL29811@parcelfarce.linux.theplanet.co.uk>
References: <Pine.GSO.4.43.0506131332380.23852-100000@sea.ntplx.net>
	<42ADC762.6010801@elischer.org>
	<20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org>
	<20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42ADD6AC.3060505@samsco.org>
User-Agent: Mutt/1.4.1i
Sender: Al Viro <viro@www.linux.org.uk>
Cc: Daniel Eischen <deischen@freebsd.org>,
	Julian Elischer <julian@elischer.org>,
	Apache Xie <apachexm@hotmail.com>, freebsd-hackers@freebsd.org
Subject: Re: contigmalloc() and mmap()
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2005 21:02:40 -0000

On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
> >Lot's of driver use file->private to get at per-device data easily,
> >but that's just a shortcut.
> 
> Ok, I thought that you were talking about per-process data being in the
> file descriptor.

Can't be done.

FWIW, the main difference between FreeBSD and Linux in that area is that
*all* files are vnode-based - we simply have pseudo-filesystems for
pipes and sockets.  So we have a single method (->release()) instead of
multi-level scheme FreeBSD uses and unlike ->d_close() it does see
struct file * (what with being a counterpart of ->fo_close()).


While we are at it, is there any reason for passing struct thread * to
->fo_close() and then to vop_close()?  <greps>

	1) out of ->fo_close() instances only svr4_soo_close(), kqueue_close()
and vn_closefile() look at the struct thread * in question.  svr4_soo_close()
panics if td is NULL (i.e. pass such descriptor in SCM_RIGHTS, make sure
that it's garbage-collected by unp_gc() and watch closef(fp, NULL) panic the
box).
	2) vn_closefile() ends up passing it to VOP_CLOSE().  vop_close
instances mostly ignore it or pass to other such instances.  However, some
do not - e.g. coda_close() panics if it gets NULL ap->a_td due to
    error = venus_close(vtomi(vp), &cp->c_fid, flag, cred, td->td_proc);

AFAICS, the only reason for passing that pointer is kludge with controlling
tty handling in spec_close() (or devfs_close() in -HEAD).  And it doesn't
look right, even ignoring the ugliness...