Christos Zoulas | 30 May 22:46 2016

Re: pthread library related

On May 30,  1:43pm, charles.cui1984 <at> gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related

| I am not familiar with _nv() (are there examples in the netbsd code base? I
| searched _nv() in nxr, but did not found anything meaningful.),
| but if you want to use atomic operations, one possible way is
| compare-and-swap (CAS).
| it has stronger guarantee than atomic inc or atomic dec, but also larger
| overhead.

man atomic_inc_uint_nv

http://nxr.netbsd.org/xref/src/sys/fs/tmpfs/tmpfs_mem.c#185

christos

Martin Husemann | 30 May 22:30 2016
Picon

Re: pthread library related

On Mon, May 30, 2016 at 01:25:34PM -0700, Charles Cui wrote:
> there is one remaining slot. And each of them will increase p_nsem by one
> using atomic_inc, the results are we have 1 slot overused, but the error is
> never detected.

You will have to use a _nv() variant and use the return value to
compare that against the limit, then decrement in the error path.

Martin

Christos Zoulas | 29 May 15:46 2016

Re: timers related

On May 28, 11:28pm, charles.cui1984 <at> gmail.com (Charles Cui) wrote:
-- Subject: timers related

| HI guys,
| 
|     I have 3 timers related macro to be added, which are _SC_CPUTIME,
| _SC_THREAD_CPUTIME and _SC_DELAYTIMER_MAX.
| the first and second are set to be 200112L in freebsd. I am wondering
| what's the meaning of those macros? and what are the cases to use these
| macros? I am thinking of where to add logics related with these macros. By
| the way, freebsd source cannot be browsed on nxr any more?

_SC_CPUTIME is for clock_getcpuclockid()
https://sourceforge.net/p/posixtest/mailman/message/3663935/
_SC_THREAD_CPUTIME is for pthread_getclockcpuid()
_SC_DELAYTIMER_MAX is for timer_getoverrun()
https://docs.oracle.com/cd/E19683-01/816-0213/6m6ne38dd/index.html
http://man7.org/linux/man-pages/man2/timer_getoverrun.2.html

I just used google to find them...

christos

Martin Husemann | 29 May 11:29 2016
Picon

Re: timers related

On Sat, May 28, 2016 at 11:28:00PM -0700, Charles Cui wrote:
> HI guys,
> 
>     I have 3 timers related macro to be added, which are _SC_CPUTIME,
> _SC_THREAD_CPUTIME and _SC_DELAYTIMER_MAX.

If I read the standard correctly, all of those are optional.

So first we need to decide, whether to add them at all. Christos, do I
remember correctly you said the first two would be simple?

Charles: isn't _SC_DELAYTIMER_MAX being undefined the way to express there
is no hard limit?

Which errors are you running into exactly? It seems to me you are trying to
fix bugs in the test suite by adapting NetBSD in this case (but I might be
missing something).

Martin

Robert Elz | 29 May 07:04 2016
Picon

Minor updates to sort ?

Inspired by Paul Goyette's question (on netbsd-users) I took a look at sort,
and I'd like to commit the following updates if no-one objects.

The only changes that should affect anything are the addition of the posix
C option, which is identical to c, but doesn't write messages to stderr
if the input file is not sorted, and fixing bugs in the processing of -R
such that if -R is used (and without setting it to \n - the processing of
which is also fixed in case it is set that wat using -R 10) \n does not
become a field separator regardless of what might be set later with -t (if
-t preceded -R it would have worked correctly, but not the other way.)

Aside from that the changes are more or less cosmetic - they enforce using
only one of -c -C and -m (which make no sense used together), make the
usage() reflect reality (including formatting it to stop assuming it
is outputting to an 80 column display..., and reflect the man page changes
mentioned next), and fix a minor bug in a comment, removed the unused 'x'
option (what was that?) from SORT_OPTS (no effect, generates usage() either
way) and sorted the option processing (R comes before S...)

In the man page, -C is documented, the synopsis is split to show the
(only one file allowed) different usage for -C or -c, and perhaps most
importantly, the names "field1" and "filed2" are changed to "kstart" and
"kend" to make it (a little more) clear that the -k argument does not specify
or use a field as such, but designates the start and end of the sort keys
(with the designators using fields as an addressing object - which is all
fields are used for in sort, unlike awk, cut, etc.) and -R is fully documented.

There are no changes (at all) to anything actually related to sorting...

Anyone object to these changes?   (patch appended)
(Continue reading)

Kamil Rytarowski | 28 May 15:45 2016
Picon

iconv(3) protype mismatch with POSIX

This was already noted in 2006

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=33125

NetBSD iconv(3):

size_t
iconv(iconv_t cd, const char ** restrict src, size_t * restrict srcleft,
char ** restrict dst, size_t * restrict dstleft);

It says that:
     Historically, the definition of iconv has not been consistent across
     operating systems.  This is due to an unfortunate historical mistake,
     documented in this e-mail:

