From owner-freebsd-arch@FreeBSD.ORG Sun May 4 04:01:10 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03F11065672 for ; Sun, 4 May 2008 04:01:10 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id F02678FC0A for ; Sun, 4 May 2008 04:01:10 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id m4441AZr010465; Sat, 3 May 2008 21:01:10 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.1/Submit) id m4441ARk010463; Sat, 3 May 2008 21:01:10 -0700 (PDT) (envelope-from obrien) Date: Sat, 3 May 2008 21:01:10 -0700 From: "David O'Brien" To: Jeremie Le Hen Message-ID: <20080504040110.GC94985@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Jeremie Le Hen , freebsd-arch@FreeBSD.org References: <20080427012416.GA9817@dragon.NUXI.org> <20080502070147.GE74500@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080502070147.GE74500@obiwan.tataz.chchile.org> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2008 04:01:11 -0000 On Fri, May 02, 2008 at 09:01:47AM +0200, Jeremie Le Hen wrote: > Index: sys/conf/kern.pre.mk > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.pre.mk,v > retrieving revision 1.97 > diff -u -p -r1.97 kern.pre.mk > --- sys/conf/kern.pre.mk 2 Feb 2008 19:55:28 -0000 1.97 > +++ sys/conf/kern.pre.mk 29 Mar 2008 14:06:45 -0000 > @@ -3,10 +3,7 @@ > # Part of a unified Makefile for building kernels. This part contains all > # of the definitions that need to be before %BEFORE_DEPEND. > > -SRCCONF?= /etc/src.conf > -.if exists(${SRCCONF}) > -.include "${SRCCONF}" > -.endif > +.include I may not be seeing it - why do you need this change? From owner-freebsd-arch@FreeBSD.ORG Sun May 4 17:31:51 2008 Return-Path: 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 B07BD106566B for ; Sun, 4 May 2008 17:31:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 68F088FC21 for ; Sun, 4 May 2008 17:31:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jshj4-000AWi-Lq for arch@freebsd.org; Sun, 04 May 2008 20:10:15 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m44HA6tb012534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 4 May 2008 20:10:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m44HA2uJ034212 for ; Sun, 4 May 2008 20:10:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m44HA2VV034211 for arch@freebsd.org; Sun, 4 May 2008 20:10:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 May 2008 20:10:02 +0300 From: Kostik Belousov To: arch@freebsd.org Message-ID: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nWESmH2uLuaSkt2F" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: f2683d8df775da069012ccac6e6e6321 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2772 [May 04 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Subject: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2008 17:31:51 -0000 --nWESmH2uLuaSkt2F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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, The patch does not change the cdevsw ABI, instead, three new functions nt devfs_get_cdevpriv(void **datap); int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); void devfs_clear_cdevpriv(void); are provided for manipulation of the per-file private data. devfs_set_cdevpriv assigns the priv as private data for the file descriptor which is used to initiate currently performed driver operation. dtr is the function that will be called when either the last refernce to the file goes away or devfs_clear_cdevpriv is called. devfs_get_cdevpriv is the obvious accessor. devfs_clear_cdevpriv allows to clear the private data for the still open file. The synchronization of the cdev data and file private data is left to the driver code, I did not found any generic helper mechanism that could be useful there. Patch: http://people.freebsd.org/~kib/misc/fdpriv.1.patch Dumb driver that shows the basic usage of the proposed KPI: http://people.freebsd.org/~kib/misc/fpclone.c Previous version of the patch was tested by Peter Holm. --nWESmH2uLuaSkt2F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgd7eoACgkQC3+MBN1Mb4h7+gCglhkTt7vXzC9prLACEuuEAS2Z yzMAoKq8kKbU7J91CuasevEeFscxffY8 =accO -----END PGP SIGNATURE----- --nWESmH2uLuaSkt2F-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 07:49:25 2008 Return-Path: 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 697B01065679 for ; Mon, 5 May 2008 07:49:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 22AFE8FC2D for ; Mon, 5 May 2008 07:49:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5DBCD1CC16; Mon, 5 May 2008 09:49:24 +0200 (CEST) Date: Mon, 5 May 2008 09:49:24 +0200 From: Ed Schouten To: Kostik Belousov Message-ID: <20080505074924.GF1181@hoeg.nl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bf1m62tZozKFsi1s" Content-Disposition: inline In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 07:49:25 -0000 --Bf1m62tZozKFsi1s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time a= go > 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 =3D=3D NULL) return (error); #endif - KASSERT(fp->f_ops =3D=3D &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 =3D=3D &badfileops) + finit(fp, fp->f_flag, DTYPE_VNODE, dev, &devfs_ops_f); return (error); } =20 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. --=20 Ed Schouten WWW: http://80386.nl/ --Bf1m62tZozKFsi1s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgevAQACgkQ52SDGA2eCwWzGwCeIFl/ThiskEJuMlsvtt5REEfs nrYAn1xlNZlcIF1ca7km6/+ye9uH8qjG =u/r8 -----END PGP SIGNATURE----- --Bf1m62tZozKFsi1s-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 08:40:55 2008 Return-Path: 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 2F7121065672 for ; Mon, 5 May 2008 08:40:55 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id B24128FC12 for ; Mon, 5 May 2008 08:40:54 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0801545E5C; Mon, 5 May 2008 10:14:01 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 45BAB45DD8; Mon, 5 May 2008 10:13:56 +0200 (CEST) Date: Mon, 5 May 2008 10:13:55 +0200 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20080505081355.GB1628@garage.freebsd.pl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 08:40:55 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 04, 2008 at 08:10:02PM +0300, Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time a= go > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, >=20 > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. >=20 > devfs_set_cdevpriv assigns the priv as private data for the file descript= or > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. >=20 > devfs_get_cdevpriv is the obvious accessor. >=20 > devfs_clear_cdevpriv allows to clear the private data for the still > open file. >=20 > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. >=20 > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch >=20 > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c >=20 > Previous version of the patch was tested by Peter Holm. Can you see if my OSD (Object-Specific-Data) KPI can be useful here? I've it only in perforce for now, but I think it's what you are looking for. I use it for jails and threads currently, but it is trivial to use it for other objects. Take a look: http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/pjd/zfs/sys= /sys/osd.h&REV=3D3 When your code is loaded/initialized you call: static int slot; slot =3D osd_file_register(mod_destroy); Where mod_destroy is a function which knows how to free your private data. On unload: osd_file_deregister(slot); Now, when you want to attach private data: error =3D osd_file_set(fp, slot, ptr_to_your_data); You can get it with: ptr =3D osd_file_get(fp, slot); --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIHsHDForvXbEpPzQRAkXSAKCQ3VsE5whVmlrjXgTVv7w122YL0QCg4D2B /KoYnlPwSlK0gB2U20HVJew= =Th9n -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 11:07:02 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35390106564A for ; Mon, 5 May 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 06C468FC17 for ; Mon, 5 May 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m45B71RQ070642 for ; Mon, 5 May 2008 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m45B71dG070638 for freebsd-arch@FreeBSD.org; Mon, 5 May 2008 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2008 11:07:01 GMT Message-Id: <200805051107.m45B71dG070638@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 11:07:02 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:56:17 2008 Return-Path: Delivered-To: freebsd-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 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 , Ed Schouten , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:56:17 2008 Return-Path: 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 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 , Ed Schouten , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:56:18 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54966106564A for ; Mon, 5 May 2008 13:56:18 +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 3EA028FC13 for ; Mon, 5 May 2008 13:56:18 +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 AD37E1A4D84; Mon, 5 May 2008 06:56:17 -0700 (PDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 5 May 2008 09:39:42 -0400 User-Agent: KMail/1.9.7 References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805050939.42425.jhb@freebsd.org> Cc: Kostik Belousov 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 13:56:18 -0000 On Sunday 04 May 2008 01:10:02 pm Kostik Belousov 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, > > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. I like this very much and will use it instead of devfs cloning in ipmi(4) so we can use ipmievd when it is committed. IWBN if there was a more automated way of handling the unload race, for example if destroy_dev() could somehow clear all the per-open fd data. That may not be easily feasible, however. (In theory each cdev could have a list of "attached" 'struct file' objects that it updates in VOP_CLOSE() and for a destroy dev it detaches all the private data after marking the cdev with a bad/null cdevsw, however, that would bloat 'struct file' with at least one more pointer (if not two).) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:21:02 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DFD51065670; Mon, 5 May 2008 14:21:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id AC8478FC17; Mon, 5 May 2008 14:21:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jt1Yp-000Hg3-FA; Mon, 05 May 2008 17:21:00 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45EKuLv063904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 17:20:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45EKqdT009653; Mon, 5 May 2008 17:20:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m45EKpu0009652; Mon, 5 May 2008 17:20:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 May 2008 17:20:51 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080505142051.GS18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vb/P15UJLYd8hx0q" Content-Disposition: inline In-Reply-To: <200805050939.42425.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 717fb1dce93df3d9117221529acf11a8 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2780 [May 05 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 14:21:02 -0000 --vb/P15UJLYd8hx0q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov 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, > > > > The patch does not change the cdevsw ABI, instead, three new functions > > nt devfs_get_cdevpriv(void **datap); > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > void devfs_clear_cdevpriv(void); > > are provided for manipulation of the per-file private data. > > > > devfs_set_cdevpriv assigns the priv as private data for the file descri= ptor > > which is used to initiate currently performed driver operation. dtr > > is the function that will be called when either the last refernce to > > the file goes away or devfs_clear_cdevpriv is called. > > > > devfs_get_cdevpriv is the obvious accessor. > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > open file. > > > > The synchronization of the cdev data and file private data is left > > to the driver code, I did not found any generic helper mechanism that > > could be useful there. > > > > Patch: > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > Dumb driver that shows the basic usage of the proposed KPI: > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > Previous version of the patch was tested by Peter Holm. >=20 > I like this very much and will use it instead of devfs cloning in ipmi(4)= so=20 > we can use ipmievd when it is committed. IWBN if there was a more automa= ted=20 > way of handling the unload race, for example if destroy_dev() could someh= ow=20 > clear all the per-open fd data. That may not be easily feasible, however= . =20 > (In theory each cdev could have a list of "attached" 'struct file' object= s=20 > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the= =20 > private data after marking the cdev with a bad/null cdevsw, however, that= =20 > would bloat 'struct file' with at least one more pointer (if not two).) Probably, I shall clarify that the dtr is called when the last reference to the struct file going away, unless the priv data is already cleared by the call to the devfs_clear_cdevpriv. The problem with VOP_CLOSE() is that some actions (like forced unmount or revoke) may cause less calls to the devfs_close then the files pointing to the cdev. Your proposal basically means that we need, besides the normal pointers file->vnode->cdev, have the reverse path cdev->file. I think this is ugly and better be handled by the fdrop(). --vb/P15UJLYd8hx0q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgfF8IACgkQC3+MBN1Mb4gqLwCg2slMEG4C9SK/IreydPLeJXu7 5a8AoOTYYIaq86Af9BRpmh/d91tz+RPp =/tM+ -----END PGP SIGNATURE----- --vb/P15UJLYd8hx0q-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:56:41 2008 Return-Path: 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 E1F381065672; Mon, 5 May 2008 14:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 70B818FC15; Mon, 5 May 2008 14:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jt27M-000KhX-2W; Mon, 05 May 2008 17:56:40 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45EuacF065488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 17:56:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45EuWYa010614; Mon, 5 May 2008 17:56:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m45EuVk7010613; Mon, 5 May 2008 17:56:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 May 2008 17:56:31 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zCRYTTfePT7f+iLT" Content-Disposition: inline In-Reply-To: <20080505081355.GB1628@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 44556c58cf61beb49de4494ee559d59c X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2780 [May 05 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 14:56:42 -0000 --zCRYTTfePT7f+iLT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 10:13:55AM +0200, Pawel Jakub Dawidek wrote: > On Sun, May 04, 2008 at 08:10:02PM +0300, Kostik Belousov 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, > >=20 > > The patch does not change the cdevsw ABI, instead, three new functions > > nt devfs_get_cdevpriv(void **datap); > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > void devfs_clear_cdevpriv(void); > > are provided for manipulation of the per-file private data. > >=20 > > devfs_set_cdevpriv assigns the priv as private data for the file descri= ptor > > which is used to initiate currently performed driver operation. dtr > > is the function that will be called when either the last refernce to > > the file goes away or devfs_clear_cdevpriv is called. > >=20 > > devfs_get_cdevpriv is the obvious accessor. > >=20 > > devfs_clear_cdevpriv allows to clear the private data for the still > > open file. > >=20 > > The synchronization of the cdev data and file private data is left > > to the driver code, I did not found any generic helper mechanism that > > could be useful there. > >=20 > > Patch: > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >=20 > > Dumb driver that shows the basic usage of the proposed KPI: > > http://people.freebsd.org/~kib/misc/fpclone.c > >=20 > > Previous version of the patch was tested by Peter Holm. >=20 > Can you see if my OSD (Object-Specific-Data) KPI can be useful here? > I've it only in perforce for now, but I think it's what you are looking > for. I use it for jails and threads currently, but it is trivial to use > it for other objects. Take a look: >=20 > http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/pjd/zfs/s= ys/sys/osd.h&REV=3D3 >=20 > When your code is loaded/initialized you call: >=20 > static int slot; >=20 > slot =3D osd_file_register(mod_destroy); >=20 > Where mod_destroy is a function which knows how to free your private > data. On unload: >=20 > osd_file_deregister(slot); >=20 > Now, when you want to attach private data: >=20 > error =3D osd_file_set(fp, slot, ptr_to_your_data); >=20 > You can get it with: >=20 > ptr =3D osd_file_get(fp, slot); This is a nice feature, but I think that privdata is a fundamental internal operation of the kernel, and it would be wrong to use the OSD. In fact, the object we shall attach OSD to is the struct file, and we would need to export the struct file to the cdevsw operations. Since it both breaks current ABI and complicates the future changes to the struct file, I would much prefer to not engage this route. --zCRYTTfePT7f+iLT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgfIB8ACgkQC3+MBN1Mb4ihBACeJwZ/qjNycP+iQNIfM8otx5y7 cuYAoMNYcHQkOChjycGdnaX88udAxm8v =DBHl -----END PGP SIGNATURE----- --zCRYTTfePT7f+iLT-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 18:26:59 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C00106566C for ; Mon, 5 May 2008 18:26:59 +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 CBB928FC16 for ; Mon, 5 May 2008 18:26:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 3C0051A4D80; Mon, 5 May 2008 11:26:59 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m45IQjdo069338; Mon, 5 May 2008 14:26:45 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Mon, 5 May 2008 11:56:14 -0400 User-Agent: KMail/1.9.7 References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> <20080505142051.GS18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080505142051.GS18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805051156.14706.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 05 May 2008 14:26:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7035/Mon May 5 13:47:07 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 18:27:00 -0000 On Monday 05 May 2008 10:20:51 am Kostik Belousov wrote: > On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov 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, > > > > > > The patch does not change the cdevsw ABI, instead, three new functions > > > nt devfs_get_cdevpriv(void **datap); > > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > void devfs_clear_cdevpriv(void); > > > are provided for manipulation of the per-file private data. > > > > > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > > > which is used to initiate currently performed driver operation. dtr > > > is the function that will be called when either the last refernce to > > > the file goes away or devfs_clear_cdevpriv is called. > > > > > > devfs_get_cdevpriv is the obvious accessor. > > > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > > open file. > > > > > > The synchronization of the cdev data and file private data is left > > > to the driver code, I did not found any generic helper mechanism that > > > could be useful there. > > > > > > Patch: > > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > > Dumb driver that shows the basic usage of the proposed KPI: > > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > > > Previous version of the patch was tested by Peter Holm. > > > > I like this very much and will use it instead of devfs cloning in ipmi(4) so > > we can use ipmievd when it is committed. IWBN if there was a more automated > > way of handling the unload race, for example if destroy_dev() could somehow > > clear all the per-open fd data. That may not be easily feasible, however. > > (In theory each cdev could have a list of "attached" 'struct file' objects > > that it updates in VOP_CLOSE() and for a destroy dev it detaches all the > > private data after marking the cdev with a bad/null cdevsw, however, that > > would bloat 'struct file' with at least one more pointer (if not two).) > > Probably, I shall clarify that the dtr is called when the last reference > to the struct file going away, unless the priv data is already cleared > by the call to the devfs_clear_cdevpriv. > > The problem with VOP_CLOSE() is that some actions (like forced unmount > or revoke) may cause less calls to the devfs_close then the files > pointing to the cdev. Your proposal basically means that we need, > besides the normal pointers file->vnode->cdev, have the reverse path > cdev->file. I think this is ugly and better be handled by the fdrop(). The disconnect as I see it is that right now destroy_dev() "orphans" devices in that the files still exist but the backing cdev's now have dead operations. However, now you can have a partially orphaned cdev in that not all of the cdev state is torn down in destroy_dev(). In that sense it would be nice to have the behavior described above, and yes you would have to have the cdev's keep track of 'file's as I suggested. Could you handle the revoke(2) and forced umount cases either via VOP_REVOKE() or by adding a VOP_INACTIVE() to devfs? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon May 5 20:40:20 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43D91065675; Mon, 5 May 2008 20:40:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFC38FC1E; Mon, 5 May 2008 20:40:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jt7Tv-000Gzi-4l; Mon, 05 May 2008 23:40:19 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45KeI0H075258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 23:40:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45KeE7f079917; Mon, 5 May 2008 23:40:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m45KeEVv079916; Mon, 5 May 2008 23:40:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 May 2008 23:40:14 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080505204013.GW18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <200805050939.42425.jhb@freebsd.org> <20080505142051.GS18958@deviant.kiev.zoral.com.ua> <200805051156.14706.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0kX0f002JLNe82mQ" Content-Disposition: inline In-Reply-To: <200805051156.14706.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: a908ef79c5d1ff8569b4b694ccf6cda2 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2780 [May 05 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 20:40:21 -0000 --0kX0f002JLNe82mQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 11:56:14AM -0400, John Baldwin wrote: > On Monday 05 May 2008 10:20:51 am Kostik Belousov wrote: > > On Mon, May 05, 2008 at 09:39:42AM -0400, John Baldwin wrote: > > > On Sunday 04 May 2008 01:10:02 pm Kostik Belousov wrote: > > > > Since the review for the clone-at-open patch (fdclone) posted some = time=20 > ago > > > > mostly says that it would be better to implement per-file private d= ata > > > > instead, I produced the patch along this line, > > > > > > > > The patch does not change the cdevsw ABI, instead, three new functi= ons > > > > nt devfs_get_cdevpriv(void **datap); > > > > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > > void devfs_clear_cdevpriv(void); > > > > are provided for manipulation of the per-file private data. > > > > > > > > devfs_set_cdevpriv assigns the priv as private data for the file=20 > descriptor > > > > which is used to initiate currently performed driver operation. dtr > > > > is the function that will be called when either the last refernce to > > > > the file goes away or devfs_clear_cdevpriv is called. > > > > > > > > devfs_get_cdevpriv is the obvious accessor. > > > > > > > > devfs_clear_cdevpriv allows to clear the private data for the still > > > > open file. > > > > > > > > The synchronization of the cdev data and file private data is left > > > > to the driver code, I did not found any generic helper mechanism th= at > > > > could be useful there. > > > > > > > > Patch: > > > > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > > > > Dumb driver that shows the basic usage of the proposed KPI: > > > > http://people.freebsd.org/~kib/misc/fpclone.c > > > > > > > > Previous version of the patch was tested by Peter Holm. > > >=20 > > > I like this very much and will use it instead of devfs cloning in ipm= i(4)=20 > so=20 > > > we can use ipmievd when it is committed. IWBN if there was a more=20 > automated=20 > > > way of handling the unload race, for example if destroy_dev() could= =20 > somehow=20 > > > clear all the per-open fd data. That may not be easily feasible, how= ever. =20 > > > (In theory each cdev could have a list of "attached" 'struct file' ob= jects=20 > > > that it updates in VOP_CLOSE() and for a destroy dev it detaches all = the=20 > > > private data after marking the cdev with a bad/null cdevsw, however, = that=20 > > > would bloat 'struct file' with at least one more pointer (if not two)= .) > >=20 > > Probably, I shall clarify that the dtr is called when the last reference > > to the struct file going away, unless the priv data is already cleared > > by the call to the devfs_clear_cdevpriv. > >=20 > > The problem with VOP_CLOSE() is that some actions (like forced unmount > > or revoke) may cause less calls to the devfs_close then the files > > pointing to the cdev. Your proposal basically means that we need, > > besides the normal pointers file->vnode->cdev, have the reverse path > > cdev->file. I think this is ugly and better be handled by the fdrop(). >=20 > The disconnect as I see it is that right now destroy_dev() "orphans" devi= ces=20 > in that the files still exist but the backing cdev's now have dead=20 > operations. However, now you can have a partially orphaned cdev in that = not=20 > all of the cdev state is torn down in destroy_dev(). In that sense it wo= uld=20 > be nice to have the behavior described above, and yes you would have to h= ave=20 > the cdev's keep track of 'file's as I suggested. >=20 > Could you handle the revoke(2) and forced umount cases either via > VOP_REVOKE() or by adding a VOP_INACTIVE() to devfs? I do not see how VOP_INACTIVE would be helpful there. Use of it still means the vnode->file walker. And, I quite dislike the backreferences like cdev->files or vnodes->files. My previous attempt of the cloning at open() resolved the lifecycle issues by making the per-fd data a cdev with the usual cdev management. I thought about either incrementing si_threadcount, or adding another refcounter to the cdev to track presence of the priv data. But destroy_dev() then have to block, and driver author still required to keep track the list of the allocated priv references to be able to actively unblock, like the d_purge. I then decided to leave this to the driver. --0kX0f002JLNe82mQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgfcK0ACgkQC3+MBN1Mb4gq7QCdFdTDH9mMfrCXzttLcfu8ukwM mSMAoJwp4hyu2Fw0yxtfiR7RufO8Rzl9 =SD3v -----END PGP SIGNATURE----- --0kX0f002JLNe82mQ-- From owner-freebsd-arch@FreeBSD.ORG Mon May 5 21:13:18 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8451065672; Mon, 5 May 2008 21:13:18 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id D3B068FC15; Mon, 5 May 2008 21:13:17 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 450253F6389; Mon, 5 May 2008 23:13:16 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 2D9223F6383; Mon, 5 May 2008 23:13:16 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 46F3E9F2A7; Mon, 5 May 2008 21:10:51 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3A5BF4089; Mon, 5 May 2008 23:10:51 +0200 (CEST) Date: Mon, 5 May 2008 23:10:51 +0200 From: Jeremie Le Hen To: obrien@freebsd.org Message-ID: <20080505211051.GC32317@obiwan.tataz.chchile.org> References: <20080427012416.GA9817@dragon.NUXI.org> <20080502070147.GE74500@obiwan.tataz.chchile.org> <20080504040110.GC94985@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080504040110.GC94985@dragon.NUXI.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 21:13:18 -0000 On Sat, May 03, 2008 at 09:01:10PM -0700, David O'Brien wrote: > On Fri, May 02, 2008 at 09:01:47AM +0200, Jeremie Le Hen wrote: > > Index: sys/conf/kern.pre.mk > > =================================================================== > > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.pre.mk,v > > retrieving revision 1.97 > > diff -u -p -r1.97 kern.pre.mk > > --- sys/conf/kern.pre.mk 2 Feb 2008 19:55:28 -0000 1.97 > > +++ sys/conf/kern.pre.mk 29 Mar 2008 14:06:45 -0000 > > @@ -3,10 +3,7 @@ > > # Part of a unified Makefile for building kernels. This part contains all > > # of the definitions that need to be before %BEFORE_DEPEND. > > > > -SRCCONF?= /etc/src.conf > > -.if exists(${SRCCONF}) > > -.include "${SRCCONF}" > > -.endif > > +.include > > I may not be seeing it - why do you need this change? It is needed so I can use MK_SSP later in kern.mk: =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/conf/kern.mk,v retrieving revision 1.52 diff -u -p -r1.52 kern.mk --- sys/conf/kern.mk 24 May 2007 21:53:42 -0000 1.52 +++ sys/conf/kern.mk 29 Mar 2008 13:44:15 -0000 @@ -97,3 +97,10 @@ CFLAGS+= -ffreestanding .if ${CC} == "icc" CFLAGS+= -restrict .endif + +# +# GCC SSP support. +# +.if ${MK_SSP} != "no" && ${CC} != "icc" +CFLAGS+= -fstack-protector +.endif Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Tue May 6 06:12:24 2008 Return-Path: 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 009B9106567A for ; Tue, 6 May 2008 06:12:24 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 77B708FC20 for ; Tue, 6 May 2008 06:12:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 21A5545E13; Tue, 6 May 2008 08:12:22 +0200 (CEST) Received: from localhost (chello087206046210.chello.pl [87.206.46.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D45CF45683; Tue, 6 May 2008 08:12:16 +0200 (CEST) Date: Tue, 6 May 2008 08:12:15 +0200 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20080506061215.GB2508@garage.freebsd.pl> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080505081355.GB1628@garage.freebsd.pl> <20080505145631.GT18958@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <20080505145631.GT18958@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 06:12:24 -0000 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 05:56:31PM +0300, Kostik Belousov wrote: > On Mon, May 05, 2008 at 10:13:55AM +0200, Pawel Jakub Dawidek wrote: > > Can you see if my OSD (Object-Specific-Data) KPI can be useful here? > > I've it only in perforce for now, but I think it's what you are looking > > for. I use it for jails and threads currently, but it is trivial to use > > it for other objects. Take a look: > >=20 > > http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/pjd/zfs= /sys/sys/osd.h&REV=3D3 > >=20 > > When your code is loaded/initialized you call: > >=20 > > static int slot; > >=20 > > slot =3D osd_file_register(mod_destroy); > >=20 > > Where mod_destroy is a function which knows how to free your private > > data. On unload: > >=20 > > osd_file_deregister(slot); > >=20 > > Now, when you want to attach private data: > >=20 > > error =3D osd_file_set(fp, slot, ptr_to_your_data); > >=20 > > You can get it with: > >=20 > > ptr =3D osd_file_get(fp, slot); > This is a nice feature, but I think that privdata is a fundamental > internal operation of the kernel, and it would be wrong to use > the OSD. [...] OSD is there to be used mostly by optional modules. For example if ZFS is not loaded there is no need to keep a pointer to its private data in struct prison and struct thread. > [...] In fact, the object we shall attach OSD to is the struct > file, and we would need to export the struct file to the cdevsw operation= s. > Since it both breaks current ABI and complicates the future changes to > the struct file, I would much prefer to not engage this route. Ok. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIH/a/ForvXbEpPzQRAmQ5AJ4/4aNF7nbZSXibdtD76uUZVNR71wCfUAo5 dZ5C7dh9TDj5ey1w3cjad4M= =BKfz -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq-- From owner-freebsd-arch@FreeBSD.ORG Wed May 7 03:29:20 2008 Return-Path: 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 72986106567C; Wed, 7 May 2008 03:29:20 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D31F38FC26; Wed, 7 May 2008 03:29:19 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl64-185.kln.forthnet.gr [77.49.191.185]) (authenticated bits=128) by igloo.linux.gr (8.14.2/8.14.2/Debian-4) with ESMTP id m473HnMb015969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 May 2008 06:17:56 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m473Hn1e009904; Wed, 7 May 2008 06:17:49 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m473HmGd009903; Wed, 7 May 2008 06:17:48 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: gnn@freebsd.org References: <4811E384.5020604@freebsd.org> Date: Wed, 07 May 2008 06:17:48 +0300 In-Reply-To: (gnn@freebsd.org's message of "Sun, 27 Apr 2008 17:07:56 -0700") Message-ID: <8763tqkdk3.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: m473HnMb015969 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.339, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.06, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: arch@freebsd.org, Andre Oppermann Subject: Re: Accounting for mbufs and clusters assigned to a socket buffer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 03:29:20 -0000 On Sun, 27 Apr 2008 17:07:56 -0700, gnn@freebsd.org wrote: >At Fri, 25 Apr 2008 15:58:28 +0200, andre wrote: >>gnn@freebsd.org wrote: >>> Howdy, >>> >>> The following patch updates the kernel (CURRENT as of 23 April or >>> so) and netstat(1) to show not only the bytes in the receive and >>> send queues but also the mbuf and cluster usage per socket buffer. >>> I'd be interested in people's comments on this. I'd like to extend >>> such counting to show more information, in particular how much of a >>> cluster or mbuf is actually in use. >> >> The intent of tracking that information is good. However there are >> some problems with your approach: M_EXT does not mean the mbuf has a >> 2k cluster attached. It could by any external storage. That is a 2k >> (classic) cluster, a 4k (page size) cluster, a 9k cluster, a VM page >> (sendfile), and so on. > > Yup, this is a first cut. > >> The field sb_mbcnt already gives you the aggregated gross storage >> space in use for the socket. And sb_cc tells how much actual payload >> it contains. > > Right but it does not tell us the mix of clusters vs. mbufs, which is > something useful for tuning. That would be very useful indeed :-) I guess we could check *both* (m_flags & M_EXT) and m_ext.ext_type. This won't really show how many mbufs use a classic cluster vs. a 9k cluster, but checking for all the m_ext.ext_types is probably going to look a bit ugly in a single if-check :( We have at least EXT_CLUSTER, EXT_JUMBOP, EXT_JUMBO9, EXT_JUMBO16 and EXT_PACKET which may be interesting for cluster-related accounting, but in socketvar.h we can't really use the uma zone accounting. I just noticed that the 'interesting' ext_types are conveniently short integers though. Maybe we could change sb_ccnt to a small array, and then change if ((m)->m_flags & M_EXT) \ (sb)->sb_ccnt += 1; to something like: if ((m)->m_flags & M_EXT && (m)->m_ext.ext_type < EXT_MBUF) \ (sb)->sb_ccnt[(m)->m_ext.ext_type - 1] += 1; \ With our current ext_type's #define EXT_CLUSTER 1 /* mbuf cluster */ #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ #define EXT_JUMBOP 3 /* jumbo cluster 4096 bytes */ #define EXT_JUMBO9 4 /* jumbo cluster 9216 bytes */ #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ ... the [ext_type - 1] would move the burden of parsing the ext_type at the place where we actually have to print something about the sb_ccnt counters. Would the 'bloat' of u_int[6] for ext_type's which are unused be too much to keep around? From owner-freebsd-arch@FreeBSD.ORG Thu May 8 15:10:32 2008 Return-Path: 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 3B7D11065676 for ; Thu, 8 May 2008 15:10:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 189DD8FC16 for ; Thu, 8 May 2008 15:10:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m48FASUu053412; Thu, 8 May 2008 08:10:31 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m48FAG5k093496; Thu, 8 May 2008 08:10:16 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m48FAGCG001409; Thu, 8 May 2008 08:10:16 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 08 May 2008 11:10:15 -0400 Message-ID: From: gnn@freebsd.org To: Giorgos Keramidas In-Reply-To: <8763tqkdk3.fsf@kobe.laptop> References: <4811E384.5020604@freebsd.org> <8763tqkdk3.fsf@kobe.laptop> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 273453 - 9903ecad0498 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: arch@freebsd.org, Andre Oppermann Subject: Re: Accounting for mbufs and clusters assigned to a socket buffer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 15:10:32 -0000 At Wed, 07 May 2008 06:17:48 +0300, Giorgos Keramidas wrote: > > I guess we could check *both* (m_flags & M_EXT) and m_ext.ext_type. > > This won't really show how many mbufs use a classic cluster vs. a 9k > cluster, but checking for all the m_ext.ext_types is probably going to > look a bit ugly in a single if-check :( > > We have at least EXT_CLUSTER, EXT_JUMBOP, EXT_JUMBO9, EXT_JUMBO16 and > EXT_PACKET which may be interesting for cluster-related accounting, but > in socketvar.h we can't really use the uma zone accounting. I just > noticed that the 'interesting' ext_types are conveniently short integers > though. Maybe we could change sb_ccnt to a small array, and then change > > if ((m)->m_flags & M_EXT) \ > (sb)->sb_ccnt += 1; > > to something like: > > if ((m)->m_flags & M_EXT && (m)->m_ext.ext_type < EXT_MBUF) \ > (sb)->sb_ccnt[(m)->m_ext.ext_type - 1] += 1; \ > > With our current ext_type's > > #define EXT_CLUSTER 1 /* mbuf cluster */ > #define EXT_SFBUF 2 /* sendfile(2)'s sf_bufs */ > #define EXT_JUMBOP 3 /* jumbo cluster 4096 bytes */ > #define EXT_JUMBO9 4 /* jumbo cluster 9216 bytes */ > #define EXT_JUMBO16 5 /* jumbo cluster 16184 bytes */ > #define EXT_PACKET 6 /* mbuf+cluster from packet zone */ > #define EXT_MBUF 7 /* external mbuf reference (M_IOVEC) */ > ... > > the [ext_type - 1] would move the burden of parsing the ext_type at the > place where we actually have to print something about the sb_ccnt > counters. > > Would the 'bloat' of u_int[6] for ext_type's which are unused be too > much to keep around? I don't know if we want to go that far, but we could certainly try it. I'll keep it in mind. Thanks, George From owner-freebsd-arch@FreeBSD.ORG Fri May 9 17:24:55 2008 Return-Path: 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 1B40E106566B for ; Fri, 9 May 2008 17:24:55 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id A2D518FC19 for ; Fri, 9 May 2008 17:24:54 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.2/8.14.2) with ESMTP id m49H4nQG063113 for ; Fri, 9 May 2008 10:05:04 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.2/8.14.2/Submit) id m49H4nZt063112 for arch@FreeBSD.org; Fri, 9 May 2008 10:04:49 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f From: Eric Anholt To: arch@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-A99sWqJyj5njfvQeoy+G" Date: Fri, 09 May 2008 10:04:48 -0700 Message-Id: <1210352688.2152.78.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port Cc: Subject: Feature requests for open-source graphics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 17:24:55 -0000 --=-A99sWqJyj5njfvQeoy+G Content-Type: multipart/mixed; boundary="=-sutqlD5+ZwOigSMbKaUt" --=-sutqlD5+ZwOigSMbKaUt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (Re-sent after I dragged a discussion of NVIDIA on FreeBSD off-topic on developers@) On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > On May 7, 2008, at 8:29 AM, John Baldwin wrote: >=20 > > Quite, and this has been covered several times already. In fact, =20 > > they engage > > in several hacks to support Linux. Other OS's such as Solaris and =20 > > OS X have > > cleaner interfaces for many of the things they wish to do. >=20 > I think this is where I normally say that we need kernel drivers > for graphics hardware. I'm not going to do that anymore; I've been > stating the obvious too often already... It's OK, we're finally listening. By the end of the year, major Linux distributions should be shipping "DRM modesetting" -- the DRM device takes over your graphics card and manages memory, execution, and suspend/resume. Your kernel console and X Server then sit on top of that, submitting video mode setting and command execution requests to the DRM. The chips I would expect to be supported by then are all Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. What FreeBSD needs to do to keep up is implement the memory manager part. I think I've got a reasonable design going that should take about a month of reimplementing for the FreeBSD kernel. If someone wanted to get us closer to doing that, git clone anongit.freedesktop.org:/git/mesa/drm=20 and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) work on -current. To see what we're working on for what we're calling the "graphics execution manager" now (memory management plus caching management plus plans for execution scheduling), git-remote add anholt people.freedesktop.org:~anholt/drm git-fetch anholt git-checkout anholt/drm-gem The interesting things we're needing from the kernel: - Private storage associated with file descriptors - Callback to driver on destruction of file descriptor - Ability to allocate a swap-backed pile of memory - Ability to pin pages from that object and get addresses for them to stuff into the GTT. - Ability to map pages in the kernel with the uncached bits set (non-intel) - Ability to map pages to userland with the uncached bits set (non-intel, likely not required, but may come at a performance cost). Interesting things we're likely going to need from the kernel: - Ability to create fds above 1024 from our driver, associated with our own set of file operations (read/write/mmap/ioctl/close). - Ability to look up those fds and get our private storage associated with them. If above goes through, then another likely adventure: - Creating a filesystem exposing those objects we've been making fds for. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-sutqlD5+ZwOigSMbKaUt Content-Disposition: inline Content-Description: Forwarded message - Re: Forward: Updated FreeBSD kernel feature requests (NVIDIA graphics) Content-Type: message/rfc822 Return-Path: X-Original-To: eric@anholt.net Delivered-To: eric@anholt.net Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by camus.anholt.net (Postfix) with ESMTP id A7C03732F9 for ; Thu, 8 May 2008 19:26:08 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 296B315549F for ; Fri, 9 May 2008 02:26:06 +0000 (UTC) (envelope-from owner-all-developers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id B3851106568B; Fri, 9 May 2008 02:26:05 +0000 (UTC) Delivered-To: anholt@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 9194F1065670; Fri, 9 May 2008 02:26:05 +0000 (UTC) Delivered-To: developers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC898106566C; Fri, 9 May 2008 02:26:03 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id 269C28FC0A; Fri, 9 May 2008 02:26:02 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.2/8.14.2) with ESMTP id m48MsJQT011541; Thu, 8 May 2008 15:54:49 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.2/8.14.2/Submit) id m48MsIw9011539; Thu, 8 May 2008 15:54:18 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f Subject: Re: Forward: Updated FreeBSD kernel feature requests (NVIDIA graphics) From: Eric Anholt To: Marcel Moolenaar Cc: John Baldwin , Coleman Kane , Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= , Martin Cracauer , gnn@freebsd.org, developers@freebsd.org In-Reply-To: <55982D27-8C59-4C3E-8832-5F0749E6C65C@mac.com> References: <20080407211738.GG10919@wolf.nvidia.com> <86k5i7ghrg.fsf@ds4.des.no> <1210117298.6421.103.camel@localhost> <200805071129.35835.jhb@freebsd.org> <55982D27-8C59-4C3E-8832-5F0749E6C65C@mac.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bLVuGJ7O4f72PRhEn7Mb" Date: Thu, 08 May 2008 15:54:17 -0700 Message-Id: <1210287258.2152.45.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port Sender: owner-all-developers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG --=-bLVuGJ7O4f72PRhEn7Mb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > On May 7, 2008, at 8:29 AM, John Baldwin wrote: >=20 > > Quite, and this has been covered several times already. In fact, =20 > > they engage > > in several hacks to support Linux. Other OS's such as Solaris and =20 > > OS X have > > cleaner interfaces for many of the things they wish to do. >=20 > I think this is where I normally say that we need kernel drivers > for graphics hardware. I'm not going to do that anymore; I've been > stating the obvious too often already... It's OK, we're finally listening. By the end of the year, major Linux distributions should be shipping "DRM modesetting" -- the DRM device takes over your graphics card and manages memory, execution, and suspend/resume. Your kernel console and X Server then sit on top of that, submitting video mode setting and command execution requests to the DRM. The chips I would expect to be supported by then are all Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. What FreeBSD needs to do to keep up is implement the memory manager part. I think I've got a reasonable design going that should take about a month of reimplementing for the FreeBSD kernel. If someone wanted to get us closer to doing that, git clone anongit.freedesktop.org:/git/mesa/drm=20 and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) work on -current. To see what we're working on for what we're calling the "graphics execution manager" now (memory management plus caching management plus plans for execution scheduling), git-remote add anholt people.freedesktop.org:~anholt/drm git-fetch anholt git-checkout anholt/drm-gem The interesting things we're needing from the kernel: - Private storage associated with file descriptors - Callback to driver on destruction of file descriptor - Ability to allocate a swap-backed pile of memory - Ability to pin pages from that object and get addresses for them to stuff into the GTT. - Ability to map pages in the kernel with the uncached bits set (non-intel) - Ability to map pages to userland with the uncached bits set (non-intel, likely not required, but may come at a performance cost). Interesting things we're considering needing from the kernel: - Ability to create fds above 1024 from our driver, associated with our own set of file operations (read/write/mmap/ioctl/close). - Ability to look up those fds and get our private storage associated with them. Down the line, likely to happen: - Creating a filesystem exposing those objects we've been making fds for. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-bLVuGJ7O4f72PRhEn7Mb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgjhJkACgkQHUdvYGzw6veSAgCfZrIMMwWQlbr+LHjeqpeQZWUO 9BMAn18Ga7Dd0omCslpnf9HL4s28Bmv1 =g7ib -----END PGP SIGNATURE----- --=-bLVuGJ7O4f72PRhEn7Mb-- -- This mail is for the internal use of the FreeBSD project committers, and as such is private. This mail may not be published or forwarded outside the FreeBSD committers' group or disclosed to other unauthorised parties without the explicit permission of the author(s). --=-sutqlD5+ZwOigSMbKaUt-- --=-A99sWqJyj5njfvQeoy+G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgkhDAACgkQHUdvYGzw6vcDcQCfTD9z3tRyP5yphrzJfnP7GKf3 KQUAnRF4nVOCH3TGjyKq4WA+i7Ybxd2T =bEev -----END PGP SIGNATURE----- --=-A99sWqJyj5njfvQeoy+G-- From owner-freebsd-arch@FreeBSD.ORG Sat May 10 16:28:24 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9477F106567C for ; Sat, 10 May 2008 16:28:24 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from catalpa.its.msstate.edu (catalpa.its.msstate.edu [130.18.2.119]) by mx1.freebsd.org (Postfix) with ESMTP id 455E08FC12 for ; Sat, 10 May 2008 16:28:24 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from localhost (archive.msstate.edu [130.18.80.18]) by catalpa.its.msstate.edu (8.13.8/8.13.8) with ESMTP id m4AGFCmV008872 for ; Sat, 10 May 2008 11:15:12 -0500 Received: from 64.234.76.20 ([64.234.76.20]) by webmail.msstate.edu (IMP) with HTTP for ; Sat, 10 May 2008 11:15:12 -0500 Message-ID: <1210436112.4825ca102cfce@webmail.msstate.edu> Date: Sat, 10 May 2008 11:15:12 -0500 From: rar102@ra.msstate.edu To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 64.234.76.20 Subject: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 16:28:24 -0000 I recently bought a new laptop. I have been unsuccesful in installing FreeBSD (or any alternatives for that matter) onto it. I wonder if I can get some help. I have tried to: 1. install the FreeBSD amd64 7.0 release. Stopped at a "No disks found!" prompt. With a little bit googling, I see that FreeBSD has been successfully installed onto ST9120822AS hard drive. 2. run the latest Knoppix on it (just to see if the Debian i386 Linux flavors can do it). Hangs on detecting hard drive. To be honest, I want BSD if I can use it, anyway. 3. install the FreeBSD 7-stable amd64 April snapshot. Same result as #1. 4. install NetBSD amd 4.0-release. Gives a disk geometry warning but installs without much further ado. In fact, I am still using NetBSD's bootloader. It boots both Vista and NetBSD. But... when I boot into NetBSD, it overheats, panics and dies within a minute. Trolling the internet again, I see that I am not the only one that has run into this problem. It is not running long enough to try an ftp install. I would like to not burn up this motherboard and I don't see any NetBSD snapshot iso's to see if they have resolved this problem. 5. install the FreeBSD i386 7.0 release. Installer complains about disk geometry. At the partitioning screen I press 'g' ('Set Disk Geometry'). I previously used Vista's magic partition resizer to leave me some space. I tell the sysintall to format that empty space as ufs2 and press 'q' ('Quit' out the disk partitioning step of sysintall). At this point, it pops up a message that my partitions are not starting on disk boundaries. I aborted the install at that point. It may still work. I just don't know. I would rather 6. install the FreeBSD i386 7-stable April snapshot. Same result as #1 and #3. This was kind of strange. I would have expected the same result as #5. Any suggestions??? RAR From owner-freebsd-arch@FreeBSD.ORG Sat May 10 17:04:07 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E5E1065674 for ; Sat, 10 May 2008 17:04:07 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 58BA38FC1A for ; Sat, 10 May 2008 17:04:07 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id PqKj1Z0010QkzPwA606F00; Sat, 10 May 2008 16:47:44 +0000 Received: from discordia ([24.60.135.75]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id Pso51Z0041dmTCQ8N00000; Sat, 10 May 2008 16:48:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=XFsXuKNdAAAA:8 a=aV6fQe9mukIFe30ZqIIA:9 a=tbGSnP4oebQ663__m_StaFZD9KwA:4 a=LY0hPdMaydYA:10 a=R7K6z73z7lgpH9iwsW0A:9 a=Gjbs7moxhhHMKGeZyAdRfhg2goQA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 1C50D1DB2F9; Sat, 10 May 2008 12:48:05 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 0B3461DB2F9; Sat, 10 May 2008 12:47:48 -0400 (EDT) From: Coleman Kane To: rar102@ra.msstate.edu In-Reply-To: <1210436112.4825ca102cfce@webmail.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xHetocM0ThdpLSeb82GR" Organization: FreeBSD Project Date: Sat, 10 May 2008 12:46:29 -0400 Message-Id: <1210437989.62567.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 17:04:07 -0000 --=-xHetocM0ThdpLSeb82GR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-10 at 11:15 -0500, rar102@ra.msstate.edu wrote: > I recently bought a new laptop. I have been unsuccesful in installing Fr= eeBSD > (or any alternatives for that matter) onto it. I wonder if I can get som= e > help. I have tried to: >=20 > 1. install the FreeBSD amd64 7.0 release. Stopped at a "No disks found!= " > prompt. With a little bit googling, I see that FreeBSD has been successf= ully > installed onto ST9120822AS hard drive. >=20 > 2. run the latest Knoppix on it (just to see if the Debian i386 Linux fl= avors > can do it). Hangs on detecting hard drive. To be honest, I want BSD if = I can > use it, anyway. >=20 > 3. install the FreeBSD 7-stable amd64 April snapshot. Same result as #1= . >=20 > 4. install NetBSD amd 4.0-release. Gives a disk geometry warning but in= stalls > without much further ado. In fact, I am still using NetBSD's bootloader.= It > boots both Vista and NetBSD. But... when I boot into NetBSD, it overhea= ts, > panics and dies within a minute. Trolling the internet again, I see that= I am > not the only one that has run into this problem. It is not running long = enough > to try an ftp install. I would like to not burn up this motherboard and = I > don't see any NetBSD snapshot iso's to see if they have resolved this pro= blem. >=20 > 5. install the FreeBSD i386 7.0 release. Installer complains about disk > geometry. At the partitioning screen I press 'g' ('Set Disk Geometry'). = I > previously used Vista's magic partition resizer to leave me some space. = I tell > the sysintall to format that empty space as ufs2 and press 'q' ('Quit' ou= t the > disk partitioning step of sysintall). At this point, it pops up a messag= e that > my partitions are not starting on disk boundaries. I aborted the install= at > that point. It may still work. I just don't know. I would rather >=20 > 6. install the FreeBSD i386 7-stable April snapshot. Same result as #1 = and #3. > This was kind of strange. I would have expected the same result as #5. >=20 > Any suggestions??? >=20 > RAR >=20 RAR, You are in luck! Well, actually I have good news and I have bad news. The good news is that I have nearly the same (6715b) laptop and experienced similar problems when getting FreeBSD onto it. After some work, I've been able to use FreeBSD reliably on the system. The bad news is that you probably have an overlap of PCI memory ranges between the SATA controller and another device in the system (likely the audio controller). I put up a page describing the problem here: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_c= ompaq_6715b_working Specifically, read this section: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_= sb600_hda_audio_controller Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in it. I figured that I should have done it a while ago. Oh well. While you are at it, see if you can use Scroll-Lock and the up/down keys to read the kernel messages. See if you can find the atapci0 probe line for your SATA controller (AHCI), as well as the line for your pcm0 device and send them back to me. I can add your info to my webpage to help others. It will look like this: atapci0: port 0x9000-0x9007,0x9008-0x900b,0= x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 a= t device 18.0 on pci0 ... pcm0: mem 0xd0608000-0xd060bff= f irq 16 at device 20.2 on pci0 You'll notice the "mem" resource for the audio controller is 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is completely covered by this audio controller. If you happen to have access to another machine for building your own releases, you can try my patch and build them from it. --=20 Coleman Kane --=-xHetocM0ThdpLSeb82GR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgl0WMACgkQcMSxQcXat5cEbACcD44xThDgxknmi10ZJCWBZhkR 5dIAnigHtZUE7CDAYmO7nAmmjb/W0E8I =SNTB -----END PGP SIGNATURE----- --=-xHetocM0ThdpLSeb82GR-- From owner-freebsd-arch@FreeBSD.ORG Sat May 10 17:13:17 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AF87106564A for ; Sat, 10 May 2008 17:13:17 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from catalpa.its.msstate.edu (catalpa.its.msstate.edu [130.18.2.119]) by mx1.freebsd.org (Postfix) with ESMTP id B31B38FC36 for ; Sat, 10 May 2008 17:13:16 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from localhost (archive.msstate.edu [130.18.80.18]) by catalpa.its.msstate.edu (8.13.8/8.13.8) with ESMTP id m4AHDF9s009784; Sat, 10 May 2008 12:13:15 -0500 Received: from host-69-59-108-107.nctv.com (host-69-59-108-107.nctv.com [69.59.108.107]) by webmail.msstate.edu (IMP) with HTTP for ; Sat, 10 May 2008 12:13:15 -0500 Message-ID: <1210439595.4825d7ab5c1df@webmail.msstate.edu> Date: Sat, 10 May 2008 12:13:15 -0500 From: rar102@ra.msstate.edu To: Coleman Kane References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> In-Reply-To: <1210437989.62567.17.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 69.59.108.107 Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 17:13:17 -0000 Quoting Coleman Kane : Yes!!! thank you. Unfortunately, I don't have access to another amd64 box to try your patch. Sorry. But, I will look at the dmesg and send it to you. > RAR, > > You are in luck! Well, actually I have good news and I have bad news. > The good news is that I have nearly the same (6715b) laptop and > experienced similar problems when getting FreeBSD onto it. After some > work, I've been able to use FreeBSD reliably on the system. > > The bad news is that you probably have an overlap of PCI memory ranges > between the SATA controller and another device in the system (likely the > audio controller). > > I put up a page describing the problem here: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > Specifically, read this section: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ati_sb600_hda_audio_controller > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in > it. I figured that I should have done it a while ago. Oh well. > > While you are at it, see if you can use Scroll-Lock and the up/down keys > to read the kernel messages. See if you can find the atapci0 probe line > for your SATA controller (AHCI), as well as the line for your pcm0 > device and send them back to me. I can add your info to my webpage to > help others. > > It will look like this: > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > ... > pcm0: mem 0xd0608000-0xd060bfff > irq 16 at device 20.2 on pci0 > > You'll notice the "mem" resource for the audio controller is > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > completely covered by this audio controller. > > If you happen to have access to another machine for building your own > releases, you can try my patch and build them from it. > > -- > Coleman Kane > From owner-freebsd-arch@FreeBSD.ORG Sat May 10 18:35:33 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22061065674 for ; Sat, 10 May 2008 18:35:33 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 0874D8FC1F for ; Sat, 10 May 2008 18:35:32 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Ptzo1Z0090x6nqcA702e00; Sat, 10 May 2008 18:35:12 +0000 Received: from discordia ([24.60.135.75]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id PubW1Z00J1dmTCQ8Y00000; Sat, 10 May 2008 18:35:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=XFsXuKNdAAAA:8 a=3xXBtTqY72jV4fyaVScA:9 a=AJTtGUW9vA7_QXirdosA:7 a=FKWgBkEoFEq9YZutqUF5AABu2VgA:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 a=2knY5oQduLKmtCpyWw8A:9 a=LFrHsNdwfp_7VGw41YvmOBoPvCYA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 7BF6335A7D4; Sat, 10 May 2008 14:35:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 092BE25AD3D; Sat, 10 May 2008 14:35:14 -0400 (EDT) From: Coleman Kane To: rar102@ra.msstate.edu In-Reply-To: <1210439595.4825d7ab5c1df@webmail.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q/fpSuNgn3vAVOy4Is4X" Organization: FreeBSD Project Date: Sat, 10 May 2008 14:33:55 -0400 Message-Id: <1210444435.62567.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 18:35:33 -0000 --=-Q/fpSuNgn3vAVOy4Is4X Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > Quoting Coleman Kane : >=20 > Yes!!! thank you. Unfortunately, I don't have access to another amd64 bo= x to > try your patch. Sorry. But, I will look at the dmesg and send it to you= . Excellent. A dmesg will be very helpful for me to write a patch from, as it will allow me to see if it is or is not the sound driver overlapping memory in your case. I suspect that the BIOS images are so similar that you probably even have almost the same bios-chosen memory regions on your system. >=20 > > RAR, > > > > You are in luck! Well, actually I have good news and I have bad news. > > The good news is that I have nearly the same (6715b) laptop and > > experienced similar problems when getting FreeBSD onto it. After some > > work, I've been able to use FreeBSD reliably on the system. > > > > The bad news is that you probably have an overlap of PCI memory ranges > > between the SATA controller and another device in the system (likely th= e > > audio controller). > > > > I put up a page describing the problem here: > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp= _compaq_6715b_working > > > > Specifically, read this section: > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_at= i_sb600_hda_audio_controller > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch in > > it. I figured that I should have done it a while ago. Oh well. > > > > While you are at it, see if you can use Scroll-Lock and the up/down key= s > > to read the kernel messages. See if you can find the atapci0 probe line > > for your SATA controller (AHCI), as well as the line for your pcm0 > > device and send them back to me. I can add your info to my webpage to > > help others. > > > > It will look like this: > > atapci0: port > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f m= em > > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > ... > > pcm0: mem 0xd0608000-0xd06= 0bfff > > irq 16 at device 20.2 on pci0 > > > > You'll notice the "mem" resource for the audio controller is > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller is > > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > completely covered by this audio controller. > > > > If you happen to have access to another machine for building your own > > releases, you can try my patch and build them from it. > > > > -- > > Coleman Kane > > >=20 >=20 >=20 --=20 Coleman Kane --=-Q/fpSuNgn3vAVOy4Is4X Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgl6pEACgkQcMSxQcXat5fqTACeNVbDHlRQ08rzghLL+475AIGN JV4AniiAaNQJulqpx1KsTr1xs2RpfVnp =1ruU -----END PGP SIGNATURE----- --=-Q/fpSuNgn3vAVOy4Is4X--