Re: [PATCH] mv -P

2018-05-05 Thread attila
Theo de Raadt <dera...@openbsd.org> wrote:
> >"Theo de Raadt" <dera...@openbsd.org> wrote:
> >> attila <att...@stalphonsos.com> wrote:
> >> > Hi tech@,
> >> > 
> >> > I frequently want to move a file from one place to another and shred
> >> > the original via the rm(1) -P option.  On several occasions I have
> >> > forgotten about wanting to shred the original file when using mv(1)
> >> > instead (out of habit) and ended up losing the ability to do so easily
> >> > because mv(1) unlinks the original in the cross-filesystem case.
> >> > 
> >> > This patch adds a -P option to mv(1) that does the same thing rm -P
> >> > does in all the cases where it would normally just unlink the source
> >> > file.
> >> > 
> >> > Maybe someone else has shared my "d'oh!" moment after typing mv?
> >> > Maybe this isn't worth it and should just be dealt with using a shell
> >> > alias, but to me this feels cleaner.
> >> > 
> >> > Feedback most welcome as always.
> >> 
> >> over my dead body.
> >
> >A better answer would've been:
> >
> >POSIX gives us no way to "shred" a file and our non-standard
> >extension to rm already irks us; we don't want to add yet another
> >to mv.
> >
> >That would've made sense, and also would've been polite.  More
> >importantly it would've been better for someone to have found that in
> >the archives than what you said, which will surely leave people who
> >find it wondering why you behave this way.
> 
> att...@stalphonsos.com whoever the hell you are, you don't get to tell
> me when i am being impolite.  you are some random hiding behind an
> email address, while everyone knows exactly who I am and where I come
> from, with >20 years of opinion turned into validity under my belt (and
> some wrong, but that goes with the territory)

I'm many things but anonymous isn't one of them:

attila@xix:~ 121:$ grep attila /usr/src/sys/dev/usb/urng.c
 * Copyright (C) 2015 Sean Levy <att...@stalphonsos.com>

> On the other hand, random mostly-anon people who aren't brave enough
> to put their full credentials into their email address tend to have
> close to zero influence.  Shocking isn't it?  Know how to fix that?

Nothing to fix.  Those of us with Jewish last names who aren't
zionists frequently take the approach of not blasting our last names
across the net in every communication because we've learned that
zionists are aggressive and it doesn't make sense to make it easy for
them to target/abuse you.  None the less, I've never made a secret of
who I am or that attila = Sean Levy, I just prefer not to use the
latter in casual communication.  Anything of mine in your trees has
had my real name attached to it since it was imported.

> So your opinion (AND JUDGEMENT ME OF) counts for far less, and you
> should (a) consider your idiotic position, (b) recognize you aren't
> someone who can land / not land the proposed change, and (c) realize
> randoms on the internet/unix don't succeed change the internet/unix -
> much to their anonymous nature, oh the dismay, oh my god.

The substance of your screed comes down to: "Don't you know who I am?"

> Over my dead body I said.
> 
> I mean it.  I will not permit the stupidity.  Nor will I accept the
> stupidity of trying to call me out for calling out the stupid.

So in your view you were "calling out the stupid" by answering a patch
with "over my dead body," and my objecting to your rudeness is also
stupidity.  This is not an interpretation that too many people I've
met in real life would share, but I guess that isn't the case here.

Good to know.

You also sent me a private email which was ruder and more direct.  In
it you ask me what gives me the right... to do what, I'm not sure, but
I guess you mean: what gives me the right to call out your rudeness?

Every person born has that right, Theo.  Everyone has the right to
reject rudeness directed at them.

Pax, -A
-- 
https://haqistan.net/~attila | attila@{stalphonsos.com,haqistan.net}
pgp: 0x62A729CF | C2CE 2487 03AC 4C2F 101D  09C1 4068 D5D5 62A7 29CF



Re: [PATCH] mv -P

2018-04-29 Thread attila
"Theo de Raadt" <dera...@openbsd.org> wrote:
> attila <att...@stalphonsos.com> wrote:
> > Hi tech@,
> > 
> > I frequently want to move a file from one place to another and shred
> > the original via the rm(1) -P option.  On several occasions I have
> > forgotten about wanting to shred the original file when using mv(1)
> > instead (out of habit) and ended up losing the ability to do so easily
> > because mv(1) unlinks the original in the cross-filesystem case.
> > 
> > This patch adds a -P option to mv(1) that does the same thing rm -P
> > does in all the cases where it would normally just unlink the source
> > file.
> > 
> > Maybe someone else has shared my "d'oh!" moment after typing mv?
> > Maybe this isn't worth it and should just be dealt with using a shell
> > alias, but to me this feels cleaner.
> > 
> > Feedback most welcome as always.
> 
> over my dead body.

A better answer would've been:

POSIX gives us no way to "shred" a file and our non-standard
extension to rm already irks us; we don't want to add yet another
to mv.

That would've made sense, and also would've been polite.  More
importantly it would've been better for someone to have found that in
the archives than what you said, which will surely leave people who
find it wondering why you behave this way.

Pax, -A
-- 
https://haqistan.net/~attila | attila@{stalphonsos.com,haqistan.net}
pgp: 0x62A729CF | C2CE 2487 03AC 4C2F 101D  09C1 4068 D5D5 62A7 29CF



[PATCH] mv -P

2018-04-28 Thread attila
Hi tech@,

I frequently want to move a file from one place to another and shred
the original via the rm(1) -P option.  On several occasions I have
forgotten about wanting to shred the original file when using mv(1)
instead (out of habit) and ended up losing the ability to do so easily
because mv(1) unlinks the original in the cross-filesystem case.

This patch adds a -P option to mv(1) that does the same thing rm -P
does in all the cases where it would normally just unlink the source
file.

Maybe someone else has shared my "d'oh!" moment after typing mv?
Maybe this isn't worth it and should just be dealt with using a shell
alias, but to me this feels cleaner.

Feedback most welcome as always.

Pax, -A
--
https://haqistan.net/~attila | attila@{stalphonsos.com,haqistan.net}
pgp: 0x62A729CF | C2CE 2487 03AC 4C2F 101D  09C1 4068 D5D5 62A7 29CF

diff --git a/bin/mv/mv.1 b/bin/mv/mv.1
index b269c67..571eb6a 100644
--- a/bin/mv/mv.1
+++ b/bin/mv/mv.1
@@ -41,10 +41,10 @@
 .Nd move files
 .Sh SYNOPSIS
 .Nm mv
-.Op Fl fiv
+.Op Fl fiPv
 .Ar source target
 .Nm mv
-.Op Fl fiv
+.Op Fl fiPv
 .Ar source ... directory
 .Sh DESCRIPTION
 In its first form, the
@@ -103,6 +103,16 @@ The
 option overrides any previous
 .Fl f
 options.
+.It Fl P
+Overwrite regular files before deleting them,
+in the case where the source and destination are on
+different file systems.
+Files are overwritten once with a random pattern.
+Files with multiple links will be unlinked but not overwritten,
+as the with
+.Xr rm 1
+.Fl P
+option.
 .It Fl v
 Display the source and destination after each move.
 .El
diff --git a/bin/mv/mv.c b/bin/mv/mv.c
index cf8e07b..8831925 100644
--- a/bin/mv/mv.c
+++ b/bin/mv/mv.c
@@ -49,9 +49,11 @@
 #include 
 #include 
 
+#define MAXIMUM(a, b)	(((a) > (b)) ? (a) : (b))
+
 extern char *__progname;
 
-int fflg, iflg, vflg;
+int fflg, iflg, vflg, Pflg;
 int stdin_ok;
 
 extern int cpmain(int argc, char **argv);
@@ -60,6 +62,9 @@ extern int rmmain(int argc, char **argv);
 int	mvcopy(char *, char *);
 int	do_move(char *, char *);
 int	fastcopy(char *, char *, struct stat *);
+int	do_unlink(char *, struct stat *);
+int	rm_overwrite(char *, struct stat *);
+int	pass(int, off_t, char *, size_t);
 void	usage(void);
 
 int
@@ -71,7 +76,7 @@ main(int argc, char *argv[])
 	int ch;
 	char path[PATH_MAX];
 
-	while ((ch = getopt(argc, argv, "ifv")) != -1)
+	while ((ch = getopt(argc, argv, "ifvP")) != -1)
 		switch (ch) {
 		case 'i':
 			fflg = 0;
@@ -84,6 +89,9 @@ main(int argc, char *argv[])
 		case 'v':
 			vflg = 1;
 			break;
+		case 'P':
+			Pflg = 1;
+			break;
 		default:
 			usage();
 		}
