Marc Balmer | 14 Oct 08:33 2014
Picon

Binary packages on NetBSD: Importing pkg(8) from FreeBSD?

[This has also been posted to pkgsrc-users <at> netbsd.org]

FreeBSD has now by default pkg(8) (formerly called pkgng) as the default manager for _binary_ packages.  It
replaces the old pkg_* tools.  pkg(8) is a manager for binary packages _only_; to produce the binary
packages the FreeBSD ports system is used almost unaltered.  pkg(8) has been designed to be a modern binary
package manager that can among other things properly deal with update situations, properly resolve
dependencies and in general allows systems to be managed with binary packages easily.

pkg(8) is not part of the base system, the base system only contains a way to bootstrap pkg(8).  pkg(8) itself
resides in the FreeBSD ports tree.

I think pkg(8) would be a good thing for NetBSD to have, too.  pkg(8) is properly designed and allows for
different binary package formats (at least in theory), so it could probably be feasible to add a pkg(8)
backend that handles binary packages produced using pkgsrc.

afaict, the following steps would be needed:

- Tell the upstream developers about our plans (the pkgsrc backend should become part of the upstream code,
if possible)
- Import the pkg(8) bootstrap mechanism into NetBSD base (src/external).
- Extend pkg(8) to deal with pkgsrc-produced binary packages.
- Import pkg(8) into pkgsrc.
- Coordinate local changes with the upstream developers.

As pkg(8) "only" deals with binary packages, this would be complimentary to the existing pkg_* tools that
come with pkgsrc, i.e. it's use would be optional.

Is anyone besides me interested in such work and would be able/willing to spend some amount of time on this?

- mbalmer
(Continue reading)

Edward Tomasz Napierała | 30 Sep 13:19 2014
Picon

Re: FreeBSD got a new automounter

Just FYI, I'll happily help you with porting the automounter.  Userland
part should be trivial; I don't think it contains any system-specific
code, apart from autofs ioctls.  The kernel part is not complicated either,
but will need someone who knows NetBSD VFS.

Steffen Nurpmeso | 29 Sep 15:05 2014

snprintf(3) behaviour regarding large "n"

Hello NetBSD,

i recently had a hard time because NetBSD was the only operating
system that fails to pass the testsuite (S/MIME function
verification, and only this test!) of the S-nail mailer
i maintain.

