Re: CVS commit: src/sys/rump
In message: <20090909010833.ga12...@netbsd.org> David Holland writes: : On Tue, Sep 08, 2009 at 10:02:33AM -0600, M. Warner Losh wrote: : > __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. : > You need to use a different symbol. This is a bug in the NetBSD code : > now. __NetBSD__ isn't, and never has bene, the KERNEL. : : No need to shout... : : Anyway, what does the compiler environment *mean* besides "we're : building a NetBSD binary"? That's exactly what rumpkernel is, even if : it's compiled with the FreeBSD compiler. Properly speaking it ought to : be built with a cross-compiler; maybe that'll happen in the long term. If you are building with a FreeBSD compiler, you are building a FreeBSD binary, by definition. __FreeBSD__ means you are building a FreeBSD binary. If that's not what you want to do, you need to jump through a lot of hoops, but it usually easier to build a cross compiler than jump through those hoops. There's a lot more to the environment than just -D__FreeBSD__, there's the default binaries that are produced, there's a bunch of defines and arch assertions, default paths to includes and libraries, etc. This may be inconvenient. I know years ago I tried building a NetBSD kernel with a FreeBSD compiler, and that failed due to these differences (and others other than __NetBSD__ not being defined). Trying to kludge it caused me much pain and suffering. I abandoned the effort because building a proper cross compiler turned out to be a lot easier... sorry for the shouting earlier, but this is a hot-button since I've had to explain this difference many times to many people over the years... Warner
Re: CVS commit: src/sys/rump
On Tue, Sep 08, 2009 at 10:02:33AM -0600, M. Warner Losh wrote: > __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. > You need to use a different symbol. This is a bug in the NetBSD code > now. __NetBSD__ isn't, and never has bene, the KERNEL. No need to shout... Anyway, what does the compiler environment *mean* besides "we're building a NetBSD binary"? That's exactly what rumpkernel is, even if it's compiled with the FreeBSD compiler. Properly speaking it ought to be built with a cross-compiler; maybe that'll happen in the long term. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/dev/sbus
On Wed, Sep 09, 2009 at 04:00:30AM +0900, Izumi Tsutsui wrote: > >sbus_establish() should take device_t self for the device itself, > >not device_t parent even if sbus is grandparent of the device, > >otherwise (*sd_reset)() callbacks will be called with an wrong device_t. > >Even in such case, sbus_establish() looks for an sbus though device tree. > >XXX: (*sd_reset)() isn't called anyway, and these stuff seems really > > bogus. > > > i think you're right. can you just delete all this sbusreset() code? > > I wonder why sbus_establish() and struct sbus_dev were implemented. > > I guess we can remove sbusreset() and (*sd_reset)() stuff safely, > but other members in struct sbusdev are used only in > sbus/if_le.c to see unattached lebuffer (I don't think it worked > as expected due to the bug mentioned in the log, though), so > it might be better to remove whole sbus_establish() stuff if possible. > > Anyway, I'll leave them for now since they are harmless. There has to be a load of code somewhere that deals with the lance errata that causes it to tri-state its output part way through an sbus master cycle [1]. Get it slightly wrong and the sbus locks. I've never looked to see if netbsd has the appropraite code! David [1] it all goes badly pear-shaped when an sbus master cycle takes exactly 255 clocks. Part of the lance times the cycle out on clock 255, and parts on clock 256! -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/dev
On Tue Sep 08 2009 at 20:57:59 +, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Tue Sep 8 20:57:59 UTC 2009 > > Modified Files: > src/sys/dev: rnd.c > > Log Message: > rnd_wakeup_readers() uses rndpool_mtx for its own consistency > management, so it cannot be called with the mutex held. There is > no consistency requirement to synchronize over the whole add-and-wakeup > operation, as if data is consumed in the window the mutex is locked, I win again. Meant *un*locked. fixed the repo.
Re: CVS commit: src/sys/dev/sbus
>sbus_establish() should take device_t self for the device itself, >not device_t parent even if sbus is grandparent of the device, >otherwise (*sd_reset)() callbacks will be called with an wrong device_t. >Even in such case, sbus_establish() looks for an sbus though device tree. >XXX: (*sd_reset)() isn't called anyway, and these stuff seems really bogus. > i think you're right. can you just delete all this sbusreset() code? I wonder why sbus_establish() and struct sbus_dev were implemented. I guess we can remove sbusreset() and (*sd_reset)() stuff safely, but other members in struct sbusdev are used only in sbus/if_le.c to see unattached lebuffer (I don't think it worked as expected due to the bug mentioned in the log, though), so it might be better to remove whole sbus_establish() stuff if possible. Anyway, I'll leave them for now since they are harmless. --- Izumi Tsutsui
re: CVS commit: src/sys/dev/sbus
Module Name: src Committed By:tsutsui Date:Tue Sep 8 18:31:36 UTC 2009 Modified Files: src/sys/dev/sbus: esp_sbus.c if_le_lebuffer.c if_le_ledma.c Log Message: sbus_establish() should take device_t self for the device itself, not device_t parent even if sbus is grandparent of the device, otherwise (*sd_reset)() callbacks will be called with an wrong device_t. Even in such case, sbus_establish() looks for an sbus though device tree. XXX: (*sd_reset)() isn't called anyway, and these stuff seems really bogus. i think you're right. can you just delete all this sbusreset() code? .mrg.
Re: CVS commit: src/sys/rump
In message: <20090908162339.ga11...@cs.hut.fi> Antti Kantee writes: : On Tue Sep 08 2009 at 12:18:57 -0400, Christos Zoulas wrote: : > | : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* : > | : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which : > | : was imported from $OtherOS, you must have the rump version think it is : > | : running on NetBSD, since it technically speaking is. The difference to : > | : most cpp symbols is merely that __NetBSD__ comes from the compiler instead : > | : of from the kernel headers. Of course param.h could define something like : > | : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD : > | : kernel code, but I don't see any benefit, especially since __NetBSD__ : > | : is a well established practise even outside NetBSD developers. : > | : > | __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. : > | You need to use a different symbol. This is a bug in the NetBSD code : > | now. __NetBSD__ isn't, and never has bene, the KERNEL. : > : > That was my complaint exactly. I meant to say this in my next message :-) : > : > | Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD : > | kernel build environment specific (since it comes from sys/parma.h) : > | and doesn't muddy the waters with the differences between the : > | different BUILD systems. : > : > That is what I was thinking also. : : Whoever finds this churn worth their effort, as dh pointed out, remember : to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, : __Slowaris__, __sMackOS__, __etc__ as well. How many instances of those are there? And wouldn't it be spelled __linsux__? :) Warmer
re: CVS commit: src/sys/rump
In article <20090908162339.ga11...@cs.hut.fi>, ntti Kantee wrote: > >Whoever finds this churn worth their effort, as dh pointed out, remember >to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, >__Slowaris__, __sMackOS__, __etc__ as well. The issue here is that we really don't want to override the symbols set by the compiler because a lot of code assumes that they are going to be set by the compiler, and not by other external means. Everytime I remember someone did this, it had to be reverted for one reason or the other. this is a pretty special case. i don't think anything beyond defining __NetBSD__ and undefining anything else used in our tree is worth it. the way that rump is separated from the host makes this quite a reasonable way of doing it. "rump" -- which is a virtual netbsd kernel -- doesn't talk to userspace itself. it's a real netbsd kernel. it is self contained and doesn't invoke the host. it has "rumpuser" for that, and rumpuser is not compiled with -D__NetBSD__. .mrg.
Re: CVS commit: src/sys/rump
On Tue Sep 08 2009 at 16:33:02 +, Christos Zoulas wrote: > In article <20090908162339.ga11...@cs.hut.fi>, > ntti Kantee wrote: > > > >Whoever finds this churn worth their effort, as dh pointed out, remember > >to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, > >__Slowaris__, __sMackOS__, __etc__ as well. > > The issue here is that we really don't want to override the symbols set > by the compiler because a lot of code assumes that they are going to be > set by the compiler, and not by other external means. Everytime I remember > someone did this, it had to be reverted for one reason or the other. Yes, I now realize it is the wrong thing to do (thank you). However, in its current form it only fixes things. It's not like rump on non-NetBSD is a fully supported concept. So for the time being, I think it is an acceptable path to take. Anything else, IMHO, is "premature optimization".
Re: CVS commit: src/sys/rump
In article <20090908162339.ga11...@cs.hut.fi>, ntti Kantee wrote: > >Whoever finds this churn worth their effort, as dh pointed out, remember >to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, >__Slowaris__, __sMackOS__, __etc__ as well. The issue here is that we really don't want to override the symbols set by the compiler because a lot of code assumes that they are going to be set by the compiler, and not by other external means. Everytime I remember someone did this, it had to be reverted for one reason or the other. christos
Re: CVS commit: src/etc/rc.d
On Tue, Sep 08, 2009 at 06:07:57PM +0200, Christoph Egger wrote: > Joerg Sonnenberger wrote: > > On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: > >>> Perhaps a better test would be that dhcpcd shouldn't touch > >>> the default route unless the default route is through the > >>> interface that dhcpcd is managing. > >> I agree. > >> How should dhcpcd deal with /etc/resolv.conf ? > >> If dhcpcd removes and rewrites the entries, DNS queries in-between > >> may fail (i.e. mounting nfs) > > > > I would say you have a completely broken setup in that case. You can > > easily prevent dhcpcd from changing the default route at all if you need > > to. > > I tried dhcpcd -n -p but I ended up with having the nfs server > unreachable. You haven't included -G to keep the default route. Joerg
Re: CVS commit: src/sys/rump
On Tue Sep 08 2009 at 12:18:57 -0400, Christos Zoulas wrote: > | : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* > | : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which > | : was imported from $OtherOS, you must have the rump version think it is > | : running on NetBSD, since it technically speaking is. The difference to > | : most cpp symbols is merely that __NetBSD__ comes from the compiler instead > | : of from the kernel headers. Of course param.h could define something like > | : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD > | : kernel code, but I don't see any benefit, especially since __NetBSD__ > | : is a well established practise even outside NetBSD developers. > | > | __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. > | You need to use a different symbol. This is a bug in the NetBSD code > | now. __NetBSD__ isn't, and never has bene, the KERNEL. > > That was my complaint exactly. I meant to say this in my next message :-) > > | Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD > | kernel build environment specific (since it comes from sys/parma.h) > | and doesn't muddy the waters with the differences between the > | different BUILD systems. > > That is what I was thinking also. Whoever finds this churn worth their effort, as dh pointed out, remember to replace all instances of __FreeBSD__, __OpenBSD__, __Linux__, __Slowaris__, __sMackOS__, __etc__ as well.
Re: CVS commit: src/sys/rump
On Sep 8, 10:02am, i...@bsdimp.com ("M. Warner Losh") wrote:
-- Subject: Re: CVS commit: src/sys/rump
| In message: <20090908131801.gb17...@cs.hut.fi>
| Antti Kantee writes:
| : On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote:
| : > In article <20090907174634.ga16...@cs.hut.fi>,
| : > Antti Kantee wrote:
| : > >On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote:
| : > >>
| : > >>Module Name:src
| : > >>Committed By: pooka
| : > >>Date: Mon Sep 7 13:02:37 UTC 2009
| : > >>
| : > >>Modified Files:
| : > >>src/sys/rump: Makefile.rump
| : > >>
| : > >>Log Message:
| : > >>Always define __NetBSD__ (for builds on non-NetBSD)
| : > >>
| : > >>
| : > >> when does this happen? even builds on non-NetBSD should
| : > >> end up here with a compiler that defines __NetBSD__.
| : > >
| : > >When you are building the binaries to be used as libraries on non-NetBSD,
| : > >i.e. not building NetBSD itself.
| : >
| : > Then perhaps we should be using a different CPP symbol?
| :
| : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is*
| : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which
| : was imported from $OtherOS, you must have the rump version think it is
| : running on NetBSD, since it technically speaking is. The difference to
| : most cpp symbols is merely that __NetBSD__ comes from the compiler instead
| : of from the kernel headers. Of course param.h could define something like
| : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD
| : kernel code, but I don't see any benefit, especially since __NetBSD__
| : is a well established practise even outside NetBSD developers.
|
| __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*.
| You need to use a different symbol. This is a bug in the NetBSD code
| now. __NetBSD__ isn't, and never has bene, the KERNEL.
That was my complaint exactly. I meant to say this in my next message :-)
| Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD
| kernel build environment specific (since it comes from sys/parma.h)
| and doesn't muddy the waters with the differences between the
| different BUILD systems.
That is what I was thinking also.
christos
Re: CVS commit: src/etc/rc.d
Joerg Sonnenberger wrote: > On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: >>> Perhaps a better test would be that dhcpcd shouldn't touch >>> the default route unless the default route is through the >>> interface that dhcpcd is managing. >> I agree. >> How should dhcpcd deal with /etc/resolv.conf ? >> If dhcpcd removes and rewrites the entries, DNS queries in-between >> may fail (i.e. mounting nfs) > > I would say you have a completely broken setup in that case. You can > easily prevent dhcpcd from changing the default route at all if you need > to. I tried dhcpcd -n -p but I ended up with having the nfs server unreachable. Christoph
Re: CVS commit: src/sys/rump
In message: <20090908131801.gb17...@cs.hut.fi> Antti Kantee writes: : On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote: : > In article <20090907174634.ga16...@cs.hut.fi>, : > Antti Kantee wrote: : > >On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote: : > >> : > >>Module Name: src : > >>Committed By: pooka : > >>Date: Mon Sep 7 13:02:37 UTC 2009 : > >> : > >>Modified Files: : > >> src/sys/rump: Makefile.rump : > >> : > >>Log Message: : > >>Always define __NetBSD__ (for builds on non-NetBSD) : > >> : > >> : > >> when does this happen? even builds on non-NetBSD should : > >> end up here with a compiler that defines __NetBSD__. : > > : > >When you are building the binaries to be used as libraries on non-NetBSD, : > >i.e. not building NetBSD itself. : > : > Then perhaps we should be using a different CPP symbol? : : No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* : NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which : was imported from $OtherOS, you must have the rump version think it is : running on NetBSD, since it technically speaking is. The difference to : most cpp symbols is merely that __NetBSD__ comes from the compiler instead : of from the kernel headers. Of course param.h could define something like : __I_am_the_NetBSD__ and we could test against that in all of our NetBSD : kernel code, but I don't see any benefit, especially since __NetBSD__ : is a well established practise even outside NetBSD developers. __NetBSD__ is the *COMPILER* environment. Depending on it is *BAD*. You need to use a different symbol. This is a bug in the NetBSD code now. __NetBSD__ isn't, and never has bene, the KERNEL. : Maybe it's easier to understand this issue if you think of rump as a : highly componentized OS running inside a virtual machine. Just instead : of qemu or xen or what have you, your vmm is a process -- nobody is : saying xen code shouldn't use __NetBSD__, are they? I'd say that it shouldn't... : I think Matt understood my extended offline explanation yesterday, : so maybe he could chime in and summarize? Maybe __NetBSD_Version__ should be used instead? Its clearly NetBSD kernel build environment specific (since it comes from sys/parma.h) and doesn't muddy the waters with the differences between the different BUILD systems. Warner
Re: CVS commit: src/etc/rc.d
On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote: > > Perhaps a better test would be that dhcpcd shouldn't touch > > the default route unless the default route is through the > > interface that dhcpcd is managing. > > I agree. > How should dhcpcd deal with /etc/resolv.conf ? > If dhcpcd removes and rewrites the entries, DNS queries in-between > may fail (i.e. mounting nfs) I would say you have a completely broken setup in that case. You can easily prevent dhcpcd from changing the default route at all if you need to. Joerg
Re: CVS commit: src/sys/rump
On Tue Sep 08 2009 at 13:25:39 +, David Holland wrote: > On Tue, Sep 08, 2009 at 04:18:01PM +0300, Antti Kantee wrote: > > No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* > > NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which > > was imported from $OtherOS, you must have the rump version think it is > > running on NetBSD, since it technically speaking is. > > You may need to also add -U__FreeBSD__ -U__OpenBSD__... Hmm, good point. I didn't think of that. I wonder if there's a better solution than an exhaustive list of operating systems? Do we after all need to check against __I_am_the_NetBSD__?
Re: CVS commit: src/sys/rump
On Tue, Sep 08, 2009 at 04:18:01PM +0300, Antti Kantee wrote: > No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* > NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which > was imported from $OtherOS, you must have the rump version think it is > running on NetBSD, since it technically speaking is. You may need to also add -U__FreeBSD__ -U__OpenBSD__... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump
On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote: > In article <20090907174634.ga16...@cs.hut.fi>, > Antti Kantee wrote: > >On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote: > >> > >>Module Name:src > >>Committed By: pooka > >>Date: Mon Sep 7 13:02:37 UTC 2009 > >> > >>Modified Files: > >>src/sys/rump: Makefile.rump > >> > >>Log Message: > >>Always define __NetBSD__ (for builds on non-NetBSD) > >> > >> > >> when does this happen? even builds on non-NetBSD should > >> end up here with a compiler that defines __NetBSD__. > > > >When you are building the binaries to be used as libraries on non-NetBSD, > >i.e. not building NetBSD itself. > > Then perhaps we should be using a different CPP symbol? No, __NetBSD__ is right. For all purposes, code in the rump kernel *is* NetBSD. E.g. if you have #ifdef __NetBSD__ in a kernel driver which was imported from $OtherOS, you must have the rump version think it is running on NetBSD, since it technically speaking is. The difference to most cpp symbols is merely that __NetBSD__ comes from the compiler instead of from the kernel headers. Of course param.h could define something like __I_am_the_NetBSD__ and we could test against that in all of our NetBSD kernel code, but I don't see any benefit, especially since __NetBSD__ is a well established practise even outside NetBSD developers. Maybe it's easier to understand this issue if you think of rump as a highly componentized OS running inside a virtual machine. Just instead of qemu or xen or what have you, your vmm is a process -- nobody is saying xen code shouldn't use __NetBSD__, are they? I think Matt understood my extended offline explanation yesterday, so maybe he could chime in and summarize?
Re: CVS commit: src/sys/rump
In article <20090907174634.ga16...@cs.hut.fi>, Antti Kantee wrote: >On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote: >> >>Module Name: src >>Committed By: pooka >>Date: Mon Sep 7 13:02:37 UTC 2009 >> >>Modified Files: >> src/sys/rump: Makefile.rump >> >>Log Message: >>Always define __NetBSD__ (for builds on non-NetBSD) >> >> >> when does this happen? even builds on non-NetBSD should >> end up here with a compiler that defines __NetBSD__. > >When you are building the binaries to be used as libraries on non-NetBSD, >i.e. not building NetBSD itself. Then perhaps we should be using a different CPP symbol? christos
Re: CVS commit: src/etc/rc.d
> On Tue, 08 Sep 2009, Christoph Egger wrote: > > > > Do not flush routes if root file system is nfs mounted. > > > > Fixes boot problem when the nfs server is in a different > > > > subnet. > > > > > > Why do you need this special case code, when a simple > > > flushroutes=NO in /etc/rc.conf will do the job? > > > > I prefer a default value that works out-of-the box. > > So do I, but why is flushroutes true out of the box? Isn't that > the right thing to fix? I am not sure. > > there's another problem still to address: > > > > if you have multiple interfaces and you have > > 'dhcp' in /etc/ifconfig. then > > dhcpcd tries to remove and re-add the default route. > > dhcpcd shouldn't touch the default route if root is on NFS > > because you end up with > > I still don't see why "root on NFS" is the right condition to > use in a test for whether to flush routes or to change the > default route. For example, if root is local but /var is on > NFS, you will get similar problems. We can extend rc.subr with a function which determines if we mount nfs and if we have root-on-nfs and exports corresponding variables set to yes or no. All scripts can use them to easily test "root on NFS". > Perhaps a better test would be that dhcpcd shouldn't touch > the default route unless the default route is through the > interface that dhcpcd is managing. I agree. How should dhcpcd deal with /etc/resolv.conf ? If dhcpcd removes and rewrites the entries, DNS queries in-between may fail (i.e. mounting nfs) Christoph
Re: CVS commit: src/etc/rc.d
On Tue, 08 Sep 2009, Christoph Egger wrote: > > > Do not flush routes if root file system is nfs mounted. > > > Fixes boot problem when the nfs server is in a different > > > subnet. > > > > Why do you need this special case code, when a simple > > flushroutes=NO in /etc/rc.conf will do the job? > > I prefer a default value that works out-of-the box. So do I, but why is flushroutes true out of the box? Isn't that the right thing to fix? > there's another problem still to address: > > if you have multiple interfaces and you have > 'dhcp' in /etc/ifconfig. then > dhcpcd tries to remove and re-add the default route. > dhcpcd shouldn't touch the default route if root is on NFS > because you end up with I still don't see why "root on NFS" is the right condition to use in a test for whether to flush routes or to change the default route. For example, if root is local but /var is on NFS, you will get similar problems. Perhaps a better test would be that dhcpcd shouldn't touch the default route unless the default route is through the interface that dhcpcd is managing. --apb (Alan Barrett)
Re: CVS commit: src/etc/rc.d
> On Tue, 08 Sep 2009, Christoph Egger wrote: > > Modified Files: > > src/etc/rc.d: network > > > > Log Message: > > Do not flush routes if root file system is nfs mounted. > > Fixes boot problem when the nfs server is in a different > > subnet. > > Why do you need this special case code, when a simple > flushroutes=NO in /etc/rc.conf will do the job? I prefer a default value that works out-of-the box. > Perhaps sysinst should automatically set > flushroutes=NO if it knows you have root on NFS. there's another problem still to address: if you have multiple interfaces and you have 'dhcp' in /etc/ifconfig. then dhcpcd tries to remove and re-add the default route. dhcpcd shouldn't touch the default route if root is on NFS because you end up with nfs_timer: ignoring error 65 nfs_timer: ignoring error 65 nfs_timer: ignoring error 65 [...] Christoph
Re: CVS commit: src/etc/rc.d
On Tue, 08 Sep 2009, Christoph Egger wrote: > Modified Files: > src/etc/rc.d: network > > Log Message: > Do not flush routes if root file system is nfs mounted. > Fixes boot problem when the nfs server is in a different subnet. Why do you need this special case code, when a simple flushroutes=NO in /etc/rc.conf will do the job? Perhaps sysinst should automatically set flushroutes=NO if it knows you have root on NFS. --apb (Alan Barrett)
