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 po...@netbsd.org 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
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: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
In message: 20090908131801.gb17...@cs.hut.fi Antti Kantee po...@cs.hut.fi writes: : On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote: : In article 20090907174634.ga16...@cs.hut.fi, : Antti Kantee po...@netbsd.org 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/sys/rump
In message: 20090908162339.ga11...@cs.hut.fi Antti Kantee po...@cs.hut.fi 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
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 po...@cs.hut.fi writes: | : On Tue Sep 08 2009 at 13:02:55 +, Christos Zoulas wrote: | : In article 20090907174634.ga16...@cs.hut.fi, | : Antti Kantee po...@netbsd.org 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
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 if 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
In article 20090908162339.ga11...@cs.hut.fi, ntti Kantee po...@cs.hut.fi 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/sys/rump
In article 20090908162339.ga11...@cs.hut.fi, ntti Kantee po...@cs.hut.fi 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/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 if but I ended up with having the nfs server unreachable. Christoph
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
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/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
