Searched hist:1.198 (Results 1 - 25 of 258) sorted by relevance

1234567891011

/src/sys/arch/hp300/hp300/
H A Dmachdep.c1.198 Mon Dec 31 13:38:49 GMT 2007 ad branches: 1.198.6; 1.198.10; 1.198.12; 1.198.14;
Remove COMPAT_HPUX.

1.198 Mon Dec 31 13:38:49 GMT 2007 ad branches: 1.198.6; 1.198.10; 1.198.12; 1.198.14;
Remove COMPAT_HPUX.

1.198 Mon Dec 31 13:38:49 GMT 2007 ad branches: 1.198.6; 1.198.10; 1.198.12; 1.198.14;
Remove COMPAT_HPUX.

1.198 Mon Dec 31 13:38:49 GMT 2007 ad branches: 1.198.6; 1.198.10; 1.198.12; 1.198.14;
Remove COMPAT_HPUX.

1.198 Mon Dec 31 13:38:49 GMT 2007 ad branches: 1.198.6; 1.198.10; 1.198.12; 1.198.14;
Remove COMPAT_HPUX.

/src/sys/arch/mips/mips/
H A Dtrap.c1.198 Sun Dec 11 00:18:09 GMT 2005 christos branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
merge ktrace-lwp.

1.198 Sun Dec 11 00:18:09 GMT 2005 christos branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
merge ktrace-lwp.

1.198 Sun Dec 11 00:18:09 GMT 2005 christos branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
merge ktrace-lwp.

1.198 Sun Dec 11 00:18:09 GMT 2005 christos branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
merge ktrace-lwp.

1.198 Sun Dec 11 00:18:09 GMT 2005 christos branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
merge ktrace-lwp.

/src/sys/dev/scsipi/
H A Dst.c1.198 Sun Jul 29 00:50:23 GMT 2007 ad branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

1.198 Sun Jul 29 00:50:23 GMT 2007 ad branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

1.198 Sun Jul 29 00:50:23 GMT 2007 ad branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

1.198 Sun Jul 29 00:50:23 GMT 2007 ad branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

1.198 Sun Jul 29 00:50:23 GMT 2007 ad branches: 1.198.4; 1.198.6; 1.198.8; 1.198.10;
It's not a good idea for device drivers to modify b_flags, as they don't
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.

/src/sys/kern/
H A Dinit_sysent.c1.198 Fri Sep 07 18:58:46 GMT 2007 rmind branches: 1.198.4; 1.198.6;
Regen syscalls.

1.198 Fri Sep 07 18:58:46 GMT 2007 rmind branches: 1.198.4; 1.198.6;
Regen syscalls.

1.198 Fri Sep 07 18:58:46 GMT 2007 rmind branches: 1.198.4; 1.198.6;
Regen syscalls.

H A Dkern_subr.c1.198 Sun Jan 11 02:45:52 GMT 2009 christos branches: 1.198.2;
merge christos-time_t

1.198 Sun Jan 11 02:45:52 GMT 2009 christos branches: 1.198.2;
merge christos-time_t

H A Dtty.c1.198 Tue Sep 25 14:04:07 GMT 2007 ad branches: 1.198.2;
Use selinit() / seldestroy().

1.198 Tue Sep 25 14:04:07 GMT 2007 ad branches: 1.198.2;
Use selinit() / seldestroy().

/src/sys/arch/hp300/conf/
H A DGENERIC1.198 Tue Jan 23 14:47:54 GMT 2018 sevan branches: 1.198.2; 1.198.4;
Alternate buffer queue strategies no longer considered experimental, update
description.

Discussed on tech-kern
http://mail-index.netbsd.org/tech-kern/2018/01/21/msg023002.html

1.198 Tue Jan 23 14:47:54 GMT 2018 sevan branches: 1.198.2; 1.198.4;
Alternate buffer queue strategies no longer considered experimental, update
description.

Discussed on tech-kern
http://mail-index.netbsd.org/tech-kern/2018/01/21/msg023002.html

1.198 Tue Jan 23 14:47:54 GMT 2018 sevan branches: 1.198.2; 1.198.4;
Alternate buffer queue strategies no longer considered experimental, update
description.

Discussed on tech-kern
http://mail-index.netbsd.org/tech-kern/2018/01/21/msg023002.html

/src/distrib/sets/lists/etc/
H A Dmi1.198 Tue Apr 15 11:17:47 GMT 2008 plunky branches: 1.198.2; 1.198.4;
some changes to serial bluetooth host controller interfaces

btuartd(8) should be named btattach(8) for consistency
with other parts of NetBSD

make btattach(8) a single-use tool for less complexity

