Re: [patch]rcs: comment typo

2014-11-30 Thread Otto Moerbeek
On Sat, Nov 29, 2014 at 05:14:08PM +0100, Fritjof Bornebusch wrote:

 On Sat, Nov 29, 2014 at 04:53:28PM +0100, Otto Moerbeek wrote:
  On Sat, Nov 29, 2014 at 02:22:25PM +0100, Fritjof Bornebusch wrote:
  
   Hi tech,
   
   it's NULL not NUL.
  
  You're touching a big controversy here. Many developers say that NUL is
  the right term when rferring to chars and not pointers,
 
 
 And what is the correct term when referring to '0'?
 Or means '\0' and '0' the same.

The first is ASCII NUL, the seconds ASCII zero.

-Otto

 
  
  -Otto
  
   
   fritjof
   
   
   Index: diff3.c
   ===
   RCS file: /cvs/src/usr.bin/rcs/diff3.c,v
   retrieving revision 1.33
   diff -u -p -r1.33 diff3.c
   --- diff3.c   4 Mar 2012 04:05:15 -   1.33
   +++ diff3.c   29 Nov 2014 13:15:51 -
   @@ -450,7 +450,7 @@ ed_patch_lines(struct rcs_lines *dlines,
 if (lp-l_len  2)
 continue;

   - /* NUL-terminate line buffer for strtol() safety. */
   + /* NULL-terminate line buffer for strtol() safety. */
 tmp = lp-l_line[lp-l_len - 1];
 lp-l_line[lp-l_len - 1] = '\0';

   Index: rcs.c
   ===
   RCS file: /cvs/src/usr.bin/rcs/rcs.c,v
   retrieving revision 1.81
   diff -u -p -r1.81 rcs.c
   --- rcs.c 10 Oct 2014 08:15:25 -  1.81
   +++ rcs.c 29 Nov 2014 13:16:40 -
   @@ -799,7 +799,7 @@ rcs_patch_lines(struct rcs_lines *dlines
 if (lp-l_len  2)
 errx(1, line too short, RCS patch seems broken);
 op = *(lp-l_line);
   - /* NUL-terminate line buffer for strtol() safety. */
   + /* NULL-terminate line buffer for strtol() safety. */
 tmp = lp-l_line[lp-l_len - 1];
 lp-l_line[lp-l_len - 1] = '\0';
 lineno = (int)strtol((lp-l_line + 1), ep, 10);
   @@ -1047,7 +1047,7 @@ rcs_delta_stats(struct rcs_delta *rdp, i
 errx(1,
 line too short, RCS patch seems broken);
 op = *(lp-l_line);
   - /* NUL-terminate line buffer for strtol() safety. */
   + /* NULL-terminate line buffer for strtol() safety. */
 tmp = lp-l_line[lp-l_len - 1];
 lp-l_line[lp-l_len - 1] = '\0';
 (void)strtol((lp-l_line + 1), ep, 10);
  
  




DisplayLink compatibility and performance issues

2014-11-30 Thread Sławomir Gonet

Hi everyone,

I've recently bought DisplayLink device[1]. According to [2], it
might/should work under OpenBSD so I gived it a try. My results are:

1) Not detected USB PID - I've added it as new device to kernel's udl
   driver.
2) Conflict with bulit-in Intel HD graphics card.
   I spent some time debugging why xf86-video-wsudl is not detecting my
   DL-165 adapter. After downloading xenocara I was debugging wsudl and
   what I found:
   
   WsudlProbe():
   driver/xf86-video-wsudl/src/wsudl_driver.c:309 calls xf86ClaimFbSlot()

   xf86ClaimFbSlot()
   xserver/hw/xfree86/common/xf86fbBus.c:62 checks if pciSlotClaimed is
   true.

   And, unfortunately, on my platform pciSlotClaimed == 1, because of
   intel driver. However, things started to work when before calling
   xf86ClaimFbSlot() I've set pciSlotClaimed to 0.
3) UDL device does not get auto-detected
   I had to define UDL device manually in xorg.conf and connect screens
   using Xinerama to make it working
4) Resolution problems with Intel - maybe because of hacking from point
   2 in random situations intel driver fails and messes up resolution on
   one of the screens - about 3/4 of screen become unusable. No idea
   how to explain it.
