Re: reorder_kernel: suport ro /usr like library_aslr does
Hello,
I use read only /usr also,
I don't like a script changing mount options without a warning.
If it's read-only reorder_kernel should fail.
I just put a symlink from /usr/share/relink to /var/relink and everything
works fine...
With mount_mfs we could have a temporary directory but where has gone mfs ?
Le mar. 8 nov. 2022 à 12:11, Klemens Nanni a écrit :
> More read-only filesystems mean less fsck during boot after crashes.
> Especially on crappy machines like the Pinebook Poop, I keep /usr
> read-only and run with this diff so I still get a relinked kernel.
>
> rc's reorder_libs() already does the same remount dance, but for
> multiple directories/filesystems.
>
> My diff works as expected with read-write and read-only /usr as well as
> interrupting /usr/libexec/reorder_kernel runs with ^C, i.e. a failed run
> will correctly mount /usr ro again if it was ro before the run.
>
> Feedback? OK?
>
> Index: reorder_kernel.sh
> ===
> RCS file: /cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
> retrieving revision 1.13
> diff -u -p -r1.13 reorder_kernel.sh
> --- reorder_kernel.sh 7 Nov 2022 15:55:56 - 1.13
> +++ reorder_kernel.sh 8 Nov 2022 11:02:42 -
> @@ -27,13 +27,32 @@ LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
> PROGNAME=${0##*/}
> SHA256=/var/db/kernel.SHA256
>
> -# Silently skip if on a NFS mounted filesystem.
> -df -t nonfs $KERNEL_DIR >/dev/null 2>&1
> +# Silently skip if on NFS, otherwise remount the filesystem read-write.
> +DEV=$(df -t nonfs $KERNEL_DIR 2>/dev/null | awk 'NR == 2 { print $1 }')
> +MP=$(mount -t ffs | grep ^$DEV)
> +RO=false
> +if [[ $MP == *read-only* ]]; then
> + MP=${MP%% *}
> + mount -u -w $MP
> + RO=true
> +fi
> +
> +restore_mount() {
> + if $RO; then
> + # Close the logfile to unbusy $MP by switching back to
> console.
> + exec 1>/dev/console
> + exec 2>&1
> + mount -u -r $MP
> + fi
> +}
>
> # Install trap handlers to inform about success or failure via syslog.
> ERRMSG='failed'
> -trap 'trap - EXIT; logger -st $PROGNAME "$ERRMSG" >/dev/console 2>&1' ERR
> -trap 'logger -t $PROGNAME "kernel relinking done"' EXIT
> +trap 'trap - EXIT
> + logger -st $PROGNAME "$ERRMSG" 2>/dev/console
> + restore_mount' ERR
> +trap 'logger -t $PROGNAME "kernel relinking done"
> + restore_mount' EXIT
>
> # Create kernel compile dir and redirect stdout/stderr to a logfile.
> mkdir -m 700 -p $KERNEL_DIR/$KERNEL
>
>
--
Thomas de Grivel
https://www.kmx.io
relax number of chunks for softraid level 1
Hello,
I couldn't but notice that the requirements on softraid level 1 in
base OpenBSD are actually lower than what the current user interface
returns.
The proposed patch does two things :
- It relaxes the check for number of chunks for raid level 1 in the kernel
- it allows building a level 1 array with only one disk.
This patch allows for the following workflow :
- Install OpenBSD on one disk
- format another disk as a single chunk RAID1
- copy the OpenBSD installation on the RAID1 disk
- check that you can boot on RAID1
- boot on bsd.rd and copy the single chunk RAID1 disk to the OpenBSD disk
- reassemble the RAID1 with two disks
It also allows reassembling a RAID1 array with a different number of
chunks, which is terribly useful I think.
-
Index: sbin/bioctl/bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.144
diff -u -p -r1.144 bioctl.c
--- sbin/bioctl/bioctl.c25 Apr 2020 14:37:43 - 1.144
+++ sbin/bioctl/bioctl.c21 Sep 2020 16:38:41 -
@@ -841,7 +841,7 @@ bio_createraid(u_int16_t level, char *de
min_disks = 2;
break;
case 1:
- min_disks = 2;
+ min_disks = 1;
break;
case 5:
min_disks = 3;
Index: sys/dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.401
diff -u -p -r1.401 softraid.c
--- sys/dev/softraid.c 14 Apr 2020 07:38:21 - 1.401
+++ sys/dev/softraid.c 21 Sep 2020 16:38:42 -
@@ -3413,7 +3413,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
} else {
/* Ensure we are assembling the correct # of chunks. */
- if (sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
+ if (bc->bc_level != 1 &&
sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
sr_error(sc, "volume chunk count does not
match metadata "
"chunk count");
goto unwind;
Index: sys/dev/softraid_raid1.c
===
RCS file: /cvs/src/sys/dev/softraid_raid1.c,v
retrieving revision 1.65
diff -u -p -r1.65 softraid_raid1.c
--- sys/dev/softraid_raid1.c12 Apr 2016 16:26:54 - 1.65
+++ sys/dev/softraid_raid1.c21 Sep 2020 16:38:42 -
@@ -76,8 +76,8 @@ int
sr_raid1_create(struct sr_discipline *sd, struct bioc_createraid *bc,
int no_chunk, int64_t coerced_size)
{
- if (no_chunk < 2) {
- sr_error(sd->sd_sc, "%s requires two or more chunks",
+ if (no_chunk < 1) {
+ sr_error(sd->sd_sc, "%s requires one or more chunks",
sd->sd_name);
return EINVAL;
}
--
Thomas de Grivel
kmx.io
Index: sbin/bioctl/bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.144
diff -u -p -r1.144 bioctl.c
--- sbin/bioctl/bioctl.c 25 Apr 2020 14:37:43 - 1.144
+++ sbin/bioctl/bioctl.c 21 Sep 2020 16:38:41 -
@@ -841,7 +841,7 @@ bio_createraid(u_int16_t level, char *de
min_disks = 2;
break;
case 1:
- min_disks = 2;
+ min_disks = 1;
break;
case 5:
min_disks = 3;
Index: sys/dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.401
diff -u -p -r1.401 softraid.c
--- sys/dev/softraid.c 14 Apr 2020 07:38:21 - 1.401
+++ sys/dev/softraid.c 21 Sep 2020 16:38:42 -
@@ -3413,7 +3413,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
} else {
/* Ensure we are assembling the correct # of chunks. */
- if (sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
+ if (bc->bc_level != 1 && sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
sr_error(sc, "volume chunk count does not match metadata "
"chunk count");
goto unwind;
Index: sys/dev/softraid_raid1.c
===
RCS file: /cvs/src/sys/dev/softraid_raid1.c,v
retrieving revision 1.65
diff -u -p -r1.65 softraid_raid1.c
--- sys/dev/softraid_raid1.c 12 Apr 2016 16:26:54 - 1.65
+++ sys/dev/softraid_raid1.c 21 Sep 2020 16:38:42 -
@@ -76,8 +76,8 @@ int
sr_raid1_create(struct sr_discipline *sd, struct bioc_createraid *bc,
int no_chunk, int64_t coerced_size)
{
- if (no_chunk < 2) {
- sr_error(sd->sd_sc, "%s requires two or more chunks",
+ if (no_chunk < 1) {
+ sr_error(sd->sd_sc, "%s requires one or more chunks",
sd->sd_name);
return EINVAL;
}
Re: Compiler warning in ctype.h
Hello, I was using base gcc but switching to base clang fixes the warnings on -current at least. Is base gcc not supported anymore ? Sorry for the noise. Cheers, Le jeu. 5 mars 2020 à 16:59, Theo de Raadt a écrit : > > Todd C. Miller wrote: > > > On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de Grivel wrote: > > > > > Actually I see the same problem on 6.6-stable : > > > including readline/readline.h produces warnings. > > > > > > Any -Werror hope some day ? > > > > You still haven't bothered to include: > > > > 1) the compiler you are using > > 2) the compiler flags to reproduce the problem > > 3) a sample program to reproduce the problem > > > > The _l parameter in those inline functions already has the __unused__ > > attribute set which is supposed to suppress those warnings. > > > > I can't reproduce this using clang (base or ports) or gcc (base or > > ports) using -Wall, -Wextra and -Wunused-parameter. But since you > > haven't provided any details, we just have to guess at what you are > > doing. > > Or not guess, but simply delete the mail -- Thomas de Grivel kmx.io
Re: Compiler warning in ctype.h
Actually I see the same problem on 6.6-stable : including readline/readline.h produces warnings. Any -Werror hope some day ? cheers Le mer. 4 mars 2020 à 13:41, Thomas de Grivel a écrit : > > With latest OpenBSD snapshot on amd64 > > In file included from /usr/include/readline/chardefs.h:26, > from /usr/include/readline/keymaps.h:36, > from /usr/include/readline/readline.h:38, > from cli.c:21: > /usr/include/ctype.h:216: warning: unused parameter '_l' > /usr/include/ctype.h:222: warning: unused parameter '_l' > /usr/include/ctype.h:228: warning: unused parameter '_l' > /usr/include/ctype.h:234: warning: unused parameter '_l' > /usr/include/ctype.h:240: warning: unused parameter '_l' > /usr/include/ctype.h:246: warning: unused parameter '_l' > /usr/include/ctype.h:252: warning: unused parameter '_l' > /usr/include/ctype.h:258: warning: unused parameter '_l' > /usr/include/ctype.h:264: warning: unused parameter '_l' > /usr/include/ctype.h:270: warning: unused parameter '_l' > /usr/include/ctype.h:276: warning: unused parameter '_l' > /usr/include/ctype.h:282: warning: unused parameter '_l' > /usr/include/ctype.h:288: warning: unused parameter '_l' > /usr/include/ctype.h:294: warning: unused parameter '_l' > > -- > Thomas de Grivel > kmx.io -- Thomas de Grivel kmx.io
Re: amdgpu (and possible radeondrm) fix
us3 at softraid0: 256 targets root on sd0a (b800c95e55295e8f.a) swap on sd0b dump on sd0b iwm0: hw rev 0x320, fw ver 34.3125811985.0, address 7c:b2:7d:1f:e4:ba initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x17AA:0x5125 0xD1). amdgpu0: 1920x1080, 32bpp wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (std, vt100 emulation) uhub0 detached ugen0 detached video0 detached uvideo0 detached video1 detached uvideo1 detached uhub2 detached uhub1 detached iwm0: acquiring device failed uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 ugen0 at uhub1 port 1 "Intel Bluetooth" rev 2.00/0.02 addr 2 uhub2 at uhub1 port 2 configuration 1 interface 0 "Genesys Logic USB2.0 Hub" rev 2.00/60.52 addr 3 uvideo0 at uhub2 port 1 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 4 video0 at uvideo0 uvideo1 at uhub2 port 1 configuration 1 interface 2 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 4 video1 at uvideo1 Le jeu. 23 janv. 2020 à 04:51, Thomas Frohwein a écrit : > > On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote: > > The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) > > as well. > [...] > > For the record, this fixes running piglit with radeon on my HD7570 since this > was committed. It used to lock up on the test spec/arb_sync/sync_api, but > now piglit completes. I haven't done further investigations how that may be > related, but though it may be good to know that this means progress with > the piglit testing suite. > -- > > tfrohw...@fastmail.com > > PGP Public Key: > https://pgp.mit.edu/pks/lookup?op=get&search=0xE1A22D58D20C6D22 > -- Thomas de Grivel kmx.io
Re: syscall call-from verification
My bad, SBCL uses the libc's wrappers indeed looking at the sources. Le ven. 29 nov. 2019 à 22:41, Josh Elsasser a écrit : > > On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote: > > Maybe Go is not the only problem, I see SBCL compiling syscalls too. > > > > Truth is libc is for C and not all programs are written in C nowadays. > > Where are you seeing SBCL compiling direct syscalls? In my testing, > SBCL self-hosts just fine under a kernel modified to disallow syscalls > from the text segment, whereas go is killed under such a kernel. Are > you sure you're not seeing SBCL compile calls to the libc syscall > wrappers? -- Thomas de Grivel kmx.io
Re: syscall call-from verification
Maybe Go is not the only problem, I see SBCL compiling syscalls too. Truth is libc is for C and not all programs are written in C nowadays. Le jeu. 28 nov. 2019 à 21:04, Theo de Raadt a écrit : > > Miod Vallat wrote: > > > > For dynamic binaries, valid regions are ld.so's text segment, the signal > > > trampoline, and libc.so's text segment... AND the main program's text. > > > > > > Unfortunately our current go build model hasn't followed solaris/macos > > > approach yet of calling libc stubs, and uses the inappropriate "embed > > > system calls directly" method, so for now we'll need to authorize the main > > > program text as well. A comment in exec_elf.c explains this. > > > > > > If go is adapted to call library-based system call stubs on OpenBSD as > > > well, this problem will go away. There may be other environments creating > > > raw system calls. I guess we'll need to find them as time goes by, and > > > hope in time we can repair those also. > > > > Or you could use an ELF note to flag binaries allowed to issue syscalls > > from their text section: only static binaries (including ld.so) and go > > binaries would need them. > > Imagine a ld.so without the flag. The kernel starts a userland process > running > there. So ld.so must be able to issue system calls > > Imagine a static binary without the flag. It would fail. > > The kernel can alreayd identify these circumstances, and does not need a flag. > > The only special case is libc.so. We discussed adding a linker option to add > a note to libc. And then build tooling to add the flag for libc. And then > ld.so > identification of this note. But does it actually matter which way this is > done? > > I fear the option would be abused for other purposes. In the future, > why would we want programs doing system calls from other segments? Are > there any legitimate compelling reasons to avoid calling the libc stubs? > I don't believe so. Especially if those segments are in network facing > programs and/or generated on the fly. At worst a nasty JIT can generate code > to call & of libc syscall(2) stub with SYS_* symbolic names. That approach > remains simple and workable for the developer, but somewhat more difficult for > an attacker who not know the relevant locations. > -- Thomas de Grivel kmx.io
Re: Add $daemon_nice to rc.subr
plus it's really 6 new lines in rc.subr, no big deal. Le mar. 4 sept. 2018 à 10:53, Thomas de Grivel a écrit : > > why ? well all interactive process get a quarter range nice priority > advance compared to all daemon tasks, at least for a laptop > environment it really makes sense. sndiod and ntpd are unaffected by > this change. > > you're right to criticize in that I did not document my code, the > point of this new variable is that an amendment to daemon priority is > no more than putting one line in /etc/rc.conf.local eg. > sshd_nice=1 > > or in the rc.d/ file > daemon_nice=whatever > > why, because it is a whole lot more readable and usable than > inheriting a whole new login class just to change one parameter, but > if you don't like it nobody foces you huh ? > > Le mar. 4 sept. 2018 à 07:57, Alexandre Ratchov a écrit : > > > > On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote: > > > > > > And I still feel the default nice priority of 10 is rather a good > > > idea. > > > > why? > > > > -- > Thomas de Grivel > http://b.lowh.net/billitch/ -- Thomas de Grivel http://b.lowh.net/billitch/
Re: Add $daemon_nice to rc.subr
> why ? why ? well all interactive process get a quarter range nice priority advance compared to all daemon tasks, at least for a laptop environment it really makes sense. sndiod and ntpd are unaffected by this change. you're right to criticize in that I did not document my code, the point of this new variable is that an amendment to daemon priority is no more than putting one line in /etc/rc.conf.local eg. sshd_nice=1 or in the rc.d/ file daemon_nice=whatever why, because it is a whole lot more readable and usable than inheriting a whole new login class just to change one parameter, but if you don't like it nobody foces you huh ? -- Thomas de Grivel http://kmx.io Le mar. 4 sept. 2018 à 07:57, Alexandre Ratchov a écrit : > > On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote: > > > > And I still feel the default nice priority of 10 is rather a good > > idea. > > why? -- Thomas de Grivel http://b.lowh.net/billitch/
Re: Add $daemon_nice to rc.subr
Thanks, good to know.
But if I actually wanted per daemon priorities with settable
configuration in rc.conf.local how would I get that ? And I still feel
the default nice priority of 10 is rather a good idea.
Le lun. 3 sept. 2018 à 23:10, Antoine Jacoutot a écrit :
>
> On Mon, Sep 03, 2018 at 10:34:51PM +0200, Thomas de Grivel wrote:
> > Hello,
>
> Hi.
>
> > Following patch allows sysadmins to configure nice values for RC daemons.
> > Default nice value is set to 10 as I wish to prioritize interactive
> > applications over system daemons and I think most probably do too.
> > It is based on OpenBSD 6.3 but might apply easily to later releases.
> > Please let me know if it is of any interest to you.
>
> We already support that.
>
> Extract from rc.d(8):
>
> daemon_class is a special read-only variable. It is set to “daemon”
> unless there is a login class configured in login.conf(5) with the same
> name as the rc.d script itself, in which case it will be set to that
> login class. This allows setting many initial process properties, for
> example environment variables, scheduling priority, and process limits
> such as maximum memory use and number of files.
>
> Extract from login.conf(5):
>
> priority number Initial priority (nice)
> level.
>
> Cheers!
>
>
> > commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
> > Author: Thomas de Grivel
> > Date: Mon Sep 3 21:52:37 2018 +0200
> >
> > Add a $daemon_nice parameter.
> > If not overriden by the launched daemon the default nice value is 10.
> > See nice(1) for more details.
> >
> > diff --git rc.d/rc.subr.orig rc.d/rc.subr
> > index 6c2f694..5f4fbe5 100644
> > --- rc.d/rc.subr.orig
> > +++ rc.d/rc.subr
> > @@ -49,6 +49,7 @@ _rc_write_runfile() {
> > cat >${_RC_RUNFILE} < > daemon_class=${daemon_class}
> > daemon_flags=${daemon_flags}
> > +daemon_nice=${daemon_nice}
> > daemon_rtable=${daemon_rtable}
> > daemon_timeout=${daemon_timeout}
> > daemon_user=${daemon_user}
> > @@ -170,7 +171,7 @@ _rc_parse_conf() {
> > [ -n "${FUNCS_ONLY}" ] && return
> >
> > rc_start() {
> > - ${rcexec} "${daemon} ${daemon_flags}"
> > + ${rcexec} "nice -n ${daemon_nice} ${daemon} ${daemon_flags}"
> > }
> >
> > rc_check() {
> > @@ -288,6 +289,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
> > _rc_do _rc_parse_conf
> >
> > eval _rcflags=\${${_name}_flags}
> > +eval _rcnice=\${${_name}_nice}
> > eval _rcrtable=\${${_name}_rtable}
> > eval _rcuser=\${${_name}_user}
> > eval _rctimeout=\${${_name}_timeout}
> > @@ -295,6 +297,7 @@ eval _rctimeout=\${${_name}_timeout}
> > # set default values; duplicated in rcctl(8)
> > getcap -f /etc/login.conf ${_name} 1>/dev/null 2>&1 &&
> > daemon_class=${_name} ||
> > daemon_class=daemon
> > +[ -z "${daemon_nice}" ] && daemon_nice=10
> > [ -z "${daemon_rtable}" ] && daemon_rtable=0
> > [ -z "${daemon_user}" ] && daemon_user=root
> > [ -z "${daemon_timeout}" ] && daemon_timeout=30
> > @@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
> > 2>&1 && daemon_class=${_name} ||
> > unset _rcflags
> >
> > [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> > +[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
> > [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
> > [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
> > [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> > @@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
> > fi
> >
> > readonly daemon_class
> > -unset _rcflags _rcrtable _rcuser _rctimeout
> > +unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
> > pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
> > rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> > [ "${daemon_rtable}" -eq 0 ] ||
> >
> >
> > --
> > Thomas de Grivel
> >
>
> --
> Antoine
--
Thomas de Grivel
http://b.lowh.net/billitch/
Re: Linux DRM
Le lun. 3 sept. 2018 à 23:33, Philip Guenther a écrit : > > On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel wrote: >> >> I was browsing the DRM code ported from Linux and it's a terrible >> mess, is there any ongoing project to clean up that codebase or >> rewrite it entirely ? > > > No. OpenBSD doesn't have the resources to reimplement the DRM subsystem or > maintain a non-trivial fork of the Linux version. We don't want to get stuck > with a code base that doesn't support close-to-current hardware, so the > porting work has concentrated on minimizing the changes necessary to make the > upstream code base work in OpenBSD. > > It's clear that the hardware support in the upstream has large contributions > from developers with inside access at the hardware vendors; without such > access it's doubtful that all the hardware bugs^Wlimitations can be worked > around with non-infinite resource. > > Improvements in the DRM code itself should be done in the upstream, not just > to minimize OpenBSD costs in this area, but so that all OSes that draw from > that base can benefit. You probably do not care and actually neither do I but that current state of graphic hardware support code is crazy in my opinion. Computer graphic cards have to be the single most successful hardware in the history of computer hardware or even hardware in general and yet their drivers are a complete mess. It makes no sense to me. It all appears like a hideous obscurity-based false sense of security where you really cannot ensure the minimality of any driver and their features. I would not be least surprised to see a few backdoors in that code, preventing OpenBSD for use for private intellectual property work, however different the advertisement can be. I sure hope I'm wrong. -- Thomas de Grivel http://kmx.io/
Linux DRM
I was browsing the DRM code ported from Linux and it's a terrible mess, is there any ongoing project to clean up that codebase or rewrite it entirely ? -- Thomas de Grivel
Add $daemon_nice to rc.subr
Hello,
Following patch allows sysadmins to configure nice values for RC daemons.
Default nice value is set to 10 as I wish to prioritize interactive
applications over system daemons and I think most probably do too.
It is based on OpenBSD 6.3 but might apply easily to later releases.
Please let me know if it is of any interest to you.
commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
Author: Thomas de Grivel
Date: Mon Sep 3 21:52:37 2018 +0200
Add a $daemon_nice parameter.
If not overriden by the launched daemon the default nice value is 10.
See nice(1) for more details.
diff --git rc.d/rc.subr.orig rc.d/rc.subr
index 6c2f694..5f4fbe5 100644
--- rc.d/rc.subr.orig
+++ rc.d/rc.subr
@@ -49,6 +49,7 @@ _rc_write_runfile() {
cat >${_RC_RUNFILE} </dev/null 2>&1 && daemon_class=${_name} ||
daemon_class=daemon
+[ -z "${daemon_nice}" ] && daemon_nice=10
[ -z "${daemon_rtable}" ] && daemon_rtable=0
[ -z "${daemon_user}" ] && daemon_user=root
[ -z "${daemon_timeout}" ] && daemon_timeout=30
@@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
2>&1 && daemon_class=${_name} ||
unset _rcflags
[ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
+[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
[ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
[ -n "${_rcuser}" ] && daemon_user=${_rcuser}
[ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
@@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
fi
readonly daemon_class
-unset _rcflags _rcrtable _rcuser _rctimeout
+unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
[ "${daemon_rtable}" -eq 0 ] ||
--
Thomas de Grivel
Re: ifconfig ieee80211 scan error to stderr
Le 12/02/11 06:35, Philip Guenther a icrit : On Thu, Dec 1, 2011 at 6:45 PM, Christiano F. Haesbaert wrote: Hi, I think we should warn() on any error, not just EPERM. This is more consistent with the rest of the code. ok ? I disagree with this. The existing message is much clearer to the non-root mortal user that gets it and, IMO, it's clearer for the message to be sent to stdout with the rest of the output from the scan. The original output is an error message sent to stdout. I think the current output is stupid : if I ask about scanning on WIF and permission is denied, I certainly don't want the mac adress and media info to be printed. As for errors other than EPERM, well, exactly what other errors *can* that call return in ifconfig? What problem are you guys trying to solve? Scripting. It's quite usual to have a one liner with interface name and error message, and not bury it inside a bunch of informations about the interface. Now if the rest is sent to stdout it's easy to send it to /dev/null and just get the error message. -- Thomas de Grivel
ifconfig ieee80211 scan error to stderr
Hi,
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.252
diff -u -p -r1.252 ifconfig.c
--- ifconfig.c26 Nov 2011 23:38:18 -1.252
+++ ifconfig.c30 Nov 2011 14:35:52 -
@@ -2169,7 +2169,7 @@ ieee80211_listnodes(void)
if (ioctl(s, SIOCS80211SCAN, (caddr_t)&ifr) != 0) {
if (errno == EPERM)
-printf("\t\tno permission to scan\n");
+fprintf(stderr, "%s: no permission to scan\n", name);
goto done;
}
? sbin_ifconfig.c-ieee80211-scan-stderr.diff
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.252
diff -u -p -r1.252 ifconfig.c
--- ifconfig.c 26 Nov 2011 23:38:18 - 1.252
+++ ifconfig.c 30 Nov 2011 14:38:25 -
@@ -2169,7 +2169,7 @@ ieee80211_listnodes(void)
if (ioctl(s, SIOCS80211SCAN, (caddr_t)&ifr) != 0) {
if (errno == EPERM)
- printf("\t\tno permission to scan\n");
+ fprintf(stderr, "%s: no permission to scan\n", name);
goto done;
}
problem in manual page for ip(4)
#x27; before 'socklen_t' /usr//include/netinet6/in6.h:819: error: expected declaration specifiers or '...' before 'u_int8_t' /usr//include/netinet6/in6.h:820: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:821: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:823: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:823: error: expected declaration specifiers or '...' before 'u_int8_t' /usr//include/netinet6/in6.h:824: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:825: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:825: error: expected declaration specifiers or '...' before 'u_int8_t' /usr//include/netinet6/in6.h:826: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:827: error: expected declaration specifiers or '...' before 'socklen_t' /usr//include/netinet6/in6.h:829: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'inet6_rth_space' /usr//include/netinet6/in6.h:830: error: expected declaration specifiers or '...' before 'socklen_t' Including before makes it ok. So either the manual is wrong or sys/socket.h or netinet/in.h is wrong. -- Thomas de Grivel http://b.lowh.net/billitch "I must plunge into the water of doubt again and again."
Re: problem in manual page for ip(4)
Le 08/25/11 14:44, Thomas de Grivel a icrit :
Hi,
From ip(4) :
SYNOPSIS
#include
#include
However this fails :
$ cat > ip.c
#include
#include
int main() {
return 0;
}
^D
$ gcc ip.c
In file included from ip.c:1:
/usr//include/sys/socket.h:105: error: expected specifier-qualifier-list
before 'off_t'
/usr//include/sys/socket.h:162: error: expected specifier-qualifier-list
before 'u_int8_t'
/usr//include/sys/socket.h:180: error: expected specifier-qualifier-list
before 'u_int8_t'
/usr//include/sys/socket.h:249: error: expected specifier-qualifier-list
before 'uid_t'
/usr//include/sys/socket.h:394: error: expected specifier-qualifier-list
before 'socklen_t'
/usr//include/sys/socket.h:420: error: expected specifier-qualifier-list
before 'socklen_t'
/usr//include/sys/socket.h:476: error: expected specifier-qualifier-list
before 'caddr_t'
In file included from ip.c:1:
/usr//include/sys/socket.h:491: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:492: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:493: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:494: error: expected declaration specifiers
or '...' before 'uid_t'
/usr//include/sys/socket.h:494: error: expected declaration specifiers
or '...' before 'gid_t'
/usr//include/sys/socket.h:495: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:496: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:497: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/sys/socket.h:499: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recv'
/usr//include/sys/socket.h:500: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recvfrom'
/usr//include/sys/socket.h:501: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'recvmsg'
/usr//include/sys/socket.h:502: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'send'
/usr//include/sys/socket.h:503: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'sendto'
/usr//include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'sendmsg'
/usr//include/sys/socket.h:506: error: expected declaration specifiers
or '...' before 'socklen_t'
In file included from ip.c:2:
/usr//include/netinet/in.h:141: error: expected specifier-qualifier-list
before 'in_addr_t'
/usr//include/netinet/in.h:225: error: expected specifier-qualifier-list
before 'u_int8_t'
/usr//include/netinet/in.h:244: error: expected specifier-qualifier-list
before 'int8_t'
In file included from /usr//include/netinet/in.h:732,
from ip.c:2:
/usr//include/netinet6/in6.h:118: error: expected
specifier-qualifier-list before 'u_int8_t'
/usr//include/netinet6/in6.h:140: error: expected
specifier-qualifier-list before 'u_int8_t'
/usr//include/netinet6/in6.h:392: error: expected
specifier-qualifier-list before 'u_long'
/usr//include/netinet6/in6.h:515: error: expected
specifier-qualifier-list before 'u_int32_t'
/usr//include/netinet6/in6.h:799: error: expected ';', ',' or ')' before
'*' token
/usr//include/netinet6/in6.h:801: error: expected '=', ',', ';', 'asm'
or '__attribute__' before '*' token
/usr//include/netinet6/in6.h:802: error: expected declaration specifiers
or '...' before 'u_int8_t'
/usr//include/netinet6/in6.h:803: error: expected declaration specifiers
or '...' before 'u_int8_t'
/usr//include/netinet6/in6.h:805: error: expected '=', ',', ';', 'asm'
or '__attribute__' before 'inet6_rthdr_space'
/usr//include/netinet6/in6.h:817: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/netinet6/in6.h:818: error: expected declaration specifiers
or '...' before 'socklen_t'
/usr//include/netinet6/in6.h:818: error: expected declaration specifiers
or '...' before 'u_int8_t'
/usr//include/netinet6/in6.h:819: error: expected declaration specifiers
or '...' before 'socklen_
make \user syntax more explicit in forward(5)
Hi I'd like to donate a small patch to share/man/man5/forward.5 It explains the \user syntax a bit more explicitly. Cheers -- Thomas de Grivel http://b.lowh.net/billitch "I must plunge into the water of doubt again and again." --- forward.5.~1.9.~Wed May 4 17:24:22 2011 +++ forward.5 Tue May 31 19:53:17 2011 @@ -35,8 +35,8 @@ Multiple entries may be specified on one line, comma separated. Additionally, a copy of all mail may be retained on the local machine using a -.Dq \euser -entry. +.Dq \eUSER +entry where USER names a valid user on the local machine. .Pp .Pa .forward files must not be group or world writable. @@ -55,7 +55,7 @@ # empty lines are ignored # #@# with whitespace on both sides may be used to start a comment -f...@bar.baz.com, \euser #@# is a comment anywhere +f...@bar.baz.com, \efoo#@# is a comment anywhere "| /usr/local/libexec/slocal -user foo" .Ed .Sh SEE ALSO
Re: diff: nuke a redundant check for cpu_unidle() (i386)
First: double checking is far from bad,
second: a test is much faster than a function call.
On 09/28/10 13:40, Vladimir Kirillov wrote:
Hello, t...@!
Subj, cpu_unidle() does that check itself.
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.481
diff -u -p -r1.481 machdep.c
--- i386/machdep.c 5 Aug 2010 21:10:09 - 1.481
+++ i386/machdep.c 28 Sep 2010 11:39:14 -
@@ -3303,8 +3303,7 @@ need_resched(struct cpu_info *ci)
/* There's a risk we'll be called before the idle threads start */
if (ci->ci_curproc) {
aston(ci->ci_curproc);
- if (ci != curcpu())
- cpu_unidle(ci);
+ cpu_unidle(ci);
}
}
Re: snapshot install, disklabel quirks
On 08/17/10 12:49, Nick Holland wrote: On 08/17/10 03:24, Thomas de Grivel wrote: For the record, i met a couple problems with the snapshot install - when selecting custom layout of an existing OpenBSD partition, the disklabel utility had kept the mount points from the auto layout, and refused that i set them, what it thought to be twice. - wifi essid and key would not be configurable but asked for IP configuration, but i guess this is expected and that there is no support for wireless installation. The rest of the install went real smooth, as usual. Platform? yeah, amd64 Snapshot date? files on cd are dated 2010-08-06 except a few dated 2010-08-05 -- Thomas de Grivel http://b.lowh.net/billitch
snapshot install, disklabel quirks
For the record, i met a couple problems with the snapshot install - when selecting custom layout of an existing OpenBSD partition, the disklabel utility had kept the mount points from the auto layout, and refused that i set them, what it thought to be twice. - wifi essid and key would not be configurable but asked for IP configuration, but i guess this is expected and that there is no support for wireless installation. The rest of the install went real smooth, as usual. -- Thomas de Grivel http://b.lowh.net/billitch
patch: diff(1) mentioning patch(1)
May seem useless but diff(1) definitely ought to mention patch(1) Index: diff.1 === RCS file: /cvs/src/usr.bin/diff/diff.1,v retrieving revision 1.37 diff -u -p -r1.37 diff.1 --- diff.1 21 Feb 2010 15:24:01 - 1.37 +++ diff.1 15 Aug 2010 14:26:46 - @@ -465,6 +465,7 @@ Differences were found. An error occurred. .El .Sh SEE ALSO +.Xr patch 1 , .Xr cmp 1 , .Xr comm 1 , .Xr diff3 1 , -- Thomas de Grivel
