Searched hist:1.229 (Results 1 - 25 of 214) sorted by relevance

123456789

/src/tests/usr.bin/xlint/lint1/
H A Dinit_braces.c1.5 Fri Jun 30 21:06:18 GMT 2023 rillig lint: fix handling of unnamed struct/union members

The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.

Real-life examples for code that lint couldn't handle are:

* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile

H A Dmsg_102.c1.6 Fri Jun 30 21:06:18 GMT 2023 rillig branches: 1.6.2;
lint: fix handling of unnamed struct/union members

The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.

Real-life examples for code that lint couldn't handle are:

* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile

H A Dexpr_sizeof.c1.12 Fri Jun 30 21:06:18 GMT 2023 rillig lint: fix handling of unnamed struct/union members

The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.

Real-life examples for code that lint couldn't handle are:

* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile

/src/sys/ufs/lfs/
H A Dulfsmount.h1.18 Mon Jun 20 03:36:09 GMT 2016 dholland One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs
H A Dlfs_rename.c1.21 Mon Jun 20 03:36:09 GMT 2016 dholland branches: 1.21.10;
One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs

H A Dulfs_extern.h1.24 Mon Jun 20 03:36:09 GMT 2016 dholland branches: 1.24.18; 1.24.24;
One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs
H A Dulfs_readwrite.c1.22 Mon Jun 20 03:36:09 GMT 2016 dholland branches: 1.22.2; 1.22.4;
One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs
H A Dulfs_inode.c1.15 Mon Jun 20 03:36:09 GMT 2016 dholland branches: 1.15.2;
One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs

H A Dulfs_vnops.c1.44 Mon Jun 20 03:36:09 GMT 2016 dholland branches: 1.44.2; 1.44.4;
One more batch of already-synced ufs changes:

ufs_extern.h 1.79 is equivalent to ulfs_extern.h 1.14
ufsmount.h 1.43 is (roughly) equivalent to lfs_extern.h 1.102
ufs_inode.c 1.94 does not apply to lfs
ufs_inode.c 1.95 does not apply to lfs either
ufs_readwrite.c 1.108 is equivalent to ulfs_readwrite.c 1.8
ufs_readwrite.c 1.109 is equivalent to ulfs_readwrite.c 1.9
ufs_readwrite.c 1.110 is equivalent to ulfs_readwrite.c 1.10
ufs_readwrite.c 1.111 does not apply to lfs
ufs_readwrite.c 1.112 is equivalent to ulfs_readwrite.c 1.11
ufs_readwrite.c 1.113 is equivalent to ulfs_readwrite.c 1.13
ufs_readwrite.c 1.114 is equivalent to ulfs_readwrite.c 1.14
ufs_readwrite.c 1.115 is equivalent to ulfs_readwrite.c 1.15
ufs_readwrite.c 1.116-1.118 does not apply to lfs
ufs_readwrite.c 1.119-1.120 are equivalent to ulfs_readwrite.c 1.16
ufs_rename.c 1.12 is equivalent to lfs_rename.c 1.8
ufs_vnops.c 1.226 is equivalent to ulfs_vnops.c 1.22 and lfs_vnops.c 1.270
ufs_vnops.c 1.227 is equivalent to ulfs_vnops.c 1.23
ufs_vnops.c 1.228-1.229 are equivalent to ulfs_vnops.c 1.24
ufs_vnops.c 1.230 is equivalent to ulfs_vnops.c 1.25 and lfs_vnops.c 1.271
ufs_vnops.c 1.231 originated in lfs
ufs_vnops.c 1.232 does not apply to lfs

/src/sys/arch/hp300/hp300/
H A Dmachdep.c1.229 Sun Apr 20 04:12:54 GMT 2014 tsutsui branches: 1.229.8; 1.229.18; 1.229.20; 1.229.28;
Add proper consinit(9) support for sti(4) at sgc framebuffer on hp300.

The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.

Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.

Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).

XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...