@@ -244,7 +252,7 @@ do_move(char *from, char *to)
 	 *	current source file...
 	 */
 	if (!lstat(to, )) {
-		if ((S_ISDIR(sb.st_mode)) ? rmdir(to) : unlink(to)) {
+		if ((S_ISDIR(sb.st_mode)) ? rmdir(to) : do_unlink(to, )) {
 			warn("can't remove %s", to);
 			return (1);
 		}
@@ -299,7 +307,7 @@ fastcopy(char *from, char *to, struct stat *sbp)
 		}
 	if (nread < 0) {
 		warn("%s", from);
-err:		if (unlink(to))
+err:		if (do_unlink(to, NULL))
 			warn("%s: remove", to);
 		(void)close(from_fd);
 		(void)close(to_fd);
@@ -341,7 +349,7 @@ err:		if (unlink(to))
 		return (1);
 	}
 
-	if (unlink(from)) {
+	if (do_unlink(from, sbp)) {
 		warn("%s: remove", from);
 		return (1);
 	}
@@ -384,11 +392,99 @@ mvcopy(char *from, char *to)
 	return (0);
 }
 
+int
+do_unlink(char *file, struct stat *sbp)
+{
+	struct stat sb;
+
+	if (sbp == NULL) {
+		if (lstat(file, )) {
+			warn("%s", file);
+			return (1);
+		}
+		sbp = 
+	}
+	if (Pflg && !rm_overwrite(file, sbp))
+		return (1);
+	if (unlink(file)) {
+		return (1);
+	}
+	return (0);
+}
+
+int
+rm_overwrite(char *file, struct stat *sbp)
+{
+	struct stat sb, sb2;
+	struct statfs fsb;
+	size_t bsize;
+	int fd;
+	char *buf = NULL;
+
+	fd = -1;
+	if (sbp == NULL) {
+		if (lstat(file, ))
+			goto err;
+		sbp = 
+	}
+	if (!S_ISREG(sbp->st_mode))
+		return (1);
+	if (sbp->st_nlink > 1) {
+		warnx("%s (inode %llu): not overwritten due to multiple links",
+		file, (unsigned long long)sbp->st_ino);
+		return (0);
+	}
+	if ((fd = open(file, O_WRONLY|O_NONBLOCK|O_NOFOLLOW, 0)) == -1)
+		goto err;
+	if (fstat(fd, ))
+		goto err;
+	if (sb2.st_dev != sbp->st_dev || sb2.st_ino != sbp->st_ino ||
+	!S_ISREG(sb2.st_mode)) {
+		errno = EPERM;
+		goto err;
+	}
+	if (fstatfs(fd, ) == -1)
+		goto err;
+	bsize = MAXIMUM(fsb.f_iosize, 1024U);
+	if ((buf = malloc(bsize)) == NULL)
+		err(1, "%s: malloc", file);
+
+	if (!pass(fd, sbp->st_size, buf, bsize))
+		goto err;
+	if (fsync(fd))
+		goto err;
+	close(fd);
+	free(buf);
+	if (vflg)
+		(void)fprintf(stderr, "# overwrote %s\n", file);
+	return (1);
+
+err:
+	warn("%s", file);
+	close(fd);
+	free(buf);
+	return (0);
+}
+
+int
+pass(int fd, off_t len, char *buf, size_t bsize)
+{
+	size_t wlen;
+
+	for (; len 

jot(1) bugs, test suite

2016-07-25 Thread attila
Hi tech@,

After the recent discussion on jot I noticed there were no tests for
it.  I looked around and saw that FreeBSD had what looked like decent
jot tests, so I brought them into my tree.  They appear to have
discovered a couple of bugs and I'd like some help in sorting it out.
The current state of the suite in my tree is the first patch attached
to this email.

There is one piece of low-hanging fruit that I picked early on: the
second patch attached fixes a regression in test , which does:
  $ jot - - - -
On OpenBSD this spits out an infinite number of zeros, on FreBSD (and
NetBSD) it spits out the integers from 1 .. 100.  My patch is what
both FreeBSD and NetBSD do (initialize begin, ender, reps, s at
compile time).  It does not cause additional regressions so far as
these tests are concerned, FWIW.

I was hoping to say something intelligent at least about the rest of
the failures but I'm still slogging through them and it's taking me
longer than I'd like.  The four dashes bug seemed serious enough to me
to warrant bugging you all at this point in the cycle, I apologize in
advance if I misjudged.

Feedback, comments, criticism most welcome.

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
? 3test.sh
Index: Makefile
===
RCS file: Makefile
diff -N Makefile
--- /dev/null	1 Jan 1970 00:00:00 -
+++ Makefile	22 Jul 2016 21:15:38 -
@@ -0,0 +1,11 @@
+#	$OpenBSD$
+
+JOT?=jot
+
+regress:
+	m4 regress.m4 regress.sh | env JOT=${JOT} sh
+
+clean:
+	rm -f test.*.out
+
+.include 
Index: regress.ascii.out
===
RCS file: regress.ascii.out
diff -N regress.ascii.out
Binary files /dev/null and regress.ascii.out differ
Index: regress.block.out
===
RCS file: regress.block.out
diff -N regress.block.out
--- /dev/null	1 Jan 1970 00:00:00 -
+++ regress.block.out	22 Jul 2016 21:15:38 -
@@ -0,0 +1,512 @@
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
+x
Index: regress..out
===
RCS file: regress..out
diff -N regress..out
--- /dev/null	1 Jan 1970 00:00:00 -
+++ regress..out	22 Jul 2016 21:15:38 -
@@ -0,0 +1,100 @@
+1
+2
+3
+4
+5
+6
+7
+8
+9
+10
+11
+12
+13
+14
+15
+16
+17
+18
+19
+20
+21
+22
+23
+24
+25
+26
+27
+28
+29
+30
+31
+32
+33
+34
+35
+36
+37
+38
+39
+40
+41
+42
+43
+44
+45
+46
+47
+48
+49
+50
+51
+52
+53
+54
+55
+56
+57
+58
+59
+60
+61
+62
+63
+64
+65
+66
+67
+68
+69
+70
+71
+72
+73
+74
+75
+76
+77
+78
+79
+80
+81
+82
+83
+84
+85
+86
+87
+88
+89
+90
+91
+92
+93
+94
+95
+96
+97
+98
+99
+100
Index: regress.dddh.out
===
RCS file: regress.dddh.out
diff -N regress.dddh.out
--- /dev/null	1 Jan 1970 00:00:00 -
+++ regress.dddh.out	22 Jul 2016 21:15:38 -
@@ -0,0 +1,100 @@
+1
+3
+5
+7
+9
+11
+13
+15
+17
+19
+21
+23
+25
+27
+29
+31
+33
+35
+37
+39
+41
+43
+45
+47
+49
+51
+53
+55
+57
+59
+61
+63
+65
+67
+69
+71
+73
+75
+77
+79
+81
+83
+85
+87
+89
+91
+93
+95
+97
+99
+101
+103
+105
+107
+109
+111
+113
+115
+117
+119
+121
+123
+125
+127
+129
+131
+133
+135
+137
+139
+141
+143
+145
+147
+149
+151
+153
+155
+157
+159
+161
+163
+165
+167
+169
+171
+173
+175
+177
+179
+181
+183
+185
+187
+189
+191
+193
+195
+197
+199
Index: regress.ddhd.out

Re: [patch] netcat: don't call report_connect() when family == AF_UNIX

2016-05-28 Thread attila

Bob Beck <b...@obtuse.com> writes:

>> Hi tech@,
>> 
>> I just ran into this while fiddling with some netcat-based plumbing.
>> When I connect to the specified socket from another shell, the
>> listening nc dies if it is AF_UNIX:
>> 
>> $ tail -10f /var/log/messages | nc -vkU -l ~/.xlog_socket
>> nc: getnameinfo: Invalid argument
>> 
>> The attached patch fixes the issue:
>> 
>> $ tail -10f /var/log/messages | \
>> /usr/obj/usr.bin/nc/nc -vkU -l ~/.xlog_socket
>> Connection on /home/attila/.xlog_socket received!
>> 
>> Feedback, comments most welcome.
>> 
>> Pax, -A
>
> How's this instead for you.. (Inspired by your diff.. thanks)

After I applied yours I saw something minor.  Attached is your patch
KNF'ed (80cols).  There appear to still be a few long lines elsewhere,
so maybe it's too much of a nit...

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.150
diff -u -p -r1.150 netcat.c
--- netcat.c	4 Jan 2016 02:18:31 -	1.150
+++ netcat.c	28 May 2016 20:04:14 -
@@ -133,7 +133,7 @@ int	unix_listen(char *);
 void	set_common_sockopts(int, int);
 int	map_tos(char *, int *);
 int	map_tls(char *, int *);
-void	report_connect(const struct sockaddr *, socklen_t);
+void	report_connect(const struct sockaddr *, socklen_t, char *);
 void	report_tls(struct tls *tls_ctx, char * host, char *tls_expectname);
 void	usage(int);
 ssize_t drainbuf(int, unsigned char *, size_t *, struct tls *);
@@ -516,7 +516,8 @@ main(int argc, char *argv[])
 	err(1, "connect");
 
 if (vflag)
-	report_connect((struct sockaddr *), len);
+	report_connect(
+	(struct sockaddr *), len, NULL);
 
 readwrite(s, NULL);
 			} else {
@@ -528,7 +529,9 @@ main(int argc, char *argv[])
 	err(1, "accept");
 }
 if (vflag)
-	report_connect((struct sockaddr *), len);
+	report_connect(
+	(struct sockaddr *), len,
+	family == AF_UNIX ? host : NULL);
 if ((usetls) &&
 (tls_cctx = tls_setup_server(tls_ctx, connfd, host)))
 	readwrite(connfd, tls_cctx);
@@ -1487,12 +1490,17 @@ report_tls(struct tls * tls_ctx, char * 
 }
 
 void
-report_connect(const struct sockaddr *sa, socklen_t salen)
+report_connect(const struct sockaddr *sa, socklen_t salen, char *path)
 {
 	char remote_host[NI_MAXHOST];
 	char remote_port[NI_MAXSERV];
 	int herr;
 	int flags = NI_NUMERICSERV;
+
+	if (path != NULL) {
+		fprintf(stderr, "Connection on %s received!\n", path);
+		return;
+	}
 
 	if (nflag)
 		flags |= NI_NUMERICHOST;


Re: [patch] netcat: don't call report_connect() when family == AF_UNIX

2016-05-28 Thread attila

Bob Beck <b...@obtuse.com> writes:

>> Hi tech@,
>> 
>> I just ran into this while fiddling with some netcat-based plumbing.
>> When I connect to the specified socket from another shell, the
>> listening nc dies if it is AF_UNIX:
>> 
>> $ tail -10f /var/log/messages | nc -vkU -l ~/.xlog_socket
>> nc: getnameinfo: Invalid argument
>> 
>> The attached patch fixes the issue:
>> 
>> $ tail -10f /var/log/messages | \
>> /usr/obj/usr.bin/nc/nc -vkU -l ~/.xlog_socket
>> Connection on /home/attila/.xlog_socket received!
>> 
>> Feedback, comments most welcome.
>> 
>> Pax, -A
>
> How's this instead for you.. (Inspired by your diff.. thanks)
>

Preferable to my patch.  Thanks for looking at it!

Also: I noticed there are no regression tests for netcat, so I'm
writing one at least to test this case.  Any requests or thoughts on
others?  I have a couple obvious ideas, input most welcome.

> Index: netcat.c
> ===
> RCS file: /cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.150
> diff -u -p -u -p -r1.150 netcat.c
> --- netcat.c  4 Jan 2016 02:18:31 -   1.150
> +++ netcat.c  28 May 2016 17:32:01 -
> @@ -133,7 +133,7 @@ int   unix_listen(char *);
>  void set_common_sockopts(int, int);
>  int  map_tos(char *, int *);
>  int  map_tls(char *, int *);
> -void report_connect(const struct sockaddr *, socklen_t);
> +void report_connect(const struct sockaddr *, socklen_t, char *);
>  void report_tls(struct tls *tls_ctx, char * host, char *tls_expectname);
>  void usage(int);
>  ssize_t drainbuf(int, unsigned char *, size_t *, struct tls *);
> @@ -516,7 +516,7 @@ main(int argc, char *argv[])
>   err(1, "connect");
>  
>   if (vflag)
> - report_connect((struct sockaddr *), 
> len);
> + report_connect((struct sockaddr *), 
> len, NULL);
>  
>   readwrite(s, NULL);
>   } else {
> @@ -528,7 +528,8 @@ main(int argc, char *argv[])
>   err(1, "accept");
>   }
>   if (vflag)
> - report_connect((struct sockaddr 
> *), len);
> + report_connect((struct sockaddr 
> *), len,
> + family == AF_UNIX ? host : NULL);
>   if ((usetls) &&
>   (tls_cctx = tls_setup_server(tls_ctx, 
> connfd, host)))
>   readwrite(connfd, tls_cctx);
> @@ -1487,12 +1488,17 @@ report_tls(struct tls * tls_ctx, char * 
>  }
>  
>  void
> -report_connect(const struct sockaddr *sa, socklen_t salen)
> +report_connect(const struct sockaddr *sa, socklen_t salen, char *path)
>  {
>   char remote_host[NI_MAXHOST];
>   char remote_port[NI_MAXSERV];
>   int herr;
>   int flags = NI_NUMERICSERV;
> +
> + if (path != NULL) {
> + fprintf(stderr, "Connection on %s received!\n", path);
> + return;
> + }
>  
>   if (nflag)
>   flags |= NI_NUMERICHOST;

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF



[patch] netcat: don't call report_connect() when family == AF_UNIX

2016-05-28 Thread attila
Hi tech@,

I just ran into this while fiddling with some netcat-based plumbing.
When I connect to the specified socket from another shell, the
listening nc dies if it is AF_UNIX:

$ tail -10f /var/log/messages | nc -vkU -l ~/.xlog_socket
nc: getnameinfo: Invalid argument

The attached patch fixes the issue:

$ tail -10f /var/log/messages | \
/usr/obj/usr.bin/nc/nc -vkU -l ~/.xlog_socket
Connection on /home/attila/.xlog_socket received!

Feedback, comments most welcome.

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.150
diff -u -p -r1.150 netcat.c
--- netcat.c	4 Jan 2016 02:18:31 -	1.150
+++ netcat.c	28 May 2016 16:31:27 -
@@ -527,8 +527,16 @@ main(int argc, char *argv[])
 	/* For now, all errnos are fatal */
 	err(1, "accept");
 }
-if (vflag)
-	report_connect((struct sockaddr *), len);
+if (vflag) {
+	if (family == AF_UNIX)
+		fprintf(stderr,
+		"Connection on %s "
+		"received!\n", host);
+	else
+		report_connect(
+		(struct sockaddr *),
+		len);
+}
 if ((usetls) &&
 (tls_cctx = tls_setup_server(tls_ctx, connfd, host)))
 	readwrite(connfd, tls_cctx);


Re: [patch] Add percentage done to fsck_ffs SIGINFO output

2016-05-25 Thread attila

attila <att...@stalphonsos.com> writes:

> Hi tech@,
>
> The subject says it all.  I find myself doing this in my head as I hit
> ^T when fsck'ing.  FreeBSD has this, NetBSD does not, FWIW...
>

Whoops, that's wrong.  NetBSD does have it, it looks like FreeBSD in
this regard.  Sorry for the incorrect information.

> Feedback, comments most welcome.  Patch attached.  Tested lightly on
> i386 (after a hilarious few minutes trying to set up a scenario
> screwed up enough that fsck took long enough to sneak a ^T in there).
>
> Pax, -A

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF



[patch] Add percentage done to fsck_ffs SIGINFO output

2016-05-25 Thread attila
Hi tech@,

The subject says it all.  I find myself doing this in my head as I hit
^T when fsck'ing.  FreeBSD has this, NetBSD does not, FWIW...

Feedback, comments most welcome.  Patch attached.  Tested lightly on
i386 (after a hilarious few minutes trying to set up a scenario
screwed up enough that fsck took long enough to sneak a ^T in there).

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF
Index: pass1.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass1.c,v
retrieving revision 1.43
diff -u -p -r1.43 pass1.c
--- pass1.c	22 Aug 2015 06:00:27 -	1.43
+++ pass1.c	25 May 2016 17:19:47 -
@@ -55,8 +55,10 @@ static ino_t info_inumber;
 static int
 pass1_info(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 1, inode %llu/%llu",
+	return (snprintf(buf, buflen, "phase 1, inode %llu/%llu (%llu%%)",
 	(unsigned long long)info_inumber,
+	(unsigned long long)sblock.fs_ipg * sblock.fs_ncg,
+	(unsigned long long)info_inumber * 100 /
 	(unsigned long long)sblock.fs_ipg * sblock.fs_ncg) > 0);
 }
 
Index: pass1b.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass1b.c,v
retrieving revision 1.21
diff -u -p -r1.21 pass1b.c
--- pass1b.c	20 Jan 2015 18:22:21 -	1.21
+++ pass1b.c	25 May 2016 17:19:47 -
@@ -47,8 +47,10 @@ static ino_t info_inumber;
 static int
 pass1b_info(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 1b, inode %llu/%llu",
+	return (snprintf(buf, buflen, "phase 1b, inode %llu/%llu (%llu%%)",
 	(unsigned long long)info_inumber,
+	(unsigned long long)sblock.fs_ipg * sblock.fs_ncg,
+	(unsigned long long)info_inumber * 100 /
 	(unsigned long long)sblock.fs_ipg * sblock.fs_ncg) > 0);
 }
 
Index: pass2.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass2.c,v
retrieving revision 1.37
diff -u -p -r1.37 pass2.c
--- pass2.c	20 Jan 2015 18:22:21 -	1.37
+++ pass2.c	25 May 2016 17:19:47 -
@@ -56,8 +56,8 @@ static int info_pos;
 static int
 pass2_info1(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 2, directory %d/%d",
-	info_pos, info_max) > 0);
+	return (snprintf(buf, buflen, "phase 2, directory %d/%d (%d%%)",
+	info_pos, info_max, info_pos * 100 / info_max) > 0);
 }
 
 static int