device specicific initialisation (from btuart(4)) is carried
out prior to activating the line discipline (in btattach(8)),
which simplifies the API somewhat and means that the user
tool and the kernel do not need to be kept in sync.

btuart(4) driver is much reduced; naming is made consistent
and all tsleep() and delay() are removed to userland
1.198 Tue Apr 15 11:17:47 GMT 2008 plunky branches: 1.198.2; 1.198.4;
some changes to serial bluetooth host controller interfaces

btuartd(8) should be named btattach(8) for consistency
with other parts of NetBSD

make btattach(8) a single-use tool for less complexity

device specicific initialisation (from btuart(4)) is carried
out prior to activating the line discipline (in btattach(8)),
which simplifies the API somewhat and means that the user
tool and the kernel do not need to be kept in sync.

btuart(4) driver is much reduced; naming is made consistent
and all tsleep() and delay() are removed to userland
1.198 Tue Apr 15 11:17:47 GMT 2008 plunky branches: 1.198.2; 1.198.4;
some changes to serial bluetooth host controller interfaces

btuartd(8) should be named btattach(8) for consistency
with other parts of NetBSD

make btattach(8) a single-use tool for less complexity

device specicific initialisation (from btuart(4)) is carried
out prior to activating the line discipline (in btattach(8)),
which simplifies the API somewhat and means that the user
tool and the kernel do not need to be kept in sync.

btuart(4) driver is much reduced; naming is made consistent
and all tsleep() and delay() are removed to userland
/src/distrib/sets/lists/misc/
H A Dmi1.198 Wed Jun 29 23:23:05 GMT 2016 christos branches: 1.198.2;
fix sets for MKCRYPTO=no
1.198 Wed Jun 29 23:23:05 GMT 2016 christos branches: 1.198.2;
fix sets for MKCRYPTO=no
/src/sys/arch/sparc64/conf/
H A DGENERIC1.198 Sat Mar 25 13:24:08 GMT 2017 martin branches: 1.198.6;
Add virtio PCI devices, some of them mostly untested so far

1.198 Sat Mar 25 13:24:08 GMT 2017 martin branches: 1.198.6;
Add virtio PCI devices, some of them mostly untested so far

/src/sys/arch/sparc64/sparc64/
H A Dtrap.c1.198 Mon May 13 00:12:33 GMT 2024 msaitoh branches: 1.198.2;
s/priviliged/privileged/

1.198 Mon May 13 00:12:33 GMT 2024 msaitoh branches: 1.198.2;
s/priviliged/privileged/

H A Dautoconf.c1.198 Fri Jul 25 17:21:32 GMT 2014 nakayama branches: 1.198.2;
Backout using humanize_number(9) in clockfreq().
humanize_number(9) cannot handle a fraction part and doesn't
match the intention of clockfreq().

Also backout the changes caused by the fallout of clockfreq().

Fixed outputs:

-cpu0 at mainbus0: MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU
+cpu0 at mainbus0: MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU

-sbus0 at iommu0: clock = 21250 MHz
+sbus0 at iommu0: clock = 21.250 MHz

-cpu0 at mainbus0: SUNW,UltraSPARC-II @ 449 MHz, CPU id 0
+cpu0 at mainbus0: SUNW,UltraSPARC-II @ 449.971 MHz, CPU id 0

1.198 Fri Jul 25 17:21:32 GMT 2014 nakayama branches: 1.198.2;
Backout using humanize_number(9) in clockfreq().
humanize_number(9) cannot handle a fraction part and doesn't
match the intention of clockfreq().

Also backout the changes caused by the fallout of clockfreq().

Fixed outputs:

-cpu0 at mainbus0: MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU
+cpu0 at mainbus0: MB86904 @ 170 MHz, MB86910 or WTL1164/5 FPU

-sbus0 at iommu0: clock = 21250 MHz
+sbus0 at iommu0: clock = 21.250 MHz

-cpu0 at mainbus0: SUNW,UltraSPARC-II @ 449 MHz, CPU id 0
+cpu0 at mainbus0: SUNW,UltraSPARC-II @ 449.971 MHz, CPU id 0

H A Dpmap.c1.198 Mon Oct 01 08:53:35 GMT 2007 martin branches: 1.198.2;
On second thought: a valid mapping is a valid mapping, period.
No need to special case the kernel pmap here.

1.198 Mon Oct 01 08:53:35 GMT 2007 martin branches: 1.198.2;
On second thought: a valid mapping is a valid mapping, period.
No need to special case the kernel pmap here.

/src/sys/arch/sun3/sun3/
H A Dmachdep.c1.198 Fri Oct 15 15:55:53 GMT 2010 tsutsui branches: 1.198.2;
Make common kernel module binaries work on both sun3 and sun3x.
Tested on 3/160 (on TME) and (real) 3/80.

