Dan Plassche | 10 Apr 17:02 2015

Mounting an ext2fs GPT Partition as a DK Wedge under NetBSD


I'm trying to mount an ext2 partition on a GPT formatted disk attached via
usb 2 under release 6.1.2 on i386. I can mount ffs partitions by dk wedge
number (/dev/dk*), but I get an error when trying to mount an ext2
partition from the same disk:

# mount -t ext2fs -o rw /dev/dk18 /mnt
mount_ext2fs: Warning realpath /dev/dk18: No such file or directory
mount_ext2fs: /dev/dk18 on /mnt: No such file or directory

Is mounting by dk wedge unsupported for filesystems other than ffs


Dan Plassche

carsten.kunze | 4 Apr 19:37 2015

Problem with wcwidth(3)


there may be a problem with the wcwidth(3) function. The C code

#include <locale.h>
#include <stdio.h>
#include <wchar.h>
int main ()
        printf("locale: %s\n", setlocale(LC_ALL, ""));
        printf("wcwidth(0x0301) = %d\n", wcwidth (0x0301));
        printf("wcwidth(0x05B0) = %d\n", wcwidth (0x05B0));
        printf("wcwidth(0x200B) = %d\n", wcwidth (0x200B));

outputs on NetBSD 6.1.5:

locale: C/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8
wcwidth(0x0301) = 1
wcwidth(0x05B0) = 1
wcwidth(0x200B) = 1

which is wrong since all glyphs have zero width.

E.g. output on OpenBSD 5.7 is:

locale: C/en_US.UTF-8/C/C/C/en_US.UTF-8
wcwidth(0x0301) = 0
wcwidth(0x05B0) = 0
wcwidth(0x200B) = 0
(Continue reading)

Joachim Henke | 4 Apr 18:45 2015

[patch] tar: short option for xz (de)compression


I'm quite new to NetBSD. One small detail I'm missing, is a quick way
to extract *.tar.xz (or *.tar.lzma) archives. I got used to the option
'-J' present in GNU tar (FreeBSD tar has it, too):

  tar cJf archive.tar.xz dir

  tar xJf archive.tar.xz

It's not a big deal to enable it in NetBSD, as there is already the
long option --xz. Please have a look at the attached patch. What do you

Attachment (tar-xz.diff): text/x-patch, 3014 bytes
Jean-Baptiste Boric | 29 Mar 14:38 2015

Re: GSoC ATF test results statistics project

2015-03-22 23:41 GMT+01:00 Gavin Atkinson <gavin <at> freebsd.org>:
> I hope ythe list doesn't mind me posting here.  FreeBSD has been accepted
> in GSoC this year, and we use the Kyua test framework too.  If you (or
> indeed others) would be interested in working on a project that would
> produce something working on both FreeBSD and NetBSD, you are welcome to
> apply to work with us - there may even be a possibility of joint
> mentorship with somebody from NetBSD if a suitable metor could be found
> and if that would make sense.
> Thanks,
> Gavin

Well, the list itself didn't mind, but Gmail's spam filter did. I
noticed your message only now, and it's way too late to register.


If time allows and nobody steps in until then, I'll give it a try this summer.

Emmanuel Dreyfus | 26 Mar 15:13 2015

malloc, thread and alignment


jemmaloc(3) says:
  Allocations are packed tightly together, which can be an issue for multi-
  threaded applications.  If you need to assure that allocations do not
  suffer from cache line sharing, round your allocation requests up to the
  nearest multiple of the cache line size.

Do we are example of how it should be done? I do not know how to discover
cache line size, neither do I know how I can specify alignment based on it.


Emmanuel Dreyfus
manu <at> netbsd.org

matthew sporleder | 25 Mar 20:01 2015

Re: service(8): post commit feedback solicited

On Wed, Mar 25, 2015 at 11:36 AM, Adrian Steinmann <ast <at> marabu.ch> wrote:
> On Wed, Mar 25, 2015 at 09:56:26AM -0400, matthew sporleder wrote:
>> On Mon, Mar 23, 2015 at 4:26 PM, Adrian Steinmann <ast <at> netbsd.org> wrote:
> ... service(8) manpage elided ...
>> Is this supposed to work on -6?
> Well I didn't test it on -6, neither did I request a pullup-6 (but a pullup-7, where it works unchanged).
>> I can't seem to produce any output.
> I could imagine that $rc_directories is not defined in /etc/defaults/rc.conf:
> rc_directories=/etc/rc.d
> should be there.
> If it's not (I don't have access to a -6 machine ATM), try putting that line into your /etc/rc.conf or:
> [ -z "rc_directories" ] && rc_directories=/etc/rc.d
> right after the getopts in the service script itself.
> If that doesn't work, send me a
> sh -x services -ev >services_out_err_on_6 2>&1
> output under private email.
> Thanks
> Adrian
> PS. This doesn't mean I intend to pullup-6, but it'd be nice to have it work anyways.
(Continue reading)

