Searched hist:1.203 (Results 1 - 25 of 246) sorted by relevance

12345678910

/src/sys/arch/sparc/conf/
H A DGENERIC1.203 Mon Dec 31 15:32:05 GMT 2007 ad branches: 1.203.6; 1.203.10; 1.203.12; 1.203.16;
Remove systrace. Ok core@.

1.203 Mon Dec 31 15:32:05 GMT 2007 ad branches: 1.203.6; 1.203.10; 1.203.12; 1.203.16;
Remove systrace. Ok core@.

1.203 Mon Dec 31 15:32:05 GMT 2007 ad branches: 1.203.6; 1.203.10; 1.203.12; 1.203.16;
Remove systrace. Ok core@.

1.203 Mon Dec 31 15:32:05 GMT 2007 ad branches: 1.203.6; 1.203.10; 1.203.12; 1.203.16;
Remove systrace. Ok core@.

1.203 Mon Dec 31 15:32:05 GMT 2007 ad branches: 1.203.6; 1.203.10; 1.203.12; 1.203.16;
Remove systrace. Ok core@.

/src/lib/libc/gen/
H A Dsysctl.31.203 Mon Jul 03 21:32:49 GMT 2017 wiz branches: 1.203.4; 1.203.6;
Remove workaround for ancient HTML generation code.

1.203 Mon Jul 03 21:32:49 GMT 2017 wiz branches: 1.203.4; 1.203.6;
Remove workaround for ancient HTML generation code.

1.203 Mon Jul 03 21:32:49 GMT 2017 wiz branches: 1.203.4; 1.203.6;
Remove workaround for ancient HTML generation code.

/src/sys/nfs/
H A Dnfs_vfsops.c1.203 Wed Oct 22 00:29:35 GMT 2008 matt branches: 1.203.2; 1.203.4; 1.203.10; 1.203.14;
Don't need nfs_vfs_reinit anymore since we don't resize tables anymore.
Move reinit code to init case.

1.203 Wed Oct 22 00:29:35 GMT 2008 matt branches: 1.203.2; 1.203.4; 1.203.10; 1.203.14;
Don't need nfs_vfs_reinit anymore since we don't resize tables anymore.
Move reinit code to init case.

1.203 Wed Oct 22 00:29:35 GMT 2008 matt branches: 1.203.2; 1.203.4; 1.203.10; 1.203.14;
Don't need nfs_vfs_reinit anymore since we don't resize tables anymore.
Move reinit code to init case.

1.203 Wed Oct 22 00:29:35 GMT 2008 matt branches: 1.203.2; 1.203.4; 1.203.10; 1.203.14;
Don't need nfs_vfs_reinit anymore since we don't resize tables anymore.
Move reinit code to init case.

1.203 Wed Oct 22 00:29:35 GMT 2008 matt branches: 1.203.2; 1.203.4; 1.203.10; 1.203.14;
Don't need nfs_vfs_reinit anymore since we don't resize tables anymore.
Move reinit code to init case.

/src/sys/arch/sun3/sun3/
H A Dmachdep.c1.203 Tue Jun 14 15:23:19 GMT 2011 tsutsui branches: 1.203.2; 1.203.6;
Fix merge botch. KERNBASE macro was split into KERNBASE3 and KERNBASE3X
for kernel, and was replaced with kernbase constant for possible reference
of USRSTACK in module(7).

1.203 Tue Jun 14 15:23:19 GMT 2011 tsutsui branches: 1.203.2; 1.203.6;
Fix merge botch. KERNBASE macro was split into KERNBASE3 and KERNBASE3X
for kernel, and was replaced with kernbase constant for possible reference
of USRSTACK in module(7).

1.203 Tue Jun 14 15:23:19 GMT 2011 tsutsui branches: 1.203.2; 1.203.6;
Fix merge botch. KERNBASE macro was split into KERNBASE3 and KERNBASE3X
for kernel, and was replaced with kernbase constant for possible reference
of USRSTACK in module(7).

/src/lib/libc/include/
H A Dnamespace.h1.203 Tue May 31 13:42:59 GMT 2022 riastradh branches: 1.203.2; 1.203.4;
libc: Reintroduce getentropy.

This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):

SYNOPSIS
#include <unistd.h>

int getentropy(void *buffer, size_t length);

DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.

RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.

ERRORS
The getentropy() function shall fail if:

[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.

The getentropy() function may fail if:

[ENOSYS] The system does not provide the necessary
source of entropy.

RATIONALE
The getentropy() function is not a cancellation point.

Minor changes from the previous introduction of getentropy into libc:

- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.

The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.

1.203 Tue May 31 13:42:59 GMT 2022 riastradh branches: 1.203.2; 1.203.4;
libc: Reintroduce getentropy.

This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):

