re: CVS commit: src/sys/arch

2017-12-02 Thread matthew green
> > 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

2017-12-02 Thread Valery Ushakov
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

2017-12-02 Thread David Holland
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

2017-12-02 Thread Christos Zoulas
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

2017-12-02 Thread Kamil Rytarowski
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

2017-12-02 Thread David Holland
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

2017-12-02 Thread Maxime Villard

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

2017-12-02 Thread Maxime Villard

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

2017-12-02 Thread David Holland
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

2017-12-02 Thread Jonathan A. Kollasch
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

2017-12-02 Thread Maxime Villard

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

2017-12-02 Thread Maxime Villard

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

2017-12-02 Thread Kamil Rytarowski
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

2017-12-02 Thread Christos Zoulas
In article <19b5c128-7725-0638-67f8-749532353...@m00nbsd.net>,
Maxime Villard   wrote:
>
>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

2017-12-02 Thread Kamil Rytarowski
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

2017-12-02 Thread Maxime Villard

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