Index: pass3.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass3.c,v
retrieving revision 1.18
diff -u -p -r1.18 pass3.c
--- pass3.c	20 Jan 2015 18:22:21 -	1.18
+++ pass3.c	25 May 2016 17:19:47 -
@@ -42,8 +42,8 @@ static int info_pos;
 static int
 pass3_info(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 3, directory %d/%ld",
-	info_pos, inplast) > 0);
+	return (snprintf(buf, buflen, "phase 3, directory %d/%ld (%ld%%)",
+	info_pos, inplast, info_pos * 100 / inplast) > 0);
 }
 
 void
Index: pass4.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass4.c,v
retrieving revision 1.24
diff -u -p -r1.24 pass4.c
--- pass4.c	20 Jan 2015 18:22:21 -	1.24
+++ pass4.c	25 May 2016 17:19:48 -
@@ -47,8 +47,10 @@ static ino_t info_inumber;
 static int
 pass4_info(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 4, inode %llu/%llu",
+	return (snprintf(buf, buflen, "phase 4, inode %llu/%llu (%llu%%)",
 	(unsigned long long)info_inumber,
+	(unsigned long long)lastino,
+	(unsigned long long)info_inumber * 100 /
 	(unsigned long long)lastino) > 0);
 }
 
Index: pass5.c
===
RCS file: /cvs/src/sbin/fsck_ffs/pass5.c,v
retrieving revision 1.48
diff -u -p -r1.48 pass5.c
--- pass5.c	20 Jan 2015 18:22:21 -	1.48
+++ pass5.c	25 May 2016 17:19:48 -
@@ -54,8 +54,8 @@ static int info_maxcg;
 static int
 pass5_info(char *buf, size_t buflen)
 {
-	return (snprintf(buf, buflen, "phase 5, cg %d/%d",
-	info_cg, info_maxcg) > 0);
+	return (snprintf(buf, buflen, "phase 5, cg %d/%d (%d%%)",
+	info_cg, info_maxcg, info_cg * 100 / info_maxcg) > 0);
 }
 
 void


Re: Scheduler hack for multi-threaded processes

2016-03-26 Thread attila

Jyri Hovila [Turvamies.fi] <jyri.hov...@turvamies.fi> writes:

> I can report significant usability improvement on a single core ThinkPad T42 
> and a dual core ThinkPad X60.
>

I hate to crap on this wonderful parade, but on my T60 (i386, dmesg at
bottom) running 25 march snap the heat has bumped a full 10DegC from
what was "normal" before.  I'm sorry for the lack of science here and
I have no hard numbers w/wo patch yet but in the past my steady state
on this machine w/o firefox was something like 70DegC, w/just some
xterms and emacs (aka life).  Starting firefox generally added 10DegC
before I did anything at all and I always had to watch the heat and
kill firefox when we crossed 95DegC or Bad Things Happened; thus I
live with w3m in one hand and treat firefox as some kind of
luxury... tor-browser was, strangely, less hard on things but maybe
that's just because I never have too many tabs there (also, maybe
firefox-esr is a little lighter, not sure).

Now it will be a challenge to see if I can cvs up, back out the patch
and build a kernel without ringing the bell (100DegC).  I freely admit
this is an old, P.O.S. laptop and that there might be some HW issue
(fan seems fine but I haven't taken it apart and really looked).  It
does seem like the difference in the scheduler has a remarkable effect
on heat in my case.

Does anyone else see this?


> It's not just "the videos in Firefox" - everything works *so* much more 
> fluently with the patch there's no way I would go back living without it.

It never occurs to me to try watching videos in firefox.  I think I'm
just old.

> I know a hack is a hack and I know there are many unknowns there, but at 
> least from the perspective of a "normal" OpenBSD desktop user, this patch is 
> an absolute must.
>
> Let's not start a flame war here, just throwing in my five cents.

"Flame war" has added meaning in my case :-).

> Kudos to Martin.
>
> -j.

I appreciate all the great work as always.  OpenBSD rules... and yes,
I need a new laptop.

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF



OpenBSD 5.9-current (GENERIC.MP) #1677: Fri Mar 25 14:19:24 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
real mem  = 2145730560 (2046MB)
avail mem = 2092142592 (1995MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 03/21/11, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 
0xe0010 (68 entries)
bios0: vendor LENOVO version "79ETE7WW (2.27 )" date 03/21/2011
bios0: LENOVO 2008VRQ
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT 
SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU T2400 @ 1.83GHz ("GenuineIntel" 686-class) 1.83 
GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF,SENSOR
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus 4 (EXP2)
acpiprt5 at acpi0: bus 12 (EXP3)
acpiprt6 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 
halt), PSS
acpicpu1 at acpi0: !C3(250@17 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1 
halt), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4504" serial 41199 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
bios0: ROM list: 0xc/0xfe00 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 
0xe/0x1!

