Re: ps output line length (was: svn commit: r314685 - head/bin/ps)

[Garance A Drosehn]

On 28 Jan 2018, at 11:22, Mike Karels wrote:

> The rationale for the original code was that, for interactive uses, the
> output line length should be the same for "ps ...", "ps ...|more", and
> "ps ... |grep".  The -w option exists to make the line longer; there is
> no option to use the terminal size even if the output is redirected.
> Hence, the tests for stderr or stdin being a tty.  This behavior has
> been in place since 1990, as noted, and no substantial rationale has
> been given for changing it other than "it doesn't matter if you use
> less with side-to-side scrolling."  fwiw, I'm sure I discussed that
> code with Marc at the time.
>
> As was stated, scripts that want to use the full line should use -ww.
> Interactive users have long been used to using -w when they need longer
> output lines, e.g. to match patterns that don't occur within a screen's
> width.
>
> I propose reverting this change.

I do have several scripts which work on the output of 'ps', and none
of my scripts would have noticed this change because they include -ww
and they also set 'local COLUMNS=180' and export the value of COLUMNS.

It also looks like the change from March 2017 is only in -current,
and has not been MFC-ed into 11.x-stable.

So reverting the change seems reasonable to me.

I will note that the behavior of 'ps' on linux seems to match what the
change does.  If you 'ps axu' the output is the width of your terminal,
and if you 'ps axu | grep something' then the output width seems to be
infinity (or at least it's somewhere over 2500 characters).

I have not checked how 'ps' acts on the other BSD's.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r356666 - in head/usr.bin: factor primes

[Garance A Drosehn]

Author: gad
Date: Sun Jan 12 20:25:11 2020
New Revision: 35
URL: https://svnweb.freebsd.org/changeset/base/35

Log:
  Fix the way 'factor' behaves when using OpenSSL to match the description
  of how it works when not compiled with OpenSSL.
  
  Also, allow users to specify a hexadecimal number by using a prefix of
  '0x'.  Before this, users could only specify a hexadecimal value if that
  value included a hex digit ('a'-'f') in the value.
  
  PR:   243136
  Submitted by: Steve Kargl
  Reviewed by:  gad
  MFC after:3 weeks

Modified:
  head/usr.bin/factor/factor.6
  head/usr.bin/factor/factor.c
  head/usr.bin/primes/primes.c

Modified: head/usr.bin/factor/factor.6
==
--- head/usr.bin/factor/factor.6Sun Jan 12 20:19:00 2020
(r356665)
+++ head/usr.bin/factor/factor.6Sun Jan 12 20:25:11 2020
(r35)
@@ -36,7 +36,7 @@
 .\"
 .\"   chongo  /\oo/\
 .\"
-.Dd October 10, 2002
+.Dd January 12, 2020
 .Dt FACTOR 6
 .Os
 .Sh NAME
@@ -67,11 +67,22 @@ When
 .Nm
 is invoked with no arguments,
 .Nm
-reads numbers, one per line, from standard input, until end of file or error.
+reads numbers, one per line, from standard input until end of file or 0
+is entered or an error occurs.
 Leading white-space and empty lines are ignored.
+.Pp
 Numbers may be preceded by a single
 .Ql + .
+Numbers can be either decimal or hexadecimal strings where the longest
+leading substring is used.
 Numbers are terminated by a non-digit character (such as a newline).
+If the string contains only decimal digits, it is treated as a
+decimal representation for a number.
+A hexadecimal string can contain an optional
+.Em 0x
+or
+.Em 0X
+prefix.
 After a number is read, it is factored.
 .Pp
 The
@@ -89,7 +100,7 @@ The
 value must not be greater than the maximum.
 The default and maximum value of
 .Ar stop
-is 3825123056546413050.
+is 18446744073709551615.
 .Pp
 When the
 .Nm primes

Modified: head/usr.bin/factor/factor.c
==
--- head/usr.bin/factor/factor.cSun Jan 12 20:19:00 2020
(r356665)
+++ head/usr.bin/factor/factor.cSun Jan 12 20:25:11 2020
(r35)
@@ -71,6 +71,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -97,15 +98,16 @@ typedef u_long  BN_ULONG;
 #define BN_is_one(v)   (*(v) == 1)
 #define BN_mod_word(a, b)  (*(a) % (b))
 
-static int BN_dec2bn(BIGNUM **a, const char *str);
-static int BN_hex2bn(BIGNUM **a, const char *str);
+static int BN_dec2bn(BIGNUM **, const char *);
+static int BN_hex2bn(BIGNUM **, const char *);
 static BN_ULONG BN_div_word(BIGNUM *, BN_ULONG);
 static voidBN_print_fp(FILE *, const BIGNUM *);
 
 #endif
 
 static voidBN_print_dec_fp(FILE *, const BIGNUM *);
-
+static voidconvert_str2bn(BIGNUM **, char *);
+static boolis_hex_str(char *);
 static voidpr_fact(BIGNUM *);  /* print factors of a value */
 static voidpr_print(BIGNUM *); /* print a prime */
 static voidusage(void);
@@ -148,21 +150,13 @@ main(int argc, char *argv[])
for (p = buf; isblank(*p); ++p);
if (*p == '\n' || *p == '\0')
continue;
-   if (*p == '-')
-   errx(1, "negative numbers aren't permitted.");
-   if (BN_dec2bn(&val, buf) == 0 &&
-   BN_hex2bn(&val, buf) == 0)
-   errx(1, "%s: illegal numeric format.", buf);
+   convert_str2bn(&val, p);
pr_fact(val);
}
/* Factor the arguments. */
else
-   for (; *argv != NULL; ++argv) {
-   if (argv[0][0] == '-')
-   errx(1, "negative numbers aren't permitted.");
-   if (BN_dec2bn(&val, argv[0]) == 0 &&
-   BN_hex2bn(&val, argv[0]) == 0)
-   errx(1, "%s: illegal numeric format.", argv[0]);
+   for (p = *argv; p != NULL; p = *++argv) {
+   convert_str2bn(&val, p);
pr_fact(val);
}
exit(0);
@@ -346,7 +340,7 @@ BN_dec2bn(BIGNUM **a, const char *str)
 
errno = 0;
**a = strtoul(str, &p, 10);
-   return (errno == 0 && (*p == '\n' || *p == '\0'));
+   return (errno == 0 ? 1 : 0);/* OpenSSL returns 0 on error! */
 }
 
 static int
