ld.so: remove unused syscall stubs

[Philip Guenther]

_dl_gettimeofday() was used by the prebind code, which was recently 
removed.

_dl_lstat() was only used by _dl_realpath(), which no longer needs it.

ok?


Index: alpha/ldasm.S
===
RCS file: /cvs/src/libexec/ld.so/alpha/ldasm.S,v
retrieving revision 1.36
diff -u -p -r1.36 ldasm.S
--- alpha/ldasm.S   7 Aug 2016 03:05:23 -   1.36
+++ alpha/ldasm.S   28 Aug 2016 04:12:17 -
@@ -316,10 +316,8 @@ DL_SYSCALL(getdents)
 DL_SYSCALL(getentropy)
 DL_SYSCALL(sendsyslog)
 DL_SYSCALL(pledge)
-DL_SYSCALL(gettimeofday)
 DL_SYSCALL_NOERR(issetugid)
 DL_SYSCALL_NOERR(getthrid)
-DL_SYSCALL(lstat)
 DL_SYSCALL(mprotect)
 DL_SYSCALL(munmap)
 DL_SYSCALL(open)
Index: alpha/syscall.h
===
RCS file: /cvs/src/libexec/ld.so/alpha/syscall.h,v
retrieving revision 1.34
diff -u -p -r1.34 syscall.h
--- alpha/syscall.h 4 Jul 2016 21:15:06 -   1.34
+++ alpha/syscall.h 28 Aug 2016 04:12:17 -
@@ -51,10 +51,8 @@ int  _dl_fstat(int, struct stat *);
 ssize_t_dl_getdents(int, char *, size_t);
 long   _dl__syscall(quad_t, ...);
 int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t);
-int_dl_gettimeofday(struct timeval *, struct timezone *);
 ssize_t_dl_readlink(const char *, char *, size_t);
 int_dl_pledge(const char *, const char **);
-int_dl_lstat(const char *, struct stat *);
 int_dl_getcwd(char *, size_t);
 int_dl_utrace(const char *, const void *, size_t);
 int_dl_getentropy(char *, size_t);
Index: amd64/ldasm.S
===
RCS file: /cvs/src/libexec/ld.so/amd64/ldasm.S,v
retrieving revision 1.24
diff -u -p -r1.24 ldasm.S
--- amd64/ldasm.S   7 May 2016 19:05:23 -   1.24
+++ amd64/ldasm.S   28 Aug 2016 04:12:17 -
@@ -91,10 +91,8 @@ DL_SYSCALL(getthrid)
 DL_SYSCALL(getdents)
 DL_SYSCALL(mprotect)
 DL_SYSCALL(munmap)
-DL_SYSCALL(gettimeofday)
 DL_SYSCALL(exit)
 DL_SYSCALL(readlink)
-DL_SYSCALL(lstat)
 DL_SYSCALL(utrace)
 DL_SYSCALL(getentropy)
 DL_SYSCALL(sendsyslog)
Index: amd64/syscall.h
===
RCS file: /cvs/src/libexec/ld.so/amd64/syscall.h,v
retrieving revision 1.22
diff -u -p -r1.22 syscall.h
--- amd64/syscall.h 4 Jul 2016 21:15:06 -   1.22
+++ amd64/syscall.h 28 Aug 2016 04:12:18 -
@@ -51,10 +51,8 @@ ssize_t  _dl_read(int, const char *, size
 int_dl_fstat(int, struct stat *);
 ssize_t_dl_getdents(int, char *, size_t);
 int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t);
-int_dl_gettimeofday(struct timeval *, struct timezone *);
 ssize_t_dl_readlink(const char *, char *, size_t);
 int_dl_pledge(const char *, const char **);
-int_dl_lstat(const char *, struct stat *);
 int_dl_getcwd(char *, size_t);
 int_dl_utrace(const char *, const void *, size_t);
 int_dl_getentropy(char *, size_t);
Index: arm/ldasm.S
===
RCS file: /cvs/src/libexec/ld.so/arm/ldasm.S,v
retrieving revision 1.23
diff -u -p -r1.23 ldasm.S
--- arm/ldasm.S 9 Aug 2016 03:58:35 -   1.23
+++ arm/ldasm.S 28 Aug 2016 04:12:18 -
@@ -126,9 +126,7 @@ DL_SYSCALL(open)
 DL_SYSCALL(read)
 DL_SYSCALL(write)
 DL_SYSCALL(fstat)
-DL_SYSCALL(gettimeofday)
 DL_SYSCALL(readlink)
-DL_SYSCALL(lstat)
 DL_SYSCALL(utrace)
 DL_SYSCALL(getentropy)
 DL_SYSCALL(sendsyslog)