https://www5.opengroup.org/sophocles2/show_mail.tpl?&source=L&listname=austin-group-l&id=7404.
     The standards page for the header file <iconv.h> defined the second
     argument of iconv() as char **, but the standards page for the iconv()
     implementation defined it as const char **.  The standards committee
     later chose to change the function definition to follow the header file
     definition (without const), even though the version with const is
     arguably more correct.  NetBSD has always used the const form.  It was
     decided to reject the committee's regression and become (technically)
     incompatible.  GNU libiconv has taken the same route:

http://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.14/.
     Most third party software affected by this issue already handles it
     during configuration.

It's no longer true for gnu libiconv. They gave up and removed "const"
(Continue reading)

'Timo Buhrmester' | 27 May 18:26 2016
Picon

Re: [patch] ftp(1) does not understand "Location"-headers with a relative reference

On Fri, May 27, 2016 at 11:58:50AM -0400, Terry Moore wrote:
> Malloc() might fail, and you don't check for that in your new path.
Right, thanks.  I meant to use ftp_malloc(), anyway.

> And it's not clear to me how you know that there's a "//" at the strstr()
I believe that the chain of events leading to that code requires that url
start with http:// or https://.  I'll try to verify that.

Thanks for the feedback

Timo Buhrmester | 27 May 16:58 2016
Picon

[patch] ftp(1) does not understand "Location"-headers with a relative reference

The "Location"-Header in a HTTP Redirect used to require a full URL,
but as of RFC 7231, relative references are also allowed.

ftp(1) does not understand this; the following patch addresses that issue.

Comments?

diff --git a/usr.bin/ftp/fetch.c b/usr.bin/ftp/fetch.c
index d5b13b6..32f0368 100644
--- a/usr.bin/ftp/fetch.c
+++ b/usr.bin/ftp/fetch.c
 <at>  <at>  -115,6 +115,7  <at>  <at>  static int	parse_url(const char *, const char *, struct urlinfo *,
 static void	url_decode(char *);
 static void	freeauthinfo(struct authinfo *);
 static void	freeurlinfo(struct urlinfo *);
+static int	isfullurl(const char *);

 static int	redirect_loop;

 <at>  <at>  -1010,9 +1011,29  <at>  <at>  negotiate_connection(FETCH *fin, const char *url, const char *penv,
 			getmtime(cp, mtime);

 		} else if (match_token(&cp, "Location:")) {
-			location = ftp_strdup(cp);
+			if (!isfullurl(cp)) {
+				/* Redirect using "relative reference",
+				 * RFC 7231 7.1.2.  The destination is just a
+				 * path, which may be absolute or relative */
+
+				/* This is going to be the base URL */
(Continue reading)

Edgar Fuß | 27 May 12:48 2016
Picon

makemandb: Error in indexing /usr/pkg/man/man3/libarchive_changes.3

On a 6.1_STABLE system, I'm getting
	makemandb: Error in indexing /usr/pkg/man/man3/archive_write_filter.3
	makemandb: Error in indexing /usr/pkg/man/man3/libarchive_changes.3
but the files look OK to me.

Charles Cui | 26 May 23:08 2016
Picon

Re: pthread library related

Hi Christos,

   I am studying the pthread libraries in netbsd, and have several patches
completed.
I have attached all of them, which is pretty easy, but can fix some
problems in user land.
Note that some of them needs to add more logic. If you can, please give me
some comments on them.

For the pthread part, I found a deep understanding is necessary to
implement the feature
such as cross process synchronization. Also, I found a patch which is
written by ad (http://www.netbsd.org/~ad/prio_protect.diff)
I found that patch implements some functions that I need, I am right now
focusing on how to port
that patch to my work.

Also, there are some missing macros like _SC_≤MISS_MICRO>, I found the
existing code just return the macro
using _POSIX_≤MISS_MICRO>, I am wondering where do you guys enforce the
limitation in the kernel ?
To clarify, let's use _SC_TIMER_MAX as an example, the netbsd code just
returns _POSIX_TIMER_MAX in
sysconf system call, where can I find the logic to enforce this number when
user land allocates more times than this value?

Let me know if there are any concerns.

Thanks, Charles.

(Continue reading)

Manuel Bouyer | 26 May 19:30 2016

C tty/tcsetattrs question

Hello,
I have a GPS device connected to a serial port. It defaults to 9600bps
NMEA messages, but I need to switch it to 4800bps. There are NMEA
commands for this, and I can properly do this using cu(1).

Now I'm trying to write a program to do this at boot time.
First I need to determine if the GPS is outputting at 4800 or 9600bps
(the CPU may be rebooted, or even powered off wihout resetting the GPS
module).
I wrote the attached C program, but the cfsetspeed() doesn't seem
to have any effect: with the GPS running at 9600bps,
if I start with the tty set to 9600 (for example from a previous
cu(1) run) I get proper NMEA sentences on both check_term() calls,
and if I start with the tty set to 4800 (e.g. from a previous
cu(1) run) I get either nothing or garbage (not getting anything
from the tty is a valid case, as the tty is in canon mode select()
will return a read event only if the serial port got something that
looks like a line).

Does anyone see an obvious error or something I missed ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
#include <stdio.h>
#include <stdlib.h>
#include <termios.h>
(Continue reading)


Gmane