SYNOPSIS
#include <unistd.h>

int getentropy(void *buffer, size_t length);

DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.

RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.

ERRORS
The getentropy() function shall fail if:

[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.

The getentropy() function may fail if:

[ENOSYS] The system does not provide the necessary
source of entropy.

RATIONALE
The getentropy() function is not a cancellation point.

Minor changes from the previous introduction of getentropy into libc:

- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.

The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.

1.203 Tue May 31 13:42:59 GMT 2022 riastradh branches: 1.203.2; 1.203.4;
libc: Reintroduce getentropy.

This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):

SYNOPSIS
#include <unistd.h>

int getentropy(void *buffer, size_t length);

DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.

RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.

ERRORS
The getentropy() function shall fail if:

[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.

The getentropy() function may fail if:

[ENOSYS] The system does not provide the necessary
source of entropy.

RATIONALE
The getentropy() function is not a cancellation point.

Minor changes from the previous introduction of getentropy into libc:

- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.

The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.

/src/sys/sys/
H A Dsyscall.h1.203 Fri Feb 15 13:10:23 GMT 2008 ad branches: 1.203.2; 1.203.6;
Regen.
1.203 Fri Feb 15 13:10:23 GMT 2008 ad branches: 1.203.2; 1.203.6;
Regen.
1.203 Fri Feb 15 13:10:23 GMT 2008 ad branches: 1.203.2; 1.203.6;
Regen.
H A Dsystm.h1.203 Thu Nov 22 22:56:16 GMT 2007 plunky branches: 1.203.2; 1.203.6;
remove insque/remque from libkern, they are no longer used

1.203 Thu Nov 22 22:56:16 GMT 2007 plunky branches: 1.203.2; 1.203.6;
remove insque/remque from libkern, they are no longer used

1.203 Thu Nov 22 22:56:16 GMT 2007 plunky branches: 1.203.2; 1.203.6;
remove insque/remque from libkern, they are no longer used

/src/sys/ufs/lfs/
H A Dlfs.h1.203 Wed Jul 26 16:42:37 GMT 2017 maya branches: 1.203.2; 1.203.4;
change lfs_nextsegsleep and lfs_allclean_wakeup to use condvar

XXX had to use lfs_lock in lfs_segwait, removed kernel_lock, is this
appropriate?
1.203 Wed Jul 26 16:42:37 GMT 2017 maya branches: 1.203.2; 1.203.4;
change lfs_nextsegsleep and lfs_allclean_wakeup to use condvar

XXX had to use lfs_lock in lfs_segwait, removed kernel_lock, is this
appropriate?
1.203 Wed Jul 26 16:42:37 GMT 2017 maya branches: 1.203.2; 1.203.4;
change lfs_nextsegsleep and lfs_allclean_wakeup to use condvar

XXX had to use lfs_lock in lfs_segwait, removed kernel_lock, is this
appropriate?
/src/sys/uvm/
H A Duvm_swap.c1.203 Sat Mar 13 15:29:55 GMT 2021 skrll branches: 1.203.4; 1.203.6;
Consistently use %#jx instead of 0x%jx or just %jx in UVMHIST_LOG formats

1.203 Sat Mar 13 15:29:55 GMT 2021 skrll branches: 1.203.4; 1.203.6;
Consistently use %#jx instead of 0x%jx or just %jx in UVMHIST_LOG formats

1.203 Sat Mar 13 15:29:55 GMT 2021 skrll branches: 1.203.4; 1.203.6;
Consistently use %#jx instead of 0x%jx or just %jx in UVMHIST_LOG formats

H A Duvm_extern.h1.203 Wed Jan 04 23:59:49 GMT 2017 christos branches: 1.203.6;
don't include uvm_physseg.h for kmem grovellers.
1.203 Wed Jan 04 23:59:49 GMT 2017 christos branches: 1.203.6;
don't include uvm_physseg.h for kmem grovellers.
/src/sys/arch/sparc/sparc/
H A Dcpu.c1.203 Mon May 28 21:24:17 GMT 2007 mrg branches: 1.203.2; 1.203.4;
cpu_attach(): in the MP case, fix up idle lwp info as well as lwp0.l_cpu.
for LOCKDEBUG, mutex_destroy() the cpu0 spc_lwplock with the global
cpuinfo VA, and re-mutex_init() it with the per-cpu address that is only
now available. for non-boot cpus, be sure to also initialise curlwp to
the idle lwp.

xcall(), pmap_quiet_check(), pmap_pmap_pool_ctor(), pmap_pmap_pool_dtor(),
and pmap_enu4m(): don't care about cpus that have not been attached yet.

1.203 Mon May 28 21:24:17 GMT 2007 mrg branches: 1.203.2; 1.203.4;
cpu_attach(): in the MP case, fix up idle lwp info as well as lwp0.l_cpu.
for LOCKDEBUG, mutex_destroy() the cpu0 spc_lwplock with the global
cpuinfo VA, and re-mutex_init() it with the per-cpu address that is only
now available. for non-boot cpus, be sure to also initialise curlwp to
the idle lwp.

xcall(), pmap_quiet_check(), pmap_pmap_pool_ctor(), pmap_pmap_pool_dtor(),
and pmap_enu4m(): don't care about cpus that have not been attached yet.

1.203 Mon May 28 21:24:17 GMT 2007 mrg branches: 1.203.2; 1.203.4;
cpu_attach(): in the MP case, fix up idle lwp info as well as lwp0.l_cpu.
for LOCKDEBUG, mutex_destroy() the cpu0 spc_lwplock with the global
cpuinfo VA, and re-mutex_init() it with the per-cpu address that is only
now available. for non-boot cpus, be sure to also initialise curlwp to
the idle lwp.

xcall(), pmap_quiet_check(), pmap_pmap_pool_ctor(), pmap_pmap_pool_dtor(),
and pmap_enu4m(): don't care about cpus that have not been attached yet.

H A Dautoconf.c1.203 Wed Mar 17 17:04:59 GMT 2004 pk branches: 1.203.2;
Rename PROM_getprop*() => prom_getprop*().

1.203 Wed Mar 17 17:04:59 GMT 2004 pk branches: 1.203.2;
Rename PROM_getprop*() => prom_getprop*().

/src/libexec/ftpd/
H A Dftpd.c1.203 Tue Jul 19 21:25:38 GMT 2016 shm branches: 1.203.6; 1.203.12;
CID 603440: ensure that closing socket exists

1.203 Tue Jul 19 21:25:38 GMT 2016 shm branches: 1.203.6; 1.203.12;
CID 603440: ensure that closing socket exists

1.203 Tue Jul 19 21:25:38 GMT 2016 shm branches: 1.203.6; 1.203.12;
CID 603440: ensure that closing socket exists

/src/sys/dev/scsipi/
H A Dst.c1.203 Sat Apr 05 15:47:01 GMT 2008 cegger branches: 1.203.2; 1.203.4;
use aprint_*_dev and device_xname

1.203 Sat Apr 05 15:47:01 GMT 2008 cegger branches: 1.203.2; 1.203.4;
use aprint_*_dev and device_xname

1.203 Sat Apr 05 15:47:01 GMT 2008 cegger branches: 1.203.2; 1.203.4;
use aprint_*_dev and device_xname

/src/sys/dev/pci/
H A Dpccbb.c1.203 Mon Aug 01 11:20:26 GMT 2011 drochner branches: 1.203.2; 1.203.6;
remove some bloat:
-cardbus doesn't use multiple interrupt lines like PCI, and it doesn't
use machanisms like interrupt line register and swizzling -- no need
to carry around dummy information, this is all dealt with by the
bridge
(I'm asking myself how "rbus_ppb" can work -- a bridge attached to
cardbus just can't work like a normal PCI bridge as far as interrupts
are concerned. I thing that should be a hardware specific driver
because behavior is not covered by a standard.)
-cardbus always uses 3.3V -- no need for a variable to keep track
of the voltage

1.203 Mon Aug 01 11:20:26 GMT 2011 drochner branches: 1.203.2; 1.203.6;
remove some bloat:
-cardbus doesn't use multiple interrupt lines like PCI, and it doesn't
use machanisms like interrupt line register and swizzling -- no need
to carry around dummy information, this is all dealt with by the
bridge
(I'm asking myself how "rbus_ppb" can work -- a bridge attached to
cardbus just can't work like a normal PCI bridge as far as interrupts
are concerned. I thing that should be a hardware specific driver
because behavior is not covered by a standard.)
-cardbus always uses 3.3V -- no need for a variable to keep track
of the voltage

1.203 Mon Aug 01 11:20:26 GMT 2011 drochner branches: 1.203.2; 1.203.6;
remove some bloat:
-cardbus doesn't use multiple interrupt lines like PCI, and it doesn't
use machanisms like interrupt line register and swizzling -- no need
to carry around dummy information, this is all dealt with by the
bridge
(I'm asking myself how "rbus_ppb" can work -- a bridge attached to
cardbus just can't work like a normal PCI bridge as far as interrupts
are concerned. I thing that should be a hardware specific driver
because behavior is not covered by a standard.)
-cardbus always uses 3.3V -- no need for a variable to keep track
of the voltage

/src/sys/miscfs/procfs/
H A Dprocfs_vnops.c1.203 Sat Apr 07 13:42:42 GMT 2018 hannken branches: 1.203.2;
Lock the target cwdi and take an additional reference to the
vnode we are interested in to prevent it from disappearing
before getcwd_common().

Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)