Index: arm/syscall.h
===
RCS file: /cvs/src/libexec/ld.so/arm/syscall.h,v
retrieving revision 1.22
diff -u -p -r1.22 syscall.h
--- arm/syscall.h   4 Jul 2016 21:15:06 -   1.22
+++ arm/syscall.h   28 Aug 2016 04:12:18 -
@@ -51,10 +51,8 @@ ssize_t  _dl_read(int, const char *, size
 int_dl_fstat(int, struct stat *);
 ssize_t_dl_getdents(int, char *, size_t);
 int_dl_sysctl(const int *, u_int, void *, size_t *, void *, size_t);
-int_dl_gettimeofday(struct timeval *, struct timezone *);
 ssize_t_dl_readlink(const char *, char *, size_t);
 int_dl_pledge(const char *, const char **);
-int_dl_lstat(const char *, struct stat *);
 int_dl_getcwd(char *, size_t);
 int_dl_utrace(const char *, const void *, size_t);
 int_dl_getentropy(char *, size_t);
Index: hppa/ldasm.S
===
RCS file: /cvs/src/libexec/ld.so/hppa/ldasm.S,v
retrieving revision 1.21
diff -u -p -r1.21 ldasm.S
--- hppa/ldasm.S7 May 2016 19:05:23 -   1.21
+++ hppa/ldasm.S28 Aug 2016 04:12:18 -
@@ -242,23 +242,11 @@ ENTRY(_dl_getdents,0)
nop
 EXIT(_dl_getdents)
 
-ENTRY(_dl_gettimeofday,0)
-   SYSCALL(gettimeofday)
-   bv  r0(rp)
-   nop
-EXIT(_dl_gettimeofday)
-
 ENTRY(_dl_readlink,0)
SYSCALL(readlink)
bv 

Re: replace struct vattr with struct stat in fusebuf

[Philip Guenther]

Sigh, stupid control-enter keybinding in gmail
What I meant to say was:


BTW, this chunk in fusefs_setattr():

On Sat, Aug 27, 2016 at 8:50 PM, Philip Guenther  wrote:
> if (io->fi_flags & FUSE_FATTR_SIZE && vp->v_type == VDIR) {
> error = EISDIR;
> goto out;
> }

can be deleted, as it's already covered by the code that set FUSE_FATTR_SIZE


Philip

Re: replace struct vattr with struct stat in fusebuf

[Philip Guenther]

if (io->fi_flags & FUSE_FATTR_SIZE && vp->v_type == VDIR) {
error = EISDIR;
goto out;
}

Re: replace struct vattr with struct stat in fusebuf

[Philip Guenther]

On Sat, Aug 27, 2016 at 4:42 AM, Martin Natano  wrote:
> In struct fusebuf the attributes (used for getattr/setattr and to return
> the ino/mode of a newly created file) are stored in a struct vattr. The
> problem with this is, that using struct vattr in userspace is suboptimal
> as some related helpers are not available, e.g. VATTR_NULL() and IFTOVT().
>
> What happens on getattr is this: fusefs requests the attributes for a
> file from the userland process. libfuse calls the getattr fuse
> operation, which fills in a struct stat. This struct is than converted
> to a partial struct vattr, which is passed back to the kernel where
> "fixup" takes place.
>
> Following diff simplifies that process by replacing the struct vattr in
> fusebuf with a struct stat. The conversion is moved to the kernel where
> it belongs. As a side effect the  include can be removed
> from libfuse.
>
> Ok? Objections?

ok guenther@

Please delete the #include  I added to fuse_private.h
while you're there, as it was only needed for vnode.h


Philip Guenther

Re: cwm(1): Enable numpad Enter on menus

[Bob Beck]

I have no objections.. If I hear none by monday I can commit it for you


On Sat, Aug 27, 2016 at 11:53:14PM -0300, Henrique N. Lengler wrote:
> > Hi,
> > 
> > This is a tiny patch to enable the use of numpad Enter key on cwm menus.
> > 
> > Regards,
> > 
> > Henrique N. Lengler
> 
> No intention to apply this?
> 
> Numpad enter key is is recognized by every program on openbsd base and 
> xenocara,
> so this would keep consistency. Anyway it is only one line.

> Index: menu.c
> ===
> RCS file: /cvs/xenocara/app/cwm/menu.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 menu.c
> --- menu.c28 Apr 2016 16:28:38 -  1.90
> +++ menu.c17 Aug 2016 19:14:06 -
> @@ -523,6 +523,7 @@ menu_keycode(XKeyEvent *ev, enum ctltype
>   case XK_BackSpace:
>   *ctl = CTL_ERASEONE;
>   break;
> + case XK_KP_Enter:
>   case XK_Return:
>   *ctl = CTL_RETURN;
>   break;

Re: cwm(1): Enable numpad Enter on menus

[Henrique N. Lengler]

> Hi,
> 
> This is a tiny patch to enable the use of numpad Enter key on cwm menus.
> 
> Regards,
> 
> Henrique N. Lengler

No intention to apply this?

Numpad enter key is is recognized by every program on openbsd base and xenocara,
so this would keep consistency. Anyway it is only one line.
Index: menu.c
===
RCS file: /cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.90
diff -u -p -r1.90 menu.c
--- menu.c  28 Apr 2016 16:28:38 -  1.90
+++ menu.c  17 Aug 2016 19:14:06 -
@@ -523,6 +523,7 @@ menu_keycode(XKeyEvent *ev, enum ctltype
case XK_BackSpace:
*ctl = CTL_ERASEONE;
break;
+   case XK_KP_Enter:
case XK_Return:
*ctl = CTL_RETURN;
break;

Re: pf.conf X11 rule.

[Theo de Raadt]

Well you've failed to justify removing it.

Does it hurt anyone to leave it?

> Xserver no longer listen on tcp 6000:6010 by default. I wonder if that pf
> rule is still necessary.
> 
> 
> Index: pf.conf
> ===
> RCS file: /cvs/src/etc/pf.conf,v
> retrieving revision 1.54
> diff -u -p -r1.54 pf.conf
> --- pf.conf   23 Aug 2014 05:49:42 -  1.54
> +++ pf.conf   28 Aug 2016 01:22:26 -
> @@ -6,6 +6,3 @@ set skip on lo
>  
>  block return # block stateless traffic
>  pass # establish keep-state
> -
> -# By default, do not permit remote connections to X11
> -block return in on ! lo0 proto tcp to port 6000:6010
> 

simplify realpath(3) slightly

[Philip Guenther]

Currently, realpath() calls lstat() on each component and -- if it's a 
symlink -- then call readlink() on it.  All it uses the lstat() for is "is 
this a symlink".

Umm, readlink() will tell you that, more cheaply!  Just call readlink() 
directly and if it returns EINVAL then its not a symlink.

Diff below makes this change for both libc and dl_realpath inside ld.so

ok?


Philip Guenther


Index: lib/libc/stdlib/realpath.c
===
RCS file: /data/src/openbsd/src/lib/libc/stdlib/realpath.c,v
retrieving revision 1.20
diff -u -p -r1.20 realpath.c
--- lib/libc/stdlib/realpath.c  13 Oct 2015 20:55:37 -  1.20
+++ lib/libc/stdlib/realpath.c  28 Aug 2016 00:08:20 -
@@ -27,8 +27,6 @@
  * SUCH DAMAGE.
  */
 
-#include 
-
 #include 
 #include 
 #include 
@@ -47,7 +45,6 @@
 char *
 realpath(const char *path, char *resolved)
 {
-   struct stat sb;
char *p, *q, *s;
size_t left_len, resolved_len;
unsigned symlinks;
@@ -148,21 +145,27 @@ realpath(const char *path, char *resolve
errno = ENAMETOOLONG;
goto err;
}
-   if (lstat(resolved, ) != 0) {
-   if (errno == ENOENT && p == NULL) {
-   errno = serrno;
-   return (resolved);
+   slen = readlink(resolved, symlink, sizeof(symlink) - 1);
+   if (slen < 0) {
+   switch (errno) {
+   case EINVAL:
+   /* not a symlink, continue to next component */
+   continue;
+   case ENOENT:
+   if (p == NULL) {
+   errno = serrno;
+   return (resolved);
+   }
+   /* FALLTHROUGH */
+   default:
+   goto err;
}
-   goto err;
-   }
-   if (S_ISLNK(sb.st_mode)) {
+   } else {
if (symlinks++ > SYMLOOP_MAX) {
errno = ELOOP;
goto err;
}
-   slen = readlink(resolved, symlink, sizeof(symlink) - 1);
-   if (slen < 0)
-   goto err;
+
symlink[slen] = '\0';
if (symlink[0] == '/') {
resolved[1] = 0;
Index: libexec/ld.so/dl_realpath.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/dl_realpath.c,v
retrieving revision 1.3
diff -u -p -r1.3 dl_realpath.c
--- libexec/ld.so/dl_realpath.c 19 Oct 2014 03:56:28 -  1.3
+++ libexec/ld.so/dl_realpath.c 28 Aug 2016 00:37:22 -
@@ -28,11 +28,10 @@
  */
 
 #include 
+#include 
 #include 
 #include "archdep.h"
 
-#define ENOENT -2
-
 /*
  * This file was copied from libc/stdlib/realpath.c and modified for ld.so's
  * syscall method which returns -errno.
@@ -48,12 +47,11 @@
 char *
 _dl_realpath(const char *path, char *resolved)
 {
-   struct stat sb;
const char *p, *s;
char *q;
size_t left_len, resolved_len;
unsigned symlinks;
-   int slen, mem_allocated, ret;
+   int slen, mem_allocated;
char left[PATH_MAX], next_token[PATH_MAX], symlink[PATH_MAX];
 
if (path[0] == '\0') {
@@ -135,27 +133,33 @@ _dl_realpath(const char *path, char *res
}
 
/*
-* Append the next path component and lstat() it. If
-* lstat() fails we still can return successfully if
-* there are no more path components left.
+* Append the next path component and readlink() it. If
+* readlink() fails we still can return successfully if
+* it wasn't a exists but isn't a symlink, or if there
+* are no more path components left.
 */
resolved_len = _dl_strlcat(resolved, next_token, PATH_MAX);
if (resolved_len >= PATH_MAX) {
goto err;
}
-   if ((ret = _dl_lstat(resolved, )) != 0) {
-   if (ret == ENOENT && p == NULL) {
-   return (resolved);
+   slen = _dl_readlink(resolved, symlink, sizeof(symlink) - 1);
+   if (slen < 0) {
+   switch (slen) {
+   case -EINVAL:
+   /* not a symlink, continue to next component */
+   continue;
+   case -ENOENT:
+   if (p == NULL)
+   

Re: Licensing into base using multiple languages, C and Perl

[Chris Bennett]

On Sat, Aug 27, 2016 at 08:31:02PM +0200, Ingo Schwarze wrote:
> Hi Chris,
> 
> i'm not sure that i understand all your questions, but i'm trying
> to answer as best i can.
> 
> Chris Bennett wrote on Sat, Aug 27, 2016 at 12:00:29PM -0500:
> 
> > I'd like some help understanding how the policy works with actually
> > having something acceptable to being included into base vs. needing to
> > be a port.
> > Some code essentially has only one way to write it and I see it all over
> > the place. Calling a variable with another name doesn't seem at all like
> > original code to me.
> 
> Copyright doesn't apply to single lines, even less to single words.
> It applies to "works".
> 
>   https://en.wikipedia.org/wiki/Copyright#Eligible_works
> 
> So, if you somehow get to look at some proprietary software and
> like some variable name, you are free to use the same name in your
> own software from the Copyright point of view (of course, if the
> code belongs to your employer, your working contract might forbid
> that you use information obtained at work privately, but that has
> nothing to do with Copyright).
> 
> > There is code in base written in Perl that is new code.
> > Base Perl changes adds and removes modules over time, like CGI being
> > removed.
> > For example, using a base Perl module might be a problem if it is
> > updated and removed to CPAN with a license change. Bang! Problem.
> 
> OpenBSD base includes many modules that are from CPAN and not
> from Perl base.  When these are updated, we check that the license
> is still OK.  In practice, that's hardly ever a problem because
> most stuff in CPAN is published under the Perl Artistic license,
> which allows inclusion into OpenBSD.
> 
> > Also, there is existing code that I never ever look at, but I write
> > essentially the same code myself independently. How does that effect
> > things?
> 
> Doesn't matter:
> 
>   https://en.wikipedia.org/wiki/Copyright#Originality
> 
>   "Two authors may own copyright on two substantially identical
>works, if it is determined that the duplication was coincidental,
>and neither was copied from the other."
> 
> In practice, that's rare, because Copyright applies to works, not
> to lines or words, and chances that a complete work (e.g.  software
> program) is identically written by two people independent of each
> other are very low.  There is a famous story, though, where in early
> UNIX development, even though Ken Thompson and Dennis Richie usually
> knew where each other was working and kept their areas of work
> separate, both did write exactly the same program.  It was such a
> rare event that people still marvel at it.
> 
> > There are also many modules on CPAN that use the same license as Perl
> > itself. Can I bring the code itself only into the project, not the
> > module so that only that version is used?
> 
> Yes.  The Perl Artistic license allows creation of derivative works.
> So you can take parts from programs and modules and create and
> distribute modified versions, as long as you keep the original
> Copyright notice and license, make it clear what you changed,
> and distribute the changed files as free software - for details,
> see the file "Artistic".
> 
> > There are also bits of code that are very restrictively licensed.
> > Do I even dare look at it for ideas?
> 
> Doesn't matter at all.  Ideas are never subject to Copyright,
> only the *expression* of an idea in a particular form is.
> So there is no problem if you carefully study the source code
> of a program, then write your own program doing exactly the same,
> as long as you don't copy code in the process.
> 
> Of course, the Copyright holder of the program might sue you,
> claiming that you *did* copy stuff, and if that person or company
> is rich, such a lawsuit might be very inconvenient.  For that
> reason, people who are exceptionally prudent sometimes use
> 
>   https://en.wikipedia.org/wiki/Clean_room_design
> 
> in particular when dealing with commercial code coming from
> corporations who are notorious for sueing.
> 

Thanks, this is very helpful. Having a third party write a specification
to work toward is not a step I was aware of as being helpful legally.

Suing seems to be very popular these days. I don't want either myself or
OpenBSD to have any problems of this kind.

Despite having seen it mentioned with the big companies suing over
patents, I didn't even think of that pitfall.

I have so far made sure to not look at any code (except in some books
about programming) which did not have a suitable license for derivative
use.

> I'm not a lawyer, this is merely how i understand that stuff.
> I won't pay you damages if you rely on this and something goes
> wrong, the responsibility for what you do is yours.  When in
> doubt, ask a lawyer.

Yes, sounds almost like writing anything that could be construed as
copying could be problematical. Sounds like so far distancing myself
from actual code examination has been the 

Re: Licensing into base using multiple languages, C and Perl

[Ingo Schwarze]

Hi Chris,

i'm not sure that i understand all your questions, but i'm trying
to answer as best i can.

Chris Bennett wrote on Sat, Aug 27, 2016 at 12:00:29PM -0500:

> I'd like some help understanding how the policy works with actually
> having something acceptable to being included into base vs. needing to
> be a port.
> Some code essentially has only one way to write it and I see it all over
> the place. Calling a variable with another name doesn't seem at all like
> original code to me.

Copyright doesn't apply to single lines, even less to single words.
It applies to "works".

  https://en.wikipedia.org/wiki/Copyright#Eligible_works

So, if you somehow get to look at some proprietary software and
like some variable name, you are free to use the same name in your
own software from the Copyright point of view (of course, if the
code belongs to your employer, your working contract might forbid
that you use information obtained at work privately, but that has
nothing to do with Copyright).

> There is code in base written in Perl that is new code.
> Base Perl changes adds and removes modules over time, like CGI being
> removed.
> For example, using a base Perl module might be a problem if it is
> updated and removed to CPAN with a license change. Bang! Problem.

OpenBSD base includes many modules that are from CPAN and not
from Perl base.  When these are updated, we check that the license
is still OK.  In practice, that's hardly ever a problem because
most stuff in CPAN is published under the Perl Artistic license,
which allows inclusion into OpenBSD.

> Also, there is existing code that I never ever look at, but I write
> essentially the same code myself independently. How does that effect
> things?

Doesn't matter:

  https://en.wikipedia.org/wiki/Copyright#Originality

  "Two authors may own copyright on two substantially identical
   works, if it is determined that the duplication was coincidental,
   and neither was copied from the other."

In practice, that's rare, because Copyright applies to works, not
to lines or words, and chances that a complete work (e.g.  software
program) is identically written by two people independent of each
other are very low.  There is a famous story, though, where in early
UNIX development, even though Ken Thompson and Dennis Richie usually
knew where each other was working and kept their areas of work
separate, both did write exactly the same program.  It was such a
rare event that people still marvel at it.

> There are also many modules on CPAN that use the same license as Perl
> itself. Can I bring the code itself only into the project, not the
> module so that only that version is used?

Yes.  The Perl Artistic license allows creation of derivative works.
So you can take parts from programs and modules and create and
distribute modified versions, as long as you keep the original
Copyright notice and license, make it clear what you changed,
and distribute the changed files as free software - for details,
see the file "Artistic".

> There are also bits of code that are very restrictively licensed.
> Do I even dare look at it for ideas?

Doesn't matter at all.  Ideas are never subject to Copyright,
only the *expression* of an idea in a particular form is.
So there is no problem if you carefully study the source code
of a program, then write your own program doing exactly the same,
as long as you don't copy code in the process.

Of course, the Copyright holder of the program might sue you,
claiming that you *did* copy stuff, and if that person or company
is rich, such a lawsuit might be very inconvenient.  For that
reason, people who are exceptionally prudent sometimes use

  https://en.wikipedia.org/wiki/Clean_room_design

in particular when dealing with commercial code coming from
corporations who are notorious for sueing.

I'm not a lawyer, this is merely how i understand that stuff.
I won't pay you damages if you rely on this and something goes
wrong, the responsibility for what you do is yours.  When in
doubt, ask a lawyer.

Yours,
  Ingo

Re: use strnlen() in vfprintf.c

[Stefan Sperling]

On Sat, Aug 27, 2016 at 07:34:53PM +0200, Ingo Schwarze wrote:
> Hi Todd,
> 
> Todd C. Miller wrote on Sat, Aug 27, 2016 at 10:28:14AM -0600:
> 
> > Now that we have a handy size_t scratch variable,
> > we can use it to store the return value of mbrtowc()
> > instead of storing it in an int.  Worth it or overkill?
> 
> Some interfaces are specifically designed to trap the unwary.
> That includes mb[r]towc(3), in multiple respects.  When dealing with
> such trapful interfaces, paying extra attention to careful idiomatics
> helps auditing and ultimately catching and avoiding some of the
> unavoidable errors.  Hence, worth it.
> 
> OK schwarze@
>   Ingo

I agree. OK by me as well.

> > Index: lib/libc/stdio/vfprintf.c
> > ===
> > RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v
> > retrieving revision 1.76
> > diff -u -p -u -r1.76 vfprintf.c
> > --- lib/libc/stdio/vfprintf.c   27 Aug 2016 16:10:40 -  1.76
> > +++ lib/libc/stdio/vfprintf.c   27 Aug 2016 16:26:04 -
> > @@ -489,17 +489,17 @@ __vfprintf(FILE *fp, const char *fmt0, _
> > size_t len;
> >  
> > cp = fmt;
> > -   while ((n = mbrtowc(, fmt, MB_CUR_MAX, )) > 0) {
> > -   fmt += n;
> > +   while ((len = mbrtowc(, fmt, MB_CUR_MAX, )) != 0) {
> > +   if (len == (size_t)-1 || len == (size_t)-2) {
> > +   ret = -1;
> > +   goto error;
> > +   }
> > +   fmt += len;
> > if (wc == '%') {
> > fmt--;
> > break;
> > }
> > }
> > -   if (n < 0) {
> > -   ret = -1;
> > -   goto error;
> > -   }
> > if (fmt != cp) {
> > ptrdiff_t m = fmt - cp;
> > if (m < 0 || m > INT_MAX - ret)
> > @@ -507,7 +507,7 @@ __vfprintf(FILE *fp, const char *fmt0, _
> > PRINT(cp, m);
> > ret += m;
> > }
> > -   if (n == 0)
> > +   if (len == 0)
> > goto done;
> > fmt++;  /* skip over '%' */
> >  
> > @@ -1217,17 +1217,19 @@ __find_arguments(const char *fmt0, va_li
> >  * Scan the format for conversions (`%' character).
> >  */
> > for (;;) {
> > +   size_t len;
> > +
> > cp = fmt;
> > -   while ((n = mbrtowc(, fmt, MB_CUR_MAX, )) > 0) {
> > -   fmt += n;
> > +   while ((len = mbrtowc(, fmt, MB_CUR_MAX, )) != 0) {
> > +   if (len == (size_t)-1 || len == (size_t)-2)
> > +   return (-1);
> > +   fmt += len;
> > if (wc == '%') {
> > fmt--;
> > break;
> > }
> > }
> > -   if (n < 0)
> > -   return (-1);
> > -   if (n == 0)
> > +   if (len == 0)
> > goto done;
> > fmt++;  /* skip over '%' */
> >  
> 

Licensing into base using multiple languages, C and Perl

[Chris Bennett]

I'd like some help understanding how the policy works with actually
having something acceptable to being included into base vs. needing to
be a port.
Some code essentially has only one way to write it and I see it all over
the place. Calling a variable with another name doesn't seem at all like
original code to me.

There is code in base written in Perl that is new code.
Base Perl changes adds and removes modules over time, like CGI being
removed.
For example, using a base Perl module might be a problem if it is
updated and removed to CPAN with a license change. Bang! Problem.

Also, there is existing code that I never ever look at, but I write
essentially the same code myself independently. How does that effect
things?

There are also many modules on CPAN that use the same license as Perl
itself. Can I bring the code itself only into the project, not the
module so that only that version is used?

There are also bits of code that are very restrictively licensed. Do I
even dare look at it for ideas?

Thanks,
Chris Bennett

Re: use strnlen() in vfprintf.c

[Todd C. Miller]

On Sat, 27 Aug 2016 12:12:02 +0200, Ingo Schwarze wrote:

> However, in the case at hand, it really helps readability
> in a function (unavoidably) already longer than comfortable
> for reading it.

Now that we have a handy size_t scratch variable, we can use it to
store the return value of mbrtowc() instead of storing it in an
int.  Worth it or overkill?

 - todd

Index: lib/libc/stdio/vfprintf.c
===
RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v
retrieving revision 1.76
diff -u -p -u -r1.76 vfprintf.c
--- lib/libc/stdio/vfprintf.c   27 Aug 2016 16:10:40 -  1.76
+++ lib/libc/stdio/vfprintf.c   27 Aug 2016 16:26:04 -
@@ -489,17 +489,17 @@ __vfprintf(FILE *fp, const char *fmt0, _
size_t len;
 
cp = fmt;
-   while ((n = mbrtowc(, fmt, MB_CUR_MAX, )) > 0) {
-   fmt += n;
+   while ((len = mbrtowc(, fmt, MB_CUR_MAX, )) != 0) {
+   if (len == (size_t)-1 || len == (size_t)-2) {
+   ret = -1;
+   goto error;
+   }
+   fmt += len;
if (wc == '%') {
fmt--;
break;
}
}
-   if (n < 0) {
-   ret = -1;
-   goto error;
-   }
if (fmt != cp) {
ptrdiff_t m = fmt - cp;
if (m < 0 || m > INT_MAX - ret)
@@ -507,7 +507,7 @@ __vfprintf(FILE *fp, const char *fmt0, _
PRINT(cp, m);
ret += m;
}
-   if (n == 0)
+   if (len == 0)
goto done;
fmt++;  /* skip over '%' */
 
@@ -1217,17 +1217,19 @@ __find_arguments(const char *fmt0, va_li
 * Scan the format for conversions (`%' character).
 */
for (;;) {
+   size_t len;
+
cp = fmt;
-   while ((n = mbrtowc(, fmt, MB_CUR_MAX, )) > 0) {
-   fmt += n;
+   while ((len = mbrtowc(, fmt, MB_CUR_MAX, )) != 0) {
+   if (len == (size_t)-1 || len == (size_t)-2)
+   return (-1);
+   fmt += len;
if (wc == '%') {
fmt--;
break;
}
}
-   if (n < 0)
-   return (-1);
-   if (n == 0)
+   if (len == 0)
goto done;
fmt++;  /* skip over '%' */
 

Re: use strnlen() in vfprintf.c

[Theo de Raadt]

> in 2014, Theo scolded me when i tried to use strnlen(3) at some
> place in mandoc where it wasn't really important, pointing out that
> some systems still didn't have it, and saying: "Let me say simply:
> Yuck."  And indeed, i promptly got reports about compile failures
> on Solaris.

Right.

> However, in the case at hand, it really helps readability
> in a function (unavoidably) already longer than comfortable
> for reading it.

And it is internal use.

Re: Amend history & authors info in bin/expr/expr.1

[Ingo Schwarze]

Hi Sevan,

Sevan Janiyan Solaris wrote on Wed, Aug 24, 2016 at 01:35:38AM +0100:

> Index: bin/expr/expr.1
> ===
> RCS file: /cvs/src/bin/expr/expr.1,v
> retrieving revision 1.23
> diff -u -p -u -r1.23 expr.1
> --- bin/expr/expr.1   16 Jan 2015 15:30:10 -  1.23
> +++ bin/expr/expr.1   24 Aug 2016 00:29:29 -
> @@ -142,15 +142,15 @@ The
>  utility first appeared in the Programmer's Workbench (PWB/UNIX)
>  and has supported regular expressions since
>  .At v7 .
> -It was rewritten from scratch for
> +A public domain version was rewritten from scratch for
>  .Bx 386 0.1

We don't usually explain the history of licensing unless it is
exceptionally important or unusual.  It goes without saying that
something that appeared in PWB was usually proprietary, while stuff
that made it into 4.4BSD-Lite2 and/or NetBSD was almost certainly
free software.  The distinction of BSD vs. PD doesn't matter enough
to encumber HISTORY with it.

> -and again for
> -.Nx 1.1 .
> +and largely again for
> +.Nx 1.0 .

While both are true, i don't think it is important enough to mention
the earlier one of these two rewrites in OpenBSD given that it lived
less than a year before being superseded again.

>  .Sh AUTHORS
>  .An -nosplit
> -The first free version was written by
> +The public domain version was written by
>  .An Pace Willisson
>  in 1992.

Again, not important enough to change it.

> -This version was written by
> +It was largely rewritten by
>  .An John T. Conklin
> -in 1994.
> +in 1993.

That's outright misleading.  OpenBSD uses Conklin's NetBSD 1.1
version (written in C in 1994).  NetBSD uses jdolecek@'s NetBSD 1.6
version (written in yacc(1) in 2000).  Neither uses Conklin's NetBSD
1.0 version (written in yacc(1) in 1993).

  http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/expr/Attic/expr.c

Yours,
  Ingo

replace struct vattr with struct stat in fusebuf

[Martin Natano]

In struct fusebuf the attributes (used for getattr/setattr and to return
the ino/mode of a newly created file) are stored in a struct vattr. The
problem with this is, that using struct vattr in userspace is suboptimal
as some related helpers are not available, e.g. VATTR_NULL() and IFTOVT().

What happens on getattr is this: fusefs requests the attributes for a
file from the userland process. libfuse calls the getattr fuse
operation, which fills in a struct stat. This struct is than converted
to a partial struct vattr, which is passed back to the kernel where
"fixup" takes place.

Following diff simplifies that process by replacing the struct vattr in
fusebuf with a struct stat. The conversion is moved to the kernel where
it belongs. As a side effect the  include can be removed
from libfuse.

Ok? Objections?

natano


Index: lib/libfuse/fuse_ops.c
===
RCS file: /cvs/src/lib/libfuse/fuse_ops.c,v
retrieving revision 1.24
diff -u -p -r1.24 fuse_ops.c
--- lib/libfuse/fuse_ops.c  5 Feb 2014 20:13:58 -   1.24
+++ lib/libfuse/fuse_ops.c  22 Aug 2016 20:53:46 -
@@ -30,53 +30,30 @@
return (0); \
}
 
-static void
-stat2attr(struct vattr *v, struct stat *st)
-{
-   v->va_fileid = st->st_ino;
-   v->va_bytes = st->st_blocks;
-   v->va_mode = st->st_mode;
-   v->va_nlink = st->st_nlink;
-   v->va_uid = st->st_uid;
-   v->va_gid = st->st_gid;
-   v->va_rdev = st->st_rdev;
-   v->va_size = st->st_size;
-   v->va_blocksize = st->st_blksize;
-   v->va_atime.tv_sec = st->st_atime;
-   v->va_atime.tv_nsec = st->st_atimensec;
-   v->va_mtime.tv_sec = st->st_mtime;
-   v->va_mtime.tv_nsec = st->st_mtimensec;
-   v->va_ctime.tv_sec = st->st_ctime;
-   v->va_ctime.tv_nsec = st->st_ctimensec;
-}
-
 static int
-update_vattr(struct fuse *f, struct vattr *attr, const char *realname,
+update_attr(struct fuse *f, struct stat *attr, const char *realname,
 struct fuse_vnode *vn)
 {
-   struct stat st;
int ret;
 
-   bzero(, sizeof(st));
-   ret = f->op.getattr(realname, );
+   memset(attr, 0, sizeof(struct stat));
+   ret = f->op.getattr(realname, attr);
 
-   if (st.st_blksize == 0)
-   st.st_blksize = 512;
-   if (st.st_blocks == 0)
-   st.st_blocks = 4;
+   if (attr->st_blksize == 0)
+   attr->st_blksize = 512;
+   if (attr->st_blocks == 0)
+   attr->st_blocks = 4;
 
-   st.st_ino = vn->ino;
+   attr->st_ino = vn->ino;
 
if (f->conf.set_mode)
-   st.st_mode = (st.st_mode & S_IFMT) | (0777 & ~f->conf.umask);
+   attr->st_mode = (attr->st_mode & S_IFMT) | (0777 & 
~f->conf.umask);
 
if (f->conf.set_uid)
-   st.st_uid = f->conf.uid;
+   attr->st_uid = f->conf.uid;
 
if (f->conf.set_gid)
-   st.st_gid = f->conf.gid;
-
-   stat2attr(attr, );
+   attr->st_gid = f->conf.gid;
 
return (ret);
 }
@@ -107,7 +84,7 @@ ifuse_ops_getattr(struct fuse *f, struct
DPRINTF("Opcode:\tgetattr\n");
DPRINTF("Inode:\t%llu\n", (unsigned long long)fbuf->fb_ino);
 
-   bzero(>fb_vattr, sizeof(fbuf->fb_vattr));
+   memset(>fb_attr, 0, sizeof(struct stat));
 
vn = tree_get(>vnode_tree, fbuf->fb_ino);
if (vn == NULL) {
@@ -121,7 +98,7 @@ ifuse_ops_getattr(struct fuse *f, struct
return (0);
}
 
-   fbuf->fb_err = update_vattr(f, >fb_vattr, realname, vn);
+   fbuf->fb_err = update_attr(f, >fb_attr, realname, vn);
free(realname);
 
return (0);
@@ -474,7 +451,7 @@ ifuse_ops_lookup(struct fuse *f, struct 
return (0);
}
 
-   fbuf->fb_err = update_vattr(f, >fb_vattr, realname, vn);
+   fbuf->fb_err = update_attr(f, >fb_attr, realname, vn);
free(fbuf->fb_dat);
free(realname);
 
@@ -614,9 +591,9 @@ ifuse_ops_create(struct fuse *f, struct 
fbuf->fb_err = -ENOSYS;
 
if (!fbuf->fb_err) {
-   fbuf->fb_err = update_vattr(f, >fb_vattr, realname, vn);
-   fbuf->fb_ino = fbuf->fb_vattr.va_fileid;
-   fbuf->fb_io_mode = fbuf->fb_vattr.va_mode;
+   fbuf->fb_err = update_attr(f, >fb_attr, realname, vn);
+   fbuf->fb_ino = fbuf->fb_attr.st_ino;
+   fbuf->fb_io_mode = fbuf->fb_attr.st_mode;
}
free(realname);
 
@@ -650,8 +627,8 @@ ifuse_ops_mkdir(struct fuse *f, struct f
fbuf->fb_err = f->op.mkdir(realname, mode);
 
if (!fbuf->fb_err) {
-   fbuf->fb_err = update_vattr(f, >fb_vattr, realname, vn);
-   fbuf->fb_io_mode = fbuf->fb_vattr.va_mode;
+   fbuf->fb_err = update_attr(f, >fb_attr, realname, vn);
+   fbuf->fb_io_mode = 

Re: Estonian keymap

[Mart Tõnso]

Would this be ok for inclusion in the next release?

On Sat, Aug 27, 2016 at 7:27 AM, Mart Tõnso  wrote:
> Updated Estonian keymap patch for current. Original from 2005 at
> http://marc.info/?l=openbsd-tech=112873075504474
>
>
> Index: sys/dev/pckbc/wskbdmap_mfii.c
> ===
> RCS file: /cvs/src/sys/dev/pckbc/wskbdmap_mfii.c,v
> retrieving revision 1.43
> diff -u -p -u -r1.43 wskbdmap_mfii.c
> --- sys/dev/pckbc/wskbdmap_mfii.c 14 Apr 2013 19:32:52 - 1.43
> +++ sys/dev/pckbc/wskbdmap_mfii.c 26 Aug 2016 19:32:22 -
> @@ -1071,6 +1071,40 @@ static const keysym_t pckbd_keydesc_is_n
>  KC(40),  KS_acute, KS_diaeresis, KS_asciicircum,
>  };
>
> +static const keysym_t pckbd_keydesc_ee[] = {
> +/*  pos  normal shifted altgr shift-altgr */
> +KC(3),   KS_2, KS_quotedbl, KS_at,
> +KC(4),   KS_3, KS_numbersign, KS_sterling,
> +KC(5),   KS_4, KS_currency, KS_dollar,
> +KC(7),   KS_6, KS_ampersand,
> +KC(8),   KS_7, KS_slash, KS_braceleft,
> +KC(9),   KS_8, KS_parenleft, KS_bracketleft,
> +KC(10),  KS_9, KS_parenright, KS_bracketright,
> +KC(11),  KS_0, KS_equal, KS_braceright,
> +KC(12),  KS_plus, KS_question, KS_backslash,
> +KC(13),  KS_dead_acute, KS_dead_grave,
> +KC(26),  KS_udiaeresis,
> +KC(27),  KS_otilde, KS_Otilde, KS_section,
> +KC(31),  KS_s, KS_S, KS_L2_scaron, KS_L2_Scaron,
> +KC(39),  KS_odiaeresis,
> +KC(40),  KS_adiaeresis, KS_Adiaeresis, KS_dead_circumflex,
> +KC(41),  KS_dead_caron, KS_dead_tilde,
> +KC(43),  KS_apostrophe, KS_asterisk, KS_onehalf,
> +KC(44),  KS_z, KS_Z, KS_L2_zcaron, KS_L2_Zcaron,
> +KC(51),  KS_comma, KS_semicolon,
> +KC(52),  KS_period, KS_colon,
> +KC(53),  KS_minus, KS_underscore,
> +KC(86),  KS_less, KS_greater, KS_bar, KS_brokenbar,
> +KC(184), KS_Mode_switch, KS_Multi_key,
> +};
> +
> +static const keysym_t pckbd_keydesc_ee_nodead[] = {
> +/*  pos  normal shifted altgr shift-altgr */
> +KC(13),  KS_apostrophe, KS_grave,
> +KC(40),  KS_adiaeresis, KS_Adiaeresis, KS_asciicircum,
> +KC(41),  KS_L2_caron, KS_asciitilde,
> +};
> +
>  #endif /* WSKBD_NO_INTL_LAYOUTS */
>
>  #define KBD_MAP(name, base, map) \
> @@ -1130,6 +1164,8 @@ const struct wscons_keydesc pckbd_keydes
>   KBD_MAP(KB_NL | KB_NODEAD, KB_NL, pckbd_keydesc_nl_nodead),
>   KBD_MAP(KB_IS, KB_US, pckbd_keydesc_is),
>   KBD_MAP(KB_IS | KB_NODEAD, KB_IS, pckbd_keydesc_is_nodead),
> + KBD_MAP(KB_EE, KB_US, pckbd_keydesc_ee),
> + KBD_MAP(KB_EE | KB_NODEAD, KB_EE, pckbd_keydesc_ee_nodead),
>  #endif /* WSKBD_NO_INTL_LAYOUTS */
>   {0, 0, 0, 0}
>  };
> Index: sys/dev/wscons/wskbdutil.c
> ===
> RCS file: /cvs/src/sys/dev/wscons/wskbdutil.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 wskbdutil.c
> --- sys/dev/wscons/wskbdutil.c 9 Dec 2014 07:05:06 - 1.14
> +++ sys/dev/wscons/wskbdutil.c 26 Aug 2016 19:32:22 -
> @@ -170,7 +170,12 @@ static struct compose_tab_s {
>   { { KS_acute, KS_u }, KS_uacute },
>   { { KS_asciicircum, KS_u }, KS_ucircumflex },
>   { { KS_grave, KS_u }, KS_ugrave },
> - { { KS_acute, KS_y }, KS_yacute }
> + { { KS_acute, KS_y }, KS_yacute },
> + { { KS_dead_caron, KS_space }, KS_L2_caron },
> + { { KS_dead_caron, KS_S }, KS_L2_Scaron },
> + { { KS_dead_caron, KS_Z }, KS_L2_Zcaron },
> + { { KS_dead_caron, KS_s }, KS_L2_scaron },
> + { { KS_dead_caron, KS_z }, KS_L2_zcaron }
>  };
>
>  #define COMPOSE_SIZE nitems(compose_tab)
> Index: sys/dev/wscons/wsksymdef.h
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsksymdef.h,v
> retrieving revision 1.36
> diff -u -p -u -r1.36 wsksymdef.h
> --- sys/dev/wscons/wsksymdef.h 26 Jan 2014 17:48:08 - 1.36
> +++ sys/dev/wscons/wsksymdef.h 26 Aug 2016 19:32:22 -
> @@ -266,6 +266,7 @@
>  #define KS_dead_diaeresis 0x0308
>  #define KS_dead_abovering 0x030a
>  #define KS_dead_cedilla 0x0327
> +#define KS_dead_caron 0x0328
>
>  /*
>   * Group Cyrillic
> @@ -734,6 +735,7 @@
>  #define KB_CF 0x1a00
>  #define KB_LV 0x1b00
>  #define KB_IS 0x1c00
> +#define KB_EE 0x1d00
>
>  #define KB_NODEAD 0x0001 /* disable dead accents */
>  #define KB_DECLK 0x0002 /* DEC LKnnn layout */
> @@ -774,7 +776,8 @@
>   { KB_SI, "si" }, \
>   { KB_CF, "cf" }, \
>   { KB_LV, "lv" }, \
> - { KB_IS, "is" }
> + { KB_IS, "is" }, \
> + { KB_EE, "ee" }
>
>  #define KB_VARTAB \
>   { KB_NODEAD, "nodead" }, \

Re: use strnlen() in vfprintf.c

[Ingo Schwarze]

Hi Todd,

in 2014, Theo scolded me when i tried to use strnlen(3) at some
place in mandoc where it wasn't really important, pointing out that
some systems still didn't have it, and saying: "Let me say simply:
Yuck."  And indeed, i promptly got reports about compile failures
on Solaris.

However, in the case at hand, it really helps readability
in a function (unavoidably) already longer than comfortable
for reading it.

So, OK schwarze@
  Ingo


Todd C. Miller wrote on Thu, Aug 25, 2016 at 03:43:31PM -0600:

> Index: lib/libc/stdio/vfprintf.c
> ===
> RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v
> retrieving revision 1.75
> diff -u -p -u -r1.75 vfprintf.c
> --- lib/libc/stdio/vfprintf.c 17 Aug 2016 22:15:08 -  1.75
> +++ lib/libc/stdio/vfprintf.c 25 Aug 2016 21:39:16 -
> @@ -486,6 +486,8 @@ __vfprintf(FILE *fp, const char *fmt0, _
>* Scan the format for conversions (`%' character).
>*/
>   for (;;) {
> + size_t len;
> +
>   cp = fmt;
>   while ((n = mbrtowc(, fmt, MB_CUR_MAX, )) > 0) {
>   fmt += n;
> @@ -886,22 +888,10 @@ fp_common:
>  
>   cp = "(null)";
>   }
> - if (prec >= 0) {
> - /*
> -  * can't use strlen; can only look for the
> -  * NUL in the first `prec' characters, and
> -  * strlen() will go further.
> -  */
> - char *p = memchr(cp, 0, prec);
> -
> - size = p ? (p - cp) : prec;
> - } else {
> - size_t len;
> -
> - if ((len = strlen(cp)) > INT_MAX)
> - goto overflow;
> - size = (int)len;
> - }
> + len = prec >= 0 ? strnlen(cp, prec) : strlen(cp);
> + if (len > INT_MAX)
> + goto overflow;
> + size = (int)len;
>   sign = '\0';
>   break;
>   case 'U':
> 

Re: Add NVIDIA GTX 960M to pcidevs please

[Guillermo Bernaldo de Quiros Maraver]

Ok, thank you so much Raf,

I'll take note for the next devices.

Cheers,
Guille

2016-08-27 10:28 GMT+02:00 Raf Czlonka :

> On Sat, Aug 27, 2016 at 08:53:57AM BST, Guillermo Bernaldo de Quiros
> Maraver wrote:
> > Hi, good morning,
> >
> > Please, could anyone add this patch?
> >
> > Thanks anyway
> >
> > Index: pcidevs
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> > retrieving revision 1.1802
> > diff -u -p -r1.1802 pcidevs
> > --- pcidevs 31 Jul 2016 07:36:16 - 1.1802
> > +++ pcidevs 27 Aug 2016 07:23:17 -
> > @@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor
> >  product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti
> >  product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750
> >  product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745
> > +product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M
> >
> >  /* Oak Technologies products */
> >  product OAKTECH OTI1007 0x0107 OTI107
> > Index: pcidevs.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> > retrieving revision 1.1796
> > diff -u -p -r1.1796 pcidevs.h
> > --- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796
> > +++ pcidevs.h 27 Aug 2016 07:23:22 -
> > @@ -6135,6 +6135,7 @@
> >  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750
> Ti */
> >  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */
> >  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */
> > +#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */
>   ^
> Hi Guillermo,
>
> pcidevs.h and pcidevs_data.h files are automatically generated and
> (not that it matters now), by convention, lower case is used in hex
> values.
>
> Cheers,
>
> Raf
>
> >  /* Oak Technologies products */
> >  #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */
> > Index: pcidevs_data.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> > retrieving revision 1.1791
> > diff -u -p -r1.1791 pcidevs_data.h
> > --- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791
> > +++ pcidevs_data.h 27 Aug 2016 07:23:27 -
> > @@ -21504,6 +21504,10 @@ static const struct pci_known_product pc
> >  "GeForce GTX 745",
> >   },
> >   {
> > +PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M,
> > +"GeForce GTX 960M",
> > + },
> > + {
> >  PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007,
> >  "OTI107",
> >   },
>

Re: Add NVIDIA GTX 960M to pcidevs please

[Raf Czlonka]

On Sat, Aug 27, 2016 at 08:53:57AM BST, Guillermo Bernaldo de Quiros Maraver 
wrote:
> Hi, good morning,
> 
> Please, could anyone add this patch?
> 
> Thanks anyway
> 
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1802
> diff -u -p -r1.1802 pcidevs
> --- pcidevs 31 Jul 2016 07:36:16 - 1.1802
> +++ pcidevs 27 Aug 2016 07:23:17 -
> @@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor
>  product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti
>  product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750
>  product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745
> +product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M
> 
>  /* Oak Technologies products */
>  product OAKTECH OTI1007 0x0107 OTI107
> Index: pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1796
> diff -u -p -r1.1796 pcidevs.h
> --- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796
> +++ pcidevs.h 27 Aug 2016 07:23:22 -
> @@ -6135,6 +6135,7 @@
>  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750 Ti */
>  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */
>  #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */
> +#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */
  ^
Hi Guillermo,

pcidevs.h and pcidevs_data.h files are automatically generated and
(not that it matters now), by convention, lower case is used in hex
values.

Cheers,

Raf

>  /* Oak Technologies products */
>  #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */
> Index: pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1791
> diff -u -p -r1.1791 pcidevs_data.h
> --- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791
> +++ pcidevs_data.h 27 Aug 2016 07:23:27 -
> @@ -21504,6 +21504,10 @@ static const struct pci_known_product pc
>  "GeForce GTX 745",
>   },
>   {
> +PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M,
> +"GeForce GTX 960M",
> + },
> + {
>  PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007,
>  "OTI107",
>   },

Add NVIDIA GTX 960M to pcidevs please

[Guillermo Bernaldo de Quiros Maraver]

Hi, good morning,

Please, could anyone add this patch?

Thanks anyway

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1802
diff -u -p -r1.1802 pcidevs
--- pcidevs 31 Jul 2016 07:36:16 - 1.1802
+++ pcidevs 27 Aug 2016 07:23:17 -
@@ -6130,6 +6130,7 @@ product NVIDIA GEFORCE940MX 0x134d GeFor
 product NVIDIA GEFORCEGTX750TI 0x1380 GeForce GTX 750 Ti
 product NVIDIA GEFORCEGTX750 0x1381 GeForce GTX 750
 product NVIDIA GEFORCEGTX745 0x1382 GeForce GTX 745
+product NVIDIA GEFORCEGTX960M 0x139b GeForce GTX 960M

 /* Oak Technologies products */
 product OAKTECH OTI1007 0x0107 OTI107
Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1796
diff -u -p -r1.1796 pcidevs.h
--- pcidevs.h 31 Jul 2016 07:37:04 - 1.1796
+++ pcidevs.h 27 Aug 2016 07:23:22 -
@@ -6135,6 +6135,7 @@
 #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750TI 0x1380 /* GeForce GTX 750 Ti */
 #define PCI_PRODUCT_NVIDIA_GEFORCEGTX750 0x1381 /* GeForce GTX 750 */
 #define PCI_PRODUCT_NVIDIA_GEFORCEGTX745 0x1382 /* GeForce GTX 745 */
+#define PCI_PRODUCT_NVIDIA_GEFORCEGTX960M 0x139B /* GeForce GTX 960M */

 /* Oak Technologies products */
 #define PCI_PRODUCT_OAKTECH_OTI1007 0x0107 /* OTI107 */
Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1791
diff -u -p -r1.1791 pcidevs_data.h
--- pcidevs_data.h 31 Jul 2016 07:37:04 - 1.1791
+++ pcidevs_data.h 27 Aug 2016 07:23:27 -
@@ -21504,6 +21504,10 @@ static const struct pci_known_product pc
 "GeForce GTX 745",
  },
  {
+PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_GEFORCEGTX960M,
+"GeForce GTX 960M",
+ },
+ {
 PCI_VENDOR_OAKTECH, PCI_PRODUCT_OAKTECH_OTI1007,
 "OTI107",
  },