Re: CVS commit: src/sys/rump/include/rump
On 16.06.2020 14:23, Kamil Rytarowski wrote: > On 16.06.2020 12:25, J. Hannken-Illjes wrote: >>> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote: >>> >>> Module Name:src >>> Committed By: kamil >>> Date: Sun Jun 14 23:38:25 UTC 2020 >>> >>> Modified Files: >>> src/sys/rump/include/rump: rump.h >>> >>> Log Message: >>> Remove old compat include of rump_syscallshotgun.h >>> >>> It was separated in 2016 and is no longer needed. >>> >>> >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.71 -r1.72 src/sys/rump/include/rump/rump.h >>> >>> Please note that diffs are not public domain; they are subject to the >>> copyright notices on the relevant files. >> >> This broke most or all NFS tests on ATF (see attached list). >> >> Please revert or investigate. >> >> -- >> J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany) >> > > I'm looking into it. > Should be fixed. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/rump/include/rump
On 16.06.2020 12:25, J. Hannken-Illjes wrote: >> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote: >> >> Module Name: src >> Committed By:kamil >> Date:Sun Jun 14 23:38:25 UTC 2020 >> >> Modified Files: >> src/sys/rump/include/rump: rump.h >> >> Log Message: >> Remove old compat include of rump_syscallshotgun.h >> >> It was separated in 2016 and is no longer needed. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.71 -r1.72 src/sys/rump/include/rump/rump.h >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. > > This broke most or all NFS tests on ATF (see attached list). > > Please revert or investigate. > > -- > J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany) > I'm looking into it. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/rump/include/rump
> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote: > > Module Name: src > Committed By: kamil > Date: Sun Jun 14 23:38:25 UTC 2020 > > Modified Files: > src/sys/rump/include/rump: rump.h > > Log Message: > Remove old compat include of rump_syscallshotgun.h > > It was separated in 2016 and is no longer needed. > > > To generate a diff of this commit: > cvs rdiff -u -r1.71 -r1.72 src/sys/rump/include/rump/rump.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. This broke most or all NFS tests on ATF (see attached list). Please revert or investigate. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany) fs/nfs/t_mountd::mountdhup fs/vfs/t_full::nfs_fillfs fs/vfs/t_io::nfs_extendfile fs/vfs/t_io::nfs_extendfile_append fs/vfs/t_io::nfs_holywrite fs/vfs/t_io::nfs_overwrite512 fs/vfs/t_io::nfs_overwrite64k fs/vfs/t_io::nfs_overwrite_trunc fs/vfs/t_io::nfs_read_after_unlink fs/vfs/t_io::nfs_read_fault fs/vfs/t_io::nfs_shrinkfile fs/vfs/t_io::nfs_wrrd_after_unlink fs/vfs/t_mtime_otrunc::nfs_otrunc_mtime_update fs/vfs/t_mtime_write::nfs_mtime_update_on_write fs/vfs/t_renamerace::nfs_renamerace fs/vfs/t_renamerace::nfs_renamerace_dirs fs/vfs/t_rmdirrace::nfs_race fs/vfs/t_ro::nfs_attrs fs/vfs/t_ro::nfs_create fs/vfs/t_ro::nfs_createdir fs/vfs/t_ro::nfs_createfifo fs/vfs/t_ro::nfs_createlink fs/vfs/t_ro::nfs_createsymlink fs/vfs/t_ro::nfs_fileio fs/vfs/t_ro::nfs_rmfile fs/vfs/t_ro::nfsro_attrs fs/vfs/t_ro::nfsro_create fs/vfs/t_ro::nfsro_createdir fs/vfs/t_ro::nfsro_createfifo fs/vfs/t_ro::nfsro_createlink fs/vfs/t_ro::nfsro_createsymlink fs/vfs/t_ro::nfsro_fileio fs/vfs/t_ro::nfsro_rmfile fs/vfs/t_rwtoro::nfs_layer_noneopen fs/vfs/t_rwtoro::nfs_layer_read_unlinked fs/vfs/t_rwtoro::nfs_layer_readopen fs/vfs/t_rwtoro::nfs_layer_writeopen fs/vfs/t_rwtoro::nfs_noneopen fs/vfs/t_rwtoro::nfs_read_unlinked fs/vfs/t_rwtoro::nfs_readopen fs/vfs/t_rwtoro::nfs_writeopen fs/vfs/t_union::nfs_basic fs/vfs/t_union::nfs_whiteout fs/vfs/t_unpriv::nfs_dirperms fs/vfs/t_unpriv::nfs_flags fs/vfs/t_unpriv::nfs_owner fs/vfs/t_unpriv::nfs_times fs/vfs/t_vfsops::nfs_tfhinval fs/vfs/t_vfsops::nfs_tfhremove fs/vfs/t_vfsops::nfs_tfilehandle fs/vfs/t_vfsops::nfs_tmount fs/vfs/t_vfsops::nfs_tstatvfs fs/vfs/t_vfsops::nfs_tsync fs/vfs/t_vnops::nfs_access_simple fs/vfs/t_vnops::nfs_attrs fs/vfs/t_vnops::nfs_create_exist fs/vfs/t_vnops::nfs_create_many fs/vfs/t_vnops::nfs_create_nametoolong fs/vfs/t_vnops::nfs_create_nonalphanum fs/vfs/t_vnops::nfs_dir_notempty fs/vfs/t_vnops::nfs_dir_rmdirdotdot fs/vfs/t_vnops::nfs_dir_simple fs/vfs/t_vnops::nfs_fcntl_getlock_pids fs/vfs/t_vnops::nfs_fcntl_lock fs/vfs/t_vnops::nfs_lookup_complex fs/vfs/t_vnops::nfs_lookup_simple fs/vfs/t_vnops::nfs_lstat_symlink fs/vfs/t_vnops::nfs_read_directory fs/vfs/t_vnops::nfs_rename_dir fs/vfs/t_vnops::nfs_rename_dotdot fs/vfs/t_vnops::nfs_rename_nametoolong fs/vfs/t_vnops::nfs_rename_reg_nodir fs/vfs/t_vnops::nfs_symlink_long fs/vfs/t_vnops::nfs_symlink_root fs/vfs/t_vnops::nfs_symlink_zerolen signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/rump
On Sat, Apr 25, 2020 at 08:49:14AM -0700, Jason Thorpe wrote: > Why were any of these files touched by Xen changes? listsrcdirs is expected, we need to add xen here (because we now need xen/intrdefs.h For others I don't know. Actually a cvs diff shows that only the $NetBSD: $ did change. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/rump
Why were any of these files touched by Xen changes? > On Apr 25, 2020, at 8:42 AM, Manuel Bouyer wrote: > > Module Name: src > Committed By: bouyer > Date: Sat Apr 25 15:42:15 UTC 2020 > > Modified Files: > src/sys/rump: listsrcdirs > src/sys/rump/dev/lib/libumass: Makefile > src/sys/rump/fs/lib/libffs: Makefile > src/sys/rump/include/rump: rump_syscalls.h > src/sys/rump/librump/rumpkern: lwproc.c rump.c rump_syscalls.c sleepq.c > src/sys/rump/librump/rumpvfs: rump_vfs.c rumpfs.c > > Log Message: > Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM > guests in GENERIC. > Xen support can be disabled at runtime with > boot -c > disable hypervisor > > > To generate a diff of this commit: > cvs rdiff -u -r1.49 -r1.50 src/sys/rump/listsrcdirs > cvs rdiff -u -r1.11 -r1.12 src/sys/rump/dev/lib/libumass/Makefile > cvs rdiff -u -r1.18 -r1.19 src/sys/rump/fs/lib/libffs/Makefile > cvs rdiff -u -r1.115 -r1.116 src/sys/rump/include/rump/rump_syscalls.h > cvs rdiff -u -r1.47 -r1.48 src/sys/rump/librump/rumpkern/lwproc.c > cvs rdiff -u -r1.345 -r1.346 src/sys/rump/librump/rumpkern/rump.c > cvs rdiff -u -r1.146 -r1.147 src/sys/rump/librump/rumpkern/rump_syscalls.c > cvs rdiff -u -r1.19 -r1.20 src/sys/rump/librump/rumpkern/sleepq.c > cvs rdiff -u -r1.92 -r1.93 src/sys/rump/librump/rumpvfs/rump_vfs.c > cvs rdiff -u -r1.157 -r1.158 src/sys/rump/librump/rumpvfs/rumpfs.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/sys/rump
On 09.03.2020 15:31, Taylor R Campbell wrote: >> Module Name:src >> Committed By: kamil >> Date: Mon Mar 9 00:03:00 UTC 2020 >> >> Modified Files: >> src/sys/rump: Makefile.rump >> >> Log Message: >> Build RUMP with -fno-delete-null-pointer-checks on all compilers > > I asked you to hold off on making this change, ten hours before you > proceeded to make it: > > https://mail-index.NetBSD.org/tech-kern/2020/03/08/msg026125.html > > It remains unclear whether the change is actually necessary. > It is necessary. The tool detects real UB and the tool is not broken. I went that far that I summoned people from compilers and the C + C++ standard to confirm this. > Please back this out until the discussion has reached a conclusion, > and please don't unilaterally move ahead to make changes that are > still under active discussion -- especially when someone in the > discussion you initiated has specifically asked you to wait. > > If there is a dispute that has deadlocked in public discussion and > requires a resolution, then you can present a case to core and ask for > a ruling. But right now the discussion is not deadlocked and nobody > has asked for core to step in to resolve any dispute in order to make > progress. > I will revert it for the time being on this demand. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/rump
> Module Name:src > Committed By: kamil > Date: Mon Mar 9 00:03:00 UTC 2020 > > Modified Files: > src/sys/rump: Makefile.rump > > Log Message: > Build RUMP with -fno-delete-null-pointer-checks on all compilers I asked you to hold off on making this change, ten hours before you proceeded to make it: https://mail-index.NetBSD.org/tech-kern/2020/03/08/msg026125.html It remains unclear whether the change is actually necessary. Please back this out until the discussion has reached a conclusion, and please don't unilaterally move ahead to make changes that are still under active discussion -- especially when someone in the discussion you initiated has specifically asked you to wait. If there is a dispute that has deadlocked in public discussion and requires a resolution, then you can present a case to core and ask for a ruling. But right now the discussion is not deadlocked and nobody has asked for core to step in to resolve any dispute in order to make progress.
re: CVS commit: src/sys/rump/kern/lib/libsljit/arch/mips
> Module Name: src > Committed By: alnsn > Date: Tue Jan 22 01:25:53 UTC 2019 > > Modified Files: > src/sys/rump/kern/lib/libsljit/arch/mips: cache.c > > Log Message: > Cast register_t to uintptr_t before casting to void *. > > Not sure what's going on here but evbmips64-el build fails > without this cast. on mips64 and the default userland, register_t is 64 bit but uintptr_t and void * are both 32 bit. your change is right -- going via uintptr_t. .mrg.
Re: CVS commit: src/sys/rump/librump/rumpnet
On Tue, Feb 27, 2018 at 02:45:43PM +, Maxime Villard wrote: > Oops, forgot this file; I just merged two IPsec functions, so adapt > the rump stubs accordingly. .. > __weak_alias(esp6_ctlinput,rumpnet_stub); > __weak_alias(ipsec4_output,rumpnet_stub); > __weak_alias(ipsec4_common_input,rumpnet_stub); > -__weak_alias(ipsec4_delete_pcbpolicy,rumpnet_stub); > __weak_alias(ipsec4_forward,rumpnet_stub); > __weak_alias(ipsec4_input,rumpnet_stub); > __weak_alias(ipsec4_set_policy,rumpnet_stub); > __weak_alias(ipsec6_common_input,rumpnet_stub); > __weak_alias(ipsec6_input,rumpnet_stub); > __weak_alias(ipsec6_check_policy,rumpnet_stub); > -__weak_alias(ipsec6_delete_pcbpolicy,rumpnet_stub); > -__weak_alias(ipsec6_get_policy,rumpnet_stub); > __weak_alias(ipsec6_process_packet,rumpnet_stub); > __weak_alias(ipsec6_set_policy,rumpnet_stub); > +__weak_alias(ipsec_get_policy,rumpnet_stub); > +__weak_alias(ipsec_delete_pcbpolicy,rumpnet_stub); > __weak_alias(ipsec_hdrsiz,rumpnet_stub); > __weak_alias(ipsec_in_reject,rumpnet_stub); > __weak_alias(ipsec_init_policy,rumpnet_stub); > For a normal library I assume this would require a major bump. do we do this for rump?
Re: CVS commit: src/sys/rump/librump/rumpkern
pullup to 8.0? On Tue, 25 Jul 2017, Ryota Ozaki wrote: Module Name:src Committed By: ozaki-r Date: Tue Jul 25 05:01:25 UTC 2017 Modified Files: src/sys/rump/librump/rumpkern: Makefile.rumpkern Log Message: Add localcount to rump kernels To generate a diff of this commit: cvs rdiff -u -r1.169 -r1.170 src/sys/rump/librump/rumpkern/Makefile.rumpkern Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5976d0ab241195299513085! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/rump/dev
On 18/11/14 09:27, matthew green wrote: Antti Kantee writes: Module Name:src Committed By: pooka Date: Tue Nov 18 08:43:03 UTC 2014 Modified Files: src/sys/rump/dev: Makefile.rumpdevcomp Added Files: src/sys/rump/dev/lib/libpci_eap: Makefile PCI_EAP.ioconf eap_at_pci.c joy_eap.h shlib_version Log Message: Add eap PCI audio driver. tested by playing audio with rump kernel booted on qemu with -soundhw es1370 i'm disappointed in you, son, that you don't have the real hardware anymore. Are you upset that I didn't fix the second DAC sounds like a fish problem yet? Ask me again in 2024. By then the sea levels will have risen enough that we'll all be talking fish anyway.
re: CVS commit: src/sys/rump/librump/rumpnet
Mindaugas Rasiukevicius writes: Module Name: src Committed By: rmind Date: Sun May 18 14:03:26 UTC 2014 Modified Files: src/sys/rump/librump/rumpnet: net_stub.c Log Message: Fix RUMP build. please describe the change itself, not the objective. .mrg.
Re: CVS commit: src/sys/rump/kern
Martin Husemann wrote:
Log Message:
sljit is only available on very few architectures, so do not try to build
it on all.
We have a special MKSLJIT variable. It's enabled by default on the three
arches you listed below but it can also be turned on on arm and mips.
Alex
To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sys/rump/kern/Makefile.rumpkerncomp
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/rump/kern/Makefile.rumpkerncomp
diff -u src/sys/rump/kern/Makefile.rumpkerncomp:1.6
src/sys/rump/kern/Makefile.rumpkerncomp:1.7
--- src/sys/rump/kern/Makefile.rumpkerncomp:1.6 Sat Nov 16 01:39:18 2013
+++ src/sys/rump/kern/Makefile.rumpkerncomp Sat Nov 16 10:34:47 2013
@@ -1,9 +1,15 @@
-#$NetBSD: Makefile.rumpkerncomp,v 1.6 2013/11/16 01:39:18 rmind Exp $
+#$NetBSD: Makefile.rumpkerncomp,v 1.7 2013/11/16 10:34:47 martin Exp $
#
.include bsd.own.mk
-RUMPKERNCOMPS= crypto sljit tty z
+RUMPKERNCOMPS= crypto tty z
+
+.if ${MACHINE_ARCH} == i386 || \
+${MACHINE_ARCH} == x86_64 || \
+${MACHINE_ARCH} == sparc
+RUMPKERNCOMPS+= sljit
+.endif
.if ${MKZFS} != no
RUMPKERNCOMPS+=solaris
--
Re: CVS commit: src/sys/rump/kern
On Sat, Nov 16, 2013 at 11:17:09AM +, Alexander Nasonov wrote: Martin Husemann wrote: Log Message: sljit is only available on very few architectures, so do not try to build it on all. We have a special MKSLJIT variable. It's enabled by default on the three arches you listed below but it can also be turned on on arm and mips. I copied the .if from src/sys/modules/Makefile - please feel free to fix both instances. But arm is missing machine/sljitarch.h, so it would not compile. Martin
Re: CVS commit: src/sys/rump/kern
Martin Husemann wrote: I copied the .if from src/sys/modules/Makefile - please feel free to fix both instances. But arm is missing machine/sljitarch.h, so it would not compile. I don't think that sljit supports all arms. If you want bpfjit on arm (or mips) you should build with MKSLJIT=yes. Default is no on these arches. Alex
Re: CVS commit: src/sys/rump/kern
On Sat, Nov 16, 2013 at 04:50:42PM +, Alexander Nasonov wrote: I don't think that sljit supports all arms. If you want bpfjit on arm (or mips) you should build with MKSLJIT=yes. Default is no on these arches. Yes, but with your suggested change (or my interpretation of it, at least), the build would fail on all arm with MKSLJIT=yes. Martin
Re: CVS commit: src/sys/rump/kern
Martin Husemann wrote: I copied the .if from src/sys/modules/Makefile - please feel free to fix both instances. But arm is missing machine/sljitarch.h, so it would not compile. I now see where the problem is. I listed those three arches because they support modules but other sljit arches don't always have modules. Is there a make variable to check whether modules are supported? Alex
Re: CVS commit: src/sys/rump
On Thu, Jul 04, 2013 at 10:14:04 +, Antti Kantee wrote:
Module Name: src
Committed By: pooka
Date: Thu Jul 4 10:14:04 UTC 2013
Modified Files:
src/sys/rump: Makefile.rump
Log Message:
Apparently warning flags are not kept in CWARNFLAGS. Compensate.
Would you care to elaborate? Do you refer to the fact that bsd.sys.mk
adds -Werror to CFLAGS instead of CWARNFLAGS?
CFLAGS+=${${_NOWERROR} == no :?-Werror:} ${CWARNFLAGS}
-uwe
Re: CVS commit: src/sys/rump
On 4.7.2013 14:53, Valery Ushakov wrote:
On Thu, Jul 04, 2013 at 10:14:04 +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Thu Jul 4 10:14:04 UTC 2013
Modified Files:
src/sys/rump: Makefile.rump
Log Message:
Apparently warning flags are not kept in CWARNFLAGS. Compensate.
Would you care to elaborate? Do you refer to the fact that bsd.sys.mk
adds -Werror to CFLAGS instead of CWARNFLAGS?
CFLAGS+=${${_NOWERROR} == no :?-Werror:} ${CWARNFLAGS}
That and this:
.if ${WARNS} 1
CFLAGS+=-Wreturn-type -Wswitch -Wshadow
.endif
.if ${WARNS} 2
CFLAGS+=-Wcast-qual -Wwrite-strings
CFLAGS+=-Wextra -Wno-unused-parameter
# Readd -Wno-sign-compare to override -Wextra with clang
CFLAGS+=-Wno-sign-compare
[...]
Re: CVS commit: src/sys/rump
On Thu, Jul 04, 2013 at 14:56:17 +0300, Antti Kantee wrote:
On 4.7.2013 14:53, Valery Ushakov wrote:
On Thu, Jul 04, 2013 at 10:14:04 +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Thu Jul 4 10:14:04 UTC 2013
Modified Files:
src/sys/rump: Makefile.rump
Log Message:
Apparently warning flags are not kept in CWARNFLAGS. Compensate.
Would you care to elaborate? Do you refer to the fact that bsd.sys.mk
adds -Werror to CFLAGS instead of CWARNFLAGS?
CFLAGS+= ${${_NOWERROR} == no :?-Werror:} ${CWARNFLAGS}
That and this:
.if ${WARNS} 1
CFLAGS+=-Wreturn-type -Wswitch -Wshadow
.endif
.if ${WARNS} 2
CFLAGS+=-Wcast-qual -Wwrite-strings
CFLAGS+=-Wextra -Wno-unused-parameter
# Readd -Wno-sign-compare to override -Wextra with clang
CFLAGS+=-Wno-sign-compare
[...]
Ah, I was confused because just before that I was staring at FreeBSD
bsd.sys.mk which does use CWARNFLAGS for -W* and then looked at
-Werror in ours.
History says:
revision 1.26
date: 1998-08-25 18:57:21 +0400; author: tv; state: Exp; lines: +3 -2;
Introduce CWARNFLAGS, idea from kernel Makefiles, which goes after -Wall
... in the CFLAGS and can be set in directory Makefile or mk.conf.
incidentally, the reason I was looking at FreeBSD bsd.sys.mk was
precisely that I needed to disable one of the warning options but they
append them to CWARNFLAGS overriding your settings instead.
-uwe
Re: CVS commit: src/sys/rump
On 4.7.2013 15:05, Valery Ushakov wrote: Ah, I was confused because just before that I was staring at FreeBSD bsd.sys.mk which does use CWARNFLAGS for -W* and then looked at -Werror in ours. History says: revision 1.26 date: 1998-08-25 18:57:21 +0400; author: tv; state: Exp; lines: +3 -2; Introduce CWARNFLAGS, idea from kernel Makefiles, which goes after -Wall ... in the CFLAGS and can be set in directory Makefile or mk.conf. incidentally, the reason I was looking at FreeBSD bsd.sys.mk was precisely that I needed to disable one of the warning options but they append them to CWARNFLAGS overriding your settings instead. I'll see your FreeBSD plight and raise with similar issues in autotools ;) Anyway, thanks for the info, makes sense.
Re: CVS commit: src/sys/rump/net/lib/libshmif
11.03.2011, 12:26, Antti Kantee po...@netbsd.org: Log Message: Don't assume rump kernel PAGE_SIZE and host page size are the same. Why can they be different? I asked myself this question when I was writing a tests for kern/44310: write to /dev/bpf truncates size_t to int. In the end, I just used sysconf(_SC_PAGE_SIZE). If rump_sysconf doesn't exist, should it be added? -- Alex
Re: CVS commit: src/sys/rump/net/lib/libshmif
On Fri Mar 11 2011 at 20:37:47 +0300, Alexander Nasonov wrote: 11.03.2011, 12:26, Antti Kantee po...@netbsd.org: Log Message: Don't assume rump kernel PAGE_SIZE and host page size are the same. Why can they be different? I asked myself this question when I was writing For example on SPARC page size depends on the model of hardware you're running on instead of being a compile-time constant (unless you configure your kernel only for a specific model). Now, since the rump kernel does not manage memory in the same sense as a regular kernel does, PAGE_SIZE is totally arbitrary. It's just some unit of granularity for calling the host's malloc() and remains constant throughout the life cycle of the kernel instance. It might as well be defined to be 32k or 1k on all archs, but that means waging war on the arch's headers, so it's just easier to play along with whatever we get. In the shmif initialization routine we are trying to fault in all of the *host's* pages for the bus file. We could add a rumpuser_getpagesize(), but since it makes really no difference if we do 512b or pagesize increments, at least the shmif case doesn't justify adding it. The commit didn't fix any bugs, but it's just more correct than going in PAGE_SIZE pieces. a tests for kern/44310: write to /dev/bpf truncates size_t to int. In the end, I just used sysconf(_SC_PAGE_SIZE). If rump_sysconf doesn't exist, should it be added? Since you are calling mmap() on the host, you want to use host's page size (although, i guess, technically it doesn't matter since you can't map less than one page of memory anyway). Technically you should be using the rump kernel's IOV_MAX, though, since you are passing that to rump_sys_writev(). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
re: CVS commit: src/sys/rump/net/lib/libshmif
11.03.2011, 12:26, Antti Kantee po...@netbsd.org: Log Message: Don't assume rump kernel PAGE_SIZE and host page size are the same. Why can they be different? I asked myself this question when I was writing some platforms don't have a well defined PAGE_SIZE, like sparc. on some machines it is 4KB, on others it is 8KB. this is the hardware (MMU), not something in software (though we could make everything appear to use 8KB i guess.) .mrg.
Re: CVS commit: src/sys/rump/librump/rumpvfs
On Tue, Nov 30, 2010 at 03:39:27PM +, Antti Kantee wrote: Modified Files: src/sys/rump/librump/rumpvfs: rump_vfs.c Log Message: fix broken rototill I did ask you if that was going to work, and you didn't answer. :-p (and the tests passed, and all componentname crap is going to disappear eventually so even if it only worked it wouldn't have been permanent.) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
On Sunday 21 November 2010 21:46:43 Antti Kantee wrote: Module Name: src Committed By: pooka Date: Sun Nov 21 21:46:43 UTC 2010 Modified Files: src/sys/rump/librump/rumpkern: Makefile.rumpkern Added Files: src/sys/rump/librump/rumpkern: atomic_cas_up.c Log Message: Add a lockless uniprocessor version of atomic_cas_generic.c, which is currently used by all the archs that previously used cas_generic. This break arm platform builds. /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S: Assembler messages: /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S:38: Error: bad instruction `ras_start_asm_hidden(_atomic_cas)' /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S:42: Error: bad instruction `ras_end_asm_hidden(_atomic_cas)' *** [atomic_cas_up.pico] Error code 1 Nick
Re: CVS commit: src/sys/rump/librump/rumpkern
On Monday 22 November 2010 10:51:03 Antti Kantee wrote: On Mon Nov 22 2010 at 10:35:00 +, Nick Hudson wrote: On Sunday 21 November 2010 21:46:43 Antti Kantee wrote: Module Name: src Committed By: pooka Date: Sun Nov 21 21:46:43 UTC 2010 Modified Files: src/sys/rump/librump/rumpkern: Makefile.rumpkern Added Files: src/sys/rump/librump/rumpkern: atomic_cas_up.c Log Message: Add a lockless uniprocessor version of atomic_cas_generic.c, which is currently used by all the archs that previously used cas_generic. This break arm platform builds. /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S: Assembler messages: /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S:38: Error: bad instruction `ras_start_asm_hidden(_atomic_cas)' /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S:42: Error: bad instruction `ras_end_asm_hidden(_atomic_cas)' *** [atomic_cas_up.pico] Error code 1 Fixed. I'll run a build just to make sure. Thanks for the quick response. Nick
Re: CVS commit: src/sys/rump/librump/rumpkern
Module Name:src Committed By: pooka Date: Wed Jun 23 08:36:03 UTC 2010 Modified Files: src/sys/rump/librump/rumpkern: emul.c Log Message: As normal, fix breakage from untested commits by rmind. Well, when I tried ./build.sh rumptest, it gave me this: --- dependall-dev --- WARNING: pseudo-root is an experimental feature /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:8: audiobus*: unknown device `audiobus' /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. *** [ioconf.c] Error code 1 1 error nbmake: stopped in /home/netbsd/src/sys/rump/dev/lib/libaudio *** [dependall-libaudio] Error code 2 1 error Can you elaborate why, and how to get it working? Other than rump, it was tested. -- Mindaugas
Re: CVS commit: src/sys/rump/librump/rumpkern
On Wed Jun 23 2010 at 12:39:17 +0100, Mindaugas Rasiukevicius wrote: Well, when I tried ./build.sh rumptest, it gave me this: --- dependall-dev --- WARNING: pseudo-root is an experimental feature /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:8: audiobus*: unknown device `audiobus' /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. *** [ioconf.c] Error code 1 1 error nbmake: stopped in /home/netbsd/src/sys/rump/dev/lib/libaudio *** [dependall-libaudio] Error code 2 1 error Can you elaborate why, and how to get it working? I suspect your config(1) is too old and config should whine about it. At least my nb5 config displays the appropriate error for -current sources: WARNING: ioconf is an experimental feature /sys/conf/files:4: your sources require a newer version of config(1) -- please rebuild it. /sys/conf/majors:12: syntax error /sys/conf/majors:13: syntax error /sys/conf/majors:15: syntax error /sys/conf/majors:18: syntax error /sys/conf/majors:19: syntax error /sys/conf/majors:21: syntax error /sys/conf/majors:25: syntax error /sys/conf/majors:26: syntax error /sys/conf/majors:27: syntax error /sys/conf/majors:28: syntax error /sys/conf/majors:29: syntax error /sys/conf/majors:30: syntax error /sys/conf/majors:33: syntax error /sys/conf/majors:37: syntax error /sys/conf/majors:41: syntax error /sys/conf/majors:43: syntax error WARNING: pseudo-root is an experimental feature AUDIO.ioconf:8: audiobus*: unknown device `audiobus' AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. Guessing from the log you pasted and that the bottom matches my too-old config's error reportable, you were bit by -j output and did not see the real error message. Try upgrading your tools and if the problem persists, let me know. Other than rump, it was tested. The point was more that you did not make an effort to run the regression test suite. (anyway, it's done now, and the commits come out clean. thanks for the features)
Re: CVS commit: src/sys/rump/librump/rumpkern
On Tue, Jun 15, 2010 at 04:40:24PM +1000, matthew green wrote: On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Arguably we shouhld fix our gcc to only define __i386__, not i386, which conflicts with the user namespace... i agree. i was going to reply to an earlier message on this that it was the kernel Makefile's that define $MACHINE, but upon looking at them i noticed that only a few do, and that i486--netbsdelf-gcc defines i386 all the time so i didn't send any email. we should audit all of our gcc configs and kernel configs to deal. Yes, I agree, too. Quite some time ago, we stopped defining unix, which mainly caused issues in pkgsrc and not in src, but nothing we couldn't overcome given time and bulk builds. Now's not the time, though, please leave it 2 weeks :-) Best, Alistair
re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Arguably we shouhld fix our gcc to only define __i386__, not i386, which conflicts with the user namespace... i agree. i was going to reply to an earlier message on this that it was the kernel Makefile's that define $MACHINE, but upon looking at them i noticed that only a few do, and that i486--netbsdelf-gcc defines i386 all the time so i didn't send any email. we should audit all of our gcc configs and kernel configs to deal. .mrg.
Re: CVS commit: src/sys/rump/librump/rumpkern
On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: Fix previous in emul.c -- only numbers are operands for cpp comparisons. Apparently non-numbers logically produce arch-dependent behaviour. Not at all. C99 6.10.1 #4: [...] After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. [...] -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote: On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: Fix previous in emul.c -- only numbers are operands for cpp comparisons. Apparently non-numbers logically produce arch-dependent behaviour. Not at all. C99 6.10.1 #4: [...] After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. [...] So, you being the person who attempted to write cpp with sed, what comparison does amd64 == sun3 actually result in? What about i386 == sun3 (the former returned true, the latter didn't).
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: So, you being the person who attempted to write cpp with sed, what comparison does amd64 == sun3 actually result in? What about i386 == sun3 (the former returned true, the latter didn't). For me both end up as 0==0 and return true ;-) Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: So, you being the person who attempted to write cpp with sed, what comparison does amd64 == sun3 actually result in? What about i386 == sun3 (the former returned true, the latter didn't). What were you compiling on? Whether it should or not, our i386 gcc predefines i386, so you probably got 0 == 0 and 1 == 0 respectively. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 11:13:23 +0200, Martin Husemann wrote: On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: So, you being the person who attempted to write cpp with sed, what comparison does amd64 == sun3 actually result in? What about i386 == sun3 (the former returned true, the latter didn't). For me both end up as 0==0 and return true ;-) How can you tell what they end up as? I can only see that the line wrapped in the #if is missing from output of cc -E (still on/targetting i386).
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon Jun 14 2010 at 09:17:43 +, David Holland wrote: On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote: So, you being the person who attempted to write cpp with sed, what comparison does amd64 == sun3 actually result in? What about i386 == sun3 (the former returned true, the latter didn't). What were you compiling on? Whether it should or not, our i386 gcc predefines i386, so you probably got 0 == 0 and 1 == 0 respectively. Ah, ok, now I see what happened. thanks
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 12:27:43PM +0300, Antti Kantee wrote: How can you tell what they end up as? I can only see that the line wrapped in the #if is missing from output of cc -E (still on/targetting i386). Well, knowing the standard (as David cited) and checking with cc -dM -E - /dev/null what is defined on your arch you can make an educated guess. But sure, you can't realy tell whether someone did a #define sun3 1 somewhere in the code. Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: 20100614083424.gc16...@cs.hut.fi Antti Kantee po...@cs.hut.fi writes: : On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote: : On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote: :Fix previous in emul.c -- only numbers are operands for cpp comparisons. :Apparently non-numbers logically produce arch-dependent behaviour. : : Not at all. : : C99 6.10.1 #4: : :[...] After all replacements due to macro expansion and the defined :unary operator have been performed, all remaining identifiers :(including those lexically identical to keywords) are replaced with :the pp-number 0, and then each preprocessing token is converted into :a token. The resulting tokens compose the controlling constant :expression which is evaluated according to the rules of 6.6. [...] : : So, you being the person who attempted to write cpp with sed, what : comparison does amd64 == sun3 actually result in? What about : i386 == sun3 (the former returned true, the latter didn't). On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: On i386, that's true. amd64 expands to '0', as does sun3. This makes the first one true. The second one, i386 expands to '1', so the second one would be false. Arguably we shouhld fix our gcc to only define __i386__, not i386, which conflicts with the user namespace... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
In message: 20100615052154.gb16...@netbsd.org David Holland dholland-sourcechan...@netbsd.org writes: : On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote: : On i386, that's true. amd64 expands to '0', as does sun3. This makes : the first one true. The second one, i386 expands to '1', so the : second one would be false. : : Arguably we shouhld fix our gcc to only define __i386__, not i386, : which conflicts with the user namespace... True, but doing so would likely break applications that have depended on this define. Which is worse? Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
On Tue, May 18, 2010 at 04:29:36PM +, Antti Kantee wrote: It's pretty obvious that in terms of scalability simple workload partitioning and replication into multiple kernels wins hands down over complicated locking or locklessing algorithms which depend on globally atomic state. ...in other breaking news, the sky is blue. :-p :-) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
On Thu May 20 2010 at 02:47:16 +, David Holland wrote:
On Tue, May 18, 2010 at 04:29:36PM +, Antti Kantee wrote:
It's pretty obvious that in terms of scalability simple workload
partitioning and replication into multiple kernels wins hands down
over complicated locking or locklessing algorithms which depend on
globally atomic state.
...in other breaking news, the sky is blue.
Yet it is not possible everywhere to observe the sky being blue due to
various layers of unnecessary crap.
:-p :-)
?:-% ('\/)
Re: CVS commit: src/sys/rump
On Wed, Apr 14, 2010 at 07:04:27PM +, Christos Zoulas wrote: Use struct kauth_cred * instead of kauth_cred_t in all exported interfaces. Allows to remove hairbrained _t typedef dance. Not that I have a problem with it, but the whole point of kauth_cred_t was to provide opacity on struct kauth_cred, and people were really pushing to never expose struct kauth_cred. typedefs don't provide opacity. but we've been over this ground many times before... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump
In article 20100414141248.b227217...@cvs.netbsd.org, Antti Kantee source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By: pooka Date: Wed Apr 14 14:12:48 UTC 2010 Modified Files: src/sys/rump/include/rump: rump.h src/sys/rump/librump/rumpkern: rumpkern.ifspec src/sys/rump/librump/rumpvfs: rumpvfs.ifspec Log Message: Use struct kauth_cred * instead of kauth_cred_t in all exported interfaces. Allows to remove hairbrained _t typedef dance. Not that I have a problem with it, but the whole point of kauth_cred_t was to provide opacity on struct kauth_cred, and people were really pushing to never expose struct kauth_cred. christos
Re: CVS commit: src/sys/rump
On Wed Apr 14 2010 at 19:04:27 +, Christos Zoulas wrote: In article 20100414141248.b227217...@cvs.netbsd.org, Antti Kantee source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By:pooka Date:Wed Apr 14 14:12:48 UTC 2010 Modified Files: src/sys/rump/include/rump: rump.h src/sys/rump/librump/rumpkern: rumpkern.ifspec src/sys/rump/librump/rumpvfs: rumpvfs.ifspec Log Message: Use struct kauth_cred * instead of kauth_cred_t in all exported interfaces. Allows to remove hairbrained _t typedef dance. Not that I have a problem with it, but the whole point of kauth_cred_t was to provide opacity on struct kauth_cred, and people were really pushing to never expose struct kauth_cred. I'm pretty sure that assumes that kernel interfaces are not exposed to userspace for non-NetBSD operating systems. different rules, different game ;) Think of them (exported struct kauth * and internal kauth_cred_t) as different types which just happen to have, at least now, a very simple conversion function... and actually they are. it's just that in C typedefs don't mean anything.
Re: CVS commit: src/sys/rump/librump/rumpkern
David Laight wrote: Module Name: src Committed By: dsl Date: Sat Nov 7 12:08:35 UTC 2009 Modified Files: src/sys/rump/librump/rumpkern: pmap_stub.c Log Message: Fix stub prototype Doh! rump is not build as part of any kernel. Hence gcc didn't catch it. Thanks for fixing. Christoph
re: CVS commit: src/sys/rump/librump/rumpkern
David Laight wrote: Module Name: src Committed By: dsl Date: Sat Nov 7 12:08:35 UTC 2009 Modified Files: src/sys/rump/librump/rumpkern: pmap_stub.c Log Message: Fix stub prototype Doh! rump is not build as part of any kernel. Hence gcc didn't catch it. Thanks for fixing. when you make a big change like your pmap change you should *ALWAYS* full release before checking in. just one platform would be sufficient. .mrg.
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/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/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/rump
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__. .mrg.
Re: CVS commit: src/sys/rump
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.