Adrian Steinmann | 23 Mar 21:26 2015

service(8): post commit feedback solicited

[I know, this should have done _before_ putting it into the tree.]

So the question is: Does someone have strong arguments against
having this shell script to manage the rc scripts? FreeBSD has it
since version 7 and it has not changed much during those years. It
actually has more bells and whistles (i.e. higher TCO). Most linuxes
have something similar. In sum, most admins expect service to manage
the startup scripts.

Our version honors the $rc_directories variable and takes the -e
(enabled) and -l (list all) options.

$ service
usage: service [-elv]
       service [-ev] rc_script_name [rc_script_name2 [...]]
       service [-v] rc_script_name action
       -e: List enabled scripts; check if given scripts are enabled
       -l: List all scripts in rcorder
       -v: Verbose (mention in which directory script is found)
rc_directories is currently set to /etc/rc.d

$ man service

     service — run or list system services

     service [−elv]
     service [−ev] rc_script_name [rc_script_name2 [...]]
     service [−v] rc_script_name action
(Continue reading)

Emmanuel Dreyfus | 19 Mar 05:43 2015

dlopen(3) and symbol conflicts


I use dlopen(3) to load a api.so, which depends on libglustefs.so. The
later embeds its own uuid_compare symbol which is binary incompatible
with NetBSD's libc uuid_compare. The thing explodes because when I call
uuid_compare(), the libc version is used insteadof libglusterfs.so's

The problem is specific to dlopen(3): when linking at build time, libc's
uuid_compare is overriden and everything goes fine. Is it a problem on
how api.so is linked? Or how dlopen() is invoked? Or a bug in dlopen(3)?

$ ldd api.so
        -lgfapi.0 => /autobuild/install/lib/libgfapi.so.0
        -lgfrpc.0 => /autobuild/install/lib/libgfrpc.so.0
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.1 => /usr/lib/libelf.so.1
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lglusterfs.0 => /autobuild/install/lib/libglusterfs.so.0
        -lz.1 => /usr/lib/libz.so.1
        -lrt.1 => /usr/lib/librt.so.1
        -lintl.1 => /usr/lib/libintl.so.1
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lcrypto.8 => /usr/lib/libcrypto.so.8
        -lcrypt.1 => /lib/libcrypt.so.1
        -lgfxdr.0 => /autobuild/install/lib/libgfxdr.so.0

$ nm /autobuild/install/lib/libglusterfs.so|grep uuid_compare 
00067c20 T uuid_compare
(Continue reading)

Emmanuel Dreyfus | 18 Mar 09:48 2015

Re: [PATCH] Re: iflag/oflag for dd(1), round 3


After a few off-list exchanges, here is the patch I am about to commit.


Emmanuel Dreyfus
manu <at> netbsd.org

Kamil Rytarowski | 17 Mar 23:56 2015

reallocarr(3) cleanup


I'm attaching a patch with reallocarr{.ay}(3) cleanup:
- merge reallocarr.3 to malloc.3 for consistency,
- make the reallocarr(3) documentation more detailed,
- write history in malloc.3 of function allocations,
- add in malloc.3 warning about possible overflows,
- add erallocarr(3) to libutil,
- add missing Id tag to reallocarray.c,
- sync reallocarr prototype with documentation (num -> number),
- note that reallocarr first appeared in .Nx 8 not 7 (am I right about it?).

Please review the English correctness.

src/lib/libc/stdlib/reallocarray.3 is without licensing notes! please add it.

CC: authors of the new function.

Thank you for your time!

Emmanuel Dreyfus | 16 Mar 05:08 2015

iflag/oflag for dd(1)


Linux's dd(1) has iflag and oflag operands to specify the O_* flags that
should be given to open(2) for the input and output file. It works like

dd if=in.txt of=out.txt oflag=direct,sync

That tells out.txt should be open with O_RW|O_DIRECT|O_SYNC

There is the question on how to cope with existing behavior. IMO it
should behave like this:

1) iflag should completely override default O_RDONLY for input open

2) oflag should only overring O_CREAT in default output open flags:
O_RW | O_CREAT | (ddflags & (C_SEEK | C_NOTRUNC) ? 0 : O_TRUNC))
it should become:
O_RW | oflag | (ddflags & (C_SEEK | C_NOTRUNC) ? 0 : O_TRUNC))
with unspecifield oflag being set to O_CREAT

Anyone against adding the feature? I can craft a patch if it is


Emmanuel Dreyfus
manu <at> netbsd.org

(Continue reading)