Re: [PATCH] pkg-config compare() fails for libevent (at least)

2015-08-14 Thread attila

Jasper Lievisse Adriaanse jas...@openbsd.org writes:

 On Thu, Aug 13, 2015 at 04:09:02PM -0500, attila wrote:
 
 Jasper Lievisse Adriaanse jas...@openbsd.org writes:
 
  On Tue, Aug 11, 2015 at 01:20:24PM -0500, attila wrote:
  Hello tech@,
  
  On the 6 Aug snap I ran into this issue:
  
$ pkg_info | grep libevent
libevent-2.0.22 event notification library
$ pkg-config --atleast-version=2.0.1 libevent  echo yes
Argument 22-stabl isn't numeric in numeric eq (==) at 
  /usr/bin/pkg-config line 662.
yes
  
  So it works but spits out that error.  The issue is that the libevent
  port reports its version as 2.0.22-stable, which does not follow the
  convention used by the compare() sub in pkg-config.  The attached
  patch gets rid of the error albeit in a very pointilistic way; perhaps
  a more general solution is desired, but I'm not sure what the best
  approach is, especially given that there is something called
  pkg-config available pretty much everywhere but based on very
  different implementations...
  
  It doesn't appear as though my patch introduces any regressions,
  although I'm still sussing out how the regression tests work so I'm
  not sure if I'm doing anything wrong... it appears that five of
  pkg-config's regression tests fail regardless of my patch:
  
FAIL usr.bin/pkg-config/static-cflags2
FAIL usr.bin/pkg-config/static-libs2
FAIL usr.bin/pkg-config/static-libs3
FAIL usr.bin/pkg-config/static-libs4
FAIL usr.bin/pkg-config/missing-req-2
  
  In all cases it looks like the difference is ordering, except for the
  last where two errors are produced but only one is expected.  I'll
  work on a patch to fix these failures next.
  That's indeed the case and patches to fix that are welcome.
   
  Feedback, comments most welcome.
  Could you please add regress tests for this issue you're solving too?
 
 This turned out to be not so much difficult as cognitive
 dissonance-inducing.  The details are numbingly boring but I'll
 happily discuss if there's an issue.  In the end I have done what you
 asked.
 
 The first patch attached modifies pkg-config itself in the following
 ways:
 
 * Adds a (looks like libevent-specific) fix to compare() so that
   libevent's version number in e.g. libevent.pc (2.0.22-stable) does
   not cause warnings;
 * Hoists the code that redirected stderr - stdout when
   --errors-to-stdout was specified from say_msg() into the main
   program, so that such warnings (if they ever appear again) appear in
   the .got files produced by regression tests;
 * Cleans up a couple stylistic nits (add a space between ) and {)
   in a few places to be consistent with how all the other Perl code
   looks.
 
 The second patch attached cleans up the failing regression tests.
 I've verified that our pkg-config produces the same output as the(a?)
 one on at least Linux given our test cases, and manually examined all
 the output.  It looks right to me.
 
 As always feedback, comments, beatings most welcome.
 Could you please send the spacing as a separate diff? I'm fine with that going
 in first, but it's making it less obvious where the real goodies are ;-)


This is reminding me of a Troma movie: I keep sticking a fork in its
eye but the beast just won't go down...

Forget my previous patches.  There are two new patches attached.

First patch in src/usr.bin/pkg-config does the following:

1. Factors out the regular expression used to check a version number
   into a variable so that we have the same idea about this
   everywhere;
2. Uses this regexp in the main loop;
3. Uses this regexp in compare() and adjusts the captured subexp
   variables used to get the components of the optional suffix
   e.g. alpha1;
4. Hoists the stderr-stdout redirection code to early in the main
   program for the same reason my previous patch did (which, BTW,
   helped me find bugs in my patch after earlier versions of it caused
   other regression tests to fail, so... yay?).

Second patch in src/regress/usr.bin/pkg-config does the following:

1. Cleans up the broken tests that were expecting the wrong thing;
2. Adds five new tests to make sure I didn't screw anything up, which
   includes two new files in pcdir.

If this patch is acceptable I'll submit another with whitespace
cleanups.

As usual feedback, comments most welcome.

Pax, -A
--
http://trac.haqistan.net | att...@stalphonsos.com | 0xE6CC1EDB
cvs server: Diffing .
Index: pkg-config
===
RCS file: /cvs/src/usr.bin/pkg-config/pkg-config,v
retrieving revision 1.85
diff -u -p -r1.85 pkg-config
--- pkg-config	17 Nov 2014 22:16:23 -	1.85
+++ pkg-config	14 Aug 2015 19:11:33 -
@@ -48,6 +48,10 @@ my $found_uninstalled = 0;
 
 my $version = '0.27.1'; # pretend to be this version of pkgconfig
 
+# Regexp that captures our idea of a version number which accomodates
+# version numbers found in practice in e.g. the ports tree:
+my $vers_regexp = qr

Re: [PATCH] pkg-config compare() fails for libevent (at least)

2015-08-14 Thread attila

attila att...@stalphonsos.com writes:

 Jasper Lievisse Adriaanse jas...@openbsd.org writes:

 On Thu, Aug 13, 2015 at 04:09:02PM -0500, attila wrote:
 
 Jasper Lievisse Adriaanse jas...@openbsd.org writes:
 
  On Tue, Aug 11, 2015 at 01:20:24PM -0500, attila wrote:
  Hello tech@,
  
  On the 6 Aug snap I ran into this issue:
  
$ pkg_info | grep libevent
libevent-2.0.22 event notification library
$ pkg-config --atleast-version=2.0.1 libevent  echo yes
Argument 22-stabl isn't numeric in numeric eq (==) at 
  /usr/bin/pkg-config line 662.
yes
  
  So it works but spits out that error.  The issue is that the libevent
  port reports its version as 2.0.22-stable, which does not follow the
  convention used by the compare() sub in pkg-config.  The attached
  patch gets rid of the error albeit in a very pointilistic way; perhaps
  a more general solution is desired, but I'm not sure what the best
  approach is, especially given that there is something called
  pkg-config available pretty much everywhere but based on very
  different implementations...
  
  It doesn't appear as though my patch introduces any regressions,
  although I'm still sussing out how the regression tests work so I'm
  not sure if I'm doing anything wrong... it appears that five of
  pkg-config's regression tests fail regardless of my patch:
  
FAIL usr.bin/pkg-config/static-cflags2
FAIL usr.bin/pkg-config/static-libs2
FAIL usr.bin/pkg-config/static-libs3
FAIL usr.bin/pkg-config/static-libs4
FAIL usr.bin/pkg-config/missing-req-2
  
  In all cases it looks like the difference is ordering, except for the
  last where two errors are produced but only one is expected.  I'll
  work on a patch to fix these failures next.
  That's indeed the case and patches to fix that are welcome.
   
  Feedback, comments most welcome.
  Could you please add regress tests for this issue you're solving too?
 
 This turned out to be not so much difficult as cognitive
 dissonance-inducing.  The details are numbingly boring but I'll
 happily discuss if there's an issue.  In the end I have done what you
 asked.
 
 The first patch attached modifies pkg-config itself in the following
 ways:
 
 * Adds a (looks like libevent-specific) fix to compare() so that
   libevent's version number in e.g. libevent.pc (2.0.22-stable) does
   not cause warnings;
 * Hoists the code that redirected stderr - stdout when
   --errors-to-stdout was specified from say_msg() into the main
   program, so that such warnings (if they ever appear again) appear in
   the .got files produced by regression tests;
 * Cleans up a couple stylistic nits (add a space between ) and {)
   in a few places to be consistent with how all the other Perl code
   looks.
 
 The second patch attached cleans up the failing regression tests.
 I've verified that our pkg-config produces the same output as the(a?)
 one on at least Linux given our test cases, and manually examined all
 the output.  It looks right to me.
 
 As always feedback, comments, beatings most welcome.
 Could you please send the spacing as a separate diff? I'm fine with that 
 going
 in first, but it's making it less obvious where the real goodies are ;-)


 This is reminding me of a Troma movie: I keep sticking a fork in its
 eye but the beast just won't go down...

 Forget my previous patches.  There are two new patches attached.

 First patch in src/usr.bin/pkg-config does the following:

 1. Factors out the regular expression used to check a version number
for validity into a variable so that we have the same idea about
this everywhere;
 2. Uses this regexp in the main loop;
 3. Uses this regexp in compare() and adjusts the captured subexp
variables used to get the components of the optional suffix
e.g. alpha1;
 4. Hoists the stderr-stdout redirection code to early in the main
program for the same reason my previous patch did (which, BTW,
helped me find bugs in my patch after earlier versions of it caused
other regression tests to fail, so... yay?).

 Second patch in src/regress/usr.bin/pkg-config does the following:

 1. Cleans up the broken tests that were expecting the wrong thing;
 2. Adds five new tests to make sure I didn't screw anything up,
which includes two new files in pcdir.

 If this patch is acceptable I'll submit another with whitespace
 cleanups.

 As usual feedback, comments most welcome.

 Pax, -A

Sigh.  My patches got mangled by emacs in another new and exciting
way.  Here they are inline:

Index: pkg-config
===
RCS file: /cvs/src/usr.bin/pkg-config/pkg-config,v
retrieving revision 1.85
diff -u -p -r1.85 pkg-config
--- pkg-config  17 Nov 2014 22:16:23 -  1.85
+++ pkg-config  14 Aug 2015 19:11:33 -
@@ -48,6 +48,10 @@ my $found_uninstalled = 0;
 
 my $version = '0.27.1'; # pretend to be this version of pkgconfig
 
+# Regexp that captures our idea of a version number which

Re: [PATCH] pkg-config compare() fails for libevent (at least)

2015-08-13 Thread attila

