Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote: I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. exactly my point, huge patches are impossible to review. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) that is indeed a good source for having a look at early-alpha-WIP stuff. As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. I see company contributed code as ad-hoc solution to the company's problem, not general solution for the whole FreeBSD userbase. To make a comparison with Linux, it is just as if Google got all the Android code merged in mainline as-is, without re-working anything. It did not happen that way. Much of their code had (and still has) to be re-designed, abstracted, and adapted to fit the general-purpose mainline. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160992 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156540 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156799 ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027400.html ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030076.html ? answer to all the above: no, this is bugs, regressions, and mis-design you folks introduced, not me. Don't blame me to point it out. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. There is tons of ad-hoc code in FreeBSD which should be properly generalized. The most silly example I can think about is `time_after()', defined in net80211/ieee80211_freebsd.h. This has _nothing_ to do specifically with IEEE802.11, it's about time manipulation. Feel free to search the tree, there is tons of potentially unsafe, open-coded version of this macros. Call it nit-picking if you want, but when I write code, I want an API to use, I'm fed up to always have to re-invent the wheel. Btw, I do not even speak about some functions in the kernel re-implementing the exact same logic +10 times in a row, one after the other, within the same function body... For the story, I've been hacking tonight in Linux... a pure pleasure, real tough to get to, but really enjoyable. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. I already commented on this. I'm no longer interested in getting my stuff integrated in FreeBSD. I put it on github, eventually send patches on MLs, then you do what you want with it, I no longer particularly care. I know some patches are used around, that's enough. I did my time fighting committers to fix their not-so-bugfree code and won those battles, that's enough for me. - Arnaud ps: I have a particular appreciation for this PR, a feature praised by users, and no committer dares to care: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/161553 ... silly. ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 25, 2012 at 9:58 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote: I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. exactly my point, huge patches are impossible to review. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) that is indeed a good source for having a look at early-alpha-WIP stuff. As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. I see company contributed code as ad-hoc solution to the company's problem, not general solution for the whole FreeBSD userbase. To make a comparison with Linux, it is just as if Google got all the Android code merged in mainline as-is, without re-working anything. It did not happen that way. Much of their code had (and still has) to be re-designed, abstracted, and adapted to fit the general-purpose mainline. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160992 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156540 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156799 ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027400.html ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030076.html ? answer to all the above: no, this is bugs, regressions, and mis-design you folks introduced, not me. Don't blame me to point it out. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. There is tons of ad-hoc code in FreeBSD which should be properly generalized. The most silly example I can think about is `time_after()', defined in net80211/ieee80211_freebsd.h. This has _nothing_ to do specifically with IEEE802.11, it's about time manipulation. Feel free to search the tree, there is tons of potentially unsafe, open-coded version of this macros. Call it nit-picking if you want, but when I write code, I want an API to use, I'm fed up to always have to re-invent the wheel. Btw, I do not even speak about some functions in the kernel re-implementing the exact same logic +10 times in a row, one after the other, within the same function body... For the story, I've been hacking tonight in Linux... a pure pleasure, real tough to get to, but really enjoyable. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. I already commented on this. I'm no longer interested in getting my stuff integrated in FreeBSD. I put it on github, eventually send patches on MLs, then you do what you want with it, I no longer particularly care. I know some patches are used around, that's enough. I did my time fighting committers to fix their not-so-bugfree code and won those battles, that's enough for me. What I'm completely missing is the reason why you're repeating this is my last word or that's enough for me or $THATSALLFOLKS_SENTENCE, but you continue adding some Gaussian noise on the MLs w/out a valid reason. If you enjoy other projects, go there. But please, don't piss off. - Arnaud ps: I have a particular appreciation for this PR, a feature praised by users, and no committer dares to care: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/161553 ... silly. ___ freebsd-hackers@freebsd.org mailing list
mdconfig(8) argument parsing.
Patch below changes the way mdconfig(8) parses its arguments: it removes the ordering requirement and makes error messages more descriptive; it also makes the code more readable by getting rid of the 'cmdline' variable. Now, the mdconfig(8) syntax is somewhat weird, and I'm not sure I tested all the ways people use it. Thus, testing is welcome. http://people.freebsd.org/~trasz/mdconfig-parsing.diff -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: mdconfig(8) argument parsing.
On 1/25/12 11:44 AM, Edward Tomasz Napierała wrote: Patch below changes the way mdconfig(8) parses its arguments: it removes the ordering requirement and makes error messages more descriptive; it also makes the code more readable by getting rid of the 'cmdline' variable. Now, the mdconfig(8) syntax is somewhat weird, and I'm not sure I tested all the ways people use it. Thus, testing is welcome. http://people.freebsd.org/~trasz/mdconfig-parsing.diff Against what version is this patched ? We're running 8.2-RELEASE here at work, I've got private boxes with 8.2-STABLE, and 2 test ones with 9.0-RELEASE. ___ 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: mdconfig(8) argument parsing.
On Wed, Jan 25, 2012 at 11:52:02AM +0100, Damien Fleuriot wrote: On 1/25/12 11:44 AM, Edward Tomasz Napierała wrote: Patch below changes the way mdconfig(8) parses its arguments: it removes the ordering requirement and makes error messages more descriptive; it also makes the code more readable by getting rid of the 'cmdline' variable. Now, the mdconfig(8) syntax is somewhat weird, and I'm not sure I tested all the ways people use it. Thus, testing is welcome. http://people.freebsd.org/~trasz/mdconfig-parsing.diff Against what version is this patched ? We're running 8.2-RELEASE here at work, I've got private boxes with 8.2-STABLE, and 2 test ones with 9.0-RELEASE. Against 10.0-CURRENT (i.e. HEAD), but it should work on other versions as well. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
On 2012-01-23 19:46, Ed Maste wrote: ... Do you have the reproduction steps documented somewhere (and if not, can you write them up)? In order to have working automated installs we need to be able to unconditionally reinit a drive w/o having behavoiur depend on what happens to be left behind. Maybe just zero the first and last N sectors of the drive, where N is 10,000 or greater? ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. mcl ___ 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: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
On Jan 25, 2012, at 4:50 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-01-23 19:46, Ed Maste wrote: ... Do you have the reproduction steps documented somewhere (and if not, can you write them up)? In order to have working automated installs we need to be able to unconditionally reinit a drive w/o having behavoiur depend on what happens to be left behind. Maybe just zero the first and last N sectors of the drive, where N is 10,000 or greater? gpart destroy -F adaX Worked. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
kqueue and note_rename
Hello list, does anybody have an idea, how to obtain the new name of a renamed file after the note_rename event is fired. I'm not very familiar with filesystem-operations. I checked the typical functions like stat or lstat, but these functions are working only with filenames. Matthias ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote: You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. I'm talking about the semantics of the non-technical part: the wording of things that people post in email. viz: the time-wasting nonsense about oh, it seems to be released already, has anyone noticed? from a few weeks ago. It was 100% FUD, which apparently you knew perfectly well at the time, and thus AFAICT only posted it to draw attention to yourself. That's the drama I'm talking about. mcl ___ 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: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Wed, Jan 25, 2012 at 3:22 PM, Mark Linimon lini...@lonesome.com wrote: On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote: You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. I'm talking about the semantics of the non-technical part: the wording of things that people post in email. viz: the time-wasting nonsense about oh, it seems to be released already, has anyone noticed? from a few weeks ago. It was 100% FUD, which apparently you knew perfectly well at the time, and thus AFAICT only posted it to draw attention to yourself. That's the drama I'm talking about. you are misquoting and misinterpreting me, I merely asked Has 9.0 been released ?, followed by misleading clues I tried to gather in a thread where the original poster's uname shown 9-RELEASE. I see no FUD in this and none was intended. The rest of the thread indeed went ballistic. - Arnaud ___ 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: kqueue and note_rename
On 1/25/12 10:44 AM, Matthias Zitzen wrote: Hello list, does anybody have an idea, how to obtain the new name of a renamed file after the note_rename event is fired. I'm not very familiar with filesystem-operations. I checked the typical functions like stat or lstat, but these functions are working only with filenames. there is no real way. the new link to the inode could come from any point in the filesystem so the only way to find it would be an exhaustive search. the only information that you could return that might make any sense would be the inode number of the new parent. That would allow you to follow the '..' links and do 'pwd' in effect. I have not checked to see if that information is returned. If it isn't it might be a really nice enhancement to see if it could be added. Matthias ___ 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 ___ 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
sh(1) vfork patch, with benchmarks
Here is a new version of the vfork patch. The concept is the same, trying to use vfork in simple common cases. Compared to http://lists.freebsd.org/pipermail/freebsd-hackers/2011-June/035618.html I have extended vfork use to some command substitutions and allowed setting an environment variable SH_DISABLE_VFORK to disable all vfork use. The test machine is a 4-core Phenom II X4 in 32-bit mode with 4GB RAM, stable/8 with newer sh. I have run tests with a dummy environment variable SH_DISABLE_VFORL=1 (y) and with SH_DISABLE_VFORK=1 (n). A microbenchmark sh -c 'x=0; while [ $x -lt 1 ]; do /bin/kill -0 $$; x=$(($x + 1)); done' is much faster: x micro-vfork-timings1-n + micro-vfork-timings1-y +--+ |+ | |+ x | | + ++ x xx | |++ ++ xx xx x| | |_A||___AM_| | +--+ N Min MaxMedian AvgStddev x 9 3.86 4.05 4 3.963 0.076648549 + 9 2.52 2.6 2.58 2.572 0.033082389 Difference at 95.0% confidence -1.39111 +/- 0.0589948 -35.0995% +/- 1.48851% (Student's t, pooled s = 0.0590315) A make -j4 buildkernel is about 0.5% faster: x buildkernel-vfork-timings-n + buildkernel-vfork-timings-y +--+ | + x + | |+ + +* + + +x*+xx+ x xx x + x x x *+ * x+ x| ||__|M_AMA|___|| +--+ N Min MaxMedian AvgStddev x 17 435.3443.65 438.8 439.03588 2.378805 + 17 432.8442.86436.76 437.06412 3.20108 Difference at 95.0% confidence -1.97176 +/- 1.97034 -0.449112% +/- 0.448789% (Student's t, pooled s = 2.82007) In both cases, the difference comes mainly from the system time, but the user time is also a bit lower (statistically significant). In a virtual machine with 10-current (default kernel config + capsicum and procdesc) and the patch, the microbenchmark is similarly much faster: x micro-vfork-timings-n + micro-vfork-timings-y +--+ |+ + | |+++ x | |xx x | | xx | |+ x xxx| ||_A| |_A_| | +--+ N Min MaxMedian AvgStddev x 18 15.14 15.85 15.5715.5550.17088868 + 18 9.79 10.14 9.92 9.9127778 0.096820365 Difference at 95.0% confidence -5.64222 +/- 0.0940703 -36.2727% +/- 0.604759% (Student's t, pooled s = 0.138883) Ian Lepore has been kind enough to try an earlier version of this patch on some sort of ARM board and reports an improvement in boot time from 54 to 51 seconds, and a large difference in microbenchmarks. commit f55a350fa9c3792e10f93160a93d016a7bfdd630 Author: Jilles Tjoelker jil...@stack.nl Date: Mon May 30 00:31:45 2011 +0200 sh: Use vfork in a few common cases. This uses vfork() for simple commands and command substitutions containing a single simple command, invoking an external program under certain conditions (no redirections or variable assignments, non-interactive shell, no job control). The use of vfork() can be disabled by setting a variable named SH_DISABLE_VFORK. diff --git a/bin/sh/eval.c b/bin/sh/eval.c index a5f0aff..2d90921 100644 --- a/bin/sh/eval.c +++ b/bin/sh/eval.c @@ -921,6 +921,15 @@ evalcommand(union node *cmd, int flags, struct backcmd *backcmd) if (pipe(pip) 0) error(Pipe call failed: %s, strerror(errno)); } + if (cmdentry.cmdtype == CMDNORMAL +
Re: sh(1) vfork patch, with benchmarks
On Wed, Jan 25, 2012 at 11:54:46PM +0100, Jilles Tjoelker wrote: [snip] x micro-vfork-timings1-n + micro-vfork-timings1-y +--+ |+ | |+ x | | + ++ x xx | |++ ++ xx xx x| | |_A| |___AM_| | +--+ N Min MaxMedian AvgStddev x 9 3.86 4.05 4 3.963 0.076648549 + 9 2.52 2.6 2.58 2.572 0.033082389 Difference at 95.0% confidence -1.39111 +/- 0.0589948 -35.0995% +/- 1.48851% (Student's t, pooled s = 0.0590315) [snip] I forgot to mention, the numbers are time in seconds (measured with /usr/bin/time). -- Jilles Tjoelker ___ 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