5) Performance
   What I've found: [3] - so more or less It will not work, no
   way. But under Linux there are no performance issues at all. I can
   even play video (but not in fullscreen), 1080p works great. Where's
   the bottleneck in OpenBSD? I am not even able to move window on the
   desktop smoothly, in idle Xorg process consumes 5-10% of CPU with
   peaks up to 40%.

Further informations about my platform:
- Lenovo ThinkPad t420s with Intel i7.
- 2× BENQ G2420HD
- i-tec 2.0 TRIO USB to DVI (DisplayLink DL-165 inside)

Unfortunately, I am really newbie in both OpenBSD and kernel
development, so I am afraid that debugging like this is everything I am
able to. Are there any active developers of wsudl driver? Issues 4 and 5
are fatal to me, I need two displays - do you have any ideas how to move
things forward here?

Regards,
Slawek


[1] - http://www.i-tec-europe.eu/?t=3v=130
[2] - http://libdlo.freedesktop.org/wiki/
[3] - 
http://openbsd.7691.n7.nabble.com/Xorg-wsudl-4-DL-165-consumes-a-lot-of-cpu-td224195.html

-- 

SG


pgpJoB82DNdkm.pgp
Description: PGP signature


Re: urndis(4) fix

2014-11-30 Thread Jonathan Armani
On Sat, Nov 29, 2014 at 09:42:51PM +0100, Mark Kettenis wrote:
 Recent Oracle SPARC machines have a USB gadget to talk to the Service
 Processor (ILOM).  This gadget supports both RNDIS and CDC Ethernet.
 The RNDIS bits uncovered a bug in urndis(4).  When urndis_ctrl_set()
 sets up the REMOTE_NDIS_SET_MSG command it sets up msg-rm_infobuflen,
 it subsequently overwrites its contents.  Apparently many RNDIS
 devices don't care, but this hardware sends a response back that
 indicates the command wasn't accepted.  Diff below fixes this problem.
 It matches what Linux does.
 
 Unfortunately, this isn't enough to make the gadget work in RNDIS mode.
 
 I'd appreciate it if people using urndis(4) could test this diff.
 

Makes sense, ok armani@ (over urndis)



clang++ and a modern C++ library

2014-11-30 Thread Dave Huseby
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Status update...

I've been working on porting Rust over to OpenBSD by building a Rust
cross-compiler for Linux that can target i386-unknown-openbsd and
x86_64-unknown-openbsd.  The largest roadblock on OpenBSD is the lack
of a more recent GNU linker (ld).  I have tried the 2.17 linker in the
source tree and it doesn't work.  To catch everybody up, the rust
compiler is built on LLVM and uses C++1x which requires a newer
compiler.  I started by using 4.8.3 on OpenBSD but the old linker
isn't working.

Somebody suggested using clang on OpenBSD, but it appears that the
port for clang++ doesn't include libc++.  Is that correct?  So clang++
doesn't have a new enough standard C++ library to do the job.  I've
tried using clang++ with the libstdc++ that is part of the gcc 4.8.3
port but I can't seem to figure out the magic set of parameters to
clang++ to make it select the newer libstdc++ that is part of the gcc
4.8.3 port.

I'm starting to think that this may not be possible without some
catching up on toolchains for OpenBSD.  And given the conservative
nature of OpenBSD, it may be some time before the toolchains are
modern enough to compile and link the Rust compiler.

- --dave
-BEGIN PGP SIGNATURE-

iF4EAREIAAYFAlR7qwoACgkQvt/JvmUQuOmMmQD+KpYTqyiNJJBoZos7+CQnOTG4
XmsrUbU8lPtOGM9kBCoA/j7e+Ghe+1hHOqBNFZlyj9cx6AfWDjN30dJ/5vNvjoED
=eufW
-END PGP SIGNATURE-


0x6510B8E9.asc
Description: application/pgp-keys


0x6510B8E9.asc.sig
Description: PGP signature


patch: fix %c in awk's printf when printing a number near 0

2014-11-30 Thread Jeremy Devenport
It looks like this bug was almost fixed nearly 20 years ago.
Unfortunately that fix only addressed the case where the floating point
value was exactly zero and not the case where the integer conversion
would coerce it to zero.

I've tested locally that this resolves the issue that Jan Stary
reported on misc but haven't done any testing beyond that.

A simple example of the bug is:

$ awk 'BEGIN { printf(%c, 0.1) }' | hexdump -C
$ awk-patched 'BEGIN { printf(%c, 0.1) }' | hexdump -C
  00|.|