XXX: module files can be loaded only on single user?

1.198 Fri Oct 15 15:55:53 GMT 2010 tsutsui branches: 1.198.2;
Make common kernel module binaries work on both sun3 and sun3x.
Tested on 3/160 (on TME) and (real) 3/80.

XXX: module files can be loaded only on single user?

/src/sys/arch/sparc/sparc/
H A Dtrap.c1.198 Sat Apr 06 03:06:27 GMT 2019 thorpej branches: 1.198.4;
Overhaul the API used to fetch and store individual memory cells in
userspace. The old fetch(9) and store(9) APIs (fubyte(), fuword(),
subyte(), suword(), etc.) are retired and replaced with new ufetch(9)
and ustore(9) APIs that can return proper error codes, etc. and are
implemented consistently across all platforms. The interrupt-safe
variants are no longer supported (and several of the existing attempts
at fuswintr(), etc. were buggy and not actually interrupt-safe).

Also augmement the ucas(9) API, making it consistently available on
all plaforms, supporting uniprocessor and multiprocessor systems, even
those that do not have CAS or LL/SC primitives.

Welcome to NetBSD 8.99.37.

1.198 Sat Apr 06 03:06:27 GMT 2019 thorpej branches: 1.198.4;
Overhaul the API used to fetch and store individual memory cells in
userspace. The old fetch(9) and store(9) APIs (fubyte(), fuword(),
subyte(), suword(), etc.) are retired and replaced with new ufetch(9)
and ustore(9) APIs that can return proper error codes, etc. and are
implemented consistently across all platforms. The interrupt-safe
variants are no longer supported (and several of the existing attempts
at fuswintr(), etc. were buggy and not actually interrupt-safe).

Also augmement the ucas(9) API, making it consistently available on
all plaforms, supporting uniprocessor and multiprocessor systems, even
those that do not have CAS or LL/SC primitives.

Welcome to NetBSD 8.99.37.

/src/lib/libc/gen/
H A DMakefile.inc1.198 Tue Feb 07 19:29:40 GMT 2017 kamil branches: 1.198.2;
Mark exect(3) obsolete and bind it to plain execve(2) on all platforms

The original exect(2) from BSD4.2 was enabling bit for tracing
(single-step mode) and calling execve(2). The purpose of it was to generate
a signal for a tracer once the application will change its image to a new
program.

This approach no longer works as:
- exect(2) traces (single-steps) libc and it requires hundreds or
thousands steps before entering a new image
- it's vax and x86 specific code
- this functionality has been moved to the kernel - once a process is
traced it will generate SIGTRAP with si_code TRAP_EXEC and route it to
its debugger
- the side effects and unportability make this interface unusable
- there are no known users of this interface
- it apparently never worked better since day0 of NetBSD ("day0 bug")

Users are requested to move to other execve(2) variants. Calling current
execve(2) as it is the most similar behavior to this one from BSD4.2.

Discussed several times on mailing lists and in PR/51700.

Add warning to exect(3) telling about marking this function obsolete.

This function is prepared to be removed in next libc major bump.

Sponsored by <The NetBSD Foundation>

1.198 Tue Feb 07 19:29:40 GMT 2017 kamil branches: 1.198.2;
Mark exect(3) obsolete and bind it to plain execve(2) on all platforms

The original exect(2) from BSD4.2 was enabling bit for tracing
(single-step mode) and calling execve(2). The purpose of it was to generate
a signal for a tracer once the application will change its image to a new
program.

This approach no longer works as:
- exect(2) traces (single-steps) libc and it requires hundreds or
thousands steps before entering a new image
- it's vax and x86 specific code
- this functionality has been moved to the kernel - once a process is
traced it will generate SIGTRAP with si_code TRAP_EXEC and route it to
its debugger
- the side effects and unportability make this interface unusable
- there are no known users of this interface
- it apparently never worked better since day0 of NetBSD ("day0 bug")

Users are requested to move to other execve(2) variants. Calling current
execve(2) as it is the most similar behavior to this one from BSD4.2.

Discussed several times on mailing lists and in PR/51700.

Add warning to exect(3) telling about marking this function obsolete.

This function is prepared to be removed in next libc major bump.

Sponsored by <The NetBSD Foundation>

/src/sys/arch/alpha/conf/
H A Dfiles.alpha1.198 Wed Mar 06 13:37:35 GMT 2024 thorpej branches: 1.198.2;
Tidy up TLSB autoconfiguration just a bit.

1.198 Wed Mar 06 13:37:35 GMT 2024 thorpej branches: 1.198.2;
Tidy up TLSB autoconfiguration just a bit.

