re: CVS commit: src/sys/arch
> > You alone do not have sufficient authority to do this. > > I maintain amd64. this is 100% false. dsl@ is the amd64 maintainer. you're just the latest person to work on it heavily. .mrg.
Re: CVS commit: src
On Sun, Dec 03, 2017 at 02:22:10 +, David Holland wrote: > On Wed, Oct 04, 2017 at 07:54:33PM -0400, Christos Zoulas wrote: > > Log Message: > > Add NOBINARIES, useful to build tools are libraries which is what's needed > > for mknative. > > Wouldn't it make more sense for this to be a build target than a > setting (as in, say, "build.sh libs")? That would be my stylistic preference too. I used that to get a cross toolchain which I was using to compile j2me for netbsd/arm http://www.stderr.spb.ru/~uwe/netbsd/cross.html We might want to add in-tree x11 includes/libs into the mix. E.g. when qt-embedded was still a separate project, the resulting toolchain+destdir would be suitable for cross compiling it. I think we should promote this and make it easy for people. Someone might want to make a package too :) -uwe
Re: CVS commit: src
On Wed, Oct 04, 2017 at 07:54:33PM -0400, Christos Zoulas wrote: > Log Message: > Add NOBINARIES, useful to build tools are libraries which is what's needed > for mknative. Wouldn't it make more sense for this to be a build target than a setting (as in, say, "build.sh libs")? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch
In article, Kamil Rytarowski wrote: > >For the record, we were fixing 0.9 compat in HEAD at least in May 2017, >after the breakage from vm.user_va0_disable. (I recall commits fixing >syscalls that were introduced later). > >http://gnats.netbsd.org/52246 > >It used to work on a NetBSD-7.99.71/amd64 kernel with NetBSD-0.9/i386 >a.out executables. > >I still want to use this software as reference, but I will ask core@ >what to do. And it still works in current after I undid the commits: [8:48pm] 2507>./lisp Franz Lisp, Opus 38.92 -> ^D Goodbye [8:48pm] 2508>uname -a NetBSD mb1.astron.com 8.99.8 NetBSD 8.99.8 (GENERIC) #154: Sat Dec 2 20:40:18 EST 2017 chris...@mb1.astron.com:/usr/src/sys/arch/amd64/compile/GENERIC amd64 [8:48pm] 2509> [8:48pm] 2509>file lisp lisp: a.out little-endian 32-bit demand paged pure executable not stripped [8:48pm] 2510> I am inclined to put it back, but I will ask core@ first. christos
Re: CVS commit: src/sys/arch
On 02.12.2017 22:23, David Holland wrote: > On Sat, Dec 02, 2017 at 10:04:26PM +0100, Maxime Villard wrote: > > > Revert this. Compat on amd64 must be available all the way back to > > > 0.9, same as i386. > > > > > > Also, please stop unilaterally breaking the world. > > > > You are kidding, right? Everything below COMPAT_15 has *never* been > > enabled. This change does not break anything, since nothing was > > enabled in the first. > > No, I am not kidding. It is there in GENERIC so it can be enabled for > people who want to run very old i386 binaries. > > > "Compat on amd64 must be available" > > > > What authority do you have to say that? It has never been this way. > > Providing compat has been policy for 25+ years. > > Since you bring up the notion of authority... what authority do you > think you have to make declarations about what will and won't be > removed? > For the record, we were fixing 0.9 compat in HEAD at least in May 2017, after the breakage from vm.user_va0_disable. (I recall commits fixing syscalls that were introduced later). http://gnats.netbsd.org/52246 It used to work on a NetBSD-7.99.71/amd64 kernel with NetBSD-0.9/i386 a.out executables. I still want to use this software as reference, but I will ask core@ what to do. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/arch
On Sat, Dec 02, 2017 at 10:04:26PM +0100, Maxime Villard wrote: > > Revert this. Compat on amd64 must be available all the way back to > > 0.9, same as i386. > > > > Also, please stop unilaterally breaking the world. > > You are kidding, right? Everything below COMPAT_15 has *never* been > enabled. This change does not break anything, since nothing was > enabled in the first. No, I am not kidding. It is there in GENERIC so it can be enabled for people who want to run very old i386 binaries. > "Compat on amd64 must be available" > > What authority do you have to say that? It has never been this way. Providing compat has been policy for 25+ years. Since you bring up the notion of authority... what authority do you think you have to make declarations about what will and won't be removed? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch
On Sat, Dec 02, 2017 at 01:03:15PM +, Maxime Villard wrote: > Modified Files: > src/sys/arch/amd64/conf: GENERIC files.amd64 > src/sys/arch/xen/conf: files.xen > Removed Files: > src/sys/arch/amd64/amd64: compat_13_machdep.c > > Log Message: > Drop COMPAT_13 on amd64, already not enabled. Reduces the number of > critical places. Revert this. Compat on amd64 must be available all the way back to 0.9, same as i386. Also, please stop unilaterally breaking the world. You are kidding, right? Everything below COMPAT_15 has *never* been enabled. This change does not break anything, since nothing was enabled in the first. "Compat on amd64 must be available" What authority do you have to say that? It has never been this way. Maxime
Re: CVS commit: src/sys/arch
Le 02/12/2017 à 21:26, Jonathan A. Kollasch a écrit : On Sat, Dec 02, 2017 at 05:45:08PM +0100, Maxime Villard wrote: Le 02/12/2017 à 17:33, Kamil Rytarowski a écrit : OK, I will prompt about it myself. Just to clarify. The < compat_20 options *will* be dropped on amd64. What authority do you have to decree this? You alone do not have sufficient authority to do this. I maintain amd64. If you meant to drop everything below compat_20 in all our supported architectures in general, then ask if you want. No, he did not mean that. I'm not asking you what he meant, I'm asking *him* what he meant. Please stop insinuating we meant things we obviously did not mean. We? I'm responding to him, not you. This attitude and behavior is not acceptable. Maxime
Re: CVS commit: src/sys/arch
On Sat, Dec 02, 2017 at 01:03:15PM +, Maxime Villard wrote: > Modified Files: > src/sys/arch/amd64/conf: GENERIC files.amd64 > src/sys/arch/xen/conf: files.xen > Removed Files: > src/sys/arch/amd64/amd64: compat_13_machdep.c > > Log Message: > Drop COMPAT_13 on amd64, already not enabled. Reduces the number of > critical places. Revert this. Compat on amd64 must be available all the way back to 0.9, same as i386. Also, please stop unilaterally breaking the world. This is getting to be a regular occurrence and that is not the way things are supposed to be done in this project. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch
On Sat, Dec 02, 2017 at 05:45:08PM +0100, Maxime Villard wrote: > Le 02/12/2017 à 17:33, Kamil Rytarowski a écrit : > >OK, I will prompt about it myself. > > Just to clarify. The < compat_20 options *will* be dropped on amd64. What authority do you have to decree this? You alone do not have sufficient authority to do this. > If you > meant to drop everything below compat_20 in all our supported architectures in > general, then ask if you want. No, he did not mean that. Please stop insinuating we meant things we obviously did not mean. This attitude and behavior is not acceptable. Jonathan Kollasch
Re: CVS commit: src/sys/arch
Le 02/12/2017 à 17:33, Kamil Rytarowski a écrit : OK, I will prompt about it myself. Just to clarify. The < compat_20 options *will* be dropped on amd64. If you meant to drop everything below compat_20 in all our supported architectures in general, then ask if you want.
Re: CVS commit: src/sys/arch
Le 02/12/2017 à 14:22, Kamil Rytarowski a écrit : There are still users of NetBSD/i386 0.9 executables (like myself - of Franz Lisp). And? compat_09 is available on i386. It's reasonable to drop compat for pre-ELF (approximately < 2.0) ... Yes, amd64 needs to start from compat_20. But compat_20 does not compile: if you include compat_netbsd20.config in GENERIC, you get "multiple definition of _KERNEL_OPT_COMPAT_15 _KERNEL_OPT_COMPAT_16 etc". However, the current compat_netbsd15.config inclusion works, even though compat_15 enables compat_20. So it looks like there is something going wrong in the dependencies. It wouldn't be a big surprise, since no one has ever tested that. ... but it should be discussed and decided by core. No. I am not going to discuss basic changes like this one all the time. (And I am not mentioning here that in each of the two times I asked core@ to decide on what to do, they were unable to formulate a single answer after months, not recognizing the rules they had themselves stated when these were to be enforced. Fool me again.) Maxime
Re: CVS commit: src/sys/arch
On 02.12.2017 16:55, Maxime Villard wrote: > Le 02/12/2017 à 14:22, Kamil Rytarowski a écrit : >> There are still users of NetBSD/i386 0.9 executables (like myself - of >> Franz Lisp). > > And? compat_09 is available on i386. > It used to work on the NetBSD/amd64 kernel. >> It's reasonable to drop compat for pre-ELF (approximately < 2.0) ... > > Yes, amd64 needs to start from compat_20. But compat_20 does not > compile: if > you include compat_netbsd20.config in GENERIC, you get "multiple definition > of _KERNEL_OPT_COMPAT_15 _KERNEL_OPT_COMPAT_16 etc". > > However, the current compat_netbsd15.config inclusion works, even though > compat_15 enables compat_20. > > So it looks like there is something going wrong in the dependencies. It > wouldn't be a big surprise, since no one has ever tested that. > < 2.0 compat is rotten on all levels. >> ... but it should be discussed and decided by core. > > No. I am not going to discuss basic changes like this one all the time. > (And > I am not mentioning here that in each of the two times I asked core@ to > decide on what to do, they were unable to formulate a single answer after > months, not recognizing the rules they had themselves stated when these > were > to be enforced. Fool me again.) > > Maxime OK, I will prompt about it myself. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/compat
In article <19b5c128-7725-0638-67f8-749532353...@m00nbsd.net>, Maxime Villardwrote: > >So is making the system vulnerable by default with marginal features. The >system is broken now. All you had to do is one sysctl; but that takes too much >time, and you're probably too busy handling serious business like debating >about your favorite hitler quotes. The problem is that nothing is black and white: 1. You probably don't use the feature most of the time, others might. [this determines how marginal the feature is] 2. How critical are the bugs, how easy it is to find them all? For example, are there similar bugs in other places in the system; do we disable those parts? [security vs usability] Here you unilateraly made a decision to disable a feature that was previously enabled. Regardless if the decision was correct or incorrect, you made a determination based on your assessment and affected not only yourself, but everyone else using the system. Such decisions should be made by consensus not by force. It is a different story if there was a critical bug that could not be fixed, so the feature had to be disabled for safety. Here we are talking about a feature that was enabled for a long time, and was disabled without enough prior discussion. I understand we perhaps are not moving fast enough or making decisions fast enough, but process needs to be followed otherwise everyone is unhappy with the results. christos
Re: CVS commit: src/sys/arch
On 02.12.2017 14:03, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sat Dec 2 13:03:15 UTC 2017 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC files.amd64 > src/sys/arch/xen/conf: files.xen > Removed Files: > src/sys/arch/amd64/amd64: compat_13_machdep.c > > Log Message: > Drop COMPAT_13 on amd64, already not enabled. Reduces the number of > critical places. > > > To generate a diff of this commit: > cvs rdiff -u -r1.1 -r0 src/sys/arch/amd64/amd64/compat_13_machdep.c > cvs rdiff -u -r1.470 -r1.471 src/sys/arch/amd64/conf/GENERIC > cvs rdiff -u -r1.94 -r1.95 src/sys/arch/amd64/conf/files.amd64 > cvs rdiff -u -r1.163 -r1.164 src/sys/arch/xen/conf/files.xen > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > > > Modified files: > > Index: src/sys/arch/amd64/conf/GENERIC > diff -u src/sys/arch/amd64/conf/GENERIC:1.470 > src/sys/arch/amd64/conf/GENERIC:1.471 > --- src/sys/arch/amd64/conf/GENERIC:1.470 Sat Dec 2 12:40:03 2017 > +++ src/sys/arch/amd64/conf/GENERIC Sat Dec 2 13:03:15 2017 > @@ -1,4 +1,4 @@ > -# $NetBSD: GENERIC,v 1.470 2017/12/02 12:40:03 maxv Exp $ > +# $NetBSD: GENERIC,v 1.471 2017/12/02 13:03:15 maxv Exp $ > # > # GENERIC machine description file > # > @@ -22,7 +22,7 @@ include "arch/amd64/conf/std.amd64" > > options INCLUDE_CONFIG_FILE # embed config file in kernel binary > > -#ident "GENERIC-$Revision: 1.470 $" > +#ident "GENERIC-$Revision: 1.471 $" > > maxusers 64 # estimated number of users > > @@ -117,7 +117,7 @@ options KDTRACE_HOOKS # kernel DTrace h > # Compatibility options > #options EXEC_AOUT # required by binaries from before 1.5 > > -# NetBSD backward compatibility. Support goes from COMPAT_11 up until > +# NetBSD backward compatibility. Support goes from COMPAT_15 up until > # the latest release. Note that really old compat (< COMPAT_16) is only > # useful for 32-bit binaries. > include "conf/compat_netbsd15.config" > > Index: src/sys/arch/amd64/conf/files.amd64 > diff -u src/sys/arch/amd64/conf/files.amd64:1.94 > src/sys/arch/amd64/conf/files.amd64:1.95 > --- src/sys/arch/amd64/conf/files.amd64:1.94 Sun Oct 8 09:06:50 2017 > +++ src/sys/arch/amd64/conf/files.amd64 Sat Dec 2 13:03:15 2017 > @@ -1,4 +1,4 @@ > -#$NetBSD: files.amd64,v 1.94 2017/10/08 09:06:50 maxv Exp $ > +#$NetBSD: files.amd64,v 1.95 2017/12/02 13:03:15 maxv Exp $ > # > # new style config file for amd64 architecture > # > @@ -136,7 +136,6 @@ attachfd at fdc > # Compatibility modules > # > # Binary compatibility with previous NetBSD releases (COMPAT_XX) > -file arch/amd64/amd64/compat_13_machdep.ccompat_13 > file arch/amd64/amd64/compat_16_machdep.ccompat_16 > > # NetBSD/i386 32-bit binary compatibility (COMPAT_NETBSD32) > > Index: src/sys/arch/xen/conf/files.xen > diff -u src/sys/arch/xen/conf/files.xen:1.163 > src/sys/arch/xen/conf/files.xen:1.164 > --- src/sys/arch/xen/conf/files.xen:1.163 Mon Nov 6 15:21:23 2017 > +++ src/sys/arch/xen/conf/files.xen Sat Dec 2 13:03:15 2017 > @@ -1,4 +1,4 @@ > -#$NetBSD: files.xen,v 1.163 2017/11/06 15:21:23 cherry Exp $ > +#$NetBSD: files.xen,v 1.164 2017/12/02 13:03:15 maxv Exp $ > #NetBSD: files.x86,v 1.10 2003/10/08 17:30:00 bouyer Exp > #NetBSD: files.i386,v 1.254 2004/03/25 23:32:10 jmc Exp > > @@ -330,7 +330,6 @@ include "compat/freebsd/files.freebsd" > elifdef amd64 > > # Binary compatibility with previous NetBSD releases (COMPAT_XX) > -file arch/amd64/amd64/compat_13_machdep.ccompat_13 > file arch/amd64/amd64/compat_16_machdep.ccompat_16 > > # NetBSD/i386 32-bit binary compatibility (COMPAT_NETBSD32) > There are still users of NetBSD/i386 0.9 executables (like myself - of Franz Lisp). It's reasonable to drop compat for pre-ELF (approximately < 2.0) as we can use emulators, but it should be discussed and decided by core. pkgsrc for early compat distributions (emulators/compat12, 13, 14) never worked well for me and I had to build them manually. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/compat
Le 02/12/2017 à 02:27, Joerg Sonnenberger a écrit : On Fri, Dec 01, 2017 at 11:32:08PM +0100, Maxime Villard wrote: Le 01/12/2017 à 23:14, Joerg Sonnenberger a écrit : Module Name:src Committed By: joerg Date: Fri Dec 1 22:14:52 UTC 2017 Modified Files: src/sys/compat/linux/common: linux_mod.c src/sys/compat/linux32/common: linux32_mod.c Log Message: Unbreak Linux emulation by default. While not loading it automatically is somewhat sensible, breaking functionality of GENERIC is not and has been objected to on a regular base. To generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/sys/compat/linux/common/linux_mod.c cvs rdiff -u -r1.8 -r1.9 src/sys/compat/linux32/common/linux32_mod.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. tell us what is "broken", exactly Every Linux binary failing by default is the very definition of broken. So is making the system vulnerable by default with marginal features. The system is broken now. All you had to do is one sysctl; but that takes too much time, and you're probably too busy handling serious business like debating about your favorite hitler quotes. Bye, Maxime