Enabling AHCI on ICH7M
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My laptop manufacturer decided not to have AHCI included in the BIOS for this device, so I've been looking at what needs to happen in order to make this work. On this device, the BIOS doesn't even initialize BAR(5), so I need to start at that point .. from the Intel specs, it seemed fairly straight-forward: Give the AHCI sub-system a chunk of memory by initializing BAR(5), tell the PCI bridge(s) about it, reset the various config bits to flip from legacy to AHCI mode and leave the rest to what already exists in the ata-intel driver. My question, however, relates to the choice of memory: Can I simply call contigmalloc() to get a chunk of memory space whose physical address I can get with vtophys and leave the mapping for the PCI bridge to the existing call to bus_alloc_resource_any()? Is there a better method of finding some "free" physical space into which to put the ICH7M AHCI registers? imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAku6hhQACgkQQv9rrgRC1JJ9TgCghkR8j9xy2MbSNW1LSRMhzX6h AdAAnR6Ctnvyng4W9qRbP0vtM352SYSo =t6V3 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on ia64/ia64
On Mon, 5 Apr 2010, Robert Watson wrote: In file included from /src/sys/fs/coda/coda_fbsd.c:49: /src/sys/fs/coda/cnode.h:97: error: expected specifier-qualifier-list before 'CodaFid' /src/sys/fs/coda/cnode.h:199: error: expected ')' before '*' token Sorry all -- I'll commit a fix for this shortly -- my fault for building the modules rather than LINT: turns out that neither coda5 nor coda modules build the same code as the kernel. There's some argument coda5 should be removed at this point, but I'll leave that for another day. Perhaps it was a tinderbox race -- I can't reproduce this on amd64, and the line numbers don't really make sense. Oh well. I'll see if it pops up on other tinderboxen. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on ia64/ia64
On Mon, 5 Apr 2010, FreeBSD Tinderbox wrote: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xl/if_xl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/fs/coda/coda_fbsd.c In file included from /src/sys/fs/coda/coda_fbsd.c:49: /src/sys/fs/coda/cnode.h:97: error: expected specifier-qualifier-list before 'CodaFid' /src/sys/fs/coda/cnode.h:199: error: expected ')' before '*' token Sorry all -- I'll commit a fix for this shortly -- my fault for building the modules rather than LINT: turns out that neither coda5 nor coda modules build the same code as the kernel. There's some argument coda5 should be removed at this point, but I'll leave that for another day. (waiting for LINT to compile ... this time) Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2010-04-05 20:44:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-05 20:44:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-04-05 20:44:45 - cleaning the object tree TB --- 2010-04-05 20:45:08 - cvsupping the source tree TB --- 2010-04-05 20:45:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-04-05 20:45:22 - building world TB --- 2010-04-05 20:45:22 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-05 20:45:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-05 20:45:22 - TARGET=ia64 TB --- 2010-04-05 20:45:22 - TARGET_ARCH=ia64 TB --- 2010-04-05 20:45:22 - TZ=UTC TB --- 2010-04-05 20:45:22 - __MAKE_CONF=/dev/null TB --- 2010-04-05 20:45:22 - cd /src TB --- 2010-04-05 20:45:22 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 5 20:45:23 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Apr 5 22:02:36 UTC 2010 TB --- 2010-04-05 22:02:36 - generating LINT kernel config TB --- 2010-04-05 22:02:36 - cd /src/sys/ia64/conf TB --- 2010-04-05 22:02:36 - /usr/bin/make -B LINT TB --- 2010-04-05 22:02:36 - building LINT kernel TB --- 2010-04-05 22:02:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-05 22:02:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-05 22:02:36 - TARGET=ia64 TB --- 2010-04-05 22:02:36 - TARGET_ARCH=ia64 TB --- 2010-04-05 22:02:36 - TZ=UTC TB --- 2010-04-05 22:02:36 - __MAKE_CONF=/dev/null TB --- 2010-04-05 22:02:36 - cd /src TB --- 2010-04-05 22:02:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 5 22:02:36 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/xl/if_xl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-func
Re: Call for testers: fxp(4) Rx buffer use after free
On Sun, Apr 04, 2010 at 06:00:54PM -0700, Pyun YongHyeon wrote: > Hi, > > It seems that fxp(4) has a long standing races between controller > and driver. The exotic RFD handling of controller is race prone as > we had seen old ethernet controllers. I could easily reproduce this > by rebooting system while netperf 64bytes UDP test is in progress. > If heavy RX frames hit the controller while interface UP is in > progress, controller started DMAing to freed mbufs such that > "Memory modified after free" message showed up. Based on OpenBSD's > patch I made a patch which seems to fix the issue. > If you saw this type of issue please give it try and let me how > it goes on your box. The patch has effect only on interrupt mode so > if you're using polling(4) you would have no effects. > You can get download the patch at the following URL. > http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch > > After applying the patch you may see somewhat increased RNR counter > value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have > lower RNR counter value but that fake value came from DMAing to > freed mbufs which was completely wrong. > Hmm, it seems there are other issues in the patch. I'll post new patch after fixing this. > Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
On Mon, 5 Apr 2010, jhell wrote: Hi, reading the thread in thread view I had wondered why your reply had been ignored until I realized that it was the last to come in. So I'll use it to reply to, especially as I like it. I have no idea (unless I'll read them) about the guts of various shell function magic we use to configure interfaces, and I heck do not care about where it's called autoblah_foo or zigbangbusheek as none of our users does, so I'll ignore that. I'll probably have to comment on a few rc.conf knobs as that's all a user cares about. Not really seeing the correct thread to reply to with this content I decided to reply to Kevin and lead off from here. Seeing a lot of *_enable for interfaces makes sense in the traditional way of configuring daemons or enabling things like rtsold/rtadvd for IPv6. Don't get me wrong but the below I am not talking about phasing those _enables out for the daemons. Personally I believe that using them for such a behavior as configuring a protocol for a interface is incorrect usage given the current use of IPv4 and not needing something like ipv4_enable. Why not skip the need for ipv?_enable all-in-all and leave those out of the mix?. Since they do not really disable them or enable anything other than the ability to use and or check ipv6 related daemons. As said, I like the idea of simplification. And I like the idea of having: ifconfig__ipv6="inet6 ..." ifconfig__ipv6_alias="inet6 ..." as well as ipv6_defaultrouter=".." ipv6_static_routes=".." ipv6_gateway_enable=".." An I like it for IPv4 and actually if you look at defaults/rc.conf you will find that we even liked it for: ifconfig_ed0_ipx="ipx 0x00010010" ipxgateway_enable="NO" So here comes one of the things I don't like, POLA back POLA forth. None of the three AFs was implemented in a consistent way. In the old days we used (and still) have (though a lot less) a mix of "ip6" and "ipv6" and while IPv4 was kind of "default" there was no ifconfig__ipv4=".." which has historic reasons I believe but it was ifconfig__ipx= and I like it that it's ifconfig__ipv6 now. It should be ipx_gateway_enable instaed of ipxgateway_enable but that's something to cleanup more easily;) Neither IPv4 nor IPX have an _enable="" knob in defaults/rc.conf and I cannot see why we would need it for IPv6. You don't configure it on an interface you don't have it configured an interface. The fact that it had been there for IPv6 is historic and could have been a good or bad idea at that time during the early days of development. I am actully too lazy to see why it had really been added. If I boot up without having any RC framework or anything but the shell run, these days I get a network stack with a loopback interface and it looks like this: # ifconfig -a lo0: flags=8008 metric 0 mtu 16384 options=3 if it also had an interface it would look like this: iface: flags=8842 metric 0 mtu 1500 ether 02:00:00:00:07:0a There is no IPv6 address, there is no IPv4 address, they are down because noone told them to be up. If I "up" them manually it looks like this: lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=21 iface: flags=8843 metric 0 mtu 1500 ether 02:00:00:00:07:0a inet6 fe80::ff:fe00:70a%iface prefixlen 64 scopeid 0x2 nd6 options=21 This actually is bad but that's because neither devd nor the rc framework were run yet and the kernel defaults were never changed (if my memory serves me right for RFC reasons). Silly me doing this in "single user";) I wouldn't want to have a link-local address on my non-loopback interfaces working unless I asked for them. That's why we had ipv6_autolinklocal in the past and that's why the current rc/devd/iface framework prevents this from happening unless explicitly asked for. That's why there is nd6 options=. If if were to implement 3927 (I think it was) 169.254.0.0 stuff like some other OSes do we would want to control that as well and have it off by default. Why do I not want that for our users? Let me repeat the argument from a couple of years ago from other people: "If I put my FreeBSD machine anywhere and I have no clue about IPv6 I don't want my neighbor to ping6 or ssh or even compromise my machine just because I didn't know we have this kind of thing and autom-agic happened." That's why link-local addresses had been disabled in the past (similar arguemnts would apply for the 169.254/16 case). Re-enabling them had never worked well in the past if ipv6_enable was NO on boot. You had to change the sysctl (manually) and then down up the interface(s) leading to serivce interruption even for IPv4. There is a PR about it if you want to check. In the past there was no way to express "enable it on my wired interface but not on my wireless" or "enable on the inside but not the outside interface" or enabled/disable it smoothly on run-time
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
John Hay wrote in <20100405083056.ga8...@zibbi.meraka.csir.co.za>: jh> These questions actually start more questions for me. :-) Maybe we should jh> also think from the user perspective and list a few use cases and what a jh> user need to put in rc.conf to make that work? jh> jh> Your normal desktop/notebook user on a ipv6 radv network, what does he jh> need to do to have his machine ipv6 usable? Given that it is 9-CURRENT and the box has 1 NIC (fxp0), add the following line to rc.conf: ifconfig_fxp0_ipv6="accept_rtadv" jh> A network server that does not accept radv, what should its ipv6 config jh> in rc.conf look like? ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64" jh> What about a server that accept radv (so that it can get router info) jh> and have fixed addresses for it services? ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64 accept_rtadv" jh> A router kind of box, what should it look like? Given that the box has 2 NICs (fxp0 and fxp1), add the following lines to rc.conf: ipv6_gateway_enable="YES" ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64" ifconfig_fxp1_ipv6="inet6 2001:db8:2::1/64" And, no ifconfig_IF_ipv6 line means no IPv6 configuration for the IF. After my changes committed last September, the existence of ifconfig_IF_ipv6 is used as a flag for whether IPv6 is enable or not on that interface. -- Hiroki pgpNptkehlRmA.pgp Description: PGP signature
Re: ipv6_enable
On 04/05/2010 00:21, Kevin Oberman wrote: >> Date: Sun, 04 Apr 2010 20:13:40 -0700 >> From: Doug Barton >> >> On 04/04/10 02:41, Hiroki Sato wrote: >>> "Kevin Oberman" wrote >>> in <20100404053352.e6f751c...@ptavv.es.net>: > > Gentlemen, > > I think this is converging on a good, functional solution. Making > ipv6_enable="NO" really turn off IPv6 looks like the ideal answer, but I > think it's up to Hiroki to determine if it is feasible. I did my last > kernel programming on VMS about 25 years ago and it was in assembly and > BLISS, not C. > > I am just a bit uncomfortable with the use of the DHCP tag in rc.conf > to control the use of SLAAC as SLAAC is so different in function and > capability from DHCPv4, but it's probably the best we can do. > > Thanks to both of you for your attention to this. I think IPv6 is > critical and anything that makes the transition easier will bear great > fruit at time goes on. Not really seeing the correct thread to reply to with this content I decided to reply to Kevin and lead off from here. Seeing a lot of *_enable for interfaces makes sense in the traditional way of configuring daemons or enabling things like rtsold/rtadvd for IPv6. Don't get me wrong but the below I am not talking about phasing those _enables out for the daemons. Personally I believe that using them for such a behavior as configuring a protocol for a interface is incorrect usage given the current use of IPv4 and not needing something like ipv4_enable. Why not skip the need for ipv?_enable all-in-all and leave those out of the mix?. Since they do not really disable them or enable anything other than the ability to use and or check ipv6 related daemons. How about this? (using ath0 as the example interface) and following what we already do for DHCP on ipv4 interfaces. ifconfig_ath0_inet6="dead:beef::1000::1 RTSOL RTADV DHCP" While right now without inet6 would obviously be ipv4 configured and when the time comes to switch to IPv6 by default, chop the inet6 into just inet or inet4. This eventually should lead into a smoother transition than ipv4_enable ipv6_enable while relieving some of the checks that to me just seem useless and can be checked for just by the existance of the above interface with inet6 attached to the end. Obviously if the configuration line exists then the user wants ipv6 functionality configured so check that line and mark ipv6 enabled. Maybe its just me but I really think we are trying to check for way to much here to make it a usable solution for the end user. No offense intended. PS: I would really love to sort(1) a rc.conf and have ipv4 and ipv6 functionality sorted together by interface but this is not my main goal by writing this. Same would go for static_routes but that is another story. Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
Doug Barton wrote in <4bb95564.1070...@freebsd.org>: do> On 04/04/10 02:41, Hiroki Sato wrote: do> > "Kevin Oberman" wrote do> > in <20100404053352.e6f751c...@ptavv.es.net>: do> > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I do> > ob> see no reason not to use them to enable or disable functionality whether do> > ob> it involves a script in rc.d or not. The idea is to have a clear, do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. do> > do> > Another reason I lean to not using xxx_enable is that an rc.d knob do> > cannot control enabling/disabling the IPv6 functionality actually. do> > It was true even when we were using the network_ipv6 script. do> do> But that's equally true of how you're using ipv6_prefer. :) You've do> basically just moved the overloading of 2 of the 3 previous functions of do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do> functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included "disable ACCEPT_RTADV by default", which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into "whether an IPv6 address is assigned or not". That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by "disable IPv6". My opinion is "ipv6_enable=NO" should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki pgpB7qA06TOsk.pgp Description: PGP signature
Re: ipv6_enable
On 04/04/10 22:42, Hiroki Sato wrote: > Doug Barton wrote > in <4bb7e224.6020...@freebsd.org>: > > If people want to disable IPv6 GUA assignment in per-AF manner, it > should be done by per-AF global knobs for $ifconfig_* because the GUA > assignment involves $ifconfig_* knobs only for the user as explained > in another email. To be honest, I think what you're proposing is way too complicated, and unnecessarily so. I think you've got a very interesting vision for where we should end up down the road, but as I said in a previous message I think your proposed UI is much too complex. > Let me summarize what I agree and disagree again: > > a. I agree that it is useful to have a knob for disabling all of > ifconfig_IF_ipv6 handling. That's not what I'm actually proposing. Your idea is that the model should be focused on ifconfig_IF_ipv6. I'd like to make that completely unnecessary for the common case (RA). > However, I disagree with using the > name "ipv6_enable" just for the purpose. ipv6_enable=NO never > means disabling IPv6 functionality in the kernel, and it will > cause people tend to think IPv6 is disabled completely. Throughout this discussion you've been ignoring something very important. The ipv6_enable knob already existed, and already had well understood semantics, which you removed. IMO this is a serious POLA violation. What I'm suggesting is a return to the same semantics that we had previously, but with your improvements running under the hood. I think being able to disable RA particularly and IPv6 generally on a per-interface basis is a tremendous improvement. > If we want to disable ifconfig_IF_AF lines in a handy manner, > implementing ifconfig_DEFAULT_AF is more consistent and where we > should go. All of AF-specific parameters for an interface are in > $ifconfig_IF_AF, and having a global knob to define the default > for all interfaces are quite reasonable to me. I do not want to > go back to AF-specific handling like ipv6_* wherever possible. > > I think this policy is compatible with David Horn's suggestions. > "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, > "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, > "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for > example (note that I do not stick to these keywords. "slaac" > would also be a good candidate). No concern for > conflicting/confusing with IPv4; this is orthogonal among AFs. We > can support another new method by just adding a keyword. Once again, I think what you're proposing is interesting, but way too complex. I certainly think it's too complex as a first step. > Note that SLAAC and DHCPv6 are exclusive. That's not accurate, but it's outside the scope of this issue. > Combinations of > DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the > latter is rather popular). This is one of the reasons I stick to > the per-IF/per-AF solution here. Once again, we don't disagree on the principle, that's why I'm adding support for [NO]RTADV so that down the road we could have something like ifconfig_IF_ipv6="RTADV DHCPV6-PD", etc. > b. Disagree with disabling IPv6 by default. I think there is no > technical and security reason to go back to the old days. Need to be clear on what this means. Given that INET6 is in GENERIC (which I think it should be) we have to have a sensible default when it comes to configuring the external interfaces. IMO the only sensible default for that is not to. Configuring them by default when the user doesn't actually have IPv6 connectivity to the outside world would cause a lot of problems. > And, well, please let me suggest something for the further discussion > here. Whether we have $ipv6_enable or not, whether we enable > $ipv6_enable by default or not, and whether receiving RA by default > or not, are separated topics from each other. So, I would like > everyone's opinions for the following points separately: > > 1. Do we need a knob to disable IPv6? If so, which in the following > is expected for that knob? > > 1-a) Disable ifconfig_IF_ipv6 processing only. This means people > can still do manual configuration for IPv6. My version of the patch does this. > 1-b) Disable IPv6 functionlity completely. We don't currently have a way to do this at all if INET6 is in the kernel. > 2. If we have a knob described in 1, what should be the default > value? Off. > 3. Do we go for "accept RAs by default"? We can break down this in > the following way related to 2: > > 3-a) Enable IPv6 functionality and accept RAs by default. > > 3-b) Enable IPv6 functionality and not accept RAs by default > > 3-c) Disable IPv6 functionality by default and accept RAs if one > enables IPv6 in rc.conf. I think this is the right answer, but others have expressed disagreement on accepting RAs by defaul
Re: Ports breakage since r205471
On Mon, Apr 5, 2010 at 2:12 AM, Erwin Lansing wrote: > On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote: >> On 2010/04/05 01:50, Erwin Lansing wrote: >> > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: >> >> Hi all, >> >> I realize that this is most suitable for current@ and I'm >> >> cross-posting, but I wanted to jot down all of the ports broken since >> >> the zlib version bump so that we can keep track of what's going on and >> >> what needs to be fixed. >> > >> > I have just started a new package build against todays HEAD on pointyhat >> > , actually before seeing this thread, so these, and any others, will be >> > picked up there. I'll update the list with the results when it finishes >> > in a day or two. >> >> Which svn revision is currently using on the build cluster? >> > Unfortunately, we're still using cvs for updating, but I just double > checked that it is past r206058. The update is less than an hour old > from cvs. You won't see the issue unless you roll back to before r206057; r206057 and r206058 disguise the compatibility issue by completely zapping the #ifdef _LARGEFILE64_SOURCE and #if _FILE_OFFSET_BITS == 64 enable pieces. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ports breakage since r205471
On Mon, Apr 05, 2010 at 02:02:46AM -0700, Xin LI wrote: > On 2010/04/05 01:50, Erwin Lansing wrote: > > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: > >> Hi all, > >> I realize that this is most suitable for current@ and I'm > >> cross-posting, but I wanted to jot down all of the ports broken since > >> the zlib version bump so that we can keep track of what's going on and > >> what needs to be fixed. > > > > I have just started a new package build against todays HEAD on pointyhat > > , actually before seeing this thread, so these, and any others, will be > > picked up there. I'll update the list with the results when it finishes > > in a day or two. > > Which svn revision is currently using on the build cluster? > Unfortunately, we're still using cvs for updating, but I just double checked that it is past r206058. The update is less than an hour old from cvs. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpxXYOcVBKqh.pgp Description: PGP signature
Re: Ports breakage since r205471
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/04/05 01:50, Erwin Lansing wrote: > On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: >> Hi all, >> I realize that this is most suitable for current@ and I'm >> cross-posting, but I wanted to jot down all of the ports broken since >> the zlib version bump so that we can keep track of what's going on and >> what needs to be fixed. > > I have just started a new package build against todays HEAD on pointyhat > , actually before seeing this thread, so these, and any others, will be > picked up there. I'll update the list with the results when it finishes > in a day or two. Which svn revision is currently using on the build cluster? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLuac2AAoJEATO+BI/yjfBusMH/jAc2pH439rkteRRX5oK+IXo hV3qXE0pMNkrGDDciVbYuJ9r/niqdkBIqaaw2te8K97YwBAdpikheHV0NaHoOzYT J+OiKmTu2o96J7FV7ORSRmPUcKhHHTjXwLMF2Kz9MeoRvYJqyVk1m33wMuDdIGEe 57Pxq3sXpbfmUoOq5S7ITLXSPqE+l5Xh0j4wM7wULQWhabTw1akliDGxvwr1XqrU 8r+3dbLASzV8hitIXk92MLCfomJNDgsW3VV3nqlzmiLlwBOfGrGowZblKlgHUWO4 VEJ6qCXpRPGpelIVSDyguR3BCEl2m9tyQ3xQ8MEznjwuOJGpp8vwNrwAUOB0PpE= =g4ur -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
I think it's clear at this point that you and I have some pretty serious disagreements about how this thing should look. I think that's unfortunate, since you have a lot of good ideas, I just think some of them are wrong. :) Seriously though, I hope we can find a way to come to agreement. I'm going to repeat myself one more time here, and in response to your other post, and then step back and let others express their opinions. I'd really like to come to an agreement on how to proceed in the next couple days. On 04/04/10 22:49, Hiroki Sato wrote: > Doug Barton wrote > in <4bb95564.1070...@freebsd.org>: > > do> On 04/04/10 02:41, Hiroki Sato wrote: > do> > "Kevin Oberman" wrote > do> > in <20100404053352.e6f751c...@ptavv.es.net>: > do> > > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts > and I > do> > ob> see no reason not to use them to enable or disable functionality > whether > do> > ob> it involves a script in rc.d or not. The idea is to have a clear, > do> > ob> obvious way to enable or disable functionality. I see nothing in > Hiroki's > do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > do> > > do> > Another reason I lean to not using xxx_enable is that an rc.d knob > do> > cannot control enabling/disabling the IPv6 functionality actually. > do> > It was true even when we were using the network_ipv6 script. > do> > do> But that's equally true of how you're using ipv6_prefer. :) You've > do> basically just moved the overloading of 2 of the 3 previous functions of > do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > do> functions into different knobs. > > No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. > It is just related to source address selection and a seatbelt for > IPv4-only people. I do not think I just moved the old functions. > > Let me explain how these changes happened. As I explained earlier, I > added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some > configuration even if you do not use IPv4 when the kernel supports > it, and skipping all of IPv6 configuration in the old > rc.d/network_ipv6 script caused another problems. So, I thought it > was possible to enable IPv6 by default and initialize the > functionality with reasonable default parameters. This parameters > included "disable ACCEPT_RTADV by default", which is one of the > topics we are discussing now. I think most of what you've got here is right, and I've tried to preserve it in my changes. My understanding is that lo0 needs to be configured if INET6 is in the kernel, but none of the other interfaces need to be. > The old rc.d/network_ipv6 had a lot more for IPv6 configuration in > the $ipv6_enable conditional clause and ipv6_enable=NO meant to > disable them, too. This is a big difference. The new ipv6_enable in > your patch is not the same in this regard. The end result is the same though. If ipv6_enable=no then when ifconfig_up() calls ipv6if() it'll come back negative, and that interface won't be configured for IPv6 at all. Specifically, the "inet6 ifdisabled" ifconfig arg will be given. > Well, I can understand and agree that people want a handy knob to > disable IPv6. I think it is more constructive for this discussion to > be more specific what should be disabled, then. I am still not sure > what you and other people mean by "disable IPv6". My definition is "not configuring IPv6 on any interface other than lo0." > My opinion is "ipv6_enable=NO" should mean disabling IPv6 > functionality completely. If we had a method of "turning off" IPv6 at the kernel level even though INET6 is in the kernel then I would agree with you. Since we don't have that, "inet6 ifdisabled" is the next best option. > I do not want to call a knob just to > ignore ifconfig_IF_ipv6 lines as "ipv6_enable" That's not what I'm proposing, have you actually looked at my patch? > as well as do not want > to disable IPv6 functionality completely by default. I don't know exactly what you mean by this. I _think_ you mean that IPv6 functionality should remain available, but that the interfaces should not be configured unless there is a specific configuration given via ifconfig_IF_ipv6. Is that right? If so, I agree with you, and my patch accomplishes this. The difference being that in v2 of the patch RA has to be enabled in ifconfig_IF_ipv6, OR it will be enabled if there is IPv4 DHCP configuration for the interface. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Ports breakage since r205471
On Sun, Apr 04, 2010 at 03:06:15PM -0700, Garrett Cooper wrote: > Hi all, > I realize that this is most suitable for current@ and I'm > cross-posting, but I wanted to jot down all of the ports broken since > the zlib version bump so that we can keep track of what's going on and > what needs to be fixed. I have just started a new package build against todays HEAD on pointyhat , actually before seeing this thread, so these, and any others, will be picked up there. I'll update the list with the results when it finishes in a day or two. > >Also, I really think we should add packaging metadata to third > party libraries in base and at least track the versioning and > dependencies because this CURRENT upgrade has turned into a royal mess > and has eaten up more of my time than it should have. Unfortunately, the story of ports on CuRRENT :-( -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpcMxDbzRDjq.pgp Description: PGP signature
Re: ipv6_enable
On Mon, Apr 05, 2010 at 02:42:52PM +0900, Hiroki Sato wrote: > Doug Barton wrote > in <4bb7e224.6020...@freebsd.org>: > > do> As we've discussed previously, you and I have a lot of disagreement on > do> some of these principles. I'm going to outline my responses in some > do> detail, however I'm also interested in what others have to say since I'd > do> ultimately like to see some consensus from the community on how this > do> should be configured. > > Yes, I agree that it is good to have discussion with more people. > > do> I'm just about the biggest rc.d purist there is, and even I don't agree > do> with this. :) I also disagree with your idea that "the original design > do> of rc.d scripts" didn't intend for concepts like this. > > Sorry for the noise. This involves my preference and was a different > story. Please ignore this for IPv6 discussion for the moment. > > do> > Second, if people need a way to disable IPv6 protocol, they have > do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need > do> > a handy way for on-and-off, separating the IPv6 configuration from > do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into > do> > /etc/rc.conf should be enough, for example. > do> > do> Even if I agreed with this idea (and I don't necessarily have strong > do> DISagreement with it) the knob has existed since the beginning of IPv6 > do> support in FreeBSD, and shouldn't be removed lightly. Personally I find > do> it handy to be able to configure things in rc.conf and turn them on and > do> off with one knob without having to comment or uncomment a bunch of stuff. > > I didn't removed it *lightly*. My motivation for that is I want to > enable IPv6 by default without making trouble for IPv4-only people. > I also committed several kernel-level measures for people who want > IPv4-only, IPv6-only, and the both to live without the knob at that > time. > > Enabling/disabling IPv6 by using rc.d script was quite complex and > the switching will be incomplete with no kernel support. My > conclusion for integration of the network_ipv6->netif changes was > "depend on if adding an GUA or not" and it works fine for > asynchronous invocation of rc.d/netif as well as needs no reboot for > the switch (see another email for the whole story). Some processing > which were in network_ipv6 (calculating $rtsol_interface and so on) > are intentionally removed thanks to this assumption. If you want to > go back to the old days and enable receiving RA by default, we must > look into the whole process carefully again. > > If people want to disable IPv6 GUA assignment in per-AF manner, it > should be done by per-AF global knobs for $ifconfig_* because the GUA > assignment involves $ifconfig_* knobs only for the user as explained > in another email. > > Let me summarize what I agree and disagree again: > > a. I agree that it is useful to have a knob for disabling all of > ifconfig_IF_ipv6 handling. However, I disagree with using the > name "ipv6_enable" just for the purpose. ipv6_enable=NO never > means disabling IPv6 functionality in the kernel, and it will > cause people tend to think IPv6 is disabled completely. > > If we want to disable ifconfig_IF_AF lines in a handy manner, > implementing ifconfig_DEFAULT_AF is more consistent and where we > should go. All of AF-specific parameters for an interface are in > $ifconfig_IF_AF, and having a global knob to define the default > for all interfaces are quite reasonable to me. I do not want to > go back to AF-specific handling like ipv6_* wherever possible. > > I think this policy is compatible with David Horn's suggestions. > "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, > "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, > "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for > example (note that I do not stick to these keywords. "slaac" > would also be a good candidate). No concern for > conflicting/confusing with IPv4; this is orthogonal among AFs. We > can support another new method by just adding a keyword. > > Note that SLAAC and DHCPv6 are exclusive. Combinations of > DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the > latter is rather popular). This is one of the reasons I stick to > the per-IF/per-AF solution here. > > b. Disagree with disabling IPv6 by default. I think there is no > technical and security reason to go back to the old days. > > do> > Also, we should not consider IPv6 as special. > do> > do> I wish that were so, but I disagree. I think we need to make it as easy > do> as possible for users to take advantage of IPv6, but there are a lot of > do> reasons why it is actually special. Primarily because unlike some of our > do> other networking protocols it's "on the cusp" of being something that > do> everyone will need someday, but isn't
Re: ipv6_enable
Doug Barton wrote in <4bb95564.1070...@freebsd.org>: do> On 04/04/10 02:41, Hiroki Sato wrote: do> > "Kevin Oberman" wrote do> > in <20100404053352.e6f751c...@ptavv.es.net>: do> > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I do> > ob> see no reason not to use them to enable or disable functionality whether do> > ob> it involves a script in rc.d or not. The idea is to have a clear, do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. do> > do> > Another reason I lean to not using xxx_enable is that an rc.d knob do> > cannot control enabling/disabling the IPv6 functionality actually. do> > It was true even when we were using the network_ipv6 script. do> do> But that's equally true of how you're using ipv6_prefer. :) You've do> basically just moved the overloading of 2 of the 3 previous functions of do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do> functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included "disable ACCEPT_RTADV by default", which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into "whether an IPv6 address is assigned or not". That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by "disable IPv6". My opinion is "ipv6_enable=NO" should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki pgp4tjGEbjwmU.pgp Description: PGP signature
