From owner-freebsd-arch@FreeBSD.ORG  Mon May  5 13:56:17 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 766A21065677;
	Mon,  5 May 2008 13:56:17 +0000 (UTC) (envelope-from jhb@freebsd.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 5FBC88FC26;
	Mon,  5 May 2008 13:56:17 +0000 (UTC) (envelope-from jhb@freebsd.org)
Received: from zion.baldwin.cx (unknown [208.65.91.234])
	by elvis.mu.org (Postfix) with ESMTP id EB2081A4D80;
	Mon,  5 May 2008 06:56:16 -0700 (PDT)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-arch@freebsd.org
Date: Mon, 5 May 2008 09:30:17 -0400
User-Agent: KMail/1.9.7
References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua>
	<20080505074924.GF1181@hoeg.nl>
In-Reply-To: <20080505074924.GF1181@hoeg.nl>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200805050930.18114.jhb@freebsd.org>
Cc: Kostik Belousov <kostikbel@gmail.com>, Ed Schouten <ed@80386.nl>,
	arch@freebsd.org
Subject: Re: Per-open file private data for the cdevs
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2008 13:56:17 -0000

On Monday 05 May 2008 03:49:24 am Ed Schouten wrote:
> * Kostik Belousov <kostikbel@gmail.com> wrote:
> > Since the review for the clone-at-open patch (fdclone) posted some time
> > ago mostly says that it would be better to implement per-file private
> > data instead, I produced the patch along this line,
>
> I also thought about this. The new TTY layer I'm developing needs the
> following patch to implement /dev/ptmx and /dev/ptyXX compatibility:
>
> --- sys/fs/devfs/devfs_vnops.c
> +++ sys/fs/devfs/devfs_vnops.c
> @@ -800,9 +800,8 @@
>  	if(fp == NULL)
>  		return (error);
>  #endif
> -	KASSERT(fp->f_ops == &badfileops,
> -	     ("Could not vnode bypass device on fdops %p", fp->f_ops));
> -	finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f);
> +	if (fp->f_ops == &badfileops)
> +		finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f);
>  	return (error);
>  }
>
> This way drivers can just implement d_fdopen() and call finit() there.
> It's probably not as nice as having the per-fdesc stuff inside devfs
> itself, but I'm not sure the amount of drivers that needs this makes it
> worth adding it to devfs itself.

Many drivers currently do devfs cloning soley to get per-file data.  Other 
OS's (such as WinXP and Linux) already provide facilities for drivers to set 
per-file data as well.  This is definitely very useful.

-- 
John Baldwin