1.203 Sat Apr 07 13:42:42 GMT 2018 hannken branches: 1.203.2;
Lock the target cwdi and take an additional reference to the
vnode we are interested in to prevent it from disappearing
before getcwd_common().

Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)

/src/sys/arch/x68k/conf/
H A DGENERIC1.203 Thu Jan 21 06:51:56 GMT 2021 nia branches: 1.203.4;
add a commented out compat_ossaudio wherever there's compat_linux

requested by mrg

1.203 Thu Jan 21 06:51:56 GMT 2021 nia branches: 1.203.4;
add a commented out compat_ossaudio wherever there's compat_linux

requested by mrg

/src/sys/arch/x68k/x68k/
H A Dmachdep.c1.203 Thu Jun 11 19:20:46 GMT 2020 ad branches: 1.203.2;
uvm_availmem(): give it a boolean argument to specify whether a recent
cached value will do, or if the very latest total must be fetched. It can
be called thousands of times a second and fetching the totals impacts not
only the calling LWP but other CPUs doing unrelated activity in the VM
system.

1.203 Thu Jun 11 19:20:46 GMT 2020 ad branches: 1.203.2;
uvm_availmem(): give it a boolean argument to specify whether a recent
cached value will do, or if the very latest total must be fetched. It can
be called thousands of times a second and fetching the totals impacts not
only the calling LWP but other CPUs doing unrelated activity in the VM
system.