0001
$ gawk 'BEGIN { printf(%c, 0.1) }' | hexdump -C
  00|.|
0001
$ mawk 'BEGIN { printf(%c, 0.1) }' | hexdump -C
  00|.|
0001


Index: run.c
===
RCS file: /cvs/src/usr.bin/awk/run.c,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 run.c
--- run.c   29 Sep 2013 15:42:25 -  1.34
+++ run.c   30 Nov 2014 23:38:00 -
@@ -921,7 +921,7 @@ int format(char **pbuf, int *pbufsize, c
break;
case 'c':
if (isnum(x)) {
-   if (getfval(x))
+   if ((int)getfval(x))
snprintf(p, buf + bufsize - p,
fmt, (int) getfval(x));
else {
*p++ = '\0'; /* explicit null byte */



Re: patch: fix %c in awk's printf when printing a number near 0

2014-11-30 Thread Todd C. Miller
Looks good, committed.  I'll forward this upstream.

 - todd



LibreSSL Windows port status update

2014-11-30 Thread Brent Cook
I got a Windows 8.1 box running this weekend and spent some quality
time making poll(2) emulation more robust, so that it can deal with
more of the select-poll conversions in openssl(1) coming in the
future. I also got the upstream poll conversion patches themselves in
better working order. This Windows port is now achieved without any
#ifdefs or odd workarounds. So, it should be possible to maintain
support without having too many new warts in the LibreSSL tree.

So, what can it do now? Well, you can run this command in a powershell window:

.\apps\openssl.exe s_server -cert tests\server.pem

and this in another:

.\apps\openssl.exe s_client

and type on the console back and forth interactively. You can also run
this from powershell and still get the expected result:

cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433

No big deal for those fancy 'everything works like a file' operating
systems, but Windows very special in its handling of sockets vs.
console IO vs pipes. Performance-wise, it's currently about 50x slower
than Cygwin's native openssl.exe, but I have not begun to optimize
anything yet.

https://github.com/busterb/portable/commits/win32-minimal

https://github.com/busterb/openbsd/commits/win32-minimal

 - Brent



Re: LibreSSL Windows port status update

2014-11-30 Thread Dongsheng Song
Cool !

I can see you do lot's of update on select-poll conversions.
The code become more and more complex since you want it works more general.

Can we use simply WSAPoll[1] instead ?

--
#ifdef _WIN32
#define poll WSAPoll
#endif
--

[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx

On Mon, Dec 1, 2014 at 11:58 AM, Brent Cook bust...@gmail.com wrote:
 I got a Windows 8.1 box running this weekend and spent some quality
 time making poll(2) emulation more robust, so that it can deal with
 more of the select-poll conversions in openssl(1) coming in the
 future. I also got the upstream poll conversion patches themselves in
 better working order. This Windows port is now achieved without any
 #ifdefs or odd workarounds. So, it should be possible to maintain
 support without having too many new warts in the LibreSSL tree.

 So, what can it do now? Well, you can run this command in a powershell window:

 .\apps\openssl.exe s_server -cert tests\server.pem

 and this in another:

 .\apps\openssl.exe s_client

 and type on the console back and forth interactively. You can also run
 this from powershell and still get the expected result:

 cat .\README | apps\openssl.exe s_client -connect 127.0.0.1:4433

 No big deal for those fancy 'everything works like a file' operating
 systems, but Windows very special in its handling of sockets vs.
 console IO vs pipes. Performance-wise, it's currently about 50x slower
 than Cygwin's native openssl.exe, but I have not begun to optimize
 anything yet.

 https://github.com/busterb/portable/commits/win32-minimal

 https://github.com/busterb/openbsd/commits/win32-minimal

  - Brent



Re: LibreSSL Windows port status update

2014-11-30 Thread Brad Smith

On 12/01/14 01:10, Dongsheng Song wrote:

Cool !

I can see you do lot's of update on select-poll conversions.
The code become more and more complex since you want it works more general.

Can we use simply WSAPoll[1] instead ?

--
#ifdef _WIN32
#define poll WSAPoll
#endif
--

[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx


There is a URL posted at the bottom of that page that points out how it
is broken and should not be used.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: clang++ and a modern C++ library

2014-11-30 Thread Stuart Henderson
On 2014/11/30 15:40, Dave Huseby wrote:
 Somebody suggested using clang on OpenBSD, but it appears that the
 port for clang++ doesn't include libc++.  Is that correct?

Yes.