From owner-freebsd-arch@FreeBSD.ORG Sun Jan 22 15:31:09 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 726AD106564A; Sun, 22 Jan 2012 15:31:09 +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 DAFAD8FC08; Sun, 22 Jan 2012 15:31:08 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 7BC85451C; Sun, 22 Jan 2012 15:31:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: <20120120221319.ca8b631f.ray@freebsd.org> Date: Sun, 22 Jan 2012 16:31:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Ethernet Switch Framework 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, 22 Jan 2012 15:31:09 -0000 Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko: > It include sys/mips/conf/AR7240, that together with hints file is good > example for typical AR7240 setup. I=C4m heaving trouble getting this to work. The patch applies cleanly = and I can get a kernel compiled and booted, but neither arge0 nor arge1 = appear to be functional. I had to roll my own kernel config as your = AR7240 hangs before printing anything on my TL-MR3420. dmesg and devinfo below. Stefan CPU platform: Atheros AR7241 rev 1 CPU Frequency=3D400 MHz CPU DDR Frequency=3D400 MHz CPU AHB Frequency=3D200 MHz platform frequency: 400000000 arguments:=20 a0 =3D 00000008 a1 =3D a1f87fb0 a2 =3D a1f88470 a3 =3D 00000004 Cmd line:argv is invalid Environment: envp is invalid Cache info: picache_stride =3D 4096 picache_loopcount =3D 16 pdcache_stride =3D 4096 pdcache_loopcount =3D 8 cpu0: MIPS Technologies processor v116.147 MMU: Standard TLB, 16 entries L1 i-cache: 4 ways of 512 sets, 32 bytes per line L1 d-cache: 4 ways of 256 sets, 32 bytes per line Config1=3D0x9ee3519e Config3=3D0x20 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1: Thu Jan 1 01:00:00 CET 1970 = stb@dummy:/home/stb/working/fe/obj/mipseb/mips.mipseb/home/stb/working/fe/= freebsd/sys/TL-MR3420D mips WARNING: WITNESS option enabled, expect reduced performance. real memory =3D 33554432 (32768K bytes) avail memory =3D 25567232 (24MB) random device not loaded; using insecure entropy nexus0: nexus0: failed to add child: arge0 nexus0: failed to add child: arge1 clock0: on nexus0 Timecounter "MIPS32" frequency 200000000 Hz quality 800 Event timer "MIPS32" frequency 200000000 Hz quality 800 apb0 at irq 4 on nexus0 uart0: <16550 or compatible> on apb0 uart0: console (115200,n,8,1) gpio0: on apb0 gpio0: [GIANT-LOCKED] gpio0: function_set: 0x0 gpio0: function_clear: 0x0 gpio0: gpio pinmask=3D0x1943 gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 0 on gpiobus0 gpioled1: at pin(s) 1 on gpiobus0 gpioled2: at pin(s) 3 on gpiobus0 ehci0: at mem = 0x1b000100-0x1bffffff irq 1 on nexus0 usbus0: set host controller mode usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0: on ehci0 arge0: at mem = 0x19000000-0x19000fff irq 2 on nexus0 arge0: Overriding MAC from EEPROM arge0: No PHY specified, using mask 16 miibus0: on arge0 floatphy0 PHY 0 on miibus0 floatphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, = 1000baseT-FDX-master, auto switch0 PHY 1 on miibus0 switch0: 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseSX-FDX, = 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master ar8x16_switch0: on switch0 arge0: Ethernet address: ff:ff:ff:ff:ff:ff arge1: at mem = 0x1a000000-0x1a000fff irq 3 on nexus0 arge1: No PHY specified, using mask 15 arge1: Ethernet address: ff:ff:ff:ff:ff:00 spi0: at mem 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 mx25l0: at cs 0 on spibus0 mx25l0: s25s1032, sector 65536 bytes, 64 sectors ar71xx_wdog0: on nexus0 ar71xx_wdog0: Previous reset was due to watchdog timeout Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on = usbus0 WARNING: WITNESS option enabled, expect reduced performance. uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on = usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:map/rootfs.uzip []... mountroot: waiting for device map/rootfs.uzip ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 = device=20 da0: 40.000MB/s transfers da0: 15252MB (31236096 512 byte sectors: 255H 63S/T 1944C) Trying to mount root from ufs:da0s1a []... warning: no time-of-day clock registered, system time will not be set = accurately Setting hostuuid: aed4c502-193a-11e1-b662-74ea3ae4d920. Setting hostid: 0x6a714343. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 3849245 free (1085 frags, 481020 blocks, 0.0% = fragmentation) lock order reversal: 1st 0x8095691c ufs (ufs) @ = /home/stb/working/fe/freebsd/sys/kern/vfs_mount.c:1245 2nd 0x80956e94 devfs (devfs) @ = /home/stb/working/fe/freebsd/sys/kern/vfs_subr.c:2167 KDB: stack backtrace: db_trace_thread+30 (?,?,?,?) ra c3f597c000000018 sp 0 sz 0 db_trace_self+1c (?,?,?,?) ra c3f597d800000018 sp 0 sz 0 800776d8+34 (?,?,?,?) ra c3f597f0000001a0 sp 0 sz 0 kdb_backtrace+44 (?,?,?,?) ra c3f5999000000018 sp 0 sz 0 801b3bbc+34 (?,?,?,?) ra c3f599a800000020 sp 0 sz 0 witness_checkorder+9cc (?,?,803b1f7c,877) ra c3f599c800000050 sp 0 sz 1 __lockmgr_args+948 (?,?,80956eb4,?) ra c3f59a1800000070 sp 0 sz 1 vop_stdlock+4c (?,?,?,?) ra c3f59a8800000028 sp 0 sz 0 VOP_LOCK1_APV+e4 (?,?,?,?) ra c3f59ab000000020 sp 0 sz 0 _vn_lock+84 (?,?,?,?) ra c3f59ad000000048 sp 0 sz 0 vget+c8 (?,?,?,?) ra c3f59b1800000030 sp 0 sz 0 devfs_allocv+100 (?,?,?,?) ra c3f59b4800000038 sp 0 sz 0 800ba9b4+4c (?,?,?,?) ra c3f59b8000000028 sp 0 sz 0 vflush+6c (?,?,0,80991300) ra c3f59ba8000000f8 sp 0 sz 1 800baa74+54 (?,?,?,?) ra c3f59ca000000028 sp 0 sz 0 dounmount+3f0 (809e8000,?,?,?) ra c3f59cc800000050 sp 100000000 sz 0 sys_unmount+39c (?,?,?,?) ra c3f59d18000000b0 sp 0 sz 0 trap+7f4 (?,?,?,?) ra c3f59dc8000000b8 sp 0 sz 0 MipsUserGenException+10c (?,?,?,404b53c0) ra c3f59e8000000000 sp 0 sz 0 pid 70 Mounting local file systems:. Setting hostname: whitebox.lassitu.de. miibus0: mii_mediachg: can't handle non-zero PHY instance 1 floatphy0: found master switch0 miibus0: mii_mediachg: can't handle non-zero PHY instance 1 arge0: link state changed to DOWN Starting Network: lo0 arge0 arge1. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 arge0: flags=3D8843 metric 0 mtu = 1500 options=3D80000 ether ff:ff:ff:ff:ff:ff inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255=20 inet6 fe80::481f:1b46:dbf1:bd78%arge0 prefixlen 64 scopeid 0x2=20= nd6 options=3D29 media: Ethernet autoselect (100baseTX ) status: no carrier arge1: flags=3D8843 metric 0 mtu = 1500 ether ff:ff:ff:ff:ff:00 inet 44.128.65.33 netmask 0xffffffc0 broadcast 44.128.65.63=20 inet6 fe80::481f:1b46:dbf1:bd78%arge1 prefixlen 64 scopeid 0x3=20= nd6 options=3D29 media: Ethernet 100baseTX status: active add net default: gateway 44.128.65.1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Mounting NFS file systems:mount_nfs: diesel: hostname nor servname = provided, or not known . Creating and/or trimming log files. No core dumps found. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting date via ntp. Error : hostname nor servname provided, or not known 22 Jan 15:01:04 ntpdate[566]: can't find host diesel 22 Jan 15:01:04 ntpdate[566]: no servers can be used, exiting Clearing /tmp (X related). Mounting late file systems:mount_nfs: diesel: hostname nor servname = provided, or not known . Mounting /etc/fstab filesystems failed,Jan 22 15:01:12 init: /bin/sh on = /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh:=20 # devinfo nexus0 clock0 apb0 uart0 gpio0 gpioc0 gpiobus0 gpioled0 gpioled1 gpioled2 ehci0 usbus0 uhub0 umass0 arge0 miibus0 floatphy0 switch0 ar8x16_switch0 arge1 spi0 spibus0 mx25l0 ar71xx_wdog0 #=20 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Sun Jan 22 17:51:46 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 27722106566C; Sun, 22 Jan 2012 17:51:46 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4FC8FC12; Sun, 22 Jan 2012 17:51:42 +0000 (UTC) Received: from rnote.ddteam.net (162-84-133-95.pool.ukrtel.net [95.133.84.162]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id E7BBCC493A; Sun, 22 Jan 2012 19:51:40 +0200 (EET) Date: Sun, 22 Jan 2012 19:51:30 +0200 From: Aleksandr Rybalko To: Stefan Bethke Message-Id: <20120122195130.360261ce.ray@freebsd.org> In-Reply-To: <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Ethernet Switch Framework 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, 22 Jan 2012 17:51:46 -0000 On Sun, 22 Jan 2012 16:31:06 +0100 Stefan Bethke wrote: > Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko: > > > It include sys/mips/conf/AR7240, that together with hints file is > > good example for typical AR7240 setup. > > IÄm heaving trouble getting this to work. The patch applies cleanly > and I can get a kernel compiled and booted, but neither arge0 nor > arge1 appear to be functional. I had to roll my own kernel config as > your AR7240 hangs before printing anything on my TL-MR3420. Yeah, I know where is problem, to proper attach switch framework to arge, arge must be regular NIC. Here is the patch for that: http://my.ddteam.net/files/2012-01-22_arge.patch Hope it will apply cleanly. Patch have fixed both arge problems (problem for allocation of ring buffer, and stray interrupts) + remove most phymask bits + whitespace cleanup. Thank you for testing that Stefan. P.S. I can't test clear SoC config on my board, because my board id D-Link DIR-615_E4 with modified U-Boot in it, which able to load only FW images, but not ELF kernel. So I test it with ZRouter.org FW image instead. P.P.S. can you also show me network part of your config and hints files. P.P.P.S. still working on your previous question about subj, already begin work on more wide documentation on wiki, but still far enough :) "http://wiki.freebsd.org/AleksandrRybalko/Switch Framework" > > dmesg and devinfo below. > > > Stefan > > CPU platform: Atheros AR7241 rev 1 > CPU Frequency=400 MHz > CPU DDR Frequency=400 MHz > CPU AHB Frequency=200 MHz > platform frequency: 400000000 > arguments: > a0 = 00000008 > a1 = a1f87fb0 > a2 = a1f88470 > a3 = 00000004 > Cmd line:argv is invalid > Environment: > envp is invalid > Cache info: > picache_stride = 4096 > picache_loopcount = 16 > pdcache_stride = 4096 > pdcache_loopcount = 8 > cpu0: MIPS Technologies processor v116.147 > MMU: Standard TLB, 16 entries > L1 i-cache: 4 ways of 512 sets, 32 bytes per line > L1 d-cache: 4 ways of 256 sets, 32 bytes per line > Config1=0x9ee3519e > Config3=0x20 > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #1: Thu Jan 1 01:00:00 CET 1970 > stb@dummy:/home/stb/working/fe/obj/mipseb/mips.mipseb/home/stb/working/fe/freebsd/sys/TL-MR3420D > mips WARNING: WITNESS option enabled, expect reduced performance. > real memory = 33554432 (32768K bytes) > avail memory = 25567232 (24MB) > random device not loaded; using insecure entropy > nexus0: > nexus0: failed to add child: arge0 > nexus0: failed to add child: arge1 > clock0: on nexus0 > Timecounter "MIPS32" frequency 200000000 Hz quality 800 > Event timer "MIPS32" frequency 200000000 Hz quality 800 > apb0 at irq 4 on nexus0 > uart0: <16550 or compatible> on apb0 > uart0: console (115200,n,8,1) > gpio0: on apb0 > gpio0: [GIANT-LOCKED] > gpio0: function_set: 0x0 > gpio0: function_clear: 0x0 > gpio0: gpio pinmask=0x1943 > gpioc0: on gpio0 > gpiobus0: on gpio0 > gpioled0: at pin(s) 0 on gpiobus0 > gpioled1: at pin(s) 1 on gpiobus0 > gpioled2: at pin(s) 3 on gpiobus0 > ehci0: at mem > 0x1b000100-0x1bffffff irq 1 on nexus0 usbus0: set host controller mode > usbus0: EHCI version 1.0 > usbus0: set host controller mode > usbus0: on ehci0 > arge0: at mem > 0x19000000-0x19000fff irq 2 on nexus0 arge0: Overriding MAC from > EEPROM arge0: No PHY specified, using mask 16 > miibus0: on arge0 > floatphy0 PHY 0 on miibus0 > floatphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, auto switch0 PHY 1 on miibus0 > switch0: 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseSX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master > ar8x16_switch0: on > switch0 arge0: Ethernet address: ff:ff:ff:ff:ff:ff arge1: AR71xx built-in ethernet interface> at mem 0x1a000000-0x1a000fff irq > 3 on nexus0 arge1: No PHY specified, using mask 15 arge1: Ethernet > address: ff:ff:ff:ff:ff:00 spi0: at mem > 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 mx25l0: > at cs 0 on spibus0 mx25l0: s25s1032, sector > 65536 bytes, 64 sectors ar71xx_wdog0: > on nexus0 ar71xx_wdog0: Previous reset was due to watchdog timeout > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on > usbus0 WARNING: WITNESS option enabled, expect reduced performance. > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > umass0: > on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:0:0:-1: Attached to scbus0 > Trying to mount root from ufs:map/rootfs.uzip []... > mountroot: waiting for device map/rootfs.uzip ... > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 > device da0: 40.000MB/s transfers > da0: 15252MB (31236096 512 byte sectors: 255H 63S/T 1944C) > Trying to mount root from ufs:da0s1a []... > warning: no time-of-day clock registered, system time will not be set > accurately Setting hostuuid: aed4c502-193a-11e1-b662-74ea3ae4d920. > Setting hostid: 0x6a714343. > Entropy harvesting: interrupts ethernet point_to_point kickstart. > Starting file system checks: > /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1a: clean, 3849245 free (1085 frags, 481020 blocks, 0.0% > fragmentation) lock order reversal: > 1st 0x8095691c ufs (ufs) > @ /home/stb/working/fe/freebsd/sys/kern/vfs_mount.c:1245 2nd > 0x80956e94 devfs (devfs) > @ /home/stb/working/fe/freebsd/sys/kern/vfs_subr.c:2167 KDB: stack > backtrace: db_trace_thread+30 (?,?,?,?) ra c3f597c000000018 sp 0 sz 0 > db_trace_self+1c (?,?,?,?) ra c3f597d800000018 sp 0 sz 0 800776d8+34 > (?,?,?,?) ra c3f597f0000001a0 sp 0 sz 0 kdb_backtrace+44 (?,?,?,?) ra > c3f5999000000018 sp 0 sz 0 801b3bbc+34 (?,?,?,?) ra c3f599a800000020 > sp 0 sz 0 witness_checkorder+9cc (?,?,803b1f7c,877) ra > c3f599c800000050 sp 0 sz 1 __lockmgr_args+948 (?,?,80956eb4,?) ra > c3f59a1800000070 sp 0 sz 1 vop_stdlock+4c (?,?,?,?) ra > c3f59a8800000028 sp 0 sz 0 VOP_LOCK1_APV+e4 (?,?,?,?) ra > c3f59ab000000020 sp 0 sz 0 _vn_lock+84 (?,?,?,?) ra c3f59ad000000048 > sp 0 sz 0 vget+c8 (?,?,?,?) ra c3f59b1800000030 sp 0 sz 0 > devfs_allocv+100 (?,?,?,?) ra c3f59b4800000038 sp 0 sz 0 > 800ba9b4+4c (?,?,?,?) ra c3f59b8000000028 sp 0 sz 0 > vflush+6c (?,?,0,80991300) ra c3f59ba8000000f8 sp 0 sz 1 > 800baa74+54 (?,?,?,?) ra c3f59ca000000028 sp 0 sz 0 > dounmount+3f0 (809e8000,?,?,?) ra c3f59cc800000050 sp 100000000 sz 0 > sys_unmount+39c (?,?,?,?) ra c3f59d18000000b0 sp 0 sz 0 > trap+7f4 (?,?,?,?) ra c3f59dc8000000b8 sp 0 sz 0 > MipsUserGenException+10c (?,?,?,404b53c0) ra c3f59e8000000000 sp 0 sz > 0 pid 70 > Mounting local file systems:. > Setting hostname: whitebox.lassitu.de. > miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > floatphy0: found master switch0 > miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > arge0: link state changed to DOWN > Starting Network: lo0 arge0 arge1. > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > arge0: flags=8843 metric 0 > mtu 1500 options=80000 > ether ff:ff:ff:ff:ff:ff > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > inet6 fe80::481f:1b46:dbf1:bd78%arge0 prefixlen 64 scopeid > 0x2 nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: no carrier > arge1: flags=8843 metric 0 > mtu 1500 ether ff:ff:ff:ff:ff:00 > inet 44.128.65.33 netmask 0xffffffc0 broadcast 44.128.65.63 > inet6 fe80::481f:1b46:dbf1:bd78%arge1 prefixlen 64 scopeid > 0x3 nd6 options=29 > media: Ethernet 100baseTX > status: active > add net default: gateway 44.128.65.1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > Mounting NFS file systems:mount_nfs: diesel: hostname nor servname > provided, or not known . > Creating and/or trimming log files. > No core dumps found. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Setting date via ntp. > Error : hostname nor servname provided, or not known > 22 Jan 15:01:04 ntpdate[566]: can't find host diesel > > 22 Jan 15:01:04 ntpdate[566]: no servers can be used, exiting > Clearing /tmp (X related). > Mounting late file systems:mount_nfs: diesel: hostname nor servname > provided, or not known . > Mounting /etc/fstab filesystems failed,Jan 22 15:01:12 init: /bin/sh > on /etc/rc terminated abnormally, going to single user mode Enter > full pathname of shell or RETURN for /bin/sh: > # devinfo > nexus0 > clock0 > apb0 > uart0 > gpio0 > gpioc0 > gpiobus0 > gpioled0 > gpioled1 > gpioled2 > ehci0 > usbus0 > uhub0 > umass0 > arge0 > miibus0 > floatphy0 > switch0 > ar8x16_switch0 > arge1 > spi0 > spibus0 > mx25l0 > ar71xx_wdog0 > # > > > -- > Stefan Bethke Fon +49 151 14070811 > > > -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Sun Jan 22 18:33:51 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 8E80D106564A; Sun, 22 Jan 2012 18:33:51 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A99738FC12; Sun, 22 Jan 2012 18:33:50 +0000 (UTC) Received: by bkbc12 with SMTP id c12so2399263bkb.13 for ; Sun, 22 Jan 2012 10:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=BaiUUB+cTOitl7lYmX6nW8sQs3ep0sECp5JT4PvWcY4=; b=dULoKdNuZVWX7MX3LZQv1KrhgRFKqxk4NKsVW3WpxEAoljHnnsCPXDW3B6Er2h6fbl 3kzD5DYtyzjI7yf6TjEMEXnquaf49XtRdso3jeB2ea+9vI/fb5WRw7Z9Xd3fRLzNSMD+ TrPq6yFEUGOG0lF92XNtv8cCh+F0nPd1p0xys= Received: by 10.204.150.7 with SMTP id w7mr2002241bkv.107.1327257229431; Sun, 22 Jan 2012 10:33:49 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id ga13sm22466594bkc.5.2012.01.22.10.33.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jan 2012 10:33:48 -0800 (PST) From: Mikolaj Golub To: Kostik Belousov References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Sun, 22 Jan 2012 20:33:45 +0200 In-Reply-To: <20120112215106.GC31224@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Thu, 12 Jan 2012 23:51:06 +0200") Message-ID: <86hazntwmu.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) 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, 22 Jan 2012 18:33:51 -0000 There was a bug in my patch: for vop_unpdetach it wanted the vnode to be exclusively locked, while it was called from the context (uipc_detach) where the vnode is not locked. It looks it is OK that the vnode is not locked here: the operation is to null vp->v_socket, and currently the only place where it is concurently accessed is in unp_connect(), and it is protected by the linkage lock. So I updated my patch to have "= = =" for unpdetach vp. http://people.freebsd.org/~trociny/VOP_UNP.2.patch On Thu, 12 Jan 2012 23:51:06 +0200 Kostik Belousov wrote: KB> On Thu, Jan 12, 2012 at 09:39:53PM +0000, Robert N. M. Watson wrote: >> >> I still find myself worried by the fact that unp->unp_vnode points at the >> nullfs vnode rather than the underlying vnode, but haven't yet managed to >> identify any actual bugs that would result. I'll continue pondering it >> over the weekend :-). KB> I think I know what could go wrong there, but due to other bug, this KB> wrongness cannot be realized now. KB> Issue is that for the forced unmount, the unp_vnode is reclaimed, so that KB> the unix domain sockets code references freed memory after reclaim. Just to have this clear, as I understand this problem with reclaim is orthogonal to the initial issue and would also exist without my patch too? Could you please tell what is the other bug? I see that after force unmount, in vflush() we call vgonel() for every vnode, and vgonel() does VOP_CLOSE(), VOP_INACTIVE(), VOP_RECLAIM(), sets v_type = VBAD, but vnode's usecount is not decreased so if a node was active it may not be freed when vdropl() is called. Was the usecount supposed to be dropped somewere in this path (when VOP_CLOSE() is called?) and this is the bug you mean or it is something else? Currently the usecount (for both VREG and VSOCK) is deacreased when the process finaly closes the discriptor. KB> Probably, some helper should provided by uipc_usrreq, called from VOP_RECLAIM() KB> implementations for VSOCK types of vnodes. I would not be very happy with adding the helper to every fs's VOP_RECLAIM() implementation :-). Couldn't it be somevere in the common code, e.g. in vflush()? Here is the patch I tried: http://people.freebsd.org/~trociny/vsock_reclaim.patch I don't know though how to export this helper function and what name would be appropriate: there are no other exported functions in uipc_usrreq.c. Thanks, -- Mikolaj Golub From owner-freebsd-arch@FreeBSD.ORG Sun Jan 22 20:43:10 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 84A491065672 for ; Sun, 22 Jan 2012 20:43:10 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 076A38FC12 for ; Sun, 22 Jan 2012 20:43:09 +0000 (UTC) Received: by werg1 with SMTP id g1so2628614wer.13 for ; Sun, 22 Jan 2012 12:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=dpct/SXUEuuQPUpSNNuptpitXmAPtHUKZJL9m2nMLE0=; b=duLtyhdFfpSug//Pt6GQutY+hde87iO/vo9TV7dw03b3z/M7oXZUjmGy7JO+gNX4QJ b3UT0+qRqncLQJeKg2ZX6u+JgfQb2SRywlIolxncYxDHT5pSmtqwmfm5wuz0CyuEMH7p xxTN3MQkaBFDY7v9jl3ChfM6KGcnd46d09EVc= Received: by 10.216.139.71 with SMTP id b49mr2574380wej.47.1327263498124; Sun, 22 Jan 2012 12:18:18 -0800 (PST) Received: from thorin (81.Red-95-122-64.staticIP.rima-tde.net. [95.122.64.81]) by mx.google.com with ESMTPS id fr8sm24050600wib.10.2012.01.22.12.18.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jan 2012 12:18:17 -0800 (PST) Sender: Robert Millan Received: from rmh by thorin with local (Exim 4.72) (envelope-from ) id 1Rp3ri-0008Ln-6y; Sun, 22 Jan 2012 21:18:14 +0100 Date: Sun, 22 Jan 2012 21:18:14 +0100 From: Robert Millan To: freebsd-arch@freebsd.org Message-ID: <20120122201814.GA32081@thorin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Adrian Chadd Subject: RFC: MK_BLOBS build option 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, 22 Jan 2012 20:43:10 -0000 --VrqPEDrXMn8OVzN4 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, I propose this build option so that users can select if they want to disable blobs of binary code in their kernel. Currently Debian does this by patchi= ng the build system; having a build option would make things much easier, but it can also be useful for users whose preference is not to install those modules. Description: Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable kernel modules that include binary-only blobs of code. More fine-grained control is provided via MK_BLOBS_HOST (for native code that runs on host CPU) and MK_BLOBS_UCODE (for microcode). Please comment! --=20 Robert Millan --AqsLC8rIMeq19msA Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mk_blobs.diff" Content-Transfer-Encoding: quoted-printable Index: sys/modules/sound/driver/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 --- sys/modules/sound/driver/Makefile (revision 230389) +++ sys/modules/sound/driver/Makefile (working copy) @@ -1,10 +1,21 @@ # $FreeBSD$ =20 -SUBDIR=3D ad1816 als4000 atiixp cs4281 csa ds1 emu10k1 emu10kx -SUBDIR+=3D envy24 envy24ht es137x ess fm801 hda ich maestro maestro3 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_BLOBS_UCODE option (see below). + +SUBDIR=3D ad1816 als4000 atiixp cs4281 ${_csa} ${_ds1} emu10k1 emu10kx +SUBDIR+=3D envy24 envy24ht es137x ess fm801 hda ich maestro ${_maestro3} SUBDIR+=3D neomagic sb16 sb8 sbc solo spicds t4dwave via8233 SUBDIR+=3D via82c686 vibes driver uaudio =20 +.if ${MK_BLOBS_UCODE} !=3D "no" +_csa=3D csa +_ds1=3D ds1 +_maestro3=3D maestro3 +.endif + .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D "amd64" SUBDIR+=3D cmi mss .endif Index: sys/modules/drm/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 --- sys/modules/drm/Makefile (revision 230389) +++ sys/modules/drm/Makefile (working copy) @@ -1,15 +1,26 @@ # $FreeBSD$ =20 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_BLOBS_UCODE option (see below). + SUBDIR =3D \ drm \ i915 \ mach64 \ - mga \ - r128 \ - radeon \ + ${_mga} \ + ${_r128} \ + ${_radeon} \ savage \ sis \ tdfx \ via =20 +.if ${MK_BLOBS_UCODE} !=3D "no" +_mga=3D mga +_r128=3D r128 +_radeon=3D radeon +.endif + .include Index: sys/modules/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 --- sys/modules/Makefile (revision 230389) +++ sys/modules/Makefile (working copy) @@ -2,6 +2,9 @@ =20 .include =20 +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_BLOBS_UCODE option (see below). + SUBDIR=3D ${_3dfx} \ ${_3dfx_linux} \ ${_aac} \ @@ -36,7 +39,7 @@ ath \ ath_pci \ ${_auxio} \ - bce \ + ${_bce} \ bfe \ bge \ ${_bxe} \ @@ -95,13 +98,13 @@ ${_ex} \ ${_exca} \ ${_ext2fs} \ - fatm \ + ${_fatm} \ fdc \ fdescfs \ ${_fe} \ firewire \ firmware \ - fxp \ + ${_fxp} \ gem \ geom \ ${_glxiic} \ @@ -147,7 +150,7 @@ ${_ipwfw} \ iscsi \ isp \ - ispfw \ + ${_ispfw} \ ${_iwi} \ ${_iwifw} \ ${_iwn} \ @@ -208,7 +211,7 @@ ${_mthca} \ mvs \ mwl \ - mwlfw \ + ${_mwlfw} \ mxge \ my \ ${_ncp} \ @@ -258,14 +261,14 @@ puc \ ${_qlxgb} \ ral \ - ralfw \ + ${_ralfw} \ ${_random} \ rc4 \ ${_rdma} \ re \ reiserfs \ rl \ - runfw \ + ${_runfw} \ ${_s3} \ ${_safe} \ ${_sbni} \ @@ -275,7 +278,7 @@ sdhci \ sem \ send \ - sf \ + ${_sf} \ ${_sfxge} \ sge \ siba_bwn \ @@ -284,7 +287,7 @@ sis \ sk \ ${_smbfs} \ - sn \ + ${_sn} \ ${_snc} \ snp \ ${_sound} \ @@ -299,7 +302,7 @@ ${_sym} \ ${_syscons} \ sysvipc \ - ti \ + ${_ti} \ tl \ tmpfs \ ${_tpm} \ @@ -308,7 +311,7 @@ twe \ tws \ tx \ - txp \ + ${_txp} \ uart \ ubsec \ udf \ @@ -357,8 +360,10 @@ # No barrier instruction support (specific to this driver) _sym=3D sym # intr_disable() is a macro, causes problems +.if ${MK_BLOBS_UCODE} !=3D "no" _cxgb=3D cxgb .endif +.endif =20 .if ${MK_CRYPT} !=3D "no" || defined(ALL_MODULES) .if exists(${.CURDIR}/../opencrypto) @@ -400,6 +405,20 @@ .endif .endif =20 +.if ${MK_BLOBS_UCODE} !=3D "no" +_bce=3D bce +_fatm=3D fatm +_fxp=3D fxp +_ispfw=3D ispfw +_mwlfw=3D mwlfw +_ralfw=3D ralfw +_runfw=3D runfw +_sf=3D sf +_sn=3D sn +_ti=3D ti +_txp=3D txp +.endif + .if ${MACHINE_CPUARCH} =3D=3D "i386" # XXX some of these can move to the general case when de-i386'ed # XXX some of these can move now, but are untested on other architectures. @@ -415,9 +434,13 @@ _bxe=3D bxe _cardbus=3D cardbus _cbb=3D cbb +.if ${MK_BLOBS_UCODE} !=3D "no" _ce=3D ce +.endif _coff=3D coff +.if ${MK_BLOBS_UCODE} !=3D "no" _cp=3D cp +.endif _cpuctl=3D cpuctl _cpufreq=3D cpufreq _cs=3D cs @@ -506,35 +529,51 @@ _cm=3D cm _cmx=3D cmx _coretemp=3D coretemp +.if ${MK_BLOBS_UCODE} !=3D "no" _ctau=3D ctau +.endif _dpt=3D dpt _ex=3D ex +.if ${MK_BLOBS_HOST} !=3D "no" _hpt27xx=3D hpt27xx +.endif _hptiop=3D hptiop +.if ${MK_BLOBS_HOST} !=3D "no" _hptmv=3D hptmv _hptrr=3D hptrr +.endif _ichwd=3D ichwd _ida=3D ida _iir=3D iir _ipmi=3D ipmi _ips=3D ips _ipw=3D ipw +.if ${MK_BLOBS_UCODE} !=3D "no" _ipwfw=3D ipwfw +.endif _iwi=3D iwi +.if ${MK_BLOBS_UCODE} !=3D "no" _iwifw=3D iwifw +.endif _iwn=3D iwn +.if ${MK_BLOBS_UCODE} !=3D "no" _iwnfw=3D iwnfw +.endif _ixgb=3D ixgb _ixgbe=3D ixgbe _mly=3D mly _nfe=3D nfe +.if ${MK_BLOBS_HOST} !=3D "no" _nve=3D nve +.endif _nvram=3D nvram _nxge=3D nxge _tpm=3D tpm _viawd=3D viawd _wpi=3D wpi +.if ${MK_BLOBS_UCODE} !=3D "no" _wpifw=3D wpifw +.endif .if ${MK_CRYPT} !=3D "no" || defined(ALL_MODULES) _padlock=3D padlock .endif @@ -586,10 +625,14 @@ _em=3D em _exca=3D exca _ext2fs=3D ext2fs +.if ${MK_BLOBS_HOST} !=3D "no" _hpt27xx=3D hpt27xx +.endif _hptiop=3D hptiop +.if ${MK_BLOBS_HOST} !=3D "no" _hptmv=3D hptmv _hptrr=3D hptrr +.endif _i2c=3D i2c _ichwd=3D ichwd _ida=3D ida @@ -600,11 +643,17 @@ _ipmi=3D ipmi _ips=3D ips _ipw=3D ipw +.if ${MK_BLOBS_UCODE} !=3D "no" _ipwfw=3D ipwfw +.endif _iwi=3D iwi +.if ${MK_BLOBS_UCODE} !=3D "no" _iwifw=3D iwifw +.endif _iwn=3D iwn +.if ${MK_BLOBS_UCODE} !=3D "no" _iwnfw=3D iwnfw +.endif _ixgb=3D ixgb _ixgbe=3D ixgbe _lindev=3D lindev @@ -620,7 +669,9 @@ .endif _ndis=3D ndis _nfe=3D nfe +.if ${MK_BLOBS_HOST} !=3D "no" _nve=3D nve +.endif _nvram=3D nvram _nxge=3D nxge .if ${MK_CDDL} !=3D "no" || defined(ALL_MODULES) @@ -650,7 +701,9 @@ _x86bios=3D x86bios _wi=3D wi _wpi=3D wpi +.if ${MK_BLOBS_UCODE} !=3D "no" _wpifw=3D wpifw +.endif .if ${MK_ZFS} !=3D "no" || defined(ALL_MODULES) _zfs=3D zfs .endif Index: sys/modules/usb/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 --- sys/modules/usb/Makefile (revision 230389) +++ sys/modules/usb/Makefile (working copy) @@ -25,16 +25,28 @@ # SUCH DAMAGE. # =20 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_BLOBS_UCODE option (see below). + SUBDIR =3D usb SUBDIR +=3D ehci musb ohci uhci xhci uss820dci ${_at91dci} ${_atmegadci} $= {_avr32dci} -SUBDIR +=3D rum run uath upgt usie ural zyd ${_urtw} +SUBDIR +=3D ${_rum} run ${_uath} upgt usie ural ${_zyd} ${_urtw} SUBDIR +=3D atp uhid ukbd ums udbp ufm uep SUBDIR +=3D ucom u3g uark ubsa ubser uchcom ucycom ufoma uftdi ugensa uipa= q ulpt \ umct umcs umodem umoscom uplcom uslcom uvisor uvscom -SUBDIR +=3D uether aue axe cdce cue kue mos rue udav uhso ipheth +SUBDIR +=3D uether aue axe cdce cue ${_kue} mos rue udav uhso ipheth SUBDIR +=3D usfs umass urio SUBDIR +=3D quirk template =20 +.if ${MK_BLOBS_UCODE} !=3D "no" +_rum=3D rum +_uath=3D uath +_zyd=3D zyd +_kue=3D kue +.endif + .if ${MACHINE_CPUARCH} =3D=3D "amd64" _urtw=3D urtw .endif Index: share/mk/bsd.own.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 --- share/mk/bsd.own.mk (revision 230389) +++ share/mk/bsd.own.mk (working copy) @@ -320,6 +320,9 @@ BOOT \ BSD_CPIO \ BSNMP \ + BLOBS \ + BLOBS_HOST \ + BLOBS_UCODE \ BZIP2 \ CALENDAR \ CAPSICUM \ @@ -511,6 +514,11 @@ MK_BIND_ETC:=3D no .endif =20 +.if ${MK_BLOBS} =3D=3D "no" +MK_BLOBS_HOST:=3D no +MK_BLOBS_UCODE:=3D no +.endif + .if ${MK_CDDL} =3D=3D "no" MK_ZFS:=3D no MK_CTF:=3D no Index: tools/build/options/WITHOUT_BLOBS =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 --- tools/build/options/WITHOUT_BLOBS (revision 0) +++ tools/build/options/WITHOUT_BLOBS (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include binary-only blobs of code (ei= ther microcode or native code for host CPU). Index: tools/build/options/WITHOUT_BLOBS_HOST =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 --- tools/build/options/WITHOUT_BLOBS_HOST (revision 0) +++ tools/build/options/WITHOUT_BLOBS_HOST (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include binary-only blobs of native c= ode for host CPU. Index: tools/build/options/WITHOUT_BLOBS_UCODE =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 --- tools/build/options/WITHOUT_BLOBS_UCODE (revision 0) +++ tools/build/options/WITHOUT_BLOBS_UCODE (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include binary-only blobs of microcod= e. --AqsLC8rIMeq19msA-- --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/kFreeBSD) iQIcBAEBCAAGBQJPHG8FAAoJELd1onhloKnOSdEQAK0I+5Lj0aP6E0I9Hz3IUiJe TwGDB9o6R+CZ4VxBNoZs+87XrDOSTxPsSkfvA6UGGHmOcdUNO7ZUoTc4QpDSM4Fl fCpXkoeuMf8DB/T0L61mkv1oZvQ0Rv+UwODyCQhMDh/no8m+v1JmUomUzIlIBrMi 9iBaLg8KR5OP8xl0IK6bIjL8eUtWQ4+dLEUZ1de+agWY3Bq5UjH5LaMFc2BGfW4R +9cefeQ8/3dyg8AgrE/namgDlaPEqEj/iSM+PrDSy+z6prlIefdryq1NUNqWTk4F iuu82CGkxsYIaWnr37kFwl4f3PunhuZ4iHXlcGV5wcMG4g0g+UlbWgGyWlPlmXUy vkEuhNdADB3Y/QrpSpk3k/1EjzEdF0cWbSJ8oZbXMIxCb1WR5JIp5tVIxMz6yjCN LXUj5W/MrZm5yjXaNm23U/hBlD7hseqKDDZYlaKU4Ydx2L9FyDTEQ3YscyJIIyyj 2VMcsQauySWtRco3oVeE13XlYoaaZrEQs4SltMYqg9r7rWwrzDX1c/ebb6PU/QUJ vZ2ShGXAdbZ5uyvkT03cqI2Rh9eXK/ORBfMyE8DfGkUJNPPP90lRkateFEGhccxM kJX7+cMCiu6EppoDDJQB8jJe25eJSjFSiDO8FEOqQqNzawosVzDtM/mgbLJGRPi9 7EYGZOuHvQFvtKXIXgam =hzoV -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 22 21:12: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 DC4A51065675 for ; Sun, 22 Jan 2012 21:12:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A36878FC0C for ; Sun, 22 Jan 2012 21:12:19 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so3562845obc.13 for ; Sun, 22 Jan 2012 13:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xi3JEvN8LzYq+ZtOr9o77Dg8eMTsmCIuruZ/0bpTYaY=; b=dWeIZ/P4Zc9ZMGPOrSdqbW5GWhK92I1m2+AGCbGGWepvIvUuZpA2jY8aNsstI6JdFU wGCQwbMeIDpbYCeEwHKMoIew69kJXGluXXuBTwMEm/FVwPnXfac0CcrNGdEEPX6Z5mIY cZvo1n57NVX9c/TBcGjV0p8dJLQdf4MRt1Lp8= MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr5558172obv.69.1327265364494; Sun, 22 Jan 2012 12:49:24 -0800 (PST) Received: by 10.182.5.162 with HTTP; Sun, 22 Jan 2012 12:49:24 -0800 (PST) In-Reply-To: <20120122201814.GA32081@thorin> References: <20120122201814.GA32081@thorin> Date: Sun, 22 Jan 2012 12:49:24 -0800 Message-ID: From: Garrett Cooper To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 22 Jan 2012 21:12:19 -0000 On Sun, Jan 22, 2012 at 12:18 PM, Robert Millan wrote: > > Hi everyone, > > I propose this build option so that users can select if they want to disa= ble > blobs of binary code in their kernel. =A0Currently Debian does this by pa= tching > the build system; having a build option would make things much easier, bu= t > it can also be useful for users whose preference is not to install those > modules. > > Description: > > =A0Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable kerne= l > =A0modules that include binary-only blobs of code. > > =A0More fine-grained control is provided via MK_BLOBS_HOST (for native co= de > =A0that runs on host CPU) and MK_BLOBS_UCODE (for microcode). What is the goal that you're trying to achieve? Is it policy based? For reducing the kernel size? Etc? Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 02:44:26 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 AA37C1065670; Mon, 23 Jan 2012 02:44:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7968B8FC08; Mon, 23 Jan 2012 02:44:26 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0N2iMF6053709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 Jan 2012 18:44:23 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F1CC9CA.2010403@freebsd.org> Date: Sun, 22 Jan 2012 18:45:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Robert Millan References: <20120122201814.GA32081@thorin> In-Reply-To: <20120122201814.GA32081@thorin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 02:44:26 -0000 On 1/22/12 12:18 PM, Robert Millan wrote: > Hi everyone, > > I propose this build option so that users can select if they want to disable > blobs of binary code in their kernel. Currently Debian does this by patching > the build system; having a build option would make things much easier, but > it can also be useful for users whose preference is not to install those > modules. > > Description: > > Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable kernel > modules that include binary-only blobs of code. > > More fine-grained control is provided via MK_BLOBS_HOST (for native code > that runs on host CPU) and MK_BLOBS_UCODE (for microcode). > > Please comment! technically it's ok, but,.. why? From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 03:12:46 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 727F2106566B; Mon, 23 Jan 2012 03:12:46 +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 7A6808FC12; Mon, 23 Jan 2012 03:12:45 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0N3Cc5S043169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0N3CcOD083236; Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0N3Cc2Q083235; Mon, 23 Jan 2012 05:12:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Jan 2012 05:12:38 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20120123031238.GL31224@deviant.kiev.zoral.com.ua> References: <86sjjobzmn.fsf@kopusha.home.net> <86fwfnti5t.fsf@kopusha.home.net> <20120112215106.GC31224@deviant.kiev.zoral.com.ua> <86hazntwmu.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bxfpw+NNV0U2roqL" Content-Disposition: inline In-Reply-To: <86hazntwmu.fsf@kopusha.home.net> 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: "Robert N. M. Watson" , freebsd-arch@freebsd.org Subject: Re: unix domain sockets on nullfs(5) 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, 23 Jan 2012 03:12:46 -0000 --bxfpw+NNV0U2roqL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 08:33:45PM +0200, Mikolaj Golub wrote: >=20 > There was a bug in my patch: for vop_unpdetach it wanted the vnode to be > exclusively locked, while it was called from the context (uipc_detach) wh= ere > the vnode is not locked. >=20 > It looks it is OK that the vnode is not locked here: the operation is to = null > vp->v_socket, and currently the only place where it is concurently access= ed is > in unp_connect(), and it is protected by the linkage lock. >=20 > So I updated my patch to have "=3D =3D =3D" for unpdetach vp. >=20 > http://people.freebsd.org/~trociny/VOP_UNP.2.patch >=20 >=20 > On Thu, 12 Jan 2012 23:51:06 +0200 Kostik Belousov wrote: >=20 > KB> On Thu, Jan 12, 2012 at 09:39:53PM +0000, Robert N. M. Watson wrote: > >>=20 > >> I still find myself worried by the fact that unp->unp_vnode points at= the > >> nullfs vnode rather than the underlying vnode, but haven't yet manage= d to > >> identify any actual bugs that would result. I'll continue pondering it > >> over the weekend :-). >=20 > KB> I think I know what could go wrong there, but due to other bug, this > KB> wrongness cannot be realized now. >=20 > KB> Issue is that for the forced unmount, the unp_vnode is reclaimed, so= that > KB> the unix domain sockets code references freed memory after reclaim. >=20 > Just to have this clear, as I understand this problem with reclaim is > orthogonal to the initial issue and would also exist without my patch too? Yes. >=20 > Could you please tell what is the other bug? I see that after force unmou= nt, > in vflush() we call vgonel() for every vnode, and vgonel() does VOP_CLOSE= (), > VOP_INACTIVE(), VOP_RECLAIM(), sets v_type =3D VBAD, but vnode's usecount= is not > decreased so if a node was active it may not be freed when vdropl() is ca= lled. The lack of the cleanup in the reclamation code. >=20 > Was the usecount supposed to be dropped somewere in this path (when > VOP_CLOSE() is called?) and this is the bug you mean or it is something e= lse? No, usecount must not be dropped. The hold count counts the owners of the pointer to the vnode, preventing the freeing of the struct vnode itself. Usecount is to avoid non-forced unmounts from reclaiming the vnode. >=20 > Currently the usecount (for both VREG and VSOCK) is deacreased when the > process finaly closes the discriptor. >=20 > KB> Probably, some helper should provided by uipc_usrreq, called from VO= P_RECLAIM() > KB> implementations for VSOCK types of vnodes. >=20 > I would not be very happy with adding the helper to every fs's VOP_RECLAI= M() > implementation :-). Couldn't it be somevere in the common code, e.g. in > vflush()? Here is the patch I tried: >=20 > http://people.freebsd.org/~trociny/vsock_reclaim.patch Not in the vflush(). I think vgonel() would be better place. >=20 > I don't know though how to export this helper function and what name woul= d be > appropriate: there are no other exported functions in uipc_usrreq.c. >=20 > Thanks, >=20 > --=20 > Mikolaj Golub --bxfpw+NNV0U2roqL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8c0CYACgkQC3+MBN1Mb4igBgCePsf2rnJEcCW+O8gCzFalOyiI 62QAni+3kpxCrOTA86kolmPY4PM4K0Gh =Xyx8 -----END PGP SIGNATURE----- --bxfpw+NNV0U2roqL-- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 07:10:14 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 91090106566B; Mon, 23 Jan 2012 07:10:14 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECE38FC12; Mon, 23 Jan 2012 07:10:14 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id z16so6463909iag.13 for ; Sun, 22 Jan 2012 23:10:13 -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=zdPsSi4KhXg+ffF7BgRfDSlulLWRE3pAud7qfo//azQ=; b=OzhV5bQvsuyI1zz9FiZmcxBVM2C6X6KT1O8kEfkKZRARgBeXE9xKWACn9XUpyVpvHJ 4DCpUV7oLOS1QsXgi8VhNZjK70kmSaarjuQlXJwboWl1pxcUmS+zhTWARvl7soNjuts+ JlI/v2kzTzyMUN/MGVXavD6fqfwL4TkWcl/xE= MIME-Version: 1.0 Received: by 10.50.6.227 with SMTP id e3mr9284952iga.20.1327302613933; Sun, 22 Jan 2012 23:10:13 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.227.133 with HTTP; Sun, 22 Jan 2012 23:10:13 -0800 (PST) In-Reply-To: References: <20120122201814.GA32081@thorin> Date: Mon, 23 Jan 2012 07:10:13 +0000 X-Google-Sender-Auth: o4FBVJmrzk3tlGHUD8povd5aljU Message-ID: From: Robert Millan To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 07:10:14 -0000 El 22 de gener de 2012 20:49, Garrett Cooper ha escrit: > What is the goal that you're trying to achieve? Is it policy based? Yes. Specifically, Debian has a policy of not including them. Individual users and organizations may have their own policies. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 19:34: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 A561E1065670; Mon, 23 Jan 2012 19:34:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id F1D528FC14; Mon, 23 Jan 2012 19:34:12 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0NJYCuL000528; Mon, 23 Jan 2012 14:34:12 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0NJYCtd000527; Mon, 23 Jan 2012 14:34:12 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 23 Jan 2012 14:34:12 -0500 From: David Schultz To: Robert Millan Message-ID: <20120123193412.GA353@zim.MIT.EDU> Mail-Followup-To: Robert Millan , freebsd-arch@freebsd.org, Kostik Belousov , Adrian Chadd , tabthorpe@FreeBSD.org References: <20120122201814.GA32081@thorin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120122201814.GA32081@thorin> Cc: Kostik Belousov , Adrian Chadd , tabthorpe@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 19:34:16 -0000 On Sun, Jan 22, 2012, Robert Millan wrote: > I propose this build option so that users can select if they want to disable > blobs of binary code in their kernel. Currently Debian does this by patching > the build system; having a build option would make things much easier, but > it can also be useful for users whose preference is not to install those > modules. > > Description: > > Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable kernel > modules that include binary-only blobs of code. > > More fine-grained control is provided via MK_BLOBS_HOST (for native code > that runs on host CPU) and MK_BLOBS_UCODE (for microcode). > > Please comment! There has been recent work on the ports system to allow users to specify what licenses are considered acceptable for software installed on their machines. The blob issue reflects a similar concern, so it's worth looking at what they have done to see if there are any good ideas you might want to adopt: http://wiki.freebsd.org/PortsLicenseInfrastructure In particular, maybe someone will want to add a way to disable building drivers covered by GPL, APSL, etc. So does it make sense to rename the knob to something along the lines of `ACCEPTABLE_LICENSES+=blob'? Note that this is a mostly uninformed suggestion, so if you're already aware of the ports license infrastructure work and don't think it's apropos to this knob, then don't worry about it. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 19:57:10 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 E50DD1065739; Mon, 23 Jan 2012 19:57:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id CA4C18FC17; Mon, 23 Jan 2012 19:57:10 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0C47ACA7C; Mon, 23 Jan 2012 11:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1327348630; bh=v1X443+FsvTedmN/y/aKp8snqwo3TimzFwI6AeMhj0U=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WGBEYzWM1EXnJgVs7w/AqolVIf6eieTsc0uCBC5jktdIFErhbxAdueQRvZsfK6+Ox F94GHpMzil+TBFlKKpYW18J/Fr3RzH9USOfqlhmA8ZxVjwIGKgFyC5rntAM9xtiDU8 MKpEMhHnKGEHA6KCDbET1vX9LO9J9dEn9xBu+Sw4= Message-ID: <4F1DBB94.900@delphij.net> Date: Mon, 23 Jan 2012 11:57:08 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Robert Millan References: <20120122201814.GA32081@thorin> In-Reply-To: <20120122201814.GA32081@thorin> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 19:57:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/22/12 12:18, Robert Millan wrote: > > Hi everyone, > > I propose this build option so that users can select if they want > to disable blobs of binary code in their kernel. Currently Debian > does this by patching the build system; having a build option would > make things much easier, but it can also be useful for users whose > preference is not to install those modules. > > Description: > > Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable > kernel modules that include binary-only blobs of code. > > More fine-grained control is provided via MK_BLOBS_HOST (for native > code that runs on host CPU) and MK_BLOBS_UCODE (for microcode). > > Please comment! Yes I think that would be good to have. Please note that it's still possible to compile these into kernel if they present in the kernel compile configuration (for instance, device hptmv), which sounds a little bit non-intuitive to me. Maybe we should create three include file (BLOBS, BLOBS_HOST, BLOBS_UCODE perhaps) that lists these modules as 'nodevice ' in the same time, so they can be included from a kernel configuration file at the end? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8du5QACgkQOfuToMruuMD0OwCdFSZe+qzxl2mM70MYdwu73Oo5 wXoAn0Iy8/hRs3NFThTSKLFYEl3dSQDS =+9aQ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 22:04:04 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 CBDDF106566C; Mon, 23 Jan 2012 22:04:04 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED3C8FC0A; Mon, 23 Jan 2012 22:04:03 +0000 (UTC) Received: by ggnq2 with SMTP id q2so615986ggn.13 for ; Mon, 23 Jan 2012 14:04:03 -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:content-type :content-transfer-encoding; bh=WQ8QBs3IeD17ify1lE+JvpHxE3Oz4mnLnVzzJorttHg=; b=aYAD/gMSNQXwqtgEoFfkh8HoPQA7kVmDvXoLC4ThcH35HaMA+E3aKaJWy73ztwHKUL xoos1Kw5CVpa+UUrQ65K34x9Zh2dQtwlbPrfwQLWoRWaBcj6EX8WU8golgpyWcDvjznh RQQ4kxoX4E43ZMUBseS3fp9J/3dEsWDNYgvDU= MIME-Version: 1.0 Received: by 10.50.236.73 with SMTP id us9mr63721igc.16.1327356243485; Mon, 23 Jan 2012 14:04:03 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Mon, 23 Jan 2012 14:04:03 -0800 (PST) In-Reply-To: <20120123193412.GA353@zim.MIT.EDU> References: <20120122201814.GA32081@thorin> <20120123193412.GA353@zim.MIT.EDU> Date: Mon, 23 Jan 2012 22:04:03 +0000 X-Google-Sender-Auth: Pcn6FDNFD4gBgktghxsIaZm8Wkg Message-ID: From: Robert Millan To: Robert Millan , freebsd-arch@freebsd.org, Kostik Belousov , Adrian Chadd , tabthorpe@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 22:04:04 -0000 Hi David, El 23 de gener de 2012 19:34, David Schultz ha escrit: > There has been recent work on the ports system to allow users to > specify what licenses are considered acceptable for software > installed on their machines. =C2=A0The blob issue reflects a similar > concern, so it's worth looking at what they have done to see if > there are any good ideas you might want to adopt: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://wiki.freebsd.org/PortsLicenseInfrastruc= ture > > In particular, maybe someone will want to add a way to disable > building drivers covered by GPL, APSL, etc. =C2=A0So does it make sense > to rename the knob to something along the lines of > `ACCEPTABLE_LICENSES+=3Dblob'? > > Note that this is a mostly uninformed suggestion, so if you're > already aware of the ports license infrastructure work and don't > think it's apropos to this knob, then don't worry about it. I looked in detail at the documentation you pointed. My impression is that this infrastructure is designed to address a very different problem. Some notable differences: - It concerns about things like license compatibility between ports. If there's a license incompatibility in kernel, it affects the whole tree, it's a lot more manual verification work which is already in place. - In src MK_* build options are already stablished practice. Adding new options and using them in Makefiles fits well with the desired goal. - src already has a license split (/gnu, /cddl...) and the diversity of license groups is much smaller. There are already build options concerned with GPL, for example MK_BSD_GREP. When some users have had this need, existing MK_* framework seems to have satisfied them. [1] http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.ht= ml From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 22:17:29 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 4F91D106566B; Mon, 23 Jan 2012 22:17:29 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF8F8FC17; Mon, 23 Jan 2012 22:17:28 +0000 (UTC) Received: by iagz16 with SMTP id z16so7965610iag.13 for ; Mon, 23 Jan 2012 14:17:28 -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=bcIn4oGhvVMNu4BJDUal8FNGJjVikFGmep9l4I6nB+M=; b=fk1+1x6Soi92d1oLTkLp3DjDKMYc/CCiGxoPmGnl9l/jxZOoCefpry5EOqpKu92dKK LXrzdX2ufSF2yhUgvwy8Zlth7gLsx2C+4doVOIR8YUGuIXaRhqPXMKmCk0NInp/R0/vf bbANhxuvpCjP80FPihObBhq1qYHF7sWkcNf0k= MIME-Version: 1.0 Received: by 10.42.131.136 with SMTP id z8mr9725131ics.5.1327357048440; Mon, 23 Jan 2012 14:17:28 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Mon, 23 Jan 2012 14:17:28 -0800 (PST) In-Reply-To: <4F1DBB94.900@delphij.net> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> Date: Mon, 23 Jan 2012 22:17:28 +0000 X-Google-Sender-Auth: o1FU0hk3FFVmHyckvBMX8kWOL6k Message-ID: From: Robert Millan To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 22:17:29 -0000 El 23 de gener de 2012 19:57, Xin Li ha escrit: > Please note that it's still possible to compile these into kernel if > they present in the kernel compile configuration (for instance, device > hptmv), which sounds a little bit non-intuitive to me. =C2=A0Maybe we > should create three include file (BLOBS, BLOBS_HOST, BLOBS_UCODE > perhaps) that lists these modules as 'nodevice ' in the > same time, so they can be included from a kernel configuration file at > the end? Sounds useful, but I'm not sure how would one implement this so that it is maintainable and doesn't break. First when you create a file to disable ucode-blobs, you have to enumerate the drivers again, creating redundancy (which usually leads to bitrot). Then when you create a file that disables both ucode-blobs and host-blobs, you either enumerate the drivers over again, adding a second level of redundancy, or have to use "include" directive. But you can't just include both ucode-blob and host-blob files because they both include GENERIC, and then GENERIC would be included twice, right? The idea sounds great (in my case it'd allow me to reduce our delta a bit further), but in practice I'm not sure this can work. From owner-freebsd-arch@FreeBSD.ORG Mon Jan 23 23:17: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 66B391065670; Mon, 23 Jan 2012 23:17:30 +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 EEB5A8FC13; Mon, 23 Jan 2012 23:17:29 +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 q0NNDo6D086100 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 16:13:50 -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: <4F1DBB94.900@delphij.net> Date: Mon, 23 Jan 2012 16:13:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0455F6A3-A04A-43C0-9E40-B19ABC4FDDAF@bsdimp.com> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> To: d@delphij.net 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]); Mon, 23 Jan 2012 16:13:51 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, Robert Millan Subject: Re: RFC: MK_BLOBS build option 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, 23 Jan 2012 23:17:30 -0000 I like the idea, but hate the name. BLOB has a negative connotation, = and this option would seem to imply the project doesn't like blobs, = which isn't the case. Can we find a different name for this please? Warner On Jan 23, 2012, at 12:57 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 01/22/12 12:18, Robert Millan wrote: >>=20 >> Hi everyone, >>=20 >> I propose this build option so that users can select if they want >> to disable blobs of binary code in their kernel. Currently Debian >> does this by patching the build system; having a build option would >> make things much easier, but it can also be useful for users whose >> preference is not to install those modules. >>=20 >> Description: >>=20 >> Add MK_BLOBS build option. Setting MK_BLOBS to "no" will disable >> kernel modules that include binary-only blobs of code. >>=20 >> More fine-grained control is provided via MK_BLOBS_HOST (for native >> code that runs on host CPU) and MK_BLOBS_UCODE (for microcode). >>=20 >> Please comment! >=20 > Yes I think that would be good to have. >=20 > Please note that it's still possible to compile these into kernel if > they present in the kernel compile configuration (for instance, device > hptmv), which sounds a little bit non-intuitive to me. Maybe we > should create three include file (BLOBS, BLOBS_HOST, BLOBS_UCODE > perhaps) that lists these modules as 'nodevice ' in the > same time, so they can be included from a kernel configuration file at > the end? >=20 > Cheers, > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk8du5QACgkQOfuToMruuMD0OwCdFSZe+qzxl2mM70MYdwu73Oo5 > wXoAn0Iy8/hRs3NFThTSKLFYEl3dSQDS > =3D+9aQ > -----END PGP SIGNATURE----- > _______________________________________________ > 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" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 07:45:32 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 CC1E51065670 for ; Tue, 24 Jan 2012 07:45:32 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9538FC12 for ; Tue, 24 Jan 2012 07:45:32 +0000 (UTC) Received: from [24.87.53.93] (helo=[192.168.1.116]) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Rpb4I-0003HZ-O2; Mon, 23 Jan 2012 23:45:27 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <4F1A3B58.7040001@freebsd.org> Date: Mon, 23 Jan 2012 23:45:29 -0800 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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> <4F1A3B58.7040001@freebsd.org> To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1084) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote: > On 20/01/2012 5:43 PM, Warner Losh wrote: >> >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >>> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up? >> >> Sure there is: you can do it by name. I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer. My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t. I wonder why we can't do that here? > > I've been thinking about it recently in regard to GPIO subsystem. > And the same issue appeared during OMAP code import: there are at least > two subsystems that are used by the rest of the drivers. Ben's suggested > following solution: define kobj interface if_SUBSYTEM.m and then > provide API call in form: > > int omap_prcm_clk_enable(clk_ident_t clk) > { > device_t prcm_dev; > > prcm_dev = devclass_get_device(devclass_find("omap_prcm"), 0); > if (prcm_dev == NULL) { > printf("Error: failed to get the PRCM device\n"); > return (EINVAL); > } > > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); > } > > So it might make sense to create some kind of upper-level API for > defining this kind of subsystems' APIs since every implementation > would duplicate a lot of code: look for instance of specific > devclass, check if it exists. Not sure how to do it at the moment > though. [...] Content analysis details: (-4.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list Cc: Ben Gray 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: Tue, 24 Jan 2012 07:45:32 -0000 On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote: > On 20/01/2012 5:43 PM, Warner Losh wrote: >>=20 >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >>> The second problem is that there's currently no way to express a = dependency between two devices other than a parent-child relationship. = I would be interested to learn why this appears to be so uncommon that I = could not find any discussion of such a feature. Has it really never = before come up? >>=20 >> Sure there is: you can do it by name. I wrote a driver that attached = to the ISA bus, but also needed to talk to the ppbus that was attached = to the printer. My solution was to have a post-attach name-lookup so = that it could then call methods on the other driver's device_t. I = wonder why we can't do that here? >=20 > I've been thinking about it recently in regard to GPIO subsystem. > And the same issue appeared during OMAP code import: there are at = least > two subsystems that are used by the rest of the drivers. Ben's = suggested > following solution: define kobj interface if_SUBSYTEM.m and then > provide API call in form: >=20 > int omap_prcm_clk_enable(clk_ident_t clk) > { > device_t prcm_dev; >=20 > prcm_dev =3D devclass_get_device(devclass_find("omap_prcm"), = 0); > if (prcm_dev =3D=3D NULL) { > printf("Error: failed to get the PRCM device\n"); > return (EINVAL); > } >=20 > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); > } >=20 > So it might make sense to create some kind of upper-level API for > defining this kind of subsystems' APIs since every implementation > would duplicate a lot of code: look for instance of specific > devclass, check if it exists. Not sure how to do it at the moment > though. I tinkered a little bit with this idea and here is what I've come up = with so far: http://people.freebsd.org/~gonzo/patches/horizontal-api.diff this patch adds one more available declaration to .m files: APIMETHOD In addition to usual kobj method declaration one more function is = generated. This function gets first device in devclass with the same name as = declared interface and uses it as object for respective method call.=20 Also if there is at least one APIMETHOD in interface one more function = called=20 XXXX_available() is generated. It returns 1 if there is device of = required devclass. Usage example: int maxpin; printf("GPIO available: %d\n", gpio_available()); if (gpio_available()) { gpio_pin_max(&maxpin); printf("GPIO pins: %d\n", maxpin); } Possible improvements: instead of using devclass for identifying kobj,=20= create way for device to explicitly register/deregister as an API = "provider".=20 Comments, ideas?= From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 09:44: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 82E8A106564A; Tue, 24 Jan 2012 09:44:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57BF98FC1A; Tue, 24 Jan 2012 09:44:59 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E568446B2A; Tue, 24 Jan 2012 04:44:58 -0500 (EST) Date: Tue, 24 Jan 2012 09:44:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Robert Millan In-Reply-To: Message-ID: References: <20120122201814.GA32081@thorin> <20120123193412.GA353@zim.MIT.EDU> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Adrian Chadd , tabthorpe@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 24 Jan 2012 09:44:59 -0000 On Mon, 23 Jan 2012, Robert Millan wrote: > I looked in detail at the documentation you pointed. My impression is that > this infrastructure is designed to address a very different problem. Some > notable differences: > > - It concerns about things like license compatibility between ports. If > there's a license incompatibility in kernel, it affects the whole tree, it's > a lot more manual verification work which is already in place. > > - In src MK_* build options are already stablished practice. Adding new > options and using them in Makefiles fits well with the desired goal. > > - src already has a license split (/gnu, /cddl...) and the diversity of > license groups is much smaller. There are already build options concerned > with GPL, for example MK_BSD_GREP. When some users have had this need, > existing MK_* framework seems to have satisfied them. There's a related concern to do with "license leakage" into the GENERIC kernel. The policy of the project is that the GENERIC kernel should essentially be BSD-licensed -- GPL, CDDL, etc, code needs to be compiled out by default, although compiled into modules is considered fine. One reason that KDTRACE_HOOKS is not in GENERIC is that no one has done a careful review to ensure that it doesn't lead to CDDL in GENERIC. It would be nice if we had tools to not only perform those checks, but also allow us to induce compile failures as part of tinderboxing if something goes wrong. It's an interesting question as to how "hard line" you get about this: how do we want to treat uuencoded firmware bits in device drivers that allow unlimited distribution but not reverse engineering, for example? I don't want to get into the politics of this, nor the specific spellings, except to say that we (a) can't provide guarantees (and especially not indemnification) to our users but (b) we do want to help them do their jobs more easily, in which case tools to help them analyse their license obligations when using FreeBSD would have benefit. Count me on in Warner's comment regarding "blob" -- binary-only (or, for that matter, obfuscated) content is a contentious issue. In as much as we can provide accurate while less potentially inflamatory descriptions, I think that's a useful thing to do. Possibly we should keep vaguely in mind the IETF mantra of being liberal about what we accept (i.e., support components under a variety of licenses) and conservative about what we generate (create as much code as possible under the BSD license). However, there is an immediate practical benefit to resolving the DTrace hooks situation, and some of the tools used to do that would be more broadly relevant. I'd like it very much if we had KDTRACE_HOOKS compiled into GENERIC -- it's one of the reasons why I find myself still using custom kernels in many configurations. Robert From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 10:35:12 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 1239F106566B; Tue, 24 Jan 2012 10:35:12 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C25EC8FC16; Tue, 24 Jan 2012 10:35:11 +0000 (UTC) Received: by iagz16 with SMTP id z16so9229210iag.13 for ; Tue, 24 Jan 2012 02:35:11 -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=ehAYWNHBRj5YyJs9k9HeWqsbxamn5+oKy8HPRtSXUZM=; b=QuN0+IevJnecUr86uAann5xnibXvynNKr0q4P8vZ1VBr2cbU+vA2AWxGsCmGzBHnqp Wh1ebLCEriIIWAm5JBKudKxQMgoEQIjsYJRiTgFyhpXda67m+z35dAFZkSz2ZZdMGN2N JvUSJvRgh2SQcQoAdigbGd0b+wm8bIEkOaMUo= MIME-Version: 1.0 Received: by 10.50.6.137 with SMTP id b9mr14115907iga.16.1327401311113; Tue, 24 Jan 2012 02:35:11 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Tue, 24 Jan 2012 02:35:11 -0800 (PST) In-Reply-To: <0455F6A3-A04A-43C0-9E40-B19ABC4FDDAF@bsdimp.com> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> <0455F6A3-A04A-43C0-9E40-B19ABC4FDDAF@bsdimp.com> Date: Tue, 24 Jan 2012 10:35:11 +0000 X-Google-Sender-Auth: nYbmYe0fQf5Pv2GDD7kefRfYvJE Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 24 Jan 2012 10:35:12 -0000 El 23 de gener de 2012 23:13, Warner Losh ha escrit: > I like the idea, but hate the name. =C2=A0BLOB has a negative connotation= , and this option would seem to imply the project doesn't like blobs, which= isn't the case. =C2=A0Can we find a different name for this please? I'm open to suggestions. What would you call them? From owner-freebsd-arch@FreeBSD.ORG Tue Jan 24 14:10:29 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 E8EA21065670 for ; Tue, 24 Jan 2012 14:10:28 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 62FF58FC15 for ; Tue, 24 Jan 2012 14:10:28 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 2E061C4930; Tue, 24 Jan 2012 15:51:30 +0200 (EET) Date: Tue, 24 Jan 2012 15:53:41 +0200 From: Aleksandr Rybalko To: Oleksandr Tymoshenko Message-Id: <20120124155341.84a000f5.ray@dlink.ua> In-Reply-To: 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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> <4F1A3B58.7040001@freebsd.org> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ben Gray , 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: Tue, 24 Jan 2012 14:10:29 -0000 On Mon, 23 Jan 2012 23:45:29 -0800 Oleksandr Tymoshenko wrote: >> >> On 2012-01-20, at 8:13 PM, Oleksandr Tymoshenko wrote: >> >> > On 20/01/2012 5:43 PM, Warner Losh wrote: >> >> >> >> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >> >>> The second problem is that there's currently no way to express a >> >>> dependency between two devices other than a parent-child >> >>> relationship. I would be interested to learn why this appears >> >>> to be so uncommon that I could not find any discussion of such a >> >>> feature. Has it really never before come up? >> >> >> >> Sure there is: you can do it by name. I wrote a driver that >> >> attached to the ISA bus, but also needed to talk to the ppbus >> >> that was attached to the printer. My solution was to have a >> >> post-attach name-lookup so that it could then call methods on the >> >> other driver's device_t. I wonder why we can't do that here? >> > >> > I've been thinking about it recently in regard to GPIO >> > subsystem. And the same issue appeared during OMAP code import: >> > there are at least two subsystems that are used by the rest of the >> > drivers. Ben's suggested following solution: define kobj interface >> > if_SUBSYTEM.m and then provide API call in form: >> > >> > int omap_prcm_clk_enable(clk_ident_t clk) >> > { >> > device_t prcm_dev; >> > >> > prcm_dev = devclass_get_device(devclass_find("omap_prcm"), >> > 0); if (prcm_dev == NULL) { >> > printf("Error: failed to get the PRCM device\n"); >> > return (EINVAL); >> > } >> > >> > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); >> > } >> > >> > So it might make sense to create some kind of upper-level API for >> > defining this kind of subsystems' APIs since every implementation >> > would duplicate a lot of code: look for instance of specific >> > devclass, check if it exists. Not sure how to do it at the moment >> > though. >> >> >> I tinkered a little bit with this idea and here is what I've come up >> with so far: >> >> http://people.freebsd.org/~gonzo/patches/horizontal-api.diff >> >> this patch adds one more available declaration to .m files: APIMETHOD >> In addition to usual kobj method declaration one more function is >> generated. This function gets first device in devclass with the same >> name as declared interface and uses it as object for respective >> method call. >> >> Also if there is at least one APIMETHOD in interface one more >> function called XXXX_available() is generated. It returns 1 if there >> is device of required devclass. >> >> Usage example: >> int maxpin; >> >> printf("GPIO available: %d\n", gpio_available()); >> if (gpio_available()) { >> gpio_pin_max(&maxpin); >> printf("GPIO pins: %d\n", maxpin); >> } >> >> Possible improvements: instead of using devclass for identifying >> kobj, create way for device to explicitly register/deregister as an >> API "provider". If I understand patch correct, it will search for device every "API" call. Is it good? >> >> >> Comments, ideas?_______________________________________________ >> 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" -- Alexandr Rybalko aka Alex RAY From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 07:12: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 C7C4B1065673; Wed, 25 Jan 2012 07:12:41 +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 4A7D48FC0C; Wed, 25 Jan 2012 07:12:40 +0000 (UTC) Received: by vcmm1 with SMTP id m1so27059vcm.13 for ; Tue, 24 Jan 2012 23:12:40 -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=Id9fczfgFoBQWogvc28rJvIOEwkrfZSk4atflRr27Tk=; b=KmvBhU74FqjdgLiqXCa+HucZG1/QZrXyA2S1iaEXmWlm2tIfSM6P3PFsjkKadP3ByR w2RHQXcE/73oXecK0FoVvTSki1lfhiUwr2NxTBAVZemvgjgnTkv7aaC1d03o4d1SG1Ve ihsYNfSWMEJ6nScD2OFTe6rDfAkuI9KoIlZyI= MIME-Version: 1.0 Received: by 10.52.74.163 with SMTP id u3mr8091806vdv.91.1327475560466; Tue, 24 Jan 2012 23:12:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.71.241 with HTTP; Tue, 24 Jan 2012 23:12:40 -0800 (PST) In-Reply-To: <20120122195130.360261ce.ray@freebsd.org> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> Date: Tue, 24 Jan 2012 23:12:40 -0800 X-Google-Sender-Auth: JuVWj5UrP9u-xuS7xBtP0RbAsIk Message-ID: From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Stefan Bethke , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework 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, 25 Jan 2012 07:12:41 -0000 So when will you two have something consensus-y to commit? :-) What I'm hoping for is: * some traction on the MII bus / MDIO bus split and tidyup from stb, which is nice; * ray's switch API for speaking to userland with; * agreeing on whether the correct place to put the driver(s) is where stb, ray, or a mix of both approaches says so. I've been (mostly) trying to stay out of this to see where both of you have gone. I think we've made some good progress; now it's time to solidify a design for the first pass of what we want in -HEAD and figure out how to move forward. Adrian On 22 January 2012 09:51, Aleksandr Rybalko wrote: > On Sun, 22 Jan 2012 16:31:06 +0100 > Stefan Bethke wrote: > > > Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko: > > > > > It include sys/mips/conf/AR7240, that together with hints file is > > > good example for typical AR7240 setup. > > > > I=C4m heaving trouble getting this to work. The patch applies cleanly > > and I can get a kernel compiled and booted, but neither arge0 nor > > arge1 appear to be functional. I had to roll my own kernel config as > > your AR7240 hangs before printing anything on my TL-MR3420. > > Yeah, I know where is problem, to proper attach switch framework to > arge, arge must be regular NIC. Here is the patch for that: > http://my.ddteam.net/files/2012-01-22_arge.patch > Hope it will apply cleanly. > > Patch have fixed both arge problems (problem for allocation of ring > buffer, and stray interrupts) + remove most phymask bits + whitespace > cleanup. > > Thank you for testing that Stefan. > > P.S. I can't test clear SoC config on my board, because my board id > D-Link DIR-615_E4 with modified U-Boot in it, which able to load only > FW images, but not ELF kernel. So I test it with ZRouter.org FW image > instead. > > P.P.S. can you also show me network part of your config and hints files. > > P.P.P.S. still working on your previous question about subj, already > begin work on more wide documentation on wiki, but still far enough :) > "http://wiki.freebsd.org/AleksandrRybalko/Switch Framework" > > > > > dmesg and devinfo below. > > > > > > Stefan > > > > CPU platform: Atheros AR7241 rev 1 > > CPU Frequency=3D400 MHz > > CPU DDR Frequency=3D400 MHz > > CPU AHB Frequency=3D200 MHz > > platform frequency: 400000000 > > arguments: > > a0 =3D 00000008 > > a1 =3D a1f87fb0 > > a2 =3D a1f88470 > > a3 =3D 00000004 > > Cmd line:argv is invalid > > Environment: > > envp is invalid > > Cache info: > > picache_stride =3D 4096 > > picache_loopcount =3D 16 > > pdcache_stride =3D 4096 > > pdcache_loopcount =3D 8 > > cpu0: MIPS Technologies processor v116.147 > > MMU: Standard TLB, 16 entries > > L1 i-cache: 4 ways of 512 sets, 32 bytes per line > > L1 d-cache: 4 ways of 256 sets, 32 bytes per line > > Config1=3D0x9ee3519e > > Config3=3D0x20 > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2012 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > 1994 The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 10.0-CURRENT #1: Thu Jan 1 01:00:00 CET 1970 > > stb@dummy > :/home/stb/working/fe/obj/mipseb/mips.mipseb/home/stb/working/fe/freebsd/= sys/TL-MR3420D > > mips WARNING: WITNESS option enabled, expect reduced performance. > > real memory =3D 33554432 (32768K bytes) > > avail memory =3D 25567232 (24MB) > > random device not loaded; using insecure entropy > > nexus0: > > nexus0: failed to add child: arge0 > > nexus0: failed to add child: arge1 > > clock0: on nexus0 > > Timecounter "MIPS32" frequency 200000000 Hz quality 800 > > Event timer "MIPS32" frequency 200000000 Hz quality 800 > > apb0 at irq 4 on nexus0 > > uart0: <16550 or compatible> on apb0 > > uart0: console (115200,n,8,1) > > gpio0: on apb0 > > gpio0: [GIANT-LOCKED] > > gpio0: function_set: 0x0 > > gpio0: function_clear: 0x0 > > gpio0: gpio pinmask=3D0x1943 > > gpioc0: on gpio0 > > gpiobus0: on gpio0 > > gpioled0: at pin(s) 0 on gpiobus0 > > gpioled1: at pin(s) 1 on gpiobus0 > > gpioled2: at pin(s) 3 on gpiobus0 > > ehci0: at mem > > 0x1b000100-0x1bffffff irq 1 on nexus0 usbus0: set host controller mode > > usbus0: EHCI version 1.0 > > usbus0: set host controller mode > > usbus0: on ehci0 > > arge0: at mem > > 0x19000000-0x19000fff irq 2 on nexus0 arge0: Overriding MAC from > > EEPROM arge0: No PHY specified, using mask 16 > > miibus0: on arge0 > > floatphy0 PHY 0 on miibus0 > > floatphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseSX, 1000baseSX-FDX, 1000baseT, 1000baseT-master, > > 1000baseT-FDX, 1000baseT-FDX-master, auto switch0 PHY 1 on miibus0 > > switch0: 100baseTX, 100baseTX-FDX, 1000baseSX, 1000baseSX-FDX, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master > > ar8x16_switch0: on > > switch0 arge0: Ethernet address: ff:ff:ff:ff:ff:ff arge1: > AR71xx built-in ethernet interface> at mem 0x1a000000-0x1a000fff irq > > 3 on nexus0 arge1: No PHY specified, using mask 15 arge1: Ethernet > > address: ff:ff:ff:ff:ff:00 spi0: at mem > > 0x1f000000-0x1f00000f on nexus0 spibus0: on spi0 mx25l0: > > at cs 0 on spibus0 mx25l0: s25s1032, sector > > 65536 bytes, 64 sectors ar71xx_wdog0: > > on nexus0 ar71xx_wdog0: Previous reset was due to watchdog timeout > > Timecounters tick every 1.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on > > usbus0 WARNING: WITNESS option enabled, expect reduced performance. > > uhub0: 1 port with 1 removable, self powered > > Root mount waiting for: usbus0 > > Root mount waiting for: usbus0 > > Root mount waiting for: usbus0 > > ugen0.2: at usbus0 > > umass0: > > on usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > > umass0:0:0:-1: Attached to scbus0 > > Trying to mount root from ufs:map/rootfs.uzip []... > > mountroot: waiting for device map/rootfs.uzip ... > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 > > device da0: 40.000MB/s transfers > > da0: 15252MB (31236096 512 byte sectors: 255H 63S/T 1944C) > > Trying to mount root from ufs:da0s1a []... > > warning: no time-of-day clock registered, system time will not be set > > accurately Setting hostuuid: aed4c502-193a-11e1-b662-74ea3ae4d920. > > Setting hostid: 0x6a714343. > > Entropy harvesting: interrupts ethernet point_to_point kickstart. > > Starting file system checks: > > /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > > /dev/da0s1a: clean, 3849245 free (1085 frags, 481020 blocks, 0.0% > > fragmentation) lock order reversal: > > 1st 0x8095691c ufs (ufs) > > @ /home/stb/working/fe/freebsd/sys/kern/vfs_mount.c:1245 2nd > > 0x80956e94 devfs (devfs) > > @ /home/stb/working/fe/freebsd/sys/kern/vfs_subr.c:2167 KDB: stack > > backtrace: db_trace_thread+30 (?,?,?,?) ra c3f597c000000018 sp 0 sz 0 > > db_trace_self+1c (?,?,?,?) ra c3f597d800000018 sp 0 sz 0 800776d8+34 > > (?,?,?,?) ra c3f597f0000001a0 sp 0 sz 0 kdb_backtrace+44 (?,?,?,?) ra > > c3f5999000000018 sp 0 sz 0 801b3bbc+34 (?,?,?,?) ra c3f599a800000020 > > sp 0 sz 0 witness_checkorder+9cc (?,?,803b1f7c,877) ra > > c3f599c800000050 sp 0 sz 1 __lockmgr_args+948 (?,?,80956eb4,?) ra > > c3f59a1800000070 sp 0 sz 1 vop_stdlock+4c (?,?,?,?) ra > > c3f59a8800000028 sp 0 sz 0 VOP_LOCK1_APV+e4 (?,?,?,?) ra > > c3f59ab000000020 sp 0 sz 0 _vn_lock+84 (?,?,?,?) ra c3f59ad000000048 > > sp 0 sz 0 vget+c8 (?,?,?,?) ra c3f59b1800000030 sp 0 sz 0 > > devfs_allocv+100 (?,?,?,?) ra c3f59b4800000038 sp 0 sz 0 > > 800ba9b4+4c (?,?,?,?) ra c3f59b8000000028 sp 0 sz 0 > > vflush+6c (?,?,0,80991300) ra c3f59ba8000000f8 sp 0 sz 1 > > 800baa74+54 (?,?,?,?) ra c3f59ca000000028 sp 0 sz 0 > > dounmount+3f0 (809e8000,?,?,?) ra c3f59cc800000050 sp 100000000 sz 0 > > sys_unmount+39c (?,?,?,?) ra c3f59d18000000b0 sp 0 sz 0 > > trap+7f4 (?,?,?,?) ra c3f59dc8000000b8 sp 0 sz 0 > > MipsUserGenException+10c (?,?,?,404b53c0) ra c3f59e8000000000 sp 0 sz > > 0 pid 70 > > Mounting local file systems:. > > Setting hostname: whitebox.lassitu.de. > > miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > > floatphy0: found master switch0 > > miibus0: mii_mediachg: can't handle non-zero PHY instance 1 > > arge0: link state changed to DOWN > > Starting Network: lo0 arge0 arge1. > > lo0: flags=3D8049 metric 0 mtu 16384 > > options=3D3 > > inet6 ::1 prefixlen 128 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > > inet 127.0.0.1 netmask 0xff000000 > > nd6 options=3D21 > > arge0: flags=3D8843 metric 0 > > mtu 1500 options=3D80000 > > ether ff:ff:ff:ff:ff:ff > > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > > inet6 fe80::481f:1b46:dbf1:bd78%arge0 prefixlen 64 scopeid > > 0x2 nd6 options=3D29 > > media: Ethernet autoselect (100baseTX ) > > status: no carrier > > arge1: flags=3D8843 metric 0 > > mtu 1500 ether ff:ff:ff:ff:ff:00 > > inet 44.128.65.33 netmask 0xffffffc0 broadcast 44.128.65.63 > > inet6 fe80::481f:1b46:dbf1:bd78%arge1 prefixlen 64 scopeid > > 0x3 nd6 options=3D29 > > media: Ethernet 100baseTX > > status: active > > add net default: gateway 44.128.65.1 > > add net ::ffff:0.0.0.0: gateway ::1 > > add net ::0.0.0.0: gateway ::1 > > add net fe80::: gateway ::1 > > add net ff02::: gateway ::1 > > Mounting NFS file systems:mount_nfs: diesel: hostname nor servname > > provided, or not known . > > Creating and/or trimming log files. > > No core dumps found. > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > > Setting date via ntp. > > Error : hostname nor servname provided, or not known > > 22 Jan 15:01:04 ntpdate[566]: can't find host diesel > > > > 22 Jan 15:01:04 ntpdate[566]: no servers can be used, exiting > > Clearing /tmp (X related). > > Mounting late file systems:mount_nfs: diesel: hostname nor servname > > provided, or not known . > > Mounting /etc/fstab filesystems failed,Jan 22 15:01:12 init: /bin/sh > > on /etc/rc terminated abnormally, going to single user mode Enter > > full pathname of shell or RETURN for /bin/sh: > > # devinfo > > nexus0 > > clock0 > > apb0 > > uart0 > > gpio0 > > gpioc0 > > gpiobus0 > > gpioled0 > > gpioled1 > > gpioled2 > > ehci0 > > usbus0 > > uhub0 > > umass0 > > arge0 > > miibus0 > > floatphy0 > > switch0 > > ar8x16_switch0 > > arge1 > > spi0 > > spibus0 > > mx25l0 > > ar71xx_wdog0 > > # > > > > > > -- > > Stefan Bethke Fon +49 151 14070811 > > > > > > > > > -- > Aleksandr Rybalko > _______________________________________________ > 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" > From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 08:57:36 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 BF67E1065673; Wed, 25 Jan 2012 08:57:36 +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 76AF08FC1B; Wed, 25 Jan 2012 08:57:36 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 35843A0D9; Wed, 25 Jan 2012 08:57:33 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Wed, 25 Jan 2012 09:57:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Aleksandr Rybalko , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework 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, 25 Jan 2012 08:57:36 -0000 Am 25.01.2012 um 08:12 schrieb Adrian Chadd: > So when will you two have something consensus-y to commit? :-) >=20 > What I'm hoping for is: >=20 > * some traction on the MII bus / MDIO bus split and tidyup from stb, = which is nice; > * ray's switch API for speaking to userland with; > * agreeing on whether the correct place to put the driver(s) is where = stb, ray, or a mix of both approaches says so. >=20 > I've been (mostly) trying to stay out of this to see where both of you = have gone. I think we've made some good progress; now it's time to = solidify a design for the first pass of what we want in -HEAD and figure = out how to move forward. My suggestion is to take my bus attachment code (incl. mdio and = miiproxy) and ray's ioctl and userland code. Aleksandr's approach for the driver attachment is to have a generic = switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, etc. = busses the devices are physically attached to, and present a uniform = register file to the chip-specific switch driver. I believe that this = is unnecessarily complicated for two reasons: newbus already provides = that abstraction, and chip-specific drivers usually differ in so many = aspects, including their register files, that code sharing between chips = will be somewhat limited anyway. One aspect that I would enjoy looking into in more detail is how = register accesses on, for example, MDIO, can be provided through the bus = space API. =46rom my cursory reading, it seems that the code currently = is tailored towards register accesses that can be implemented through = CPU native instructions, instead of indirectly through a controller. Aleksandr has defined a quite comprehensive ethernet switch control API = that the framework provides towards in-kernel clients as well as = userland. I think it would be really helpful if we could concentrate on = those API functions that can be controlled through the userland utility, = have immediate use cases (for example, VLAN configuration on the = TL-WR1043ND to separate the WAN from the LAN ports), and we have test = hardware for. In short, don't commit dead code. Having a description of the generic switch model that the API assumes = and driver-specific documentation also wouldn't hurt. (Yes, I'm = volunteering.) Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 18:40: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 20A38106566B; Wed, 25 Jan 2012 18:40:47 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C053E8FC15; Wed, 25 Jan 2012 18:40:46 +0000 (UTC) Received: by ggnq2 with SMTP id q2so2044576ggn.13 for ; Wed, 25 Jan 2012 10:40:46 -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=XZB8zRCxIMAi3wwC7zkFPDskvPs8SI5TqzacVYzKKmo=; b=RsbVRJiY0RCE7SnZStsMcw8x6MEztn/Y8rw0nYp07zdsoNM6Xfvtk5R7MO+Re4E1m+ 4d49GVkXMyuPIZlEuCtvC2vV1QUv0vBTX/+8iLKZ6nma9RY8BX4OuXRKCncgJgZBWHPj RCUXGL1KGCLU/Ipnq92DZZjfB1mca4zkUpYZw= MIME-Version: 1.0 Received: by 10.50.236.73 with SMTP id us9mr7657903igc.16.1327516845910; Wed, 25 Jan 2012 10:40:45 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Wed, 25 Jan 2012 10:40:45 -0800 (PST) In-Reply-To: References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> <0455F6A3-A04A-43C0-9E40-B19ABC4FDDAF@bsdimp.com> Date: Wed, 25 Jan 2012 18:40:45 +0000 X-Google-Sender-Auth: bgyDcHZ9N3VmkEIRQvVn3LFoap4 Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 25 Jan 2012 18:40:47 -0000 El 24 de gener de 2012 10:35, Robert Millan ha escrit: > El 23 de gener de 2012 23:13, Warner Losh ha escrit: >> I like the idea, but hate the name. =C2=A0BLOB has a negative connotatio= n, and this option would seem to imply the project doesn't like blobs, whic= h isn't the case. =C2=A0Can we find a different name for this please? > > I'm open to suggestions. =C2=A0What would you call them? I gave this some thought, looking for a more neutral term that is still accurate. How about MK_SOURCELESS_CODE? From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 18:44: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 C87141065673; Wed, 25 Jan 2012 18:44:59 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F6848FC1A; Wed, 25 Jan 2012 18:44:59 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2246185iae.13 for ; Wed, 25 Jan 2012 10:44:58 -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=rPRb0Qq5fa55bMdiesohRrlL7vSO3zHGbKAPAC5dtgI=; b=CWtzFenpHurHJLJ4bTt4PQWBBhZyx6R20fxkaUgZ/R7HVSocMKjtxUn6UM8UWrsdUM q4cqfQ5/KYuHx5ziNX5l5Z6Tkm0QzM2m4AeKyj2St3S3YfJOPV+S/xVn506g0TmDjGVf zVuFLcJOH6jXSD4kkx7GnRfYmvvelZZhNeBts= MIME-Version: 1.0 Received: by 10.50.170.97 with SMTP id al1mr5643174igc.1.1327517098619; Wed, 25 Jan 2012 10:44:58 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.152.10 with HTTP; Wed, 25 Jan 2012 10:44:58 -0800 (PST) In-Reply-To: References: <20120122201814.GA32081@thorin> <20120123193412.GA353@zim.MIT.EDU> Date: Wed, 25 Jan 2012 18:44:58 +0000 X-Google-Sender-Auth: 3S4sd2_tfPvwsCwQplj7tCyuBSM Message-ID: From: Robert Millan To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , tabthorpe@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option 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, 25 Jan 2012 18:45:00 -0000 El 24 de gener de 2012 9:44, Robert Watson ha escrit: > There's a related concern to do with "license leakage" into the GENERIC > kernel. =C2=A0The policy of the project is that the GENERIC kernel should > essentially be BSD-licensed -- GPL, CDDL, etc, code needs to be compiled = out > by default, although compiled into modules is considered fine. =C2=A0One = reason > that KDTRACE_HOOKS is not in GENERIC is that no one has done a careful > review to ensure that it doesn't lead to CDDL in GENERIC. =C2=A0It would = be nice > if we had tools to not only perform those checks, but also allow us to > induce compile failures as part of tinderboxing if something goes wrong. > =C2=A0It's an interesting question as to how "hard line" you get about th= is: how > do we want to treat uuencoded firmware bits in device drivers that allow > unlimited distribution but not reverse engineering, for example? > > I don't want to get into the politics of this, nor the specific spellings= , > except to say that we (a) can't provide guarantees (and especially not > indemnification) to our users but (b) we do want to help them do their jo= bs > more easily, in which case tools to help them analyse their license > obligations when using FreeBSD would have benefit. > > Count me on in Warner's comment regarding "blob" -- binary-only (or, for > that matter, obfuscated) content is a contentious issue. =C2=A0In as much= as we > can provide accurate while less potentially inflamatory descriptions, I > think that's a useful thing to do. =C2=A0Possibly we should keep vaguely = in mind > the IETF mantra of being liberal about what we accept (i.e., support > components under a variety of licenses) and conservative about what we > generate (create as much code as possible under the BSD license). > > However, there is an immediate practical benefit to resolving the DTrace > hooks situation, and some of the tools used to do that would be more broa= dly > relevant. =C2=A0I'd like it very much if we had KDTRACE_HOOKS compiled in= to > GENERIC -- it's one of the reasons why I find myself still using custom > kernels in many configurations. Hi Robert, Thanks for your explanation. I understand why such license tracking system would be useful. I've to admit, though, that I completely lack the time to implement it. The remaining question would be if for the time being it is acceptable to use MK_* build options for manually disabling sourceless code. There's a similar precedent (MK_BSD_GREP) so I would guess that it is. But if you (or anyone else) has a reason why this would be a bad thing, then please explain it :-) From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 18:54: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 BB94D106564A; Wed, 25 Jan 2012 18:54:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA188FC19; Wed, 25 Jan 2012 18:54:24 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 39DDBC364; Wed, 25 Jan 2012 10:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1327517664; bh=M0E/Ek7u2q3KQNQHKI5eVSUPsjSMF+VlIRKxVqxVq5s=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=iI+LXeaDmjB8fQKMOi6DhZCpKVO0/axm4Q4gVXENGE0y8F96gI+X+lyON2nMyxB50 xL6sASzSjcmrG96UiIGnSzLGimgaUjqopD6Gppmi13Gczih+aBd9EGTk/tVbN36UjP rHAq8+fx29kPy4IgO5oFqAmhbzjdjvlA0ZJBs5xc= Message-ID: <4F204FDD.60807@delphij.net> Date: Wed, 25 Jan 2012 10:54:21 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Robert Millan References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 18:54:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Robert, On 01/23/12 14:17, Robert Millan wrote: > El 23 de gener de 2012 19:57, Xin Li ha > escrit: >> Please note that it's still possible to compile these into kernel >> if they present in the kernel compile configuration (for >> instance, device hptmv), which sounds a little bit non-intuitive >> to me. Maybe we should create three include file (BLOBS, >> BLOBS_HOST, BLOBS_UCODE perhaps) that lists these modules as >> 'nodevice ' in the same time, so they can be >> included from a kernel configuration file at the end? > > Sounds useful, but I'm not sure how would one implement this so > that it is maintainable and doesn't break. > > First when you create a file to disable ucode-blobs, you have to > enumerate the drivers again, creating redundancy (which usually > leads to bitrot). > > Then when you create a file that disables both ucode-blobs and > host-blobs, you either enumerate the drivers over again, adding a > second level of redundancy, or have to use "include" directive. > But you can't just include both ucode-blob and host-blob files > because they both include GENERIC, and then GENERIC would be > included twice, right? > > The idea sounds great (in my case it'd allow me to reduce our delta > a bit further), but in practice I'm not sure this can work. I meant this, basically we have: GENERIC -- default kernel in FreeBSD SOURCELESS_EXCLUDES -- a meta-'overlay' that contains 'include SOURCELESS_HOST_EXCLUDES' and 'include SOURCELESS_UCODE_EXCLUDES' SOURCELESS_HOST_EXCLUDES -- a 'overlay' that contains a few 'nodevice 's SOURCELESS_UCODE_EXCLUDES -- ditto This way, e.g. GENERIC-DEBIAN would be simply: include GENERIC include SOURCELESS_EXCLUDES This way would minimize the maintenance of the GENERIC-DEBIAN I think while not compromising your policy of not including these stuff in binary? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8gT90ACgkQOfuToMruuMCFkwCfZbRP6g0v7eq14t02bWX2d+sf oWYAnRMwr6XDcZmyiYWMJmEA5gtxQSsh =ONW1 -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 18:55:38 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 6FFA3106566C; Wed, 25 Jan 2012 18:55:38 +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 249338FC0C; Wed, 25 Jan 2012 18:55:38 +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 q0PIiD7j010052 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 11:44:14 -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: Wed, 25 Jan 2012 11:44:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> <0455F6A3-A04A-43C0-9E40-B19ABC4FDDAF@bsdimp.com> To: Robert Millan 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]); Wed, 25 Jan 2012 11:44:15 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , d@delphij.net, freebsd-arch@FreeBSD.org Subject: Re: RFC: MK_BLOBS build option 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, 25 Jan 2012 18:55:38 -0000 On Jan 25, 2012, at 11:40 AM, Robert Millan wrote: > El 24 de gener de 2012 10:35, Robert Millan ha = escrit: >> El 23 de gener de 2012 23:13, Warner Losh ha escrit: >>> I like the idea, but hate the name. BLOB has a negative = connotation, and this option would seem to imply the project doesn't = like blobs, which isn't the case. Can we find a different name for this = please? >>=20 >> I'm open to suggestions. What would you call them? >=20 > I gave this some thought, looking for a more neutral term that is > still accurate. How about MK_SOURCELESS_CODE? I like that a lot better... Sorry I was slow in making a suggestion... Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 22:17:55 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 15AA0106564A for ; Wed, 25 Jan 2012 22:17:55 +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 8E39B8FC08 for ; Wed, 25 Jan 2012 22:17:54 +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 q0PMHrmj018190; Wed, 25 Jan 2012 23:17:53 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0PMHr85018189; Wed, 25 Jan 2012 23:17:53 +0100 (CET) (envelope-from marius) Date: Wed, 25 Jan 2012 23:17:53 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120125221753.GA17821@alchemy.franken.de> References: <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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-arch 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, 25 Jan 2012 22:17:55 -0000 On Sat, Jan 21, 2012 at 12:08:34AM +0100, Stefan Bethke wrote: > Am 11.01.2012 um 20:37 schrieb Marius Strobl: > > > Okay, I suggest to postpone this discussion until then. For the > > scenario when mdiobus is the parent of miibus I see no technical > > need to change miibus to support what you want to do, just implement > > the miibus_if in mdiobus and redirect it to the device_t of the > > MAC there. Moreover, that way the hack to sidestep newbus is contained > > in the layer that actually needs it and not scattered over multiple > > frameworks. > > I've posted to -net a patch that implements a workaround along those lines. It solves two issues: talking to two upstream devices, and providing a proper attachment for miibus. > > There's a number of things that made this harder than I would have liked: > - miibus has a funny way of attaching to it's parent. Making the parent a bus that automatically attaches matching children does not lead to good results. That's the idea behind auto-probing, which all FreeBSD bus drivers implement as far as the physical bus supports it. Otherwise you have to resort to using hints one way or the other, which miibus(4) also supports nowadays. The problem with miibus(4) in the embedded world probably is that as a last resort ukphy(4) grabs anything that sufficiently looks like a PHY. If there's a way to properly identify devices that actually shouldn't be handled by ukphy(4) it probably would make sense to add a pseudo-driver roughly similar to fixup_pci(4) that grabs them instead and does whatever needs to be done or maybe even just nothing instead of treating them as PHYs. The bottom line still is whether with all the quirks needed to make a framework built around IEEE 802.3-compliant stuff support also the odds of the embedded world the IMO limited code-reuse justifies doing it that way. > - miibus uses it's parents ivars. To clarify: device_get_ivars get's a devices ivars, but those are owned by the parent; the bus uses device_[gs]et_ivars(9) to manipulate it's own private per-child data storage. The device must not manipulate them. I believe those variables can be moved to mii_data. Yes, that's unpleasant. However, according to the man page and the newbus code a device not setting it's own instance variables is just a should, not a must. The problem with mii_data is that you can't really rely on the softc being stable until the attach method is called. This happens to work between probe and attach if the former returns 0 but given that miibus(4) manages the memory for its instance variables itself going that route is the lesser evil thing here. I'm trying to think of a way to properly newbus-ify the whole stuff that mii_attach() does but currently can't come up with a really cleaner solution ... > - miibus makes assumptions about it's children, namely that they have specific softc's and that they provide callbacks outside of the newbus method mechanism > - miibus assumes that all devices attached to that mdio have certain registers that have certain bits set or cleared > - miibus calls it's parent methods and two explicit callbacks, plus various calls into the interface management code. Yes, it assumes IEEE 802.3-compliant devices and usecases. If you throw out all the things like auto-probing via ID registers, out- detection of media via the BMSR and so and which makes miibus(4) the generic PHY handling framework that it is or work around them, I hardly can think of much that would be left that justifies using miibus(4) in the first place though. Can't we just build another framework which handles all the other stuff that also just happens to have an MDIO interface and attach it instead? > > The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up? > > Leaving aside the miibus issue, the newbus problem is that the ethernet driver (which is attached to some bus) needs to associate with some other driver that might not be in it's vincinity, in particular neither it's parent nor one of it's children. Compounding the problem is that there is no way to express an attachment ordering constraint so that the ethernet driver is only attached once the required mdio driver has attached. > Yes, architecture of newbus is built around the assumption that there's a single device tree and all you ever need are child- parent-relationships. AFAICT this assumption dates back to at least the device configuration in 4.4BSD and apart from the embedded world it held true just fine so far ... Marius From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 22:36:04 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 DDFC9106566C for ; Wed, 25 Jan 2012 22:36:04 +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 8D4558FC1A for ; Wed, 25 Jan 2012 22:36:04 +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 q0PMSiC4015460 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 15:28:45 -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: <20120125221753.GA17821@alchemy.franken.de> Date: Wed, 25 Jan 2012 15:28:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> To: Marius Strobl 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]); Wed, 25 Jan 2012 15:28:46 -0700 (MST) Cc: Stefan Bethke , FreeBSD-arch 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, 25 Jan 2012 22:36:04 -0000 On Jan 25, 2012, at 3:17 PM, Marius Strobl wrote: > Yes, architecture of newbus is built around the assumption that > there's a single device tree and all you ever need are child- > parent-relationships. AFAICT this assumption dates back to at > least the device configuration in 4.4BSD and apart from the > embedded world it held true just fine so far ... Even in the embedded world it is true. The problem is that in the = embedded world multiple devices use the service of another device which = is why we're seeing teething pain with the MDIO bus (which shares all = the management lines between the PHY rather than having each MAC have = its own connection to the PHY). So while the basic resources are still = hierarchical, the interconnects have become more complicated. The issue = we're facing here is that we'd assumed that the MAC PHY connection could = provide management services since you knew you had to have data services = or else you'd have no packet flow... We're seeing the same struggles with gpio and interrupt pins... Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jan 25 23:22:06 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 C2D0E106566C for ; Wed, 25 Jan 2012 23:22:06 +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 554C48FC0C for ; Wed, 25 Jan 2012 23:22:05 +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 q0PNM16Q018453; Thu, 26 Jan 2012 00:22:01 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0PNM13M018452; Thu, 26 Jan 2012 00:22:01 +0100 (CET) (envelope-from marius) Date: Thu, 26 Jan 2012 00:22:01 +0100 From: Marius Strobl To: Warner Losh Message-ID: <20120125232201.GP44286@alchemy.franken.de> References: <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Stefan Bethke , FreeBSD-arch 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, 25 Jan 2012 23:22:06 -0000 On Wed, Jan 25, 2012 at 03:28:38PM -0700, Warner Losh wrote: > > On Jan 25, 2012, at 3:17 PM, Marius Strobl wrote: > > Yes, architecture of newbus is built around the assumption that > > there's a single device tree and all you ever need are child- > > parent-relationships. AFAICT this assumption dates back to at > > least the device configuration in 4.4BSD and apart from the > > embedded world it held true just fine so far ... > > Even in the embedded world it is true. The problem is that in the embedded world multiple devices use the service of another device which is why we're seeing teething pain with the MDIO bus (which shares all the management lines between the PHY rather than having each MAC have its own connection to the PHY). So while the basic resources are still hierarchical, the interconnects have become more complicated. The issue we're facing here is that we'd assumed that the MAC PHY connection could provide management services since you knew you had to have data services or else you'd have no packet flow... > > We're seeing the same struggles with gpio and interrupt pins... > Hrm, is there a proper solution to this? Could resource-multiplexers ala puc(4) that are attached before all their consumers via multi- pass be one? Marius From owner-freebsd-arch@FreeBSD.ORG Thu Jan 26 16:25: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 19D14106566C for ; Thu, 26 Jan 2012 16:25:11 +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 C18708FC0A for ; Thu, 26 Jan 2012 16:25:10 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 9DA12F00C; Thu, 26 Jan 2012 16:25:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120125221753.GA17821@alchemy.franken.de> Date: Thu, 26 Jan 2012 17:25:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6A719D-A616-4D1E-9DD2-BAA399FFD3AC@lassitu.de> References: <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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: FreeBSD-arch 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, 26 Jan 2012 16:25:11 -0000 Am 25.01.2012 um 23:17 schrieb Marius Strobl: > On Sat, Jan 21, 2012 at 12:08:34AM +0100, Stefan Bethke wrote: >> - miibus has a funny way of attaching to it's parent. Making the = parent a bus that automatically attaches matching children does not lead = to good results. >=20 > That's the idea behind auto-probing, which all FreeBSD bus drivers > implement as far as the physical bus supports it. Sorry, I should have been more specific. I had problems when the device = that miibus attaches to implements autoprobing and auto-attaches miibus = directly, instead of through mii_attach(). Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 26 16:27:07 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 0C26B106566C for ; Thu, 26 Jan 2012 16:27:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 87A8F8FC13 for ; Thu, 26 Jan 2012 16:27:06 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 234572763; Thu, 26 Jan 2012 17:27:04 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 26 Jan 2012 17:25:02 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <9E6A719D-A616-4D1E-9DD2-BAA399FFD3AC@lassitu.de> In-Reply-To: <9E6A719D-A616-4D1E-9DD2-BAA399FFD3AC@lassitu.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201261725.02980.hselasky@c2i.net> Cc: Stefan Bethke , Marius Strobl 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, 26 Jan 2012 16:27:07 -0000 On Thursday 26 January 2012 17:25:09 Stefan Bethke wrote: > Am 25.01.2012 um 23:17 schrieb Marius Strobl: > > On Sat, Jan 21, 2012 at 12:08:34AM +0100, Stefan Bethke wrote: > >> - miibus has a funny way of attaching to it's parent. Making the parent > >> a bus that automatically attaches matching children does not lead to > >> good results. > > > > That's the idea behind auto-probing, which all FreeBSD bus drivers > > implement as far as the physical bus supports it. > > Sorry, I should have been more specific. I had problems when the device > that miibus attaches to implements autoprobing and auto-attaches miibus > directly, instead of through mii_attach(). > Hi, While staying at the topic. All unneccesary panic() statements should be removed from mii() drivers. Sometimes, when you unplug a USB network device, a mii read can fail and that should not crash the system! --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Jan 26 16:30: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 9F21C106566C for ; Thu, 26 Jan 2012 16:30:52 +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 5833F8FC1D for ; Thu, 26 Jan 2012 16:30:52 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 8FB0EF0AD; Thu, 26 Jan 2012 16:30:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120125221753.GA17821@alchemy.franken.de> Date: Thu, 26 Jan 2012 17:30:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1084) Cc: FreeBSD-arch 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, 26 Jan 2012 16:30:52 -0000 Am 25.01.2012 um 23:17 schrieb Marius Strobl: > Yes, it assumes IEEE 802.3-compliant devices and usecases. If you > throw out all the things like auto-probing via ID registers, out- > detection of media via the BMSR and so and which makes miibus(4) > the generic PHY handling framework that it is or work around them, > I hardly can think of much that would be left that justifies using > miibus(4) in the first place though. Can't we just build another > framework which handles all the other stuff that also just happens > to have an MDIO interface and attach it instead? The problem with that is that for f.e. the RTL8306, the switch and the = PHYs coexist on the same MDIO bus, so some form of interoperation is = required. Don't get me wrong, my post was not meant to suggest that the current = miibus code must be scratched or even significantly changed, I just = wanted to document the limitations I discovered. What I would like to do is make my new mdio bus driver into a = full-fledged bus, and then maybe see if miibus can be extended to work = with it more naturally than through the miiproxy adapter driver. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 27 06:04:00 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 57143106566B; Fri, 27 Jan 2012 06:04:00 +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 D5AE08FC1B; Fri, 27 Jan 2012 06:03:59 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so1618977vbb.13 for ; Thu, 26 Jan 2012 22:03:59 -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=zsOG+Td6olprJiykJJ3eGZ9/lHoDEO0L9yDV6npBZzk=; b=bGapyzKhVbCBtWDUH5sV+NFJX5z9a4FDdWvaNy6akeR1JxtPCnKf+287DLQZU4e+HM p0j/FFreRrN04OFcuRagRwHVWr5myjC2MTAGYnjPg03o0dXC2n82FF/vTRUqNjm9ytrc RWmvFpqIM86MGz32uURo6BaLqYqjnK4BjCjYo= MIME-Version: 1.0 Received: by 10.52.65.100 with SMTP id w4mr2342326vds.3.1327644238987; Thu, 26 Jan 2012 22:03:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.73.228 with HTTP; Thu, 26 Jan 2012 22:03:58 -0800 (PST) In-Reply-To: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> Date: Thu, 26 Jan 2012 22:03:58 -0800 X-Google-Sender-Auth: jNdELBKiWmqVD4lBcH_wkce2LkQ Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Aleksandr Rybalko , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework 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, 27 Jan 2012 06:04:00 -0000 Ok, I do like the idea of: * mdiobus/miibus proxy tidyup; * then the switch API; * then the switch devices themselves. Can we get some consensus/agreement from Marius (and others) about the first step? Adrian From owner-freebsd-arch@FreeBSD.ORG Fri Jan 27 14:16:01 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 03C6C1065672 for ; Fri, 27 Jan 2012 14:16:01 +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 8C9508FC08 for ; Fri, 27 Jan 2012 14:16:00 +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 q0REFuYg032439; Fri, 27 Jan 2012 15:15: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 q0REFuH4032438; Fri, 27 Jan 2012 15:15:56 +0100 (CET) (envelope-from marius) Date: Fri, 27 Jan 2012 15:15:56 +0100 From: Marius Strobl To: Hans Petter Selasky Message-ID: <20120127141556.GU44286@alchemy.franken.de> References: <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <20120125221753.GA17821@alchemy.franken.de> <9E6A719D-A616-4D1E-9DD2-BAA399FFD3AC@lassitu.de> <201201261725.02980.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201261725.02980.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: Stefan Bethke , 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, 27 Jan 2012 14:16:01 -0000 On Thu, Jan 26, 2012 at 05:25:02PM +0100, Hans Petter Selasky wrote: > On Thursday 26 January 2012 17:25:09 Stefan Bethke wrote: > > Am 25.01.2012 um 23:17 schrieb Marius Strobl: > > > On Sat, Jan 21, 2012 at 12:08:34AM +0100, Stefan Bethke wrote: > > >> - miibus has a funny way of attaching to it's parent. Making the parent > > >> a bus that automatically attaches matching children does not lead to > > >> good results. > > > > > > That's the idea behind auto-probing, which all FreeBSD bus drivers > > > implement as far as the physical bus supports it. > > > > Sorry, I should have been more specific. I had problems when the device > > that miibus attaches to implements autoprobing and auto-attaches miibus > > directly, instead of through mii_attach(). > > > > Hi, > > While staying at the topic. All unneccesary panic() statements should be > removed from mii() drivers. Sometimes, when you unplug a USB network device, a > mii read can fail and that should not crash the system! > Uhm, there's a single KASSERT() in mii_phy_setmedia() that you also can only hit when actually trying to set invalid media but otherwise there's no call to panic() in sys/dev/mii/*. If you are seeing panics due to MII access failing these must be triggered by upper layers. Marius From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 00:04:51 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 313351065672 for ; Sat, 28 Jan 2012 00:04:51 +0000 (UTC) (envelope-from christopher@struska.com) Received: from mx02lb.world4you.com (mx02lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id E8A548FC1B for ; Sat, 28 Jan 2012 00:04:50 +0000 (UTC) Received: from [189.106.166.30] (helo=struska.com) by mx02lb.world4you.com with esmtpa (Exim 4.77) (envelope-from ) id 1Rqvmh-00062x-F5 for freebsd-arch@freebsd.org; Sat, 28 Jan 2012 01:04:48 +0100 From: "Ivanovs Andrejs" To: freebsd-arch@freebsd.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Date: Fri, 27 Jan 2012 16:04:44 -0800 X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 189.106.166.30 X-SA-Exim-Mail-From: christopher@struska.com X-SA-Exim-Scanned: No (on mx02lb.world4you.com); SAEximRunCond expanded to false Message-Id: <20120128000451.313351065672@hub.freebsd.org> Subject: RE:RE: Bezmaksas filmas :):) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ivanovs Andrejs List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:04:51 -0000 Vienigi trakakie porno materiali !? http://www.tracyevans.co.uk/nolaizi-to-nosts Ivanovs Andrejs From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 15:01:32 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 C6E1E1065674; Sat, 28 Jan 2012 15:01:32 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 18D918FC0A; Sat, 28 Jan 2012 15:01:31 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3239169wib.13 for ; Sat, 28 Jan 2012 07:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SRffam1MqQ1pwTjlmrn9yyuIkH7PGMQDWwfMZH0sWFQ=; b=ii6D+449vy422TRP9FvFAbBHhQDaM+OdLklxOJf1AFr+EqPLKb1G7tXgCljRwMjl3Q h/JgrnxLou9tX2by0VWuPKpmH1Y7nDMkiAr7YEq1J/yJGKCaYPtAXVv8iQG7t4MeF/D5 edJW1/tpWkpT5mvTCgkPAYj8/Xyo9gbymfSxM= Received: by 10.180.95.199 with SMTP id dm7mr17581774wib.9.1327762891191; Sat, 28 Jan 2012 07:01:31 -0800 (PST) Received: from thorin (81.Red-95-122-64.staticIP.rima-tde.net. [95.122.64.81]) by mx.google.com with ESMTPS id dw7sm3862353wib.4.2012.01.28.07.01.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Jan 2012 07:01:30 -0800 (PST) Sender: Robert Millan Received: from rmh by thorin with local (Exim 4.72) (envelope-from ) id 1Rr9mQ-0003mX-S1; Sat, 28 Jan 2012 16:01:26 +0100 Date: Sat, 28 Jan 2012 16:01:26 +0100 From: Robert Millan To: d@delphij.net Message-ID: <20120128150126.GA14522@thorin> References: <20120122201814.GA32081@thorin> <4F1DBB94.900@delphij.net> <4F204FDD.60807@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <4F204FDD.60807@delphij.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 15:01:32 -0000 --KFztAG8eRSV9hGtP Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 10:54:21AM -0800, Xin Li wrote: >=20 > I meant this, basically we have: >=20 > GENERIC -- default kernel in FreeBSD > SOURCELESS_EXCLUDES -- a meta-'overlay' that contains 'include > SOURCELESS_HOST_EXCLUDES' and 'include SOURCELESS_UCODE_EXCLUDES' > SOURCELESS_HOST_EXCLUDES -- a 'overlay' that contains a few 'nodevice > 's > SOURCELESS_UCODE_EXCLUDES -- ditto >=20 > This way, e.g. GENERIC-DEBIAN would be simply: >=20 > include GENERIC > include SOURCELESS_EXCLUDES >=20 > This way would minimize the maintenance of the GENERIC-DEBIAN I think > while not compromising your policy of not including these stuff in binary? Sounds fine to me. Please let me know what you think about this. I took y= our idea but used "WITHOUT" rather than "EXCLUDES" for consistency with the MK_SOURCELESS_* options (which would be disabled using e.g. -DWITHOUT_SOURCELESS_UCODE in command-line). I've also rewritten descriptions of the MK_* options so they use the word "sourceless" instead of referring to "binary-only blobs". --=20 Robert Millan --UlVJffcvxoiEqYs2 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mk_sourceless.diff" Content-Transfer-Encoding: quoted-printable Index: sys/i386/conf/WITHOUT_SOURCELESS =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/i386/conf/WITHOUT_SOURCELESS (revision 0) +++ sys/i386/conf/WITHOUT_SOURCELESS (revision 0) @@ -0,0 +1,7 @@ +# +# WITHOUT_SOURCELESS -- Disable drivers that include sourceless code. +# +# $FreeBSD$ + +include WITHOUT_SOURCELESS_HOST +include WITHOUT_SOURCELESS_UCODE Index: sys/i386/conf/WITHOUT_SOURCELESS_HOST =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/i386/conf/WITHOUT_SOURCELESS_HOST (revision 0) +++ sys/i386/conf/WITHOUT_SOURCELESS_HOST (revision 0) @@ -0,0 +1,10 @@ +# +# WITHOUT_SOURCELESS_UCODE -- Disable drivers that include sourceless +# native code for host CPU. +# +# $FreeBSD$ + +nodevice hpt27xx +nodevice hptmv +nodevice hptrr +nodevice nve Index: sys/i386/conf/WITHOUT_SOURCELESS_UCODE =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/i386/conf/WITHOUT_SOURCELESS_UCODE (revision 0) +++ sys/i386/conf/WITHOUT_SOURCELESS_UCODE (revision 0) @@ -0,0 +1,40 @@ +# +# WITHOUT_SOURCELESS_UCODE -- Disable drivers that include sourceless +# microcode. +# +# $FreeBSD$ + +nodevice bce +nodevice fatm +nodevice fxp +nodevice ispfw +nodevice mwlfw +nodevice ralfw +nodevice runfw +nodevice sf +nodevice sn +nodevice ti +nodevice txp +nodevice ce +nodevice cp +nodevice ctau +nodevice ipwfw +nodevice iwifw +nodevice iwnfw +nodevice wpifw + +# drm +nodevice mga +nodevice r128 +nodevice radeon + +# sound +nodevice csa +nodevice ds1 +nodevice maestro3 + +# usb +nodevice rum +nodevice uath +nodevice zyd +nodevice kue Index: sys/amd64/conf/WITHOUT_SOURCELESS =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/amd64/conf/WITHOUT_SOURCELESS (revision 0) +++ sys/amd64/conf/WITHOUT_SOURCELESS (revision 0) @@ -0,0 +1,7 @@ +# +# WITHOUT_SOURCELESS -- Disable drivers that include sourceless code. +# +# $FreeBSD$ + +include WITHOUT_SOURCELESS_HOST +include WITHOUT_SOURCELESS_UCODE Index: sys/amd64/conf/WITHOUT_SOURCELESS_HOST =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/amd64/conf/WITHOUT_SOURCELESS_HOST (revision 0) +++ sys/amd64/conf/WITHOUT_SOURCELESS_HOST (revision 0) @@ -0,0 +1,10 @@ +# +# WITHOUT_SOURCELESS_UCODE -- Disable drivers that include sourceless +# native code for host CPU. +# +# $FreeBSD$ + +nodevice hpt27xx +nodevice hptmv +nodevice hptrr +nodevice nve Index: sys/amd64/conf/WITHOUT_SOURCELESS_UCODE =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/amd64/conf/WITHOUT_SOURCELESS_UCODE (revision 0) +++ sys/amd64/conf/WITHOUT_SOURCELESS_UCODE (revision 0) @@ -0,0 +1,40 @@ +# +# WITHOUT_SOURCELESS_UCODE -- Disable drivers that include sourceless +# microcode. +# +# $FreeBSD$ + +nodevice bce +nodevice fatm +nodevice fxp +nodevice ispfw +nodevice mwlfw +nodevice ralfw +nodevice runfw +nodevice sf +nodevice sn +nodevice ti +nodevice txp +nodevice ce +nodevice cp +nodevice ctau +nodevice ipwfw +nodevice iwifw +nodevice iwnfw +nodevice wpifw + +# drm +nodevice mga +nodevice r128 +nodevice radeon + +# sound +nodevice csa +nodevice ds1 +nodevice maestro3 + +# usb +nodevice rum +nodevice uath +nodevice zyd +nodevice kue Index: sys/modules/sound/driver/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 --- sys/modules/sound/driver/Makefile (revision 230389) +++ sys/modules/sound/driver/Makefile (working copy) @@ -1,10 +1,21 @@ # $FreeBSD$ =20 -SUBDIR=3D ad1816 als4000 atiixp cs4281 csa ds1 emu10k1 emu10kx -SUBDIR+=3D envy24 envy24ht es137x ess fm801 hda ich maestro maestro3 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_SOURCELESS_UCODE option (see below). + +SUBDIR=3D ad1816 als4000 atiixp cs4281 ${_csa} ${_ds1} emu10k1 emu10kx +SUBDIR+=3D envy24 envy24ht es137x ess fm801 hda ich maestro ${_maestro3} SUBDIR+=3D neomagic sb16 sb8 sbc solo spicds t4dwave via8233 SUBDIR+=3D via82c686 vibes driver uaudio =20 +.if ${MK_SOURCELESS_UCODE} !=3D "no" +_csa=3D csa +_ds1=3D ds1 +_maestro3=3D maestro3 +.endif + .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D "amd64" SUBDIR+=3D cmi mss .endif Index: sys/modules/drm/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 --- sys/modules/drm/Makefile (revision 230389) +++ sys/modules/drm/Makefile (working copy) @@ -1,15 +1,26 @@ # $FreeBSD$ =20 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_SOURCELESS_UCODE option (see below). + SUBDIR =3D \ drm \ i915 \ mach64 \ - mga \ - r128 \ - radeon \ + ${_mga} \ + ${_r128} \ + ${_radeon} \ savage \ sis \ tdfx \ via =20 +.if ${MK_SOURCELESS_UCODE} !=3D "no" +_mga=3D mga +_r128=3D r128 +_radeon=3D radeon +.endif + .include Index: sys/modules/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 --- sys/modules/Makefile (revision 230389) +++ sys/modules/Makefile (working copy) @@ -2,6 +2,9 @@ =20 .include =20 +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_SOURCELESS_UCODE option (see below). + SUBDIR=3D ${_3dfx} \ ${_3dfx_linux} \ ${_aac} \ @@ -36,7 +39,7 @@ ath \ ath_pci \ ${_auxio} \ - bce \ + ${_bce} \ bfe \ bge \ ${_bxe} \ @@ -95,13 +98,13 @@ ${_ex} \ ${_exca} \ ${_ext2fs} \ - fatm \ + ${_fatm} \ fdc \ fdescfs \ ${_fe} \ firewire \ firmware \ - fxp \ + ${_fxp} \ gem \ geom \ ${_glxiic} \ @@ -147,7 +150,7 @@ ${_ipwfw} \ iscsi \ isp \ - ispfw \ + ${_ispfw} \ ${_iwi} \ ${_iwifw} \ ${_iwn} \ @@ -208,7 +211,7 @@ ${_mthca} \ mvs \ mwl \ - mwlfw \ + ${_mwlfw} \ mxge \ my \ ${_ncp} \ @@ -258,14 +261,14 @@ puc \ ${_qlxgb} \ ral \ - ralfw \ + ${_ralfw} \ ${_random} \ rc4 \ ${_rdma} \ re \ reiserfs \ rl \ - runfw \ + ${_runfw} \ ${_s3} \ ${_safe} \ ${_sbni} \ @@ -275,7 +278,7 @@ sdhci \ sem \ send \ - sf \ + ${_sf} \ ${_sfxge} \ sge \ siba_bwn \ @@ -284,7 +287,7 @@ sis \ sk \ ${_smbfs} \ - sn \ + ${_sn} \ ${_snc} \ snp \ ${_sound} \ @@ -299,7 +302,7 @@ ${_sym} \ ${_syscons} \ sysvipc \ - ti \ + ${_ti} \ tl \ tmpfs \ ${_tpm} \ @@ -308,7 +311,7 @@ twe \ tws \ tx \ - txp \ + ${_txp} \ uart \ ubsec \ udf \ @@ -357,8 +360,10 @@ # No barrier instruction support (specific to this driver) _sym=3D sym # intr_disable() is a macro, causes problems +.if ${MK_SOURCELESS_UCODE} !=3D "no" _cxgb=3D cxgb .endif +.endif =20 .if ${MK_CRYPT} !=3D "no" || defined(ALL_MODULES) .if exists(${.CURDIR}/../opencrypto) @@ -400,6 +405,20 @@ .endif .endif =20 +.if ${MK_SOURCELESS_UCODE} !=3D "no" +_bce=3D bce +_fatm=3D fatm +_fxp=3D fxp +_ispfw=3D ispfw +_mwlfw=3D mwlfw +_ralfw=3D ralfw +_runfw=3D runfw +_sf=3D sf +_sn=3D sn +_ti=3D ti +_txp=3D txp +.endif + .if ${MACHINE_CPUARCH} =3D=3D "i386" # XXX some of these can move to the general case when de-i386'ed # XXX some of these can move now, but are untested on other architectures. @@ -415,9 +434,13 @@ _bxe=3D bxe _cardbus=3D cardbus _cbb=3D cbb +.if ${MK_SOURCELESS_UCODE} !=3D "no" _ce=3D ce +.endif _coff=3D coff +.if ${MK_SOURCELESS_UCODE} !=3D "no" _cp=3D cp +.endif _cpuctl=3D cpuctl _cpufreq=3D cpufreq _cs=3D cs @@ -506,35 +529,51 @@ _cm=3D cm _cmx=3D cmx _coretemp=3D coretemp +.if ${MK_SOURCELESS_UCODE} !=3D "no" _ctau=3D ctau +.endif _dpt=3D dpt _ex=3D ex +.if ${MK_SOURCELESS_HOST} !=3D "no" _hpt27xx=3D hpt27xx +.endif _hptiop=3D hptiop +.if ${MK_SOURCELESS_HOST} !=3D "no" _hptmv=3D hptmv _hptrr=3D hptrr +.endif _ichwd=3D ichwd _ida=3D ida _iir=3D iir _ipmi=3D ipmi _ips=3D ips _ipw=3D ipw +.if ${MK_SOURCELESS_UCODE} !=3D "no" _ipwfw=3D ipwfw +.endif _iwi=3D iwi +.if ${MK_SOURCELESS_UCODE} !=3D "no" _iwifw=3D iwifw +.endif _iwn=3D iwn +.if ${MK_SOURCELESS_UCODE} !=3D "no" _iwnfw=3D iwnfw +.endif _ixgb=3D ixgb _ixgbe=3D ixgbe _mly=3D mly _nfe=3D nfe +.if ${MK_SOURCELESS_HOST} !=3D "no" _nve=3D nve +.endif _nvram=3D nvram _nxge=3D nxge _tpm=3D tpm _viawd=3D viawd _wpi=3D wpi +.if ${MK_SOURCELESS_UCODE} !=3D "no" _wpifw=3D wpifw +.endif .if ${MK_CRYPT} !=3D "no" || defined(ALL_MODULES) _padlock=3D padlock .endif @@ -586,10 +625,14 @@ _em=3D em _exca=3D exca _ext2fs=3D ext2fs +.if ${MK_SOURCELESS_HOST} !=3D "no" _hpt27xx=3D hpt27xx +.endif _hptiop=3D hptiop +.if ${MK_SOURCELESS_HOST} !=3D "no" _hptmv=3D hptmv _hptrr=3D hptrr +.endif _i2c=3D i2c _ichwd=3D ichwd _ida=3D ida @@ -600,11 +643,17 @@ _ipmi=3D ipmi _ips=3D ips _ipw=3D ipw +.if ${MK_SOURCELESS_UCODE} !=3D "no" _ipwfw=3D ipwfw +.endif _iwi=3D iwi +.if ${MK_SOURCELESS_UCODE} !=3D "no" _iwifw=3D iwifw +.endif _iwn=3D iwn +.if ${MK_SOURCELESS_UCODE} !=3D "no" _iwnfw=3D iwnfw +.endif _ixgb=3D ixgb _ixgbe=3D ixgbe _lindev=3D lindev @@ -620,7 +669,9 @@ .endif _ndis=3D ndis _nfe=3D nfe +.if ${MK_SOURCELESS_HOST} !=3D "no" _nve=3D nve +.endif _nvram=3D nvram _nxge=3D nxge .if ${MK_CDDL} !=3D "no" || defined(ALL_MODULES) @@ -650,7 +701,9 @@ _x86bios=3D x86bios _wi=3D wi _wpi=3D wpi +.if ${MK_SOURCELESS_UCODE} !=3D "no" _wpifw=3D wpifw +.endif .if ${MK_ZFS} !=3D "no" || defined(ALL_MODULES) _zfs=3D zfs .endif Index: sys/modules/usb/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 --- sys/modules/usb/Makefile (revision 230389) +++ sys/modules/usb/Makefile (working copy) @@ -25,16 +25,28 @@ # SUCH DAMAGE. # =20 +.include + +# Modules that include binary-only blobs of microcode should be selectable= by +# MK_SOURCELESS_UCODE option (see below). + SUBDIR =3D usb SUBDIR +=3D ehci musb ohci uhci xhci uss820dci ${_at91dci} ${_atmegadci} $= {_avr32dci} -SUBDIR +=3D rum run uath upgt usie ural zyd ${_urtw} +SUBDIR +=3D ${_rum} run ${_uath} upgt usie ural ${_zyd} ${_urtw} SUBDIR +=3D atp uhid ukbd ums udbp ufm uep SUBDIR +=3D ucom u3g uark ubsa ubser uchcom ucycom ufoma uftdi ugensa uipa= q ulpt \ umct umcs umodem umoscom uplcom uslcom uvisor uvscom -SUBDIR +=3D uether aue axe cdce cue kue mos rue udav uhso ipheth +SUBDIR +=3D uether aue axe cdce cue ${_kue} mos rue udav uhso ipheth SUBDIR +=3D usfs umass urio SUBDIR +=3D quirk template =20 +.if ${MK_SOURCELESS_UCODE} !=3D "no" +_rum=3D rum +_uath=3D uath +_zyd=3D zyd +_kue=3D kue +.endif + .if ${MACHINE_CPUARCH} =3D=3D "amd64" _urtw=3D urtw .endif Index: share/mk/bsd.own.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 --- share/mk/bsd.own.mk (revision 230389) +++ share/mk/bsd.own.mk (working copy) @@ -320,6 +320,9 @@ BOOT \ BSD_CPIO \ BSNMP \ + SOURCELESS \ + SOURCELESS_HOST \ + SOURCELESS_UCODE \ BZIP2 \ CALENDAR \ CAPSICUM \ @@ -511,6 +514,11 @@ MK_BIND_ETC:=3D no .endif =20 +.if ${MK_SOURCELESS} =3D=3D "no" +MK_SOURCELESS_HOST:=3D no +MK_SOURCELESS_UCODE:=3D no +.endif + .if ${MK_CDDL} =3D=3D "no" MK_ZFS:=3D no MK_CTF:=3D no Index: tools/build/options/WITHOUT_SOURCELESS =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 --- tools/build/options/WITHOUT_SOURCELESS (revision 0) +++ tools/build/options/WITHOUT_SOURCELESS (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include sourceless code (either micro= code or native code for host CPU). Index: tools/build/options/WITHOUT_SOURCELESS_HOST =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 --- tools/build/options/WITHOUT_SOURCELESS_HOST (revision 0) +++ tools/build/options/WITHOUT_SOURCELESS_HOST (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include sourceless native code for ho= st CPU. Index: tools/build/options/WITHOUT_SOURCELESS_UCODE =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 --- tools/build/options/WITHOUT_SOURCELESS_UCODE (revision 0) +++ tools/build/options/WITHOUT_SOURCELESS_UCODE (revision 0) @@ -0,0 +1,2 @@ +.\" $FreeBSD$ +Set to not build kernel modules that include sourceless microcode. --UlVJffcvxoiEqYs2-- --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/kFreeBSD) iQIcBAEBCAAGBQJPJA3EAAoJELd1onhloKnO4J8P/At3Ybi1aG4ijodSnarslhVd uxTSLaLBQ22hcGrBDFtwfxlz8jAvm4/httIzDQIP53fFRh2UAyA43eCx3uzv8C7A IcfHdr9RgPcaM0WWDoUDFV6Ym+1InnKeH9Ko5fZsKp7KBbs0BwjkklJ7a6WWs1Ut /OKQ2qDGSAlyoCUuXI6lqe4yFAIueciGsfJenv55+oF68leMnjXP9DiZC72J8Rw1 AWMIz4Vn1brPbh2s3PDokrBc4zlWpRP6Qa0W0mJ4D2veiO5b4pQgc6adAC0/qAsF /mhLQTJbMjIq52LTUrXrnf6a85Av8VIIZXFUG5gSHkgkYgo3O8kf/97ebDwfgufu 6ao6/zXupN84M/9doh+WXvhUPdsoHE3Jnu6EkGVwlIDRqGnXmHAzHqZxntkkpl/o S1uLnJgVGiR8sb5Wp7XRsEzjgmcN39UiV1cZUXGn2XlJR5d/5YtfHd8ynuDawq9t sZFA5/2F+944Xj81MTi8IVBVGOd9B6pntvqA7LdMVhH9pVsZCDSRSLZxAVZ/koL8 pGZNufA1dbbKPwnhuJXublF4jOA37HxwyR9slpZypw1a4ugYHapLQRznLiAy10nd QWdBUNX4ijUcCmIuXC7svHs967PR1DKvXLxjnlcAIh0P/+ar8lqcPcSVHsbKZMBk 8uMNO8msCh2Qlkx8PoF2 =3K2L -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 16:34:21 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 05059106566C; Sat, 28 Jan 2012 16:34:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6C58FC08; Sat, 28 Jan 2012 16:34:19 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3312855wib.13 for ; Sat, 28 Jan 2012 08:34: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:content-type :content-transfer-encoding; bh=B0Uq5I1mYaaDZ9rx5TMCGEzSJ3duNVCjxo12goClvtA=; b=tamz16P/toS/LtBK2qJiF4e7oTnjnqggp+Xv7k3YvtNEZGsQ3mLjrfn/0ng8XBrugs PlxO6tcBKAWbhpDhkIzaHHVeNm6bkGps/fTVKPnP8R7S1+VieP16am5XukUnbCt8b0zc WzWjEm3RBPFukqevJx9bFdfkJKJOloKXne46k= MIME-Version: 1.0 Received: by 10.180.109.77 with SMTP id hq13mr18401922wib.7.1327766591358; Sat, 28 Jan 2012 08:03:11 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Sat, 28 Jan 2012 08:03:11 -0800 (PST) In-Reply-To: References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Sat, 28 Jan 2012 17:03:11 +0100 X-Google-Sender-Auth: A3bGQKxC_f9Bc9MRYADpTfYRpZE Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 16:34:21 -0000 2011/11/8 Attilio Rao : > 2011/11/8 Attilio Rao : >> Author: attilio >> Date: Tue Nov =C2=A08 10:18:07 2011 >> New Revision: 227333 >> URL: http://svn.freebsd.org/changeset/base/227333 >> >> Log: >> =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default= on >> =C2=A0all the architectures. >> =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the >> =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. >> >> =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems >> =C2=A0from the tree. > > This is just a gentle reminder in order to point you further to the > "official" page: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > and encourage once again people in adopting a dying FS if it really > matters to them. > So far, unfortunately, I didn't see a lot of activity in this area but > I hope that this would change soon. This is a further reminder. So far I've not seen any improvement over the locking of any of our 'legacy' filesystems. I remind you that this may be meaning disconnecting them from the tree on 1st Semptember 2012, accordingly with this road-map: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in order to see how well the users do with this option down. At the present times this means that from 1st March you won't be able to mount smbfs or ntfs volumes, for example. Please step up and fix your favourite filesystem. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 22:13: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 2C4E81065673; Sat, 28 Jan 2012 22:13:16 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD8E8FC0C; Sat, 28 Jan 2012 22:13:14 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1116547eaa.13 for ; Sat, 28 Jan 2012 14:13:14 -0800 (PST) Received: by 10.213.25.78 with SMTP id y14mr1955869ebb.139.1327788787920; Sat, 28 Jan 2012 14:13:07 -0800 (PST) Received: from rnote.ddteam.net (238-239-92-178.pool.ukrtel.net. [178.92.239.238]) by mx.google.com with ESMTPS id n56sm49505525eeh.6.2012.01.28.14.13.04 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 14:13:06 -0800 (PST) Date: Sun, 29 Jan 2012 00:12:51 +0200 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20120129001251.7e4cfe83.ray@ddteam.net> In-Reply-To: References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> 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-net@freebsd.org, Aleksandr Rybalko , Stefan Bethke , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 22:13:16 -0000 On Wed, 25 Jan 2012 09:57:32 +0100 Stefan Bethke wrote: > My suggestion is to take my bus attachment code (incl. mdio and > miiproxy) and ray's ioctl and userland code. As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible, that why I send you patch http://my.ddteam.net/files/2012-01-22_arge.patch which clean most phymask features from if_arge driver. You may ask me why I do so? It is because arge H/W is not the single implementation, it is just FPGA design that also used in many other devices, f.e. if_et. Look into dev/et/if_etreg.h, begin from line: #define ET_MAC_CFG1 0x5000 There is the same registers, same logic, just mapped at 0x5000 in device PCI BAR, instead of 0x19000000(arge) and I bet it is not last time when that FPGA design used :) > > Aleksandr's approach for the driver attachment is to have a generic > switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, > etc. busses the devices are physically attached to, and present a > uniform register file to the chip-specific switch driver. I believe > that this is unnecessarily complicated for two reasons: newbus > already provides that abstraction, and chip-specific drivers usually > differ in so many aspects, including their register files, that code > sharing between chips will be somewhat limited anyway. newbus allow attach anything to anything, but bus interfaces implemented in different ways (for mem/mdio we call read/write, for SPI/IIC we call transfer). When we made that interfaces consistent we be able really forget about "bus glue". While we still not done it(even still not doing it), model with single parent (switch0) require bus glue for each supported interface (MDIO, MEM, SPI, etc.). But model with direct attach driver to bus will require bus glue per driver. If only one interface is supported, then glue in driver file, else - separate file per each supported interface. And two words about "complicated": 1. If we about complicated structure of devices - yes switch0 with bcm5325_switch0 more complicated, than just bcm5325_switch0, but device tree will care about it. 2. If we about code size, then I will say my model much smaller even having more drivers. My personal decision - is 2, because - less code better for maintenance. > > One aspect that I would enjoy looking into in more detail is how > register accesses on, for example, MDIO, can be provided through the > bus space API. From my cursory reading, it seems that the code > currently is tailored towards register accesses that can be > implemented through CPU native instructions, instead of indirectly > through a controller. > > Aleksandr has defined a quite comprehensive ethernet switch control > API that the framework provides towards in-kernel clients as well as > userland. I think it would be really helpful if we could concentrate > on those API functions that can be controlled through the userland > utility, have immediate use cases (for example, VLAN configuration on > the TL-WR1043ND to separate the WAN from the LAN ports), and we have > test hardware for. In short, don't commit dead code. It is not dead code, it is TODO :) > > Having a description of the generic switch model that the API assumes > and driver-specific documentation also wouldn't hurt. (Yes, I'm > volunteering.) It is also TODO :) On Thu, 26 Jan 2012 22:03:58 -0800 Adrian Chadd wrote: > Ok, I do like the idea of: > > * mdiobus/miibus proxy tidyup; > * then the switch API; > * then the switch devices themselves. > > Can we get some consensus/agreement from Marius (and others) about the > first step? I think we don't need to "rewrite" miibus now. :) > > > Adrian WBW -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 23:26:54 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 D3175106566B; Sat, 28 Jan 2012 23:26:54 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 195878FC08; Sat, 28 Jan 2012 23:26:53 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so2481723wgb.1 for ; Sat, 28 Jan 2012 15:26:53 -0800 (PST) Received: by 10.180.89.71 with SMTP id bm7mr14901816wib.20.1327791621197; Sat, 28 Jan 2012 15:00:21 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.208.210 with HTTP; Sat, 28 Jan 2012 15:00:01 -0800 (PST) In-Reply-To: <20120129001251.7e4cfe83.ray@ddteam.net> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> From: Juli Mallett Date: Sat, 28 Jan 2012 15:00:01 -0800 X-Google-Sender-Auth: -ga7FvK7qbBxsus2YXrZSJahcsA Message-ID: To: Aleksandr Rybalko Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Adrian Chadd , freebsd-arch@freebsd.org, Aleksandr Rybalko , Stefan Bethke Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 23:26:54 -0000 On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko wrote: > As I see from your patch, mdio/miiproxy require special bits in MAC > driver. When I design switch framework, I keeping in mind that > MAC drivers should be standard as possible I don't understand why this is desirable in practice. It's a nice theory, but it falls down when one thinks in depth about how Ethernet interfaces are used and administered vs. how switches are used and administered. What should media report? What should media changes do? What is link status? Do you show the CPU-to-switch port, or all switch ports? It makes me wonder if the understanding of the relationship in FreeBSD isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but you can conceptualize of it as a child of the PHY, rather than the parent of it, especially in systems with switch chipsets. Especially in systems where there is a switch chipset attached to multiple MACs. In that model, it makes sense to semi-generically attach a CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) to a MAC generically, but that doesn't meant that the switch itself is attached generically to the MAC. There are a lot of switches out there that don't look or act much like MII-driven PHYs, but which are connected over MDIO, as I've tried to stress before. I hope there will be as much separation between the MII work that is being done and the switch work that is being done as possible. I think anything else will prove rapidly-obsolete and perhaps even obstructive as soon as anyone seeks to add support for more switch chipsets to FreeBSD. I suppose the most likely reality, though, is that people simply won't add switch support to FreeBSD, and will administer them out-of-band from userland, using gross kernel shims. That is probably true whether any of the currently-outstanding work is committed or not, unfortunately :( I just hope we'll end up with something flexible enough, broad enough in applicability, narrow enough in requirements, etc., that we'll have feature-rich support for a few chipsets in tree that work in sufficiently-different manners that they can be models for other drivers in the future. Thanks, Juli. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 28 23:37:15 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 C6D2D1065782; Sat, 28 Jan 2012 23:37:15 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB568FC15; Sat, 28 Jan 2012 23:37:15 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 27FB71DFD42; Sun, 29 Jan 2012 00:37:13 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 0E04E28468; Sun, 29 Jan 2012 00:37:13 +0100 (CET) Date: Sun, 29 Jan 2012 00:37:12 +0100 From: Jilles Tjoelker To: Giovanni Trematerra Message-ID: <20120128233712.GA92694@stack.nl> References: <20120110005155.S2378@besplex.bde.org> <20120110153807.H943@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , flo@freebsd.org, Konstantin Belousov , freebsd-arch@freebsd.org Subject: Re: pipe/fifo code merged. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 23:37:15 -0000 On Tue, Jan 17, 2012 at 12:43:19PM +0100, Giovanni Trematerra wrote: > Did you agree that this patch > http://www.trematerra.net/patches/pipefifo_merge2.4.diff > doesn't introduce any further regressions while it fixes > - style bugs you pointed out. > - pipe_stat now use underlying filesystem information for pipes. > - comment about pipeinfo was intended for. > - race into pipe_poll (look at fifo_iseof line). I tested this version of the patch and found that it breaks opening a fifo with O_TRUNC: it fails with [EINVAL]. This appears to be pipe_truncate()'s doing. Previously, truncate requests went to the vnode. In particular, this happens when opening a fifo for writing using sh(1)'s > (unless 'set -C' is in effect) or >| redirection operators. The open properly blocks until a reader arrives but then fails with [EINVAL]. Several tests in tools/regression/bin/sh do this. -- Jilles Tjoelker