1.229 Sun Apr 20 04:12:54 GMT 2014 tsutsui branches: 1.229.8; 1.229.18; 1.229.20; 1.229.28;
Add proper consinit(9) support for sti(4) at sgc framebuffer on hp300.

The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.

Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.

Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).

XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...

1.229 Sun Apr 20 04:12:54 GMT 2014 tsutsui branches: 1.229.8; 1.229.18; 1.229.20; 1.229.28;
Add proper consinit(9) support for sti(4) at sgc framebuffer on hp300.

The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.

Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.

Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).

XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...

1.229 Sun Apr 20 04:12:54 GMT 2014 tsutsui branches: 1.229.8; 1.229.18; 1.229.20; 1.229.28;
Add proper consinit(9) support for sti(4) at sgc framebuffer on hp300.

The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.

Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.

Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).

XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...

1.229 Sun Apr 20 04:12:54 GMT 2014 tsutsui branches: 1.229.8; 1.229.18; 1.229.20; 1.229.28;
Add proper consinit(9) support for sti(4) at sgc framebuffer on hp300.

The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.

Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.

Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).

XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...

/src/sys/kern/
H A Dinit_sysent.c1.229 Thu Oct 16 20:12:23 GMT 2008 wrstuden branches: 1.229.2; 1.229.4; 1.229.8;
Regen syscall tables. I forgot to do it after revivesa. While pooka
did some, not all are regenerated. Do them all at once for consistency.

1.229 Thu Oct 16 20:12:23 GMT 2008 wrstuden branches: 1.229.2; 1.229.4; 1.229.8;
Regen syscall tables. I forgot to do it after revivesa. While pooka
did some, not all are regenerated. Do them all at once for consistency.

1.229 Thu Oct 16 20:12:23 GMT 2008 wrstuden branches: 1.229.2; 1.229.4; 1.229.8;
Regen syscall tables. I forgot to do it after revivesa. While pooka
did some, not all are regenerated. Do them all at once for consistency.

1.229 Thu Oct 16 20:12:23 GMT 2008 wrstuden branches: 1.229.2; 1.229.4; 1.229.8;
Regen syscall tables. I forgot to do it after revivesa. While pooka
did some, not all are regenerated. Do them all at once for consistency.

H A Dkern_sysctl.c1.229 Sun Apr 11 01:50:25 GMT 2010 mrg branches: 1.229.2; 1.229.4;
reject attempts to write CTLTYPE_BOOL nodes with a value other than 0 or 1.
1.229 Sun Apr 11 01:50:25 GMT 2010 mrg branches: 1.229.2; 1.229.4;
reject attempts to write CTLTYPE_BOOL nodes with a value other than 0 or 1.
1.229 Sun Apr 11 01:50:25 GMT 2010 mrg branches: 1.229.2; 1.229.4;
reject attempts to write CTLTYPE_BOOL nodes with a value other than 0 or 1.
H A Dsyscalls.c1.229 Tue Jan 13 22:33:17 GMT 2009 pooka branches: 1.229.2;
Regen to prove I didn't screw up the conversion: purely RCSID changes.

1.229 Tue Jan 13 22:33:17 GMT 2009 pooka branches: 1.229.2;
Regen to prove I didn't screw up the conversion: purely RCSID changes.

H A Dkern_descrip.c1.229 Mon Aug 03 04:55:15 GMT 2015 christos branches: 1.229.8;
1. mask fflags so we don't tack on whateve oflags were passed from userland
2. honor O_CLOEXEC, so the children of daemons that use cloning devices, don't
end up with the parents descriptors
fd_clone and in general the fd approach of 'allocate' > 'play with guts' >
'attach' should be converted to be more constructor like.
XXX: pullup-{6,7}

1.229 Mon Aug 03 04:55:15 GMT 2015 christos branches: 1.229.8;
1. mask fflags so we don't tack on whateve oflags were passed from userland
2. honor O_CLOEXEC, so the children of daemons that use cloning devices, don't
end up with the parents descriptors
fd_clone and in general the fd approach of 'allocate' > 'play with guts' >
'attach' should be converted to be more constructor like.
XXX: pullup-{6,7}

/src/sys/arch/sparc/sparc/
H A Dautoconf.c1.229 Thu Jul 17 14:39:26 GMT 2008 cegger branches: 1.229.2; 1.229.4; 1.229.8;
devive_private -> device_private

1.229 Thu Jul 17 14:39:26 GMT 2008 cegger branches: 1.229.2; 1.229.4; 1.229.8;
devive_private -> device_private

1.229 Thu Jul 17 14:39:26 GMT 2008 cegger branches: 1.229.2; 1.229.4; 1.229.8;
devive_private -> device_private

1.229 Thu Jul 17 14:39:26 GMT 2008 cegger branches: 1.229.2; 1.229.4; 1.229.8;
devive_private -> device_private

/src/usr.bin/
H A DMakefile1.229 Sun May 21 15:28:42 GMT 2017 riastradh branches: 1.229.4; 1.229.8; 1.229.10;
Remove MKCRYPTO option.

Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.

In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.

The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.

My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.

As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:

https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html

P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.

1.229 Sun May 21 15:28:42 GMT 2017 riastradh branches: 1.229.4; 1.229.8; 1.229.10;
Remove MKCRYPTO option.

Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.

In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.

The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.

My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.

As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:

https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html

P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.

1.229 Sun May 21 15:28:42 GMT 2017 riastradh branches: 1.229.4; 1.229.8; 1.229.10;
Remove MKCRYPTO option.

Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.

In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.

The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.

My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.

As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:

https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html

P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.

1.229 Sun May 21 15:28:42 GMT 2017 riastradh branches: 1.229.4; 1.229.8; 1.229.10;
Remove MKCRYPTO option.

Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.

In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.

The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.

My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.

As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:

https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.html
https://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.html
https://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html

P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.

/src/sys/dev/pcmcia/
H A Dpcmciadevs.h1.229 Thu Jun 19 18:21:32 GMT 2008 imp branches: 1.229.2;
Sync to pcmciadevs 1.226

1.229 Thu Jun 19 18:21:32 GMT 2008 imp branches: 1.229.2;
Sync to pcmciadevs 1.226

H A Dpcmciadevs_data.h1.229 Thu Jun 19 18:21:32 GMT 2008 imp branches: 1.229.2;
Sync to pcmciadevs 1.226

1.229 Thu Jun 19 18:21:32 GMT 2008 imp branches: 1.229.2;
Sync to pcmciadevs 1.226

/src/sys/dev/
H A DDEVNAMES1.229 Wed Jul 11 08:08:39 GMT 2007 kiyohara branches: 1.229.6; 1.229.8; 1.229.10; 1.229.12;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.
And zyd(4).

1.229 Wed Jul 11 08:08:39 GMT 2007 kiyohara branches: 1.229.6; 1.229.8; 1.229.10; 1.229.12;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.
And zyd(4).

1.229 Wed Jul 11 08:08:39 GMT 2007 kiyohara branches: 1.229.6; 1.229.8; 1.229.10; 1.229.12;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.
And zyd(4).

1.229 Wed Jul 11 08:08:39 GMT 2007 kiyohara branches: 1.229.6; 1.229.8; 1.229.10; 1.229.12;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.
And zyd(4).

1.229 Wed Jul 11 08:08:39 GMT 2007 kiyohara branches: 1.229.6; 1.229.8; 1.229.10; 1.229.12;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.
And zyd(4).

/src/usr.sbin/
H A DMakefile1.229 Sat Aug 04 11:03:03 GMT 2007 ad branches: 1.229.2; 1.229.6;
Add cpuctl(8). For now this is not much more than a toy for debugging and
benchmarking that allows taking CPUs online/offline.

1.229 Sat Aug 04 11:03:03 GMT 2007 ad branches: 1.229.2; 1.229.6;
Add cpuctl(8). For now this is not much more than a toy for debugging and
benchmarking that allows taking CPUs online/offline.

1.229 Sat Aug 04 11:03:03 GMT 2007 ad branches: 1.229.2; 1.229.6;
Add cpuctl(8). For now this is not much more than a toy for debugging and
benchmarking that allows taking CPUs online/offline.

/src/sys/compat/linux/common/
H A Dlinux_misc.c1.229 Thu May 29 10:35:27 GMT 2014 njoly branches: 1.229.2; 1.229.4; 1.229.8;
For utimes(2), use compat_50_sys_utimes() instead of local version.

1.229 Thu May 29 10:35:27 GMT 2014 njoly branches: 1.229.2; 1.229.4; 1.229.8;
For utimes(2), use compat_50_sys_utimes() instead of local version.

1.229 Thu May 29 10:35:27 GMT 2014 njoly branches: 1.229.2; 1.229.4; 1.229.8;
For utimes(2), use compat_50_sys_utimes() instead of local version.

1.229 Thu May 29 10:35:27 GMT 2014 njoly branches: 1.229.2; 1.229.4; 1.229.8;
For utimes(2), use compat_50_sys_utimes() instead of local version.

/src/usr.bin/xlint/lint1/
H A Ddebug.c1.39 Fri Jun 30 21:06:18 GMT 2023 rillig lint: fix handling of unnamed struct/union members

The support for unnamed struct/union members that was added in decl.c
1.60 from 2015-10-13 was simple but wrong. It didn't cover initializers
of these structures and computed wrong sizes for structures containing
anonymous unions. At that time, the handling of initializers was broken
as well, it was fixed 6 years later in init.c 1.229 from 2021-12-22.

Real-life examples for code that lint couldn't handle are:

* external/bsd/jemalloc/dist/src/jemalloc.c
* external/mit/xorg/lib/dri.old/Makefile

/src/sys/nfs/
H A Dnfs_vfsops.c1.229 Fri May 30 08:47:45 GMT 2014 hannken branches: 1.229.2; 1.229.4;
Change NFS from rbtree to vcache.

1.229 Fri May 30 08:47:45 GMT 2014 hannken branches: 1.229.2; 1.229.4;
Change NFS from rbtree to vcache.

1.229 Fri May 30 08:47:45 GMT 2014 hannken branches: 1.229.2; 1.229.4;
Change NFS from rbtree to vcache.

/src/sys/miscfs/procfs/
H A Dprocfs_vnops.c1.229 Fri Jun 17 14:30:37 GMT 2022 shm branches: 1.229.4;
Add missing permission check

1.229 Fri Jun 17 14:30:37 GMT 2022 shm branches: 1.229.4;
Add missing permission check

/src/sys/arch/hpcmips/conf/
H A DGENERIC1.229 Sun Nov 16 16:01:41 GMT 2014 manu branches: 1.229.2;
Remove unused extended attributes kernel options

As Masao Uebayashi pointed to me, UFS_EXTATTR_AUTOSTART, LFS_EXTATTR_AUTOSTART
and UFS_EXTATTR_AUTOCREATE are not used anywhere in the code. Remove them
as they have been obsolete for a long time:
UFS_EXTATTR_AUTOSTART was replaced by mount -o extattr
LFS_EXTATTR_AUTOSTART was created to match obsolete UFS_EXTATTR_AUTOSTART
UFS_EXTATTR_AUTOCREATE was replaced by sysctl vfs.ffs.extattr_autocreate

1.229 Sun Nov 16 16:01:41 GMT 2014 manu branches: 1.229.2;
Remove unused extended attributes kernel options

As Masao Uebayashi pointed to me, UFS_EXTATTR_AUTOSTART, LFS_EXTATTR_AUTOSTART
and UFS_EXTATTR_AUTOCREATE are not used anywhere in the code. Remove them
as they have been obsolete for a long time:
UFS_EXTATTR_AUTOSTART was replaced by mount -o extattr
LFS_EXTATTR_AUTOSTART was created to match obsolete UFS_EXTATTR_AUTOSTART
UFS_EXTATTR_AUTOCREATE was replaced by sysctl vfs.ffs.extattr_autocreate

Completed in 168 milliseconds

123456789