@@ -356,7 +350,7 @@ BN_hex2bn(BIGNUM **a, const char *str)
 
errno = 0;
**a = strtoul(str, &p, 16);
-   return (errno == 0 && (*p == '\n' || *p == '\0'));
+   return (errno == 0 ? 1 : 0);/* OpenSSL returns 0 on error! */
 }
 
 static BN_ULONG
@@ -370,3 +364,46 @@ BN_div_word(BIGNUM *a, BN_ULONG b)
 }

svn commit: r220586 - head/usr.sbin/lpr/common_source

[Garance A Drosehn]

Author: gad
Date: Wed Apr 13 00:36:19 2011
New Revision: 220586
URL: http://svn.freebsd.org/changeset/base/220586

Log:
  - Fix the code that matches userids in match_jobspec().  It needs to check
the username-for-accounting field (P), not the username-for-headerpage (L).
These are usually the same value, except that control files do not have
the username-for-headerpage field if the user has requested no header page.
  - Also rename the cji_username field to cji_headruser, to make it clear that
the value should only be used for the header page.  (aka banner page)
  
  MFC after:3 weeks

Modified:
  head/usr.sbin/lpr/common_source/ctlinfo.c
  head/usr.sbin/lpr/common_source/ctlinfo.h
  head/usr.sbin/lpr/common_source/matchjobs.c

Modified: head/usr.sbin/lpr/common_source/ctlinfo.c
==
--- head/usr.sbin/lpr/common_source/ctlinfo.c   Wed Apr 13 00:03:49 2011
(r220585)
+++ head/usr.sbin/lpr/common_source/ctlinfo.c   Wed Apr 13 00:36:19 2011
(r220586)
@@ -1,6 +1,6 @@
 /*
  * 
--+-+-+-+-+-+-+-*
- * Copyright (c) 2001  - Garance Alistair Drosehn .
+ * Copyright (c) 2001,2011  - Garance Alistair Drosehn .
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -248,7 +248,7 @@ ctl_freeinf(struct cjobinfo *cjinf)
/* [cpriv->pub.cji_fname is part of cpriv-malloced area] */
FREESTR(cpriv->pub.cji_jobname);
FREESTR(cpriv->pub.cji_mailto);
-   FREESTR(cpriv->pub.cji_username);
+   FREESTR(cpriv->pub.cji_headruser);
 
