Re: Interpreted language(s) in the base
On Sun, Aug 15, 2010 at 11:15:55PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: > > However, a bigger reason was that it was impossible to marry our > concept of a "stable" branch with the ever-evolving world that was > perl. This one at least is conceptually pretty easy to solve. We don't have any worries about how old or new the version of expat in base is; since it's not called libexpat, nothing but the stuff in base written specifically against it has to worry about it getting old, and upgrading it requires only checking against those things in base. So we could go right ahead and import perl, just renamed to 'bsdscript' 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
In message , Doug Barton writes: >On Sun, 15 Aug 2010, Ivan Voras wrote: >> This is my long-term point - [...] Some of use were 12 years ahead of you :-) >I sort of agree with you here, but I don't. :) ONE of the reasons that >perl was axed [...] Actually, let me put that stuff on the record, as one of the prime & convicted suspects of that entire ordeal. Tcl, a very small language, specifically designed to be embeddable in other programs, was imported into FreeBSD because we had a dream. The intent of the Tcl import was that it would be embedded into other programs, and thus open them up to customization at a net reduction in C-code lines. Inetd(8) is an example: Rather than "exec this file" you would get to examine IP#'s and other context before you made up your mind about what to do, all in a friendly script language. Other obvious candidates: ampd(8), ppp(8), config(8) and so on. In other words, the Intent behind Tcl was architectural: To improve the base system, eliminated duplication of structural code giving an overall stream-lining of the system. We probably did not manage to sell that vision back then, and I will forego conclusions on the advisability of our vision in hindsight. Tcl was soon axed again, because people did not see the value of having a high-level language, if it were not THEIR high-level language, which was missing the point by the width of the horizon. Next we tried Perl. The thing we probably did not realize and certainly not appreciate the importance of, is that pretty much all other languages than Tcl, are languages you add things to, not languages you add to things. This has two implications: The first is that the only thing you gain by including such a language, is the ability to run scripts in it. That might improve (or not!) the readability of the rc.d scripts. The second is that such languages really do not want to be treated as house-guests in a software distribution. Maintaining them is a major hazzle and they all have fuzzy boundaries, in the sense that calls along the lines of "We should really import the P-FOO package/module/library also because it is so much more convenient..." will never cease. With Perl we found conclusively that the benefits did not even get close to balance the hazzle. And thus perl was also removed again. Based on what we learned, My advice would be: The window of opportunity for an embeddable language is long since closed. Nobody uses the base-system any more to an extent where it makes sense to bother about, for that concept to have been long term viable, it would have had to cross-fertilize into desktops (KDE, Gnome etc) and Apache. Adding any of the "big" languages (perl, python, ruby, ...) will not _ever_ pay off the costs, even if we exclude from the bill the friendly fire involved in determining which we pick. If it is the /bin/sh syntax that bothers you, set your eyes on gettung us a zsh or ksh upgrade, that may be feasible and would be sensible, considering what a new language can do for the base system. But otherwise: Forget it. Poul-Henning PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
> Personally, I think the whole "base" and "ports" thing is an artificial > divide that is rapidly losing utility. I think we're past due for > stripping the FreeBSD "base" down to a much more bare minimum, and > having a lot more of the bells and whistles live in the ports tree. Strongly disagree. One of the reasons I've been using FreeBSD for many years is precisely the fact that the base system is very good, and contains most of what I need without installing a lot of extra ports/ packages. (Yes, I always end up installing perl, but that is one of a select few.) If I only wanted a kernel and everything else as installable packages, I might as well use one of the Linux distributions. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
On Mon, 16 Aug 2010, Poul-Henning Kamp wrote: ... PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. Besides the syntax FORTH ist the only embeddable high level language which has both intepreter and compiler built in. It has a small form factor too. One alternative could be something like WABA (http://waba.sourceforge.net/). Besides the wrong license it would mean to have pre-compiled byte code on the FS and no chance to recompile on the fly... Or ECMAScript as a pure interpreted language. Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
On Mon, Aug 16, 2010 at 09:47:40AM +0200, sth...@nethelp.no wrote: > > Personally, I think the whole "base" and "ports" thing is an artificial > > divide that is rapidly losing utility. I think we're past due for > > stripping the FreeBSD "base" down to a much more bare minimum, and > > having a lot more of the bells and whistles live in the ports tree. > > Strongly disagree. One of the reasons I've been using FreeBSD for many > years is precisely the fact that the base system is very good, and > contains most of what I need without installing a lot of extra ports/ > packages. I can agree to this argument. While it is easy to install required tools on your system it is a hassle if you are doing support for systems installed by someone else. With FreeBSD you can expect a great set of tools already available. I remember the old days when I was doing embedded systems on tiny CF media and thought I only stripped the tools I really don't need, but in the end I often missed something. But I also never missed something with a complete base. Perl is a fancy tool, but when you really need it you don't have a problem in installing it. It is not that long time ago that a friend with his Linux couldn't even check the negotiated ethernet link without installing an additional tool - easy if you have network, but isn't this a tool to debug network problems? The last thing I've missed was something to script in single-user-mode. In loader we have FICL and in single-user-mode we have /bin/sh, while the shell is reasonable to write scripts it also requires external helpers which sits in non-mounted /usr - e.g.: grep, sed, lock, ... With todays disk and partition sizes however I don't split /usr - I split /usr/local (often don't even this), so this isn't a problem anymore. Having an embeddable lanmguage is another story - no matter if it is TCL, FICL, Lua or whatever. There is a possible benefit for extending our tools, but after reading PHKs history description I'm not that sure about it anymore. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
better way than hacking termcap to be ca_mode free
is there a better way to achieve this? randy *** termcap.FCS Tue Jun 17 15:10:46 2003 --- termcap Tue Jun 17 15:14:15 2003 *** *** 299,305 adm3|3|lsi adm3:\ :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: xterm|xterm-color|X11 terminal emulator:\ ! :ti@:te@:tc=xterm-xfree86: # # DESCRIPTION: # This file describes capabilities of various terminals, as needed by --- 299,305 adm3|3|lsi adm3:\ :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: xterm|xterm-color|X11 terminal emulator:\ ! :tc=xterm-xfree86: # # DESCRIPTION: # This file describes capabilities of various terminals, as needed by ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
Dimitry Andric writes: > - Uses plain file descriptors instead of struct FILE, since the > buffering is done manually anyway, and it makes it easier to support > gzip and bzip2. It might be worth a shot adding mmap(2) support as well, i.e. when processing an uncompressed regular file, try to mmap(2) it first, and if that fails, fall back to the plain buffered read(2) method. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Runaway intr, not flash related
On 16 August 2010 13:09, Doug Barton wrote: >> Can you remember the revision number of the last >> version of -CURRENT that didn't have these problems? > > It was at least a year ago, so no; I can't remember specifically. Have you tried running software build(s) from ~ 1.5 years ago to see whether it makes a difference? So it's still possibly hardware (which the software is somehow handling badly?) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
Doug Barton writes: > lua too "flavor of the day," not enough track record of stability, > not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Scripting language in base [was Re: Official request: Please make GNU grep the default]
Since this is now well off the original topic. On 2010-Aug-15 12:57:23 +0200, Ivan Voras wrote: >This is my long-term point - it really would be beneficial to have an >alternative, richer language in base which would fall between the >categories of "a good system language but far too complex for simple >string-parsing stuff" which is C and "a good glue language for system >utilities but lacking more evolved concepts" which is shell. I'd say the bigger problem with C is that its native string processing capabilities are basically non-existent. Compared to awk, perl, ruby, (insert your favourite scripting language here) or even sh, the equivalent code in C is going to be much longer and less clear. Note that the system does have a language intermediate between sh and C - awk. The main downside of awk is its lack of pipe support. >default. My current favorite is lua because it's very small and easily >embeddable and extendable by C code, but there are others - some >JavaScript engines probably fit the description. You have previously suggested importing lua. I'd suggest that all you need is the killer app written in lua to justify importing it. Another option might be ficl - the code is already in the base system, it would just need to be compiled. Of course, the downside is that FORTH is a very niche language. -- Peter Jeremy pgpjJGFhyLDo6.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
On 2010-08-15 21:49, Dimitry Andric wrote:
> ...I
> have attached a more complete patch that:
>
> - Replaces the horrendously inefficient grep_fgetln() with mostly the
> same implementation as the libc fgetln() function.
> - Uses plain file descriptors instead of struct FILE, since the
> buffering is done manually anyway, and it makes it easier to support
> gzip and bzip2.
> - Let the bzip2 reader just read the file as plain data, when the
> initial magic number doesn't match, mimicking the behaviour of GNU
> grep.
Here is a new patch, updated against Gabor's changes in r211364.
diff --git a/usr.bin/grep/fastgrep.c b/usr.bin/grep/fastgrep.c
index c66f0a7..30a2dc5 100644
--- a/usr.bin/grep/fastgrep.c
+++ b/usr.bin/grep/fastgrep.c
@@ -198,7 +198,7 @@ fastcomp(fastgrep_t *fg, const char *pat)
}
int
-grep_search(fastgrep_t *fg, unsigned char *data, size_t len, regmatch_t
*pmatch)
+grep_search(fastgrep_t *fg, const unsigned char *data, size_t len, regmatch_t
*pmatch)
{
unsigned int j;
int ret = REG_NOMATCH;
diff --git a/usr.bin/grep/file.c b/usr.bin/grep/file.c
index 1872d0e..185ab1d 100644
--- a/usr.bin/grep/file.c
+++ b/usr.bin/grep/file.c
@@ -37,7 +37,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -47,138 +47,160 @@ __FBSDID("$FreeBSD$");
#include "grep.h"
-static char fname[MAXPATHLEN]; /* file name */
+#defineMAXBUFSIZ (32 * 1024)
+#defineLNBUFBUMP 80
-#define MAXBUFSIZ (16 * 1024)
-#define PREREAD_M 0.2
+static gzFile gzbufdesc;
+static BZFILE* bzbufdesc;
-/* Some global variables for the buffering and reading. */
-static char*lnbuf;
-static size_t lnbuflen;
-static unsigned char *binbuf;
-static int binbufsiz;
-unsigned char *binbufptr;
-static int bzerr;
+static unsigned char buffer[MAXBUFSIZ];
+static unsigned char *bufpos;
+static size_t bufrem;
-#define iswbinary(ch) (!iswspace((ch)) && iswcntrl((ch)) && \
- (ch != L'\b') && (ch != L'\0'))
+static unsigned char *lnbuf;
+static size_t lnbuflen;
-/*
- * Returns a single character according to the file type.
- * Returns -1 on failure.
- */
-static inline int
-grep_fgetc(struct file *f)
+static int
+grep_refill(struct file *f)
{
- unsigned char c;
+ ssize_t nr;
+ int bzerr;
- switch (filebehave) {
- case FILE_STDIO:
- return (getc_unlocked(f->f));
- case FILE_GZIP:
- return (gzgetc(f->gzf));
- case FILE_BZIP:
- BZ2_bzRead(&bzerr, f->bzf, &c, 1);
- if (bzerr == BZ_STREAM_END)
- return (-1);
- else if (bzerr != BZ_SEQUENCE_ERROR && bzerr != BZ_OK)
- errx(2, "%s", getstr(2));
- return (c);
+ bufpos = buffer;
+ bufrem = 0;
+
+ if (filebehave == FILE_GZIP) {
+ nr = gzread(gzbufdesc, buffer, MAXBUFSIZ);
+ } else if (filebehave == FILE_BZIP && bzbufdesc != NULL) {
+ nr = BZ2_bzRead(&bzerr, bzbufdesc, buffer, MAXBUFSIZ);
+ switch (bzerr) {
+ case BZ_OK:
+ case BZ_STREAM_END:
+ /* No problem, nr will be okay */
+ break;
+ case BZ_DATA_ERROR_MAGIC:
+ /*
+* As opposed to gzread(), which simply returns the
+* plain file data, if it is not in the correct
+* compressed format, BZ2_bzRead() instead aborts.
+*
+* So, just restart at the beginning of the file again,
+* and use plain reads from now on.
+*/
+ BZ2_bzReadClose(&bzerr, bzbufdesc);
+ bzbufdesc = NULL;
+ if (lseek(f->fd, 0, SEEK_SET) == -1)
+ return (EOF);
+ nr = read(f->fd, buffer, MAXBUFSIZ);
+ break;
+ default:
+ /* Make sure we exit with an error */
+ nr = -1;
+ }
+ } else {
+ nr = read(f->fd, buffer, MAXBUFSIZ);
}
- return (-1);
+
+ if (nr <= 0)
+ return (EOF);
+
+ bufrem = nr;
+ return (0);
}
-/*
- * Returns true if the file position is a EOF, returns false
- * otherwise.
- */
-static inline int
-grep_feof(struct file *f)
+static int
+grep_lnbufgrow(size_t newlen)
{
+ unsigned char *p;
- switch (filebehave) {
- case FILE_STDIO:
- return (feof_unlocked(f->f));
- case FILE_GZIP:
- return (gzeof(f->gzf));
- case FILE_BZIP:
- return (bzerr == BZ_STREAM_END);
- }
- return (1);
+ if (lnbuflen >= newlen
Re: Interpreted language(s) in the base
> zsh less POSIX-compliant, oddly deviant from "standard" > bourne-derived shells which makes graybeards break out in hives > also, see ruby under user community ZSH has a POSIX-compliant interface through emulate -L sh or by naming (linking) zsh binary sh. even if the man page says that the posix compliance isn't complete from my own tests it is at least as compliant as bash. For example I'm able to run portmaster using zsh instead of sh. (by the way it is a lot faster using zsh :) but that is another storry) -- Bapt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
2010/8/16 Dag-Erling Smørgrav : > Doug Barton writes: >> lua too "flavor of the day," not enough track record of stability, >> not enough installed base/proven utility > > You're wrong. Lua has been around for ages and is especially widely > used as a game scripting engine. It is not intended as a standalone > language, but as an embeddable scripting engine. We could easily create > our own scripting language based on lua with FreeBSD-specific functions, > and there would be no fear of interfering with third-party software, > because it wouldn't be called lua. Replying randomly to this post but also to phk's, dougb's and others' points specifically about lua: 1. "churn" / version stability / "language of the day" History of lua's recent releases is: - 5.2 : TBD, new yet unfinished release, "will be done when it is done" - 5.1 : 2006. - 5.0 : 2003. - 4.0 : 2000. ... - 1.0 : 1993. [source: http://www.lua.org/versions.html] If anything, it's much slower than the "hip" languages. 2. Future compatibility / ports dependancies, etc. If anything gets imported, lua or something else, I will loudly support renaming it to something like "bsdscript", binaries and libraries and all. 3. Size of language Lua *is* 32 C files (and as many C headers) in a single directory, totalling (with headers) a bit over 17,000 lines. The interpreter can be compiled with "gcc -o bsdscript *.c". Libraries can be built similarly. There are no other libraries or modules which "make" lua, Among the mentioned above are equivalents of stdio, libm, libz, etc. 4. Embeddability Here's the documentation: http://www.lua.org/pil/24.1.html Personally, I'm more interested in the opposite direction: writing FreeBSD-specific lua libraries (which would wrap, as an obvious example coming from me, libgeom) making it possible to script complex system scripts in lua. 5. License Released under MIT license: http://www.lua.org/license.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 2010-Aug-16 10:55:18 +0200, Dag-Erling Smørgrav wrote: >It might be worth a shot adding mmap(2) support as well, i.e. when >processing an uncompressed regular file, try to mmap(2) it first, and if >that fails, fall back to the plain buffered read(2) method. Note that ZFS and mmap() don't get on especially well together so this isn't a definite win. You also need to allow for files that are too large to be mapped in one go. -- Peter Jeremy pgphMfssk1asB.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
On Sun, 15 Aug 2010, Dag-Erling Smørgrav wrote: "Sean C. Farley" writes: This should trim some time off BSD grep. Did you actually test your patch? It makes absolutely no measurable difference. Yes, I saw a reduction, using the first test script Doug provided, from 36 to 27 seconds. I only sent the patch after profiling confirmed a reduction. The script ran non-profiled grep 100 times. "Trim" did not imply it would reduce the time from 36 to 2 seconds. Here are profiles of one execution of bsdgrep using the parameters from the script. Non-patched grep (cumulative time 4.17 seconds): % cumulative self self total time seconds secondscalls ms/call ms/call name 79.5 3.32 3.320 100.00% _mcount [1] 7.9 3.65 0.330 100.00% .mcount (106) 4.5 3.83 0.19 21971711 0.00 0.00 fgetc [7] 3.5 3.98 0.15 21993762 0.00 0.00 grep_feof [8] 2.5 4.09 0.10 21971711 0.00 0.00 grep_fgetc [6] 1.5 4.15 0.0622051 0.00 0.02 grep_fgetln [5] 0.5 4.17 0.02 1352 0.02 0.02 read [9] 0.0 4.17 0.00 67 0.02 0.02 memset [14] 0.0 4.17 0.00 61 0.01 0.01 arena_run_split [17] 0.0 4.17 0.001 0.50 522.57 procfile [4] ... Patched grep (cumulative time 2.82 seconds): % cumulative self self total time seconds secondscalls ms/call ms/call name 77.4 2.19 2.190 100.00% _mcount [1] 8.4 2.42 0.240 100.00% .mcount (109) 6.1 2.60 0.17 21971711 0.00 0.00 grep_fgetc [6] 4.9 2.74 0.14 21993762 0.00 0.00 grep_feof [7] 2.7 2.81 0.0822051 0.00 0.02 grep_fgetln [5] 0.3 2.82 0.01 1352 0.01 0.01 _read [10] 0.1 2.82 0.00 67 0.03 0.03 memset [13] 0.1 2.82 0.00 10 0.15 0.15 free [16] 0.0 2.82 0.001 1.00 398.11 procfile [4] ... getc_unlocked() is merely a macro around __sgetr() as opposed to calling into getc(). My patch was to show it could be reduced by removing some of stdio's overhead (one function call and unneeded locking). I did not have time to do a complete removal of stdio as I was unsure of any dependencies this version of bsdgrep had on stdio. For some reason, I thought there was mention of making bsdgrep into an application and library. If threading became involved, losing fgetc() would help more. Without threading, the test for locking would still be performed in getc(). Sean -- s...@freebsd.org___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
"Sean C. Farley" writes: > Dag-Erling Smørgrav writes: > > Did you actually test your patch? It makes absolutely no measurable > > difference. > Yes, I saw a reduction, I didn't... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: better way than hacking termcap to be ca_mode free
Randy Bush writes:
> is there a better way to achieve this?
Not sure about ~/.termcap but you can just override ti/te via TERMCAP in
environment.
$ export TERM=${TERM:-xterm}
$ export TERMCAP=${TERM}:ti@:te@:tc=${TERM}:
>
> *** termcap.FCS Tue Jun 17 15:10:46 2003
> --- termcap Tue Jun 17 15:14:15 2003
> ***
> *** 299,305
> adm3|3|lsi adm3:\
> :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80:
> xterm|xterm-color|X11 terminal emulator:\
> ! :ti@:te@:tc=xterm-xfree86:
> #
> # DESCRIPTION:
> # This file describes capabilities of various terminals, as needed by
> --- 299,305
> adm3|3|lsi adm3:\
> :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80:
> xterm|xterm-color|X11 terminal emulator:\
> ! :tc=xterm-xfree86:
> #
> # DESCRIPTION:
> # This file describes capabilities of various terminals, as needed by
I guess the diff is not for termcap file from /head.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
Hi. Seeing on mostly idle, recently updated current, while closing a file. Presumably never reported on ML. lock order reversal: 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xff000234a048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1580 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 fdinit() at fdinit+0x5b fdcopy() at fdcopy+0x2a fork1() at fork1+0x836 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffea88, rbp = 0 --- -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 16 August 2010 21:05, pluknet wrote: > Hi. > > Seeing on mostly idle, recently updated current, while closing a file. > Presumably never reported on ML. > > lock order reversal: > 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > 2nd 0xff000234a048 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1580 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_xlock() at _sx_xlock+0x55 > fdinit() at fdinit+0x5b > fdcopy() at fdcopy+0x2a > fork1() at fork1+0x836 > kproc_create() at kproc_create+0x63 > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > nfs_asyncio() at nfs_asyncio+0xa6 > nfs_strategy() at nfs_strategy+0x83 > bufstrategy() at bufstrategy+0x43 > nfs_writebp() at nfs_writebp+0xcf > nfs_flush() at nfs_flush+0x1dc > nfs_close() at nfs_close+0x213 > vn_close() at vn_close+0x10e > vn_closefile() at vn_closefile+0x5a > _fdrop() at _fdrop+0x23 > closef() at closef+0x5b > kern_close() at kern_close+0x110 > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = > 0x7fffea88, rbp = 0 --- > > Mostly the same (different 2nd lock path). lock order reversal: 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0x80ca47e0 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c:335 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_slock() at _sx_slock+0x55 fork1() at fork1+0x190 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffea88, rbp = 0 --- -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: > On 16 August 2010 21:05, pluknet wrote: > > Hi. > > > > Seeing on mostly idle, recently updated current, while closing a file. > > Presumably never reported on ML. > > > > lock order reversal: > > 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > > 2nd 0xff000234a048 filedesc structure (filedesc structure) @ > > /usr/src/sys/kern/kern_descrip.c:1580 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_xlock() at _sx_xlock+0x55 > > fdinit() at fdinit+0x5b > > fdcopy() at fdcopy+0x2a > > fork1() at fork1+0x836 > > kproc_create() at kproc_create+0x63 > > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > > nfs_asyncio() at nfs_asyncio+0xa6 > > nfs_strategy() at nfs_strategy+0x83 > > bufstrategy() at bufstrategy+0x43 > > nfs_writebp() at nfs_writebp+0xcf > > nfs_flush() at nfs_flush+0x1dc > > nfs_close() at nfs_close+0x213 > > vn_close() at vn_close+0x10e > > vn_closefile() at vn_closefile+0x5a > > _fdrop() at _fdrop+0x23 > > closef() at closef+0x5b > > kern_close() at kern_close+0x110 > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = > > 0x7fffea88, rbp = 0 --- > > > > > > Mostly the same (different 2nd lock path). > > lock order reversal: > 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > 2nd 0x80ca47e0 proctree (proctree) @ > /usr/src/sys/kern/kern_fork.c:335 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_slock() at _sx_slock+0x55 > fork1() at fork1+0x190 > kproc_create() at kproc_create+0x63 > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > nfs_asyncio() at nfs_asyncio+0xa6 > nfs_strategy() at nfs_strategy+0x83 > bufstrategy() at bufstrategy+0x43 > nfs_writebp() at nfs_writebp+0xcf > nfs_flush() at nfs_flush+0x1dc > nfs_close() at nfs_close+0x213 > vn_close() at vn_close+0x10e > vn_closefile() at vn_closefile+0x5a > _fdrop() at _fdrop+0x23 > closef() at closef+0x5b > kern_close() at kern_close+0x110 > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = > 0x7fffea88, rbp = 0 --- > Both LORs are valid. The fork performed deep inside the VFS call stack is obviously problematic. As a workaround, you may fix the number of nfsiods. Proper fix might consist of creating a shepherd thread which only task is to act on the requests on creating new nfsiods. Would you try to implement this ? I will provide the assistance, if needed. pgpF9gJFtMFVc.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
Em 2010.08.15. 21:49, Dimitry Andric escreveu: GNU grep Elapsed time: 57 seconds BSD grep (original) Elapsed time: 820 seconds (~14.4x slower than GNU grep) BSD grep (quickfixed) Elapsed time: 115 seconds (~2.0x slower than GNU grep) It proves that getting rid of the fgetc's is certainly worthwhile, and I have attached a more complete patch that: - Replaces the horrendously inefficient grep_fgetln() with mostly the same implementation as the libc fgetln() function. - Uses plain file descriptors instead of struct FILE, since the buffering is done manually anyway, and it makes it easier to support gzip and bzip2. - Let the bzip2 reader just read the file as plain data, when the initial magic number doesn't match, mimicking the behaviour of GNU grep. There is probably more room for optimization, but let's see if this survives a bunch of tests first. :) Thanks Dmitry, I've also started to work on a similar solution but you were extremely fast. :) I'm checking your patch just now and will tell my experiences if I see any regression. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
Em 2010.08.16. 16:11, Dag-Erling Smørgrav escreveu: "Sean C. Farley" writes: Dag-Erling Smørgrav writes: Did you actually test your patch? It makes absolutely no measurable difference. Yes, I saw a reduction, I didn't... I also saw a reduction by 8-30% depending on the particular case. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Performance AMD Phenom II X6 1090T
Is there anyone using AMD Phenom II X6 1090T? What can you say about it's performance? Have you any tasks that use all 6-cores? Does it balance workload between all 6 cores properly? I am interested how it will work specifically under 8.1-RELEASE and 9.0-CURRENT. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
On 08/16/2010 00:47, sth...@nethelp.no wrote: If I only wanted a kernel and everything else as installable packages, I might as well use one of the Linux distributions. That wasn't at all what I said, or what I was suggesting. There is a middle ground between "everything is a package" and the status quo. The fact that people keep asking for more things to be in the base that clearly don't/can't belong there is evidence of this. Meanwhile, to respond more or less generally to some of the specific responses I received: 1. My descriptions of the various possible things to import were meant to be tongue-in-cheek, not exhaustive technical reviews of the alternatives. The fact that some people "bit" on those, particularly the ones that described rabid user communities, is, well, funny. :) 2. phk's description of the the situation with tcl is both more eloquent and more complete than I could have come up with, which is why I didn't mention it in my previous post. Although the situation with perl is more vivid for me since I was directly affected by it my recollections of the tcl thing match his description, and more importantly I agree with him that it should be viewed as a cautionary tale. 3. In case I wasn't clear in my last post the correct answer at this time is neither "import more stuff into the base" nor "turn more things into packages." It's "write good apps using the tool(s) of your own choosing and we'll find a way to make it work." Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: better way than hacking termcap to be ca_mode free
On Mon, 16 Aug 2010 at 04:50 -, Randy Bush wrote: > is there a better way to achieve this? I'm not sure what ca_mode is, but I have the following in my .Xresources file: XTerm*tiXtraScroll: true XTerm*titeInhibit: true These get rid of the silly alternate screen in vi, etc. There are also similar options directly to xterm. Stuart Barkley -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS will gone,FreeBSD will import btrfs?
opensolaris is gone,ZFS also gone. Will FreeBSD import btrfs or other similar file system? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Official request: Please make GNU grep the default
On 08/16/2010 03:42, Dimitry Andric wrote: On 2010-08-15 21:49, Dimitry Andric wrote: ...I have attached a more complete patch that: - Replaces the horrendously inefficient grep_fgetln() with mostly the same implementation as the libc fgetln() function. - Uses plain file descriptors instead of struct FILE, since the buffering is done manually anyway, and it makes it easier to support gzip and bzip2. - Let the bzip2 reader just read the file as plain data, when the initial magic number doesn't match, mimicking the behaviour of GNU grep. Here is a new patch, updated against Gabor's changes in r211364. Huge improvement! r211364:With your patch: ./grep-time-trial GNU grep Elapsed time: 2 seconds BSD grepBSD grep Elapsed time: 33 secondsElapsed time: 16 seconds ./grep-time-trial-2 GNU grep Elapsed time: 3 seconds BSD grepBSD grep Elapsed time: 18 secondsElapsed time: 11 seconds -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS will gone,FreeBSD will import btrfs?
On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: > opensolaris is gone It appears there will be a fork, but that's not particularly crucial to FreeBSD. > ZFS also gone. We're not going to drop ZFS because Oracle's plans are unclear. It remains to be seen how much other community support there is behind ZFS. > Will FreeBSD import btrfs or other similar file system? >From my observation, it takes about 2 years from the initial work on a new filesystem until it's relatively stable, so I don't know why we would suddenly decide to go that direction. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS will gone,FreeBSD will import btrfs?
Thanks for your reply. 2010/8/17 Mark Linimon : > On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: >> opensolaris is gone > > It appears there will be a fork, but that's not particularly crucial > to FreeBSD. > >> ZFS also gone. > > We're not going to drop ZFS because Oracle's plans are unclear. It > remains to be seen how much other community support there is behind ZFS. > >> Will FreeBSD import btrfs or other similar file system? > > From my observation, it takes about 2 years from the initial work on a > new filesystem until it's relatively stable, so I don't know why we would > suddenly decide to go that direction. > > mcl > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Interpreted language(s) in the base
2010/8/16 Dag-Erling Smørgrav : > Doug Barton writes: >> lua too "flavor of the day," not enough track record of stability, >> not enough installed base/proven utility > > You're wrong. Lua has been around for ages and is especially widely > used as a game scripting engine. It is not intended as a standalone > language, but as an embeddable scripting engine. We could easily create > our own scripting language based on lua with FreeBSD-specific functions, > and there would be no fear of interfering with third-party software, > because it wouldn't be called lua. It looks like this is rearing its head again elsewhere: http://mail-index.netbsd.org/tech-userlevel/2009/10/24/msg002827.html http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd/t127230760748 "Student Name: Lourival Vieira Organization: The NetBSD Foundation Organization Home Page: http://www.netbsd.org/ Mentor Name: Marc Balmer Title: Provide support for dynamic NetBSD kernel extensions using the Lua language - Lunatik/NetBSD Abstract: This project has the goal to develop a framework to provide support for dynamically extending the NetBSD kernel using the Lua programming language. I intend to allow adaptation of the kernel and its subsystems for different purposes at runtime, through download of Lua scripts and exposure of kernel internals to Lua. Moreover, this framework will provide support for rapid prototyping and experimentation with new algorithms and mechanisms inside the kernel." b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
