relax number of chunks for softraid level 1

2020-09-22 Thread Thomas de Grivel
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

2020-03-06 Thread Thomas de Grivel
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

2020-03-05 Thread Thomas de Grivel
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

2020-02-12 Thread Thomas de Grivel
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=0xE1A22D58D20C6D22
>


-- 
 Thomas de Grivel
 kmx.io



Re: syscall call-from verification

2019-12-02 Thread Thomas de Grivel
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

2019-11-29 Thread Thomas de Grivel
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

2018-09-04 Thread Thomas de Grivel
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

2018-09-04 Thread Thomas de Grivel
> 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

2018-09-03 Thread Thomas de Grivel
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

2018-09-03 Thread Thomas de Grivel
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

2018-09-03 Thread Thomas de Grivel
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

2018-09-03 Thread Thomas de Grivel
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

2011-12-02 Thread Thomas de Grivel

Le 12/02/11 06:35, Philip Guenther a icrit :

On Thu, Dec 1, 2011 at 6:45 PM, Christiano F. Haesbaert
haesba...@openbsd.org  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

2011-11-30 Thread Thomas de Grivel
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;
}



Re: problem in manual page for ip(4)

2011-08-25 Thread Thomas de Grivel

Le 08/25/11 14:44, Thomas de Grivel a icrit :

Hi,

 From ip(4) :

SYNOPSIS
#include sys/socket.h
#include netinet/in.h

However this fails :

$ cat  ip.c
#include sys/socket.h
#include netinet/in.h

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_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

problem in manual page for ip(4)

2011-08-25 Thread Thomas de Grivel
 
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 sys/types.h before sys/socket.h 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: diff: nuke a redundant check for cpu_unidle() (i386)

2010-09-29 Thread Thomas de Grivel

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

2010-08-18 Thread Thomas de Grivel

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

2010-08-17 Thread Thomas de Grivel

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)

2010-08-15 Thread Thomas de Grivel

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