/src/sys/arch/hpcmips/conf/
H A DGENERIC1.203 Sun Aug 10 15:31:21 GMT 2008 tls branches: 1.203.2;
Add accept filters to GENERIC kernels where they exist.

1.203 Sun Aug 10 15:31:21 GMT 2008 tls branches: 1.203.2;
Add accept filters to GENERIC kernels where they exist.

/src/lib/libm/
H A DMakefile1.203 Tue Sep 26 16:01:59 GMT 2017 maya branches: 1.203.2;
Add man page link for hypotl.3

1.203 Tue Sep 26 16:01:59 GMT 2017 maya branches: 1.203.2;
Add man page link for hypotl.3

/src/sys/arch/amd64/conf/
H A DXEN3_DOM01.203 Tue Apr 02 22:56:50 GMT 2024 charlotte branches: 1.203.2;
Mention DKWEDGE_METHOD_TOS in several kernel config files
1.203 Tue Apr 02 22:56:50 GMT 2024 charlotte branches: 1.203.2;
Mention DKWEDGE_METHOD_TOS in several kernel config files
/src/sys/arch/mac68k/conf/
H A DGENERIC1.203 Tue Nov 22 21:25:23 GMT 2011 tls branches: 1.203.2;

The rnd pseudo-device is not really optional, because it is in the same
source file as the entropy-pool code itself. Move it to std. This
will be cleaned up more when I split the sources up as they should be.

This fixes build breaks on several ports. Thanks to Havard Eidnes for
pointing them out.

1.203 Tue Nov 22 21:25:23 GMT 2011 tls branches: 1.203.2;

The rnd pseudo-device is not really optional, because it is in the same
source file as the entropy-pool code itself. Move it to std. This
will be cleaned up more when I split the sources up as they should be.

This fixes build breaks on several ports. Thanks to Havard Eidnes for
pointing them out.

/src/usr.bin/vmstat/
H A Dvmstat.c1.203 Sat Jul 12 20:04:31 GMT 2014 nakayama branches: 1.203.2;
Use u_long to avoid negative value outputs.

1.203 Sat Jul 12 20:04:31 GMT 2014 nakayama branches: 1.203.2;
Use u_long to avoid negative value outputs.

/src/sys/dev/pcmcia/
H A Dpcmciadevs.h1.203 Thu Aug 05 21:53:26 GMT 2004 mycroft Regen.

H A Dpcmciadevs_data.h1.203 Thu Aug 05 21:53:26 GMT 2004 mycroft Regen.

Completed in 230 milliseconds

12345678910