if (cpriv->cji_fstream != NULL) {
fclose(cpriv->cji_fstream);
@@ -343,7 +343,7 @@ ctl_readcf(const char *ptrname, const ch
cpriv->pub.cji_jobname = strdup(lbuff);
break;
case 'L':
-   cpriv->pub.cji_username = strdup(lbuff);
+   cpriv->pub.cji_headruser = strdup(lbuff);
break;
case 'M':
/*
@@ -586,8 +586,8 @@ ctl_renametf(const char *ptrname, const 
fprintf(newcf, "C%s\n", cjinf->cji_class);
if (cjinf->cji_jobname != NULL)
fprintf(newcf, "J%s\n", cjinf->cji_jobname);
-   if (cjinf->cji_username != NULL)
-   fprintf(newcf, "L%s\n", cjinf->cji_username);
+   if (cjinf->cji_headruser != NULL)
+   fprintf(newcf, "L%s\n", cjinf->cji_headruser);
 
/*
 * This should probably add more sanity checks on mailto value.
@@ -832,7 +832,7 @@ ctl_dumpcji(FILE *dbg_stream, const char
PRINTSTR("cf-fname", cpriv->pub.cji_fname);
PRINTSTR("jobname.J", cpriv->pub.cji_jobname);
PRINTSTR("mailto.M", cpriv->pub.cji_mailto);
-   PRINTSTR("hdruser.L", cpriv->pub.cji_username);
+   PRINTSTR("headruser.L", cpriv->pub.cji_headruser);
 
ctl_dbgline++;
fprintf(dbg_stream, "%4d] %12s = ", ctl_dbgline, "*cjprivate");

Modified: head/usr.sbin/lpr/common_source/ctlinfo.h
==
--- head/usr.sbin/lpr/common_source/ctlinfo.h   Wed Apr 13 00:03:49 2011
(r220585)
+++ head/usr.sbin/lpr/common_source/ctlinfo.h   Wed Apr 13 00:36:19 2011
(r220586)
@@ -1,6 +1,6 @@
 /*
  * 
--+-+-+-+-+-+-+-*
- * Copyright (c) 2001  - Garance Alistair Drosehn .
+ * Copyright (c) 2001,2011  - Garance Alistair Drosehn .
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -59,7 +59,7 @@ struct cjobinfo {
char*cji_fname; /* filename of the control file */
char*cji_jobname;   /* job-name (for banner) */
char*cji_mailto;/* userid to send email to (or null) */
-   char*cji_username;  /* "literal" user-name (for banner) or
+   char*cji_headruser; /* "literal" user-name (for banner) or
 * NULL if no banner-page is wanted */
struct cjprivate *cji_priv;
 };

Modified: head/usr.sbin/lpr/common_source/matchjobs.c
==
--- head/usr.sbin/lpr/common_source/matchjobs.c Wed Apr 13 00:03:49 2011
(r220585)
+++ head/usr.sbin/lpr/common_source/matchjobs.c Wed Apr 13 00:36:19 2011
(r220586)
@@ -1,6 +1,6 @@
 /*
  * 
--+-+-+-+-+-+-+-*
- * Copyright (c) 2002   - Garance Alistair Drosehn .
+ * Copyright (c) 2002,2011   - Garance Alistair Drosehn .
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -453,7 +453,7 @@ match_jobspec(struct jobqueue *jq, struc
cfinf = ctl_readcf

svn commit: r211190 - head/usr.sbin/lpr/lpd

[Garance A Drosehn]

Author: gad
Date: Wed Aug 11 19:32:49 2010
New Revision: 211190
URL: http://svn.freebsd.org/changeset/base/211190

Log:
  - Improve the wait4data() routine so it behaves better when checking
print-jobs which have last-modification times that are in the future.
This shouldn't happen, of course, but it can.  And when it did happen,
the previous check could cause completely-spooled jobs to sit in the
queue for 20 minutes per job.  The new code waits until the last-modify
time is not changing, instead of making decisions based on the specific
value of last-modify.
  
  MFC after:2 weeks

Modified:
  head/usr.sbin/lpr/lpd/printjob.c

Modified: head/usr.sbin/lpr/lpd/printjob.c
==
--- head/usr.sbin/lpr/lpd/printjob.cWed Aug 11 18:23:26 2010
(r211189)
+++ head/usr.sbin/lpr/lpd/printjob.cWed Aug 11 19:32:49 2010
(r211190)
@@ -1263,8 +1263,9 @@ wait4data(struct printer *pp, const char
 {
const char *cp;
int statres;
+   u_int sleepreq;
size_t dlen, hlen;
-   time_t amtslept, checktime;
+   time_t amtslept, cur_time, prev_mtime;
struct stat statdf;
 
/* Skip these checks if the print job is from the local host. */
@@ -1297,15 +1298,30 @@ wait4data(struct printer *pp, const char
 
/*
 * The file exists, so keep waiting until the data file has not
-* changed for some reasonable amount of time.
+* changed for some reasonable amount of time.  Extra care is
+* taken when computing wait-times, just in case there are data
+* files with a last-modify time in the future.  While that is
+* very unlikely to happen, it can happen when the system has
+* a flakey time-of-day clock.
 */
-   while (statres == 0 && amtslept < MAXWAIT_4DATA) {
-   checktime = time(NULL) - MINWAIT_4DATA;
-   if (statdf.st_mtime <= checktime)
-   break;
+   prev_mtime = statdf.st_mtime;
+   cur_time = time(NULL);
+   if (statdf.st_mtime >= cur_time - MINWAIT_4DATA) {
+   if (statdf.st_mtime >= cur_time)/* some TOD oddity */
+   sleepreq = MINWAIT_4DATA;
+   else
+   sleepreq = cur_time - statdf.st_mtime;
if (amtslept == 0)
pstatus(pp, "Waiting for data file from remote host");
-   amtslept += MINWAIT_4DATA - sleep(MINWAIT_4DATA);
+   amtslept += sleepreq - sleep(sleepreq);
+   statres = stat(dfile, &statdf);
+   }
+   sleepreq = MINWAIT_4DATA;
+   while (statres == 0 && amtslept < MAXWAIT_4DATA) {
+   if (statdf.st_mtime == prev_mtime)
+   break;
+   prev_mtime = statdf.st_mtime;
+   amtslept += sleepreq - sleep(sleepreq);
statres = stat(dfile, &statdf);
}
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r315655 - head/usr.sbin/lpr/chkprintcap

[Garance A Drosehn]

Author: gad
Date: Mon Mar 20 22:36:28 2017
New Revision: 315655
URL: https://svnweb.freebsd.org/changeset/base/315655

Log:
  Fixes to chkprintcap:
  - Check the return from a call to malloc() in skim_printcap(), and
return a NULL if that fails.
  - Fix a small memory leak in main() that happens if skim_printcap()
returns an error, including the new error-return of NULL.
  
  Submitted by: Tom Rix 
  Reviewed by:  pfg, ngie
  MFC after:4 weeks
  Sponsored by: Dell EMC Isilon, Juniper
  Differential Revision:D9954, D9982

Modified:
  head/usr.sbin/lpr/chkprintcap/chkprintcap.c
  head/usr.sbin/lpr/chkprintcap/skimprintcap.c

Modified: head/usr.sbin/lpr/chkprintcap/chkprintcap.c
==
--- head/usr.sbin/lpr/chkprintcap/chkprintcap.c Mon Mar 20 22:33:22 2017
(r315654)
+++ head/usr.sbin/lpr/chkprintcap/chkprintcap.c Mon Mar 20 22:36:28 2017
(r315655)
@@ -113,8 +113,13 @@ main(int argc, char **argv)
 * the printcap file.
*/
skres = skim_printcap(pcap_fname, verbosity);
-   if (skres->fatalerr)
-   return (skres->fatalerr);
+   if (skres == NULL) {
+   problems = 1;
+   goto main_ret;
+   } else if (skres->fatalerr) {
+   problems = skres->fatalerr;
+   goto main_ret;
+   }
 
/*
 * Now use the standard capability-db routines to check the values
@@ -156,6 +161,9 @@ next:
warnx("WARNING:  but only found %d queues to process!",
queuecnt);
}
+
+main_ret:
+   free(pcap_fname);
return (problems);
 }
 

Modified: head/usr.sbin/lpr/chkprintcap/skimprintcap.c
==
--- head/usr.sbin/lpr/chkprintcap/skimprintcap.cMon Mar 20 22:33:22 
2017(r315654)
+++ head/usr.sbin/lpr/chkprintcap/skimprintcap.cMon Mar 20 22:36:28 
2017(r315655)
@@ -82,6 +82,8 @@ skim_printcap(const char *pcap_fname, in
enum {CMNT_LINE, ENTRY_LINE, TAB_LINE, TABERR_LINE} is_type, had_type;
 
skinf = malloc(sizeof(struct skiminfo));
+   if (skinf == NULL)
+   return (NULL);
memset(skinf, 0, sizeof(struct skiminfo));
 
pc_file = fopen(pcap_fname, "r");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r330787 - head/usr.sbin/lpr/common_source

[Garance A Drosehn]

Author: gad
Date: Mon Mar 12 01:41:16 2018
New Revision: 330787
URL: https://svnweb.freebsd.org/changeset/base/330787

Log:
  Fix the resource leak of a 'FILE *' which could happen in routine
  ctl_readcf() if a call to malloc failed.
  
  PR:   204955
  Reported by:  David Binderman

Modified:
  head/usr.sbin/lpr/common_source/ctlinfo.c

Modified: head/usr.sbin/lpr/common_source/ctlinfo.c
==
--- head/usr.sbin/lpr/common_source/ctlinfo.c   Mon Mar 12 00:33:01 2018
(r330786)
+++ head/usr.sbin/lpr/common_source/ctlinfo.c   Mon Mar 12 01:41:16 2018
(r330787)
@@ -292,8 +292,10 @@ ctl_readcf(const char *ptrname, const char *cfname)
msize = sroom2 + CTI_LINEMAX;
msize = roundup(msize, 8);
cstart = malloc(msize);
-   if (cstart == NULL)
+   if (cstart == NULL) {
+   fclose(cfile);
return NULL;
+   }
memset(cstart, 0, msize);
cpriv = (struct cjprivate *)cstart;
cpriv->pub.cji_priv = cpriv;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r314654 - in head/cddl: lib/drti lib/libavl lib/libctf lib/libdtrace lib/libnvpair lib/libumem lib/libuutil lib/libzfs lib/libzfs_core lib/libzpool sbin/zfs sbin/zpool usr.bin/ctfconve

[Garance A Drosehn]

On 4 Mar 2017, at 15:42, Ngie Cooper (yaneurabeya) wrote:


On Mar 4, 2017, at 12:39, Rodney W. Grimes wrote:

On 4 Mar 2017, at 15:13, Bryan Drewery wrote:


Where is this discussion?  The only one I can find is
https://reviews.freebsd.org/D9207 which seems to have
a consensus of moving to SRCTOP and :H vs '../..'.


There was a short discussion here on the commiters list
with some others expressing the preferred the relative
status of things even though it clutters logs.

D9207 touches 15 files.. I would not consider that an
adequate review that is actually going to change nearly
every Makefile in the tree, and change what people have
been looking and at working with for 30 years.

I don't think any differntial that only had 3 or 4 people
involved that is going to effect all developers is
adequate either.  Tree wide sweeping changes should be
discussed far more widely.

Idk, maybe I am to personally attached to the relative
paths.. cause I had a major part in helping them all to
work, or perhaps its my been burned by absolute paths
that had to be reworked too many times in my past.  But
my gut is telling me this change is Bad(tm).


I care about this for the reasons brewery posted, but I
also care because it slows down my terminal output and
it bloats my disk with typescript logs that contain
unnecessary information.


FWIW, here was my method to fix the "slows down output" issue.
I wrote a wrapper around 'make' which I called "wcmake", and
it runs the output from a 'make' command through a script
which does a variety of analysis on that output.

Among other things, it truncates the lines of make-output to
screen width, but it saves the full output to a temp file, and
then compresses that temp file.  It also parses and condenses
the output so what the user sees at the console looks like:

cc -c /usr/src/usr.bin/make/arch.c -O2 -pipe -I/usr/src/usr.bin/make 
-DMAKE_V|+
cc -c /usr/src/usr.bin/make/buf.c -O2 -pipe -I/usr/src/usr.bin/make 
-DMAKE_VE|+
cc -c /usr/src/usr.bin/make/cond.c -O2 -pipe -I/usr/src/usr.bin/make 
-DMAKE_V|+


instead of:

cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\"9201210220\" 
-DDEFSHELLNAME=\"sh\" -std=gnu99  -fstack-protector -Wsystem-headers 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c 
-o arch.o


cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\"9201210220\" 
-DDEFSHELLNAME=\"sh\" -std=gnu99  -fstack-protector -Wsystem-headers 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/buf.c 
-o buf.o


cc -O2 -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=\"9201210220\" 
-DDEFSHELLNAME=\"sh\" -std=gnu99  -fstack-protector -Wsystem-headers 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
-Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
-Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/make/cond.c 
-o cond.o


#  [I added blank-lines between the lines of make-output, so
#   it doesn't look so much like a solid wall of characters]

(ie, it moves the '-c filename' to the start of the line, strips
the setting of any environment variables at the start, and tacks
on the '|+' at the end if it has truncated the line).  It also
parses the output looking for warning messages, and writes a
summary of messages-seen after the 'make' has finished.

One of the goals was to speed up buildworld's when I was doing
them via a serial console-session or over a slow ssh-connection.
But this way if something really bad or odd *did* come up, I
could look at the original full make-output which was saved on
disk.  Adding a wrapper-script obviously adds more CPU work to
the build, but my builds definitely finished faster as-far-as
wall-clock time because I was writing so much less output to
the console.

I have two versions of this script, and I don't remember why
there are two versions.  The first one was written in perl, and
later I wrote a second one in ruby.  Both are under ~gad/scripts
on the machines at freebsd.org.  I'm sure the code in the
scripts is probably lousy and somewhat embarrassing (to me),
but you could at least check them out and see where I was
going with it.

disclaimer: I haven't taken a serious look at these scripts a
few years.  I'm sure they need to be updated due to new commands
and new warning messages which have appeared since then.

--
Garan

Re: svn commit: r314654 - in head/cddl: lib/drti lib/libavl lib/libctf lib/libdtrace lib/libnvpair lib/libumem lib/libuutil lib/libzfs lib/libzfs_core lib/libzpool sbin/zfs sbin/zpool usr.bin/ctfconve

[Garance A Drosehn]

On 5 Mar 2017, at 20:43, Ngie Cooper wrote:

>> On Mar 5, 2017, at 17:05, Garance A Drosehn  wrote:
>>
>> FWIW, here was my method to fix the "slows down output" issue.
>> I wrote a wrapper around 'make' which I called "wcmake", and
>> it runs the output from a 'make' command through a script
>> which does a variety of analysis on that output.
>
> Hi!
> Have you considered using make -s instead? It definitely
> abbreviates the output quite a bit...
> I probably could do similar for my local builds. Our
> Jenkins runs don't do that, but maybe they should though..
> Thanks,
> -Ngie

Well, the scripts are doing a lot more than just abbreviating the
output sent to the console.  They save the entire output, and
compress that file to reduce the space used.  They also generate
a summary of warnings-seen at the end.  This was very helpful
when I was fixing all the compile-time warnings in 'lpr'.

My first tactic was sending the output to /dev/null, but then I
was stuck when "something weird" happened, and I had no idea
where 'make' had been before it went off the rails.  Especially
when using 'make -j', it can be important to see the last 30-50
lines of make's output to understand what really went wrong.

And sometimes what-went-wrong was that some file was being built
with the wrong parameters, and I'd lose that info with 'make -s'.

Also, I use these same 'wcmake' scripts on multiple platforms.
These scripts don't care which version of 'make' needs to be used.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r250731 - head

[Garance A Drosehn]

Author: gad
Date: Fri May 17 03:14:55 2013
New Revision: 250731
URL: http://svnweb.freebsd.org/changeset/base/250731

Log:
  Drop any connection to newsyslog.  I haven't worked on it for quite
  some time.  Note that I do want to keep the pre-commit review for
  usr.sbin/lpr.  I am actively working on some updates for that.

Modified:
  head/MAINTAINERS

Modified: head/MAINTAINERS
==
--- head/MAINTAINERSFri May 17 00:40:48 2013(r250730)
+++ head/MAINTAINERSFri May 17 03:14:55 2013(r250731)
@@ -63,7 +63,6 @@ procfsdes Pre-commit review requested.
 linprocfs  des Pre-commit review requested.
 lprgad Pre-commit review requested, particularly for
lpd/recvjob.c and lpd/printjob.c.
-newsyslog(8)   gad Heads-up appreciated.  I'm going thru the PR's for it.
 nvipeter   Try not to break it.
 libz   peter   Try not to break it.
 groff  ru  Recommends pre-commit review.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r251044 - head/usr.sbin/lpr/common_source

[Garance A Drosehn]

Author: gad
Date: Mon May 27 22:19:01 2013
New Revision: 251044
URL: http://svnweb.freebsd.org/changeset/base/251044

Log:
  Change the closeallfds() routine to use closefrom() when it is
  available (closefrom() was added to FreeBSD in 8.0-release).
  The selection is made at compile-time, as I still compile a
  FreeBSD-based version of lpr&friends on other platforms.
  
  While testing I out that (at least on my system) lpd has been
  closing 11095 fd's, when there are only 6 fd's open.  The old
  code took 120 times more clocktime than calling closefrom().
  (although that was still less than 2/1000-ths of a second!)
  
  Reviewed by:  jilles
  MFC after:2 weeks

Modified:
  head/usr.sbin/lpr/common_source/common.c
  head/usr.sbin/lpr/common_source/lp.cdefs.h

Modified: head/usr.sbin/lpr/common_source/common.c
==
--- head/usr.sbin/lpr/common_source/common.cMon May 27 22:18:04 2013
(r251043)
+++ head/usr.sbin/lpr/common_source/common.cMon May 27 22:19:01 2013
(r251044)
@@ -757,16 +757,22 @@ fatal(const struct printer *pp, const ch
 
 /*
  * Close all file descriptors from START on up.
- * This is a horrific kluge, since getdtablesize() might return
- * ``infinity'', in which case we will be spending a long time
- * closing ``files'' which were never open.  Perhaps it would
- * be better to close the first N fds, for some small value of N.
  */
 void
 closeallfds(int start)
 {
-   int stop = getdtablesize();
-   for (; start < stop; start++)
-   close(start);
+   int stop;
+
+   if (USE_CLOSEFROM)  /* The faster, modern solution */
+   closefrom(start);
+   else {
+   /* This older logic can be pretty awful on some OS's.  The
+* getdtablesize() might return ``infinity'', and then this
+* will waste a lot of time closing file descriptors which
+* had never been open()-ed. */
+   stop = getdtablesize();
+   for (; start < stop; start++)
+   close(start);
+   }
 }
 

Modified: head/usr.sbin/lpr/common_source/lp.cdefs.h
==
--- head/usr.sbin/lpr/common_source/lp.cdefs.h  Mon May 27 22:18:04 2013
(r251043)
+++ head/usr.sbin/lpr/common_source/lp.cdefs.h  Mon May 27 22:19:01 2013
(r251044)
@@ -1,6 +1,6 @@
 /*-
  * 
--+-+-+-+-+-+-+-*
- * Copyright (c) 2003  - Garance Alistair Drosehn .
+ * Copyright (c) 2003,2013  - Garance Alistair Drosehn .
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -56,6 +56,21 @@
 #endif
 
 /*
+ * FreeBSD added a closefrom() routine in release 8.0.  When compiling
+ * `lpr' on other platforms you might want to include bsd-closefrom.c
+ * from the portable-openssh project.
+ */
+#ifndefUSE_CLOSEFROM
+#  if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+#defineUSE_CLOSEFROM   1
+#  endif
+#endif
+/* The macro USE_CLOSEFROM must be defined with a value of 0 or 1. */
+#ifndefUSE_CLOSEFROM
+#  define  USE_CLOSEFROM   0
+#endif
+
+/*
  * __unused is a compiler-specific trick which can be used to avoid
  * warnings about a variable which is defined but never referenced.
  * Some lpr files use this, so define a null version if it was not
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba

[Garance A Drosehn]

On 6/18/13 12:40 PM, Tijl Coosemans wrote:
> On 2013-06-18 04:53, Peter Wemm wrote:
>> Author: peter
>> Date: Tue Jun 18 02:53:45 2013
>> New Revision: 251886
>> URL: http://svnweb.freebsd.org/changeset/base/251886
>>
>> Log:
>>Introduce svnlite so that we can check out our source code again.
>>
>>This is actually a fully functional build except: [...]
>>
>>To be absolutely clear, this is not intended for any use other
>>than checking out freebsd source and committing, like we once
>>did with cvs.
>>
>>It should be usable for small scale local repositories that don't
>>need the python/perl plugin architecture.
>
> This ties the repo to the oldest supported release, meaning that years
> from now we won't be able to use some new subversion feature because
> an old FreeBSD release doesn't support it.
>
> I don't find it unreasonable to ask developers to install the port.

This doesn't tie the repo to anything.  It just means that when anyone
installs the latest version of FreeBSD, they can immediately use this
'svnlite' to get the latest updates.

If the user is still running the same release of FreeBSD after a major
format change to the repo, then they can install the 'svn' port at that
time.  If it is reasonable to ask someone to install a port right when
they first install a brand new release, then it's certainly reasonable
to ask them to install the port if they're sticking to an ancient
release of FreeBSD after the FreeBSD repository has gone through a
significant svn-level update.

Note that a major change to the FreeBSD repo would require that users
install a new 'svn' anyway, even if they did install 'svn' back when
they first installed FreeBSD.

IMO, I think this 'svnlite' idea is a good move.  I wouldn't want a
full-blown official 'svn' in the base system, but just enough that
a user can immediately get freebsd-specific updates without first
needing to install some port.

--
Garance Alistair Drosehn=   g...@gilead.netel.rpi.edu
Senior Systems Programmer   or  g...@freebsd.org
Rensselaer Polytechnic Instituteor  dro...@rpi.edu

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba

[Garance A Drosehn]

On 6/22/13 2:38 PM, Tijl Coosemans wrote:
> On 2013-06-20 21:34, Warner Losh wrote:
>>
>> I think insisting on a definitive statement on svn lite's mission
>> statement is a way to obstruct progress. Sometimes you just need to
>> things because they feel right, not because they have been through a
>> 20-step approval process...
>
> For what it's worth, my reservations have always been because it
> didn't feel right. I never asked for an approval process.
>
> I do think there should be a tool in base that can fetch source
> updates and it would be nice if it could roll back changes and
> even nicer if it could do bisects. But svn itself is not the
> right tool for that.
>
> For instance, will you allow that svn is updated from version x.y
> to x.(y+1) in a stable branch? If yes, then users might have to run
> run "svn upgrade" which is a one way process, so how does importing
> svn allow you to roll back changes or do bisects then? If no, then
> who's volunteering to backport security fixes?

What was added to the base system was 'svnlite', not 'svn' from
the official subversion project.  The distinction is that
'svnlite' is a version meant only for access to the official
FreeBSD repositories.  'svnlite' in the base system would only
be upgraded when it is needed to match the FreeBSD respository.
And if you need to run 'svn upgrade' to access the FreeBSD
repository, then it doesn't make much difference if you have
to do that with 'svnlite' or via the official 'svn' port.

I'm not sure that my comments provide an answer to what you're
concerned about, but anyone who wants the latest version of
'svn' to match their own repositories is still going to need
to install the port.  We're not going to blindly update
'svnlite' every time a new version of 'svn' is released.
'svnlite' is going to be updated on *FreeBSD*'s schedule,
not on the schedule of the subversion project.

It is true that we're going to have to be careful when it does
come time to switch to some new repo-format for the FreeBSD
repository.  We might find ourselves in some kind of chicken-
and-egg situation at that point.  And when we do make a
significant upgrade to the FreeBSD repository, then we're
going to have to upgrade 'svnlite' across multiple FreeBSD
branches at the same time, including all -stable branches.
But when that issue comes up it'll come up on our schedule,
because we'll control both 'svnlite' and the FreeBSD repo.

--
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r263351 - in head: bin/pkill bin/pkill/tests etc/mtree tools/regression/usr.bin/pkill

[Garance A Drosehn]

On 19 Mar 2014, at 8:46, Julio Merino wrote:

> Author: jmmv
> Date: Wed Mar 19 12:46:04 2014
> New Revision: 263351
> URL: http://svnweb.freebsd.org/changeset/base/263351
>
> Log:
> Migrate tools/regression/usr.bin/pkill to the new tests layout.
>
> Interestingly, the pkill tool lives in bin, not usr.bin.  Haven't bothered
> to check if this is because the tool moved or because the tests were
> originally added in the wrong place.

FWIW:

pkill was originally in usr.bin, because it was in usr.bin in other
BSD projects (particularly NetBSD, where it came from).  I thought some
kind of marker had been left behind in usr.bin after it was moved, just
because people from other projects might look for it there.  But I guess
that did not happen.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Garance A Drosehn]

On 7 Aug 2016, at 7:40, Bruce Simpson wrote:

> On 07/08/16 11:58, Bruce Simpson wrote:
>> Is there a way to revert this change, at least on an ongoing
>> operational basis (e.g. configuration file) for those of us who
>> use FreeBSD to connect directly to such devices?
>
> I was able to override this (somewhat unilateral, to my mind)
> deprecation of the DH key exchange by using this option:
>-oKexAlgorithms=+diffie-hellman-group1-sha1

If I understand the issues, the biggest concern with this change is
for people who need ssh clients to connect to ancient hardware.

Perhaps we could reduce the pain of this change by creating a special
port for ssh.  One which installs a version of openssh that does not
include this change, and which also does not include sshd.  In addition,
it could install ssh/scp under some alternate names, such that people
would have to explicitly request 'ssh-2015' (instead of 'ssh') to
execute this older version of ssh.  (I suspect that we should not
call the binaries 'ssh-old' and 'scp-old', as those names will not
work well for a long-term option).

*That* port would remain frozen in time, and would (probably) not
import any updates from future versions of openssh.  The only goal of
this port is to give people a way to access hardware that they cannot
access with the newer version of openssh.  It is not some new fork
of ssh which will track future improvements to openssh.

This ssh-2015 version might need some updates of it's own, but only
wrt default configuration settings, and maybe so it will recognize
some special configuration options that the main ssh will ignore.

[aside: we have some machines here at RPI which are old enough that
I already have an alternate-version of ssh to connect to them, so
this tactic is nothing new to me!  Kinda sad, really...]

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r290951 - head

[Garance A Drosehn]

Author: gad
Date: Mon Nov 16 22:08:49 2015
New Revision: 290951
URL: https://svnweb.freebsd.org/changeset/base/290951

Log:
  I'm still interested in reviewing any code changes to lpr & friends
  (lpc, lpd, lpq, etc).

Modified:
  head/MAINTAINERS

Modified: head/MAINTAINERS
==
--- head/MAINTAINERSMon Nov 16 21:55:11 2015(r290950)
+++ head/MAINTAINERSMon Nov 16 22:08:49 2015(r290951)
@@ -70,6 +70,8 @@ sys/dev/e1000 erj Pre-commit phabricator
 sys/dev/ixgbe  erj Pre-commit phabricator review requested.
 sys/dev/ixlerj Pre-commit phabricator review requested.
 usr.sbin/pkg   pkg@Please coordinate behavior or flag changes with pkg 
team.
+lprgad Pre-commit review requested, particularly for
+   lpd/recvjob.c and lpd/printjob.c.
  OLD 
 libc/posix1e   rwatson Pre-commit review requested.
 POSIX.1e ACLs  rwatson Pre-commit review requested.
@@ -100,8 +102,6 @@ etc/mailgshapiroPre-commit review requ
Keep in sync with -STABLE.
 etc/sendmail   gshapiroPre-commit review requested.
Keep in sync with -STABLE.
-lprgad Pre-commit review requested, particularly for
-   lpd/recvjob.c and lpd/printjob.c.
 nvipeter   Try not to break it.
 libz   peter   Try not to break it.
 groff  ru  Recommends pre-commit review.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r298592 - head/usr.sbin/lpr/lpd

[Garance A Drosehn]

Author: gad
Date: Mon Apr 25 20:58:54 2016
New Revision: 298592
URL: https://svnweb.freebsd.org/changeset/base/298592

Log:
  Remove a variable and three lines of code which I should have removed as
  part of revision 98776 back on June 24/2002.  Noticed by pfg@ trying
  coccinelle for checking code.
  
  MFC after:3 weeks

Modified:
  head/usr.sbin/lpr/lpd/lpd.c

Modified: head/usr.sbin/lpr/lpd/lpd.c
==
--- head/usr.sbin/lpr/lpd/lpd.c Mon Apr 25 18:55:01 2016(r298591)
+++ head/usr.sbin/lpr/lpd/lpd.c Mon Apr 25 20:58:54 2016(r298592)
@@ -657,11 +657,7 @@ chkhost(struct sockaddr *f, int ch_opts)
char hostbuf[NI_MAXHOST], ip[NI_MAXHOST];
char serv[NI_MAXSERV];
char *syserr, *usererr;
-   int error, errsav, fpass, good, wantsl;
-
-   wantsl = 0;
-   if (ch_opts & LPD_LOGCONNERR)
-   wantsl = 1; /* also syslog the errors */
+   int error, errsav, fpass, good;
 
from_host = ".na.";
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r234824 - head/usr.sbin/lpr/lpc

[Garance A Drosehn]

Author: gad
Date: Mon Apr 30 00:54:10 2012
New Revision: 234824
URL: http://svn.freebsd.org/changeset/base/234824

Log:
  Catch the user-error when no queue name was specified on an
  lpc-command which supports '-msg' (e.g.: setstatus).  Print
  out a helpful error message instead hitting a seg-fault.
  
  MFC after:3 weeks

Modified:
  head/usr.sbin/lpr/lpc/cmds.c

Modified: head/usr.sbin/lpr/lpc/cmds.c
==
--- head/usr.sbin/lpr/lpc/cmds.cSun Apr 29 22:29:48 2012
(r234823)
+++ head/usr.sbin/lpr/lpc/cmds.cMon Apr 30 00:54:10 2012
(r234824)
@@ -163,6 +163,14 @@ generic(void (*specificrtn)(struct print
break;
}
}
+   if (argc < 1) {
+   printf("error: No printer name(s) specified before"
+   " '-msg'.\n");
+   printf("usage: %s  {all | printer ...}",
+   generic_cmdname);
+   printf(" [-msg  ...]\n");
+   return;
+   }
}
 
/* call initialization routine, if there is one for this cmd */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r234826 - head/usr.sbin/lpr/lpc

[Garance A Drosehn]

Author: gad
Date: Mon Apr 30 01:10:13 2012
New Revision: 234826
URL: http://svn.freebsd.org/changeset/base/234826

Log:
  Print out a warning message if a `lpc setstatus' is done when
  the queue is not 'lpc stop'-ed.  In that situation `lpq' will
  not display the status message to the user, and the operator
  may think the queue is already stopped when it is not.
  
  MFC after:3 weeks

Modified:
  head/usr.sbin/lpr/lpc/cmds.c

Modified: head/usr.sbin/lpr/lpc/cmds.c
==
--- head/usr.sbin/lpr/lpc/cmds.cMon Apr 30 01:08:18 2012
(r234825)
+++ head/usr.sbin/lpr/lpc/cmds.cMon Apr 30 01:10:13 2012
(r234826)
@@ -1009,12 +1009,30 @@ setstatus_gi(int argc __unused, char *ar
 void
 setstatus_q(struct printer *pp)
 {
+   struct stat stbuf;
+   int not_shown;
char lf[MAXPATHLEN];
 
lock_file_name(pp, lf, sizeof lf);
printf("%s:\n", pp->printer);
 
upstat(pp, generic_msg, 1);
+
+   /*
+* Warn the user if 'lpq' will not display this new status-message.
+* Note that if lock file does not exist, then the queue is enabled
+* for both queuing and printing.
+*/
+   not_shown = 1;
+   if (stat(lf, &stbuf) >= 0) {
+   if (stbuf.st_mode & LFM_PRINT_DIS)
+   not_shown = 0;
+   }
+   if (not_shown) {
+   printf("\tnote: This queue currently has printing enabled,\n");
+   printf("\tso this -msg will only be shown by 'lpq' if\n");
+   printf("\ta job is actively printing on it.\n");
+   }
 }
 
 /*
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r235601 - head/include/protocols

[Garance A Drosehn]

On 5/21/12 11:27 AM, John Baldwin wrote:

On Friday, May 18, 2012 11:24:36 am Gleb Kurtsou wrote:
   

On (18/05/2012 09:41), John Baldwin wrote:
 

A question about your stat changes: did you expand dev_t to 32 bits
for the AFS folks, or did you leave it as 16 bits?

dev_t is already 32-bit. Changing it to 64-bit was discussed at some
point and from what I recall no decision was made:

   http://marc.info/?t=12911947875&r=1&w=2

I'm going to commit preparatory changes only for now. Then publish
diff for testing. We can still change dev_t to 64-bit if needed.
Although I didn't work on it.
 

Ah, it was 64-bit they asked for.  If it is easy to do so, I'd favor
changing it since you've already done all the hard work of rolling a
new stat structure.  I'd rather err on wasting 32-bits for dev_t than
having to do all this over again.
   

I would also like to see dev_t changed to 64-bits as part of these
'stat' changes, if that won't cause too much work.  It should be
less work to do it as part of these changes than to do it later!
If changing dev_t to 64-bits turns out to be too much work right
now, then maybe we could at least reserve a 64-bit space and have
the current dev_t be the low-order 32-bits of that space.

--
Garance Alistair Drosehn=   g...@gilead.netel.rpi.edu
Senior Systems Programmer   or  g...@freebsd.org
Rensselaer Polytechnic Instituteor  dro...@rpi.edu

___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r253002 - head

[Garance A Drosehn]

On 7/7/13 4:39 PM, Alfred Perlstein wrote:


Log:
   Document tip on how to build all kernels quickly.


Modified: head/Makefile
==
--- head/Makefile   Sun Jul  7 19:58:14 2013(r253001)
+++ head/Makefile   Sun Jul  7 20:39:11 2013(r253002)
@@ -32,6 +32,12 @@
  # targets - Print a list of supported TARGET/TARGET_ARCH pairs
  #   for world and kernel targets.
  # toolchains  - Build a toolchain for all world and kernel targets.
+#
+# "quick" way to test all kernel builds:
+#  _jflag=`sysctl -n hw.ncpu`
+#  _jflag=$(($_jflag * 2))
+#  [ $_jflag -gt 12 ]&&  _jflag=12
+#  make universe -DMAKE_JUST_KERNELS JFLAG=${jflag}
  #
  # This makefile is simple by design. [...]


I think it's probably helpful to point out the -j flag, but I'm
not sure I would phrase it as if we're sure that the values here
are the ideal ones.  I expect the ideal values depend too much on
hardware (e.g.: the CPU, type of disk used, and amount of memory
on the machine).  I did a lot of benchmarks of -j a few years
ago on the few machines I owned.  In my case, when I averaged
the results across my machines, the ideal value was more like
ncpu+1, not ncpu*2.

It wouldn't surprise me at all if the ideal value has changed
since I did that.  And it wouldn't surprise me if the ideal
value changes again in the next two years, especially when
one considers the variety of hardware architectures that
FreeBSD runs on.

It's good to mention the make command, the -DMAKE_JUST_KERNELS,
and that using the JFLAG can speed things up.  But I think it
should be said that this min(jcpu*2, 12) recommendation works
well for some hardware, but that people might need to do their
own checking to see what value will work best on their hardware.

Put some short and generic recommendation in the makefile, and
then point people at a man page or some other documentation
for a more detailed explanation.  IMO.

--
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"