Emmanuel Dreyfus | 14 Dec 16:57 2014
Picon

power control on USB port

Hello

Do we have a way to control the power supplied to a USB port from
userland? I have an arduino board attached that seems to crash and I
would like to power cycle it from the host. Is it possible?

--

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu <at> netbsd.org

Taylor R Campbell | 12 Dec 21:42 2014
Picon

SHA-3 in libc

The attached patch implements SHA3_224/256/384/512_Init/Update/Final
following the similar sha2, sha1, md5, &c., APIs in libc.

I propose to include these in libc and pull them up to netbsd-7,
before the NIST SHA-3 draft is finalized, so that the symbols will be
available in NetBSD 7's libc for applications to use later on without
the trouble of adding symbols to libc in, e.g., NetBSD 7.1 once the
draft is finalized.

The man page will include a stern warning that the standard is a draft
and may change, which we can remove when it is finalized.  If it does
change before finalization, we can always pull up the change.  But I
think it is unlikely to change at this point.

Comments?

(I excluded the test vectors from this patch because they are three
megabytes of little interest to the mailing list for review, at
<https://github.com/gvanas/KeccakCodePackage/tree/master/TestVectors>.)
Index: common/lib/libc/Makefile.inc
===================================================================
RCS file: /cvsroot/src/common/lib/libc/Makefile.inc,v
retrieving revision 1.16
diff -p -u -r1.16 Makefile.inc
--- common/lib/libc/Makefile.inc	10 Aug 2014 23:25:49 -0000	1.16
+++ common/lib/libc/Makefile.inc	12 Dec 2014 20:22:15 -0000
 <at>  <at>  -4,7 +4,7  <at>  <at> 
 
(Continue reading)

Christos Zoulas | 10 Dec 18:05 2014

resolver function namespace protection


Most people don't notice, but although we supply all the "new"
resolver functions (res_ninit and friends), configure scripts don't
find them because of the way namespace protection is done in
<resolv.h>:

    #define res_ninit               __res_ninit  

This is because autoconf does not include the header in its test
to find the symbol, so it does not find "res_ninit".

I would like to fix that.

One way (the simplest) to fix this is to leave things the way they
are and add weak references to all the renamed symbols by adding:

    __weak_alias(res_ninit, __res_ninit)
    ...

to a file in libc, so that we keep the old __'ed names and leave
it at that.

I propose though that we go one (or two) steps further, and remove
the defines from <resolv.h>, and put them in libc/include/namespace.h
with all the rest of the renamed symbols as the second step. This is
desirable because it unclutters resolv.h and puts all the renamed
symbols in one place (or at least one place that I know of).

As a third (optional step), I propose that we move all the
__weak_aliases() from the libc c files, and autogenerate them into
(Continue reading)

Mr. dustin Kick | 4 Dec 00:55 2014
Picon

Re: Compiling Linux under emulated environment

Thank you very much!  I just got it to connect to the radio via symlinking dtyU0 to tty00 (for some reason the
fldigi source code only shows up tty00-03 on netbsd)  I had NetBSD relegated to the secondary drive, and I
might just put it back on the main one, now!

Dustin Kick
KC9MEL

On Dec 3, 2014, at 5:11 PM, Greg Troxel <gdt <at> ir.bbn.com> wrote:

> 
>> uftdi0 at uhub1 port 1
>> uftdi0: FTDI FT232R USB UART, rev 2.00/6.00, addr 2
>> ucom0 at uftdi0 portno 1
> 
> So this should mean you can use ttyU0 or /dev/dtyU0.
> 
> You might check your BIOS settings to see what serial ports are
> enabled/disabled.
> 
> Also, find the dmesg line for the dock port from debian and send that.
> It may be that it's an odd address and isn't in your netbsd kernel and
> can be added.
> 
> Your parallel port:
>  lpt2 at isa0 port 0x3bc-0x3bf irq : polled
> is at an odd address.   So maybe the serial port is too.
> Docking stations are like that.
> 
> 
> 
(Continue reading)

Mr. dustin Kick | 4 Dec 00:30 2014
Picon

Re: Compiling Linux under emulated environment

its at 0x3f8 on debian.  For me, the big question is whether I should have been able to find out what the dev file
is from the documentation.   I have tried man serial, man isa, man *ftdi*, man uart, etc, etc, and never have
been quite able to find a path that led me to a device file name.  I like many things about NetBSD, and the
UNIXes, but this is not one of them.  Lots of man pages that don't say what I need, so I still have to go ask
someone on a forum.

Dustin Kick
KC9MEL

On Dec 3, 2014, at 5:11 PM, Greg Troxel <gdt <at> ir.bbn.com> wrote:

> 
>> uftdi0 at uhub1 port 1
>> uftdi0: FTDI FT232R USB UART, rev 2.00/6.00, addr 2
>> ucom0 at uftdi0 portno 1
> 
> So this should mean you can use ttyU0 or /dev/dtyU0.
> 
> You might check your BIOS settings to see what serial ports are
> enabled/disabled.
> 
> Also, find the dmesg line for the dock port from debian and send that.
> It may be that it's an odd address and isn't in your netbsd kernel and
> can be added.
> 
> Your parallel port:
>  lpt2 at isa0 port 0x3bc-0x3bf irq : polled
> is at an odd address.   So maybe the serial port is too.
> Docking stations are like that.
> 
(Continue reading)

Mr. dustin Kick | 3 Dec 23:59 2014
Picon

Re: Compiling Linux under emulated environment

Well… for its intended purpose, I would be using the USB serial port (which hasn't worked, yet, either),
to have the laptop detached from the dock, and lighter.  A dmesg from the machine, docked, with a standard
boot show a parallel port, I believe "lpt2?", and there is a line of isa0 but with no mention of ports at all.  I
show the dmesg out, below.  Before I dumped a dmesg from a boot into my normal OS setup (from a drive on the
dock), I ran the commands: 

ttys.sh ttys_before.txt; #after which I plugged in the usb to serial cable
ttys.sh ttys_U.txt; dmesg | tail -3 >> ttys_U.txt #after which I docked the laptop
ttys.sh ttys_U_D.txt; dmesg | tail -4 >> ttys_U_D.txt

and I show a reduced dump of the output files, below (there are large sections where a type of /dev/file shows
no output from stty at all, so I'll summarized them, and after I plug in the serial cable and dock, I'll just
show diff files output, which is really just the tacked on dmesg files, since nothing changes)

So that's what I've been doing to try to find out what is supposed to be working, so far, since, at first, it
wouldn't work, then worked fine under Debian, I thought it would be a process of finding which file
represented the dock's port, which seems to be wrong, from what you've told me, and the dock port doesn't
seem to be on there at all.  I had been hoping it was one of the configured ttys from the stty dumps, and the
"constty" is something that wasn't on until my recent upgrade to 6.1.5, so I had hoped it might have
something to do with things.  Anyway, thanks for your help, again.

Dustin Kick
KC9MEL

<file:ttys.sh>
OUT=$1
for A in /dev/*ty*
do
echo '***************' >> $OUT
echo $A >> $OUT
(Continue reading)

Mr. dustin Kick | 1 Dec 16:20 2014
Picon

Compiling Linux under emulated environment

Hello,
I hope I am sending this to the proper mailing list.  I am wondering if it is possible to compile a linux program
under the emulated environment using that would be useable in both emulated linux and an actual linux.

Dustin Kick
KC9MEL

tsugutomo.enami | 27 Nov 01:47 2014
Picon

preserving full timestamps

Hi.

As you know, userland tools like cp(1) currently preserve timestamps
only up to microseconds order since there was no system call to set full
timestamps.

Nowadays, we have such system calls.  So, I'd like to change those tools
to set full timestamps unless there is an objection.

In addition, test(1) is already changed to compare full timestamps.  So,
unlike on netbsd-6 or earlier, currently the result of test -ot/nt may
be inconsistent even when timestamps are copied in a same filesystem or
between filesystems of same type.

enami.
? sbin/restore/.gdbinit
Index: bin/cp/utils.c
===================================================================
RCS file: /cvsroot/src/bin/cp/utils.c,v
retrieving revision 1.42
diff -u -r1.42 utils.c
--- bin/cp/utils.c	11 Dec 2013 06:00:11 -0000	1.42
+++ bin/cp/utils.c	27 Nov 2014 00:41:31 -0000
 <at>  <at>  -62,12 +62,12  <at>  <at> 
 int
 set_utimes(const char *file, struct stat *fs)
 {
-    static struct timeval tv[2];
(Continue reading)

Thomas Klausner | 26 Nov 00:38 2014
Picon

patch core dump with line number overflow

See
http://marc.info/?l=openbsd-tech&m=141693055412785&w=2

Also seems to apply to NetBSD's patch(1).
 Thomas

Kamil Rytarowski | 25 Nov 00:22 2014
Picon

Reuse strtonum(3) and reallocarray(3) from OpenBSD

Hello,

OpenBSD standardized in its eco-system i.e. two functions:
- reallocarray(3) is a safer drop-in replacement of realloc(3)
- strtonum(3) is yet another function to change literal string to a number

strtonum(3) became a BSD standard (OpenBSD since 3.6 A.D. 2004, FreeBSD since 6.1 A.D. 2004)
reallocarray(3) was introduced in OpenBSD 5.6 (A.D. 2014)

I don't want to start rant how these functions are good or needed, my personal intention is different:
easier code share between our BSD systems. To narrow things down, I want to use an unmodified piece of code
from the OpenBSD sources - and there pops out this compat problem.

I can see 4 solutions:
- push things upstream and import strtonum(3) and reallocarray(3) to NetBSD's stdlib,
- wrap around a system-wide reusable source-code level OpenBSD compat layer,
- patch Linux specific libbsd for emulation of OpenBSD in the NetBSD environment (I really don't want to do this!),
- all-time patching sources for missing functions and it's not so unmodified anymore (I'm so bored of
losing my time on this...).

In reality all current code in OpenBSD reuses these two functions (not counting a few bit more specialized
like explicit_bzero(3)).

If we will ever collaborate with OpenBSD with e.g. LibreSSL (not tracking how it is with at least mandoc)
these functions are must. The first solution opens possibility to reuse these functions in our
eco-system as well, the second one gives me possibility to stop making compat functions anymore for other too.

I'm a volunteer for a public-report with a patch.

Manual pages as references:
(Continue reading)

Rocky Hotas | 24 Nov 11:04 2014

Re: Understanding a source code file

Thank you for all your useful advices.
As a real "technical" clarification, there are two versions of "banner" in the system, one in /usr/games
and one in /usr/bin/banner.
The source code we used was that of /usr/games/banner. But this is not the program runned after typing
"banner" in the system, which by default is located in /usr/bin/banner. It is different and it has a
different output. Its source code is located instead in

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/usr.bin/banner/banner.c?rev=1.15&content-type=text/plain&only_with_tag=MAIN

I will test them following your useful hints.
Regards,

Rocky

> Sent: Saturday, November 22, 2014 at 12:28 AM
> From: "Iain Hibbert" <plunky <at> ogmig.net>
> To: "Rocky Hotas" <rockyhotas <at> post.com>
> Cc: "tech-userlevel <at> netbsd.org" <tech-userlevel <at> netbsd.org>
> Subject: Re: Understanding a source code file
>
> On Fri, 21 Nov 2014, Rocky Hotas wrote:
> 
> > Hoping this is the right section for my question.
> 
> maybe, in that it is a technical question relating to a userland program..
> however, I think you are asking a basic programming question really
> 
> > I would like to correctly understand the contents of a simple source
> > file: it is banner.c (/src/games/banner), the version contained in
> 
(Continue reading)


Gmane