On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
>
> This is the biggest one, and I think it may be too soon. Also, we
> need to be careful on the initialization side of things because we
> currently have a lot of code that looks like:
>
>
> struct foo *fp;
> struct b
Well I agree with the proposed changes.
What about allowing // comments?
___
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"
M. Warner Losh wrote:
Hunting for declarations sucks
I'd rather hunt a bit for its declaration and find uses of it on the
way, rather than find the declaration..and then what?
This is a religious point, and we're dangerously close to saying my
religion is better than your religion. I don't
On 2009-05-01 15:50:38, Alexander Kabaev wrote:
> On Fri, 1 May 2009 20:21:13 +0100
> xorquew...@googlemail.com wrote:
>
> > Hello.
> >
> > Checking back through my sent mail from the DRI thread, this version
> > of -STABLE was checked out and compiled on Fri, 10 Apr 2009 16:42:51
> > +0100.
> >
Hi all,
I'm a PhD student, this summer I'll work on a SoC project on disk
scheduling. I will extend the work we started with luigi, that we already
presented in [1, 2]. Two of the main areas that still need improvement,
and that will be considered during the project, are doing proper request
cl
M. Warner Losh schrieb:
In message: <49fa8d73.6040...@gmx.de>
Christoph Mallon writes:
: M. Warner Losh schrieb:
: > In message: <20090428114754.gb89...@server.vk2pj.dyndns.org>
: > Peter Jeremy writes:
: > : >> +.Sh LOCAL VARIABLES
: > :
: > : >Last, but definitely not
On Fri, 1 May 2009, Christoph Mallon wrote:
Daniel Eischen schrieb:
+1 for leaving style(9) alone.
Have you looked at all the proposed changes? I ask to consider them
individually.
Point taken, my previous comment will only be for the
part about inline declarations. I'll go back and look
Marius Strobl schrieb:
On Fri, May 01, 2009 at 01:37:23PM +0200, Christoph Mallon wrote:
Marius Strobl schrieb:
On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
return with parentheses:
Removed, because it does not improve maintainability in any way. There
is no source for co
Daniel Eischen schrieb:
+1 for leaving style(9) alone.
Have you looked at all the proposed changes? I ask to consider them
individually.
Christoph
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
On Fri, May 1, 2009 at 4:30 AM, Julian Elischer wrote:
> As an old-fart I have found many cases where what I thought was
> a silly style rule, turned out to save my work in some way.
>
> Christoph Mallon wrote:
>
>
>
>>>
>>>struct foo *fp;
>>>struct bar *bp;
>>>
>>>fp = get_foo();
>>>
Julian Elischer schrieb:
Christoph Mallon wrote:
You are mistaken. Re-read the "if": It already contains a "return;" as
then-part. The declaration of "bp" has no relation to the "if".
In fact this is very good: "bp" can only be used after the "if",
because it is declared after it. Further, i
Christoph Mallon wrote:
You are mistaken. Re-read the "if": It already contains a "return;" as
then-part. The declaration of "bp" has no relation to the "if".
In fact this is very good: "bp" can only be used after the "if", because
it is declared after it. Further, it most probably is only as
Zaphod Beeblebrox schrieb:
On Fri, May 1, 2009 at 4:30 AM, Julian Elischer wrote:
As an old-fart I have found many cases where what I thought was
a silly style rule, turned out to save my work in some way.
Christoph Mallon wrote:
struct foo *fp;
struct bar *bp;
fp = get_foo();
Hello,
my name is Marta Carbone, I am at the first year of my PhD program in
Information Engineering at the University of Pisa.
As part of the Google SoC I will work on FreeBSD ipfw and dummynet.
My mentor is Luigi Rizzo. The main goal of the project is to revise
and improve the ipfw and dummy
On Fri, 1 May 2009 20:21:13 +0100
xorquew...@googlemail.com wrote:
> Hello.
>
> Checking back through my sent mail from the DRI thread, this version
> of -STABLE was checked out and compiled on Fri, 10 Apr 2009 16:42:51
> +0100.
>
> The machine was so new that I hadn't even set the clock, so the
On 2009-05-01 15:13:08, Alexander Kabaev wrote:
> How recent are your sources? There were a number of bugs introduced and
> then fixed in releng/7.2 and stable/7 and line number you post does not
> match anything interesting in either.
>
> Please make sure you have latest vfs_cache.c file at the l
How recent are your sources? There were a number of bugs introduced and
then fixed in releng/7.2 and stable/7 and line number you post does not
match anything interesting in either.
Please make sure you have latest vfs_cache.c file at the least.
--
Alexander Kabaev
signature.asc
Description: P
On Fri, May 01, 2009 at 11:28:02AM -0700, Yuri wrote:
> When I run cycle process: main() {for (;;) {}} I never see that it
> consumes ~100% CPU.
> Instead 'top -C' shows something like this, with numbers fluctuating
> around the shown numbers:
>
>
> CPU: 96.2% user, 0.0% nice, 20.0% system, 0
Alexey Shuvaev wrote:
Strange is 20% system load. The summary line is about all cpus/cores/...
Correction: instead of 20% should be 3.8%.
Also if this matters I have FreeBSD 7.2, single CPU AMD3200 @ 2GHz.
Yuri
___
freebsd-hackers@freebsd.org mai
When I run cycle process: main() {for (;;) {}} I never see that it
consumes ~100% CPU.
Instead 'top -C' shows something like this, with numbers fluctuating
around the shown numbers:
CPU: 96.2% user, 0.0% nice, 20.0% system, 0.0% interrupt, 0.0% idle
Mem: 653M Active, 995M Inact, 241M Wired,
2009/5/1 :
> Filed under:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=134142
>
> Would be incredibly grateful if somebody in the know could take
> a look at this.
But, what's the panic message?
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
M. Warner Losh wrote:
[...]
(about return ();)
It has been an example used for the past 15 years at least as to why
to do this... I don't know how many people have actually used the
ability to do this in code.
I have done so..
: Also I consider this as gross abuse: Macro names shall be i
On 2009-05-01 19:39:43, Attilio Rao wrote:
> 2009/5/1 :
> > Filed under:
> >
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=134142
> >
> > Would be incredibly grateful if somebody in the know could take
> > a look at this.
>
> But, what's the panic message?
>
It's at the bottom:
Fatal trap 12:
Filed under:
http://www.freebsd.org/cgi/query-pr.cgi?pr=134142
Would be incredibly grateful if somebody in the know could take
a look at this.
xw
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
On behalf of the Program Committee, I would like to invite you to submit
your work to the USENIX Conference on Web Application Development
(WebApps '10).
WebApps '10 is a new technical conference designed to bring together
experts in all aspects of developing and deploying Web applications.
Sugg
> > [snip exciting discussion on style]
> >
> > > There are several C99 features used already, e.g. designated
initializers:
> > > bla bli = { .blub = "foo", .arr[0] = 42 };
> > > Do you suggest that this should not be used, because it is
inconsistent
> > > with all the other existing compound i
On Fri, 01 May 2009 08:57:34 PDT "Matthew Fleming"
wrote:
> [snip exciting discussion on style]
>
> > There are several C99 features used already, e.g. designated initializers:
> > bla bli = { .blub = "foo", .arr[0] = 42 };
> > Do you suggest that this should not be used, because it is inco
Hello Hackers,
We came into a Cobalt Raq 550 the other day and were wondering if we
could put it to use. I've googled and googled and found only guides
for Linux installs. Much of it is quite similar, but my issue is with
the loader on the device being able to boot into FreeBSD. The device
searche
[snip exciting discussion on style]
> There are several C99 features used already, e.g. designated
initializers:
> bla bli = { .blub = "foo", .arr[0] = 42 };
> Do you suggest that this should not be used, because it is
inconsistent
> with all the other existing compound initialisations?
Re
In message: <20090501.081229.1359784281@bsdimp.com>
M. Warner Losh writes:
: In message: <49fa8e88.1040...@gmx.de>
: Christoph Mallon writes:
: : M. Warner Losh schrieb:
: : > In message: <20090430233648.ga95...@keira.kiwi-computer.com>
: : > "Rick C. Petty
In message: <49fadef3.5010...@gmx.de>
Christoph Mallon writes:
: Marius Strobl schrieb:
: > On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
: >> return with parentheses:
: >> Removed, because it does not improve maintainability in any way. There
: >> is no source for
In message: <49fa8e88.1040...@gmx.de>
Christoph Mallon writes:
: M. Warner Losh schrieb:
: > In message: <20090430233648.ga95...@keira.kiwi-computer.com>
: > "Rick C. Petty" writes:
: > : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
: > : >
: > : > This
In message: <49fa8d73.6040...@gmx.de>
Christoph Mallon writes:
: M. Warner Losh schrieb:
: > In message: <20090428114754.gb89...@server.vk2pj.dyndns.org>
: > Peter Jeremy writes:
: > : >Maybe using all of these changes is a bit too big change at once, but
: > : >I'd like
Hi Jan,
Jan Melen wrote:
Hi,
Again when I compiled a custom kernel just to enable IPsec in the
FreeBSD kernel it came to my mind why is it so that the IPsec is not
enabled by default in the GENERIC kernel configuration file? At least
for me the GENERIC kernel configuration would do just fin
Hello.
After extensive hardware testing, new thermal compound, new case and a
lot of work improving airflow, I'm now confident my new machine is OK
from a hardware point of view (a weeks worth of memory testing, days
of running prime95, temperature monitoring, extensive sessions with
sysutils/stre
> On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
> >
> > return with parentheses:
> > Removed, because it does not improve maintainability in any way. There
> > is no source for confusion here, so the rule even contradicts the rule,
> > which states not to use redundant parent
On Fri, May 01, 2009 at 01:37:23PM +0200, Christoph Mallon wrote:
> Marius Strobl schrieb:
> >On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
> >>return with parentheses:
> >>Removed, because it does not improve maintainability in any way. There
> >>is no source for confusion her
On Thu, 30 Apr 2009 20:32:00 +0100 (BST)
Robert Watson wrote:
>
> On Thu, 30 Apr 2009, Oliver Pinter wrote:
>
> > Is the FreeBSD's FS management so slow?
> >
> > http://www.netbsd.org/~ad/50/img15.html
> >
> > Or so big is the difference between the two cpu scheduler?
>
> Also, there's a known
Peter Jeremy schrieb:
On 2009-Apr-26 09:02:36 +0200, Christoph Mallon wrote:
as some of you may have noticed, several years ago a new millenium
started and a decade ago there was a new C standard.
Your implication that FreeBSD is therefore a decade behind the times
is unfair. Whilst the C99
Christoph Mallon wrote:
Roman Divacky schrieb:
I like the part about using as many variables as possible because
of documentation and performance enhancements. I tend to like
the other changes as well..
This is not about using as many variables as possible. The goal is to
use as many variable
Julian Elischer schrieb:
Christoph Mallon wrote:
No, this is not what I intended. The idea is to limit the scope of
local variables as much as is sensible. Maybe I should have been more
explicit. On the other hand, I also did not mention that it is just
about moving to the start of inner block
On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
>
> return with parentheses:
> Removed, because it does not improve maintainability in any way. There
> is no source for confusion here, so the rule even contradicts the rule,
> which states not to use redundant parentheses. Maybe
Marius Strobl schrieb:
On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
return with parentheses:
Removed, because it does not improve maintainability in any way. There
is no source for confusion here, so the rule even contradicts the rule,
which states not to use redundant par
Julian Elischer schrieb:
As an old-fart I have found many cases where what I thought was
a silly style rule, turned out to save my work in some way.
Christoph Mallon wrote:
struct foo *fp;
struct bar *bp;
fp = get_foo();
if (!fp) return;
bp = fp->bp;
this can't easily
On Fri, 01 May 2009 01:30:26 -0700
Julian Elischer wrote:
> Christoph Mallon wrote:
> >>
> >> since really you'd want to write:
> >>
> >> struct foo *fp = get_foo();
> >> if (!fp) return;
> >> struct bar *bp = fp->bp;
> >>
> >> which isn't legal in 'C'. However, we have enough where
Christoph Mallon wrote:
M. Warner Losh schrieb:
In message: <20090430233648.ga95...@keira.kiwi-computer.com>
"Rick C. Petty" writes:
: On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote:
: > : > This is the biggest one, and I think it may be too soon.
Also, we
: > nee
As an old-fart I have found many cases where what I thought was
a silly style rule, turned out to save my work in some way.
Christoph Mallon wrote:
struct foo *fp;
struct bar *bp;
fp = get_foo();
if (!fp) return;
bp = fp->bp;
this can't easily be translated to the more
47 matches
Mail list logo
