Re: c99 project
On 2013-02-04 21:48, Eitan Adler li...@eitanadler.com wrote: Is the following page still useful? Would there be any objection to me removing it? http://www.freebsd.org/projects/c99/index.html I think this is useful until we have full C99 support in at least one compiler toolchain. To the best of my knowledge this is not entirely true for either GCC or LLVM. So we should keep the page alive, until the project is done or canceled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
On Fri, Apr 27, 2012 at 11:18 PM, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Another point is that server installers are highly educated with respect to desktop installers and their numbers are small with respect to desktop users . For them , it is very easy to harden FreeBSD after installation if ever it is needed , because during installation , it is a simple question to ask : Will this be used as a Server ? Judging from the amount of effort it takes to harden a system that already starts a thousand services (typical desktop Linux scenario these days), and the number of times I've seen this sort of customization cause even more headaches, I'd say this is a slightly exaggerated statement. You are right that a plain user does not care about why their CD-ROM is not accessible after installation, but there are two different ways to approach this: - Install and enable everything by default, hoping that nothing bad happens when an unused service is exploitable. - Install a minimal system and build from there. Most Linux distributions pick the first option. _Some_ Linux distributions pick the second option (e.g. Gentoo). The default FreeBSD installation uses the second option. PC-BSD leans towards the first option, and does a really good job at making a BSD desktop 'accessible' to what is usually called the average user. So it all depends on what you want to do, and there _are_ options that cover both cases for either Linux or BSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
On Wed, May 2, 2012 at 2:33 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 05/02/12 04:55, Giorgos Keramidas wrote: Judging from the amount of effort it takes to harden a system that already starts a thousand services (typical desktop Linux scenario these days), and the number of times I've seen this sort of customization cause even more headaches, I'd say this is a slightly exaggerated statement. You might be thinking of SELinux, which is not the only option for hardening. Not really, no. I was referring to the practice of starting a gazillion services by default, including dbus, avahi, ftp and http services, file sharing components, and all the rest of the stuff that is now commonly installed as part of a Linux desktop. SELinux is indeed one form of hardening, but I wasn't referring specifically to it; exactly the opposite, in fact. You are right that a plain user does not care about why their CD-ROM is not accessible after installation, but there are two different ways to approach this: - Install and enable everything by default, hoping that nothing bad happens when an unused service is exploitable. - Install a minimal system and build from there. Most Linux distributions pick the first option. _Some_ Linux distributions pick the second option (e.g. Gentoo). You might be thinking of Gentoo Linux, rather than Gentoo. The term Gentoo also covers Gentoo/FreeBSD and Gentoo Prefix. Gentoo/FreeBSD replaces the Linux kernel and GNU userland with FreeBSD while Gentoo Prefix provides a userland package manager to UNIX-compatible systems: Gentoo Linux is what I was talking about. It's one of the distributions that does lean towards the install only what is necessary side of the spectrum. The main point is not whether Gentoo/Linux or Gentoo/BSD is the best color for the particular bikeshed though. It was that one _has_ the option both with Linux and BSD as a base to implement both types of installations. Hardening can be either an install-time property or an after-effect. It's really not OS-dependent at all. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: Diane Bruce d...@db.net wrote: There certainly would not be a chance of putting mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. This argument is actually a bit weak for most of the VCS'es out there (including svn by the way). We don't really *need* to import the full VCS itself into FreeBSD. For instance, Subversion is also not part of the base system. It works fine as a port that people can install. There's really _nothing_ wrong with a VCS that is a port/package. We used to have CVS into the base system as the official VCS, but this is no longer the case for the subversion repo of src/. IMO this hasn't really caused any major problem with the people who want to check out and patch the source tree. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] have rtprio check that arguments are numeric; change atoi to strtol
On Sun, 2 Jan 2011 18:46:47 -0500, Eitan Adler li...@eitanadler.com wrote:
What about this patch? I incorporated your feedback so I am not going
to reply inline.
Since the pattern of converting strings to int-derivative values appears
multiple times, I'd probably prefer something like a new function that
does the parsing *and* error-checking, to avoid duplication of errno
checks, invalidchar checks, and so on, e.g. something like this near the
top of rtprio.c:
#include errno.h
#include limits.h
#include string.h
/*
* Parse an integer from 'string' into 'value'. Return the first
* invalid character in 'endp', if endp is non-NULL. The return value
* of parseint is 0 on success, -1 for any parse error.
*/
int
parseint(const char *string, const char **endp, int base, int *value)
{
long x;
errno = 0;
x = strtol(string, endp, base);
if (errno != 0 || endp == str || (endp != NULL
endp != str *endp != '\0' (isdigit(*endp) == 0 ||
isspace(*endp) != 0)))
return -1;
if (x = INT_MAX) {
errno = ERANGE;
return -1;
}
return (int)x;
}
Then you can replace all the atoi() calls with:
int x;
if (parseint(argv[1], NULL, 0, x) != 0)
errx(1, your message);
which is a relatively cleaner way of handling strtol() parsing errors,
without the associated clutter of checking properly all possible edge
cases at every call-point.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] have rtprio check that arguments are numeric; change atoi to strtol
On Tue, 04 Jan 2011 11:36:38 +0100, Giorgos Keramidas keram...@freebsd.org
wrote:
On Sun, 2 Jan 2011 18:46:47 -0500, Eitan Adler li...@eitanadler.com wrote:
What about this patch? I incorporated your feedback so I am not going
to reply inline.
Since the pattern of converting strings to int-derivative values appears
multiple times, I'd probably prefer something like a new function that
does the parsing *and* error-checking, to avoid duplication of errno
checks, invalidchar checks, and so on, e.g. something like this near the
top of rtprio.c:
#include errno.h
#include limits.h
#include string.h
/*
* Parse an integer from 'string' into 'value'. Return the first
* invalid character in 'endp', if endp is non-NULL. The return value
* of parseint is 0 on success, -1 for any parse error.
*/
int
parseint(const char *string, const char **endp, int base, int *value)
{
long x;
errno = 0;
x = strtol(string, endp, base);
if (errno != 0 || endp == str || (endp != NULL
endp != str *endp != '\0' (isdigit(*endp) == 0 ||
isspace(*endp) != 0)))
return -1;
if (x = INT_MAX) {
errno = ERANGE;
return -1;
}
return (int)x;
}
instead of `return (int)x' the last bits should be slightly different,
of course:
if (value != NULL)
*value = (int)x;
return 0;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] have rtprio check that arguments are numeric; change atoi to strtol
On Tue, 4 Jan 2011 13:25:02 +0200, Kostik Belousov kostik...@gmail.com wrote:
On Tue, Jan 04, 2011 at 11:40:45AM +0100, Giorgos Keramidas wrote:
On Tue, 04 Jan 2011 11:36:38 +0100, Giorgos Keramidas keram...@freebsd.org
wrote:
Since the pattern of converting strings to int-derivative values appears
multiple times, I'd probably prefer something like a new function that
does the parsing *and* error-checking, to avoid duplication of errno
checks, invalidchar checks, and so on, e.g. something like this near the
top of rtprio.c:
/*
* Parse an integer from 'string' into 'value'. Return the first
* invalid character in 'endp', if endp is non-NULL. The return
value
* of parseint is 0 on success, -1 for any parse error.
*/
int
parseint(const char *string, const char **endp, int base, int
*value)
...
}
Well, I think it shall be simplified. What about this ?
This looks much better than plain strtol() calls. Thanks :)
diff --git a/usr.sbin/rtprio/rtprio.c b/usr.sbin/rtprio/rtprio.c
index 245f714..fc212b5 100644
--- a/usr.sbin/rtprio/rtprio.c
+++ b/usr.sbin/rtprio/rtprio.c
@@ -37,31 +37,31 @@ __FBSDID($FreeBSD$);
#include sys/param.h
#include sys/rtprio.h
-#include sys/errno.h
#include ctype.h
#include err.h
+#include errno.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
-static void usage();
+static int parseint(const char *, const char *);
+static void usage(void);
int
-main(argc, argv)
- int argc;
- char **argv;
+main(int argc, char *argv[])
{
- char *p;
- int proc = 0;
struct rtprio rtp;
+ char *p;
+ pid_t proc;
/* find basename */
if ((p = rindex(argv[0], '/')) == NULL)
p = argv[0];
else
++p;
+ proc = 0;
if (!strcmp(p, rtprio))
rtp.type = RTP_PRIO_REALTIME;
@@ -70,12 +70,12 @@ main(argc, argv)
switch (argc) {
case 2:
- proc = abs(atoi(argv[1])); /* Should check if numeric
- * arg! */
+ proc = parseint(argv[1], pid);
+ proc = abs(proc);
/* FALLTHROUGH */
case 1:
if (rtprio(RTP_LOOKUP, proc, rtp) != 0)
- err(1, %s, argv[0]);
+ err(1, RTP_LOOKUP);
printf(%s: , p);
switch (rtp.type) {
case RTP_PRIO_REALTIME:
@@ -103,19 +103,17 @@ main(argc, argv)
usage();
break;
}
- } else {
- rtp.prio = atoi(argv[1]);
- }
+ } else
+ rtp.prio = parseint(argv[1], priority);
} else {
usage();
break;
}
if (argv[2][0] == '-')
- proc = -atoi(argv[2]);
-
+ proc = parseint(argv[2] + 1, pid);
if (rtprio(RTP_SET, proc, rtp) != 0)
- err(1, %s, argv[0]);
+ err(1, RTP_SET);
if (proc == 0) {
execvp(argv[2], argv[2]);
@@ -123,12 +121,28 @@ main(argc, argv)
}
exit(0);
}
- exit (1);
+ exit(1);
+}
+
+static int
+parseint(const char *str, const char *errname)
+{
+ char *endp;
+ long res;
+
+ errno = 0;
+ res = strtol(str, endp, 10);
+ if (errno != 0 || endp == str || *endp != '\0')
+ err(1, %s shall be a number, errname);
+ if (res = INT_MAX)
+ err(1, Integer overflow parsing %s, errname);
+ return (res);
}
static void
-usage()
+usage(void)
{
+
(void) fprintf(stderr, %s\n%s\n%s\n%s\n%s\n%s\n,
usage: [id|rt]prio,
[id|rt]prio [-]pid,
pgp01wK7MOYI9.pgp
Description: PGP signature
Re: [patch] have rtprio check that arguments are numeric; change atoi to strtol
On Tue, 4 Jan 2011 08:58:48 -0800, Garrett Cooper yaneg...@gmail.com wrote: + errno = 0; + res = strtol(str, endp, 10); + if (errno != 0 || endp == str || *endp != '\0') + err(1, %s shall be a number, errname); Small nit, maybe use 'must' instead of 'shall'. it seems at some point there has been a massive usage of the term 'shall' in manual pages, which people tried to get rid of. hence the 'usr/share/examples/mdoc/deshallify.sh' script. I know shall is used widely by opengroup when describing definitions and interfaces in the POSIX standards, but the connotation in English is very squishy, so I agree with John that must would be better. BTW, only if errno was non-zero would using err(3) be logical. Otherwise it will just produce noise :). That's a good point. I think we should change err() to errx() there. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] have rtprio check that arguments are numeric; change atoi to strtol
On Sun, 2 Jan 2011 12:18:45 +0200, Kostik Belousov kostik...@gmail.com wrote:
On Sun, Jan 02, 2011 at 02:41:10AM -0500, Eitan Adler wrote:
Just set the second argument to strtol to something non-NULL and then check
the value returned; that will help provide the error handling with
simplicity that you desire :).
How about this version? It also corrects a copy/paste error I have above
Index: rtprio.c
===
--- rtprio.c (revision 216679)
+++ rtprio.c (working copy)
@@ -56,6 +56,7 @@
char *p;
int proc = 0;
struct rtprio rtp;
While there, you may change the type of proc to pid_t.
Also, move the initialization of proc out of local declaration section,
according to style(9).
+ char *invalidChar;
We do not use camelCase, according to style(9).
/* find basename */
if ((p = rindex(argv[0], '/')) == NULL)
@@ -70,8 +71,9 @@
switch (argc) {
case 2:
- proc = abs(atoi(argv[1])); /* Should check if numeric
- * arg! */
+ proc = abs((int)strtol(argv[1], invalidChar, 10));
Why is the cast needed there ?
Also, I think that doing
proc = strtol();
if (*invalid_char ...)
...;
proc = abs(proc);
It's quite surprising how easy it is to use strtol() in an allegedly
safe manner, but miss some of the edge cases. We should probably check
for errno too, e.g.:
#include errno.h
#include string.h
#include stdlib.h
pid_t proc;
long x;
char *endp;
errno = 0;
x = strtol(argv[1], endp, 0);
if (errno != 0 || (endp != NULL endp != str *endp != '\0'
(isdigit(*endp) == 0 || isspace(*endp) == 0)))
error();
Then if we want to avoid overflows of pid_t, we might have to check
against PID_MAX or at least INT32_MAX. The sizeof(pid_t) is __int32_t
on all FreeBSD architectures, so it may be useful to check for:
if (x = INT32_MAX)
error();
proc = (pid_t)x;
But this is probably being too paranoid now.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deterministic builds?
On Mon, 15 Nov 2010 12:56:29 +0100, Erik Cederstrand e...@cederstrand.dk wrote: Den 15/11/2010 kl. 12.40 skrev Tom Evans: The important things for us are that given a binary, you should be able to easily reproduce the source environment that the binary was produced from, and any two binaries produced from the same sources should be identical. I'm leaning towards not even recording the svn rev. within the binary. A commit only changing comments or style(9) would not change the bits of the binary, but the differing revision number would. A solution could be to have an external file, e.g. /etc/kernel-buildinfo and /etc/world-buildinfo, containing the output of svn stat, svn diff, src.conf, make.conf, SRCDIR and OBJDIR locations, the full buildworld/kernel command and whatever else could affect the build outcome. A few other things that may affect the binaries produced are: * Runtime shell environment (CFLAGS etc.) * make -j JOBS count * the value of -frandom-seed=STRING (see NetBSD's build.sh script and `3.9 Options for Debugging Your Program or GCC' in the gcc.info docs) If we are to record all these in the resulting binary snapshot of build output, then it may be possible to fully reproduce the *exact* set of binaries from a given source tree, but 'perfect' may be the enemy of the good-enough solution. pgpFKtRpaRTsA.pgp Description: PGP signature
Re: Deterministic builds?
On Sun, 14 Nov 2010 21:22:53 +0100, Erik Cederstrand e...@cederstrand.dk wrote: Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas: Since the SVN rev. is recorded, I think a timestamp is redundant. Any ideas where I can disable the timestamps in the source? The timestamp is not 'redundant'. It records _when_ you compiled the sources of the kernel, which in itself is a useful bit of information. I'm curious as to why this might be useful? Would the mtime of the file not be be sufficient? I can only think of debugging purposes, but apart from the timestamp, two kernels with the same rev. would be bitwise identical, so I think the rev. number is more useful. Is the timestamp not just a remnant from the CVS days? The timestamp is a remnant from much older days, but it's still a bit useful if you build several kernels from 'almost' the same source tree. For example, think of two kernels who are built from the same svn revision but they are built from two different patched kernel source trees. They will both have a version string that says svn 12345+ but their + will refer to different patch states. When a kernel developer is trying various iterations of this own local patch, having the timestamp may actually be useful to differentiate between a working and a non-working patch state. I *like* the idea of 100% repeatable kernel builds and I'd even go as far as suggesting it is nice to turn on by *default*, but let's think about a way to _include_ the timestamp e.g. with an src.conf option for those cases when it's really useful. pgpn7MvxgD8SB.pgp Description: PGP signature
Re: Deterministic builds?
On Fri, 12 Nov 2010 15:13:36 +0100, Erik Cederstrand e...@cederstrand.dk wrote: Den 22/10/2010 kl. 12.01 skrev Ulrich Spörlein: Why do you make this a requirement? Of course it's usually easier to build different releases from different source directories, but I think requiring the following conditions are fine: 1. If you build a specific svn revision, 2. sitting in /usr/src with 3. the default make.conf (ie., no special flags, no frobbing of OBJDIR) 4. at different times then you get the same binaries. Let's start with an achievable, not-so-intrusive goal, right? :) Ok, here's a new attempt with SRCDIR and OBJDIR constant between the two builds. This time, /boot/kernel/kernel, /boot/loader, /boot/pxeboot and /boot/zfsloader differ. According to strings(1), the only difference is the timestamp. E.g. the kernel: @(#)FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 22:58:34 CET 2010 FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 22:58:34 CET 2010 --- @(#)FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 23:29:17 CET 2010 FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 23:29:17 CET 2010 Since the SVN rev. is recorded, I think a timestamp is redundant. Any ideas where I can disable the timestamps in the source? The timestamp is not 'redundant'. It records _when_ you compiled the sources of the kernel, which in itself is a useful bit of information. We could probably get away with making it an option though, e.g. in src.conf(5) something that defaults to 'yes': WITH_KERNEL_TIMESTAMP='yes' Then if it's the only remaining bit of information that changes between two subsequent builds of precisely the same tree one can set it to 'no' or overload it under WITH_REPEATABLE_BUILDS='yes' or similar. FYI, have a look at src/conf/newvers.sh for the place where this information is gathered at kernel-build time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: building world with debugging symbols
On Tue, 30 Mar 2010 15:10:58 -0400, John Baldwin j...@freebsd.org wrote: On Tuesday 30 March 2010 11:48:58 am Giorgos Keramidas wrote: +.It Va DEBUG_FLAGS +Defines a set of debugging flags that will be used to build all userland +binaries under +.Pa /usr/src . +When +.Va DEBUG_FLAGS +is defined, the +.Cm install +and +.Cm installworld +targets install binaries from the current +.Va MAKEOBJDIRPREFIX +without stripping too, so that debugging information is retained in the +installed binaries. I would drop the too and start 'so' on a new line (at least that is my interpretation of the line-break rules we use for mdoc). Other than that I think this looks fine. Fixed and committed in r205978. Thanks :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: building world with debugging symbols
On Fri, 05 Mar 2010 18:15:33 +0100 (CET), Alexander Best alexbes...@wwu.de wrote: DEBUG_FLAGS=-g ahh. thanks for the hint. with DEBUG_FLAGS i was able to build world with debugging symbols but also managed to keep the bootloader small enough. i don't think this option is documented anywhere or is it? It's not documented in the obvious place I'd look for it: the build(7) manpage. Does the following look ok? %%% diff -r 236fcd32a358 share/man/man7/build.7 --- a/share/man/man7/build.7Sun Mar 28 00:46:10 2010 +0200 +++ b/share/man/man7/build.7Tue Mar 30 18:48:16 2010 +0300 @@ -24,7 +24,7 @@ .\ .\ $FreeBSD$ .\ -.Dd December 15, 2009 +.Dd March 30, 2010 .Dt BUILD 7 .Os .Sh NAME @@ -311,6 +311,20 @@ should be set as with .Sh ENVIRONMENT Variables that influence all builds include: .Bl -tag -width .Va MAKEOBJDIRPREFIX +.It Va DEBUG_FLAGS +Defines a set of debugging flags that will be used to build all userland +binaries under +.Pa /usr/src . +When +.Va DEBUG_FLAGS +is defined, the +.Cm install +and +.Cm installworld +targets install binaries from the current +.Va MAKEOBJDIRPREFIX +without stripping too, so that debugging information is retained in the +installed binaries. .It Va DESTDIR The directory hierarchy prefix where built objects will be installed. If not set, %%% pgppLcr7A9zzy.pgp Description: PGP signature
Re: Building FreeBSD on a linux FC11 box.
On Sun, 21 Feb 2010 21:22:51 +0100, Ulrich Spörlein u...@freebsd.org wrote: On Sat, 20.02.2010 at 13:03:14 -0800, R. Tyler Ballance wrote: You might want to ask the Debian GNU/kFreeBSD guys: http://www.debian.org/ports/kfreebsd-gnu/ I bet they've got a good idea :) They are using the kernel only, though. Before you reinvent the wheel, take a look at NetBSD, they are known for their cross-compilation work. It's non-trivial to set up a NetBSD-like cross-compilation environment, but the bits you have to use are well-documented in the support of the NetBSD source tree for 'tools'. I've experimented a bit with some of the work that's needed and it includes at least the following: * mtree -- This is used by parts of the build glue to set up build-time directories. * make -- Targetting *all* possible platforms with BSD make is probably not worth the effort, but adding a minimal configure.in script that can produce an 'fbmake' binary suitable for cross building FreeBSD is doable and not very hard. With these two in place and a bit of Makefile target hacking it might be possible to cross-build FreeBSD on e.g. Linux. I don't have a Linux machine anymore, but if someone starts doing this I can probably set one up and test any patches. pgp9dzGlvZPH1.pgp Description: PGP signature
Re: debug libraries
On Thu, 25 Feb 2010 11:09:36 -0800 (PST), Dr. Baud drb...@yahoo.com wrote: Apologies if this is the wrong list Are there prepackaged debug versions of the system libraries available (like 'yum install *-debuginfo' in Fedora and 'apt-get install *-dbg' in Ubuntu)? No, not really. You can always build a base system *with* debugging symbols from source though. Naturally, this is not as fast to install as a small set of pre-built packages, but it is at least possible. For example, my laptop runs a base system _with_ debugging symbols most of the time. To rebuild everything I made the following changes to my '/etc/make.conf' file: 1. I enabled the DEBUG_FLAGS option, by adding the following: DEBUG_FLAGS ?= -g 2. I checked that I am not using high optimization levels in CFLAGS or COPTFLAGS. 3. I enabled the NO_CPU_CFLAGS and NO_CPU_COPTFLAGS options: NO_CPU_CFLAGS= # Don't add -march=cpu to CFLAGS automatically NO_CPU_COPTFLAGS= # Don't add -march=cpu to COPTFLAGS automatically Then I rebuilt everything from my latest source tree at /usr/src. The combined effect of NO_CPU_CFLAGS and DEBUG_FLAGS is that binaries are not stripped before they are installed, and optimization flags are not added automatically by the build system. Note #1. The resulting binaries are *much* larger. For example the ed(1) editor in unstripped format is 123 KB on my laptop, but stripping it reduces its size down to 48 KB: keram...@kobe:/tmp$ ls -ld /bin/ed -r-xr-xr-x 2 root wheel - 123663 16 Φεβ 12:25 /bin/ed keram...@kobe:/tmp$ cp -a /bin/ed ed keram...@kobe:/tmp$ sudo strip -s ed keram...@kobe:/tmp$ ls -ld ed -r-xr-xr-x 1 keramida wheel - 48400 26 Φεβ 17:24 ed The effect of enabling debugging flags for larger programs like gcc, gdb or bind is much much larger than ed(1) of course. Note #2. There's probably a measurable performance hit by running a debugging base system, because -O2 optimizations do not get a chance to do their magic as you build your binaries. HTH, Giorgos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Weekend PR smashing
On Sun, 17 Jan 2010 13:30:50 -0800, R. Tyler Ballance ty...@monkeypox.org wrote: Are there similar resources I've not stumbled across yet? I would like to help, I have but one machine running -CURRENT and sporadic free time over the weekends. Hi there. I just noticed this post in among others in -hackers. If you don't know about the bugbuster team already, you should check it out. There's a mailing list at freebsd-bugbusters and an IRC channel at the EFnet network. Since you are looking for pointers to get you started, the following may help a bit: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ Finally, it's worth noting that it is not a huge problem if you only have weekend-time to contribute. We welcome all the help we can get, so please feel free to jump in and help in any way you can with the existing bugs (or new ones that you have noticed). pgpfEwVGtOxWD.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
On Thu, 10 Dec 2009 13:42:22 +0100, Ed Schouten e...@80386.nl wrote: Hello Alexander, others, * Alexander Leidinger alexan...@leidinger.net wrote: The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. So the idea is to make TERM=xterm use 256 colors? Even though I think having more colors would be awesome, I think many things would break. How about an xterm entry with 8 fg and 8 bg colors and a separate xterm-256color entry with 256 colors? I know, from our personal chat sessions, that the original drive behind Leonidas' patch to termcap was to make it possible for Emacs and vim to highlight/format code with more than 8 colors. This *is* useful for X11-based xterm windows but it may be less useful for vty terminals. pgpUoViQjf9bX.pgp Description: PGP signature
Re: [patch] burncd: honour for envar SPEED
On Mon, 09 Nov 2009 11:00:43 +0100, Dag-Erling Smørgrav d...@des.no wrote: Giorgos Keramidas keram...@ceid.upatras.gr writes: atoi() doesn't really have error checking and it does not necessarily affect `errno'. man 3 expand_number I know, but thanks. In this case, expand_number's logic for parsing possible SI suffixes is not useful and may be slightly confusing. I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option, for example. And please don't call it SPEED or WRITE_SPEED or anything generic; call it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar used to specify the device is called CDROM, not DEVICE. Good point. pgp27FxReZQoN.pgp Description: PGP signature
Re: [patch] burncd: honour for envar SPEED
On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best alexbes...@wwu.de
wrote:
Giorgos Keramidas schrieb am 2009-11-09:
Hi Alexander,
The idea seems very good, but since the value of SPEED is user
supplied data, I would rather see a bit of validation code after
getenv(). With this version of the patch, burncd would happily
accept and try to use values that are quite absurd, i.e.:
env SPEED=12234567890 burncd ...
It may also be sensible to do the translation from human readable
speed values and the multiplication with 177 _after_ the value has
been parsed from getenv(), so that e.g. one can write:
env SPEED=4 burncd
and get behavior similar to the current default.
i don't quite get why the value supplied with the envar has to be
validated. if the user supplies a speed value using the -s switch no
validation (except = 0) is being performed either.
This is probably me being paranoid. I'd prefer *both* places to check
the supplied value for invalid values, even if the check is something
like negative numbers are not ok.
also i think there's a speed check in the atapi code. if the speed
requested is the maximum driver speed it gets set to the maximum
driver speed automatically.
If the capping happens automatically we're fine. From a cursory look at
the kernel sources this morning, I didn't manage to find a speed-range
check in sys/dev/ata. The acd_set_speed() code is a small function:
: static int
: acd_set_speed(device_t dev, int rdspeed, int wrspeed)
: {
: int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed 8, rdspeed,
:wrspeed 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
: int error;
:
: error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30);
: if (!error)
: acd_get_cap(dev);
: return error;
: }
and that's all. It probably relies on the hardware to cap the speed,
but I am not very familiar with the rest of the ATA code to be sure.
Your patch is fine, but as a followup commit I'd probably like seeing
atoi() go away. AFAICT, it currently allows invalid speed values,
defaulting to speed=0 when a user types:
burncd -s foobar [options ...]
We can fix that later though :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] burncd: honour for envar SPEED
On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best alexbes...@wwu.de
wrote:
Giorgos Keramidas schrieb am 2009-11-09:
i don't quite get why the value supplied with the envar has to be
validated. if the user supplies a speed value using the -s switch
no validation (except = 0) is being performed either.
This is probably me being paranoid. I'd prefer *both* places to
check the supplied value for invalid values, even if the check is
something like negative numbers are not ok.
also i think there's a speed check in the atapi code. if the speed
requested is the maximum driver speed it gets set to the maximum
driver speed automatically.
Your patch is fine, but as a followup commit I'd probably like seeing
atoi() go away. AFAICT, it currently allows invalid speed values,
defaulting to speed=0 when a user types:
burncd -s foobar [options ...]
We can fix that later though :)
ok. so do you think this patch is sufficient then? once committed i'll
see if i can add some extra validation to the envar as well as the -s
switch and will also have a look at the validation the ATA code is
doing atm.
Yes, the patch attached below is fine, and IMO it would be ok to commit
it, minus a couple of tiny details: sorting the BURNCD_SPEED environment
variable before the current CDROM item in the manpage, and bumping the
manpage modification date near .Dd to today.
%%%
Index: usr.sbin/burncd/burncd.8
===
--- usr.sbin/burncd/burncd.8(revision 199064)
+++ usr.sbin/burncd/burncd.8(working copy)
@@ -164,6 +164,12 @@
.Fl f
flag.
.El
+.Bl -tag -width .Ev BURNCD_SPEED
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
+.El
.Sh FILES
.Bl -tag -width .Pa /dev/acd0
.It Pa /dev/acd0
Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c(revision 199064)
+++ usr.sbin/burncd/burncd.c(working copy)
@@ -80,11 +80,20 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;
if ((dev = getenv(CDROM)) == NULL)
dev = /dev/acd0;
+ if ((env_speed = getenv(BURNCD_SPEED)) != NULL) {
+ if (strcasecmp(max, env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed = 0)
+ errx(EX_USAGE, Invalid speed: %s, env_speed);
+ }
+
while ((ch = getopt(argc, argv, def:Flmnpqs:tv)) != -1) {
switch (ch) {
case 'd':
%%%
pgp5BQPCQ7Jo2.pgp
Description: PGP signature
Re: [patch] burncd: honour for envar SPEED
On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best
alexbes...@math.uni-muenster.de wrote:
any thoughts on these small changes to burncd?
Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -78,13 +78,16 @@
{
int arg, addr, ch, fd;
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
- int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
+ int nogap = 0, speed = 0, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
const char *dev;
if ((dev = getenv(CDROM)) == NULL)
dev = /dev/acd0;
+ if ((speed = getenv(SPEED)) == NULL)
+ speed = 4 * 177;
+
while ((ch = getopt(argc, argv, def:Flmnpqs:tv)) != -1) {
switch (ch) {
case 'd':
Hi Alexander,
The idea seems very good, but since the value of SPEED is user supplied
data, I would rather see a bit of validation code after getenv(). With
this version of the patch, burncd would happily accept and try to use
values that are quite absurd, i.e.:
env SPEED=12234567890 burncd ...
It may also be sensible to do the translation from human readable
speed values and the multiplication with 177 _after_ the value has been
parsed from getenv(), so that e.g. one can write:
env SPEED=4 burncd
and get behavior similar to the current default.
pgpl1Dl1ze7nw.pgp
Description: PGP signature
Re: [patch] burncd: honour for envar SPEED
On Mon, 09 Nov 2009 02:22:36 +0100 (CET), Alexander Best
alexbes...@math.uni-muenster.de wrote:
--- burncd.c.typo 2009-11-09 02:19:47.0 +0100
+++ burncd.c 2009-11-09 02:20:27.0 +0100
@@ -85,8 +85,8 @@
if ((dev = getenv(CDROM)) == NULL)
dev = /dev/acd0;
- if ((env_speed = getenv(WRITE_SPEED)) != NULL)
- if (strcasecmp(max, getenv) == 0)
+ if ((env_speed = getenv(WRITE_SPEED)) != NULL) {
+ if (strcasecmp(max, env_speed) == 0)
speed = CDR_MAX_SPEED;
else
speed = atoi(env_speed) * 177;
atoi() doesn't really have error checking and it does not necessarily
affect `errno'. I'd probably prefer something that uses strtoul() and a
few more value/range checks, i.e.:
: #include limits.h
: #include string.h
:
: {
: char *endp;
: long xspeed;
:
: speed = 4 * 177;
: if ((env_speed = getenv(SPEED)) != NULL) {
: if (strcasecmp(max, env_speed) == 0) {
: speed = CDR_MAX_SPEED;
: } else {
: end = NULL;
: errno = 0;
: xspeed = strtol(env_speed, endp, 0);
: if (errno != 0 || (endp != NULL endp != str
: *endp != '\0' (isdigit(*endp) != 0 ||
: isspace(*endp) == 0)))
: err(1, invalid write speed: %s, env_speed);
: if (xspeed 0 || xspeed INT_MAX)
: err(1, write speed out of range: %ld,
xspeed);
: speed = (int)xspeed * 177;
: }
: }
: }
pgpIw3IMiex7c.pgp
Description: PGP signature
Re: Make process title - % complete
On Mon, 19 Oct 2009 17:51:42 +0200, Ivan Voras ivo...@freebsd.org wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: How about add this statistic to make info handler? You mean SIGINFO? Yes, that's the ``info handler''. While printing something on SINGINFO arrival is a nice idea, it may not be extremely useful for make(1). With dd(1) this is very useful to see, but with long-running make jobs that write tons of output to stderr any information from SIGINFO may be lost in the noise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Make process title - % complete
On Tue, 20 Oct 2009 20:28:40 -0400, Boris Kochergin sp...@acm.poly.edu wrote: Giorgos Keramidas wrote: On Mon, 19 Oct 2009 17:51:42 +0200, Ivan Voras ivo...@freebsd.org wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: How about add this statistic to make info handler? You mean SIGINFO? Yes, that's the ``info handler''. While printing something on SINGINFO arrival is a nice idea, it may not be extremely useful for make(1). With dd(1) this is very useful to see, but with long-running make jobs that write tons of output to stderr any information from SIGINFO may be lost in the noise. The SIGINFO handler could be made to put the make process to sleep for, say, a second to give the user some time to read the statistics, but I'm sure there are lots of objections to be made to that, too. That would be bad, indeed. David Wolfskill has emailed me, in the meantime, that it's probably ok to `lose' SIGINFO output in the noise of build output, as long as it is easy to grep for it. So I still like the idea, but without a delay please :) pgpF8p6C0GJbo.pgp Description: PGP signature
Re: llvm/clang a tool chain or just a compiler for FreeBSD?
On Wed, 22 Jul 2009 19:05:47 +0300, Kostik Belousov kostik...@gmail.com wrote: I know some ports using USE_GCC knob of /usr/ports/Mk/bsd.gcc.mk . Is this the same as you suggest? No. And this was actually not my idea. The proposal is to have portmgr-selected and approved version of gcc, installed from port and used to build ports. The base (g)cc is used only to build base. Such divorce seems to be beneficial both to base compiler, and for ports. ISTR this is what pkgsrc does. It isn't a very bad idea, and it may give ports/ a bit of freedom about the version of the compiler they can use for special OPTIONS= items like SSE instruction optimizations and so on. pgpYOSYxSuSfR.pgp Description: PGP signature
Re: distributed scm+freebsd svn?
local commit that affected a file, i.e. my local `usr.sbin/chown/chown.c' changes. First you'd have to look at the local history of the file: keram...@kobe:/hg/bsd/src$ hg log --style compact usr.sbin/chown/chown.c 12010:11998,12009 7f4fa839afed 2009-06-20 00:50 +0300 keramida Merge from head 12002 96e04082ef3f 2009-06-19 15:58 + brooks In preparation for raising NGROUPS and NGROUPS_MAX, change base 7782 141cd5ffef80 2009-01-22 07:18 +0200 keramida Add a new -x option to chown and chgrp, to inhibit file system 0 dd5ed0412a8b 2007-12-31 22:03 + jhb Actually declare the kern.features sysctl node. keram...@kobe:/hg/bsd/src$ From this output it's obvious my local changes were made on 2009-01-22 07:18 +0200, and they are available as changeset 7782:141cd5ffef80. You can extract this changeset only with hg export: keram...@kobe:/hg/bsd/src$ hg export 141cd5ffef80 # HG changeset patch # User Giorgos Keramidas keram...@ceid.upatras.gr # Date 1232601528 -7200 # Branch head # Node ID 141cd5ffef80ff979627d8898500c92984287426 # Parent e8506b2ac7aefbfb875f0def0de8dd6441885a40 Add a new -x option to chown and chgrp, to inhibit file system mount point traversal. The -x option is documented, like -v, as a non-standard option in the COMPATIBILITY manpage sections. diff -r e8506b2ac7ae -r 141cd5ffef80 usr.sbin/chown/chgrp.1 --- a/usr.sbin/chown/chgrp.1Wed Jan 21 21:31:33 2009 +0200 +++ b/usr.sbin/chown/chgrp.1Thu Jan 22 07:18:48 2009 +0200 @@ -31,7 +31,7 @@ .\ @(#)chgrp.18.3 (Berkeley) 3/31/94 .\ $FreeBSD$ .\ -.Dd April 25, 2003 +.Dd January 22, 2009 .Dt CHGRP 1 .Os .Sh NAME @@ -39,7 +39,7 @@ .Nd change group .Sh SYNOPSIS .Nm -.Op Fl fhv +.Op Fl fhvx .Oo .Fl R ... snip ... This patch is _directly_ usable with `patch -p1' in a checkout of /head from Subversion, but it *may* require a bit of `svn merge' work if you have fast-forwarded chown/chgrp to its latest 'head' version. It is not a diff of the *latest* chown/chgrp from /head but a _precise_ copy of the past changeset, as it was committed. More... === * You can browse the 'clean' head/ copy I am using at http://hg.hellug.gr/freebsd/head/ Note: this only has the head history since 2007-12-31. For older head commits, you will have to use a new convert run and it will change all the commit/changeset hashes even if their patch data is identical. * You can find a compressed 'bundle' file called 'head.hg' in my home directory at freefall. This can be used to 'seed' the initial copy of your local 'head', eg. by pulling directly from the bundle: % cd /var/tmp % scp freefall.freebsd.org:'~keramida/head.hg' . % cd ~ % mkdir -p ~/work/freebsd/head % hg init ~/work/freebsd/head % cd ~/work/freebsd/head % hg pull /var/tmp/head.hg * If you plan to use the incremental conversion script I described earlier in this message, you will also need a SHA map file that maps Subversion changesets to Mercurial changeset hashes. This is also available at freefall as `~keramida/head.shamap' and you have to copy it to your `head/.hg/shamap' file. Then either run the hg convert extension manually or use a small shell wrapper like the one I pasted here. * For more information about some of the extensions I've mentioned it is always a good idea to check the Mercurial Wiki at: http://www.selenic.com/mercurial/ I hope all this helps a bit... If you need more help with publishing local workspaces over http and/or extracting patches (these are often two of the points where help is necessary and welcome), please feel free to ask. I've been using this sort of workflow for local changesets quite some time and I know enough about Mercurial to help where needed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: can we afford an extra column in iostat?
On Tue, 14 Jul 2009 14:55:15 -0700, Brian Somers br...@freebsd.org wrote: On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas keram...@freebsd.org wrote: While converting my laptop's main disk to zfs, I noticed iostat output like this (bits copied from here and there): | keram...@kobe:/home/keramida$ iostat -w3 ad0 da0 | tty ad0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id |5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 |0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 |012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 |050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 [.] | $ ./iostat -w2 | tty ad0 md0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id |7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 |0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 |0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 |0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 | ^C The patch that changes this is quite small: This should be fixed. Ironically, the only people that usually have problems with fixes like this are people that have seen the fields merge and have adjusted some script to understand column widths! Yes, that's a bit unfortunate. I'm ok with keeping this in 8.X only for this reason alone, but I would prefer if it was eventually MFCd. I'll ask re@ if they are ok with committing this now in head. Thanks :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
can we afford an extra column in iostat?
While converting my laptop's main disk to zfs, I noticed iostat output
like this (bits copied from here and there):
| keram...@kobe:/home/keramida$ iostat -w3 ad0 da0
| tty ad0 da0 cpu
| tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
|5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89
|0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15
|012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4
|050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20
| 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16
| 33835534 7.61 211 1.57 7.31 295 2.11 36 0 55 1 9
| 38636874 3.10 186 0.56 6.63 309 2.00 37 0 56 0 7
| 24239726 2.54 196 0.49 6.13 336 2.01 36 0 56 0 8
| 17136654 0.57 192 0.11 7.97 305 2.37 34 0 56 0 9
| 23439020 0.76 195 0.15 7.02 333 2.28 32 0 57 1 11
| 43733189 2.52 192 0.47 6.99 269 1.84 37 0 57 1 5
| 36232178 5.48 193 1.03 6.78 268 1.77 38 0 54 0 8
| 43226266 34.19 228 7.61 6.94 253 1.72 32 0 49 1 19
The default output of iostat, when no disks are specified is a bit wider
than this, reaching column 75 here:
1 2 3 4 5 6 7
12345678901234567890123456789012345678901234567890123456789012345678901234567890
---
tty ad0 md0 da0 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
6 2315 34.97 58 1.99 6.46 0 0.00 47.41 8 0.37 4 0 8 0 88
But there's still a bit of space before column 80, so can we afford an
extra space between tin/tout to make the output look more like this?
| $ ./iostat -w2
| tty ad0 md0 da0 cpu
| tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
|7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87
|0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9
|0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9
|0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17
| ^C
The patch that changes this is quite small:
%%%
diff -r 0f182a7399e8 usr.sbin/iostat/iostat.c
--- a/usr.sbin/iostat/iostat.c Sun Jul 12 09:34:48 2009 +0300
+++ b/usr.sbin/iostat/iostat.c Tue Jul 14 07:20:41 2009 +0300
@@ -586,7 +586,7 @@
}
if (xflag == 0 Tflag 0)
- printf(%4.0Lf%5.0Lf, cur.tk_nin / etime,
+ printf(%4.0Lf %5.0Lf, cur.tk_nin / etime,
cur.tk_nout / etime);
devstats(hflag, etime, havelast);
@@ -696,7 +696,7 @@
(void)printf(\n);
if (Tflag 0)
- (void)printf( tin tout);
+ (void)printf( tin tout);
for (i=0, printed = 0;(i num_devices) (printed maxshowdevs);i++){
if ((dev_select[i].selected != 0)
@@ -754,7 +754,7 @@
device r/i w/ikr/ikw/i wait svc_t %%b
);
if (Tflag 0)
- printf(tin tout );
+ printf(tin tout );
if (Cflag 0)
printf(us ni sy in id );
printf(\n);
@@ -895,7 +895,7 @@
*/
printf(%52s,);
if (Tflag 0)
- printf(%4.0Lf%5.0Lf, cur.tk_nin / etime,
+ printf(%4.0Lf %5.0Lf, cur.tk_nin / etime,
cur.tk_nout / etime);
if (Cflag 0)
cpustats();
%%%
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
On Tue, 30 Jun 2009 20:21:03 +0200 (CEST), Alexander Best alexbes...@math.uni-muenster.de wrote: thanks. now the output gets redirected using . i'm quite new to programming under unix. sorry for the inconvenience. so i guess there is no really easy way to output an inhomogeneous struct to stdout without using a loop to output each array contained in the struct. No not really. You have to do the sizeof() dance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: c question: *printf'ing arrays
On Wed, 01 Jul 2009 00:06:05 +0200 (CEST), Alexander Best
alexbes...@math.uni-muenster.de wrote:
thanks for all the help. i decided to take the pill and coded all the
fprintfs by hand. here's the result. usually i'd stick to a higher
level languag, but i need C's inline assembly support:
struct Header
{
u_int8_t rom_entry[4];
u_int8_t nintendo_logo[156];
...
fprintf(stderr, \nNintendo Logo: 0x);
for (i=0; i sizeof(hdr-nintendo_logo); i++)
fprintf(stderr, %x, hdr-nintendo_logo[i]);
Note that %x will only print *one* digit for values smaller than 16,
i.e. printf(%x, 10) = a, so it may be useful to use %02x instead.
fprintf(stderr, \nFixed Value: 0x);
fprintf(stderr, %x, hdr-fixed_val);
For multi-byte fields, it makes sense to print 0x first and then
iterate. For single-byte values, it's probably a tiny bit faster to go
only _once_ through for *printf() family formatter, i.e.:
- fprintf(stderr, \nFixed Value: 0x);
- fprintf(stderr, %x, hdr-fixed_val);
+ fprintf(stderr, \nFixed Value: 0x%x, hdr-fixed_val);
Another nit that I noticed is that your last line doesn't end with \n:
fprintf(stderr, \nJoybus Entry Point: 0x);
for (i=0; i sizeof(hdr-joybus_entry); i++) fprintf(stderr, %x,
hdr-joybus_entry[i]);
Some terminal setups will *not* output the last line if it does not
finish properly with a \n, so it may be worth editing the code to
avoid the \nXXX format idiom, and go for a format style that puts
\n at the _end_ of output lines:
fprintf(stderr, Nintendo Logo: 0x);
for (i = 0; i sizeof(hdr-nintendo_logo); i++)
fprintf(stderr, %02x, hdr-nintendo_logo[i]);
fprintf(stderr, \n);
fprintf(stderr, Fixed Value: 0x%02x\n, hdr-fixed_val);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is international support broken is msdosfs file system driver?
On Mon, 06 Apr 2009 16:29:55 -0700, Yuri y...@rawbw.com wrote: Nobody replied and I still have the problem. I extracted the area of the disk where long file names are stored. And can see that all characters are in UTF-8. So how to correctly read UTF-8 encoded VFAT? Remap the locale to something you *can* read? I regularly use mount options like -L el_GR.ISO8859-7 to browse FAT filesystems frm non-UTF8 sessions. Can you try mounting with something like this? # mount -o -L=el_GR.ISO8859-7 /dev/msdosfs/FOO /mnt BTW, this should probably be in -questions not -hackers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Code review request: cdcontrol status label additon
On Wed, 28 Jan 2009 09:20:46 -0700 (MST), M. Warner Losh i...@bsdimp.com wrote: Not going to look at glabel for this. I lifted the code from glable, but must have done it badly. I'll grab a core 10 cd and see what's up. It may not be Fedora specific. I just happened to have it handy... Sorry for creating *more* work for you. I'll see if I can hack at cdcontrol too, and provide more useful input :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Code review request: cdcontrol status label additon
On Wed, 28 Jan 2009 18:29:10 +0200, Giorgos Keramidas keram...@freebsd.org
wrote:
On Wed, 28 Jan 2009 09:20:46 -0700 (MST), M. Warner Losh i...@bsdimp.com
wrote:
Not going to look at glabel for this. I lifted the code from glable,
but must have done it badly. I'll grab a core 10 cd and see what's up.
It may not be Fedora specific. I just happened to have it handy...
Sorry for creating *more* work for you. I'll see if I can hack at
cdcontrol too, and provide more useful input :)
If it helps at all, I added this:
lseek(fd, ISO9660_OFFSET, SEEK_SET);
rc = read (fd, buffer, CD_SECTOR_LEN);
+ if (rc == -1)
+ err(1, read);
if (rc == CD_SECTOR_LEN
memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) {
and it seems that read() fails with EIO:
lseek(3,0x8000,SEEK_SET) = 32768 (0x8000)
read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error'
My `/var/log/messages' shows at the same time:
Jan 28 19:01:52 kobe kernel: acd0: FAILURE - non aligned DMA transfer attempted
Jan 28 19:01:52 kobe kernel: acd0: setting up DMA failed
This is with a FreeBSD 8.0-CURRENT kernel from svn /head @ 187792.
So it may not really be a problem with the patch itself...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Code review request: cdcontrol status label additon
On Wed, 28 Jan 2009 10:19:00 -0700 (MST), M. Warner Losh i...@bsdimp.com
wrote:
: lseek(3,0x8000,SEEK_SET) = 32768 (0x8000)
: read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error'
OK. That's definitely not page aligned.
Slightly modified to force the alignment. Thanks for the tip about the
address, which I failed to notice in truss output :)
%%%
diff -r 0c625c73ecc0 usr.sbin/cdcontrol/cdcontrol.1
--- a/usr.sbin/cdcontrol/cdcontrol.1Wed Jan 28 18:38:39 2009 +0200
+++ b/usr.sbin/cdcontrol/cdcontrol.1Wed Jan 28 19:34:15 2009 +0200
@@ -156,12 +156,14 @@
Play the right subtrack on both left and right channels.
.It Ic info
Print the table of contents.
-.It Ic status Op Cm audio | media | volume
+.It Ic status Op Cm audio | label | media | volume
Print the information about the disc:
.Pp
.Bl -tag -width .Cm volume -compact
.It Cm audio
the current playing status and position
+.It Cm label
+the current ISO 9660 volume label, if present
.It Cm media
the current media catalog status
.It Cm volume
diff -r 0c625c73ecc0 usr.sbin/cdcontrol/cdcontrol.c
--- a/usr.sbin/cdcontrol/cdcontrol.cWed Jan 28 18:38:39 2009 +0200
+++ b/usr.sbin/cdcontrol/cdcontrol.cWed Jan 28 19:34:15 2009 +0200
@@ -86,6 +86,7 @@
#define STATUS_AUDIO 0x1
#define STATUS_MEDIA 0x2
#define STATUS_VOLUME 0x4
+#define STATUS_LABEL 0x8
struct cmdtab {
int command;
@@ -801,6 +802,8 @@
what |= STATUS_MEDIA;
else if (!strncasecmp(p, volume, strlen(p)))
what |= STATUS_VOLUME;
+ else if (!strncasecmp(p, label, strlen(p)))
+ what |= STATUS_LABEL;
else {
warnx(invalid command arguments);
return 0;
@@ -851,6 +854,32 @@
else
printf (No volume level info available\n);
}
+ if (what STATUS_LABEL) {
+#defineISO9660_MAGIC \x01 CD001 \x01\x00
+#defineISO9660_OFFSET 0x8000
+#defineVOLUME_LEN 32
+#define CD_SECTOR_LEN 2048
+#define LABEL_NAME_OFF 0x28
+#define LABEL_NAME_LEN 32
+ uint32_t buffer[CD_SECTOR_LEN / sizeof(uint32_t)];
+ char *sp, *ep;
+
+ lseek(fd, ISO9660_OFFSET, SEEK_SET);
+ rc = read (fd, buffer, CD_SECTOR_LEN);
+ if (rc == CD_SECTOR_LEN
+ memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) {
+ sp = (void *)buffer + LABEL_NAME_OFF;
+ ep = sp + LABEL_NAME_LEN - 1;
+ while (*ep == ' ' ep = sp)
+ *ep-- = '\0';
+ if (verbose)
+ printf(ISO 9660 Label is: %s\n, sp);
+ else
+ printf(%s\n, sp);
+ }
+ else
+ printf(No ISO 9660 label found\n);
+ }
return(0);
}
%%%
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Determine if a kernel is built with a specific option?
On Mon, 12 Jan 2009 14:56:21 +, Andrew Brampton brampton+freebsd-hack...@gmail.com wrote: If you were going to do this, would you make it a configure flag... ie --enable-polling... That way it doesn't matter if the build box is different? If both choices are available (i.e. no header files are missing, no link-time libraries are unavailable, and so on), I'd probably make it a runtime option: * A configure-time flag to set the 'default' and * A runtime option to explicitly specify the current preference when the program runs. This seems a bit more flexible, and does not require an expensive ``go back to your vendor, and ask for a special build-time option'' cycle to test different setups when a field installation is done. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [Testers wanted] vt100/xterm-support for syscons
On Tue, 23 Dec 2008 14:59:51 +0100, Ed Schouten e...@80386.nl wrote: Hello all, Some time ago I sent a message to the lists about vt100/xterm/UTF-8 support for syscons. I think the code is pretty stable now and after some minor improvements/fixes, it should be ready to hit the tree. I'm sending this message to this list, because it would be nice if people could test the patch before I commit it. Especially if people with different fonts/keymaps could test it, it would be really nice. Patches are available at: http://people.FreeBSD.org/~ed/mpsafetty/ Hi Ed, Do we just pick the latest version of mpsafetty changes? I think I might be able to run a few tests with the xterm support patch during the next week. If no serious issues turn up that I've not been able to fix before the end of the year, I'll commit it one of the first days of January. Heh, that would be a good New Year's gift :-) I have been using screen and a .bashrc snippet that sets TERM=vt220 inside screen until now. This has proved to be a remarkably good combination for [ FreeBSD console - screen - TERM=vt220 - ssh ] sessions to BSD, Linux *and* Solaris systems. I suspect having full `TERM=xterm' support in the console would make at least half of this setup obsolete and make ssh connections to non-BSD systems Just Work(TM) without the screen+vt220 hack! pgpySYNQE90Xl.pgp Description: PGP signature
Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: While you're enhancing cdboot anyway, can I ask how complicated it would be to make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - but I'd be prepared to try and look at this myself if no-one else is interested). As it stands, the only way I've found to do a serial-console CD-based installation is by enabling the serial console in /boot/loader.conf, by which time you've already missed several useful points, particularly the entry to BIOS settings (if you have a serial-capable BIOS). cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. Sorry, of course you're right: I'm talking nonsense. It's the stage immediately after that that isn't available. I wish I could remember why I thought that had caused me a problem once. Certainly there's a big chunk of the boot process that is accessible through a serial console on a disk-based boot that's not available on a serial-console boot. I'm still not sure what sort of `serial console boot' we are talking about here. What's the difference between a `serial console on a disk-based boot' and a `serial console boot'? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small Change to chpass.c
On Thu, 11 Dec 2008 08:11:20 +0100 (CET), Trond Endrestøl [EMAIL PROTECTED]
wrote:
On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
On Wed, 10 Dec 2008 18:00:25 -0800, Sheldon Givens [EMAIL PROTECTED]
wrote:
--- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
+++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
@@ -80,10 +80,11 @@
{
enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
struct passwd lpw, *old_pw, *pw;
- int ch, pfd, tfd;
+ int ch, pfd, tfd, itr, auth;
const char *password;
char *arg = NULL;
uid_t uid;
+ int max_retries = 3;
#ifdef YP
struct ypclnt *ypclnt;
const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
}
if (old_pw !master_mode) {
- password = getpass(Password: );
I'm sure you have noticed the trailing space in the string.
- if (strcmp(crypt(password, old_pw-pw_passwd),
- old_pw-pw_passwd) != 0)
+ auth = 0;
+ for(itr=0;itrmax_retries;itr++) {
+ password = getpass(Password:);
The space's missing in this string. It might be better to stay
consistent with the original code.
Good catch. No, I didn't notice the missing space the first time I read
the diff :/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
On Mon, 08 Dec 2008 20:41:32 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Hi, I'm looking at kern/subr_param.c: 72 #ifndef MAXFILES 73 #define MAXFILES (maxproc * 2) 74 #endif Shouldn't this be at least maxproc*3, for stdin,out,err for every proc? Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; This is an attempt to limit a rogue process from grabbing the full maxfiles or maxproc value by opening too many files. There will still be (maxfiles / 10) file descriptors available and (maxproc / 10) process table entries, so that you can for example try to log into the system as root and try to fix things. You can still cause all sorts of trouble by *forking* and then going off into a file descriptor allocation spree, but as I said this is an _attempt_ at keeping things in a relatively sane state in the _default_ state. You can still use the loader to set the actual values of the `kern.maxprocperuid' and `kern.maxfilesperproc' tunables to something that is more robust for your particular application. The defaults are just a `best effort' guess to keep things working in the most common case. Nothing funny about them :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXFILES in subr_param.c
On Wed, 10 Dec 2008 14:30:24 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Also, it looks like MAXFILES is used only once, and in a bit funny way: 238 maxfiles = MAXFILES; 239 TUNABLE_INT_FETCH(kern.maxfiles, maxfiles); 240 maxprocperuid = (maxproc * 9) / 10; 241 maxfilesperproc = (maxfiles * 9) / 10; What's funny about it? MAXFILES is a macro used only once, where it resolves to (maxproc*2). It's not technically incorrect, but it looks like it adds noise. It doesn't add noise :-) It's arguably a code quality and `documentation' feature. It provides a human-readable, useful name to the magic value (maxproc * 2). If we decide to bump the default to (maxproc * 10) sometime later, we won't have to grovel through the entire src/sys/tree and look for maxproc instances that need updating. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small Change to chpass.c
On Wed, 10 Dec 2008 18:00:25 -0800, Sheldon Givens [EMAIL PROTECTED] wrote:
Hi guys,
When I was doing some user management today I noticed that chpass, and
all the utilities that use chpass.c, only give one attempt to
authenticate to make the change. After I messed this up once or twice
(and after doing 4-5 minutes of editing only to have it lost when I
typo'd the password) I wrote this little change in to chpass.c.
This seems useful, thanks for submitting the patch :)
---snip---
--- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
+++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
@@ -80,10 +80,11 @@
{
enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
struct passwd lpw, *old_pw, *pw;
- int ch, pfd, tfd;
+ int ch, pfd, tfd, itr, auth;
const char *password;
char *arg = NULL;
uid_t uid;
+ int max_retries = 3;
#ifdef YP
struct ypclnt *ypclnt;
const char *yp_domain = NULL, *yp_host = NULL;
@@ -227,9 +228,16 @@
}
if (old_pw !master_mode) {
- password = getpass(Password: );
- if (strcmp(crypt(password, old_pw-pw_passwd),
- old_pw-pw_passwd) != 0)
+ auth = 0;
+ for(itr=0;itrmax_retries;itr++) {
+ password = getpass(Password:);
+ if(strcmp(crypt(password, old_pw-pw_passwd),
+ old_pw-pw_passwd) == 0) {
+ auth=1;
+ break;
+ }
+ }
+ if (!auth)
baduser();
} else {
password = ;
---snip---
You can probably do away with `auth' and reset password to NULL when
strcmp() fails (note that we also use whitespace in for statements to
separate everything more clearly):
if (old_pw !master_mode) {
for (itr = 0; itr max_retries; itr++) {
password = getpass(Password:);
if (strcmp(crypt(password, old_pw-pw_passwd),
old_pw-pw_passwd) != 0)
break;
password = NULL;
}
if (password == NULL)
baduser();
} else {
password = ;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev [EMAIL PROTECTED] wrote:
Luigi Rizzo wrote:
On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
Hi,
Below please find patch that enhances cdboot with two compile-time options:
...
Any comments/suggestions are appreciated. If there are no objections I
would like to commit the change. The long-term goal is to make
CDBOOT_PROMPT default mode for installation CD.
http://sobomax.sippysoft.com/~sobomax/cdboot.diff
Looks good. Some comments:
Thank you for the review and comments. Please see my answers below.
1. since there is plenty of space in the cdboot sector, why don't you
make the two option always compiled in, controlling which one to
activate through flags in the bootsector itself, to be set
patching the binary sector itself using a mechanism similar to
boot0cfg.
Of course you cannot alter a cdrom after you burn it,
but it makes it easier to build CDs with one or the other defaults,
patching cdboot or the iso image itself before creating/burning it.
2. in fact, the 'silent' option could be disabled at runtime by
pressing some key (e.g. adding a short wait loop before proceeding;
if this is meant for custom, unattended CDs the extra delay should not
matter much);
Good idea, I will see if I can put that in. In fact this behavior should
have to be optional as well, since one of the uses for the silent
option here is to provide tamper-resistant boot process on custom
hardware.
Nice pair of features :-)
If there are no pressing space constraints maybe we can build both
options in by default, but still make them opt-out when necessary?
With a bit of makefile glue we can make it possible to compile with an
`src.conf' that includes:
WITH_CDBOOT_SILENT=1
WITHOUT_CDBOOT_PROMPT=1
This way the defaults can include support for both options, but we can
conditionally compile *out* the bits that are not needed for some custom
installation.
Something like this can define one or both of these options in CFLAGS,
depending on what `src.conf' contains:
# When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except
# Loading, please wait... and it also passes RBX_MUTE flag to the next
# stage to silence it as well. This is intended for custom installations
# where end-user is not required to see any messages or interfere with the
# boot process.
.if ${MK_CDBOOT_SILENT} != no
CFLAGS+= -DCDBOOT_SILENT
.endif
# When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista
# cd loader, that is it reads MBR from the first hard drive in the system
# and if the MBR is bootable (i.e. drive has some other operating system
# installed on it) then it presents user with Press any key to boot from
# CD prompt and waits for 20 seconds. If key is not pressed then the
# control is passed to the MBR, otherwise CD is booted. This is intended for
# installation CD to allow unattended mode and also helps when installation
# CD has been unintentionally left in the drive of the machine that is set
# to boot off CD.
.if ${MK_CDBOOT_PROMPT} != no
CFLAGS+= -DCDBOOT_PROMPT
.endif
The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in
`src/share/mk/bsd.own.mk', near line 281:
281 #
282 # MK_* options which default to yes.
283 #
284 .for var in \
...
But that shouldn't be a problem, AFAICT :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Timer driven tasks in FreeBSD 7
On Sun, 7 Dec 2008 17:56:47 +0200, Yony Yossef [EMAIL PROTECTED] wrote: Hi All, What mechanism should I use for making my netwrok driver call a function every half a second, for instnace? I am already using task queues but I haven't found a way to make it work with a timer. callout_xxx() functions should do the trick. See the timeout(9) manpage for more details. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, 5 Dec 2008 18:46:00 -0800, Sheldon Givens [EMAIL PROTECTED] wrote:
On Fri, Dec 5, 2008 at 4:17 PM, Giorgos Keramidas [EMAIL PROTECTED]wrote:
Adding the option to increase finger-compatibility and make shell
scripts a bit easier to port over sounds fine by me :)
My apologies if this is in the wrong format. I don't often post here.
---snip---
[patch]
---unsnip---
Can you post a `diff -u' or `diff -c' version of the patch? I like the
idea of the new option but it would be easier to read in -u/-c format.
New diff -u:
Excellent, thanks! Other than a few minor style-bugs, which can be
fixed before committing it (see inline comments for details), the patch
looks great to me :-)
--- /usr/src/usr.bin/wc/wc.c2004-12-27 14:27:56.0 -0800
+++ wc/wc.c 2008-12-05 14:33:21.0 -0800
@@ -167,9 +172,13 @@
return (1);
}
charct += len;
- for (p = buf; len--; ++p)
- if (*p == '\n')
+ for (p = buf; len--; ++p)
+ if (*p == '\n') {
+ if (tmpll llcnt)
+ llcnt = tmpll;
+ tmpll = 0;
++linect;
+ } else {tmpll++;}
It's probably more 'stylish' to write the else part as:
if (*p == '\n') {
if (tmpll llcnt)
llcnt = tmpll;
tmpll = 0;
++linect;
} else
tmpll++;
@@ -194,7 +207,7 @@
(void)printf( %7lld, (long
long)sb.st_size);
tcharct += sb.st_size;
(void)close(fd);
- return (0);
+ return (0);
This change only removes indendation from a return statement. We should
probably keep it out of the final commit.
Thanks for writing posting the patch :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Sat, 06 Dec 2008 13:57:53 +0200, Giorgos Keramidas [EMAIL PROTECTED] wrote:
Can you post a `diff -u' or `diff -c' version of the patch? I like the
idea of the new option but it would be easier to read in -u/-c format.
New diff -u:
Excellent, thanks! Other than a few minor style-bugs, which can be
fixed before committing it (see inline comments for details), the patch
looks great to me :-)
Ok, I've fixed a few minor bugs I noticed:
* When only -L is specified it should not enable the default 'cwl' set
of options.
* The tlongline total length should not be overwritten by each input
file, unless we *did* find a longer line in the particular file.
* The (llct - 1) trick is not needed when printing llcnt if we only
count != '\n' characters near line 229.
The updated patch, and a manpage change to document the new option is
attached below. Konstantin, if you like this version of the patch, I'll
commit it to /head and schedule an MFC after a week or so.
The longer line length that -L reports seems to work like this here:
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc /etc/rc.conf
: 114 2222632 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -L /etc/rc.conf
: 82 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.conf
: 114 2222632 82 /etc/rc.conf
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$ ./wc -lwc -L /etc/rc.
: 114 2222632 82 /etc/rc.conf
: 15985648 36725 85 /etc/rc.subr
: 17125870 39357 85 total
: [EMAIL PROTECTED]:/hg/bsd/src/usr.bin/wc$
Here's the current patch version...
%%%
diff -r fb56dd4c9c47 usr.bin/wc/wc.1
--- a/usr.bin/wc/wc.1 Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.1 Sat Dec 06 17:39:17 2008 +0200
@@ -43,7 +43,7 @@
.Nd word, line, character, and byte count
.Sh SYNOPSIS
.Nm
-.Op Fl clmw
+.Op Fl Lclmw
.Op Ar
.Sh DESCRIPTION
The
@@ -71,6 +71,15 @@
.Pp
The following options are available:
.Bl -tag -width indent
+.It Fl L
+The number of characters in the longest input line
+is written to the standard output.
+When more then one
+.Ar file
+argument is specified, the longest input line of
+.Em all
+files is reported as the value of the final
+.Dq total .
.It Fl c
The number of bytes in each input file
is written to the standard output.
@@ -129,6 +138,10 @@
as well as the totals for both:
.Pp
.Dl wc -mlw report1 report2
+.Pp
+Find the longest line in a list of files:
+.Pp
+.Dl wc -L file1 file2 file3 | fgrep total
.Sh COMPATIBILITY
Historically, the
.Nm
@@ -154,6 +167,16 @@
.Xr iswspace 3
function, as required by
.St -p1003.2 .
+.Pp
+The
+.Fl L
+option is a non-standard
+.Fx
+extension, compatible with the
+.Fl L
+option of the GNU
+.Nm
+utility.
.Sh SEE ALSO
.Xr iswspace 3
.Sh STANDARDS
diff -r fb56dd4c9c47 usr.bin/wc/wc.c
--- a/usr.bin/wc/wc.c Sat Dec 06 17:04:51 2008 +0200
+++ b/usr.bin/wc/wc.c Sat Dec 06 17:39:17 2008 +0200
@@ -62,8 +62,8 @@
#include wchar.h
#include wctype.h
-uintmax_t tlinect, twordct, tcharct;
-int doline, doword, dochar, domulti;
+uintmax_t tlinect, twordct, tcharct, tlongline;
+int doline, doword, dochar, domulti, dolongline;
static int cnt(const char *);
static voidusage(void);
@@ -75,7 +75,7 @@
(void) setlocale(LC_CTYPE, );
- while ((ch = getopt(argc, argv, clmw)) != -1)
+ while ((ch = getopt(argc, argv, clmwL)) != -1)
switch((char)ch) {
case 'l':
doline = 1;
@@ -87,6 +87,9 @@
dochar = 1;
domulti = 0;
break;
+ case 'L':
+ dolongline = 1;
+ break;
case 'm':
domulti = 1;
dochar = 0;
@@ -99,7 +102,7 @@
argc -= optind;
/* Wc's flags are on by default. */
- if (doline + doword + dochar + domulti == 0)
+ if (doline + doword + dochar + domulti + dolongline == 0)
doline = doword = dochar = 1;
errors = 0;
@@ -125,6 +128,8 @@
(void)printf( %7ju, twordct);
if (dochar || domulti)
(void)printf( %7ju, tcharct);
+ if (dolongline)
+ (void)printf( %7ju, tlongline);
(void)printf( total\n);
}
exit(errors == 0 ? 0 : 1);
@@ -134,7 +139,7 @@
cnt(const char *file)
{
struct stat sb;
- uintmax_t linect, wordct, charct;
+ uintmax_t linect, wordct, charct, llct, tmpll;
int fd, len, warned;
size_t clen;
short gotsp;
@@ -143,7 +148,7 @@
wchar_t wch;
mbstate_t mbs;
- linect = wordct = charct = 0;
+ linect = wordct = charct = llct = tmpll = 0;
if (file == NULL) {
file = stdin;
fd = STDIN_FILENO;
@@ -168,8 +173,13
Re: Small change to wc
On Sat, 06 Dec 2008 17:40:14 +0200, Giorgos Keramidas [EMAIL PROTECTED] wrote: The updated patch, and a manpage change to document the new option is attached below. Konstantin, if you like this version of the patch, I'll commit it to /head and schedule an MFC after a week or so. Committed to /head as change 185714: http://svn.freebsd.org/viewvc/base?view=revisionrevision=185714 Sheldon, thanks for the patch. I will merge it to the stable branches after about a few days :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small change to wc
On Fri, 5 Dec 2008 14:14:32 -0800, Sheldon Givens [EMAIL PROTECTED] wrote: Hello everyone, In the process of migrating the last of a few Linux servers to FreeBSD, we ran in to a bit of a snag with one of our scripts when BSD wc didn't have an equivalent to the Linux -L. This flag tells wc to keep track of the longest line in the input. Here's a little diff to add this functionality to BSD wc. With this patch, an additional parameter is added to output that shows the length of the longest line Adding the option to increase finger-compatibility and make shell scripts a bit easier to port over sounds fine by me :) My apologies if this is in the wrong format. I don't often post here. ---snip--- [patch] ---unsnip--- Can you post a `diff -u' or `diff -c' version of the patch? I like the idea of the new option but it would be easier to read in -u/-c format. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Mon, 01 Dec 2008 21:08:25 -0800, [EMAIL PROTECTED] wrote: Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Not sure I understand what is meant by unexpanded here, since it looks as if this sed example would convert an expanded form -- containing the version info -- to an unexpanded one that merely shows where that info should go. Perhaps it's my ClearCase background showing through, but I'd think it highly desirable for a patch to include what I think of as the expanded tag line -- including the version info, as it appears in the distributed files under /usr/src -- thereby explicitly showing the version on which the patch is based (the base contributor in ClearCase-speak). This should greatly simplify merging in the (likely) event that other development has occurred on the same file in the meantime -- provided one is using a 3-way merge tool that understands such things. You are right, of course. The fact that `$FreeBSD$' is extracted in unexpanded form by the current svn-hg converter is a limitation of the Python bindings of Subversion. They do not support expansion of the svn:keywords property of checked out files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin [EMAIL PROTECTED] wrote: May be I am missing something, but what's wrong with the patches from other VCS, providing that with Subversion you can exchange only by the plain diffs? Yes, Git/Mercurial patches should be applied with 'patch -p1', but that's all. Subversion has no notion simular to 'git format-patch' and 'git am', if I am not messing the things up, so the only way to exchange with others are the patches themselves. Conflicts... Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. I like Mercurial myself, but it's some times a pain to refresh patches that touch lines near $FreeBSD$. The only issue I do see is about '$FreeBSD$', but plain Subversion clients shouldn't mess with it. Bingo :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: keeping track of local modifications
On Mon, 1 Dec 2008 22:56:02 +0300, Eygene Ryabinkin [EMAIL PROTECTED] wrote: Giorgos, good day. Hi Eygene, thanks. The same to you too :) Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and you may end up submitting patches that include unexpanded forms of the $FreeBSD: $ text. These will fail to apply if they same patch touches nearby lines. Ahm, yes. sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g' should help in this case. Thanks for clarification! Having said that, I have been using a patched version of the `crew' branch of Mercurial, for local FreeBSD work. I didn't want to convert the *full* history of the /head branch from Subversion, so I started by converting only the changes of 2008, using a local Subversion mirror for speed. The `convert' extension of Hg can pull changesets from Subversion, using the py-subversion bindings. An initial conversion of all the 2008 commits of the /head branch was bootstrapped with: % mkdir -p /hg/bsd % cd /hg/bsd % hg convert --config convert.svn.startrev='175021' \ --config convert.svn.trunk='head' \ --config convert.svn.branches='' \ --config convert.svn.tags='' \ file:///home/svn/base/ head After running for a while, this produced `/hg/bsd/head/.hg' which takes about 200 MB of space now, and it includes 6600+ changesets so far: % hg -R /hg/bsd/head tip changeset: 6603:bfec3e11214e branch: head tag: tip user:jasone date:Mon Dec 01 10:20:59 2008 + summary: Fix a lock order reversal bug that could cause deadlock during fork(2). % Rerunning the same command can incrementally pull only the new changes from Subversion, and it is fast enough that I saved it to a shell script called `/hg/bsd/pull-head.sh' and I run it from time to time, whenever I want to resync with 8.0-CURRENT: % pwd /hg/bsd % \time ./pull-head.sh scanning source... sorting... converting... 10 Adjustments to make a tags file a bit more suitable to amd64. 9 Fix fread() to return a correct value on platforms where sizeof(int) != 8 Catch up with the disappearance of sys/dev/hfa. 7 Trivial patch to show on which geom has the error been detected. 6 The times(3) function returns the number of CLK_TCKs since the 5 import ath hal 4 Switch to ath hal source code. Note this removes the ath_hal 3 Fix typo. 2 Add controller suspend/resume support. 1 Invoke _rtld_atfork_post earlier, before we reinitialize rtld locks 0 Add ixgbe(4) and upgt(4). 12.06 real 3.52 user 1.42 sys % It's nice to be able to use local-only operation for merging some of the patches I have to test, so it may be useful to anyone who wants to keep doing local FreeBSD work with Hg. In particular, it's nice to be able to look at the local diffs very very fast. Once the filesystem cache is warmed with the .hg/ contents of one workspace, I like being able to see stuff like: % \time hg diff -r bfec3e11214e:tip /dev/null 1.81 real 1.30 user 0.41 sys % I'll try to write to the Wiki how I keep a few local patches around, using a clone of the converted source tree. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reccomendation for tools to use on FreeBSD for a wiki ?
On Wed, 19 Nov 2008 18:24:21 +0100, Julian Stacey [EMAIL PROTECTED] wrote: Hi hackers, Maybe Some of you might suggest some software I might install, Wiki I guess. ? I got zero response from ports@, I could use some reccomendations please. PS From http://wiki.freebsd.org/HelpContents I tried cd /usr/ports/www ; vi *iki*/pkg-descr or is /usr/ports/www/moinmoin the way to go ? Thanks. --- Subject: Reccomendation for ports for web based club events forthcoming diary ? Can anyone reccomend some ports to install on a FreeBSD web server, for a club of mostly non technical people, to support: - All club members can add events to a forthcoming calendar, - All club members can request server to prepare a listing of next next upcoming events, to download (probably in PDF, or perhaps tbl to a pipe or ? - A list of moderators can delete fake events from robots the malicious. - Preferably moderators should not themselves be capable of deleting logged event submission, but only capable of deleting events formatted to the ouput printable programme sheet. (To autopsy for suspect rogue moderators) - I guess first entry criteria might be a fuzzy picture for human to decode password from). 2nd might be mail return for confirm password, - 3rd, A majordomo (later mailman) maintained list of club members moderators etc is available for automated validation. - I hope there will be some packages available, http probably wiki based etc, that will come close enough ? Hi Julian, I have been working with `OddMuse' in the EmacsWiki[1] as a user and as an admin/moderator in some installations of my own. The UI of the wiki is pretty simple, and it does have a very low level of requirements for becoming a `wiki editor', so it may be a good choice for a Wiki where non-technical people produce a lot of the content. OddMuse does have a relatively _unique_ way of treating Wiki content and may require a bit of Perl hackery to configure captchas, but I like the fact that it is basically a relatively small `wiki core' that is fairly trivial to extend by writing Perl modules. See http://www.oddmuse.org/cgi-bin/oddmuse for more details about the OddMuse wiki engine. Wikipedia has a list of other Wiki software at http://en.wikipedia.org/wiki/List_of_wiki_software that may also be useful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Mon, 3 Nov 2008 15:12:34 -0700, Steve Franks [EMAIL PROTECTED] wrote: That's alot of good info. It should go in the porter's handbook, maybe... Hi Steve, Probably not. What I wrote is specific to the GNU build system. We have many ports that use configure scripts and makefiles generated from various versions of the GNU build tools, but ports are ``different''. We are not the _maintainers_ of the main source code of all the ported applications. We just have to make sure they build on FreeBSD, and that's pretty much all of it. For example, if the source tree of a port includes a `configure.in' that is broken on FreeBSD and Cygwin, we don't really have to ``fix'' both of these. If it builds correctly on FreeBSD, we are done. This may not be enough for Cygwin users, but we are not out to fix everyone's code to build on everybody else's system. That would be an insane amount of work for a very doubtful amount of gain :) So, if I'm looking to make a port, which one of those people should I be acting as? Maintainer? That's FreeBSD-port-terminology you are using, correct? FreeBSD Porters are a separate category. They usually fall in the category of `builder' I mentioned in the original post, but they have to provide the tools for `packagers' too, in the form of Makefiles, scripts and packaging lists that allow others to configure, build and package the ``vendor'' code for some FreeBSD version. When I mentioned `maintainer', `builder' and `packager' roles in the original post I didn't mean *FreeBSD-maintainer* but the actual person or team that maintains the upstream source of a program. HTH, Giorgos ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAVP (Yet Another Vmstat Patch)
On Tue, 04 Nov 2008 23:13:19 +0100, Ivan Voras [EMAIL PROTECTED] wrote: Hi, I'm working on something that tends to generate a lot of context switches and I don't like the way values in vmstat 1 are printed practically unbounded, causing wrapping, etc. Here's a patch against -CURRENT that uses humanize_number() to keep the formatting of memory and context switches tabular in the common case: http://people.freebsd.org/~ivoras/diffs/vmstat.c.patch.txt The following people might not like it: * Those who really need to distinguish between 185400 context switches and 185499 context switches * Those who have scripts that parse the output * Those who thought the previous chaotic behaviour is cute :) Example of new output is: procs memory pagedisks faults cpu r b w avm free flt re pi pofr sr ad4 ad8 in sy cs us sy id 3 0 0 112M 3.7G 0 0 0 0 0 0 0 02 373K 267K 4 37 59 2 0 0 112M 3.7G 0 0 0 0 0 0 0 00 366K 271K 4 37 59 3 0 0 112M 3.7G 0 0 0 0 0 0 0 00 370K 267K 4 36 59 4 0 0 112M 3.7G 0 0 0 0 0 0 0 00 378K 278K 5 36 60 3 0 0 112M 3.7G 0 0 0 0 0 0 0 0 69 366K 268K 4 39 58 2 0 0 112M 3.7G 0 0 0 0 0 0 0 0 65 372K 271K 5 41 54 4 0 0 112M 3.7G 0 0 0 0 0 0 0 0 71 374K 271K 5 40 55 2 0 0 112M 3.7G 0 0 0 0 0 0 0 06 375K 276K 4 39 57 Any objections to the patch? Can we convince you to make it an option and default to off at first? vmstat's current output format has the useful property that fault columns align nicely when they are ``small enough'', and seeing them misaligned is something that triggers a ``we have considerable load'' double-check. Right now my backup script is running, and I see: : $ vmstat -w 1 : procs memory pagedisks faults cpu : r b w avmfre flt re pi pofr sr ad0 md0 in sy cs us sy id : 3 0 0 1071M 211M 903 0 0 0 1176 388 0 0 661 16032 5783 12 9 79 : 3 0 0 1071M 210M 1 0 0 030 0 74 0 1356 3062 7927 7 15 78 : 0 0 0 1071M 209M20 0 0 032 0 79 0 1509 3139 8629 4 16 80 : 0 0 0 1071M 207M 0 0 0 030 0 74 0 1306 2988 7653 4 14 82 : 0 0 0 1071M 206M 0 0 0 031 0 63 0 1315 2787 7302 6 17 77 : 1 0 0 1071M 205M 0 0 0 030 0 49 0 1787 2786 8750 4 20 76 : 0 0 0 1071M 204M 0 0 0 030 0 49 0 1974 2465 9480 5 19 76 : 0 0 0 1071M 202M 0 0 0 030 0 89 0 1388 3588 8432 6 16 78 : 0 0 0 1071M 200M 1 0 0 030 0 87 0 1358 3338 8199 6 17 77 : 3 0 0 1071M 199M 0 0 0 030 0 80 0 1367 4142 8216 9 16 75 : 1 0 0 1071M 198M 0 0 0 030 0 76 0 1339 3175 8133 6 18 76 : 1 0 0 1071M 241M 0 0 0 0 11354 0 73 0 1361 3055 7839 8 24 68 : 3 0 0 1057M 253M 0 0 0 0 3426 0 82 0 1398 3548 8273 10 17 73 : 2 0 0 1057M 247M 0 0 0 031 0 123 0 1357 4377 8113 4 14 82 : 1 0 0 1057M 240M36 0 1 047 0 150 0 1394 4597 8526 6 16 78 : 1 0 0 1057M 233M 0 0 0 030 0 146 0 1298 4496 7970 4 15 81 : ^C Only the first line is misaligned by _one_ character, and I *like* the extra granularity of the rest. Your patched version has a shorter `avm' and `fre' too. Do we really have to trim them? They seem to be doing fine with physmem = 3 GB. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: du -A / -B options [Re: zfs quota question]
On Tue, 4 Nov 2008 23:42:49 +0100, Max Laier [EMAIL PROTECTED] wrote: Hi again, On Saturday 01 November 2008 21:14:42 I wrote: a thread on freebsd-stable@ [1] about problems with du(1) and compressed zfs filesystems got me looking for a possible solution. Attached is a diff for du(1) that adds two new options: -A to display the apparent size of the file instead of the used blocks. -B bsize to specify a custom blocksize. In particular one 512byte The GNU du(1) has --apparent-size for -A, but we don't like long options. That's not to say that it couldn't be added for script compat. -B is probably not that interesting, but it can be helpful and came for free. Attached is an updated patch. This refines the -B option to something more useful (and fixes a bug in the original patch). From the man page: -B blocksize Calculate block counts in blocksize byte blocks. This is differ- ent from the -k, -m options or setting BLOCKSIZE and gives an estimate of how many space the examined file hierachy would require on a filesystem with the given blocksize. Unless in -A mode, blocksize is rounded up to the next multiple of 512. That looks nice! With a small fix (``how _much_ space'') I like the idea a lot :) The patch fails to apply on a recent /head snapshot of du though: : [EMAIL PROTECTED]:/ws/bsd/src/usr.bin/du$ patch -p0 -i ~/du.AB.diff : [...] : The text leading up to this was: : -- : |Index: du.c : |=== : |--- du.c (revision 184656) : |+++ du.c (working copy) : -- : Patching file du.c using Plan A... : Hunk #1 failed at 79. : Hunk #2 failed at 99. : Hunk #3 failed at 159. : Hunk #4 succeeded at 215 (offset -2 lines). : Hunk #5 failed at 236. : Hunk #6 failed at 259. : Hunk #7 failed at 292. : Hunk #8 failed at 317. : Hunk #9 succeeded at 465 (offset -5 lines). : Hunk #10 succeeded at 482 (offset -2 lines). : 7 out of 10 hunks failed--saving rejects to du.c.rej : done : [EMAIL PROTECTED]:/ws/bsd/src/usr.bin/du$ Can you please refresh and repost it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: du -A / -B options [Re: zfs quota question]
On Wed, 5 Nov 2008 03:39:51 +0100, Max Laier [EMAIL PROTECTED] wrote:
That looks nice! With a small fix (``how _much_ space'') I like the
idea a lot :)
The patch fails to apply on a recent /head snapshot of du though:
...
Can you please refresh and repost it?
Hum ... are you sure your snapshot is up to date? I did some style(9)
cleanup in r184654/6 that you might not have yet. Anyways ... here is
a diff with those revisions included.
Ah, that's it then. I ran 'svn up' at the change right *before* the
HPS-USB commit and the latest du stuff was missing. Thanks :)
The patch works fine here. I only had to make a tiny change, to avoid a
core dump when the -B blocksize is invalid as an integer and it caused a
division by zero in fts:
$ ./du -B abcde
Floating point exception: 8 (core dumped)
Here's a diff of all the local changes I made:
%%%
diff -r a3da3ebb57ab usr.bin/du/du.1
--- a/usr.bin/du/du.1 Wed Nov 05 04:47:07 2008 +0200
+++ b/usr.bin/du/du.1 Wed Nov 05 04:53:28 2008 +0200
@@ -72,7 +72,7 @@
.Fl k, m
options or setting
.Ev BLOCKSIZE
-and gives an estimate of how many space the examined file hierachy would
+and gives an estimate of how much space the examined file hierachy would
require on a filesystem with the given
.Ar blocksize .
Unless in
@@ -160,7 +160,7 @@
or
.Fl h
options are not specified, the block counts will be displayed in units of
-that size block.
+that block size.
If
.Ev BLOCKSIZE
is not set, and the
diff -r a3da3ebb57ab usr.bin/du/du.c
--- a/usr.bin/du/du.c Wed Nov 05 04:47:07 2008 +0200
+++ b/usr.bin/du/du.c Wed Nov 05 04:53:28 2008 +0200
@@ -117,7 +117,7 @@
case 'B':
errno = 0;
cblocksize = atoi(optarg);
- if (errno == ERANGE || cblocksize 0) {
+ if (errno == ERANGE || cblocksize = 0) {
warnx(invalid argument to option B: %s,
optarg);
usage();
%%%
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, 31 Oct 2008 12:30:46 -0700, Steve Franks [EMAIL PROTECTED] wrote: Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). Then you run `configure' with the `right' environment: env CPPFLAGS='-I/usr/local/include' \ LDFLAGS='-L/usr/local/lib' ./configure The `--includedir' and `--libdir' options are *not* meant to be useful to the developer that uses the GNU build tools, but to the person who compiles something for the target host. There are several types of people involved in the `release' of a full program: * The maintainer, who uses `automake', `libtool' and `autoconf' to write portable Makefiles and build tools. * The builder, who compiles the program with specific options. * The packager, who runs `make install' in the build tree, creates a set of installed files, and then packages *some* of these files in a packaging-specific format. These types of people commonly have different constraints in the way they can tweak and twist the GNU build tools, to match their needs. 1. The _maintainer_ of the program is free to set up his environment to include any `CPPFLAGS', `CFLAGS' or `LDFLAGS' they find useful. For example, if they have an experimental third-party library installed in a custom location they can use: export CPPFLAGS='-I/opt/foolib/include' LDFLAGS='-L/opt/foolib/lib' ./configure --prefix='/var/tmp/myprog' This way `configure' will emit Makefiles that try to use the third-party library from `/opt/foolib' instead of the system-default location for header files and libraries. This may often be a lot easier than waiting until the necessary bits are installed in the ``official'' places at development systems. Developers who want to experiment with a new version of `libfoo', i.e. to integrate it with the rest of a program, can use custom `CPPFLAGS' and `LDFLAGS' while everyone else is merrily going along with the ``standard'' version of the `libfoo' library. 2. The _builder_ may be constrained in the sets of options he can pass to the `CFLAGS'. He is, after all, testing how a pristine, clean version of the program can build in what is defined as the ``official release'' environment. He may be allowed to tinker with include paths and library paths, but it is often safer to wrap the build process in scripts and tools that yield a repeatable, verifiable build process. This may preclude the use of options like `-I/custom/hdr/path' and `-L/custom/lib/path'. The builder of a program may not be an actual person, but a cron job or another automated process, i.e. a `nightly build' script that runs a clean build in a pristine environment, verifies that it can all complete without errors, and then emails one or more reports. When the builder _is_ a real person, he may be sharing roles with the third type of person involved in the build life of a program that uses the GNU build tools: the packaging person. 3. The _packager_ is someone who runs `make install', to produce the final program distribution and then bundles parts of or even all the files that are produced by the usual `install' target of GNU tools. The installation of all the files may be done in the default installation `prefix', but it may also be redirected to a staging area by setting `DESTDIR' in the environment: mkdir /var/tmp/proto env DESTDIR=/var/tmp/proto make install Depending on the type of the target system, and on particular needs of the packaging person, there may be cases where certain files have to be installed in a `non-standard' location, or in a location that was not foreseen by the original maintainer. In that case, the packager can use the `--libdir' and `--includedir' options to change the final, installed location of the relevant bits. A typical example is the case of Solaris systems, where libraries may be installed in `/usr/lib/64' for 64-bit architectures. When a packager prepares installation images for these architectures, he can build the program with: ./configure --prefix='/opt/foo' --libdir='$prefix/lib/64' All this is a pretty long-winded way of saying: The `--includedir' and `--libdir' options are not really something that is meant to be a convenience option for the _maintainer_ of a program,, the person who writes the code. They are meant to be useful tools for the _packager_ of the program, the person who builds and prepares the final, install-able
Re: du -A / -B options [Re: zfs quota question]
On Sat, 1 Nov 2008 21:14:42 +0100, Max Laier [EMAIL PROTECTED] wrote: Hi, a thread on freebsd-stable@ [1] about problems with du(1) and compressed zfs filesystems got me looking for a possible solution. Attached is a diff for du(1) that adds two new options: -A to display the apparent size of the file instead of the used blocks. -B bsize to specify a custom blocksize. In particular one 512byte That's nice :) % Index: du.1 % === % --- du.1 (revision 184513) % +++ du.1 (working copy) % @@ -60,6 +61,14 @@ % .Pp % The options are as follows: % .Bl -tag -width indent % +.It Fl A % +Display the apparent size instead of the diskusage. 'disk usage' should be two words here. % +This can be helpful to find sparse files and when operating on % +compressed volumes. ``This can be helpful when operating on sparse files or compressed volumes'' maybe? The fact that a difference between plain `du' and `du -A' output may be a nice hack to find sparse files is a cool side-effect, but that's not really the main driving force behind the change, right? :) % Index: du.c % === % --- du.c (revision 184513) % +++ du.c (working copy) % @@ -86,27 +86,39 @@ % FTS *fts; % FTSENT *p; % off_t savednumber = 0; % - longblocksize; % + longblocksize = 0; savednumber is one of the existing style bugs. We shouldn't copy it, but initialize `blocksize' further down, near `depth = INT_MAX' and the rest of the initializations. Thoughts? FWIW, I like the new options :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mercurial working copy of FreeBSD src
On Fri, 8 Aug 2008 11:47:15 -0700, Navdeep Parhar [EMAIL PROTECTED] wrote: Hello everyone, I'm looking for the fastest way to get a full mercurial repository of HEAD. Do you really want the *FULL* history of head? It's probably going to be in the order of a couple of hundred of MB, or even more. If you can live with an Hg repository that only includes the 2008 history of 'HEAD', then please keep reading, you may like the rest of this post :) I tried using hgsvn and the tree at http://svn.freebsd.org/base/head but it looks like the first hgpullsvn operation will take days (literally): hgpullsvn is slow. Really really *REALLY* slow... It's probably a better idea to get a recent version of the mercurial/crew branch. This includes support for the svn-1.5.X bindings, and you can convert parts of the history of the /base/head branch. I have a local hg tree with the history of the 'head' branch since 2008-01-01 on my laptop, which I periodically resync from svn with: [EMAIL PROTECTED]:/home/keramida$ cd /hg/bsd [EMAIL PROTECTED]:/hg/bsd$ ./pull-head.sh scanning source... sorting... converting... [lots of output snipped] [EMAIL PROTECTED]:/hg/bsd/head$ hg shortlog --limit 2 4201:99f1acdec12f | 2008-08-09 04:08 + | imp: Rather than waiting a fixed amount of time, which might not be enough 4200:d5553c08bf90 | 2008-08-09 03:54 + | imp: Change -1 to 0xul since the interface returns uint32_t. (1) A bit of background === I didn't really want to convert the full history of the 'head' branch From Subversion, because I have a local Subversion repository for that. Being able to rebase my local in-progress patches on an Hg clone _did_ seem useful at the time, so that's why I converted only the history of 'head' from the start of 2008. The initial pull was done by pulling a clean copy of the first commit of 2008 and then importing changesets on top of that with: % cd /hg/bsd % \time hg convert --config convert.svn.startrev=175026 \ --config convert.svn.trunk='head' \ --config convert.svn.branches='' \ --config convert.svn.tags='' file:///home/svn/base/ head The initial pull took a bit of time, but far less than hgimportsvn. Subsequent pull-head.sh runs take literally seconds to pull from a local Subversion repository mirror. The speed is much much better than hgpullsvn, because the Hg convert extension doesn't parse the output of shell commands, but it links `natively' (through SWIG) with the subversion libraries. The conversion process is interruptible, and if you keep the 'SHA map' of the initial conversion you can keep pulling changesets into the conversion clone as many times as necessary with something like: % cd /hg/bsd % cat -n pull-head.sh 1 #!/bin/sh 2 3 hg convert \ 4--config convert.svn.trunk='head' \ 5--config convert.svn.branches='' \ 6--config convert.svn.tags='' \ 7file:///home/svn/base/ head % You don't need the `convert.svn.startrev=175026' option in the second and subsequent runs, because the conversion clone already has a file called `.hg/shamap' and the conversion picks up from the place it stopped the previous time. (2) Bootstrapping your own clone Everything above is of `encyclopedical' nature, because now that I've done the conversion once, you can just use a bundle file and a matching copy of my `.hg/shamap' file to bootstrap a conversion clone of your own. You can fetch an Hg bundle and a matching shamap with the history of 'head' in 2008 from: http://people.freebsd.org/~keramida/mercurial/head.hg http://people.freebsd.org/~keramida/mercurial/head.shamap The checksums of these files should be: MD5 (head.hg) = 4978723c560bc48c390be1634c7d36a4 MD5 (head.shamap) = 8e5957657fb499ed3a3575fc921e3029 SHA256 (head.hg) = ab073135925fdb54a2820077a5a4d75f4306d44a217b7c30d6b8719a9a5008d4 SHA256 (head.shamap) = 04c6648bd108d3550ffb126c321b8faf2f5dda9f891787bb57ae178efa271893 The head.hg bundle is around 92 MB and you can pull it directly into an empty Hg workspace: % hg init head % cd head ; hg pull /var/tmp/head.hg Then copy the `head.shamap' file in `.hg/shamap' and you are ready to go. You can start cloning this tree, and you can also run hg convert to incrementally pull the history of the svn/head branch, as many times as necessary. The `pull-head.sh' script I included above will make subsequent pulls less tedious by saving you the typing of all the --config options to get the svn-hg branch names right. (3) Important disclaimer Note that this is *NOT* an official branch of the FreeBSD source tree, so if you plan to use the head.hg bundle, this email is _not_ really a promise to keep uploading `bootstrap bundles'. You are also the sole person responsible for comparing the
Re: Sysinstall is still inadequate after all of these years
On Thu, 3 Jul 2008 10:56:29 +0200, Holger Kipp [EMAIL PROTECTED] wrote: Dear Antoine Brunel, I completely 100% agree. Actually I don't see the need for a new sysinstall. It does what it needs to do. I have seen the later RH- and SUSE-Installer, but I don't want them. What's the use of a graphical installer? Graphical installers are not useless. They usually 'look' easier for the average user. They may not always _be_ easier to use, but it is often the first impression that counts. Localization tends to be easier for GUI installers too. Now, it may seem pretty useless for someone who knows English already, but a *lot* of people feel more comfortable with an installer that speaks their native language. After the installation is finished, English may be a lot more useful (think manpages, for instance). But it still 'looks' nicer to be able to install in one's native language. I am more than happy with sysinstall, have used it for years (starting with 2.2.8 actually) and don't want to see a colorful chingeling whistleblowing hard-to-maintain suitable for all graphics card gui installer. Agreed :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On Fri, 4 Jul 2008 09:38:37 +0300, Aggelidis Nikos [EMAIL PROTECTED] wrote:
I'm sorry I started a kind of flame war. All I wanted was two
things: 1. CD's that installed without being switched in and out
dozens of times. That was fixed by the suggestion of using a DVD. I
didn't even know the DVD install existed, but will do that next time.
I also had the same problem {cd switching} to get around it, i created
an installation DVD with all the contents of cd1-2-3. You can find
such guide
Hi Nikos :)
The DVD-ROM doesn't even have to be bootable. Just collecting all the
`packages/All/*' files from the CD-ROMs in a single directory makes it
much easier to run:
# cd /nfs/blah ; pkg_add vim*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On Fri, 4 Jul 2008 14:31:51 +0200, Paul B. Mahol [EMAIL PROTECTED] wrote:
On 7/4/08, Randy Bush [EMAIL PROTECTED] wrote:
This is why there are precompiled packages on ftp.freebsd.org which you
can install with 'pkg_add -r'. You can install them from any FTP
mirror, actually; just point PACKAGEROOT at the mirror:
why isn't this stuff in the docs? oh, it is! silly me. is the problem
that there are just too much doc or two little reading?
/sarcasm
It is in pkg_add(1), If you are talking about handbook only
PACKAGESITE is documented: should get fixed.
Hi Paul,
Can you please open a docs/* problem report for this? Feel free to add
`keramida' to the `X-GNATS-Notify:' header. I'll try to add at least a
reference to pkg_add(1) to read more about the `PACKAGEROOT' environment
variable.
I'm just getting back from a 8-10 day period of ${offline_world} stuff,
but it would be a shame to lose the opportunity to document this,
because it got hidden in the `noise' of the mailing lists.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On Sun, 06 Jul 2008 10:51:10 +0300, Giorgos Keramidas [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008 14:31:51 +0200, Paul B. Mahol [EMAIL PROTECTED] wrote: On 7/4/08, Randy Bush [EMAIL PROTECTED] wrote: This is why there are precompiled packages on ftp.freebsd.org which you can install with 'pkg_add -r'. You can install them from any FTP mirror, actually; just point PACKAGEROOT at the mirror: why isn't this stuff in the docs? oh, it is! silly me. is the problem that there are just too much doc or two little reading? /sarcasm It is in pkg_add(1), If you are talking about handbook only PACKAGESITE is documented: should get fixed. Hi Paul, Can you please open a docs/* problem report for this? Feel free to add `keramida' to the `X-GNATS-Notify:' header. I'll try to add at least a reference to pkg_add(1) to read more about the `PACKAGEROOT' environment variable. Nevermind, that was easy. I just opened a PR for it... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On Wed, 2 Jul 2008 21:28:50 -0700, Rob Lytle [EMAIL PROTECTED] wrote: 2. Being able to use Sysinstall and not having it crash when a dependency is already present. Sometimes I like to use Sysinstall to install gigantic packages where the compile time is 26 hours, e.g KDE metapackage, and my notebook uses an Intel Core 2 Duo at 2Ghz or thereabout. That is one hell of a long compile time. For this request I will just have to wait for FreeBSD 10.0. Crashing is a bug. We should fix that. Having said this, I often use portupgrade for this sort of thing. After mounting the DVD, you can see what would be installed with # mount /cdrom # env PKG_PATH=/cdrom/packages/All portupgrade -n -N -PP postfix and then you can actually *run* the installation by removing the `-n' option from the portupgrade run. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/124409: fsck(8) requires exact entry for mountpoints when executing / bug by design in getfsfile(3) in .../lib/libc/gen/fstab.c
On Mon, 16 Jun 2008 20:28:08 -0700, Garrett Cooper [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 2:27 AM, Garrett Cooper [EMAIL PROTECTED] wrote:
Ok it appears I wasn't intelligent enough to post this in the right
place last night. Comments please?
Hi hackers,
I have a question, pending a bug found in getfsfile(3) [1].
Is there any possibility where a mountpoint be any value other
than a directory, a symlink, or none, i.e. a flat file?
Thanks,
-Garrett
References:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR
database yet).
Going once, going twice...
Hi Garrett :-)
When I wrote the original comment in that PR I had something like this
in mind:
%%%
*** src.7789d2851415/lib/libc/gen/fstab.c Sun Jun 22 05:57:09 2008
--- /home/build/src/lib/libc/gen/fstab.cSun Jun 22 05:56:48 2008
*** struct fstab *
*** 236,245
getfsfile(name)
const char *name;
{
if (setfsent())
! while (fstabscan())
! if (!strcmp(_fs_fstab.fs_file, name))
return(_fs_fstab);
return((struct fstab *)NULL);
}
--- 236,256
getfsfile(name)
const char *name;
{
+ char name_path[PATH_MAX];
+ char fstab_path[PATH_MAX];
+
+ if (realpath(name, name_path) == NULL)
+ return((struct fstab *)NULL);
if (setfsent())
! while (fstabscan()) {
! if (strcmp(_fs_fstab.fs_file, name) == 0 ||
! strcmp(_fs_fstab.fs_file, name_path) == 0)
! return(_fs_fstab);
! if (realpath(_fs_fstab.fs_file, fstab_path) == NULL)
! return((struct fstab *)NULL);
! if (strcmp(fstab_path, name_path) == 0)
return(_fs_fstab);
+ }
return((struct fstab *)NULL);
}
%%%
I tried to avoid unnecessary realpath(3) calls as much as possible, but
there is still the possibility for at least N+1 calls, where N is the
number of entries in fstab...
Can you test the above patch, and let me know if it looks ok, if you
have a better fix in the works, etc.? It seems to pass the bug you
originally reported when I run:
% env LD_PRELOAD=/home/build/obj/home/build/src/lib/libc/libc.so.7 \
fsck ///cdrom///
fsck: exec fsck_cd9660 for /dev/acd0 in /sbin:/usr/sbin: No such file or
directory
The failure later is ok, because we don't have fsck_cd9660 for CD-ROMs.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug by design in getfsfile(3) / needed sanity check for mountpoints
On Mon, 9 Jun 2008 01:34:19 -0700, Garrett Cooper [EMAIL PROTECTED] wrote: Hi hackers, I have a question, pending a bug found in getfsfile(3) [1]. Is there any possibility where a mountpoint be any value other than a directory, a symlink, or none, i.e. a flat file? Thanks, -Garrett References: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR database yet). It looks like could be 'fixed' by using realpath() on its argument. Then this should work fine: # fsck /usr/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug by design in getfsfile(3) / needed sanity check for mountpoints
On Tue, 10 Jun 2008 03:53:41 +0300, Giorgos Keramidas [EMAIL PROTECTED] wrote: On Mon, 9 Jun 2008 01:34:19 -0700, Garrett Cooper [EMAIL PROTECTED] wrote: Hi hackers, I have a question, pending a bug found in getfsfile(3) [1]. Is there any possibility where a mountpoint be any value other than a directory, a symlink, or none, i.e. a flat file? Thanks, -Garrett References: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/124409 (not fully in PR database yet). It looks like could be 'fixed' by using realpath() on its argument. Then this should work fine: # fsck /usr/ I meant to write It looks like getfsfile() could be 'fixed'..., but the keyboard daemon ate a word there. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impact of having a large number of open file descriptors
On Mon, 2 Jun 2008 21:07:15 -0400, Garance A Drosihn [EMAIL PROTECTED] wrote: At 12:33 AM +0200 6/3/08, Kris Kennaway wrote: Ivan Voras wrote: Suleiman Souhlal wrote: I have an old patch that makes kqueue monitor every file write on the system and return the inode number in the knote's data field: http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff . I'd think it shouldn't be too hard to make it per-mountpoint.. FWIW, I would love to use this. I have situations where I have huge numbers of files and need to cheaply detect changes so I can resynchronize them to remote machines. I remember a discussion of changes to MacOS10 in Leopard which made it easier to implement features such as Spotlight and TimeMachine. The description starts here, I think: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 the section on file-system events. The idea I thought was interesting was to save the metadata on a directory basis, instead of saving it on the file. So, if file /some/dir/fname was changed, then they'd record that *some* file under /some/dir has changed. So when your userland process comes along later on, it still has to scan all files in that directory to see which file(s) actually changed. But that's a lot less work than scanning all files in the filesystem, and it also means there is much less data that has to be kept track of. I have no idea how easy it would be to implement something similar on FreeBSD, but the strategy seemed like a pretty neat idea. It sounds like a useful compromise between the number of tracked entries and scanning the entire fs :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: indent(1) support for gcc(1) 0b prefix
On Sun, 27 Apr 2008 02:01:53 +0200, Max Laier [EMAIL PROTECTED] wrote:
On Saturday 26 April 2008 23:35:57 Romain Tarti?re wrote:
Hello FreeBSD hackers!
I'm using avr-gcc from the ports and relying on the 0b prefix notation
for binary constants, that is:
foo = 0b00101010;
Thanks to /usr/ports/devel/avr-gcc/files/patch-0b-constants this is
possible :-)
But I would like to use indent(1) to reformat contributed code
automatically. Unfortunately, the 0b notation is not supported by that
program, and the resulting code looks like this:
foo = 0 b00101010;
... then compilation fails, bla bla bla...
I can't think of a case (outside of 0x context) where ...0b...
would be valid C code, let alone better formated as ...0 b
Hence I see no harm in adding your patch to the base indent(1).
Does anyone have an example where ...0 b... is valid C code?
The only case I can think of is when the b... is an existing macro,
i.e. something like:
1 #include stdio.h
2
3 #define b0101 + 3
4
5 int
6 main(void)
7 {
8 printf(%u\n, 0 b0101);
9 return 0;
10 }
But that's a rather contrived example. Making the 0b support
tunable through a command-line option seems ok for me.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strdup(NULL) supposed to create SIGSEGV?
On Wed, 23 Apr 2008 10:30:39 +0200, Bernard van Gastel [EMAIL PROTECTED] wrote: Op 23 apr 2008, om 08:50 heeft Mike Meyer het volgende geschreven: On Tue, 22 Apr 2008 22:40:21 -0700 Garrett Cooper [EMAIL PROTECTED] wrote: Hi all, I made an oops in a program, which uncovered feature in strdup(2) that I wasn't aware of before. So I was wondering, is strdup(pointer = NULL) supposed to segfault should this just return NULL and set errno? Yes, it's supposed to segfault. Check out what, say, strcpy does if you ask it to copy a NULL pointer. And this is an improvement from the bad old days, when they would happily walk through memory starting at 0. I don't like it this way. I would like: strdup(NULL) = NULL strdup(string) = copy of string strcpy(NULL, NULL) = NULL strcpy(s1, NULL) = ERROR strcpy(NULL, s2) = NULL (with s2 unchanged) strcpy(s1, s2) = normal But I am not sure of the implications. Maybe in some situation it is bad... Anyone? Well-written programs already check for NULL before they call strdup(), so they won't be affected by changing strdup() to return NULL when a null pointer is passed to strdup(). What is more likely to happen is that _badly_ written programs will crash further down, at the place where the null pointer is actually used. So we'll be hiding the bug of strdup(NULL) and causing faults in other, possibly very far places in the program's execution path. That's not really a very good idea :( Besides, errno is used to signal errors from system calls. strdup isn't a system call, it's a library function (says so at the top of the man page). But strdup uses malloc, which is a system call (from the strdup manual: If insufficient memory is available, NULL is returned and errno is set to ENOMEM.) I have to disagree I'm afraid. The malloc() function is *not* a system call, although it may be mapped to low-level primitives like sbrk() or mmap(). In general, malloc() is a `special' library function that abstracts away the implementation specific details of obtaining memory from the kernel. There are implementations of malloc() out there that rely on certain system-specific features but are, otherwise, implemented *entirely* in userland code. Our own is one. The sources of FreeBSD's malloc() are in `/usr/src/lib/libc/stdlib/malloc.c' for anyone interested to read the source and see all the cool things Jason has done :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strdup(NULL) supposed to create SIGSEGV?
On Wed, 23 Apr 2008 09:06:44 -0700 (PDT), Simun Mikecin [EMAIL PROTECTED] wrote: If you're going to quote documents to support your ideas, it's probably better to read them first. My apologies. My fingers were faster than my mind. But this made me read it the way I should have done in the first place. And I see that it says: A null pointer is returned if the new string cannot be created. Does that also mean that a null pointer is returned if the input is a NULL pointer (cause in that case new string could not be created)? No. It means that if the input is *valid* but the is a problem with completing the operation of strdup(validstring), then an error is returned to let you know something bad is going on. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strdup(NULL) supposed to create SIGSEGV?
On Wed, 23 Apr 2008 19:57:47 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: Hi, I recently had to tell someone that strncpy does not always zero terminate the destination string. Surprised by what I was telling they immediately wanted to change the way the function worked. When a function is defined by an ISO standard you are not supposed to change the definition. Instead I pointed the person at strlcpy. Else you will have serious trouble when code is ported to a new platform. http://www.gratisoft.us/todd/papers/strlcpy.html The name strdup is very appealing, but it has already been taken and defined. You have to give your variant a different name and convince everyone that your function is good and solves a problem so that it deserves to be in the C-library. Right on the spot, Hans :) You may have to pick a name that doesn't start from str, though, because the str* function names are reserved for future extensions to the standard. ISO/IEC 9899:1999 (E), page 401, §7.26.11 says: 7.26 Future library directions [...] 7.26.11 String handling string.h 1 Function names that begin with str, mem, or wcs and a lowercase letter may be added to the declarations in the string.h header. You're quite right about 'not replacing' the standard functions in a lighthearted manner though. The short-term benefits of making a single application easier to write, are dwarfed by the possibilities for introducing gratuitous incompatibilities for all the _other_ programs running on the same platform, and any other platforms conforming to the real standard behavior. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Perforce and `p4 diff2' against the origin
On Sat, 5 Apr 2008 16:50:38 +0200, Ed Schouten [EMAIL PROTECTED] wrote: Hello everyone, Because my mpsafetty project in Perforce is going quite well, I'm considering running some kind of cron job to generate nightly diffs, so other people (interested friends, colleagues and others) to test my work. I've read `p4 help diff2' and it seems you can run the following command: p4 diff2 -b mpsafetty Unfortunately this command just does a braindead diff against the latest FreeBSD vendor source, which is not useful in my case. I just want it to generate a diff against the version I integrated. Is it possible to do this with Perforce? Yes, as long as you have a 'base' version to diff against. I'd probably try something like: p4 diff2 -du //depot/vendor/freebsd/head/... //depot/user/ed/mpsafetty/... The only tricky part with diff2 is that it expects depot-based paths, as it runs the diff `in the server', not against local workspace files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in /bin/sh?!?
On Sun, 06 Apr 2008 11:17:18 -0700, Julian Elischer [EMAIL PROTECTED] wrote:
dino wrote:
Hello,
on my FreeBSD 7.0-STABLE the line:
sh -c 'set -- ${HOME+A B C}; echo 1:$1; echo 2:$2:; echo 3:$3:'
prints
1:A B C:
2::
3::
I would rather expect:
1:A:
2:B:
3:C:
Is it correct that field splitting isn't performed on default/alternate
expanded values?
A B C is a single value tha thappens to contain spaces.
so, yes there is no splitting at that point.
I think there *is* splitting.
To inhibit splitting, you would have to use quotes, i.e. one of:
set -- ${HOME+A B C}; echo 1:$1; echo 2:$2; echo 3:$3
set -- ${HOME+A B C}; echo 1:$1; echo 2:$2; echo 3:$3
Splitting does occur in bash, mksh, pdksh and zsh in FreeBSD.
The Solaris 10 version of /bin/sh shell does not accept the original at
all (I used Solaris 10 Update 3, aka Solaris 10 11/06 s10x_u3wos_10
X86, for the test):
$ sh -c 'set -- ${HOME+A B C}; echo 1:$1; echo 2:$2:; echo 3:$3:'
sh: bad substitution
$
but it does accept any of the quoted options. The /usr/bin/ksh shell on
Solaris accepts the original, but it splits the result at whitespace.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pfind() and the proc structure
On Wed, 2 Apr 2008 10:59:26 -0700, Rao, Nikhil [EMAIL PROTECTED] wrote:
Thanks for all your replies,
the all_proc lock is held in pfind(..) at the point PROC_LOCK(p) is
obtained. In the kern_wait(..) code below, the allproc_lock is acquired
before removing the proc from the list of all procs. The PROC_LOCK is
then acquired before continuing. Since the thread that called pfind(..)
has the PROC_LOCK, kern_wait(..) would need to wait for it to release
the PROC_LOCK before continuing. I hope this understanding is correct.
In http://fxr.watson.org/fxr/source/kern/kern_exit.c?v=RELENG62#L579
sx_xlock(allproc_lock);
675 LIST_REMOVE(p, p_list); /* off zombproc */
676 sx_xunlock(allproc_lock);
677 LIST_REMOVE(p, p_sibling);
678 leavepgrp(p);
679 sx_xunlock(proctree_lock);
680
681 /*
682 * As a side effect of this lock, we know
that
683 * all other writes to this proc are visible
now, so
684 * no more locking is needed for p.
685 */
686 PROC_LOCK(p);
Yes, line 686 above will have to wait for any holders of the proc lock
on the specific proc entry. The allproc_lock is not needed anymore,
because these last lines are inside:
if (p-p_state == PRS_ZOMBIE) {
...
After the zombie process has been removed from the zombie list, we will
have to wait until the proc entry is unlocked. At that point, the proc
entry is no longer on the zombie list, so it won't be locked by anyone
else. We grab the lock, clean it up and it's gone for good.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: crontab Patches
On Wed, 2 Apr 2008 15:35:02 -0400, Steven Kreuzer [EMAIL PROTECTED] wrote: I wrote two patches for crontab.c that I was wondering if someone would take a look at. The first one zero out pw_passwd in crontab, just to be paranoid side. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122070 The second replaces sprintf with snprintf http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/122137 Thanks, I'll have a look at these :-) On an unrleated note, I submitted a small change for the freebsd-tips fortune datfile that removes references to two ports that no longer exist. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/122296 misc/instant-server is still there. I think it's ok to remove the tip about instant-workstation, because the port has been removed by: # $FreeBSD: ports/misc/Makefile,v 1.831 2007/01/05 17:08:38 miwi Exp $ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pfind() and the proc structure
On Tue, 1 Apr 2008 07:23:58 -0700, Rao, Nikhil [EMAIL PROTECTED] wrote:
Ok, I should have caught that :-( Another question - Now that the
PROC_LOCK on p is obtained the all_proc lock is released and the
function returns, at this point can't the proc get deallocated ?
Nikhil
242 struct proc *
243 pfind(pid)
244 register pid_t pid;
245 {
246 register struct proc *p;
247
248 sx_slock(allproc_lock);
249 LIST_FOREACH(p, PIDHASH(pid), p_hash)
250 if (p-p_pid == pid) {
251 if (p-p_state == PRS_NEW) {
252 p = NULL;
253 break;
254 }
255 PROC_LOCK(p);
256 break;
257 }
258 sx_sunlock(allproc_lock);
259 return (p);
260 }
Not until you unlock the specific proc entry. You are holding a lock
for the specific proc entry, so anyone trying to `reap' the process
would have to wait until you are done with what you are doing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building in /usr/src copied to $HOME
On Fri, 21 Mar 2008 14:32:24 -0600 (MDT), M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Václav Haisman [EMAIL PROTECTED] writes: : The problem is that MK_DYNAMICROOT is defined by bsd.own.mk. This : likely means that he's not building the same version of FreeBSD as : the system is running, otherwise the system's bsd.own.mk file : would cope. : : That was the problem as I stated in email from two days ago. I guess : nobody noticed the second email :) I noticed after I replied. That should teach me to read the whole thread before replying :-) I replied offline, and then got the rest of the thread when I reconnected. My apologies for the noise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some versioned storage program?
On Fri, 21 Mar 2008 16:10:22 -0700, Xin LI [EMAIL PROTECTED] wrote:
Hi, folks,
I'm looking for some versioned storage program that can fulfill the
following requirements:
- Open source/Free Software that can run on FreeBSD, or not far
(i.e. on other POSIX OS)
- Support of atomic commit/rollback.
- Fast checkin time (At least, when added/changed files are explicitly
specified).
- Fast update time (i.e. something like 'cvsup -s' that makes it
possible to trust bookkeeping file rather than stat'ing every files)
- Scalable for a large number of files, directories and revisions. Say,
it is not acceptable for it to store a zillion of revisions as
individual files within one directory.
- Ideally it can support some sort of hook functions upon commit so
that changes can be notified in some way such as e-mail.
- Ideally it can support fast export of a snapshot for HEAD and
nearby revision like HEAD - 1, etc.
I think what I need is some SCM software like subversion or hg, but I do
not know if there is some superior stuff that matches these requirements
better. Any other suggestions?
Before you start using Hg, Git or Subversion it may be worth
experimenting a bit with them. My apologies if you _have_ already and
the previous sentence sounds patronising. All I'm saying is that they
all have a fair share of good, not so good, or even bad aspects. So it
would be nice to have tried them all a bit and pick the one that seems
like the best fit for the job at hand :)
To provide a few starting points:
- Subversion, Git and Hg, all run on FreeBSD
- They support 'changesets' as the basic model of storing commits
- Commit speed varies a bit. For locally stored 'workspaces', Git and
Hg seem to be more or less equally fast, with Subversion being a close
second
- Update times tend to vary a bit too. Hg and Git will blow Subversion
away on locally stored repositories, but they might suck a bit on NFS
workspaces
- Storing individual revisions as 'a zillion directory entries in a
single tree' seem to point at Subversion. Have you already tried it,
and found that it doesn't scale for your sort of work? It is used by
many large-ish projects, so it would be surprising but not unrealistic
to have scalability issues after a few million commits
- Hooks _are_ supported by Subversion, Git and Hg (others too)
- Checkout speed (and `export' speed) is pretty fast in Git and Hg.
Subversion is a bit slower, but still usable. Changeset support is a
nice feature, because it doesn't matter if your `export' run takes 1.5
minutes instead of 20 seconds. When a given changeset is exported in
any of svn/git/hg you _never_ get a mix of file revisions from
changesets ${FOO} ... ${FOO+j} for some arbitrarily random value of
'j', because 'j+k' commits happened in the mean time.
Before you _do_ embark on the journey of using a VCS for storing a bunch
of files, it would be nice to stop for a moment and consider if you need
one. If you do, there _are_ options, and they are definitely not
limited to the three systems mentioned so far.
HTH,
Giorgos
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building in /usr/src copied to $HOME
On 2008-03-18 21:28, V??clav Haisman [EMAIL PROTECTED] wrote:
Hi,
I am trying to use /usr/src copied to my $HOME but the build process
doesn't want to work. For example when I try build /bin/cp I get the
following:
shell::wilx:~/freebsd/src/bin/cp make
/usr/home/users/wilx/freebsd/src/bin/cp/../Makefile.inc, line 9:
Malformed conditional (${MK_DYNAMICROOT} == no)
/usr/share/mk/bsd.init.mk, line 15: if-less endif
make: fatal errors encountered -- cannot continue
Is there any sort of tutorial/prescription anywhere how to use /usr/src
tree that does not reside in /usr/src?
Hmmm, that should work. I regularly build as a non-root user, at
`/home/build/src'.
The error about ``Malformed conditional'' seems a bit odd too. Are you
using /usr/bin/make? What version of FreeBSD is the build host running,
and what version of the source tree have you checked out?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 17:01, Daniel O'Connor [EMAIL PROTECTED] wrote: On Tue, 4 Mar 2008, M. Warner Losh wrote: Greetings, here's a set of diffs that will allow FreeBSD's usr.bin/make to build on Linux. I'm sure they are gross, and I don't plan to commit them (at least not all of them), but I thought I'd post them here to see what people think. I think that the extra config.h includes, the errc - errx patches and the Makefile.dist patches may be good for the tree. The rest may not meet FreeBSD's source tree policies. Comments? I did this a while ago when porting some of our code to Linux because it builds with pmake.. Your patches are much nicer than mine however :) The tailq stuff could be shoved into a linux.h or some such.. So it's more obvious what it's for and why it's there. Solaris lacks TAILQ_xxx stuff too, so I would prefer something like bsdcompat.h or similar. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-03 22:42, M. Warner Losh [EMAIL PROTECTED] wrote:
Greetings,
here's a set of diffs that will allow FreeBSD's usr.bin/make to build
on Linux. I'm sure they are gross, and I don't plan to commit them
(at least not all of them), but I thought I'd post them here to see
what people think.
I think that the extra config.h includes, the errc - errx patches and
the Makefile.dist patches may be good for the tree. The rest may not
meet FreeBSD's source tree policies.
Comments?
Warner
diff -ur pmake.orig/config.h pmake/config.h
--- pmake.orig/config.h 2005-02-01 03:50:35.0 -0700
+++ pmake/config.h2008-03-03 22:24:16.745493000 -0700
@@ -108,4 +108,27 @@
# endif
#endif
+#ifndef TAILQ_HEAD_INITIALIZER
+#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
+#endif
+
+#ifndef TAILQ_FOREACH
+#define TAILQ_FOREACH(var, head, field)
\
+ for ((var) = TAILQ_FIRST((head)); \
+ (var); \
+ (var) = TAILQ_NEXT((var), field))
+#endif
+
+#ifndef TAILQ_FIRST
+#define TAILQ_FIRST(head) ((head)-tqh_first)
+#endif
+
+#ifndef TAILQ_NEXT
+#define TAILQ_NEXT(elm, field) ((elm)-field.tqe_next)
+#endif
+
+#ifndef TAILQ_EMPTY
+#define TAILQ_EMPTY(head) ((head)-tqh_first == NULL)
+#endif
+
#endif /* config_h_efe0765e */
In a Solaris-based project I'm involved with, I used our own queue.h
pretty much verbatim. Only STAILQ_LAST() seems to use __offsetof(),
which may be a bit tricky to 'port over'.
That's not to say that I don't like the above change, but I am just
`thinking aloud' about the possibility of importing sys/queue.h into
`http://hg.hellug.gr/bmake' to avoid the need for the #ifdef trick.
The TAILQ_*() macros are pretty simple, so it's fairly easy to copy them
verbatim. In the long run, they may get `stale' though, so a full
import of sys/queue.h looks like a `safe' thing. It also stands a
chance of working on Solaris, which doesn't have a sys/queue.h header
at all.
--- pmake.orig/main.c 2007-12-18 15:58:14.0 -0700
+++ pmake/main.c 2008-03-03 22:25:47.543349000 -0700
@@ -660,11 +664,9 @@
int level = (value == NULL) ? 0 : atoi(value);
if (level 0) {
- errc(2, EAGAIN, Invalid value for recursion level (%d).,
- level);
+ errx(2, Invalid value for recursion level (%d)., level);
} else if (level MKLVL_MAXVAL) {
- errc(2, EAGAIN, Max recursion level (%d) exceeded.,
- MKLVL_MAXVAL);
+ errx(2, Max recursion level (%d) exceeded., MKLVL_MAXVAL);
} else {
char new_value[32];
sprintf(new_value, %d, level + 1);
Hohoho! I didn't realize errx() was already available on Linux. Last
night, when I ran `man errx' there was no manpage, but I forgot that
glibc prefers Info manuals :)
Nice...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 15:15, Robert Watson [EMAIL PROTECTED] wrote:
On Mon, 3 Mar 2008, M. Warner Losh wrote:
--- pmake.orig/config.h 2005-02-01 03:50:35.0 -0700
+++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
@@ -108,4 +108,27 @@
# endif
#endif
+#ifndef TAILQ_HEAD_INITIALIZER
+#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
+#endif
In most ports of FreeBSD parts to Linux that I've seen, the preferred
solution has to been to bring the entire FreeBSD queue.h with you rather
than relying on the native Linux queue.h. This is what we do for OpenBSM,
for example; this also helps out when you get to Mac OS X, Solaris, etc,
where all the queue.h's continue to vary in subtle ways. This depends a
fair amount on a lack of header pollution in the OS's own include files, of
course...
Fortunately, in Solaris where I am testing the import of sys/cdefs.h and
sys/queue.h today, things seem to be `ok'. Just importing the two
headers at http://hg.hellug.gr/bmake/gker/rev/68bfc25ed443 seems to have
moved things one step closer towards building everything on Solaris:
Now off to the next little annoyance. Building with Sun Studio on
Solaris 10, in my test machine at home, stops at:
arch.c, line 1063: undefined symbol: INT_MIN
cc: acomp failed for arch.c
*** Error code 2
make: Fatal error: Command failed for target `arch.o'
Current working directory /home/keramida/bmake/src
This is easy to fix with:
diff -r 68bfc25ed443 src/arch.c
--- a/src/arch.cTue Mar 04 17:29:11 2008 +0200
+++ b/src/arch.cTue Mar 04 17:35:08 2008 +0200
@@ -96,6 +96,7 @@
#include ctype.h
#include errno.h
#include inttypes.h
+#include limits.h
#include regex.h
#include stdlib.h
#include stdio.h
The next part, about the missing errx() functions on Solaris is going to
be tonight's fun. If there are too many missing functions, it may be
worth adding a static `libcompat' with copies of just the functions we
need to run BSD make on non-BSD hosts.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 21:01, Girish Venkatachalam [EMAIL PROTECTED] wrote: On 17:01:28 Mar 04, Daniel O'Connor wrote: I did this a while ago when porting some of our code to Linux because it builds with pmake.. Your patches are much nicer than mine however :) The tailq stuff could be shoved into a linux.h or some such.. So it's more obvious what it's for and why it's there. PMI but why do I see tailq in gentoo? I was taken by surprise when I found my code compile and run beautifully few months ago. I am wondering if that is the case, then why port it? Minor compatibility nits here and there, which can turn a simple TAILQ_FOREACH() call to a nightmare of nested preprocessor hells :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 15:38, Robert Watson [EMAIL PROTECTED] wrote: On Tue, 4 Mar 2008, M. Warner Losh wrote: : In most ports of FreeBSD parts to Linux that I've seen, the preferred solution : has to been to bring the entire FreeBSD queue.h with you rather than relying : on the native Linux queue.h. This is what we do for OpenBSM, for example; : this also helps out when you get to Mac OS X, Solaris, etc, where all the : queue.h's continue to vary in subtle ways. This depends a fair amount on a : lack of header pollution in the OS's own include files, of course... I was rather hoping for something that could be used without any of that nonsense... Sadly, nonsense seems to be the name of the game in software portability. Here's the broken autoconf garbage I use to pick out adequate queue.h's from inadequate ones: # sys/queue.h exists on most systems, but its capabilities vary a great deal. # test for LIST_FIRST and TAILQ_FOREACH_SAFE, which appears to not exist in # all of them, and are necessary for OpenBSM. AC_TRY_LINK([ #include sys/queue.h ], [ #ifndef LIST_FIRST #error LIST_FIRST missing #endif #ifndef TAILQ_FOREACH_SAFE #error TAILQ_FOREACH_SAFE #endif ], [ AC_DEFINE(HAVE_FULL_QUEUE_H,, Define if queue.h includes LIST_FIRST) ]) Note that there are at least a couple of mostly stylistic bugs there (could use compile rather than link, definition description is poor, errors are inconsistent). :-) I found that on both Linux and Mac OS X, the queue.h's didn't have everything I wanted. Nice! Thank you Robert. Can I copy parts of this and add them to the autoconf glue I'm adding now? To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, which I used when I tried writing a check for __FBSDID(): AC_PREPROC_IFELSE( [AC_LANG_PROGRAM([[#include sys/cdefs.h #ifndef __FBSDID #error No __FBSDID definition. #endif]])], [AC_DEFINE([HAVE_FBSDID_MACRO], [1], [Define to 1 if you have the __FBSDID macro.])]) I can probably improve a bit the queue.h check using what you wrote above and AC_PREPROC_IFELSE(). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 08:50, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : arch.c, line 1063: undefined symbol: INT_MIN : cc: acomp failed for arch.c : *** Error code 2 : make: Fatal error: Command failed for target `arch.o' : Current working directory /home/keramida/bmake/src : : This is easy to fix with: : : diff -r 68bfc25ed443 src/arch.c : --- a/src/arch.cTue Mar 04 17:29:11 2008 +0200 : +++ b/src/arch.cTue Mar 04 17:35:08 2008 +0200 : @@ -96,6 +96,7 @@ :#include ctype.h :#include errno.h :#include inttypes.h : +#include limits.h :#include regex.h :#include stdlib.h :#include stdio.h We likely should just commit this to FreeBSD's make, since Section 5.2.4.2.1 of the C standard says that INT_MIN is defined there. That's true. This is, I hope, one of the good things about the `exercise' of making BSD make build on all three of BSD, Linux and Solaris :) Should I commit the change to arch.c to HEAD? : The next part, about the missing errx() functions on Solaris is : going to be tonight's fun. If there are too many missing functions, : it may be worth adding a static `libcompat' with copies of just the : functions we need to run BSD make on non-BSD hosts. In the longer term, this likely is a good idea. In the shorter term, I'm not so sure that this is a good idea, since all you'd need would be inlines for the functions that make uses. Once everything builds I plan to keep `synchronizing' with the usr.bin/make version, so I'm willing to go the extra mile to make things more maintanable in the long run. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 08:52, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : Nice! Thank you Robert. Can I copy parts of this and add them to the : autoconf glue I'm adding now? : : To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, : which I used when I tried writing a check for __FBSDID(): : : AC_PREPROC_IFELSE( : [AC_LANG_PROGRAM([[#include sys/cdefs.h : #ifndef __FBSDID : #error No __FBSDID definition. : #endif]])], : [AC_DEFINE([HAVE_FBSDID_MACRO], [1], :[Define to 1 if you have the __FBSDID macro.])]) : : I can probably improve a bit the queue.h check using what you wrote : above and AC_PREPROC_IFELSE(). The alternative to uglifying the make sources with #ifdefs would be to just always use the compat includes when building... No autoconf needed, and minimal changes to the base make, if any. True. I'll try to keep #ifdef changes down to the absolutely _minimum_ amount of changes. It will make repeated merged from usr.bin/make much easier, for example :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 15:45, Robert Watson [EMAIL PROTECTED] wrote: The next part, about the missing errx() functions on Solaris is going to be tonight's fun. If there are too many missing functions, it may be worth adding a static `libcompat' with copies of just the functions we need to run BSD make on non-BSD hosts. It's beginning to sound like it would be really nice to have an autoconf'd/automake'd version of our make to drop onto Linux, Solaris, etc, etc, systems in order to bootstrap our compile. Thanks :) I share Warner's reluctance to add autoconf parts to our native build, but having 'bsdmake' as a starting point is useful, and would put those other platforms more at parity with Mac OS X as a starting point (probably ahead due to more accessible native build tools). I'm a bit surprised there isn't already a Linux 'bsdmake' package floating around... There's always `pmake', and the `bmake' that NetBSD uses to bootstrap itself using their `build.sh' script and a POSIX shell, but there are a couple of details which may inhibit these from being useful for bootstrapping FreeBSD. The `pmake' package of Linux distributions[1] is based on NetBSD make sources. While NetBSD make is probably 90% of what we need to bootstrap FreeBSD, it's still *not* FreeBSD make :/ [1] http://packages.debian.org/etch/pmake (When I say 'nice' above, I mean it in the normal autoconf sense of the word 'nice', so don't take that the wrong way!) I lost you there. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 09:56, David O'Brien [EMAIL PROTECTED] wrote: On Tue, Mar 04, 2008 at 05:45:43PM +0200, Giorgos Keramidas wrote: To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, which I used when I tried writing a check for __FBSDID(): Why are you writing a check for __FBSDID? After the discussion with Warner about our cdefs.h we don't need a check. I'll revert the change tonight, and use our own sys/cdefs.h and sys/queue.h :) Our sources so assume it that IMnoHO you just need to provide it. See missing/sys/cdefs.h in ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/bmake-20080215.tar.gz Thanks! That's precisely the version I had downloaded last night, and plan to study later today :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 10:01, David O'Brien [EMAIL PROTECTED] wrote: On Tue, Mar 04, 2008 at 05:37:30PM +0200, Giorgos Keramidas wrote: The next part, about the missing errx() functions on Solaris is going to be tonight's fun. If there are too many missing functions, it may be worth adding a static `libcompat' with copies of just the functions we need to run BSD make on non-BSD hosts. fbsdmake will be just one of many tools you'll find you need. A libfbsdcompat would be useful to this endevor. If I were you, I would try to create one using FreeBSD src/ - that is assume a checked out FreeBSD is available. See some of my sed'ing and unifdef*(1) hacks I've used over the years to build GNU stuff on FreeBSD. A libfbsdcompat seems like one of the best options to keep the source code changes down to a tolerable level, indeed. Thanks for all the _very_ useful input so far, David :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On 2008-03-04 09:58, David O'Brien [EMAIL PROTECTED] wrote: On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: #include arch.h +#include config.h Are you able to use CFLAGS+= -include config.h instead? If so, that would mean less .[ch] changes. Not with Sun Studio compilers on Solaris. There's a fair amount of things that can be done without _any_ source code change at all, but there's also a limit to what can be done. My $dayjob includes maintaining programs on Solaris, which built with Studio compilers, so I've already bumped against things like this :( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
On 2008-02-27 08:36, John Hein [EMAIL PROTECTED] wrote: Can someone point me at a script that does tag renaming after a repo copy? You don't really need a `script' to do this. Tags in CVS are not versioned, so you can force-tag the repo-copied files and move the tag to its new place. For example if you have two files: foo.c,v bar.c,v and bar.c,v is a repo-copy of foo.c,v then you move the tag only for the bar.c file by checking it out, and running: cvs tag -f -r 1.2 bar.c This should force/move the tag to point revision 1.2. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
On 2008-02-27 10:31, David O'Brien [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 10:33:41PM +0200, Giorgos Keramidas wrote: On 2008-02-23 16:48, M. Warner Losh [EMAIL PROTECTED] wrote: This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. So should I expect similar knee-jerk reactions to the just committed `finger compatibility' option to implement du -l for hardlinks? You added a new useful feature - and you based the option letter on prior-art (and resumable doen't conflict with POSIX). Fortunately, no, there is no conflict :-) The du(1) manpage at the online version of SUSv3 http://www.opengroup.org/onlinepubs/95399/utilities/du.html mentions only the -L option, for dereferencing symlinks. I should have probably mentioned this in the commit log, now that I think about it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs tag renaming after repo copy
On 2008-02-27 12:21, John Hein [EMAIL PROTECTED] wrote: Giorgos Keramidas wrote at 21:04 +0200 on Feb 27, 2008: On 2008-02-27 08:36, John Hein [EMAIL PROTECTED] wrote: Can someone point me at a script that does tag renaming after a repo copy? You don't really need a `script' to do this. Tags in CVS are not versioned, so you can force-tag the repo-copied files and move the tag to its new place. For example if you have two files: foo.c,v bar.c,v and bar.c,v is a repo-copy of foo.c,v then you move the tag only for the bar.c file by checking it out, and running: cvs tag -f -r 1.2 bar.c ^^^ you're missing the tag name in this example, but... This should force/move the tag to point revision 1.2. I don't want to move the tag... I want to invalidate old tags by renaming them to something else (like foo-1-2-3 - old_foo-1-2-3). Ah, now I see. Sorry for the confusion :/ Note that just using cvs to rename a tag (by tagging with the new name and then removing the former name) has issues when you try to do that with branch tags. Anyway, I'm pretty sure the FreeBSD cvs-meisters run something to invalidate tags after doing a repo copy. That's the information I was looking for. Scripting is probably risky for this sort of thing, but I'll let the CVS meisters reply :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
On 2008-02-23 16:48, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Jonathan McKeown [EMAIL PROTECTED] writes: : Yes, where it makes sense. I'm not at all convinced that this change makes as : much sense as you obviously think it does - especially given that it doesn't : add previously unavailable functionality, and that we have a ports system : which includes a patch stage for dealing with this sort of gratuitous : non-portability in ported applications. The change absolutely makes sense, and so far none of the arguments against it are really worth the time to respond to. I'm using packages not in the ports system. Frankly, the more gratuitous differences with the gnu tools we have, the harder the sell will be for companies wanting to replace their Linux systems with FreeBSD ones. The changes I made were absolutely trivial in the scheme of things. This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. So should I expect similar knee-jerk reactions to the just committed `finger compatibility' option to implement du -l for hardlinks? I think there *is* value in making things `less hard' for the user who migrates from Linux, as long as the cost of implementing the compatibility `shims' is not humongous. I'm completely baffled by the reactions to the recent find changes :/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On 2008-02-19 02:39, Dimitry Andric [EMAIL PROTECTED] wrote: On 2008-02-19 02:18, Jerry Toung wrote: anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. Can you elaborate on what you *are* talking about then? Some security-by-obscurity scheme, perhaps? :) Encrypted executables, using some sort of stream or block cipher may not be something which looks *very* useful, but there are a few interesting things which can be done with executable encryption and signatures. One of them is described here: http://blogs.sun.com/darren/entry/signed_solaris_10_binaries ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On 2008-02-18 19:54, Jerry Toung [EMAIL PROTECTED] wrote: On Feb 18, 2008 5:39 PM, Dimitry Andric [EMAIL PROTECTED] wrote: On 2008-02-19 02:18, Jerry Toung wrote: anybody knows of a tool to encrypt executables under FreeBSD? may be from the ports? I am not talking about simple file encryption. Can you elaborate on what you *are* talking about then? Some security-by-obscurity scheme, perhaps? :) I need to encrypt elf binaries. I'd like to make it harder for the bad guy to reverse engineer my app. You know about truss/ktrace/strace already, right? It may be moot to encrypt the ELF binary, if the `bad guy' can access the running image of the process *after* it has been decrypted to execute. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On 2008-01-31 21:37, Stefan Sperling [EMAIL PROTECTED] wrote:
I could not find any tool that does this properly among subversion,
git, monotone and mercurial. That's not a big list, but I don't have
time to try out version control systems all day. Also, proprietary
VCS's were never considered (I also keep my freebsd kernels blob-free,
call me a hippie or whatever if you want :P)
Most tools seem to insist on trying to import the whole history of a
CVS repository before they let you start doing any work in the newly
converted repository. All conversion tools I've tried failed converting
the FreeBSD repository.
Not really. You can keep 'importing' snapshots of the src tree from any
arbitrary CVS branch, if you are willing to wait until CVS checks out
the first copy of the snapshot.
This is how we 'resync' with the official doc/ tree changes in the Greek
translation team:
(a) We keep a Mercurial workspace which is read-only to everyone
else, except the importer.
(b) The importer checks outs doc/ snapshots and commits them as
'vendor code drops' in http://hg.hellug.gr/freebsd/doc/
(c) I pull changes from the 'import tree' into my own personal
workspace, and merge them with the latest translation effort text.
(d) Then the merged tree is pushed to a second 'workspace', 'branch'
or whatever you prefer calling it, at http://hg.hellug.gr/freebsd/doc-el/
The whole process of importing clean snapshots is automated in a shell
script, which I manually kick off at this point:
% #!/bin/sh
%
% cd /ws/doc/bsd
%
% # 1. Start from a clean slate for the next import
% rm -fr *
%
% # 2. Check out a clean copy of a partial doc/ tree.
% cvs -d /home/ncvs co -d . -l doc
% cvs -d /home/ncvs -qR up -APd * share \
% en_US.ISO8859-1 el_GR.ISO8859-7
% find . -type d -name CVS -exec rm -r {} +
%
% # 3. Update mercurial's idea of the current workspace state,
% # hg adding new files, and hg removing gone stuff.
% hg addremove
%
% # 4. Find out the $FreeBSD$ timestamp of the latest patch we are
% # about to commit. Note that this may be a bit silly, because it
% # won't correctly detect -kb files being added after the last
% # $FreeBSD$ id change. A better way would use -D to checkout from
% # CVS, so that a timestamp would be automatically known.
% timestamp=$( hg diff | grep '^+.*FreeBSD:' | \
% sed -e 's/.*,v //' | awk '{print $1,$2}' )
%
% # Commit everything to Mercurial.
% hg ci -u ncvs -d ${timestamp} + \
% -m Import FreeBSD doc/ snapshot at ${timestamp} +
That's not something I would like doing manually several times a day,
but it certainly isn't impossible.
Naturally, similar scripting can be installed for Subversion, Git,
Bazaar, or darcs if that's your personal preference.
Mercurial failed to convert the repo, too, and there was no way of
telling it not to try to import the whole history either.
Snapshot-based import sof FreeBSD code as `vendor imports' are really
*VERY* easy to script in Subversion, Mercurial, Git and Bazaar. Been
there, done that several times, and I can help you if you plan to do
something like this with any of the aforementioned VCSes.
So far, this setup hasn't failed me, and the speed is several orders of
magnitude higher than using CVS branches.
That's my impression too :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
On 2008-02-01 02:00, Giorgos Keramidas [EMAIL PROTECTED] wrote: You can keep 'importing' snapshots of the src tree from any arbitrary CVS branch, if you are willing to wait until CVS checks out the first copy of the snapshot. This is how we 'resync' with the official doc/ tree changes in the Greek translation team: (a) We keep a Mercurial workspace which is read-only to everyone else, except the importer. (b) The importer checks outs doc/ snapshots and commits them as 'vendor code drops' in http://hg.hellug.gr/freebsd/doc/ (c) I pull changes from the 'import tree' into my own personal workspace, and merge them with the latest translation effort text. (d) Then the merged tree is pushed to a second 'workspace', 'branch' or whatever you prefer calling it, at http://hg.hellug.gr/freebsd/doc-el/ The whole process of importing clean snapshots is automated in a shell script, which I manually kick off at this point: An much improved snapshot import script is now finished (for some odd definition of `improved' I guess), even thought it is still a bit ugly for my taste. http://people.freebsd.org/~keramida/scripts/bsd-doc-import.ksh.txt I'd probably prefer Perl for some of the stuff done in ksh(1) there, but no time for that tonight, and it seems to work as a 'proof of concept' of importing partial checkouts from CVS to Hg without having to go through all the hoops of converting the *full* history. The cron job entry which runs this is: # Try to import a snapshot of the BSD doc/ tree once an hour. @hourly $HOME/bsd-doc-import.sh $HOME/hg/doc/bsd-import This is getting pretty off-topic for freebsd-hackers though, so it's probably time for me to shuttup and go do something useful :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
