Age | Commit message (Collapse) | Author |
|
ok deraadt@
|
|
|
|
media on them. Try to be helpful and explain how things may fail on the
older PROM and what to do about this.
|
|
|
|
(IP20, IP22, IP24) in 64-bit mode, adapated from NetBSD. Currently limited
to headless operation, input and video drivers will get ported soon.
Should work on all R4000, R4440 and R5000 based systems. L2 cache on R5000SC
Indy not supported yet (coming soon), R4600 not supported yet either (coming
soon as well).
Tested to boot multiuser on: Indigo2 R4000SC, Indy R4000PC, Indy R4000SC,
Indy R5000SC, Indigo2 R4400SC. There are still glitches in the Ethernet driver
which are being looked at.
Expansion support is limited to the GIO E++ board; GIO boards with PCI-GIO
bridges not ported yet due to the lack of hardware, and this kind of driver
does not port blindly.
Most of this work comes from NetBSD, polishing and integration work, as well
as putting as many ``R4x00 in 64-bit mode'' erratas as necessary, by yours
truly.
More work is coming, as well as trying to get some easy way to boot install
kernels (as older PROM can only boot ECOFF binaries, which won't do for the
kernel).
|
|
noticed / requested by claudio@
discussed with henning / claudio / me
|
|
these are obsolete and no longer available in kernel
"absolutely. ok" henning@
|
|
|
|
|
|
|
|
this diff starts ypldap before ypbind instead of after.
ok deraadt@ ajacoutot@
|
|
reminded by mikeb@
ok sthen@
|
|
|
|
mostly from Kent R. Spillner
ok sthen@ robert@
|
|
|
|
for a while now and groups are usually stored outside of People.
ok sthen@
|
|
ok miod@
|
|
|
|
usr.sbin/nginx using the distribution target
|
|
duid and device entries in fstab. As a bonus make commented out
lines in fstab in-eligable for altroot detection.
ok halex@ deraadt@
|
|
|
|
Reported by & fix tested by Dave Anderson. Thanks!
ok deraadt@
|
|
initially intended for YubiKey, jmc@ noted that list was out of date.
ok deraadt@, jmc@
|
|
ok sthen@
|
|
ok deraadt
|
|
From danh@, ok aja@ giovanni@
|
|
ok ajacoutot sthen
|
|
|
|
|
|
ok ratchov@
|
|
|
|
|
|
with input from and ok sthen@
|
|
ok sthen@
|
|
rename key1 to tsig1 to clearly identify this name as a transaction
signature digest; consistently use tsig key name on slave zone.
ok jakob@
|
|
configuration without service disruption which is not what -HUP does for
nsd(8).
Anyway, zone operations (...) should be done using nsdc(8) and not with
an rc script.
discussed with and ok sthen@
|
|
from ajacoutot@.
ok deraadt ajacoutot
|
|
out by Arne Becker, who also supplied the diff, thanks!
ok schwarze@
agreed by many
|
|
regular user, member of the operator group); rm(1) was waiting for
interactive input to remove the runfiles which made no sense, so just
use `-f'.
issue spotted by weerd@
ok weerd@ robert@
|
|
|
|
Pretty terse for now but will eventually come with some more complex
examples when ratchov@ finishes some ongoing work on aucat(1).
ok ratchov@ jmc@ deraadt@
|
|
|
|
number of audio* nodes from 3 to 1 on vax, since none of the audio-capable
vax can receive another audio device as expansion (until we get TURBOchannel
support with DMA on VS4k/90).
ok deraadt@ todd@
|
|
|
|
|
|
just leave them untouched
ok ajacoutot@ sthen@ schwarze@
|
|
server _must_ be running and accessible before ypldap is started).
Add a proper pexp in the ypldap rc script.
discussed with pyr@ robert@ deraadt@
ok deraadt@
|
|
might pick it up from a polluted environment.
Requested by halex@, ok ajacoutot@ halex@
|
|
reading it failed, ${pexp} ended up as the empty string and the script
would send SIGTERM to init(1), which was really inconvenient.
Fix that by never allowing pexp to become empty.
My patch considerably simplified by and ok ajacoutot@.
|
|
its _flags in rc.conf(8).
When the rc.d(8) system starts a daemon, it will record its pexp under
/var/run/rc.d/rcscriptname and use that to interact with it (errors in
creating /var/run/rc.d or missing pexp file are non fatal, the framework
will just fallback to what it currently does).
deraadt@ doesn't mind a long as it doesn't come in the way of people
manually managing their daemons.
discussed with and input from sthen@ halex@ robert@ schwarze@
ok sthen@ robert@
|