Jasper Lievisse Adriaanse jas...@openbsd.org writes:

 On Tue, Aug 11, 2015 at 01:20:24PM -0500, attila wrote:
 Hello tech@,
 
 On the 6 Aug snap I ran into this issue:
 
   $ pkg_info | grep libevent
   libevent-2.0.22 event notification library
   $ pkg-config --atleast-version=2.0.1 libevent  echo yes
   Argument 22-stabl isn't numeric in numeric eq (==) at 
 /usr/bin/pkg-config line 662.
   yes
 
 So it works but spits out that error.  The issue is that the libevent
 port reports its version as 2.0.22-stable, which does not follow the
 convention used by the compare() sub in pkg-config.  The attached
 patch gets rid of the error albeit in a very pointilistic way; perhaps
 a more general solution is desired, but I'm not sure what the best
 approach is, especially given that there is something called
 pkg-config available pretty much everywhere but based on very
 different implementations...
 
 It doesn't appear as though my patch introduces any regressions,
 although I'm still sussing out how the regression tests work so I'm
 not sure if I'm doing anything wrong... it appears that five of
 pkg-config's regression tests fail regardless of my patch:
 
   FAIL usr.bin/pkg-config/static-cflags2
   FAIL usr.bin/pkg-config/static-libs2
   FAIL usr.bin/pkg-config/static-libs3
   FAIL usr.bin/pkg-config/static-libs4
   FAIL usr.bin/pkg-config/missing-req-2
 
 In all cases it looks like the difference is ordering, except for the
 last where two errors are produced but only one is expected.  I'll
 work on a patch to fix these failures next.
 That's indeed the case and patches to fix that are welcome.
  
 Feedback, comments most welcome.
 Could you please add regress tests for this issue you're solving too?

This turned out to be not so much difficult as cognitive
dissonance-inducing.  The details are numbingly boring but I'll
happily discuss if there's an issue.  In the end I have done what you
asked.

The first patch attached modifies pkg-config itself in the following
ways:

* Adds a (looks like libevent-specific) fix to compare() so that
  libevent's version number in e.g. libevent.pc (2.0.22-stable) does
  not cause warnings;
* Hoists the code that redirected stderr - stdout when
  --errors-to-stdout was specified from say_msg() into the main
  program, so that such warnings (if they ever appear again) appear in
  the .got files produced by regression tests;
* Cleans up a couple stylistic nits (add a space between ) and {)
  in a few places to be consistent with how all the other Perl code
  looks.

The second patch attached cleans up the failing regression tests.
I've verified that our pkg-config produces the same output as the(a?)
one on at least Linux given our test cases, and manually examined all
the output.  It looks right to me.

As always feedback, comments, beatings most welcome.

Pax, -A
--
http://trac.haqistan.net | att...@stalphonsos.com | 0xE6CC1EDB
cvs server: Diffing .
Index: pkg-config
===
RCS file: /cvs/src/usr.bin/pkg-config/pkg-config,v
retrieving revision 1.85
diff -u -p -r1.85 pkg-config
--- pkg-config	17 Nov 2014 22:16:23 -	1.85
+++ pkg-config	13 Aug 2015 21:02:55 -
@@ -109,13 +109,24 @@ GetOptions(	'debug' 		= \$mode{debug},
 		'define-variable=s' 	= $variables,
 	);
 
