HomeSort by: relevance | last modified time | path
    Searched hist:1.366 (Results 1 - 25 of 85) sorted by relevancy

1 2 3 4

  /src/lib/libc/string/
wcscasecmp.c 1.2.2.1 Sun Aug 27 06:15:45 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.

wcsdup.c 1.2.2.1 Sun Aug 27 06:15:44 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.

wcsncasecmp.c 1.2.2.1 Sun Aug 27 06:15:45 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.

Makefile.inc 1.60.2.2 Sun Aug 27 06:15:45 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.

  /src/include/
wchar.h 1.25.2.1 Sun Aug 27 06:15:47 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.
  /src/sys/arch/i386/i386/
machdep.c 1.366 Wed Oct 06 20:04:26 UTC 1999 fvdl branches: 1.366.2; 1.366.4;
Add machdep.fpu_present sysctl.
Wed Oct 06 20:04:26 UTC 1999 fvdl branches: 1.366.2; 1.366.4;
Add machdep.fpu_present sysctl.
.2; 1.366.4;
Add machdep.fpu_present sysctl.
1.366.4.1 Mon Nov 15 00:38:01 UTC 1999 fvdl Sync with -current
1.366.2.10 Mon Apr 23 09:41:48 UTC 2001 bouyer Sync with HEAD.
1.366.2.9 Sat Apr 21 17:53:50 UTC 2001 bouyer Sync with HEAD
1.366.2.8 Tue Mar 27 15:31:02 UTC 2001 bouyer Sync with HEAD.
1.366.2.7 Mon Mar 12 13:28:55 UTC 2001 bouyer Sync with HEAD.
1.366.2.6 Thu Jan 18 09:22:34 UTC 2001 bouyer Sync with head (for UBC+NFS fixes, mostly).
1.366.2.5 Fri Jan 05 17:34:30 UTC 2001 bouyer Sync with HEAD
  /src/sys/arch/sparc/sparc/
pmap.c 1.366 Sun Jan 13 22:11:11 UTC 2019 mrg switch sparc pmap lock to the scheme sparc64 uses:

- local IPL_NONE mutex for general pmap locking operations, not
kernel lock.
- for pmap_activate()/pmap_deactivate(), switch to using the
existing ctx_lock, and push handling of it into ctx_alloc() the
ctx_free() callers.

fixes easy to trigger deadlocks on systems with >2 cpus. without
this patch i usually hang during boot. with it, i was able to
push the machine hard for over 12 hours.

XXX: pullup-8, and maybe -7.
1.358.10.1 Tue Jan 15 18:44:28 UTC 2019 martin Pull up following revision(s) (requested by mrg in ticket #1672):

sys/arch/sparc/sparc/pmap.c: revision 1.366

switch sparc pmap lock to the scheme sparc64 uses:
- - local IPL_NONE mutex for general pmap locking operations, not
kernel lock.
- - for pmap_activate()/pmap_deactivate(), switch to using the
existing ctx_lock, and push handling of it into ctx_alloc() the
ctx_free() callers.

fixes easy to trigger deadlocks on systems with >2 cpus. without
this patch i usually hang during boot. with it, i was able to
push the machine hard for over 12 hours.

XXX: pullup-8, and maybe -7.
1.358.6.1 Tue Jan 15 18:45:24 UTC 2019 martin Pull up following revision(s) (requested by mrg in ticket #1672):

sys/arch/sparc/sparc/pmap.c: revision 1.366

switch sparc pmap lock to the scheme sparc64 uses:
- - local IPL_NONE mutex for general pmap locking operations, not
kernel lock.
- - for pmap_activate()/pmap_deactivate(), switch to using the
existing ctx_lock, and push handling of it into ctx_alloc() the
ctx_free() callers.

fixes easy to trigger deadlocks on systems with >2 cpus. without
this patch i usually hang during boot. with it, i was able to
push the machine hard for over 12 hours.

XXX: pullup-8, and maybe -7.
1.358.2.1 Tue Jan 15 18:43:27 UTC 2019 martin Pull up following revision(s) (requested by mrg in ticket #1672):

sys/arch/sparc/sparc/pmap.c: revision 1.366

switch sparc pmap lock to the scheme sparc64 uses:
- - local IPL_NONE mutex for general pmap locking operations, not
kernel lock.
- - for pmap_activate()/pmap_deactivate(), switch to using the
existing ctx_lock, and push handling of it into ctx_alloc() the
ctx_free() callers.

fixes easy to trigger deadlocks on systems with >2 cpus. without
this patch i usually hang during boot. with it, i was able to
push the machine hard for over 12 hours.

XXX: pullup-8, and maybe -7.
1.361.8.1 Tue Jan 15 18:40:15 UTC 2019 martin Pull up following revision(s) (requested by mrg in ticket #1163):

sys/arch/sparc/sparc/pmap.c: revision 1.366

switch sparc pmap lock to the scheme sparc64 uses:
- - local IPL_NONE mutex for general pmap locking operations, not
kernel lock.
- - for pmap_activate()/pmap_deactivate(), switch to using the
existing ctx_lock, and push handling of it into ctx_alloc() the
ctx_free() callers.

fixes easy to trigger deadlocks on systems with >2 cpus. without
this patch i usually hang during boot. with it, i was able to
push the machine hard for over 12 hours.

XXX: pullup-8, and maybe -7.
  /src/sys/netinet/
ip_input.c 1.366 Mon Feb 05 13:23:11 UTC 2018 maxv Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:

source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network

And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.298.8.1 Fri Feb 09 14:11:21 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1526):
sys/netinet/ip_input.c: revision 1.366

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.298.6.1 Fri Feb 09 14:12:22 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1526):
sys/netinet/ip_input.c: revision 1.366

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.298.2.1 Fri Feb 09 14:09:35 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1526):
sys/netinet/ip_input.c: revision 1.366

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.319.10.1 Fri Feb 09 14:05:29 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1563):
sys/netinet/ip_input.c: revision 1.366 (via patch)

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.319.6.1 Fri Feb 09 14:06:25 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1563):
sys/netinet/ip_input.c: revision 1.366 (via patch)

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.319.2.1 Fri Feb 09 13:37:09 UTC 2018 martin Pull up following revision(s) (requested by maxv in ticket #1563):
sys/netinet/ip_input.c: revision 1.366 (via patch)

Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.

By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.

It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
1.355.2.4 Mon Feb 12 18:23:29 UTC 2018 snj Pull up following revision(s) (requested by maxv in ticket #547):
sys/netinet/ip_input.c: 1.366
Disable ip_allowsrcrt and ip_forwsrcrt. Enabling them by default was a
completely dumb idea, because they have security implications.
By sending an IPv4 packet containing an LSRR option, an attacker will
cause the system to forward the packet to another IPv4 address - and
this way he white-washes the source of the packet.
It is also possible for an attacker to reach hidden networks: if a server
has a public address, and a private one on an internal network (network
which has several internal machines connected), the attacker can send a
packet with:
source = 0.0.0.0
destination = public address of the server
LSRR first address = address of a machine on the internal network
And the packet will be forwarded, by the server, to the internal machine,
in some cases even with the internal IP address of the server as a source.
  /src/
build.sh 1.366 Mon Mar 13 11:52:29 UTC 2023 martin Avoid the dependency on a populated tooldir (or building the tools)
when simply doing mkrepro-timestamp and the current repository setups
does not actually require it.
1.316.4.4 Mon Mar 13 21:36:29 UTC 2023 jdc Pull up the following revision (requested by martin in ticket #1807):

build.sh: revision 1.366 via patch

Avoid the dependency on a populated tooldir (or building the tools)
when simply doing mkrepro-timestamp and the current repository setups
does not actually require it.
1.333.2.3 Mon Mar 13 21:38:13 UTC 2023 jdc Pull up the following revision (requested by martin in ticket #1611):

build.sh: revision 1.366 via patch

Avoid the dependency on a populated tooldir (or building the tools)
when simply doing mkrepro-timestamp and the current repository setups
does not actually require it.
1.365.2.1 Mon Mar 13 21:40:24 UTC 2023 jdc Pull up the following revision (requested by martin in ticket #117):

build.sh: revision 1.366 via patch

Avoid the dependency on a populated tooldir (or building the tools)
when simply doing mkrepro-timestamp and the current repository setups
does not actually require it.
UPDATING 1.366 Mon Nov 11 13:58:56 UTC 2024 riastradh UPDATING: Expand list of deletions for zstd mess.

1. Don't use $ for variables -- if you copy & paste, e.g.,

rm -rf $DESTDIR/usr/lib/libarchive*

and DESTDIR is not actually defined in the environment, you might
be an unhappy camper. (Resolvable by using /bin/pax to extract
the library from base.tgz but not great!)

2. Nix compat libraries and libmagic too.

3. Sort for easier maintenance.
  /src/sys/arch/macppc/conf/
GENERIC 1.366 Sat Mar 28 08:35:36 UTC 2020 isaki branches: 1.366.2;
Reduce default AUDIO_BLK_MS from 40msec to 10msec on all platform except m68k
(m68k uses 40msec default as before). And remove the option from GENERIC.
- It's not good idea to set such parameter in individual GENERICs.
- 4msec is (probably no problem for most modern real hardware but)
too aggressive to be default.
- 10msec is too severe for antique machines but it's hard to draw a line.
Sat Mar 28 08:35:36 UTC 2020 isaki branches: 1.366.2;
Reduce default AUDIO_BLK_MS from 40msec to 10msec on all platform except m68k
(m68k uses 40msec default as before). And remove the option from GENERIC.
- It's not good idea to set such parameter in individual GENERICs.
- 4msec is (probably no problem for most modern real hardware but)
too aggressive to be default.
- 10msec is too severe for antique machines but it's hard to draw a line.
1.366.2.1 Sat Apr 25 11:23:56 UTC 2020 bouyer Sync with bouyer-xenpvh-base2 (HEAD)
  /src/doc/
BRANCHES 1.366 Fri Dec 16 17:35:42 UTC 2022 martin Welcome to 10.99.1!
  /src/sys/arch/amd64/amd64/
machdep.c 1.366 Wed Oct 26 23:38:06 UTC 2022 riastradh branches: 1.366.2;
ddb/db_active.h: New home for extern db_active.

This can be included unconditionally, and db_active can then be
queried unconditionally; if DDB is not in the kernel, then db_active
is a constant zero. Reduces need for #include opt_ddb.h, #ifdef DDB.
Wed Oct 26 23:38:06 UTC 2022 riastradh branches: 1.366.2;
ddb/db_active.h: New home for extern db_active.

This can be included unconditionally, and db_active can then be
queried unconditionally; if DDB is not in the kernel, then db_active
is a constant zero. Reduces need for #include opt_ddb.h, #ifdef DDB.
1.366.2.1 Sat Mar 29 10:32:43 UTC 2025 martin Pull up following revision(s) (requested by imil in ticket #1074):

sys/arch/x86/x86/x86_machdep.c: revision 1.155
sys/arch/x86/include/cpu.h: revision 1.137
sys/arch/x86/x86/x86_machdep.c: revision 1.156
sys/arch/x86/include/cpu.h: revision 1.138
sys/arch/x86/x86/consinit.c: revision 1.40
sys/arch/x86/acpi/acpi_machdep.c: revision 1.37
sys/arch/x86/acpi/acpi_machdep.c: revision 1.38
sys/arch/amd64/amd64/machdep.c: revision 1.370
sys/arch/xen/xen/hypervisor.c: revision 1.97
sys/arch/xen/xen/hypervisor.c: revision 1.98
sys/arch/amd64/amd64/genassym.cf: revision 1.98
sys/arch/x86/x86/x86_autoconf.c: revision 1.88
sys/arch/x86/x86/x86_autoconf.c: revision 1.89
sys/arch/amd64/amd64/locore.S: revision 1.226
sys/arch/amd64/amd64/locore.S: revision 1.227
sys/arch/x86/x86/identcpu.c: revision 1.131

Add support for non-Xen PVH guests to amd64. Patch from
Emile 'iMil' Heitor in PR kern/57813, with some cosmetic tweaks by me.
Tested on bare metal, Xen PV and Xen PVH by me.

Get one more change from PR kern/57813, needed for non-Xen PVH.

Introduce vm_guest_is_pvh() and use it in place of
(vm_guest == VM_GUEST_XENPVH || vm_guest == VM_GUEST_GENPVH)
  /src/sys/kern/
sys_ptrace_common.c 1.58.2.5 Tue Oct 15 19:01:06 UTC 2019 martin Pull up following revision(s) (requested by kamil in ticket #320):

sys/kern/kern_synch.c: revision 1.324
sys/kern/kern_sig.c: revision 1.366
sys/kern/kern_exit.c: revision 1.277
sys/kern/kern_lwp.c: revision 1.204
sys/kern/sys_ptrace_common.c: revision 1.62

Separate flag for suspended by _lwp_suspend and suspended by a debugger

Once a thread was stopped with ptrace(2), userland process must not
be able to unstop it deliberately or by an accident.

This was a Windows-style behavior that makes threading tracing fragile.

kern_sig.c 1.366 Thu Oct 03 22:48:44 UTC 2019 kamil Separate flag for suspended by _lwp_suspend and suspended by a debugger

Once a thread was stopped with ptrace(2), userland process must not
be able to unstop it deliberately or by an accident.

This was a Windows-style behavior that makes threading tracing fragile.
1.364.2.2 Tue Oct 15 19:01:06 UTC 2019 martin Pull up following revision(s) (requested by kamil in ticket #320):

sys/kern/kern_synch.c: revision 1.324
sys/kern/kern_sig.c: revision 1.366
sys/kern/kern_exit.c: revision 1.277
sys/kern/kern_lwp.c: revision 1.204
sys/kern/sys_ptrace_common.c: revision 1.62

Separate flag for suspended by _lwp_suspend and suspended by a debugger

Once a thread was stopped with ptrace(2), userland process must not
be able to unstop it deliberately or by an accident.

This was a Windows-style behavior that makes threading tracing fragile.
kern_synch.c 1.366 Wed Nov 22 13:18:48 UTC 2023 riastradh kpause(9): KASSERT -> KASSERTMSG

PR kern/57718 (might help to diagnose manifestations of the problem)
1.323.4.1 Tue Oct 15 19:01:06 UTC 2019 martin Pull up following revision(s) (requested by kamil in ticket #320):

sys/kern/kern_synch.c: revision 1.324
sys/kern/kern_sig.c: revision 1.366
sys/kern/kern_exit.c: revision 1.277
sys/kern/kern_lwp.c: revision 1.204
sys/kern/sys_ptrace_common.c: revision 1.62

Separate flag for suspended by _lwp_suspend and suspended by a debugger

Once a thread was stopped with ptrace(2), userland process must not
be able to unstop it deliberately or by an accident.

This was a Windows-style behavior that makes threading tracing fragile.
kern_lwp.c 1.202.2.2 Tue Oct 15 19:01:06 UTC 2019 martin Pull up following revision(s) (requested by kamil in ticket #320):

sys/kern/kern_synch.c: revision 1.324
sys/kern/kern_sig.c: revision 1.366
sys/kern/kern_exit.c: revision 1.277
sys/kern/kern_lwp.c: revision 1.204
sys/kern/sys_ptrace_common.c: revision 1.62

Separate flag for suspended by _lwp_suspend and suspended by a debugger

Once a thread was stopped with ptrace(2), userland process must not
be able to unstop it deliberately or by an accident.

This was a Windows-style behavior that makes threading tracing fragile.
  /src/share/misc/
acronyms.comp 1.366 Mon Sep 18 15:19:33 UTC 2023 jschauma +CERT computer emergency response team
+[C]SIRT (computer) security incident response team
+SOC security operations center
  /src/distrib/notes/common/
main 1.366 Mon Nov 05 22:58:33 UTC 2007 xtraeme Sync with NetBSD-4.0.xml 1.35, which fixes a typo in the sparc changes
section caught by pavel@.
1.320.2.6 Mon Nov 05 23:17:55 UTC 2007 pavel Pull up following revisions (requested by xtraeme in ticket #978):
distrib/notes/common/main: revision 1.365-1.366
Sync with NetBSD-4.0.xml 1.34 for the updated list of changes.
With instructions from pavel@.
Sync with NetBSD-4.0.xml 1.35, which fixes a typo in the sparc changes
section caught by pavel@.
  /src/sys/uvm/
uvm_map.c 1.366 Fri Nov 01 13:04:22 UTC 2019 rin Fix previous; semantics of align argument of uvm_map() is different
when UVM_FLAG_COLORMATCH is specified.

Should fix PR kern/54669.
1.362.2.2 Fri Nov 01 18:24:31 UTC 2019 martin Addionally pull up the following revision for ticket #388:

sys/uvm/uvm_map.c 1.366

Fix previous; semantics of align argument of uvm_map() is different
when UVM_FLAG_COLORMATCH is specified.

Should fix PR kern/54669.
  /src/lib/libc/include/
namespace.h 1.117.2.2 Sun Aug 27 06:15:45 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.
  /src/lib/libc/
shlib_version 1.180.2.2 Sun Aug 27 06:15:45 UTC 2006 riz Pull up following revision(s) (requested by tron in ticket #64):
lib/libc/include/namespace.h: revision 1.119
lib/libc/string/wcsdup.c: revision 1.1
lib/libc/string/wcscasecmp.c: revision 1.1
lib/libc/include/namespace.h: revision 1.120
distrib/sets/lists/base/shl.mi: revision 1.366
lib/libc/shlib_version: revision 1.182
include/wchar.h: revision 1.26
lib/libc/string/Makefile.inc: revision 1.62
lib/libc/string/Makefile.inc: revision 1.63
lib/libc/string/wcsncasecmp.c: revision 1.1
PR/34238: Aleksey Cheusov: add wcsdup, wcscasecmp and wcsncasecmp functions
libc 147 for wcsdup and wcs{n,}casecmp
include one more new file.
add wcsdup, wcscasecmp and wcsncasecmp. fixes build problems..
I think we want both wcs{c,n}casecmp weak.
  /src/share/man/man4/
options.4 1.366 Thu Sep 11 21:14:16 UTC 2008 pgoyette Add warning on possible side effects of using 'options I2C_SCAN'
  /src/sys/dev/ic/
com.c 1.366 Mon Oct 11 18:39:06 UTC 2021 jmcneill com: speed up close with HUPCL set

Instead of incurring a 1s penalty on close of a com device with HUPCL set,
defer the sleep until the next open, and only sleep if necessary.

This has a side effect of making `ttyflags -a` with a default install not
pause for 1s for every non-console com device, which happens every boot
via /etc/rc.d/ttys.
  /src/usr.bin/indent/
indent.c 1.366 Wed Jun 14 19:05:40 UTC 2023 rillig indent: allow more than 128 brace levels

Completed in 775 milliseconds

1 2 3 4