Short: the problem is that i use snprintf(3) with a "size_t n"
argument of UI32_MAX (is EQ to UINT32_MAX).
Well, looking at POSIX this is even somewhat correct (but then it
should be EOVERFLOW for conformance), but it is (a) neither
documented in the manual nor (b) would a halfway sane person do it
like that -- :) --, though i'd agree that i should have used
SIZE_MAX to indicate what i had in mind ("buffer _is_ large
enough"), not at last because there is an error defined for when
_the return value_ would exceed INT_MAX (also EOVERFLOW).

The patch has not been compile tested (regarding availability of
INT_MAX), sorry (very small resources here).

--steffen
James K. Lowden | 19 Sep 21:38 2014

fcntl & cmsg

unix(4) contains an "interesting" sentence:

	     "The received descriptor is a duplicate of the sender's
descriptor, as if it were created with a call to dup(2).  Per-process
descriptor flags, set with fcntl(2), are not passed to a receiver."

because fcntl(2) doesn't define "per-process" descriptor flags.  Does
the sentence mean "any flag set with fcntl", or are some flags
per-process?  If the latter, is the reader supposed to be able to
determine which flags are per-process from the context?  

McKusick distinguishes between a "file entry" describing an open file,
and a descriptor, which is an index into an array of references to file
entries.  The descriptor array -- and hence each descriptor -- is
unique to each process, whereas many references to the file entry may
be created by fork() and dup(), and via unix domain sockets.  

But fcntl(2) says it "provides for control over descriptors" when in
fact sometimes it updates or interrogates the file entry.  Examples
include F_SETLK and (afaict) F_SETOWN.  fcntl(2) does mention "flags
associated with the file descriptor", which I'm willing to believe are
"per-process".   They are:

*  the close-on-exec flag via F_SETFD
*  the O_NONBLOCK, O_APPEND, and O_ASYNC flags via F_SETFL

(Can anyone explain why close-on-exec isn't just another option for
F_SETFL?  I see that dup(2) preserves the F_SETFL flags but not
close-on-exec. Interesting choice....)

(Continue reading)

Jens Mehler | 18 Sep 14:05 2014
Picon

Cross building NetBSD userland

Hi Folks I hope this is the correct list.

After resolving several issues with my GCC port and finally being able
to build the kernel as intended I started porting the userland for the
Eco32 processor.

I use the following commands
                export MKGCCMDS=no
                export MKBINUTILS=no
                export MKGDB=no
                export MKSTATICLIB=yes
                ./build.sh -T ./obj/tooldir -u -U -m eco32 release

The build starts and finally ends with:
obj ===> lib
obj ===> lib/csu
obj ===> lib/../external/gpl3/gcc/lib/libgcc
obj ===> lib/../external/gpl3/gcc/lib/libgcc/libgcc
nbmake: "/hdd/home/okarin/eco32/netbsd/usr/src/share/mk/bsd.files.mk"
line 110: Wrong number of words (1) in .for substitution list with 2 vars
nbmake: Fatal errors encountered -- cannot continue
nbmake: stopped in
/hdd/home/okarin/eco32/netbsd/usr/src/external/gpl3/gcc/lib/libgcc/libgcc

I wonder what I am missing.
Is there some kind of guide to get the userland compiled for the first
time ?

With best regards,
Jens
(Continue reading)

Emmanuel Dreyfus | 15 Sep 06:35 2014
Picon

strtoll question

Hello

Consider the program below and its output. Am I using strtoll() wrongly,
or is this a bug? (this is netbsd-7 branch)

$ cat /tmp/x.c
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>

int
main(void)
{
        const char *ptr = "999999999999999";
        char *endp;
        long long int res;

        errno = 0;
        res = strtoll(ptr, &endp, 0);
        printf("errno = %d\n", errno);
        printf("*endp = 0x%02x\n", *endp);
        printf("str %s\n", ptr);
        printf("num %lld\n", res);

        return 0;
}

$ cc -o /tmp/x /tmp/x.c 
$ /tmp/x
errno = 0
(Continue reading)

Thomas Klausner | 23 Aug 22:22 2014
Picon

FreeBSD got a new automounter

Something to borrow?

http://svnweb.freebsd.org/base?view=revision&revision=270096

Emmanuel Dreyfus | 22 Aug 11:59 2014
X-Face
Picon

check memory mapping

Hi

Is there a way for a process to check whether a given address in mmeory 
is accessible, without triggering a signal?

There is mincore(), but it jus says wether it is already in resident
memory, not if accessing the address will swap it in or cause a SIGSEGV.

--

-- 
Emmanuel Dreyfus
manu <at> netbsd.org

Emmanuel Dreyfus | 20 Aug 17:02 2014
X-Face
Picon

Linux libaio

Hi

What can be done for porting software that depends on Linux libaio? 
It seems NetBSD has a POSIX aio feature in librt, was there some
middlewae library developped for porting libaio on NetBSD?

--

-- 
Emmanuel Dreyfus
manu <at> netbsd.org

Patrick Welche | 15 Aug 01:30 2014
Picon
Picon

PTHREAD_STACK_MIN

I just tried to compile xen, and the first problem I hit is that it makes
use of PTHREAD_STACK_MIN.

Tantalizingly, our /usr/include/limits.h says:

/* Not yet: PTHREAD_STACK_MIN */

http://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html suggests
that any positive value is possible:

  Minimum size in bytes of thread stack storage. Minimum Acceptable Value: 0

According to pthread_attr_getstack(3):

     The pthread_attr_setstacksize() function may additionally fail if:

     [EINVAL]           The specified stacksize is less than PTHREAD_STACK_MIN
                        or exceeds some system-imposed limit.

and pthread_attr_setstacksize returns EINVAL if
stacksize > _SC_THREAD_STACK_MIN (=59) as per /usr/include/sys/unistd.h.

Should PTHREAD_STACK_MIN be defined to 59?

Cheers,

Patrick

James K. Lowden | 12 Aug 02:29 2014

poison mmap cache

I'm testing different algorithms for performance against a single
memory-mapped file.  How can I best ensure that for each run the
page cache is cold, that the prior run left nothing for the current run
to take advantage of?  

I tried calling mmap(2) on an unrelated file larger than RAM, and
iterating over it.  Not only would I prefer something more
deterministic, but the following output suggests to me that technique
wasn't effective:

begin= 0x7f7f9de1e000, n= 10000000
sorted 1 of 100000000 in 2 seconds
begin= 0x7f7fa2a69408, n= 10000000
sorted 2 of 100000000 in 4 seconds
begin= 0x7f7fa76b4810, n= 10000000
sorted 3 of 100000000 in 6 seconds
begin= 0x7f7fac2ffc18, n= 10000000
sorted 4 of 100000000 in 8 seconds
begin= 0x7f7fb0f4b020, n= 10000000
sorted 5 of 100000000 in 9 seconds
begin= 0x7f7fb5b96428, n= 10000000
sorted 6 of 100000000 in 11 seconds
begin= 0x7f7fba7e1830, n= 10000000
sorted 7 of 100000000 in 13 seconds
begin= 0x7f7fbf42cc38, n= 10000000
sorted 8 of 100000000 in 14 seconds
begin= 0x7f7fc4078040, n= 10000000
sorted 9 of 100000000 in 16 seconds
begin= 0x7f7fc8cc3448, n= 10000000
sorted 10 of 100000000 in 19 seconds
(Continue reading)


Gmane