From owner-freebsd-arch@FreeBSD.ORG Sun Jan 1 01:52:47 2012 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 A3889106564A; Sun, 1 Jan 2012 01:52:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE718FC08; Sun, 1 Jan 2012 01:52:47 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q011qUVJ083909 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 31 Dec 2011 18:52:30 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 31 Dec 2011 18:52:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 31 Dec 2011 18:52:30 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 01 Jan 2012 01:52:47 -0000 On Dec 31, 2011, at 4:39 PM, Adrian Chadd wrote: > Hi, >=20 > I need a bit of a hand with this. >=20 > I'd like to be able to make the wlan and ath modules aware of kernel > configuration options. >=20 > For example, a kernel configuration with IEEE80211_SUPPORT_TDMA won't > build a wlan module that'll run successfully, as wlan/Makefile doesn't > know to suck in ieee80211_tdma.c . I could just wrap the whole file up > in an #ifdef, but I'd like to try and instead only build / link that > object in if it's needed. >=20 > Similarly, the ath module currently builds everything, regardless of > what options are currently enabled in the kernel configuration file. > So it'll always build ar5210, ar5211, ar5212, ar5416, ar9001, ar9002 > support, along with ath_rate_sample. Instead, I'd like to be able to > specify which HAL objects to link in, much like how you can do this > with "device ath_rfX" for the RF backends and "device ath_arX" for the > chipset support. For the integrated SoC stuff, it'd be nice to only > build a HAL which supports the relevant hardware, rather than having > to suck it _all_ in. >=20 > So, what kinds of evil ways can people dream up to achieve this? :) Build the kernel modules with the kernel and the kernel options will be = picked up. However, that only works for the opt_xxx.h files. There's not an (easy) = way to selectively include for modules with our current module system. The easy way to "work around" this is to always include the _tdma file, = and have a big ifdef around it. The 'harder' way would be to have a Makefile variable that will set all = the options in opt_foo.h as Makefile variables so you could .if based on = them. However, making that automated starts to get messy, due to the = order of inclusion. Working off the cuff, I'd propose the following API: KERNOPTS=3Dfoo baz SRC_FOO =3D foo.c SRC_BAZ =3D baz.c SRC=3D a.c b.c d.c And have the magic needed to conditionally add SRC_FOO and SRC_BAZ to = SRC in bsd.kern.mk. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Jan 1 12:58:25 2012 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 D0E8B106566C; Sun, 1 Jan 2012 12:58:25 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9468FC14; Sun, 1 Jan 2012 12:58:25 +0000 (UTC) Received: by eekc50 with SMTP id c50so17626866eek.13 for ; Sun, 01 Jan 2012 04:58:24 -0800 (PST) Received: by 10.213.3.214 with SMTP id 22mr98793ebo.2.1325421144933; Sun, 01 Jan 2012 04:32:24 -0800 (PST) Received: from rnote.ddteam.net (170-249-133-95.pool.ukrtel.net. [95.133.249.170]) by mx.google.com with ESMTPS id q67sm114529129eea.8.2012.01.01.04.32.22 (version=SSLv3 cipher=OTHER); Sun, 01 Jan 2012 04:32:23 -0800 (PST) Date: Sun, 1 Jan 2012 14:32:18 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20120101143218.7a42f001.ray@ddteam.net> In-Reply-To: References: X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-arch@freebsd.org Subject: Re: [patch] bsdbox changes for base system: add LOCAL_ 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, 01 Jan 2012 12:58:25 -0000 On Fri, 23 Dec 2011 16:42:06 -0800 Adrian Chadd wrote: > Hi, > > Here are two patches which implement some useful features for crunch > building: > > * Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the > 'build-tools' target. This is needed for cross-building bsdbox (and > any external directory added by LOCAL_DIRS) That makes me happy :) > * If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate > the crunch-gen hard links. > > I may end up changing the latter to CRUNCH_GENERATE_LINKS and default > that to yes, then allow the bsdbox build system to change that to > 'no', but the intent is the same. > > I'd like to commit this tomorrow if possible, so I can then follow it > up with the bsdbox import. > > Thanks, > > > Adrian Do it Adrian :) > > [adrian@pcbsd-macvm] ~/work/freebsd/head/src> svn diff Makefile.inc1 > share/mk Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 228757) > +++ Makefile.inc1 (working copy) > @@ -15,6 +15,8 @@ > # -DNO_WWWUPDATE do not update www in ${MAKE} update > # -DNO_CTF do not run the DTrace CTF conversion tools on built > # objects LOCAL_DIRS="list of dirs" to add additional dirs to the > # SUBDIR list > +# LOCAL_TOOL_DIRS="list of dirs" to add additional dirs to the > build-tools +# list > # TARGET="machine" to crossbuild world for a different machine > # type TARGET_ARCH= may be required when a TARGET supports multiple > # endians > > @@ -104,6 +106,8 @@ > CLEANDIR= cleandir > .endif > > +LOCAL_TOOL_DIRS?= '' > + > CVS?= cvs > CVSFLAGS?= -A -P -d -I! > SVN?= svn > @@ -1102,6 +1106,7 @@ > bin/csh \ > bin/sh \ > ${_rescue} \ > + ${LOCAL_TOOL_DIRS} \ > lib/ncurses/ncurses \ > lib/ncurses/ncursesw \ > ${_share} \ > Index: share/mk/bsd.crunchgen.mk > =================================================================== > --- share/mk/bsd.crunchgen.mk (revision 228757) > +++ share/mk/bsd.crunchgen.mk (working copy) > @@ -22,6 +22,8 @@ > # Specific links can be suppressed by setting > # CRUNCH_SUPPRESS_LINK_$(NAME) to 1. > # > +# If CRUNCH_SUPPRESS_ALL_LINKS is set to yes, no links will be > generated. +# > > # $FreeBSD$ > > @@ -39,6 +41,7 @@ > .else > CANONICALOBJDIR:= /usr/obj${.CURDIR} > .endif > +CRUNCH_SUPPRESS_ALL_LINKS?= no > > CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h > > @@ -51,6 +54,7 @@ > .else > $(OUTPUTS): $(.CURDIR)/../../$(D)/$(P)/Makefile > .endif > +.if ${CRUNCH_SUPPRESS_ALL_LINKS} != "yes" > .ifndef CRUNCH_SUPPRESS_LINK_${P} > LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(P) > .endif > @@ -59,6 +63,7 @@ > LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(A) > .endif > .endfor > +.endif > .endfor > .endfor > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Mon Jan 2 06:37:05 2012 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 8C186106566B; Mon, 2 Jan 2012 06:37:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1518FC12; Mon, 2 Jan 2012 06:37:04 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q026b0Ld000197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 08:37:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id q026b00h035389; Mon, 2 Jan 2012 08:37:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id q026b0Q8035388; Mon, 2 Jan 2012 08:37:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jan 2012 08:37:00 +0200 From: Kostik Belousov To: amd64@freebsd.org, arch@freebsd.org Message-ID: <20120102063700.GF50300@deviant.kiev.zoral.com.ua> References: <20111226220756.GR50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q4D258xU9PSURnuy" Content-Disposition: inline In-Reply-To: <20111226220756.GR50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: sparc64@freebsd.org Subject: Re: AVX 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, 02 Jan 2012 06:37:05 -0000 --Q4D258xU9PSURnuy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The patch http://people.freebsd.org/~kib/misc/avx.2.patch is the commit candidate. Compared with avx.1.patch, it includes several bugfixes, some move of code around, and finishes the implementation of getcontextx(3) for non-x86 architectures. Please note that variant of getcontextx() is required for deferred signal delivery from libthr. This is the reason for Cc:ing sparc64@, could somebody test the patch on this architecture ? I used the http://people.freebsd.org/~kib/misc/defer_sig.c to test deferred delivery on amd64. Another missed testing point is machines capable of XSAVE but lacking AVX extensions. I think most Core2 fall into this category, but my Core2 machine is disassembled. Could anybody test the patch on non-SandyBridge machine having XSAVE support ? You can check the capability using ports/sysutils/x86info or looking at the early boot Features2 line, which shall contain the XSAVE. --Q4D258xU9PSURnuy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8BUIwACgkQC3+MBN1Mb4j9SACeMjU7gPmMcjeZlS8tCvAmcSsm X/gAoM4VHWXd9gcE+xET40nPQVxZMi8f =mvHZ -----END PGP SIGNATURE----- --Q4D258xU9PSURnuy-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 3 16:23:48 2012 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 EC569106566B; Tue, 3 Jan 2012 16:23:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C209E8FC16; Tue, 3 Jan 2012 16:23:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6792846B2A; Tue, 3 Jan 2012 11:23:48 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EC373B944; Tue, 3 Jan 2012 11:23:47 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Jan 2012 09:24:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> In-Reply-To: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201030924.44493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 11:23:48 -0500 (EST) Cc: Adrian Chadd Subject: Re: Request for help: how do teach module building about kernel options? 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, 03 Jan 2012 16:23:49 -0000 On Saturday, December 31, 2011 8:52:29 pm Warner Losh wrote: > > On Dec 31, 2011, at 4:39 PM, Adrian Chadd wrote: > > > Hi, > > > > I need a bit of a hand with this. > > > > I'd like to be able to make the wlan and ath modules aware of kernel > > configuration options. > > > > For example, a kernel configuration with IEEE80211_SUPPORT_TDMA won't > > build a wlan module that'll run successfully, as wlan/Makefile doesn't > > know to suck in ieee80211_tdma.c . I could just wrap the whole file up > > in an #ifdef, but I'd like to try and instead only build / link that > > object in if it's needed. > > > > Similarly, the ath module currently builds everything, regardless of > > what options are currently enabled in the kernel configuration file. > > So it'll always build ar5210, ar5211, ar5212, ar5416, ar9001, ar9002 > > support, along with ath_rate_sample. Instead, I'd like to be able to > > specify which HAL objects to link in, much like how you can do this > > with "device ath_rfX" for the RF backends and "device ath_arX" for the > > chipset support. For the integrated SoC stuff, it'd be nice to only > > build a HAL which supports the relevant hardware, rather than having > > to suck it _all_ in. > > > > So, what kinds of evil ways can people dream up to achieve this? :) > > Build the kernel modules with the kernel and the kernel options will be picked up. > > However, that only works for the opt_xxx.h files. There's not an (easy) way to selectively include for modules with our current module system. > > The easy way to "work around" this is to always include the _tdma file, and have a big ifdef around it. > > The 'harder' way would be to have a Makefile variable that will set all the options in opt_foo.h as Makefile variables so you could .if based on them. However, making that automated starts to get messy, due to the order of inclusion. > > Working off the cuff, I'd propose the following API: > > KERNOPTS=foo baz > SRC_FOO = foo.c > SRC_BAZ = baz.c > SRC= a.c b.c d.c > > And have the magic needed to conditionally add SRC_FOO and SRC_BAZ to SRC in bsd.kern.mk. Not only that, but it would be nice if the list of modules to be built could be tailored to what options are enabled. For example, if I build a kernel that doesn't have inet or inet6 then it shouldn't try to build ipfw, etc. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jan 3 17:30:23 2012 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 4ACDD106566B; Tue, 3 Jan 2012 17:30:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBD518FC15; Tue, 3 Jan 2012 17:30:22 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so21935458vbb.13 for ; Tue, 03 Jan 2012 09:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wLjRmBRnZWf7Bg9E7HTu8BTSz1A3qcqsJEPk8i3TZwU=; b=iwvFfHU08WHWE4gefKrrokdo3doEgRAmahF99ku7aPEpEWrMZOUokFcKPQKJetmZz1 T0ekW5s/UeoPukE3uDxlblF2JDu//6Q/gzkY69SjAD0mlHdoB8VGUThuiURk8DLXVBni UvMtUpsm2mztTXkErrXQ9s2fjJO/sE74HyONo= MIME-Version: 1.0 Received: by 10.52.23.44 with SMTP id j12mr18591105vdf.117.1325611822063; Tue, 03 Jan 2012 09:30:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 3 Jan 2012 09:30:22 -0800 (PST) In-Reply-To: <201201030924.44493.jhb@freebsd.org> References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> Date: Tue, 3 Jan 2012 09:30:22 -0800 X-Google-Sender-Auth: S3xynVEXk7yekFVk7CRk5MoJMW8 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 03 Jan 2012 17:30:23 -0000 On 3 January 2012 06:24, John Baldwin wrote: >> Working off the cuff, I'd propose the following API: >> >> KERNOPTS=3Dfoo baz >> SRC_FOO =3D foo.c >> SRC_BAZ =3D baz.c >> SRC=3D a.c b.c d.c >> >> And have the magic needed to conditionally add SRC_FOO and SRC_BAZ to SR= C in bsd.kern.mk. I'd be happy with the former to begin with, based on all the options. Devices would be nice too, but that can come later. How about: KERNOPTS=3Dfoo baz KERNDEVICES=3Da b c d e Or if we're goign for linux-like config.mk (which would save on line length issues, for very large kernel config files?): KERNOPTS_foo=3D KERNOPTS_bar=3DXXX KERNOPTS_baz=3DYYY > Not only that, but it would be nice if the list of modules to be built co= uld > be tailored to what options are enabled. =A0For example, if I build a ker= nel that > doesn't have inet or inet6 then it shouldn't try to build ipfw, etc. That'd be nice too, but it's almost like we'd need another domain specific language just to describe how to build sys/modules/Makefile. :-) So how about we do up say, the KERNOPTS field first, which would be a big win. Then KERNDEVICES too, if that's possible? Adrian From owner-freebsd-arch@FreeBSD.ORG Tue Jan 3 19:02:11 2012 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 B2A76106567C; Tue, 3 Jan 2012 19:02:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4F05C8FC1E; Tue, 3 Jan 2012 19:02:11 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q03IulTj010827 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 11:56:49 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 3 Jan 2012 11:56:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 03 Jan 2012 11:56:49 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 03 Jan 2012 19:02:11 -0000 On Jan 3, 2012, at 10:30 AM, Adrian Chadd wrote: > On 3 January 2012 06:24, John Baldwin wrote: >=20 >>> Working off the cuff, I'd propose the following API: >>>=20 >>> KERNOPTS=3Dfoo baz >>> SRC_FOO =3D foo.c >>> SRC_BAZ =3D baz.c >>> SRC=3D a.c b.c d.c >>>=20 >>> And have the magic needed to conditionally add SRC_FOO and SRC_BAZ = to SRC in bsd.kern.mk. >=20 > I'd be happy with the former to begin with, based on all the options. > Devices would be nice too, but that can come later. > How about: >=20 > KERNOPTS=3Dfoo baz > KERNDEVICES=3Da b c d e I think you are misunderstanding what I'm trying to say. This isn't = "options foo and bar from the kernel config file" but rather "please let = me build things based on what's in the opt_foo.h and opt_bar.h files" > Or if we're goign for linux-like config.mk (which would save on line > length issues, for very large kernel config files?): >=20 > KERNOPTS_foo=3D > KERNOPTS_bar=3DXXX > KERNOPTS_baz=3DYYY >=20 >> Not only that, but it would be nice if the list of modules to be = built could >> be tailored to what options are enabled. For example, if I build a = kernel that >> doesn't have inet or inet6 then it shouldn't try to build ipfw, etc. >=20 > That'd be nice too, but it's almost like we'd need another domain > specific language just to describe how to build sys/modules/Makefile. > :-) Right now MODULES_OVERRIDE provides an adequate hook for this. > So how about we do up say, the KERNOPTS field first, which would be a > big win. Then KERNDEVICES too, if that's possible? I'd only planned on doing KERNOPTS :) Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Jan 3 19:06:20 2012 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 D2AB81065675; Tue, 3 Jan 2012 19:06:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE508FC14; Tue, 3 Jan 2012 19:06:20 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so22029467vbb.13 for ; Tue, 03 Jan 2012 11:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5yWKIilFpMNS8dHMAw6S66KiyLWz0dBzMkvcHdl3xTs=; b=gHhuccdXTOcoOGlh34Sod9SLHY0NFaau5kKL9vrAWmtSDmNcntr7heXqQ2CPeet7Ir fBMFj3RCpoPikSTdLLe3S2b/HSFb/PH39gjrz1hDVoGKSgNbNERsXnvfeFW7Q1Vf/XF0 MxQeZFCilCjrlwnLC9B7ILs6L5Nv1bl3lRY3o= MIME-Version: 1.0 Received: by 10.52.33.99 with SMTP id q3mr24998668vdi.100.1325617579533; Tue, 03 Jan 2012 11:06:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 3 Jan 2012 11:06:19 -0800 (PST) In-Reply-To: References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> Date: Tue, 3 Jan 2012 11:06:19 -0800 X-Google-Sender-Auth: 9mll4FjkteClk7czJyVtwUM4p_I Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 03 Jan 2012 19:06:20 -0000 On 3 January 2012 10:56, Warner Losh wrote: >> So how about we do up say, the KERNOPTS field first, which would be a >> big win. Then KERNDEVICES too, if that's possible? > > I'd only planned on doing KERNOPTS :) KERNOPTS would be fine for now. That at least gets me out of my initial issues with wlan/ath building and the fun in handling options. Thanks, Adrian From owner-freebsd-arch@FreeBSD.ORG Tue Jan 3 23:38:17 2012 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 A97C11065672; Tue, 3 Jan 2012 23:38:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 383308FC08; Tue, 3 Jan 2012 23:38:17 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q03NVhZo012969 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 16:31:44 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 3 Jan 2012 16:31:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 03 Jan 2012 16:31:45 -0700 (MST) Cc: John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 03 Jan 2012 23:38:17 -0000 On Jan 3, 2012, at 12:06 PM, Adrian Chadd wrote: > On 3 January 2012 10:56, Warner Losh wrote: >=20 >>> So how about we do up say, the KERNOPTS field first, which would be = a >>> big win. Then KERNDEVICES too, if that's possible? >>=20 >> I'd only planned on doing KERNOPTS :) >=20 > KERNOPTS would be fine for now. That at least gets me out of my > initial issues with wlan/ath building and the fun in handling options. Please find enclosed a proposed patch. This will not build, of course, = since there's no file in the tree mesh_baby.c, so if you have = IEEE80211_SUPPORT_MESH defined, it won't work. It keys off the actual = define. It even works with devices (which define DEV_xxx), but only if you have = it in the options file like isa (eg, you need to tell config to generate = it). Comments? Warner Index: conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- conf/kmod.mk (revision 229436) +++ conf/kmod.mk (working copy) @@ -324,7 +324,16 @@ ${_src}: ln -sf ${KERNBUILDDIR}/${_src} ${.TARGET} .endif +.if exists(${KERNBUILDDIR}/${_src}) +_opts!=3Dcut -d' ' -f 2 ${KERNBUILDDIR}/${_src} +.for _o in ${_opts} +KERNOPT_${_o}=3D1 +.if defined(SRCS_${_o}) +SRCS+=3D${SRCS_${_o}} +.endif .endfor +.endif +.endfor .else .for _src in ${SRCS:Mopt_*.h} CLEANFILES+=3D ${_src} Index: modules/ath/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- modules/ath/Makefile (revision 229436) +++ modules/ath/Makefile (working copy) @@ -41,6 +41,7 @@ SRCS+=3D ah_osdep.c ah.c ah_regdomain.c ah_eeprom_v3.c SRCS+=3D device_if.h bus_if.h pci_if.h opt_inet.h opt_ath.h opt_ah.h = opt_wlan.h =20 +SRCS_IEEE80211_SUPPORT_MESH=3Dmesh_baby.c # # AR5210 support; these are first generation 11a-only devices. # From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 00:12:23 2012 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 EA3D9106566C; Wed, 4 Jan 2012 00:12:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 820008FC08; Wed, 4 Jan 2012 00:12:23 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so22189803vcb.13 for ; Tue, 03 Jan 2012 16:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JuONW7Fx/Ew6G/MUJrPv7UxqvRBuoH7NIfNVF1/zaAo=; b=LBirx1vmxfe5gkHzyEfjc2kDh8BEZiNos1ZaKbom2y36EcTovxVaeyRIyIoLOpTgxR 5DO7Lb5io7Ac0taIgwS2COvTQcIGXRPGxYrPmZjHqc+jQb7CsU0TDnitI6CfmPgS2WjJ 9h+CiF8H1tpXXqcxL3agDl7P4HmtxvYSwjNPU= MIME-Version: 1.0 Received: by 10.220.148.201 with SMTP id q9mr11092196vcv.33.1325635942667; Tue, 03 Jan 2012 16:12:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Tue, 3 Jan 2012 16:12:22 -0800 (PST) In-Reply-To: References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> Date: Tue, 3 Jan 2012 16:12:22 -0800 X-Google-Sender-Auth: n_S2lKTAu5uw6eTAjv3Zsd02i2I Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 04 Jan 2012 00:12:24 -0000 On 3 January 2012 15:31, Warner Losh wrote: > Please find enclosed a proposed patch. =A0This will not build, of course,= since there's no file in the tree mesh_baby.c, so if you have IEEE80211_SU= PPORT_MESH defined, it won't work. =A0It keys off the actual define. > > It even works with devices (which define DEV_xxx), but only if you have i= t in the options file like isa (eg, you need to tell config to generate it)= . > > Comments? I don't strictly need the SRCS line just yet - I can wrap it up in an if: (not correct make fu, but you get the idea): .if (KERNOPT_IEEE80211_SUPPORT_MESH =3D=3D 1) SRCS+=3D ieee80211_mesh.c .endif .if (KERNOPT_IEEE80211_SUPPORT_TDMA =3D=3D 1) SRCS+=3D ieee80211_tdma.c .endif What do you mean about DEV_xxx? Can you give me an example to look at in the sys directory? Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 01:32:43 2012 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 C3208106566B; Wed, 4 Jan 2012 01:32:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 616798FC0A; Wed, 4 Jan 2012 01:32:43 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q041VBGr013707 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 18:31:12 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 3 Jan 2012 18:31:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B845928-5DDC-4DB8-BFD5-1A0599D261EC@bsdimp.com> References: <15285562-E9BA-431B-A2C1-D0547DFB2663@bsdimp.com> <201201030924.44493.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 03 Jan 2012 18:31:12 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: Request for help: how do teach module building about kernel options? 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, 04 Jan 2012 01:32:43 -0000 On Jan 3, 2012, at 5:12 PM, Adrian Chadd wrote: > On 3 January 2012 15:31, Warner Losh wrote: >=20 >> Please find enclosed a proposed patch. This will not build, of = course, since there's no file in the tree mesh_baby.c, so if you have = IEEE80211_SUPPORT_MESH defined, it won't work. It keys off the actual = define. >>=20 >> It even works with devices (which define DEV_xxx), but only if you = have it in the options file like isa (eg, you need to tell config to = generate it). >>=20 >> Comments? >=20 > I don't strictly need the SRCS line just yet - I can wrap it up in an > if: (not correct make fu, but you get the idea): >=20 > .if (KERNOPT_IEEE80211_SUPPORT_MESH =3D=3D 1) > SRCS+=3D ieee80211_mesh.c > .endif >=20 > .if (KERNOPT_IEEE80211_SUPPORT_TDMA =3D=3D 1) > SRCS+=3D ieee80211_tdma.c > .endif The problem with this method is the chicken/egg problem. These defines = aren't defined until after kmod.mk has been included. But the kmod.mk = files depend, in some places, on having a full list. The = SRCS_IEE80211_SUPPORT_MESH solves this problem nicely. > What do you mean about DEV_xxx? Can you give me an example to look at > in the sys directory? isa. Look at sys/conf/options* to see what I'm talking about. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 12:54:52 2012 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 53E7E106567C; Wed, 4 Jan 2012 12:54:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 28CF58FC08; Wed, 4 Jan 2012 12:54:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id BB5A946B2A; Wed, 4 Jan 2012 07:54:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D738B924; Wed, 4 Jan 2012 07:54:51 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 4 Jan 2012 07:45:28 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201040745.28306.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jan 2012 07:54:51 -0500 (EST) Cc: Adrian Chadd Subject: Re: Request for help: how do teach module building about kernel options? 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, 04 Jan 2012 12:54:52 -0000 On Tuesday, January 03, 2012 6:31:37 pm Warner Losh wrote: > > On Jan 3, 2012, at 12:06 PM, Adrian Chadd wrote: > > > On 3 January 2012 10:56, Warner Losh wrote: > > > >>> So how about we do up say, the KERNOPTS field first, which would be a > >>> big win. Then KERNDEVICES too, if that's possible? > >> > >> I'd only planned on doing KERNOPTS :) > > > > KERNOPTS would be fine for now. That at least gets me out of my > > initial issues with wlan/ath building and the fun in handling options. > > Please find enclosed a proposed patch. This will not build, of course, since there's no file in the tree mesh_baby.c, so if you have IEEE80211_SUPPORT_MESH defined, it won't work. It keys off the actual define. > > It even works with devices (which define DEV_xxx), but only if you have it in the options file like isa (eg, you need to tell config to generate it). > > Comments? I like this, nice and simple. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 16:03:43 2012 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 0D4491065670; Wed, 4 Jan 2012 16:03:43 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id AA2298FC1B; Wed, 4 Jan 2012 16:03:42 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BF666409B4; Wed, 4 Jan 2012 16:03:41 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2012 17:03:41 +0100 Message-Id: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> To: freebsd-arch@freebsd.org, Marius Strobl Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Subject: Extending sys/dev/mii 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, 04 Jan 2012 16:03:43 -0000 As discussed recently, ray@, adrian@ and myself are trying to get a = framework and utility into the tree that allows the use and = configuration of ethernet switch chips. The switch controllers we've = looked at so far share a number of features, in particular they use = 802.3 MII, MDIO and PHYs to implement and configure the ports they = offer. In addition to being a switch, some of them also offer one of = the built-in PHYs to the ethernet controller as a classical PHY. Since the switch is already using MDIO and PHYs, it seems sensible to = reuse the existig sys/dev/mii code. However, the current code assumes a = simple model where the ethernet controller has one MAC and an MDIO = master, and the PHYs are attached to these two busses. In addition, the = code assumes that all attached child drivers of an miibus will always be = PHY drivers (using custom dispatch table, specific ivars, etc.) I'd like to extend miibus in such a way that the one-to-one mapping = between MDIO and MII is broken up. For that, I propose to add a new bus = driver "mdiobus" (with appropriate resource management) that uses = methods similar to miibus_if.m readreg and writereg to access an = ethernet controllers' MDIO master. miibus then attaches to it as a = child, claims one or more PHY addresses and attaches PHYs to itself (as = currently implemented). This allows our new switch drivers to attach to the mdiobus as children = and claim appropriate PHY addresses as resources, as well. The current miibus code assumes that it is attached to the ethernet = driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY = link changes. Since the parent will now be the mdiobus, miibus needs = effectively two attachments, one to the provider of the MDIO access, the = other for the ethernet interface. I propose to associate the ethernet = interface by a modified mii_attach() function that takes a device_t (of = the ethernet driver) instead of the two callback function pointers. At the same time, I'd like to unravel the use of callbacks in miibus and = in the PHY drivers. On the one hand the miibus_if.m has three callbacks = (statchg, linkchg, mediainit), on the other hand the bus keeps three = function pointers (mii_data.mii_readreg, mii_writereg, mii_statchg) that = it never uses(?), plus two others (miibus_ivars.ifmedia_upd and = ifmedia_sts) that are regularly called to provide link updates to the = interface. I would be interested to learn why these are spread out like = this (hysterical raisins?), and why they can't just be handled in the = usual bus method manner. (Documentation wouldn't hurt either :-) Despite this long description, I believe that the code changes are = relatively minor. The major issue is the proposed ABI change for the = callback functions, which probably will involve updating all drivers = calling mii_attach(). It might be possible to have the existing = function provide a compatibility wrapper around the new attachment code. There's one issue that I don't have a proposal for yet: in one platform = (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while = it is being controlled via the switch controller's MDIO master, and the = switch controller being attached to arge1's MDIO. If we want to attach = an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 = has been probed and can provide the MDIO attachment (and transitively = the switch and it's mdio). Note that we also have boards without a = switch, but the two PHYs still being attached to only a single MDIO. = One possible way would be for the MDIO driver to be separate from the = ethernet driver, so that the normal newbus dependency resolution can be = used to ensure that mdio1 is attached before arge0 is probed. For the = time being, I've worked around this through hackery in if_arge.c. I currently have some parts of this implemented to the point where the = PHY in the switch is properly working together with arge0. I hope to = have a complete patch for review in a couple of weeks, but I'd = appreciate comments on the general approach I have outlined here. You can find my current code in the work/ath branch at = http://www.gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work. = I've written up a couple of points about the ethernet switch work at = http://wiki.freebsd.org/StefanBethke/EtherSwitch. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 17:08:16 2012 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 2620D1065710; Wed, 4 Jan 2012 17:08:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A049C8FC12; Wed, 4 Jan 2012 17:08:15 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so23006136vcb.13 for ; Wed, 04 Jan 2012 09:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kkz3pSLe347C0i4MJWVuj/d1WVshWqockYSfD2oVf0M=; b=ZF4GueV3eP75LmHkDOb5gtSIWlFsVcj7OfupvezYKWs7qFBzRLQ2RZ85jpwoiqkklf SWzBv3Ed5yyCVF48HXtfvgB4Ub6ewchkblUb9dPPQlcMC1PWX+qE1a7FZ42UW9F3Oroz ZY1nd3ow1GBIKGDiyNexmvfa8/KJjmAZCaM8Q= MIME-Version: 1.0 Received: by 10.220.213.137 with SMTP id gw9mr33087912vcb.3.1325696894732; Wed, 04 Jan 2012 09:08:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 4 Jan 2012 09:08:14 -0800 (PST) In-Reply-To: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> Date: Wed, 4 Jan 2012 09:08:14 -0800 X-Google-Sender-Auth: 4a9C4B-gj9zvtawsZYYdO9BmStg Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Marius Strobl , freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 04 Jan 2012 17:08:16 -0000 I'm including -net here so we can try and pull in further feedback from network-cluey people. On 4 January 2012 08:03, Stefan Bethke wrote: > As discussed recently, ray@, adrian@ and myself are trying to get a frame= work and utility into the tree that allows the use and configuration of eth= ernet switch chips. =A0The switch controllers we've looked at so far share = a number of features, in particular they use 802.3 MII, MDIO and PHYs to im= plement and configure the ports they offer. =A0In addition to being a switc= h, some of them also offer one of the built-in PHYs to the ethernet control= ler as a classical PHY. [snip] > I'd like to extend miibus in such a way that the one-to-one mapping betwe= en MDIO and MII is broken up. =A0For that, I propose to add a new bus drive= r "mdiobus" (with appropriate resource management) that uses methods simila= r to miibus_if.m readreg and writereg to access an ethernet controllers' MD= IO master. =A0miibus then attaches to it as a child, claims one or more PHY= addresses and attaches PHYs to itself (as currently implemented). This sounds like a good idea. I wonder what's stopping us from doing that. = :) > There's one issue that I don't have a proposal for yet: in one platform (= AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it i= s being controlled via the switch controller's MDIO master, and the switch = controller being attached to arge1's MDIO. =A0If we want to attach an miibu= s for PHY4, we'd have to defer attachment of arge0 until arge1 has been pro= bed and can provide the MDIO attachment (and transitively the switch and it= 's mdio). =A0Note that we also have boards without a switch, but the two PH= Ys still being attached to only a single MDIO. =A0One possible way would be= for the MDIO driver to be separate from the ethernet driver, so that the n= ormal newbus dependency resolution can be used to ensure that mdio1 is atta= ched before arge0 is probed. =A0For the time being, I've worked around this= through hackery in if_arge.c. juli@ proposed something quite similar a few weeks ago. Now that I'm a little more clued up on this whole area, I now understand why she suggested it. I'm happy with "hacky" being in if_arge for now (I mean, there already _is_ ..) but this work seems like the right path to take to bring sanity to this whole setup in the longer term. Thanks for tackling this! Adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 22:25:59 2012 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 DA694106564A for ; Wed, 4 Jan 2012 22:25:59 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 42DA48FC12 for ; Wed, 4 Jan 2012 22:25:58 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q04LxUtc083348; Wed, 4 Jan 2012 22:59:30 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q04LxURA083347; Wed, 4 Jan 2012 22:59:30 +0100 (CET) (envelope-from marius) Date: Wed, 4 Jan 2012 22:59:30 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120104215930.GM90831@alchemy.franken.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 04 Jan 2012 22:25:59 -0000 On Wed, Jan 04, 2012 at 05:03:41PM +0100, Stefan Bethke wrote: > As discussed recently, ray@, adrian@ and myself are trying to get a framework and utility into the tree that allows the use and configuration of ethernet switch chips. The switch controllers we've looked at so far share a number of features, in particular they use 802.3 MII, MDIO and PHYs to implement and configure the ports they offer. In addition to being a switch, some of them also offer one of the built-in PHYs to the ethernet controller as a classical PHY. > > Since the switch is already using MDIO and PHYs, it seems sensible to reuse the existig sys/dev/mii code. The intention of miibus(4) was to factor out the common code for handling PHYs conforming to IEEE 802.3, specifically chapter 22. Before Ethernet drivers for controllers that have an MII interface duplicated that code over and over again. The problem with switches is that even if they ave an MII management interface they often don't comply with IEEE 802.3 (also note that chapter 22 right at the beginning says that the MII is for connecting MACs with PHYs) in that they don't implement the basic registers and/ or the ID registers and/or implement something entirely different at the same addresses. Also a switch with an MII isn't necessarily connected to a MAC in he first place, f.e. you could simply drive it via bitbanging using GPIOs of a microcontroller. All that stuff makes it rather hard to support these with a generic framework that's laid out around IEEE 802.3. That's also why I think that miibus(4) isn't the right vehicle to support all these kinds of switches even if they have an MII interface. If the idea is to only support those via miibus(4) that actually hang off of a MAC and act like a IEEE 802.3 PHY I'm fine with that though. > However, the current code assumes a simple model where the ethernet controller has one MAC and an MDIO master, and the PHYs are attached to these two busses. In addition, the code assumes that all attached child drivers of an miibus will always be PHY drivers (using custom dispatch table, specific ivars, etc.) I'd say that description is to strict. Currently the only real "limiting" factor is that miibus(4) attaches and adds ifmedia and while that only partly makes sense for a switch when it's connected to a MAC it completely doesn't if there's no MAC. But as far as miibus(4) goes its parent doesn't necessarily need to be a MAC driver and also while it's children need to have a mii_softc or at least a softc that begins with a struct mii_softc for the most part you could also just ignore that miibus(4) assigns instance variables to it and a child also doesn't necessarily need to do anything in the mii_phy_funcs that are part of the mii_softc. A child of the miibus(4) could also just sit there and twiddle some registers of something that isn't a PHY but then the question is why you'd want to handle the whole thing via miibus(4) in the first place ... > > I'd like to extend miibus in such a way that the one-to-one mapping between MDIO and MII is broken up. For that, I propose to add a new bus driver "mdiobus" (with appropriate resource management) that uses methods similar to miibus_if.m readreg and writereg to access an ethernet controllers' MDIO master. miibus then attaches to it as a child, claims one or more PHY addresses and attaches PHYs to itself (as currently implemented). > > This allows our new switch drivers to attach to the mdiobus as children and claim appropriate PHY addresses as resources, as well. This generally sounds fine so far. > > The current miibus code assumes that it is attached to the ethernet driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY link changes. That's not correct. It's true that miibus(4) calls the statchg method of its parent but that doesn't necessarily need to be an Ethernet driver. It could as well be mdiobus(4) which then bubbles up the request to the Ethernet driver (if there is one). Actually that's one of the benefits of newbus. In the past there was a requirement that the parent had the ifnet pointer at the beginning of it's softc but I fixed that with the introduction of mii_attach() so you now can supply a ifnet pointer from anywhere higher in the hierarchy you want. > Since the parent will now be the mdiobus, miibus needs effectively two attachments, one to the provider of the MDIO access, the other for the ethernet interface. I propose to associate the ethernet interface by a modified mii_attach() function that takes a device_t (of the ethernet driver) instead of the two callback function pointers. Again I see no technical reason for such a change. While it would be nice to only need to pass one pointer around instead of two this IMO doesn't outweight the churn throughout all MAC drivers and the ABI breakage this would cause, which means that such a change can't be MFC'ed, needs #ifdefs on drivers that are maintained as multi- release versions etc. It could very well be that there actually is the technical necessity to change the API of mii_attach() in order to support switch PHYs but so far you failed to make clear what that would be. > At the same time, I'd like to unravel the use of callbacks in miibus and in the PHY drivers. On the one hand the miibus_if.m has three callbacks (statchg, linkchg, mediainit), on the other hand the bus keeps three function pointers (mii_data.mii_readreg, mii_writereg, mii_statchg) that it never uses(?), plus two others (miibus_ivars.ifmedia_upd and ifmedia_sts) that are regularly called to provide link updates to the interface. I would be interested to learn why these are spread out like this (hysterical raisins?), and why they can't just be handled in the usual bus method manner. (Documentation wouldn't hurt either :-) Just read the comments and the VCS history; mii{,bus}(4) origins in BSD/OS and was reimplemented in NetBSD using a compatible API. >From there it was ported/copied to OpenBSD and also ported to FreeBSD. The FreeBSD implementation is a compromise between integrating it with newbus and maintaining API-compatibility with NetBSD (to-date the FreeBSD miibus(4) actually is still highly API-compatible with NetBSD; if you use the helper functions FreeBSD has grown since then all it really takes to port a PHY driver from NetBSD is to replace some headers and to adjust the arguments of the probe and attach methods). The newbus integration without doubts could have been done a bit better in some respects though. The mii_readreg, mii_writereg and mii_statchg pointers of struct mii_data you mention are what NetBSD and OpenBSD use instead of the newbus interface. I'm aware that they are unused in FreeBSD and they probably were forgotten to be removed when the code was ported over. Though as they already were there I decided to keep them as placeholders in case we wanted to MFC an otherwise ABI-breaking change extending struct mii_data back. It might make sense to rename them in order to make it clear that they only serve as placeholders. The ifmedia_upd and ifmedia_sts pointers could be implemented as newbus methods as well but given that these are passed to ifmedia_init(9) using pointers passed via instance variables probably was the more straight forward approach given that you don't really need to support a hierarchy here. > > Despite this long description, I believe that the code changes are relatively minor. The major issue is the proposed ABI change for the callback functions, which probably will involve updating all drivers calling mii_attach(). It might be possible to have the existing function provide a compatibility wrapper around the new attachment code. Please elaborate on why these changes are technically necessary to implement what you are trying do. Otherwise I prefer to avoid them given the rototilling they'd cause. > > There's one issue that I don't have a proposal for yet: in one platform (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it is being controlled via the switch controller's MDIO master, and the switch controller being attached to arge1's MDIO. If we want to attach an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 has been probed and can provide the MDIO attachment (and transitively the switch and it's mdio). Note that we also have boards without a switch, but the two PHYs still being attached to only a single MDIO. One possible way would be for the MDIO driver to be separate from the ethernet driver, so that the normal newbus dependency resolution can be used to ensure that mdio1 is attached before arge0 is probed. For the time being, I've worked around this through hackery in if_arge.c. > What I proposed here to properly deal with this case is to multiplex the MII sharing above the MAC drivers, which then also is independent of the probe order: http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030646.html With your latter approach it's unclear to me how you would link mdio1 and arge0, which would be siblings on the same bus if I get you right, i.e. either you attach miibus(4) to mdio(4) and then would need to pass the status and update handlers of arge0 to mdio1 or you attach miibus(4) to arge1 and then would need to somehow access the MII readreg and writereg methods of mdio1 there. Marius From owner-freebsd-arch@FreeBSD.ORG Wed Jan 4 23:39:24 2012 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 9F68C106566C for ; Wed, 4 Jan 2012 23:39:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 131608FC12 for ; Wed, 4 Jan 2012 23:39:24 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 40A542A2A387; Thu, 5 Jan 2012 00:39:23 +0100 (CET) Date: Thu, 5 Jan 2012 00:39:23 +0100 From: Ed Schouten To: Marcel Moolenaar Message-ID: <20120104233923.GY1895@hoeg.nl> References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zNngJsVJxur72n6A" Content-Disposition: inline In-Reply-To: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Arch Subject: Re: ntohq/htonq? 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, 04 Jan 2012 23:39:24 -0000 --zNngJsVJxur72n6A Content-Type: multipart/mixed; boundary="GpIToxGFjxEkdZJB" Content-Disposition: inline --GpIToxGFjxEkdZJB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marcel, others, * Marcel Moolenaar , 20110914 04:36: > I did some googling and htonq and ntohq seem to be de > facto names used, but oddly enough no OS has them defined. > It's surreal. Are there better alternatives we should > migrate to? I just sent a patch to stefanf@ to change to be built on top of a new macro __generic(), which can act as a transition aid towards C11's _Generic(). If we really want to add support for htonq() and ntohq(), I would rather see us gain a hton() and ntoh() that are implemented as type-generic macros. That way we won't up having htonllll() by the year 2050. Also, it will allow people to `wrap' it into more fancy macros: #define DECODE_FIELD(x) do { foo->a_ ## x =3D ntoh(bar->b_ ## x); } while (= 0) Proof of concept patch (for illustration purposes only) for attached to this email. --=20 Ed Schouten WWW: http://80386.nl/ --GpIToxGFjxEkdZJB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="endian.diff" Content-Transfer-Encoding: quoted-printable Index: sys/sys/cdefs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/cdefs.h (revision 229516) +++ sys/sys/cdefs.h (working copy) @@ -248,6 +248,24 @@ #endif #endif =20 +/* + * Emulation of C11 _Generic(). Unlike the previously defined C11 + * keywords, it is not possible to implement this using exactly the same + * syntax. Therefore implement something similar under the name + * __generic(). Unlike _Generic(), this macro can only distinguish + * between a single type, so it requires nested invocations to + * distinguish multiple cases. + */ + +#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 201112L +#define __generic(expr, t, yes, no) \ + _Generic(expr, t: yes, default: no) +#elif __GNUC_PREREQ__(3, 1) +#define __generic(expr, t, yes, no) \ + __builtin_choose_expr( \ + __builtin_types_compatible_p(__typeof(expr), t), yes, no) +#endif + #if __GNUC_PREREQ__(2, 96) #define __malloc_like __attribute__((__malloc__)) #define __pure __attribute__((__pure__)) Index: sys/sys/endian.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/endian.h (revision 229516) +++ sys/sys/endian.h (working copy) @@ -202,4 +202,27 @@ le32enc(p + 4, (uint32_t)(u >> 32)); } =20 +#ifdef __generic + +/* + * Type-generic byte order macros. + */ + +#define __endian_op(x, func16, func32, func64) \ + __endian_op2(x, 8, x, \ + __endian_op2(x, 16, func16, \ + __endian_op2(x, 32, func32, \ + __endian_op2(x, 64, func64, (void)0)))) +#define __endian_op2(x, size, func, rest) \ + __generic(x, __uint ## size ## _t, func, \ + __generic(x, __int ## size ## _t, func, rest)) + +#define bswap(x) __endian_op(x, bswap16(x), bswap32(x), bswap64(x)) +#define htobe(x) __endian_op(x, htobe16(x), htobe32(x), htobe64(x)) +#define betoh(x) __endian_op(x, be16toh(x), be32toh(x), be64toh(x)) +#define htole(x) __endian_op(x, htole16(x), htole32(x), htole64(x)) +#define letoh(x) __endian_op(x, le16toh(x), le32toh(x), le64toh(x)) + +#endif /* __generic */ + #endif /* _SYS_ENDIAN_H_ */ --GpIToxGFjxEkdZJB-- --zNngJsVJxur72n6A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPBOMqAAoJEG5e2P40kaK71d4QAKP8oEk74xaVKOFzAaHqeYVi wrZ+CcOlGSmemQNGsk10co7+96LOxiaMjskShbY/ZiayONJTKTRHfee6wlQmaM4/ 8a843MDCf8pLbpYN4m1H7Yl98AyH5P5Rt4Mi7vloo6WPzQmueci9nm0JtIkHiARC 8buzpBqsuSODMpmRVbHd15JDTwUz1OWDWaJ+vkXKEbUpT00F12WTxxikiFls5iv7 ra1NOaLJgp7+I2b3dhoTFeymFFdHaRFravyl2VE38HxqpZfVC+zxJ+pdezyMNvA6 IhL6ya8BE+xEoapmA1Pmu9I9I6Cel7aIciGiNW+DpQDxQco6vO5bZKgN4g+H+VzG 8RAu2q7Wka/j17nmkFJ71h9bM9BXFeuoOnKCssiwZsZdjwbCr0onUkO1cIYwvXNX NWzA2QrG3Q/P2lX3cID8LpEKwHNXkUlzSF5nm6mqrMDmkUacN5blwlHIV0d/zTVj 9sYr+LugS4RJilthJSWZx40d5bNKa2pFnJvFoPbKkM+g9NGQRXEAlCtquoVzMBd4 XVOmOY6Lqfe13PsmA6cJvfx4t3S5wWFFT3tPC635jxnuuT3/gGJ7g4erdsgMk2u9 TUhe1wdgXcwy+ILPtTu/cuDjSHwoqbRhkQ+wyG8P2q34DpsI2DJYfap72Ip1veMv JO0Kit2XUfPr8jIYBHmK =Ht6m -----END PGP SIGNATURE----- --zNngJsVJxur72n6A-- From owner-freebsd-arch@FreeBSD.ORG Thu Jan 5 07:57:47 2012 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 C4FD5106566C; Thu, 5 Jan 2012 07:57:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB158FC08; Thu, 5 Jan 2012 07:57:45 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so336778vbb.13 for ; Wed, 04 Jan 2012 23:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=NnUQm+so8EsZCtaRNLd0CSQelC9+kFIQk6Xgde9em1w=; b=dM9coviIXtFZFHyY3f09uWHj93jSfTLn5H25GtlcgIOEzbPsvzMyvqwmV2XwoOVZ/z rLHPo1Uam6hzw1+VTcPCRV3rzzn82fTYq6dzsqxh1l2SrV5IDymjSXEiZ9GSI1BjsjfE p0TAvXSKuPADOAQOAGX1SAo4ybFL0Je59/DEw= MIME-Version: 1.0 Received: by 10.52.33.99 with SMTP id q3mr381210vdi.100.1325750264895; Wed, 04 Jan 2012 23:57:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 4 Jan 2012 23:57:44 -0800 (PST) Date: Wed, 4 Jan 2012 23:57:44 -0800 X-Google-Sender-Auth: deumgNbsHau7Q5Qgx30ieF70xUA Message-ID: From: Adrian Chadd To: freebsd-arch@freebsd.org, freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? 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, 05 Jan 2012 07:57:47 -0000 Hi, I'm trying to slim down the freebsd kernel to fit on some devices with 4MB of flash. Since I'm not using NFS or UFS_ACL, I wondered if that code required. It turns out I can just build a kernel with those two disabled. Would it be possible to remove them from "standard" and make them optional? Or is there a reason to keep it in base? If so (eg so things can be kldload'ed that uses the ACL code) can we make it a build-time option, and/or a pair of loadable kernel modules? Thanks, Adrian From owner-freebsd-arch@FreeBSD.ORG Thu Jan 5 10:39:42 2012 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 4AC8D1065672 for ; Thu, 5 Jan 2012 10:39:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E5F9A8FC14 for ; Thu, 5 Jan 2012 10:39:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1054F62A0; Thu, 5 Jan 2012 10:39:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E408B8CB8; Thu, 5 Jan 2012 11:39:40 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: Date: Thu, 05 Jan 2012 11:39:40 +0100 In-Reply-To: (Adrian Chadd's message of "Wed, 4 Jan 2012 23:57:44 -0800") Message-ID: <86ty4a8mc3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? 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, 05 Jan 2012 10:39:42 -0000 Adrian Chadd writes: > Since I'm not using NFS or UFS_ACL, I wondered if that code required. > It turns out I can just build a kernel with those two disabled. > > Would it be possible to remove them from "standard" and make them > optional? Or is there a reason to keep it in base? I would be very annoyed if it were no longer possible to netboot GENERIC... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jan 5 13:48:20 2012 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 70C54106564A; Thu, 5 Jan 2012 13:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 42C138FC12; Thu, 5 Jan 2012 13:48:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id EE7FC46B0D; Thu, 5 Jan 2012 08:48:19 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78918B971; Thu, 5 Jan 2012 08:48:19 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 5 Jan 2012 08:48:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201050848.18414.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Jan 2012 08:48:19 -0500 (EST) Cc: freebsd-fs@freebsd.org, Adrian Chadd , freebsd-current Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? 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, 05 Jan 2012 13:48:20 -0000 [ A bit excessive on the cross-posting? arch@ alone was probably fine ] On Thursday, January 05, 2012 2:57:44 am Adrian Chadd wrote: > Hi, > > I'm trying to slim down the freebsd kernel to fit on some devices with > 4MB of flash. > > Since I'm not using NFS or UFS_ACL, I wondered if that code required. > It turns out I can just build a kernel with those two disabled. > > Would it be possible to remove them from "standard" and make them > optional? Or is there a reason to keep it in base? > If so (eg so things can be kldload'ed that uses the ACL code) can we > make it a build-time option, and/or a pair of loadable kernel modules? NFS doesn't actually use them curently, only UFS and ZFS do. Unfortunately we've yet to make it possible to compile ZFS into the kernel, so you can't make the sys/conf/files bits completely accurate yet (it would be nice to let folks who don't need FFS for a ZFS-only system remove FFS and UFS, but this would break that): Index: files =================================================================== --- files (revision 229491) +++ files (working copy) @@ -2393,8 +2393,9 @@ kern/sched_ule.c optional sched_ule kern/serdev_if.m standard kern/stack_protector.c standard \ compile-with "${NORMAL_C:N-fstack-protector*}" -kern/subr_acl_nfs4.c standard -kern/subr_acl_posix1e.c standard +# XXX: subr_acl_nfs4.c is also used by ZFS +kern/subr_acl_nfs4.c optional ufs_acl +kern/subr_acl_posix1e.c optional ufs_acl kern/subr_autoconf.c standard kern/subr_blist.c standard kern/subr_bus.c standard -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jan 5 20:52:41 2012 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 35DF1106566C for ; Thu, 5 Jan 2012 20:52:41 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1DF8FC1E for ; Thu, 5 Jan 2012 20:52:40 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 5EC8B118250; Thu, 5 Jan 2012 20:52:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Stefan Bethke In-Reply-To: <20120104215930.GM90831@alchemy.franken.de> Date: Thu, 5 Jan 2012 21:52:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 05 Jan 2012 20:52:41 -0000 Thank you for your extensive reply, that really helps my understanding = of the code! Am 04.01.2012 um 22:59 schrieb Marius Strobl: > On Wed, Jan 04, 2012 at 05:03:41PM +0100, Stefan Bethke wrote: >> As discussed recently, ray@, adrian@ and myself are trying to get a = framework and utility into the tree that allows the use and = configuration of ethernet switch chips. The switch controllers we've = looked at so far share a number of features, in particular they use = 802.3 MII, MDIO and PHYs to implement and configure the ports they = offer. In addition to being a switch, some of them also offer one of = the built-in PHYs to the ethernet controller as a classical PHY. >>=20 >> Since the switch is already using MDIO and PHYs, it seems sensible to = reuse the existig sys/dev/mii code. >=20 > The intention of miibus(4) was to factor out the common code for > handling PHYs conforming to IEEE 802.3, specifically chapter 22. > Before Ethernet drivers for controllers that have an MII interface > duplicated that code over and over again. > The problem with switches is that even if they ave an MII management > interface they often don't comply with IEEE 802.3 (also note that > chapter 22 right at the beginning says that the MII is for connecting > MACs with PHYs) in that they don't implement the basic registers and/ > or the ID registers and/or implement something entirely different at > the same addresses. Also a switch with an MII isn't necessarily > connected to a MAC in he first place, f.e. you could simply drive it > via bitbanging using GPIOs of a microcontroller. All that stuff makes > it rather hard to support these with a generic framework that's > laid out around IEEE 802.3. That's also why I think that miibus(4) > isn't the right vehicle to support all these kinds of switches even > if they have an MII interface. If the idea is to only support those > via miibus(4) that actually hang off of a MAC and act like a IEEE > 802.3 PHY I'm fine with that though. The reason I'm even looking at miibus is to avoid code duplication. I = agree that miibus is not the right driver for switches that do not = implement the .3 PHY register set. *However*, the switch chips that = we're looking at (all part of shipping consumer products that I would = love to be able to run FreeBSD on) implement PHYs with the proper = register set. These PHYs can successfully be driven by ukphy. The hard = part: on some switch models, the MDIO these PHYs are on are not the MDIO = the MII is on. I've drawn three diagrams = (http://wiki.freebsd.org/StefanBethke/EtherSwitch) to illustrate two = existing hardware setups that cannot be supported by miibus with either = changes to miibus (AFAIKT). If you feel that changing miibus to allow this split between MDIO and = MII is not advisable, I can create workarounds, but I'd much rather = avoid writing workarounds. >> However, the current code assumes a simple model where the ethernet = controller has one MAC and an MDIO master, and the PHYs are attached to = these two busses. In addition, the code assumes that all attached child = drivers of an miibus will always be PHY drivers (using custom dispatch = table, specific ivars, etc.) >=20 > I'd say that description is to strict. Currently the only real > "limiting" factor is that miibus(4) attaches and adds ifmedia and > while that only partly makes sense for a switch when it's connected > to a MAC it completely doesn't if there's no MAC. But as far as > miibus(4) goes its parent doesn't necessarily need to be a MAC > driver and also while it's children need to have a mii_softc or > at least a softc that begins with a struct mii_softc for the > most part you could also just ignore that miibus(4) assigns instance > variables to it and a child also doesn't necessarily need to do > anything in the mii_phy_funcs that are part of the mii_softc. > A child of the miibus(4) could also just sit there and twiddle some > registers of something that isn't a PHY but then the question is > why you'd want to handle the whole thing via miibus(4) in the first > place =85 Wouldn't that be rather brittle? miibus has a defined interface (and = with your explanations, I believe I now understand it), so poking around = in the innards and forcing parts into the bus that don't really belong = there feels wrong. >> The current miibus code assumes that it is attached to the ethernet = driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY = link changes. >=20 > That's not correct. It's true that miibus(4) calls the statchg method > of its parent but that doesn't necessarily need to be an Ethernet > driver. It could as well be mdiobus(4) which then bubbles up the > request to the Ethernet driver (if there is one). Actually that's > one of the benefits of newbus. In the past there was a requirement > that the parent had the ifnet pointer at the beginning of it's > softc but I fixed that with the introduction of mii_attach() so > you now can supply a ifnet pointer from anywhere higher in the=20 > hierarchy you want. The problem with this is that the miibus instance might not be a = (transitive) child of the ethernet driver that has the MII that needs to = be adjusted to the new PHY settings. And since the method does not = provide any parameters about which phy or miibus did issue the method, = or which ifp it applies to, bubbling it up won't work (that the scenario = where the PHY for arge0 is connected to the switch's MDIO, which is = attached to arge1's MDIO). >> Since the parent will now be the mdiobus, miibus needs effectively = two attachments, one to the provider of the MDIO access, the other for = the ethernet interface. I propose to associate the ethernet interface = by a modified mii_attach() function that takes a device_t (of the = ethernet driver) instead of the two callback function pointers. >=20 > Again I see no technical reason for such a change. While it would > be nice to only need to pass one pointer around instead of two this > IMO doesn't outweight the churn throughout all MAC drivers and the > ABI breakage this would cause, which means that such a change can't > be MFC'ed, needs #ifdefs on drivers that are maintained as multi- > release versions etc. It could very well be that there actually is > the technical necessity to change the API of mii_attach() in order > to support switch PHYs but so far you failed to make clear what > that would be. See above. [ suggested cleanup of methods and callbacks and history lesson removed = ] >> Despite this long description, I believe that the code changes are = relatively minor. The major issue is the proposed ABI change for the = callback functions, which probably will involve updating all drivers = calling mii_attach(). It might be possible to have the existing = function provide a compatibility wrapper around the new attachment code. >=20 > Please elaborate on why these changes are technically necessary > to implement what you are trying do. Otherwise I prefer to avoid > them given the rototilling they'd cause. Necessary is a strong word. Right now, I'm trying to understand how a = sensible change would even look like, and which combination of glue code = and miibus changes make the most sense. Let me see if I can come up with a prototype patch the next couple of = days, so we don't have to theorize about the changes that might or might = not be necessary. Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 12:57:08 2012 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 62F69106566B for ; Fri, 6 Jan 2012 12:57:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 209818FC13 for ; Fri, 6 Jan 2012 12:57:08 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C31CA118C93; Fri, 6 Jan 2012 12:57:06 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> Date: Fri, 6 Jan 2012 13:57:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 12:57:08 -0000 Am 05.01.2012 um 21:52 schrieb Stefan Bethke: > The problem with this is that the miibus instance might not be a = (transitive) child of the ethernet driver that has the MII that needs to = be adjusted to the new PHY settings. And since the method does not = provide any parameters about which phy or miibus did issue the method, = or which ifp it applies to, bubbling it up won't work (that the scenario = where the PHY for arge0 is connected to the switch's MDIO, which is = attached to arge1's MDIO). >=20 >>> Since the parent will now be the mdiobus, miibus needs effectively = two attachments, one to the provider of the MDIO access, the other for = the ethernet interface. I propose to associate the ethernet interface = by a modified mii_attach() function that takes a device_t (of the = ethernet driver) instead of the two callback function pointers. >>=20 >> Please elaborate on why these changes are technically necessary >> to implement what you are trying do. Otherwise I prefer to avoid >> them given the rototilling they'd cause. >=20 > Necessary is a strong word. Right now, I'm trying to understand how a = sensible change would even look like, and which combination of glue code = and miibus changes make the most sense. >=20 > Let me see if I can come up with a prototype patch the next couple of = days, so we don't have to theorize about the changes that might or might = not be necessary. Here's a patch that causes zero rototilling, if I'm not mistaken. The patch implements the split between the MDIO access and notifications = posted to the ethernet interface device that has the MII that needs to = be adjusted in accordance with the PHY autonegotiation results. I've = added a field to the ivars struct and not the softc, because the softc = is included by many network drivers, while the ivars are private to = mii.c For this reason, I believe this change is API and ABI compatible, = and likely can be MFCed. (I believe MFCing is not high on the priority = list because many other parts in sys/mips would need to be MFCed first = for all the Atheros platforms to become fully usable, but Adrian can = correct me.) A second patch will implement a separate MDIO bus driver, but I haven't = finished that yet. It s completely independent of the above change. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 13:03:30 2012 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 5E135106566C for ; Fri, 6 Jan 2012 13:03:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEC98FC13 for ; Fri, 6 Jan 2012 13:03:29 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 1D79A118CF3; Fri, 6 Jan 2012 13:03:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-3--344543017 From: Stefan Bethke In-Reply-To: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> Date: Fri, 6 Jan 2012 14:03:27 +0100 Message-Id: <331547BD-7CFD-40B3-97C0-2C85B31D03FB@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 13:03:30 -0000 --Apple-Mail-3--344543017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Now with actual patch attached. Thanks ray!) Am 05.01.2012 um 21:52 schrieb Stefan Bethke: > The problem with this is that the miibus instance might not be a = (transitive) child of the ethernet driver that has the MII that needs to = be adjusted to the new PHY settings. And since the method does not = provide any parameters about which phy or miibus did issue the method, = or which ifp it applies to, bubbling it up won't work (that the scenario = where the PHY for arge0 is connected to the switch's MDIO, which is = attached to arge1's MDIO). >=20 >>> Since the parent will now be the mdiobus, miibus needs effectively = two attachments, one to the provider of the MDIO access, the other for = the ethernet interface. I propose to associate the ethernet interface = by a modified mii_attach() function that takes a device_t (of the = ethernet driver) instead of the two callback function pointers. >>=20 >> Please elaborate on why these changes are technically necessary >> to implement what you are trying do. Otherwise I prefer to avoid >> them given the rototilling they'd cause. >=20 > Necessary is a strong word. Right now, I'm trying to understand how a = sensible change would even look like, and which combination of glue code = and miibus changes make the most sense. >=20 > Let me see if I can come up with a prototype patch the next couple of = days, so we don't have to theorize about the changes that might or might = not be necessary. Here's a patch that causes zero rototilling, if I'm not mistaken. The patch implements the split between the MDIO access and notifications = posted to the ethernet interface device that has the MII that needs to = be adjusted in accordance with the PHY autonegotiation results. I've = added a field to the ivars struct and not the softc, because the softc = is included by many network drivers, while the ivars are private to = mii.c For this reason, I believe this change is API and ABI compatible, = and likely can be MFCed. (I believe MFCing is not high on the priority = list because many other parts in sys/mips would need to be MFCed first = for all the Atheros platforms to become fully usable, but Adrian can = correct me.) A second patch will implement a separate MDIO bus driver, but I haven't = finished that yet. It s completely independent of the above change. Stefan --=20 Stefan Bethke Fon +49 151 14070811 --Apple-Mail-3--344543017 Content-Disposition: attachment; filename=mii.diff Content-Type: application/octet-stream; name="mii.diff" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/mii/mii.c b/sys/dev/mii/mii.c index f85c579..ef9421b 100644 --- a/sys/dev/mii/mii.c +++ b/sys/dev/mii/mii.c @@ -106,6 +106,7 @@ driver_t miibus_driver = { struct miibus_ivars { struct ifnet *ifp; + device_t ifdev; ifm_change_cb_t ifmedia_upd; ifm_stat_cb_t ifmedia_sts; u_int mii_flags; @@ -300,11 +301,10 @@ miibus_writereg(device_t dev, int phy, int reg, int data) static void miibus_statchg(device_t dev) { - device_t parent; + struct miibus_ivars *ivars = device_get_ivars(dev); struct mii_data *mii; - parent = device_get_parent(dev); - MIIBUS_STATCHG(parent); + MIIBUS_STATCHG(ivars->ifdev); mii = device_get_softc(dev); mii->mii_ifp->if_baudrate = ifmedia_baudrate(mii->mii_media_active); @@ -313,12 +313,11 @@ miibus_statchg(device_t dev) static void miibus_linkchg(device_t dev) { + struct miibus_ivars *ivars = device_get_ivars(dev); struct mii_data *mii; - device_t parent; int link_state; - parent = device_get_parent(dev); - MIIBUS_LINKCHG(parent); + MIIBUS_LINKCHG(ivars->ifdev); mii = device_get_softc(dev); @@ -335,12 +334,13 @@ miibus_linkchg(device_t dev) static void miibus_mediainit(device_t dev) { + struct miibus_ivars *ivars = device_get_ivars(dev); struct mii_data *mii; struct ifmedia_entry *m; int media = 0; - /* Poke the parent in case it has any media of its own to add. */ - MIIBUS_MEDIAINIT(device_get_parent(dev)); + /* Poke the interface device in case it has any media of its own to add. */ + MIIBUS_MEDIAINIT(ivars->ifdev); mii = device_get_softc(dev); LIST_FOREACH(m, &mii->mii_media.ifm_list, ifm_list) { @@ -361,6 +361,22 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, ifm_change_cb_t ifmedia_upd, ifm_stat_cb_t ifmedia_sts, int capmask, int phyloc, int offloc, int flags) { + return mii_attach_interface(dev, dev, miibus, ifp, ifmedia_upd, + ifmedia_sts, capmask, phyloc, offloc, flags); +} + +/* + * Helper function used by network interface drivers. The mdiodev device + * becomes the parent of the miibus and provides access to the MDIO master + * that communicates with the PHY(s). The ifdev device is the network + * interface driver that will receive MIIBUS_STATCHG, MIIBUS_LINKCHG, and + * MIIBUS_MEDIAINIT messages. Both devices can be the same. + */ +int +mii_attach_interface(device_t mdiodev, device_t ifdev, device_t *miibus, struct ifnet *ifp, + ifm_change_cb_t ifmedia_upd, ifm_stat_cb_t ifmedia_sts, int capmask, + int phyloc, int offloc, int flags) +{ struct miibus_ivars *ivars; struct mii_attach_args *args, ma; device_t *children, phy; @@ -395,10 +411,11 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, if (ivars == NULL) return (ENOMEM); ivars->ifp = ifp; + ivars->ifdev = ifdev; ivars->ifmedia_upd = ifmedia_upd; ivars->ifmedia_sts = ifmedia_sts; ivars->mii_flags = flags; - *miibus = device_add_child(dev, "miibus", -1); + *miibus = device_add_child(mdiodev, "miibus", -1); if (*miibus == NULL) { rv = ENXIO; goto fail; @@ -453,7 +470,7 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, * many braindead PHYs report 0/0 in their ID registers, * so we test for media in the BMSR. */ - bmsr = MIIBUS_READREG(dev, ma.mii_phyno, MII_BMSR); + bmsr = MIIBUS_READREG(mdiodev, ma.mii_phyno, MII_BMSR); if (bmsr == 0 || bmsr == 0xffff || (bmsr & (BMSR_EXTSTAT | BMSR_MEDIAMASK)) == 0) { /* Assume no PHY at this address. */ @@ -478,8 +495,8 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, * the `ukphy' driver, as we have no ID information to * match on. */ - ma.mii_id1 = MIIBUS_READREG(dev, ma.mii_phyno, MII_PHYIDR1); - ma.mii_id2 = MIIBUS_READREG(dev, ma.mii_phyno, MII_PHYIDR2); + ma.mii_id1 = MIIBUS_READREG(mdiodev, ma.mii_phyno, MII_PHYIDR1); + ma.mii_id2 = MIIBUS_READREG(mdiodev, ma.mii_phyno, MII_PHYIDR2); ma.mii_offset = ivars->mii_offset; args = malloc(sizeof(struct mii_attach_args), M_DEVBUF, @@ -511,7 +528,7 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, rv = ENXIO; goto fail; } - rv = bus_generic_attach(dev); + rv = bus_generic_attach(mdiodev); if (rv != 0) goto fail; @@ -526,7 +543,7 @@ mii_attach(device_t dev, device_t *miibus, struct ifnet *ifp, fail: if (*miibus != NULL) - device_delete_child(dev, *miibus); + device_delete_child(mdiodev, *miibus); free(ivars, M_DEVBUF); if (first != 0) *miibus = NULL; diff --git a/sys/dev/mii/miivar.h b/sys/dev/mii/miivar.h index 34b0e9ed..029e6a8 100644 --- a/sys/dev/mii/miivar.h +++ b/sys/dev/mii/miivar.h @@ -248,6 +248,8 @@ extern driver_t miibus_driver; int mii_attach(device_t, device_t *, struct ifnet *, ifm_change_cb_t, ifm_stat_cb_t, int, int, int, int); +int mii_attach_interface(device_t, device_t, device_t *, struct ifnet *, + ifm_change_cb_t, ifm_stat_cb_t, int, int, int, int); void mii_down(struct mii_data *); int mii_mediachg(struct mii_data *); void mii_tick(struct mii_data *); --Apple-Mail-3--344543017-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 16:34:07 2012 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 D8025106566C for ; Fri, 6 Jan 2012 16:34:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AEF128FC0A for ; Fri, 6 Jan 2012 16:34:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 68BAC46B09 for ; Fri, 6 Jan 2012 11:34:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E502BB971 for ; Fri, 6 Jan 2012 11:34:06 -0500 (EST) From: John Baldwin To: arch@freebsd.org Date: Fri, 6 Jan 2012 11:34:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201201061134.06351.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Jan 2012 11:34:07 -0500 (EST) Cc: Subject: Adding spare VOPs to allow new VOPs to be MFC'd 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, 06 Jan 2012 16:34:07 -0000 Right now if we MFC a new VOP into a stable branch this breaks the KBI for any VFS kernel modules since the size and layout of struct vop_vector changes. What I am proposing is to add N (currently 5) spare VOPs at the end of the table that can be used by MFCs to add new VOPs onto a stable branch (assuming the change includes a suitable default VOP implementation). Index: vnode_if.src =================================================================== --- vnode_if.src (revision 229703) +++ vnode_if.src (working copy) @@ -50,7 +50,7 @@ # X: locked if not nil. # # The paramater named "vpp" is assumed to be always used with double -# indirection (**vpp) and that name is hard-codeed in vnode_if.awk ! +# indirection (**vpp) and that name is hard-coded in vnode_if.awk ! # # Lines starting with %! specify a pre or post-condition function # to call before/after the vop call. @@ -639,3 +639,28 @@ vop_advise { IN off_t end; IN int advice; }; + +# The VOPs below are spares at the end of the table to allow new VOPs to be +# added in stable branches without breaking the KBI. New VOPs in HEAD should +# be added above these spares. When merging a new VOP to a stable branch, +# the new VOP should replace one of the spares. + +vop_spare1 { + IN struct vnode *vp; +}; + +vop_spare2 { + IN struct vnode *vp; +}; + +vop_spare3 { + IN struct vnode *vp; +}; + +vop_spare4 { + IN struct vnode *vp; +}; + +vop_spare5 { + IN struct vnode *vp; +}; -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 18:27:58 2012 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 B3D0E106566C for ; Fri, 6 Jan 2012 18:27:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7E28FC08 for ; Fri, 6 Jan 2012 18:27:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q06IRuIm012805; Fri, 6 Jan 2012 19:27:56 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q06IRuNh012804; Fri, 6 Jan 2012 19:27:56 +0100 (CET) (envelope-from marius) Date: Fri, 6 Jan 2012 19:27:56 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120106182756.GA88161@alchemy.franken.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 18:27:58 -0000 On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote: > Am 05.01.2012 um 21:52 schrieb Stefan Bethke: > > > The problem with this is that the miibus instance might not be a (transitive) child of the ethernet driver that has the MII that needs to be adjusted to the new PHY settings. And since the method does not provide any parameters about which phy or miibus did issue the method, or which ifp it applies to, bubbling it up won't work (that the scenario where the PHY for arge0 is connected to the switch's MDIO, which is attached to arge1's MDIO). > > > >>> Since the parent will now be the mdiobus, miibus needs effectively two attachments, one to the provider of the MDIO access, the other for the ethernet interface. I propose to associate the ethernet interface by a modified mii_attach() function that takes a device_t (of the ethernet driver) instead of the two callback function pointers. > >> > >> Please elaborate on why these changes are technically necessary > >> to implement what you are trying do. Otherwise I prefer to avoid > >> them given the rototilling they'd cause. > > > > Necessary is a strong word. Right now, I'm trying to understand how a sensible change would even look like, and which combination of glue code and miibus changes make the most sense. > > > > Let me see if I can come up with a prototype patch the next couple of days, so we don't have to theorize about the changes that might or might not be necessary. > > Here's a patch that causes zero rototilling, if I'm not mistaken. > > The patch implements the split between the MDIO access and notifications posted to the ethernet interface device that has the MII that needs to be adjusted in accordance with the PHY autonegotiation results. I've added a field to the ivars struct and not the softc, because the softc is included by many network drivers, while the ivars are private to mii.c For this reason, I believe this change is API and ABI compatible, and likely can be MFCed. (I believe MFCing is not high on the priority list because many other parts in sys/mips would need to be MFCed first for all the Atheros platforms to become fully usable, but Adrian can correct me.) > By calling an newbus method on a device that is not the parent this patch hacks around how newbus is intended to work. I also still don't see why for the scenarios you describe you can't simply use miibus(4) as-is in a clean way. For the following scenario: fooeth0 | mdiobus0 | \ miibus0 (ethswitch0 or whatever) | foophy0 In mdiobus(4) you'd simply do: DEVMETHOD(miibus_statchg, mdiobus_statchg), <...> static void mdiobus_statchg(device_t dev) { parent = device_get_parent(dev); MIIBUS_STATCHG(device_get_parent(dev)); } in order to bubble up the miibus_statchg-method call from miibus0 to fooeth0. Likewise for the miibus_{linkchg,mediainit,readreg,writereg}. This isn't a work-around but how newbus works, just see the various bus drivers in the tree. I agree that if you'd want to do something like the following in order to "solve" the problem with arge(4): nexus0 / \ arge0 arge1 | mdiobus0 / \ miibus0 miibus1 | | foophy0 foophy1 or even: nexus0 / | \ arge0 arge1 mdio0 / \ miibus0 miibus1 | | foophy0 foophy1 then newbus is inconvenient here as it's just not how newbus is designed. But then calling the miibus_statchg-method etc on the Ethernet driver device also isn't your only problem as there's no newbus way to connect miibus0 with arge0 in the upper or arge0/arge1 with mdio0 in the lower diagram. Such architectures are just one big hack in the newbus point of view as you'd need to sidestep newbus with something like your patch. That's why I proposed the model that puc(4), scc(4) etc are following to solve this in a clean way, which for arge(4) would look like: nexus0 | miimux0 / \ arge0 arge1 | | ethswitch0 | | | miibus0 miibus1 | | foophy0 foophy1 Then you once again can bubble up things just fine. Basically look at scc(4) how to implement this, i.e. miimux(4) (or whatever you'd like to call it) would have a core, various bus-frontends (for nexus(4), pci(4) etc) and MAC-specific device parts for AR71xx etc. Then the probe routine of the nexus-frontend of miimux(4) would need claim the devices for arge0/1 in this setup (you'd probably need to provide a way to easily hard-code or specify this via hints as I can't imagine a way to auto-detect that) by returning a higheR probe value than arge(4) does. Apart from that it just needs to pass-through the bus resources to arge(4) and implement miibus_{readreg,writereg}-methods for the shared AR71xx MDIO master. In turn arge(4) would have two bus-frontends, one for nexus(4) (for the "normal" case) and one for miimux(4). In case it attaches to miimux(4) it then would just bubble up miibus_{readreg,writereg}- calls but terminate miibus_{linkchg,mediainit,statchg)- calls locally. Besides doing whatever it needs to do to configure the switch, ethswitch(4) would also just always bubble up the miibus_if.m methods. Besides being the clean way to do this from the newbus point of view this architecture also needs zero changes to miibus(4). Marius From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 20:35:42 2012 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 BC6521065672 for ; Fri, 6 Jan 2012 20:35:42 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7B48FC12 for ; Fri, 6 Jan 2012 20:35:42 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id CBF5711986A; Fri, 6 Jan 2012 20:35:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120106182756.GA88161@alchemy.franken.de> Date: Fri, 6 Jan 2012 21:35:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 20:35:42 -0000 Am 06.01.2012 um 19:27 schrieb Marius Strobl: > On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote: >> Am 05.01.2012 um 21:52 schrieb Stefan Bethke: >>=20 >>> The problem with this is that the miibus instance might not be a = (transitive) child of the ethernet driver that has the MII that needs to = be adjusted to the new PHY settings. And since the method does not = provide any parameters about which phy or miibus did issue the method, = or which ifp it applies to, bubbling it up won't work (that the scenario = where the PHY for arge0 is connected to the switch's MDIO, which is = attached to arge1's MDIO). >>>=20 >>>>> Since the parent will now be the mdiobus, miibus needs effectively = two attachments, one to the provider of the MDIO access, the other for = the ethernet interface. I propose to associate the ethernet interface = by a modified mii_attach() function that takes a device_t (of the = ethernet driver) instead of the two callback function pointers. >>>>=20 >>>> Please elaborate on why these changes are technically necessary >>>> to implement what you are trying do. Otherwise I prefer to avoid >>>> them given the rototilling they'd cause. >>>=20 >>> Necessary is a strong word. Right now, I'm trying to understand how = a sensible change would even look like, and which combination of glue = code and miibus changes make the most sense. >>>=20 >>> Let me see if I can come up with a prototype patch the next couple = of days, so we don't have to theorize about the changes that might or = might not be necessary. >>=20 >> Here's a patch that causes zero rototilling, if I'm not mistaken. >>=20 >> The patch implements the split between the MDIO access and = notifications posted to the ethernet interface device that has the MII = that needs to be adjusted in accordance with the PHY autonegotiation = results. I've added a field to the ivars struct and not the softc, = because the softc is included by many network drivers, while the ivars = are private to mii.c For this reason, I believe this change is API and = ABI compatible, and likely can be MFCed. (I believe MFCing is not high = on the priority list because many other parts in sys/mips would need to = be MFCed first for all the Atheros platforms to become fully usable, but = Adrian can correct me.) >=20 > By calling an newbus method on a device that is not the parent this > patch hacks around how newbus is intended to work. Admittedly, it adds a reference across the tree. > I also still don't see why for the scenarios you describe you can't = simply use miibus(4) as-is in a clean way. [ Scenarios for which the existing model works ] > That's why I proposed the model that puc(4), scc(4) etc are > following to solve this in a clean way, which for arge(4) > would look like: > nexus0 > | > miimux0 > / \ > arge0 arge1 > | | > ethswitch0 | > | | > miibus0 miibus1 > | | > foophy0 foophy1 >=20 [ Explanation on how things work with above setup ] Except that your diagram does not correlate with the scenario I've = outlined. I'll try to explain again: the MDIO master access for the PHY = which MII lines are connected to arge1 are hosted on a separate device. = Please refer to this diagram: = http://wiki.freebsd.org/StefanBethke/EtherSwitch?action=3DAttachFile&do=3D= get&target=3Dembedded-switch.png (arge0 and phy4) To make things as clear as possible, consider an RTL836x controller = which is attached to the system through an I2C bus. (Never mind that it = has a switch, that's not relevant to the discussion here.) It has one = MII bus connection connecting one ethernet interface MAC to one PHY; the = MDIO master that can talk to that PHY is in the RTL836x. The common = ancestor for the ethernet driver and the MDIO driver then are likely to = be very near the top, meaning that the interposed driver would need = support not only for the ethernet driver in question, but the I2C bus as = well. An interposed driver at nexus level that gets the phy linkchg = message bubbled up to it does need to send it back down to the ethernet = driver. The message sent by miibus does contains neither source nor = destination information, so that miibus needs to be attached to a unique = driver instances that adds that information to the message before = bubbling it up. Of course, it also needs to get this information from = somewhere, so a reference to the ethernet driver needs to be injected = somehow. I would like to find a solution that allows us to plug together an = ethernet driver, a driver that makes that MDIO bus available, and the = miibus/phy combo with minimal effort. Writing a driver framework that = can be interposed between arbitrary drivers in the system to pass one = message from the PHY to the ethernet driver seems rather convoluted to = me. (Yes, for the concrete case we can always hack something up, but = I'm trying to find something better than that.) Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 21:30:33 2012 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 A46FE1065676; Fri, 6 Jan 2012 21:30:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 271858FC16; Fri, 6 Jan 2012 21:30:32 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2468820vbb.13 for ; Fri, 06 Jan 2012 13:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7i8L0JobRQXi8fpSUb/2zL5mr/eigMvIQmnjRiCPRqI=; b=DzZQTnzId4Lpls/2IaBjYGlBnvAdJ/5lxyqsnFmGdhduKjvt4B1f4hcVMjc1blwcre haPiqY19K2Yh2vixvPGfSr6wA5wtIU7pmRmWOlUTFyvJq94i/6ZtjuEH+NIXhhShAdLq HujoLAtCQlCTm93bpFuQGqUV2xSy4MfcL89ME= MIME-Version: 1.0 Received: by 10.52.24.35 with SMTP id r3mr3881435vdf.81.1325885431095; Fri, 06 Jan 2012 13:30:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 13:30:31 -0800 (PST) In-Reply-To: <86ty4a8mc3.fsf@ds4.des.no> References: <86ty4a8mc3.fsf@ds4.des.no> Date: Fri, 6 Jan 2012 13:30:31 -0800 X-Google-Sender-Auth: VrRk9ZViKHedD6PwnMzfkv_i4i4 Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? 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, 06 Jan 2012 21:30:33 -0000 2012/1/5 Dag-Erling Sm=F8rgrav : > Adrian Chadd writes: >> Since I'm not using NFS or UFS_ACL, I wondered if that code required. >> It turns out I can just build a kernel with those two disabled. >> >> Would it be possible to remove them from "standard" and make them >> optional? Or is there a reason to keep it in base? > > I would be very annoyed if it were no longer possible to netboot > GENERIC... I don't want to break that. :) I Just don't want to compile it in unless I'm using NFS/ZFS, and on my 4MB flash boards I'm not booting w/ NFS compiled in statically.. Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 21:37:19 2012 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 B3CFF1065676; Fri, 6 Jan 2012 21:37:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 384678FC12; Fri, 6 Jan 2012 21:37:19 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so2475220vbb.13 for ; Fri, 06 Jan 2012 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h5I48bZmkhT/BL8aTjZtM+ME+4su8sNBZEiKc/J1Ze4=; b=TovoUsGPZ+hQI7Dl/UFHa0WNC3+04nTj36ACPAataWHfTqC4Rr49Y9z4xWFX/prgqb R+NMbmDg3kiRzsQYp+bisGr/mjycBwxRCN72fy0houhGrSH0EBu60ThAM2PfuLKC0YDB V15z3HTQpI7uZ4XFz6B3cxHbvBo0bMye20VuA= MIME-Version: 1.0 Received: by 10.52.26.66 with SMTP id j2mr3838387vdg.98.1325885838661; Fri, 06 Jan 2012 13:37:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 6 Jan 2012 13:37:18 -0800 (PST) In-Reply-To: <201201050848.18414.jhb@freebsd.org> References: <201201050848.18414.jhb@freebsd.org> Date: Fri, 6 Jan 2012 13:37:18 -0800 X-Google-Sender-Auth: U9y4aWPHvV9i3FSLOZqseimAzS4 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current , freebsd-arch@freebsd.org Subject: Re: Is it possible to make subr_acl_nfs4 and subr_acl_posix1e disabled? 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, 06 Jan 2012 21:37:19 -0000 On 5 January 2012 05:48, John Baldwin wrote: > [ A bit excessive on the cross-posting? =A0arch@ alone was probably fine = ] I wanted to capture the attention of relevant people, as I don't want to break some subtle setup that I'm not at all aware of. > NFS doesn't actually use them curently, only UFS and ZFS do. =A0Unfortuna= tely > we've yet to make it possible to compile ZFS into the kernel, so you can'= t > make the sys/conf/files bits completely accurate yet (it would be nice to > let folks who don't need FFS for a ZFS-only system remove FFS and UFS, bu= t > this would break that): Ok. I'll just test that the GENERIC build works and then commit it. adrian From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 21:47:43 2012 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 9E2531065680 for ; Fri, 6 Jan 2012 21:47:43 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC258FC0A for ; Fri, 6 Jan 2012 21:47:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q06Llf10015660; Fri, 6 Jan 2012 22:47:41 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q06Llf9b015659; Fri, 6 Jan 2012 22:47:41 +0100 (CET) (envelope-from marius) Date: Fri, 6 Jan 2012 22:47:41 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120106214741.GB88161@alchemy.franken.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 21:47:43 -0000 On Fri, Jan 06, 2012 at 09:35:40PM +0100, Stefan Bethke wrote: >=20 > Am 06.01.2012 um 19:27 schrieb Marius Strobl: >=20 > > On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote: > >> Am 05.01.2012 um 21:52 schrieb Stefan Bethke: > >>=20 > >>> The problem with this is that the miibus instance might not be a (tra= nsitive) child of the ethernet driver that has the MII that needs to be adj= usted to the new PHY settings. And since the method does not provide any p= arameters about which phy or miibus did issue the method, or which ifp it a= pplies to, bubbling it up won't work (that the scenario where the PHY for a= rge0 is connected to the switch's MDIO, which is attached to arge1's MDIO). > >>>=20 > >>>>> Since the parent will now be the mdiobus, miibus needs effectively = two attachments, one to the provider of the MDIO access, the other for the = ethernet interface. I propose to associate the ethernet interface by a mod= ified mii_attach() function that takes a device_t (of the ethernet driver) = instead of the two callback function pointers. > >>>>=20 > >>>> Please elaborate on why these changes are technically necessary > >>>> to implement what you are trying do. Otherwise I prefer to avoid > >>>> them given the rototilling they'd cause. > >>>=20 > >>> Necessary is a strong word. Right now, I'm trying to understand how = a sensible change would even look like, and which combination of glue code = and miibus changes make the most sense. > >>>=20 > >>> Let me see if I can come up with a prototype patch the next couple of= days, so we don't have to theorize about the changes that might or might n= ot be necessary. > >>=20 > >> Here's a patch that causes zero rototilling, if I'm not mistaken. > >>=20 > >> The patch implements the split between the MDIO access and notificatio= ns posted to the ethernet interface device that has the MII that needs to b= e adjusted in accordance with the PHY autonegotiation results. I've added = a field to the ivars struct and not the softc, because the softc is include= d by many network drivers, while the ivars are private to mii.c For this r= eason, I believe this change is API and ABI compatible, and likely can be M= FCed. (I believe MFCing is not high on the priority list because many othe= r parts in sys/mips would need to be MFCed first for all the Atheros platfo= rms to become fully usable, but Adrian can correct me.) > >=20 > > By calling an newbus method on a device that is not the parent this > > patch hacks around how newbus is intended to work. >=20 > Admittedly, it adds a reference across the tree. >=20 > > I also still don't see why for the scenarios you describe you can't sim= ply use miibus(4) as-is in a clean way. >=20 > [ Scenarios for which the existing model works ] >=20 > > That's why I proposed the model that puc(4), scc(4) etc are > > following to solve this in a clean way, which for arge(4) > > would look like: > > nexus0 > > | > > miimux0 > > / \ > > arge0 arge1 > > | | > > ethswitch0 | > > | | > > miibus0 miibus1 > > | | > > foophy0 foophy1 > >=20 > [ Explanation on how things work with above setup ] >=20 > Except that your diagram does not correlate with the scenario I've outlin= ed. I'll try to explain again: the MDIO master access for the PHY which MI= I lines are connected to arge1 are hosted on a separate device. Please ref= er to this diagram: http://wiki.freebsd.org/StefanBethke/EtherSwitch?action= =3DAttachFile&do=3Dget&target=3Dembedded-switch.png (arge0 and phy4) >=20 > To make things as clear as possible, consider an RTL836x controller which= is attached to the system through an I2C bus. (Never mind that it has a s= witch, that's not relevant to the discussion here.) It has one MII bus con= nection connecting one ethernet interface MAC to one PHY; the MDIO master t= hat can talk to that PHY is in the RTL836x. The common ancestor for the et= hernet driver and the MDIO driver then are likely to be very near the top, = meaning that the interposed driver would need support not only for the ethe= rnet driver in question, but the I2C bus as well. An interposed driver at = nexus level that gets the phy linkchg message bubbled up to it does need to= send it back down to the ethernet driver. The message sent by miibus does= contains neither source nor destination information, so that miibus needs = to be attached to a unique driver instances that adds that information to t= he message before bubbling it up. Of course, it also needs to get this inf= ormation from somewhere, so a reference to the ethernet driver needs to be = injected somehow. >=20 Okay, now I'm confused; I don't know the RTL836x but you seem to say that essentially for this discussion this is a I2C to MDIO bridge, with iicbus(4) being involved to access the MDIO of PHYs being new information. Is this scenario supposed to be also covered by embedded-switch.png? If it is, what purpose does the MDIO connection between arge1 and the switch in there serve for? Marius From owner-freebsd-arch@FreeBSD.ORG Fri Jan 6 21:53:16 2012 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 CE61D1065679 for ; Fri, 6 Jan 2012 21:53:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 46E038FC19 for ; Fri, 6 Jan 2012 21:53:16 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 658D6119C50; Fri, 6 Jan 2012 21:53:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120106214741.GB88161@alchemy.franken.de> Date: Fri, 6 Jan 2012 22:53:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii 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, 06 Jan 2012 21:53:16 -0000 Am 06.01.2012 um 22:47 schrieb Marius Strobl: > On Fri, Jan 06, 2012 at 09:35:40PM +0100, Stefan Bethke wrote: >>=20 >> Am 06.01.2012 um 19:27 schrieb Marius Strobl: >>=20 >>> On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote: >>>> Am 05.01.2012 um 21:52 schrieb Stefan Bethke: >>>>=20 >>>>> The problem with this is that the miibus instance might not be a = (transitive) child of the ethernet driver that has the MII that needs to = be adjusted to the new PHY settings. And since the method does not = provide any parameters about which phy or miibus did issue the method, = or which ifp it applies to, bubbling it up won't work (that the scenario = where the PHY for arge0 is connected to the switch's MDIO, which is = attached to arge1's MDIO). >>>>>=20 >>>>>>> Since the parent will now be the mdiobus, miibus needs = effectively two attachments, one to the provider of the MDIO access, the = other for the ethernet interface. I propose to associate the ethernet = interface by a modified mii_attach() function that takes a device_t (of = the ethernet driver) instead of the two callback function pointers. >>>>>>=20 >>>>>> Please elaborate on why these changes are technically necessary >>>>>> to implement what you are trying do. Otherwise I prefer to avoid >>>>>> them given the rototilling they'd cause. >>>>>=20 >>>>> Necessary is a strong word. Right now, I'm trying to understand = how a sensible change would even look like, and which combination of = glue code and miibus changes make the most sense. >>>>>=20 >>>>> Let me see if I can come up with a prototype patch the next couple = of days, so we don't have to theorize about the changes that might or = might not be necessary. >>>>=20 >>>> Here's a patch that causes zero rototilling, if I'm not mistaken. >>>>=20 >>>> The patch implements the split between the MDIO access and = notifications posted to the ethernet interface device that has the MII = that needs to be adjusted in accordance with the PHY autonegotiation = results. I've added a field to the ivars struct and not the softc, = because the softc is included by many network drivers, while the ivars = are private to mii.c For this reason, I believe this change is API and = ABI compatible, and likely can be MFCed. (I believe MFCing is not high = on the priority list because many other parts in sys/mips would need to = be MFCed first for all the Atheros platforms to become fully usable, but = Adrian can correct me.) >>>=20 >>> By calling an newbus method on a device that is not the parent this >>> patch hacks around how newbus is intended to work. >>=20 >> Admittedly, it adds a reference across the tree. >>=20 >>> I also still don't see why for the scenarios you describe you can't = simply use miibus(4) as-is in a clean way. >>=20 >> [ Scenarios for which the existing model works ] >>=20 >>> That's why I proposed the model that puc(4), scc(4) etc are >>> following to solve this in a clean way, which for arge(4) >>> would look like: >>> nexus0 >>> | >>> miimux0 >>> / \ >>> arge0 arge1 >>> | | >>> ethswitch0 | >>> | | >>> miibus0 miibus1 >>> | | >>> foophy0 foophy1 >>>=20 >> [ Explanation on how things work with above setup ] >>=20 >> Except that your diagram does not correlate with the scenario I've = outlined. I'll try to explain again: the MDIO master access for the PHY = which MII lines are connected to arge1 are hosted on a separate device. = Please refer to this diagram: = http://wiki.freebsd.org/StefanBethke/EtherSwitch?action=3DAttachFile&do=3D= get&target=3Dembedded-switch.png (arge0 and phy4) >>=20 >> To make things as clear as possible, consider an RTL836x controller = which is attached to the system through an I2C bus. (Never mind that it = has a switch, that's not relevant to the discussion here.) It has one = MII bus connection connecting one ethernet interface MAC to one PHY; the = MDIO master that can talk to that PHY is in the RTL836x. The common = ancestor for the ethernet driver and the MDIO driver then are likely to = be very near the top, meaning that the interposed driver would need = support not only for the ethernet driver in question, but the I2C bus as = well. An interposed driver at nexus level that gets the phy linkchg = message bubbled up to it does need to send it back down to the ethernet = driver. The message sent by miibus does contains neither source nor = destination information, so that miibus needs to be attached to a unique = driver instances that adds that information to the message before = bubbling it up. Of course, it also needs to get this information from = somewhere, so a reference to the ethernet driver needs to be injected = somehow. >>=20 >=20 > Okay, now I'm confused; I don't know the RTL836x but you seem to say > that essentially for this discussion this is a I2C to MDIO bridge, > with iicbus(4) being involved to access the MDIO of PHYs being new > information. Is this scenario supposed to be also covered by > embedded-switch.png? If it is, what purpose does the MDIO connection > between arge1 and the switch in there serve for? Yes, for the purpose of this discussion, the RTL836x series is an I2C to = MDIO bridge; the diagram for the Atheros chip is an MDIO to MDIO bridge = in that sense. Atheros switches, as well as the RTL803x series, have an MDIO slave = instead of an I2C slave, but the basic layout remains the same. The = ethernet driver for arge0 cannot directly talk to PHY4 because it's = hanging off some more or less remote part of the device tree. That's = what I'm trying to get across, and that's the problem I'm trying to = solve in a more or less generic way. Stefan --=20 Stefan Bethke Fon +49 151 14070811