From owner-freebsd-arch@FreeBSD.ORG  Wed Jun  9 14:28:01 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id B1D4D16A4CE; Wed,  9 Jun 2004 14:28:01 +0000 (GMT)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id A745343D2F; Wed,  9 Jun 2004 14:28:01 +0000 (GMT)
	(envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id D8A6F5C867; Wed,  9 Jun 2004 07:27:56 -0700 (PDT)
Date: Wed, 9 Jun 2004 16:27:56 +0200
From: Maxime Henrion <mux@freebsd.org>
To: Brian Feldman <green@freebsd.org>
Message-ID: <20040609142756.GU9228@elvis.mu.org>
References: <53993.1086779790@critter.freebsd.dk>
	<20040609124308.GC11475@green.homeunix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040609124308.GC11475@green.homeunix.org>
User-Agent: Mutt/1.4.2.1i
cc: arch@freebsd.org
cc: Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject: Re: dev_t / udev_t confusion ?
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
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: Wed, 09 Jun 2004 14:28:01 -0000

Brian Feldman wrote:
> On Wed, Jun 09, 2004 at 01:16:30PM +0200, Poul-Henning Kamp wrote:
> > [...]
> > The change proposed is more or less to do:
> > 	s/dev_t/struct cdev */
> > 	s/udev_t/dev_t/
> > over all the kernel sources (366 files or so).
> > [....]
> 
> One yes vote, please.  The dev_t structure is not treated as opaque,
> so as long as people are going to->dereference it, it deserves to be
> a struct *.

This reflects what I think perfectly.

Cheers,
Maxime