/src/sys/nfs/
H A Dnfs_socket.c1.198 Fri Jun 17 14:28:29 GMT 2016 christos branches: 1.198.10;
Serialize all access to the NFS request queue via splsoftnet(). Fixes random
crashes.
XXX: Pullup-7

1.198 Fri Jun 17 14:28:29 GMT 2016 christos branches: 1.198.10;
Serialize all access to the NFS request queue via splsoftnet(). Fixes random
crashes.
XXX: Pullup-7

/src/usr.bin/
H A DMakefile1.198 Wed Jan 12 16:14:24 GMT 2011 pooka branches: 1.198.2;
shmif(4) bus dumping utility

1.198 Wed Jan 12 16:14:24 GMT 2011 pooka branches: 1.198.2;
shmif(4) bus dumping utility

/src/sys/dev/pcmcia/
H A Dpcmciadevs.h1.198 Wed Jul 07 05:34:33 GMT 2004 mycroft Regen.

H A Dpcmciadevs_data.h1.198 Wed Jul 07 05:34:33 GMT 2004 mycroft Regen.

/src/sys/sys/
H A Dsysctl.h1.198 Sat Nov 19 22:51:31 GMT 2011 tls branches: 1.198.2;
First step of random number subsystem rework described in
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:

An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.

A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.

The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.

An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.

A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.

An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.

In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.

The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.

The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.

A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.

The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.

Manual pages for the new kernel interfaces are forthcoming.

1.198 Sat Nov 19 22:51:31 GMT 2011 tls branches: 1.198.2;
First step of random number subsystem rework described in
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:

An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.

A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.

The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.

An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.

A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.

An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.

In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.

The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.

The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.

A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.

The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.

Manual pages for the new kernel interfaces are forthcoming.

/src/sys/uvm/
H A Duvm_page.c1.198 Sat May 19 15:03:26 GMT 2018 jdolecek branches: 1.198.2;
add experimental new function uvm_direct_process(), to allow of read/writes
of contents of uvm pages without mapping them into kernel, using
direct map or moral equivalent; pmaps supporting the interface need
to provide pmap_direct_process() and define PMAP_DIRECT

implement the new interface for amd64; I hear alpha and mips might be relatively
easy to add too, but I lack the knowledge

part of resolution for PR kern/53124

1.198 Sat May 19 15:03:26 GMT 2018 jdolecek branches: 1.198.2;
add experimental new function uvm_direct_process(), to allow of read/writes
of contents of uvm pages without mapping them into kernel, using
direct map or moral equivalent; pmaps supporting the interface need
to provide pmap_direct_process() and define PMAP_DIRECT

implement the new interface for amd64; I hear alpha and mips might be relatively
easy to add too, but I lack the knowledge

part of resolution for PR kern/53124

/src/sys/fs/puffs/
H A Dpuffs_vnops.c1.198 Tue Nov 04 09:14:42 GMT 2014 manu branches: 1.198.2;
PUFFS direct I/O cache fix

There are a few situations where we must take care of the cache if direct
I/O was enabled:
- if we do direct I/O for write but not for read, then any write must
invalidate the cache so that a reader gets the written data and not
the not-updated cache.
- if we used a vnode without direct I/O and it is enabled for writing,
we must flush the cache before compeling the open operation, so that
the cachec write are not lost.

And at inactive time, we wipe direct I/O flags so that a new open without
direct I/O does not inherit direct I/O.

1.198 Tue Nov 04 09:14:42 GMT 2014 manu branches: 1.198.2;
PUFFS direct I/O cache fix

There are a few situations where we must take care of the cache if direct
I/O was enabled:
- if we do direct I/O for write but not for read, then any write must
invalidate the cache so that a reader gets the written data and not
the not-updated cache.
- if we used a vnode without direct I/O and it is enabled for writing,
we must flush the cache before compeling the open operation, so that
the cachec write are not lost.

And at inactive time, we wipe direct I/O flags so that a new open without
direct I/O does not inherit direct I/O.

/src/sys/arch/x86/include/
H A Dspecialreg.h1.198 Mon Nov 21 00:21:17 GMT 2022 msaitoh branches: 1.198.2;
Update AMD CPUID Fn8000_001b

- Add IbsFetchCtlExtd and IbsOpData4.
- Fix typo (lbs -> Ibs).

1.198 Mon Nov 21 00:21:17 GMT 2022 msaitoh branches: 1.198.2;
Update AMD CPUID Fn8000_001b

- Add IbsFetchCtlExtd and IbsOpData4.
- Fix typo (lbs -> Ibs).

Completed in 228 milliseconds

1234567891011