+# If --errors-to-stdout was given, close STDERR (to be safe),
+# then dup the output to STDOUT and delete the key from %mode so we
+# won't keep checking it. STDERR stays dup'ed.
+# We do this here instead of in say_msg() to also redirect warn()
+# output to stdout to make a regression test happy (dash-stable).
+if ($mode{estdout}) {
+	close(STDERR);
+	open(STDERR, STDOUT) or die Can't dup STDOUT: $!;
+	delete($mode{estdout});
+}
+
 # Unconditionally switch to static mode on static arches as --static
 # may not have been passed explicitly, but we don't want to re-order
 # and simplify the libs like we do for shared architectures.
 {
 	my @static_archs = qw(vax);
 	my $machine_arch = $Config{'ARCH'};
-	if (grep { $_ eq $machine_arch } @static_archs){
+	if (grep { $_ eq $machine_arch } @static_archs) {
 		$mode{static} = 1;
 	}
 }
@@ -156,12 +167,12 @@ my $top_config = [];
 
 # When we got here we're supposed to have had at least one
 # package as argument.
-if (!@ARGV){
+if (!@ARGV) {
 	say_error(No package name(s) specified.);
 	exit 1;
 }
 
-while (@ARGV){
+while (@ARGV) {
 	my $p = shift @ARGV;
 	my $op = undef;
 	my $v = undef;
@@ -233,7 +244,7 @@ if ($mode{variable}) {
 
 my $dep_cfg_list = $cfg_full_list;
 
-if ($mode{static}){
+if ($mode{static}) {
 	$dep_cfg_list = [reverse(@$cfg_full_list)];
 } else {
 	$dep_cfg_list = simplify_and_reverse($cfg_full_list);
@@ -439,7 +450,7 @@ sub do_modversion
 	if (defined $cfg) {
 		my $value = $cfg-get_property('Version', $variables);
 		if (defined $value) {
-			if (defined($mode{printprovides})){
+			if (defined($mode{printprovides})) {
 print $p =  . stringize($value) . \n;
 return undef

[PATCH] pkg-config compare() fails for libevent (at least)

2015-08-11 Thread attila
Hello tech@,

On the 6 Aug snap I ran into this issue:

  $ pkg_info | grep libevent
  libevent-2.0.22 event notification library
  $ pkg-config --atleast-version=2.0.1 libevent  echo yes
  Argument 22-stabl isn't numeric in numeric eq (==) at /usr/bin/pkg-config 
line 662.
  yes

So it works but spits out that error.  The issue is that the libevent
port reports its version as 2.0.22-stable, which does not follow the
convention used by the compare() sub in pkg-config.  The attached
patch gets rid of the error albeit in a very pointilistic way; perhaps
a more general solution is desired, but I'm not sure what the best
approach is, especially given that there is something called
pkg-config available pretty much everywhere but based on very
different implementations...

It doesn't appear as though my patch introduces any regressions,
although I'm still sussing out how the regression tests work so I'm
not sure if I'm doing anything wrong... it appears that five of
pkg-config's regression tests fail regardless of my patch:

  FAIL usr.bin/pkg-config/static-cflags2
  FAIL usr.bin/pkg-config/static-libs2
  FAIL usr.bin/pkg-config/static-libs3
  FAIL usr.bin/pkg-config/static-libs4
  FAIL usr.bin/pkg-config/missing-req-2

In all cases it looks like the difference is ordering, except for the
last where two errors are produced but only one is expected.  I'll
work on a patch to fix these failures next.

Feedback, comments most welcome.

Pax, -A
--
http://trac.haqistan.net | att...@stalphonsos.com | 0xE6CC1EDB

Index: pkg-config
===
RCS file: /cvs/src/usr.bin/pkg-config/pkg-config,v
retrieving revision 1.85
diff -u -p -r1.85 pkg-config
--- pkg-config	17 Nov 2014 22:16:23 -	1.85
+++ pkg-config	11 Aug 2015 17:53:24 -
@@ -625,16 +625,16 @@ sub compare
 	# is there a valid non-numeric suffix to deal with later?
 	# accepted are (in order): a(lpha)  b(eta)  rc  ' '.
 	# suffix[0] is the 'alpha' part, suffix[1] is the '1' part in 'alpha1'.
-	if ($a =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
-		say_debug(valid suffix $1$2 found in $a$1$2.);
-		$suffix_a[0] = $1;
-		$suffix_a[1] = $2;
+	if ($a =~ s/(|-)(stable|rc|beta|b|alpha|a)(|\d+)$//) {
+		say_debug(valid suffix $2$3 found in $a$2$3.);
+		$suffix_a[0] = $2;
+		$suffix_a[1] = $3;
 	}
 
-	if ($b =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
-		say_debug(valid suffix $1$2 found in $b$1$2.);
-		$suffix_b[0] = $1;
-		$suffix_b[1] = $2;
+	if ($b =~ s/(|-)(stable|rc|beta|b|alpha|a)(|\d+)$//) {
+		say_debug(valid suffix $2$3 found in $b$2$3.);
+		$suffix_b[0] = $2;
+		$suffix_b[1] = $3;
 	}
 
 	# The above are standard suffixes; deal with single alphabetical


[PATCH] Man pages: usbd_open_pipe(9), usbd_close_pipe(9)

2015-05-02 Thread attila
Hi tech@,

This patch adds man pages for usbd_open_pipe, usbd_open_pipe_intr,
usbd_close_pipe and usbd_abort_pipe, done as two files:
usbd_open_pipe.9 and usbd_close_pipe.9.  It also adds these two new .9
files to the appropriate Makefile and tweaks usbd_transfer(9) to refer
to usbd_open_pipe(9).

Comments, feedback most welcome.

Pax, -A

P.S. I f'ing love mandoc.  Just sayin...
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E  AC29 9677 D0A6 E6CC 1EDB

Index: Makefile
===
RCS file: /cvs/src/share/man/man9/Makefile,v
retrieving revision 1.230
diff -u -p -r1.230 Makefile
--- Makefile	10 Feb 2015 21:56:08 -	1.230
+++ Makefile	2 May 2015 00:07:16 -
@@ -31,7 +31,7 @@ MAN=	aml_evalnode.9 atomic_add_int.9 ato
 	tsleep.9 spl.9 startuphook_establish.9 \
 	socreate.9 sosplice.9 style.9 syscall.9 systrace.9 sysctl_int.9 \
 	task_add.9 tc_init.9 time.9 timeout.9 tvtohz.9 uiomove.9 uvm.9 \
-	usbd_transfer.9 \
+	usbd_transfer.9 usbd_open_pipe.9 usbd_close_pipe.9 \
 	vfs.9 vfs_busy.9 \
 	vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \
 	vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \
Index: usbd_close_pipe.9
===
RCS file: usbd_close_pipe.9
diff -N usbd_close_pipe.9
--- /dev/null	1 Jan 1970 00:00:00 -
+++ usbd_close_pipe.9	2 May 2015 00:07:16 -
@@ -0,0 +1,59 @@
+.\ $OpenBSD$
+.\
+.\ Copyright (c) 2015 Sean Levy att...@stalphonsos.com
+.\
+.\ Permission to use, copy, modify, and distribute this software for any
+.\ purpose with or without fee is hereby granted, provided that the above
+.\ copyright notice and this permission notice appear in all copies.
+.\
+.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\
+.Dd $Mdocdate$
+.Dt USBD_CLOSE_PIPE 9
+.Os
+.Sh NAME
+.Nm usbd_close_pipe , usbd_abort_pipe
+.Nd close or abort transfers on a USB pipe
+.Sh SYNOPSIS
+.In dev/usb/usb.h
+.In dev/usb/usbdi.h
+.Ft usbd_status
+.Fn usbd_close_pipe struct usbd_pipe *pipe
+.Ft usbd_status
+.Fn usbd_abort_pipe struct usbd_pipe *pipe
+.Sh DESCRIPTION
+A pipe is a logical connection between the host and an endpoint
+on a USB device, created by one of
+.Xr usbd_open_pipe 9
+or
+.Xr usbd_open_pipe_intr 9 .
+.Pp
+The
+.Fn usbd_abort_pipe
+function aborts any transfers queued on the pipe and ensures it is quiescent
+before returning.
+.Pp
+The
+.Fn usbd_close_pipe
+function first calls
+.Fn usbd_abort_pipe ,
+then removes the pipe from the relevant USB interface's list of pipes
+and cleans up any memory associated with the pipe, including any
+implicit transfer created by
+.Xr usbd_open_pipe_intr 9 .
+.Sh CONTEXT
+.Fn usbd_abort_pipe
+and
+.Fn usbd_close_pipe
+can be called during autoconf, from process context or from interrupt
+context.
+.Sh SEE ALSO
+.Xr usbd_open_pipe 9 ,
+.Xr usb 4 ,
+.Xr intro 4
Index: usbd_open_pipe.9
===
RCS file: usbd_open_pipe.9
diff -N usbd_open_pipe.9
--- /dev/null	1 Jan 1970 00:00:00 -
+++ usbd_open_pipe.9	2 May 2015 00:07:16 -
@@ -0,0 +1,162 @@
+.\ $OpenBSD$
+.\
+.\ Copyright (c) 2015 Sean Levy att...@stalphonsos.com
+.\
+.\ Permission to use, copy, modify, and distribute this software for any
+.\ purpose with or without fee is hereby granted, provided that the above
+.\ copyright notice and this permission notice appear in all copies.
+.\
+.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\
+.Dd $Mdocdate$
+.Dt USBD_OPEN_PIPE 9
+.Os
+.Sh NAME
+.Nm usbd_open_pipe , usbd_open_pipe_intr
+.Nd create USB pipe
+.Sh SYNOPSIS
+.In dev/usb/usb.h
+.In dev/usb/usbdi.h
+.Ft usbd_status
+.Fn usbd_open_pipe struct usbd_interface *iface u_int8_t address u_int8_t flags struct usbd_pipe **pipe
+.Ft usbd_status
+.Fn usbd_open_pipe_intr struct usbd_interface *iface u_int8_t address u_int8_t flags struct usbd_pipe **pipe void *priv void *buffer u_int32_t len usbd_callback cb int ival
+.Sh DESCRIPTION
+The
+.Fn

Re: [NEW] Driver for the Araneus Alea II USB TRNG

2015-04-16 Thread attila

Martin Pieuchot m...@openbsd.org writes:

 On 15/04/15(Wed) 10:46, attila wrote:
 Martin Pieuchot m...@openbsd.org writes:
 
  On 14/04/15(Tue) 15:22, attila wrote:
  Martin Pieuchot m...@openbsd.org writes:
   
   static const struct usb_devno ualea_devs[] = {
  { USB_VENDOR_ARANEUS,   USB_PRODUCT_ARANEUS_ALEA }
   };
  
   Is it possible to match your device based on the content of the device
   descriptor instead of whitelisting IDs?  Whitelisting means that if the
   company produce a compatible device with a new ID we'll need to modify
   the driver.
  
  
  Sadly, I don't think it is possible... you mean by looking at
  bDeviceClass/bDeviceSubClass/bDeviceProtocol?  He only gives me zeroes
  [...]
  Perhaps I am misunderstanding; is there something else in there I
  could/should match on?  I've changed the attach routine in the updated
  version to check vendor/product/iface, at least.
 
  I was thinking at bInterfaceClass and bInterfaceProtocol but when they
  are both to vendor defined (255), matching against the ID is the right
  thing to do. 
 
  I looked and it appears that M_ZERO is used when allocating the memory
  for all of these structures, so I take it that explicit zeroing of
  things when tearing down is neither required nor desired?  I removed
  this kind of thing from ualea.c because it looked like it wasn't
  necessary.
 
  That's right.
 
  I'm attaching the updated driver.
  
  Thank you for the critique.  I suppose I need to write a man page for
  this as well... working on it.
 
  Perfect, I'll put it in tree together with your driver :)
 
 
 Man page attached.  I am also attaching an updated copy of the driver
 (only copyright changed).
 
 Thanks so much for your help.  I look forward to contributing more.

 Committed thanks.  I removed some unneeded headers and applied jmc@'s
 tweak.

 In the future I'd suggest you to send unified diff against the CVS tree,
 it's easier to apply  test!

After this was committed I received a critique of the driver from the
person behind the Alea II (Andreas Gustafsson) who made a few pretty
good points.  He felt trying to pull all the entropy off of the device
that would theoretically be available every second was a losing
strategy for several reasons.  Most importantly I ended up calling
add_true_randomness() in bursts of 3200 calls every trip through
ualea_task() whereas rnd_event_space[] in rnd.c only has 64 entries on
a 32bit machine (42 on amd64); this almost surely means that the vast
majority of my calls are no-ops... not so useful, it appears.

The attached diff cranks the buffer size way down and now we call
add_true_randomness() 32 times every 100ms.  When I crank ALEA_MSECS
below 100ms I start to notice the load increases on the machine with
an Alea II plugged in.  I guess this is because the stuff that happens
in ualea_task() happens in the context of a process and that process
always appears to be runnable when ALEA_MSECS is e.g. 10ms.  I crank
the read timeout up to 5000ms because that's what he recommends in his
sample code; under normal circumstances we never time out.

The diff also explicitly looks for endpoint #1 because that's the
endpoint that Andreas says to use, not necc. the first one that I
find; as it turns out now the first one I find is the right one but
just to be safe it's better to check explicitly.

Maybe now this is closer to production-worthy.  All feedback and
comments most welcome.


 Cheers,
 Martin

Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E  AC29 9677 D0A6 E6CC 1EDB

Index: ualea.c
===
RCS file: /cvs/src/sys/dev/usb/ualea.c,v
retrieving revision 1.1
diff -u -p -r1.1 ualea.c
--- ualea.c 16 Apr 2015 08:55:21 -  1.1
+++ ualea.c 16 Apr 2015 20:34:59 -
@@ -36,9 +36,10 @@
 #include dev/rndvar.h
 
 #define ALEA_IFACE 0
+#define ALEA_ENDPOINT  1
 #define ALEA_MSECS 100
-#define ALEA_READ_TIMEOUT  1000
-#define ALEA_BUFSIZ((1024/8)*100)  /* 100 kbits */
+#define ALEA_READ_TIMEOUT  5000
+#define ALEA_BUFSIZ128
 
 #define DEVNAME(_sc) ((_sc)-sc_dev.dv_xname)
 
@@ -101,7 +102,8 @@ ualea_attach(struct device *parent, stru
return;
}
if (UE_GET_DIR(ed-bEndpointAddress) == UE_DIR_IN 
-   UE_GET_XFERTYPE(ed-bmAttributes) == UE_BULK) {
+   UE_GET_XFERTYPE(ed-bmAttributes) == UE_BULK 
+   UE_GET_ADDR(ed-bEndpointAddress) == ALEA_ENDPOINT) {
ep_ibulk = ed-bEndpointAddress;
break;
}


Re: [NEW] Driver for the Araneus Alea II USB TRNG

2015-04-15 Thread attila
Martin Pieuchot m...@openbsd.org writes:

 On 14/04/15(Tue) 15:22, attila wrote:
 Martin Pieuchot m...@openbsd.org writes:
  
  static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS,   USB_PRODUCT_ARANEUS_ALEA }
  };
 
  Is it possible to match your device based on the content of the device
  descriptor instead of whitelisting IDs?  Whitelisting means that if the
  company produce a compatible device with a new ID we'll need to modify
  the driver.
 
 
 Sadly, I don't think it is possible... you mean by looking at
 bDeviceClass/bDeviceSubClass/bDeviceProtocol?  He only gives me zeroes
 [...]
 Perhaps I am misunderstanding; is there something else in there I
 could/should match on?  I've changed the attach routine in the updated
 version to check vendor/product/iface, at least.

 I was thinking at bInterfaceClass and bInterfaceProtocol but when they
 are both to vendor defined (255), matching against the ID is the right
 thing to do. 

 I looked and it appears that M_ZERO is used when allocating the memory
 for all of these structures, so I take it that explicit zeroing of
 things when tearing down is neither required nor desired?  I removed
 this kind of thing from ualea.c because it looked like it wasn't
 necessary.

 That's right.

 I'm attaching the updated driver.
 
 Thank you for the critique.  I suppose I need to write a man page for
 this as well... working on it.

 Perfect, I'll put it in tree together with your driver :)


Man page attached.  I am also attaching an updated copy of the driver
(only copyright changed).

Thanks so much for your help.  I look forward to contributing more.

Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E  AC29 9677 D0A6 E6CC 1EDB

.\ $OpenBSD$
.\
.\ Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
.\ Copyright (c) 2015 attila att...@stalphonsos.com
.\
.\ Permission to use, copy, modify, and distribute this software for any
.\ purpose with or without fee is hereby granted, provided that the above
.\ copyright notice and this permission notice appear in all copies.
.\
.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\
.Dd $Mdocdate$
.Dt UALEA 4
.Os
.Sh NAME
.Nm ualea
.Nd Araneus Alea II USB TRNG
.Sh SYNOPSIS
.Cd ualea* at uhub?
.Sh DESCRIPTION
The
.Nm
driver provides support for the Araneus Alea II, a USB true random
number generator (TRNG).
It delivers 100kbit/sec of hardware-generated entropy.
.Nm
reads raw entropy from the Alea II and uses
.Xr add_true_randomness 9
to add it to the system entropy pool.
.Pp
The product documentation states that the USB interface used by the
Alea II is the same as that used by its predecessor the Alea I;
theoretically this means that the Alea I should work but this has not
been tested.
.Sh SEE ALSO
.Xr intro 4 ,
.Xr usb 4 ,
.Xr add_true_randomness 9 ,
.Sh HISTORY
The
.Nm
driver first appeared in
.Ox 5.7 .
.Sh AUTHORS
The
.Nm
driver was written by
.An attila Aq Mt att...@stalphonsos.com .
/*  $OpenBSD$ */
/*
 * Copyright (c) 2006 Alexander Yurchenko gra...@openbsd.org
 * Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
 * Copyright (C) 2015 Sean Levy att...@stalphonsos.com
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/*
 * Alea II TRNG.  Produces 100kbit/sec of entropy by black magic
 *
 * Product information in English can be found here:
 * http://www.araneus.fi/products/alea2/en/
 */

#include sys/param.h
#include sys/systm.h
#include sys/device.h
#include sys/kernel.h
#include sys/timeout.h
#include dev/usb/usb.h
#include dev/usb/usbdevs.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include dev/rndvar.h

#define ALEA_IFACE  0
#define ALEA_MSECS  100
#define ALEA_READ_TIMEOUT   1000
#define ALEA_BUFSIZ ((1024/8)*100)  /* 100 kbits */

#define DEVNAME(_sc) ((_sc

Re: [NEW] Driver for the Araneus Alea II USB TRNG

2015-04-14 Thread attila
Martin Pieuchot m...@openbsd.org writes:

 On 14/04/15(Tue) 07:40, attila wrote:
 [...]
 Feedback most welcome.

 See below.

 /* -*- mode:c; tab-width:8; indent-tabs-mode:t; c-basic-offset:8 -*- */

 We do not include editor settings in files, the first line should
 contain:

 /*$OpenBSD$ */

 Which will be expanded by CVS.


Done.

 /*
  * Copyright (c) 2006 Alexander Yurchenko gra...@openbsd.org
  * Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
  * Copyright (C) 2015 attila att...@stalphonsos.com
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
  * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 /*
  * Alea II TRNG.  Produces 100kbit/sec of entropy by black magic
  *
  * Product information in English can be found here:
  * http://www.araneus.fi/products/alea2/en/
  *
  * I only have an Alea II to play with but the documentation says
  * that the Alea I is the same, so they should also work.
  *
  * I cribbed liberally from both the uow and umbg drivers, both of
  * which are similar to this situation in different ways.

 The two last paragraphs do not add much information, think about what will
 help you when you'll have to read this code again in a couple of years
 :)


Ixnay to excess verbiage :-).  Gone.

  */
 
 #include sys/param.h
 #include sys/systm.h
 #include sys/device.h
 #include sys/kernel.h
 #include sys/time.h

 I believe you need sys/time.h just to make sure your driver works as
 expected.  You kept this code as #ifdef ALEA_DEBUG but does it really
 help to debug something?  Do you think it's worth keeping this code?
 We try to not add too much verbosity to driver code.


The only DEBUG code I actually cared about was the bit that measured
kbps actually delivered, and that was just to convince myself that the
device did as the mfgr said.  All ALEA_DEBUG gone now (and it was
subtly wrong anyway :-).

 #include sys/timeout.h
 
 #include dev/usb/usb.h
 #include dev/usb/usbdevs.h
 #include dev/usb/usbdi.h
 #include dev/usb/usbdi_util.h
 
 #include dev/rndvar.h
 
 #define ALEA_IFACE   0
 #define ALEA_MSECS   10

 How did you choose 10msec?  


Empirically, by cranking it down until I was seeing 100kbps all the
time, however my method for doing this was wrong so my numbers were a
little bogus.  I did some more digging and it turns out each read from
the ibulk pipe completes in just under 1000msec (990 or so).  I've
changed the timeout values to reflect this.

 #define ALEA_READ_TOUT   1100

 Compared to a transfer timeout of 1,1 second is seems very short.  By
 the way we generally spell timeout TIMEOUT :o)


Spelling fixed everywhere :-).

 #define ALEA_BUFSIZ  ((1024/8)*100)  /* 100 kbits */
 /*#define ALEA_DEBUG 1*/ /* comment out */
 
 #define OURNAME(x)   x-sc_dev.dv_xname

 We generally use DEVNAME(), look at how it is defined :) 


Fixed.

 
 struct ualea_softc {
  struct  device sc_dev;
  struct  usbd_device *sc_udev;
  struct  usbd_interface *sc_iface;
  struct  usbd_pipe *sc_ibulk;
  struct  timeout sc_tout;
  struct  usb_task sc_task;
 #ifdef ALEA_DEBUG
  struct  timespec sc_tattach;
  u_int32_t sc_nbits;
 #endif
 };
 
 int ualea_match(struct device *, void *, void *);
 void ualea_attach(struct device *, struct device *, void *);
 int ualea_detach(struct device *, int);
 void ualea_task(void *);
 void ualea_intr(void *);
 
 struct cfdriver ualea_cd = {
  NULL, ualea, DV_DULL
 };
 
 const struct cfattach ualea_ca = {
  sizeof(struct ualea_softc),
  ualea_match,
  ualea_attach,
  ualea_detach
 };
 
 static const struct usb_devno ualea_devs[] = {
  { USB_VENDOR_ARANEUS,   USB_PRODUCT_ARANEUS_ALEA }
 };

 Is it possible to match your device based on the content of the device
 descriptor instead of whitelisting IDs?  Whitelisting means that if the
 company produce a compatible device with a new ID we'll need to modify
 the driver.


Sadly, I don't think it is possible... you mean by looking at
bDeviceClass/bDeviceSubClass/bDeviceProtocol?  He only gives me zeroes
there:

Bus 005 Device 002: ID 12d8:0001  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0

Re: [NEW] Driver for the Araneus Alea II USB TRNG

2015-04-14 Thread attila
Hi tech@,

I balled the copyright and license up a bit (thanks to deraadt@ and
bcallah@ for pointing this out).  I apologize to grange@ and mbalmer@
for not carrying along their copyright notices when I obviously
cribbed liberally from their code in uow.c and umbg.c, respectively.

Updated driver attached.  If anyone has one of these and can test
please let me know.  The only visible effect when you plug one in is
that Puffy's eyes in the sticker on my thinkpad glow a bit...  not
sure what's up with that, just going to go with it.

Feedback most welcome.

Pax, -A

/* -*- mode:c; tab-width:8; indent-tabs-mode:t; c-basic-offset:8 -*- */
/*
 * Copyright (c) 2006 Alexander Yurchenko gra...@openbsd.org
 * Copyright (c) 2007 Marc Balmer mbal...@openbsd.org
 * Copyright (C) 2015 attila att...@stalphonsos.com
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/*
 * Alea II TRNG.  Produces 100kbit/sec of entropy by black magic
 *
 * Product information in English can be found here:
 * http://www.araneus.fi/products/alea2/en/
 *
 * I only have an Alea II to play with but the documentation says
 * that the Alea I is the same, so they should also work.
 *
 * I cribbed liberally from both the uow and umbg drivers, both of
 * which are similar to this situation in different ways.
 */

#include sys/param.h
#include sys/systm.h
#include sys/device.h
#include sys/kernel.h
#include sys/time.h
#include sys/timeout.h

#include dev/usb/usb.h
#include dev/usb/usbdevs.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h

#include dev/rndvar.h

#define ALEA_IFACE  0
#define ALEA_MSECS  10
#define ALEA_READ_TOUT  1100
#define ALEA_BUFSIZ ((1024/8)*100)  /* 100 kbits */
/*#define ALEA_DEBUG1*/ /* comment out */

#define OURNAME(x)  x-sc_dev.dv_xname

struct ualea_softc {
struct  device sc_dev;
struct  usbd_device *sc_udev;
struct  usbd_interface *sc_iface;
struct  usbd_pipe *sc_ibulk;
struct  timeout sc_tout;
struct  usb_task sc_task;
#ifdef ALEA_DEBUG
struct  timespec sc_tattach;
u_int32_t sc_nbits;
#endif
};

int ualea_match(struct device *, void *, void *);
void ualea_attach(struct device *, struct device *, void *);
int ualea_detach(struct device *, int);
void ualea_task(void *);
void ualea_intr(void *);

struct cfdriver ualea_cd = {
NULL, ualea, DV_DULL
};

const struct cfattach ualea_ca = {
sizeof(struct ualea_softc),
ualea_match,
ualea_attach,
ualea_detach
};

static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS,   USB_PRODUCT_ARANEUS_ALEA }
};

int
ualea_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;

if (uaa-iface != NULL)
return (UMATCH_NONE);
#ifdef ALEA_DEBUG
if (uaa-vendor == USB_VENDOR_ARANEUS)
printf(ualea: vendor 0x%x (%d) (ARANEUS) product 0x%x (%d)\n,
uaa-vendor, uaa-vendor, uaa-product, uaa-product);
#endif
return ((usb_lookup(ualea_devs, uaa-vendor, uaa-product) != NULL) ?
UMATCH_VENDOR_PRODUCT : UMATCH_NONE);
}

void
ualea_attach(struct device *parent, struct device *self, void *aux)
{
struct ualea_softc *sc = (struct ualea_softc *)self;
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
usb_endpoint_descriptor_t *ed;
int ep_ibulk = -1;
usbd_status error;
int i;

sc-sc_udev = uaa-device;
error = usbd_set_config_index(sc-sc_udev, 0, 1);
if (error != 0) {
printf(%s: failed to set config: %s\n,
   OURNAME(sc), usbd_errstr(error));
}
error = usbd_device2interface_handle(
sc-sc_udev, ALEA_IFACE, sc-sc_iface);
if (error != 0) {
printf(%s: failed to get iface %d: %s\n,
OURNAME(sc), ALEA_IFACE, usbd_errstr(error));
return;
}
/* Get endpoint (there can be only one) */
id = usbd_get_interface_descriptor(sc-sc_iface);
for (i = 0; i  id-bNumEndpoints; i++) {
ed = usbd_interface2endpoint_descriptor(sc-sc_iface, i);
if (ed == NULL) {
printf(%s

Re: [NEW] Driver for the Araneus Alea II USB TRNG

2015-04-13 Thread attila
Hi tech@,

Ping?

attila att...@stalphonsos.com writes:

 Hi tech@,

 I've written a driver for the Araneus Alea II USB TRNG:
 http://www.araneus.fi/products/alea2/en/

 It produces 100kbit/sec of entropy, which my driver stuffs into
 add_true_randomness().  A small thing, but maybe valuable in
 situations that do a lot of crypto.  I mainly did it to get my head
 around more of the codebase, and I happened to have one lying around,
 so...  According to the docs the interface has not changed between the
 Alea I and the Alea II so this driver should work for both, but I only
 have a II.  I'm interested in writing drivers for other TRNGs if
 anyone else finds it useful.

 Tested under i386 and amd64.

 I'm sure I've made many mistakes.  Comments and feedback most welcome.

 Pax, -A

 diff -Nurp src.orig/sys/arch/amd64/conf/GENERIC 
 src/sys/arch/amd64/conf/GENERIC
 --- src.orig/sys/arch/amd64/conf/GENERIC  Thu Apr  2 08:24:02 2015
 +++ src/sys/arch/amd64/conf/GENERIC   Thu Apr  9 16:02:27 2015
 @@ -271,6 +271,7 @@ uvideo*   at uhub?# USB Video
  video*   at uvideo?
  udl* at uhub?# DisplayLink USB displays
  wsdisplay* at udl?
 +ualea*   at uhub?# Araneus Alea II USB TRNG
  
  puc* at pci? # PCI universal communication device
  com* at cardbus?
 diff -Nurp src.orig/sys/arch/i386/conf/GENERIC src/sys/arch/i386/conf/GENERIC
 --- src.orig/sys/arch/i386/conf/GENERIC   Thu Apr  2 08:24:02 2015
 +++ src/sys/arch/i386/conf/GENERICThu Apr  9 16:02:01 2015
 @@ -325,6 +325,7 @@ uvideo* at uhub?  # USB video
  video*  at uvideo?
  udl* at uhub?# DisplayLink USB displays
  wsdisplay* at udl?
 +ualea*   at uhub?# Araneus Alea II USB TRNG
  
  puc* at pci? # PCI universal communication device
  com* at cardbus?
 diff -Nurp src.orig/sys/arch/macppc/conf/GENERIC 
 src/sys/arch/macppc/conf/GENERIC
 --- src.orig/sys/arch/macppc/conf/GENERIC Thu Apr  2 08:24:02 2015
 +++ src/sys/arch/macppc/conf/GENERIC  Thu Apr  9 16:02:43 2015
 @@ -292,6 +292,7 @@ utrh* at uhidev?  # USBRH sensor
  utwitch* at uhidev?  # YUREX BBU sensor
  uow* at uhub?# Maxim/Dallas DS2490 1-Wire adapter
  onewire* at uow?
 +ualea*   at uhub?# Araneus Alea II USB TRNG
  
  # USB Video
  uvideo* at uhub?
 diff -Nurp src.orig/sys/arch/sparc64/conf/GENERIC 
 src/sys/arch/sparc64/conf/GENERIC
 --- src.orig/sys/arch/sparc64/conf/GENERICTue Mar 24 06:00:39 2015
 +++ src/sys/arch/sparc64/conf/GENERIC Thu Apr  9 16:02:58 2015
 @@ -245,6 +245,7 @@ ugold*at uhidev?  # gold TEMPer sensor
  utwitch* at uhidev?  # UYUREX BBU sensor
  uow* at uhub?# Maxim/Dallas DS2490 1-Wire adapter
  onewire* at uow?
 +ualea*   at uhub?# Araneus Alea II USB TRNG
  
  # USB Video
  uvideo* at uhub?
 diff -Nurp src.orig/sys/arch/zaurus/conf/GENERIC 
 src/sys/arch/zaurus/conf/GENERIC
 --- src.orig/sys/arch/zaurus/conf/GENERIC Sat Jan  3 15:24:19 2015
 +++ src/sys/arch/zaurus/conf/GENERIC  Thu Apr  9 16:03:25 2015
 @@ -135,6 +135,7 @@ umbg* at uhub?# Meinberg 
 Funkuhren USB5131
  uow* at uhub?# Maxim/Dallas DS2490 1-Wire adapter
  onewire* at uow?
  utwitch* at uhidev?  # YUREX BBU sensor
 +ualea*   at uhub?# Araneus Alea II USB TRNG
  
  scsibus* at scsi?
  sd*  at scsibus? # SCSI disk drives
 diff -Nurp src.orig/sys/dev/usb/files.usb src/sys/dev/usb/files.usb
 --- src.orig/sys/dev/usb/files.usbThu Apr  2 08:24:02 2015
 +++ src/sys/dev/usb/files.usb Thu Apr  9 16:04:38 2015
 @@ -195,6 +195,11 @@ device   utwitch: hid
  attach   utwitch at uhidbus
  file dev/usb/utwitch.c   utwitch
  
 +# Araneus Alea II TRNG
 +device   ualea
 +attach   ualea at uhub
 +file dev/usb/ualea.c ualea
 +
  # Ethernet adapters
  # ADMtek AN986 Pegasus
  device   aue: ether, ifnet, mii, ifmedia
 diff -Nurp src.orig/sys/dev/usb/ualea.c src/sys/dev/usb/ualea.c
 --- src.orig/sys/dev/usb/ualea.c  Wed Dec 31 18:00:00 1969
 +++ src/sys/dev/usb/ualea.c   Fri Apr 10 15:46:30 2015
 @@ -0,0 +1,265 @@
 +/* -*- mode:c; tab-width:8; indent-tabs-mode:t; c-basic-offset:8 -*- */
 +/*
 + * Copyright (C) 2015 by attila att...@stalphonsos.com
 + *
 + * Permission to use, copy, modify, and/or distribute this software
 + * for any purpose with or without fee is hereby granted, provided
 + * that the above copyright notice and this permission notice appear
 + * in all copies.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL
 + * WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
 + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
 + * AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR
 + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES

[NEW] Driver for the Araneus Alea II USB TRNG

2015-04-10 Thread attila
Hi tech@,

I've written a driver for the Araneus Alea II USB TRNG:
http://www.araneus.fi/products/alea2/en/

It produces 100kbit/sec of entropy, which my driver stuffs into
add_true_randomness().  A small thing, but maybe valuable in
situations that do a lot of crypto.  I mainly did it to get my head
around more of the codebase, and I happened to have one lying around,
so...  According to the docs the interface has not changed between the
Alea I and the Alea II so this driver should work for both, but I only
have a II.  I'm interested in writing drivers for other TRNGs if
anyone else finds it useful.

Tested under i386 and amd64.

I'm sure I've made many mistakes.  Comments and feedback most welcome.

Pax, -A

diff -Nurp src.orig/sys/arch/amd64/conf/GENERIC src/sys/arch/amd64/conf/GENERIC
--- src.orig/sys/arch/amd64/conf/GENERICThu Apr  2 08:24:02 2015
+++ src/sys/arch/amd64/conf/GENERIC Thu Apr  9 16:02:27 2015
@@ -271,6 +271,7 @@ uvideo* at uhub?# USB Video
 video* at uvideo?
 udl*   at uhub?# DisplayLink USB displays
 wsdisplay* at udl?
+ualea* at uhub?# Araneus Alea II USB TRNG
 
 puc*   at pci? # PCI universal communication device
 com*   at cardbus?
diff -Nurp src.orig/sys/arch/i386/conf/GENERIC src/sys/arch/i386/conf/GENERIC
--- src.orig/sys/arch/i386/conf/GENERIC Thu Apr  2 08:24:02 2015
+++ src/sys/arch/i386/conf/GENERIC  Thu Apr  9 16:02:01 2015
@@ -325,6 +325,7 @@ uvideo* at uhub?# USB video
 video*  at uvideo?
 udl*   at uhub?# DisplayLink USB displays
 wsdisplay* at udl?
+ualea* at uhub?# Araneus Alea II USB TRNG
 
 puc*   at pci? # PCI universal communication device
 com*   at cardbus?
diff -Nurp src.orig/sys/arch/macppc/conf/GENERIC 
src/sys/arch/macppc/conf/GENERIC
--- src.orig/sys/arch/macppc/conf/GENERIC   Thu Apr  2 08:24:02 2015
+++ src/sys/arch/macppc/conf/GENERICThu Apr  9 16:02:43 2015
@@ -292,6 +292,7 @@ utrh*   at uhidev?  # USBRH sensor
 utwitch* at uhidev?# YUREX BBU sensor
 uow*   at uhub?# Maxim/Dallas DS2490 1-Wire adapter
 onewire* at uow?
+ualea* at uhub?# Araneus Alea II USB TRNG
 
 # USB Video
 uvideo* at uhub?
diff -Nurp src.orig/sys/arch/sparc64/conf/GENERIC 
src/sys/arch/sparc64/conf/GENERIC
--- src.orig/sys/arch/sparc64/conf/GENERIC  Tue Mar 24 06:00:39 2015
+++ src/sys/arch/sparc64/conf/GENERIC   Thu Apr  9 16:02:58 2015
@@ -245,6 +245,7 @@ ugold*  at uhidev?  # gold TEMPer sensor
 utwitch* at uhidev?# UYUREX BBU sensor
 uow*   at uhub?# Maxim/Dallas DS2490 1-Wire adapter
 onewire* at uow?
+ualea* at uhub?# Araneus Alea II USB TRNG
 
 # USB Video
 uvideo* at uhub?
diff -Nurp src.orig/sys/arch/zaurus/conf/GENERIC 
src/sys/arch/zaurus/conf/GENERIC
--- src.orig/sys/arch/zaurus/conf/GENERIC   Sat Jan  3 15:24:19 2015
+++ src/sys/arch/zaurus/conf/GENERICThu Apr  9 16:03:25 2015
@@ -135,6 +135,7 @@ umbg*   at uhub?# Meinberg 
Funkuhren USB5131
 uow*   at uhub?# Maxim/Dallas DS2490 1-Wire adapter
 onewire*   at uow?
 utwitch*   at uhidev?  # YUREX BBU sensor
+ualea* at uhub?# Araneus Alea II USB TRNG
 
 scsibus*   at scsi?
 sd*at scsibus? # SCSI disk drives
diff -Nurp src.orig/sys/dev/usb/files.usb src/sys/dev/usb/files.usb
--- src.orig/sys/dev/usb/files.usb  Thu Apr  2 08:24:02 2015
+++ src/sys/dev/usb/files.usb   Thu Apr  9 16:04:38 2015
@@ -195,6 +195,11 @@ device utwitch: hid
 attach utwitch at uhidbus
 file   dev/usb/utwitch.c   utwitch
 
+# Araneus Alea II TRNG
+device ualea
+attach ualea at uhub
+file   dev/usb/ualea.c ualea
+
 # Ethernet adapters
 # ADMtek AN986 Pegasus
 device aue: ether, ifnet, mii, ifmedia
diff -Nurp src.orig/sys/dev/usb/ualea.c src/sys/dev/usb/ualea.c
--- src.orig/sys/dev/usb/ualea.cWed Dec 31 18:00:00 1969
+++ src/sys/dev/usb/ualea.c Fri Apr 10 15:46:30 2015
@@ -0,0 +1,265 @@
+/* -*- mode:c; tab-width:8; indent-tabs-mode:t; c-basic-offset:8 -*- */
+/*
+ * Copyright (C) 2015 by attila att...@stalphonsos.com
+ *
+ * Permission to use, copy, modify, and/or distribute this software
+ * for any purpose with or without fee is hereby granted, provided
+ * that the above copyright notice and this permission notice appear
+ * in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL
+ * WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
+ * AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+ * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+ * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT