NetBSD Problem Report #50166

From www@NetBSD.org  Mon Aug 24 17:50:13 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C3D4DA65D1
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 24 Aug 2015 17:50:12 +0000 (UTC)
Message-Id: <20150824175009.D8C88A65E2@mollari.NetBSD.org>
Date: Mon, 24 Aug 2015 17:50:09 +0000 (UTC)
From: rmh@gnu.org
Reply-To: rmh@gnu.org
To: gnats-bugs@NetBSD.org
Subject: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
X-Send-Pr-Version: www-1.0

>Number:         50166
>Category:       misc
>Synopsis:       [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pooka
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 24 17:55:00 +0000 2015
>Closed-Date:    Thu Sep 24 00:40:42 +0000 2015
>Last-Modified:  Thu Sep 24 00:50:00 +0000 2015
>Originator:     Robert Millan
>Release:        HEAD
>Organization:
>Environment:
>Description:
GNU/Hurd doesn't have PATH_MAX or MAXHOSTNAMELEN (arbitrarily long strings can be used). Since attempting to replace every instance of static allocation with dynamic buffer management would make for a very intrusive patch, I'm proposing to just define the limits as alternative.

I took care to use the same limits Rump namespace has, just to avoid accidental cross-definition of a different value causing damage somewhere (e.g. overflows or such).
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/50166: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd
 support in Rump)
Date: Mon, 24 Aug 2015 20:11:37 +0200

 This is a multi-part message in MIME format.
 --------------000702000804050103070600
 Content-Type: text/plain; charset=windows-1252; format=flowed
 Content-Transfer-Encoding: 7bit

 El 24/08/15 a les 19:55, gnats-admin@netbsd.org ha escrit:
 > Thank you very much for your problem report.
 > It has the internal identification `misc/50166'.
 > The individual assigned to look at your
 > report is: misc-bug-people.
 >
 >> Category:       misc
 >> Responsible:    misc-bug-people
 >> Synopsis:       [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd support in Rump)
 >> Arrival-Date:   Mon Aug 24 17:55:00 +0000 2015

 Thanks. Here's the patch.

 -- 
 Robert Millan

 --------------000702000804050103070600
 Content-Type: text/x-patch;
  name="hurd_3_limits.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="hurd_3_limits.diff"

 --- a/src/tools/compat/Makefile
 +++ b/src/tools/compat/Makefile
 @@ -38,6 +38,11 @@
  CPPFLAGS+=	-I. -I./include -I${.CURDIR} -I${.CURDIR}/sys \
  		-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64

 +# Define MAXPATHLEN limit on GNU/Hurd
 +.if ${BUILD_OSTYPE} == "GNU"
 +CPPFLAGS+=	-DMAXPATHLEN=1024 -DPATH_MAX=1024
 +.endif
 +
  .PATH:		${.CURDIR}/../../lib/libc/cdb \
  		${.CURDIR}/../../lib/libc/gen \
  		${.CURDIR}/../../lib/libc/hash \
 --- a/src/tools/compat/defs.mk.in
 +++ b/src/tools/compat/defs.mk.in
 @@ -79,6 +79,11 @@
  HOST_CPPFLAGS+=	${COMPATINCFLAGS} -I${NETBSDSRCDIR}/tools/compat \
  		-DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64

 +# Define MAXPATHLEN limit on GNU/Hurd
 +.if ${BUILD_OSTYPE} == "GNU"
 +HOST_CPPFLAGS+= -DMAXPATHLEN=1024 -DPATH_MAX=1024
 +.endif
 +
  .if "${COMPATLIB_NO_LIB}" != "yes"
  DPADD+=		${COMPATLIBDIR}/libnbcompat.a
  LDADD+=		-L${COMPATLIBDIR} -lnbcompat @LIBS@
 --- a/src/tools/make/configure
 +++ b/src/tools/make/configure
 @@ -971,6 +971,10 @@
  #define DEFSHELL_CUSTOM "${BSHELL}"
  EOF

 +cat >>confdefs.h <<EOF
 +#define MAXPATHLEN 1024
 +EOF
 +
  # Make sure we have POSIX regex ability.
  ac_ext=c
  ac_cpp='$CPP $CPPFLAGS'
 --- a/src/tools/make/configure.ac
 +++ b/src/tools/make/configure.ac
 @@ -24,6 +24,7 @@

  AC_INIT([make], [noversion], [bin-bug-people@NetBSD.org])
  AC_CONFIG_FILES(buildmake.sh)
 +AC_CANONICAL_HOST()

  AC_PATH_PROG(BSHELL, sh)
  if test x"$BSHELL" = x; then
 @@ -31,6 +32,13 @@
  fi
  AC_DEFINE_UNQUOTED(DEFSHELL_CUSTOM, "${BSHELL}")

 +case $host_os in
 +	gnu*)
 +		# Define MAXPATHLEN limit on GNU/Hurd
 +		AC_DEFINE_UNQUOTED(MAXPATHLEN, 1024)
 +	;;
 +esac
 +
  # Make sure we have POSIX regex ability.
  AC_CHECK_HEADER(regex.h,, AC_MSG_ERROR([POSIX regex.h is required]))


 --------------000702000804050103070600--

From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org, 
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, rmh@gnu.org
Cc: 
Subject: Re: misc/50166: [PATCH] MAXPATHLEN / PATH_MAX definitions (for GNU/Hurd
 support in Rump)
Date: Mon, 24 Aug 2015 23:05:07 +0200

 El 24/08/15 a les 21:20, Robert Millan ha escrit:
 >   --- a/src/tools/make/configure
 >   +++ b/src/tools/make/configure
 >   @@ -971,6 +971,10 @@
 >    #define DEFSHELL_CUSTOM "${BSHELL}"
 >    EOF
 >
 >   +cat >>confdefs.h <<EOF
 >   +#define MAXPATHLEN 1024
 >   +EOF
 >   +
 >    # Make sure we have POSIX regex ability.
 >    ac_ext=c
 >    ac_cpp='$CPP $CPPFLAGS'

 As I assume you re-generate configure from configure.ac, this part was ment
 to be editted out before submitting. Sorry for the oversight ;-)

 -- 
 Robert Millan

From: Antti Kantee <pooka@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/50166
Date: Wed, 26 Aug 2015 12:02:00 +0000

 Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because 
 a reference to install-sh is generated (and install-sh is not present).

From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: misc/50166
Date: Fri, 28 Aug 2015 19:00:28 +0200

 El 26/08/15 a les 14:05, Antti Kantee ha escrit:
 > The following reply was made to PR misc/50166; it has been noted by GNATS.
 >
 > From: Antti Kantee <pooka@iki.fi>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: misc/50166
 > Date: Wed, 26 Aug 2015 12:02:00 +0000
 >
 >   Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because
 >   a reference to install-sh is generated (and install-sh is not present).
 >
  > ....
  > So, I tried it, and indeed there was fallout from AC_CANONICAL_HOST() (as noted in the PR).  Can you try to work around it somehow? src/tools/make/configure.ac contains the official way to regenerate configure.

 If you want to keep it simple, I could switch it to use uname instead of AC_CANONICAL_HOST(). It
 will break cross-compiling but AFAICS the whole purpose of this script is to bootstrap make on
 non-NetBSD systems, which is a very native-build oriented end, and I doubt cross-compiling was
 ever intended to work here anyways.

 Does that sound good?

 -- 
 Robert Millan

From: Antti Kantee <pooka@iki.fi>
To: Robert Millan <rmh@gnu.org>, gnats-bugs@NetBSD.org,
 misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: misc/50166
Date: Sun, 30 Aug 2015 23:14:38 +0000

 On 28/08/15 17:00, Robert Millan wrote:
 > El 26/08/15 a les 14:05, Antti Kantee ha escrit:
 >> The following reply was made to PR misc/50166; it has been noted by
 >> GNATS.
 >>
 >> From: Antti Kantee <pooka@iki.fi>
 >> To: gnats-bugs@NetBSD.org
 >> Cc:
 >> Subject: Re: misc/50166
 >> Date: Wed, 26 Aug 2015 12:02:00 +0000
 >>
 >>   Adding AC_CANONICAL_HOST() to configure.ac makes configure fail because
 >>   a reference to install-sh is generated (and install-sh is not present).
 >>
 >  > ....
 >  > So, I tried it, and indeed there was fallout from AC_CANONICAL_HOST()
 > (as noted in the PR).  Can you try to work around it somehow?
 > src/tools/make/configure.ac contains the official way to regenerate
 > configure.
 >
 > If you want to keep it simple, I could switch it to use uname instead of
 > AC_CANONICAL_HOST(). It
 > will break cross-compiling but AFAICS the whole purpose of this script
 > is to bootstrap make on
 > non-NetBSD systems, which is a very native-build oriented end, and I
 > doubt cross-compiling was
 > ever intended to work here anyways.
 >
 > Does that sound good?

 I assume you mean cross-compiling in the Canadian sense, i.e. building 
 the tools for another system.  I don't know if that works or is intended 
 to work.  You can ask tech-toolchain@netbsd.org and observe the outcry 
 or lack thereof.

 Testing for availability of MAXPATHLEN would be better, though.  I guess 
 you can just look at some tool using MAXPATHLEN and determine what you 
 need to include so that you can test if it's available or not.

From: Robert Millan <rmh@gnu.org>
To: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, rmh@gnu.org
Cc: 
Subject: Re: misc/50166
Date: Fri, 11 Sep 2015 01:04:08 +0200

 This is a multi-part message in MIME format.
 --------------010702000706090604010000
 Content-Type: text/plain; charset=windows-1252; format=flowed
 Content-Transfer-Encoding: 7bit

 El 31/08/15 a les 01:15, Antti Kantee ha escrit:
 >   > If you want to keep it simple, I could switch it to use uname instead of
 >   > AC_CANONICAL_HOST(). It
 >   > will break cross-compiling but AFAICS the whole purpose of this script
 >   > is to bootstrap make on
 >   > non-NetBSD systems, which is a very native-build oriented end, and I
 >   > doubt cross-compiling was
 >   > ever intended to work here anyways.
 >   >
 >   > Does that sound good?
 >
 >   I assume you mean cross-compiling in the Canadian sense, i.e. building
 >   the tools for another system.  I don't know if that works or is intended
 >   to work.  You can ask tech-toolchain@netbsd.org and observe the outcry
 >   or lack thereof.
 >
 >   Testing for availability of MAXPATHLEN would be better, though.  I guess
 >   you can just look at some tool using MAXPATHLEN and determine what you
 >   need to include so that you can test if it's available or not.

 Hi,

 I just realized there's a much simpler way around this, if we want to test for
 MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
 directly in C pre-processor.

 See attached patch, please let me know what you think.

 -- 
 Robert Millan

 --------------010702000706090604010000
 Content-Type: text/x-patch;
  name="maxpathlen.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="maxpathlen.diff"

 Index: rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h
 ===================================================================
 --- rumpkernel-0~20150715.orig/buildrump.sh/src/usr.bin/make/make.h	2015-07-23 22:54:05.000000000 +0200
 +++ rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h	2015-09-05 12:31:02.556270631 +0200
 @@ -503,4 +503,11 @@
  #define MAX(a, b) ((a > b) ? a : b)
  #endif

 +/* GNU/Hurd systems lack MAXPATHLEN */
 +#include <limits.h>
 +#ifndef MAXPATHLEN
 +#warning "MAXPATHLEN undefined on this system, forcing an arbitrary limit"
 +#define MAXPATHLEN	4096
 +#endif
 +
  #endif /* _MAKE_H_ */

 --------------010702000706090604010000--

Responsible-Changed-From-To: misc-bug-people->pooka
Responsible-Changed-By: pooka@NetBSD.org
Responsible-Changed-When: Fri, 18 Sep 2015 12:40:13 +0000
Responsible-Changed-Why:
make me responsible so that I get email notifications about replies


State-Changed-From-To: open->analyzed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Fri, 18 Sep 2015 12:40:13 +0000
State-Changed-Why:
problem known


From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 12:57:35 +0000

 On Fri, Sep 11, 2015 at 01:04:08AM +0200, Robert Millan wrote:
 > I just realized there's a much simpler way around this, if we want to test for
 > MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
 > directly in C pre-processor.
 > 
 > See attached patch, please let me know what you think.

 Even if make is the only thing in tools currently using MAXPATHLEN,
 could we put the compat value into tools/compat/compat_defs.h
 instead?

 Apart from that, the approach seems ok.

 > Index: rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h
 > ===================================================================
 > --- rumpkernel-0~20150715.orig/buildrump.sh/src/usr.bin/make/make.h	2015-07-23 22:54:05.000000000 +0200
 > +++ rumpkernel-0~20150715/buildrump.sh/src/usr.bin/make/make.h	2015-09-05 12:31:02.556270631 +0200
 > @@ -503,4 +503,11 @@
 >  #define MAX(a, b) ((a > b) ? a : b)
 >  #endif
 >  
 > +/* GNU/Hurd systems lack MAXPATHLEN */
 > +#include <limits.h>
 > +#ifndef MAXPATHLEN
 > +#warning "MAXPATHLEN undefined on this system, forcing an arbitrary limit"
 > +#define MAXPATHLEN	4096
 > +#endif
 > +
 >  #endif /* _MAKE_H_ */

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 14:22:54 +0000

 On Fri, Sep 18, 2015 at 01:00:01PM +0000, Antti Kantee wrote:
  >  > See attached patch, please let me know what you think.
  >  
  >  Even if make is the only thing in tools currently using MAXPATHLEN,
  >  could we put the compat value into tools/compat/compat_defs.h
  >  instead?
  >  
  >  Apart from that, the approach seems ok.

 Well, it should be changed to PATH_MAX, which is posix.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Antti Kantee <pooka@NetBSD.org>
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
 rmh@gnu.org
Cc: 
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 14:42:26 +0000

 On 18/09/15 14:25, David Holland wrote:
 >   Well, it should be changed to PATH_MAX, which is posix.

 Yes, standardized, but I read the standard so that PATH_MAX is not 
 required to be defined by limits.h:

 "The values in the following list may be constants within an 
 implementation or may vary from one pathname to another. For example, 
 file systems or directories may have different characteristics.

 A definition of one of the values shall be omitted from the <limits.h> 
 header on specific implementations where the corresponding value is 
 equal to or greater than the stated minimum, but where the value can 
 vary depending on the file to which it is applied.  The actual value 
 supported for a specific pathname shall be provided by the pathconf() 
 function."

 Notably, not just may be omitted, but shall be omitted.

 Anyway, if Hurd does define PATH_MAX, we can use it, but if not, 
 changing the identifier doesn't solve anything no matter what the 
 standard says.

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>, gnats-bugs@NetBSD.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 21:23:33 +0200

 El 18/09/15 a les 16:42, Antti Kantee ha escrit:
 > Anyway, if Hurd does define PATH_MAX, we can use it, but if not, changing the identifier doesn't solve anything no matter what the standard says.

 It defines neither PATH_MAX nor MAXPATHLEN (pathnames can be arbitrarily long).

 -- 
 Robert Millan

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>, Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Fri, 18 Sep 2015 22:25:23 +0200

 El 18/09/15 a les 14:57, Antti Kantee ha escrit:
 > On Fri, Sep 11, 2015 at 01:04:08AM +0200, Robert Millan wrote:
 >> I just realized there's a much simpler way around this, if we want to test for
 >> MAXPATHLEN as you suggest, autoconf really isn't necessary as it can be done
 >> directly in C pre-processor.
 >>
 >> See attached patch, please let me know what you think.
 >
 > Even if make is the only thing in tools currently using MAXPATHLEN,
 > could we put the compat value into tools/compat/compat_defs.h
 > instead?
 >
 > Apart from that, the approach seems ok.

 compat_defs.h doesn't seem to help as make.h does:

 /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c: In function 'ArchSVR4Entry':
 /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47: error: 'MAXPATHLEN' undeclared (first use in this function)
       (void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);

 what is the expected include path for arch.c -> compat_defs.h?

 -- 
 -- 
 Robert Millan

From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sat, 19 Sep 2015 13:27:54 +0000

 On 18/09/15 20:25, Robert Millan wrote:
 > compat_defs.h doesn't seem to help as make.h does:
 >
 > /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:
 > In function 'ArchSVR4Entry':
 > /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47:
 > error: 'MAXPATHLEN' undeclared (first use in this function)
 >       (void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);
 >
 > what is the expected include path for arch.c -> compat_defs.h?

 Try adding:

 #if HAVE_NBTOOL_CONFIG_H
 #include "nbtool_config.h"
 #endif

 to the appropriate place(s).

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 14:20:14 +0200

 Hi,

 El 19/09/15 a les 15:27, Antti Kantee ha escrit:
 > On 18/09/15 20:25, Robert Millan wrote:
 >> compat_defs.h doesn't seem to help as make.h does:
 >>
 >> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:
 >> In function 'ArchSVR4Entry':
 >> /home/amnesia/rump/debian/rumpkernel/buildrump.sh/src/tools/make/../../usr.bin/make/arch.c:815:47:
 >> error: 'MAXPATHLEN' undeclared (first use in this function)
 >>       (void)strncpy(name, &ar->fnametab[entry], MAXPATHLEN);
 >>
 >> what is the expected include path for arch.c -> compat_defs.h?
 >
 > Try adding:
 >
 > #if HAVE_NBTOOL_CONFIG_H
 > #include "nbtool_config.h"
 > #endif
 >
 > to the appropriate place(s).

 I don't think this can work. Looking at the log, make is initially compiled before running
 build.sh, then build.sh uses make to build other stuff, and then nbtool_config.h is
 dynamically generated by src/tools/compat/configure.

 Can we make an exception for make and put the MAXPATHLEN ifdef in make.h too?

 -- 
 Robert Millan

From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 12:48:21 +0000

 On 20/09/15 12:20, Robert Millan wrote:
 >>> what is the expected include path for arch.c -> compat_defs.h?
 >>
 >> Try adding:
 >>
 >> #if HAVE_NBTOOL_CONFIG_H
 >> #include "nbtool_config.h"
 >> #endif
 >>
 >> to the appropriate place(s).
 >
 > I don't think this can work. Looking at the log, make is initially
 > compiled before running
 > build.sh, then build.sh uses make to build other stuff, and then
 > nbtool_config.h is
 > dynamically generated by src/tools/compat/configure.
 >
 > Can we make an exception for make and put the MAXPATHLEN ifdef in make.h
 > too?

 You don't think it can work, or you tested it => it didn't work, and you 
 think there's a fundamental flaw in the scheme?

 We can address make separately too if need be.  Do you still need the 
 bits in compat/{Makefile,defs.mk.in}?  Can those be addressed by using 
 compat_defs.h instead of hardcoding the values based on uname -s?  Or 
 does that require including nbtool_config.h from a large number of .c files?

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 15:19:34 +0200

 El 20/09/15 a les 14:48, Antti Kantee ha escrit:
 > On 20/09/15 12:20, Robert Millan wrote:
 >>>> what is the expected include path for arch.c -> compat_defs.h?
 >>>
 >>> Try adding:
 >>>
 >>> #if HAVE_NBTOOL_CONFIG_H
 >>> #include "nbtool_config.h"
 >>> #endif
 >>>
 >>> to the appropriate place(s).
 >>
 >> I don't think this can work. Looking at the log, make is initially
 >> compiled before running
 >> build.sh, then build.sh uses make to build other stuff, and then
 >> nbtool_config.h is
 >> dynamically generated by src/tools/compat/configure.
 >>
 >> Can we make an exception for make and put the MAXPATHLEN ifdef in make.h
 >> too?
 >
 > You don't think it can work, or you tested it => it didn't work, and you think there's a fundamental flaw in the scheme?

 I tested it and it didn't work, then I noticed the chicken & egg problem. Sorry I wasn't clear enough.

 > Do you still need the bits in compat/{Makefile,defs.mk.in}?  Can those be addressed by using compat_defs.h instead of hardcoding the values based on uname -s?  Or does that require including nbtool_config.h from a large number of .c files?

 Possibly not. I'll check and get back to you.

 Thanks

 -- 
 Robert Millan

From: Martin Husemann <martin@duskware.de>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: misc/50166
Date: Sun, 20 Sep 2015 16:56:39 +0200

 Maybe we should even do something more radical and follow Plan9 completely
 (in make) by eliminating all size limited path name buffers?

 Should not be too hard, and conceptionally make has no purpose to know about
 varying and arbitrary path limits.

 Martin
 P.S.: but I understand you are looking for a quick/interim solution to get
 things going, that is fine too.

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Mon, 21 Sep 2015 22:37:13 +0200

 This is a multi-part message in MIME format.
 --------------030703000301090409070001
 Content-Type: text/plain; charset=windows-1252; format=flowed
 Content-Transfer-Encoding: 7bit

 El 20/09/15 a les 14:48, Antti Kantee ha escrit:
 > We can address make separately too if need be.  Do you still need the bits in compat/{Makefile,defs.mk.in}?  Can those be addressed by using compat_defs.h instead of hardcoding the values based on uname -s?  Or does that require including nbtool_config.h from a large number of .c files?

 As you suggested, I took a closer inspection by disabling all the generic -D flags and
 using nbtool_config.h instead.

 Then I added back only the defines that were needed in the corresponding individual
 files.

 The result is much smaller than I expected. In fact, other than make (because of the
 bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc issues are
 handled by nbtool_config.h.

 Please consider attached patch.

 -- 
 Robert Millan

 --------------030703000301090409070001
 Content-Type: text/x-patch;
  name="limits.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="limits.diff"

 Index: rumpkernel/buildrump.sh/src/usr.bin/make/make.h
 ===================================================================
 --- rumpkernel.orig/buildrump.sh/src/usr.bin/make/make.h
 +++ rumpkernel/buildrump.sh/src/usr.bin/make/make.h
 @@ -503,4 +503,10 @@ int str2Lst_Append(Lst, char *, const ch
  #define MAX(a, b) ((a > b) ? a : b)
  #endif

 +/* GNU/Hurd systems lack MAXPATHLEN */
 +#include <limits.h>
 +#ifndef MAXPATHLEN
 +#define MAXPATHLEN	4096
 +#endif
 +
  #endif /* _MAKE_H_ */
 Index: rumpkernel/buildrump.sh/src/tools/compat/compat_defs.h
 ===================================================================
 --- rumpkernel.orig/buildrump.sh/src/tools/compat/compat_defs.h
 +++ rumpkernel/buildrump.sh/src/tools/compat/compat_defs.h
 @@ -1201,6 +1201,17 @@ __GEN_ENDIAN_DEC(64, le)
  #define LINE_MAX 2048
  #endif

 +/* GNU/Hurd systems lack MAXPATHLEN (aka PATH_MAX) and MAXHOSTNAMELEN */
 +#ifndef MAXPATHLEN
 +#define MAXPATHLEN	4096
 +#endif
 +#ifndef PATH_MAX
 +#define PATH_MAX	MAXPATHLEN
 +#endif
 +#ifndef MAXHOSTNAMELEN
 +#define MAXHOSTNAMELEN	256
 +#endif
 +
  /* <sys/time.h> */

  #ifndef timercmp
 Index: rumpkernel/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
 ===================================================================
 --- rumpkernel.orig/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
 +++ rumpkernel/buildrump.sh/src/sys/rump/include/rump/rumpuser.h
 @@ -251,4 +251,8 @@ int	rumpuser_sp_raise(void *, int);
  void	rumpuser_sp_fini(void *);
  #endif /* _RUMP_SYSPROXY || LIBRUMPUSER */

 +#ifndef MAXHOSTNAMELEN
 +#define MAXHOSTNAMELEN 256
 +#endif
 +
  #endif /* _RUMP_RUMPUSER_H_ */
 Index: rumpkernel/buildrump.sh/src/lib/librumpuser/sp_common.c
 ===================================================================
 --- rumpkernel.orig/buildrump.sh/src/lib/librumpuser/sp_common.c
 +++ rumpkernel/buildrump.sh/src/lib/librumpuser/sp_common.c
 @@ -64,6 +64,10 @@
  #define __unused __attribute__((__unused__))
  #endif

 +#ifndef PATH_MAX
 +#define PATH_MAX 4096
 +#endif
 +
  //#define DEBUG
  #ifdef DEBUG
  #define DPRINTF(x) mydprintf x
 Index: rumpkernel/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
 ===================================================================
 --- rumpkernel.orig/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
 +++ rumpkernel/buildrump.sh/src/usr.bin/rump_allserver/rump_allserver.c
 @@ -50,6 +50,10 @@ __RCSID("$NetBSD: rump_allserver.c,v 1.3
  #include <rump/rumpdefs.h>
  #include <rump/rumperr.h>

 +#ifndef MAXPATHLEN
 +#define MAXPATHLEN 4096
 +#endif
 +
  __dead static void
  usage(void)
  {

 --------------030703000301090409070001--

State-Changed-From-To: analyzed->feedback
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Mon, 21 Sep 2015 21:54:39 +0000
State-Changed-Why:
patches potentially fixing the problem committed


From: "Antti Kantee" <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/50166 CVS commit: src
Date: Mon, 21 Sep 2015 21:50:16 +0000

 Module Name:	src
 Committed By:	pooka
 Date:		Mon Sep 21 21:50:16 UTC 2015

 Modified Files:
 	src/lib/librumpuser: rumpuser_port.h
 	src/tools/compat: compat_defs.h
 	src/usr.bin/make: make.h

 Log Message:
 Add more compat defs for code compiled for !NetBSD targets.

 At least GNU Hurd lacks MAXHOSTNAMELEN/MAXPATHLEN/PATH_MAX, so make sure
 those have some arbitrary semi-sane values.

 from Robert Millan in PR misc/50166, with some modifications from myself


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.46 src/lib/librumpuser/rumpuser_port.h
 cvs rdiff -u -r1.102 -r1.103 src/tools/compat/compat_defs.h
 cvs rdiff -u -r1.95 -r1.96 src/usr.bin/make/make.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: gnats-bugs@NetBSD.org, misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Mon, 21 Sep 2015 21:53:31 +0000

 On 21/09/15 20:37, Robert Millan wrote:
 > The result is much smaller than I expected. In fact, other than make
 > (because of the
 > bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc
 > issues are
 > handled by nbtool_config.h.
 >
 > Please consider attached patch.

 Ok I committed a variant of it (I moved the rump kernel userspace bits 
 into rumpuser_port.h).  Please check if NetBSD HEAD now works for your 
 use case.

 I'm also happy to apply a patch where MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN 
 is removed from the rump kernel userspace code, if you (or someone else) 
 want to send one in another PR.

From: Robert Millan <rmh@gnu.org>
To: Antti Kantee <pooka@NetBSD.org>
Cc: Bug hurd mailing list <bug-hurd@gnu.org>, gnats-bugs@NetBSD.org,
 misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Wed, 23 Sep 2015 23:25:48 +0200

 El 21/09/15 a les 23:53, Antti Kantee ha escrit:
 > On 21/09/15 20:37, Robert Millan wrote:
 >> The result is much smaller than I expected. In fact, other than make
 >> (because of the
 >> bootstrap issue) and some Rump components, all remaining MAXPATHLEN/etc
 >> issues are
 >> handled by nbtool_config.h.
 >>
 >> Please consider attached patch.
 >
 > Ok I committed a variant of it (I moved the rump kernel userspace bits into rumpuser_port.h).  Please check if NetBSD HEAD now works for your use case.

 Well I'm glad to say I just tested, and current CVS HEAD builds correctly on GNU/Hurd now.

 > I'm also happy to apply a patch where MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel userspace code, if you (or someone else) want to send one in another PR.

 I think that would be nice having, but unfortunately I lack the spare time at the moment. CCing bug-hurd in case someone is interested.

 Thanks!

 -- 
 Robert Millan

State-Changed-From-To: feedback->closed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Thu, 24 Sep 2015 00:40:42 +0000
State-Changed-Why:
submitter reported fixed

thanks for the report and patch!


From: Antti Kantee <pooka@NetBSD.org>
To: Robert Millan <rmh@gnu.org>
Cc: Bug hurd mailing list <bug-hurd@gnu.org>, gnats-bugs@NetBSD.org,
 misc-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: misc/50166
Date: Thu, 24 Sep 2015 00:44:54 +0000

 On 23/09/15 21:25, Robert Millan wrote:
 >> I'm also happy to apply a patch where
 >> MAXPATHLEN/PATH_MAX/MAXHOSTNAMELEN is removed from the rump kernel
 >> userspace code, if you (or someone else) want to send one in another PR.
 >
 > I think that would be nice having, but unfortunately I lack the spare
 > time at the moment. CCing bug-hurd in case someone is interested.

 Right, probably not highest priority now, since the code does work ... 
 unless someone wants to exercise their possibility to put it in a 8k 
 long subdirectory path on Hurd ;)

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.