Re: C99: Suggestions for style(9)
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 bar *bp; > > fp = get_foo(); > if (!fp) return; > bp = fp->bp; > > this can't easily be translated to the more natural: > > struct foo *fp = get_foo(); > struct bar *bp = fp->bp; > > 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'. I thought we were talking about C99, in which case this is perfectly legal. I certainly use it all the time in my C99 code. And I thought this was the point of this discussion, to be able to declare variables when you first use them. -- Rick C. Petty ___ 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: C99: Suggestions for style(9)
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"
Re: C99: Suggestions for style(9)
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 like this part of the proposal at all. I can see the value in relaxing it for when you have a series of variables that are initialized, but relaxing it to the point where you intermix code and declarations goes way too far. It is bad enough to have to deal with inner scopes, but tolerable. It is intolerable to have to look for it anywhere in a big function. It tends to encourage spaghetti code, which is one of the things that style(9) tries to discourage in many subtle ways. If there is a function so big that it overwhelms you at first look, do not make micro changes to parts unless you know what you are doing, that is, you basically looked through the function. I think the thinking required for a linear skim is decreased with localized code. And instead of making large functions, isn't it recommended to divide it into subfunctions, which self-documents the code? So you should be able to see the declaration "just" above the use. But let's consider large functions. If, and after looking at the top of the function, you can't see the declatation there either, the only thing you have to do is run a search down the function, and the declaration is found [epsilon time wasted?]. ___ 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: vfs_cache panic, 7.2-prerelease (stable)
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. > > > > The machine was so new that I hadn't even set the clock, so the kernel > > timestamps appear to be Jan 1. > > > > I'll make an attempt to check out today's -STABLE and compile it but > > I'm not optimistic that the machine will actually be able to build > > world without reverting to a release first. > > You can always try to bypass namecache altogether while you are > building the new kernel: do sysctl debug.vfscache=0 Hi. Updating to today's -STABLE appears to have fixed the problem (or at least it doesn't occur for the usage described in the PR!). Thanks! xw ___ 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"
SoC2009: Geom-based Disk Schedulers
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 classification and performance tuning for the specific scheduling algorithms. More info available on the wiki page of the project: http://wiki.freebsd.org/SOC2009FabioChecconi [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html [2] http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html ___ 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: C99: Suggestions for style(9)
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 least, I added this paragraph about the use of : > : >local variables. This is to clarify, how today's compilers handle : > : >unaliased local variables. : > : : > : Every version of gcc that FreeBSD has ever used would do this for : > : primitive types when optimisation was enabled. This approach can : > : become expensive in stack (and this is an issue for kernel code) when : > : using non-primitive types or when optimisation is not enabled (though : > : I'm not sure if this is supported). Assuming that gcc (and icc and : > : clang) behaves as stated in all supported optimisation modes, this : > : change would appear to be quite safe to make. : > : > Agreed, in general. We don't want to optimize our code style based on : > what one compiler does, perhaps on x86. : : I'm not sure whether I understand this - in particular the last three words. I'm saying we shouldn't tune our coding standard to the optimizations that the compiler of the hour gives, especially if those optimizations to the style are tuned to one architecture. Since there's little evidence presented on how these style changes will help any architecture, it is hard to judge if this is the case or not. The main goal of the proposed change is not about optimisation, but about clarity of the code: It is better to declare multiple variables with meaningful names instead of having one generic "int k;" used in several different contexts. I just also mentioned, that re-using variables in different contexts when taking its address is involved, leads to worse machine code, but this is a minor point. It's just that clarity for a reader and quality of the generated code nicely correlate here. Christoph ___ 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: C99: Suggestions for style(9)
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 at the other proposed changes. -- DE ___ 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: C99: Suggestions for style(9)
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 confusion here, so the rule even contradicts the rule,
which states not to use redundant parentheses. Maybe, decades ago it was
just a workaround for a broken compiler, which does not exist anymore.
FYI, the idea behind this rule is said to be to able to use
a macro return(), f.e. for debugging you then can do:
#define return(x) do { \
printf("returning from %s with %d\n", __func__, (x)); \
return (x); \
} while (0)
Given the this is a nifty feature and parentheses around the
return value don't hurt maintainability in any way IMO this
rule should stay.
This is mentioned nowhere in style(9) (in general it is lacking reasons
why something is some way or the other).
I agree that style(9) lacks explanations, however this doesn't
necessarily mean that non-obvious rules are "silly" and should
be removed.
I neither said not implied this. I said, that it is lacking in
justification, which clearly is bad.
Also I consider this as gross abuse: Macro names shall be in all
uppercase, so it is clear that there is a macro at work. Therefore
"return" is not a candidate. So this would violate yet another rule in
style(9) (the original return already violates the no-redundant
parentheses rule).
Also I would not mention __func__: there were objections against using
it in the past (though I, logically, prefer its use).
In general this is correct, a return() macro (in which case
the parentheses are not redundant) would be for local debugging
only and not ever hit the tree just like any other printf()-
debugging should not, so neither is relevant here. Besides,
a macro without side effects, which a return() macro typically
shouldn't have, is fine to be named all lowercase according
to style(9).
So everybody has to pay with a small amount of obfuscation per return
for an obscure trick, which compared to the number of returns is never used.
Therefore I don't consider the return-macro convincing at all.
Christoph
___
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: C99: Suggestions for style(9)
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/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: C99: Suggestions for style(9)
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(); >>>if (!fp) return; >>>bp = fp->bp; >>> >>> this can't easily be translated to the more natural: >>> >>>struct foo *fp = get_foo(); >>>struct bar *bp = fp->bp; >>> >> > Well more natural for you, but not necessarily for everyone, > and NOT the same as what is there now, as you noticed. > > > >>> 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 this isn't >>> >> >> You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) >> §6.8.2:1. In short: you can mix statements and declarations. >> > Sure, but it's still very bad: If I'm not mistaken, this would mean that "bp" would only be valid within the "if" clause --- which isn't very useful. ___ 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: C99: Suggestions for style(9)
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, it most probably is only
assigned a value once, so declaration and the signle assignment are in
the same place, which aids readability and makes the code more concise.
the fact that people misread it allows me to say
"the defense rests m'lord"
Non sequitur. Warner wrote the "return;" in the same line as the if,
which easily hides it. If the "return;" wasn't there, the original
statement would be almost correct - actually it would be a compile
error, because if (x) int i; is not allowed[1].
Christoph
[1] if (x) { int i; } is allowed, of course.
___
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: C99: Suggestions for style(9)
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 assigned a value once, so declaration and the signle assignment are in the same place, which aids readability and makes the code more concise. the fact that people misread it allows me to say "the defense rests m'lord" Christoph ___ 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"
Re: C99: Suggestions for style(9)
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(); if (!fp) return; bp = fp->bp; this can't easily be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp->bp; Well more natural for you, but not necessarily for everyone, and NOT the same as what is there now, as you noticed. 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 this isn't You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) §6.8.2:1. In short: you can mix statements and declarations. Sure, but it's still very bad: If I'm not mistaken, this would mean that "bp" would only be valid within the "if" clause --- which isn't very useful. 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 assigned a value once, so declaration and the signle assignment are in the same place, which aids readability and makes the code more concise. Christoph ___ 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"
SoC2009: Ipfw and dummyent improvements
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 dummynet subsystems. The project will mainly involve: - the kernel source code, making it more manageable, splitting large functions, improving the microinstruction compiler; - the userland kernel-interface, identifying locking issues or performance problems. A more detailed version of the proposal can be found on the FreeBSD Wiki page: http://wiki.freebsd.org/SOC2009MartaCarbone marta ___ 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: vfs_cache panic, 7.2-prerelease (stable)
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 kernel > timestamps appear to be Jan 1. > > I'll make an attempt to check out today's -STABLE and compile it but > I'm not optimistic that the machine will actually be able to build > world without reverting to a release first. You can always try to bypass namecache altogether while you are building the new kernel: do sysctl debug.vfscache=0 -- Alexander Kabaev signature.asc Description: PGP signature
Re: vfs_cache panic, 7.2-prerelease (stable)
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 least. 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 kernel timestamps appear to be Jan 1. I'll make an attempt to check out today's -STABLE and compile it but I'm not optimistic that the machine will actually be able to build world without reverting to a release first. xw ___ 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: vfs_cache panic, 7.2-prerelease (stable)
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: PGP signature
Re: Why top never shows ~100% CPU usage with heavy PCU load?
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.0% interrupt, 0.0% idle
> Mem: 653M Active, 995M Inact, 241M Wired, 90M Cache, 112M Buf, 11M Free
> Swap: 16G Total, 204M Used, 16G Free, 1% Inuse, 16K In
>
> PID USERNAMETHR PRI NICE SIZERES STATETIMECPU COMMAND
> 85422 yuri 1 990 2520K 980K RUN 0:21 57.47% cycle
>
>
> [snip]
>
Strange is 20% system load. The summary line is about all cpus/cores/...
Here I have:
top:
last pid: 48056; load averages: 0.91, 0.38, 0.15 up 12+23:14:39 20:34:58
49 processes: 2 running, 47 sleeping
CPU: 50.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 49.8% idle
Mem: 259M Active, 1630M Inact, 537M Wired, 16M Cache, 417M Buf, 1495M Free
Swap: 4096M Total, 4096M Free
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND
48032 lexx 1 1180 2624K 604K CPU11 2:31 100.00% bbb
...
~>uname -a
FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Apr 18 20:38:14 CEST
2009 r...@wep4035:/usr/obj/usr/src/sys/GENERIC amd64
~> cat bbb.c
int
main(void)
{
for (;;);
return;
}
My $0.02,
Alexey.
___
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 top never shows ~100% CPU usage with heavy PCU load?
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 mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Why top never shows ~100% CPU usage with heavy PCU load?
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, 90M Cache, 112M Buf, 11M Free
Swap: 16G Total, 204M Used, 16G Free, 1% Inuse, 16K In
PID USERNAMETHR PRI NICE SIZERES STATETIMECPU COMMAND
85422 yuri 1 990 2520K 980K RUN 0:21 57.47% cycle
Total of CPU column for all processes is never what top shows in "CPU:"
field.
At the same time kde system guard app shows 100% overall CPU load and
same cycle app shows as consuming ~85% CPU.
So system guard always shows consistently higher number for the same
process than top -C shows.
On Linux process the cycle app shows as consuming <~100% CPU and total
is also <~100% that makes sense.
Why top's "CPU:" field doesn't equal total of all CPUs for all processes
that it shows?
Why top doesn't show ~100% CPU consumption for the cycle process?
Why sysguard in kde consistently shows higher CPU consumption numbers
than top -C?
Yuri
___
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: vfs_cache panic, 7.2-prerelease (stable)
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 ___ 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: C99: Suggestions for style(9)
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 in all : uppercase, so it is clear that there is a macro at work. Therefore : "return" is not a candidate. So this would violate yet another rule in : style(9) (the original return already violates the no-redundant : parentheses rule). : Also I would not mention __func__: there were objections against using : it in the past (though I, logically, prefer its use). It is a debugging aid, but one of dubious value for a far more fundamental reason: return; will break any macro. Warner ___ 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"
Re: vfs_cache panic, 7.2-prerelease (stable)
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: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1a0 fault code = supervisor read data, page not present instruction pointer = 0x8:0x80509409 stack pointer = 0x10:0x7a3d46b0 frame pointer = 0x10:0x7a3d46e0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75381 (sh) exclusive sleep mutex Name Cache r = 0 (0x80be9940) locked @ /usr/src/sys/kern/vfs_cache.c:345 exclusive sleep mutex Name Cache r = 0 (0x80be9940) locked @ /usr/src/sys/kern/vfs_cache.c:345 exclusive sx so_rcv_sx r = 0 (0xff0005b42970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 The web interface mangled the whitespace somewhat. xw ___ 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: vfs_cache panic, 7.2-prerelease (stable)
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 unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
USENIX WebApps '10 Call for Papers Now Available
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.
Suggested topics related to Web application development include but
are not limited to:
* Computing substrates and deployment technologies ("cloud computing")
* Frameworks for developing Web applications
* Client-side toolkits, libraries, and plug-ins
* Storage systems
* Security issues for Web applications
* Management techniques for large-scale Web applications
* Languages for Web applications
* Scalability issues and techniques
* Techniques for creating highly interactive Web applications
* Software as a service
* Applications that illustrate interesting new features or
implementation techniques
* Performance measurements of Web applications
* Real-time data delivery over the Web
* Web services
Paper submissions are due by January 11, 2010.
The Call for Papers, with submission guidelines, can be found at
http://www.usenix.org/webapps10/cfpa/
The USENIX Conference on Web Application Development (WebApps '10) will
take place June 20–25, 2010, in Boston, MA. The technical sessions will
take place on June 23–25.
I look forward to receiving your submissions!
Sincerely,
John Ousterhout, Stanford University
WebApps '10 Program Chair
webapps10ch...@usenix.org
Call for Papers:
USENIX Conference on Web Application Development (WebApps '10)
June 20–25, 2010
Boston, MA
http://www.usenix.org/webapps10/cfpa
Paper submissions deadline: January 11, 2010
___
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++ incompatability, was C99: Suggestions for style(9)
> > [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?
> >
> > Regarding this great feature of C99, sadly, it's not C++ compatible.
So
> > while designated initializers in a C source file are great, in a
header
> > file they will give a compile error if included in e.g. a C++ kernel
> > module (which otherwise would work fine).
>
> Why would you put initializers in a header file? If included
> in more than one file, the linker will complain that the
> initialized variable is multiply defined. If creating header
> files that get included in in only one file *and* you want to
> use initializers, why not use the right language for include
> file code.
Macros, like MALLOC_DEFINE, DB_COMMAND, etc., define initialized
variables when used. These can't be changed to use named initializers
without breaking C++.
Thanks,
matthew
___
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++ incompatability, was C99: Suggestions for style(9)
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 inconsistent
> > with all the other existing compound initialisations?
>
> Regarding this great feature of C99, sadly, it's not C++ compatible. So
> while designated initializers in a C source file are great, in a header
> file they will give a compile error if included in e.g. a C++ kernel
> module (which otherwise would work fine).
Why would you put initializers in a header file? If included
in more than one file, the linker will complain that the
initialized variable is multiply defined. If creating header
files that get included in in only one file *and* you want to
use initializers, why not use the right language for include
file code.
___
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"
Cobalt Raq 550
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 searches for linux kernel images when booting. Does anyone have any experience with installing FreeBSD on a Raq 550? I wasn't able to find a website with much detail and would appreciate any hints or leads :-) I hope everyone has an excellent weekend. ___ 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"
C++ incompatability, was C99: Suggestions for style(9)
[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?
Regarding this great feature of C99, sadly, it's not C++ compatible. So
while designated initializers in a C source file are great, in a header
file they will give a compile error if included in e.g. a C++ kernel
module (which otherwise would work fine).
Actually, as a further digression, I was wondering if/when FreeBSD would
add
#ifdef __cplusplus
extern "C" {
#endif
to sys/sys/*.h and other headers that can be included by a kernel
module.
Thanks,
matthew
___
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: C99: Suggestions for style(9)
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" 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 : : > : > 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 bar *bp; : : > : > : : > : > fp = get_foo(); : : > : > if (!fp) return; : : > : > bp = fp->bp; : : > : > : : > : > this can't easily be translated to the more natural: : : > : > : : > : > struct foo *fp = get_foo(); : : > : > struct bar *bp = fp->bp; : : > : > : : > : > 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'. : : > : : : > : I thought we were talking about C99, in which case this is perfectly legal. : : > : I certainly use it all the time in my C99 code. : : > : : > Hmmm, looks like that was added. That's ugly as C++... : : : : I do not think, this is ugly. On the contrary, it aids maintainability, : : because it reduces the scope of variables. Also quite some variables are : : only initialised and not changed afterwards, so it's nice to have the : : declaration and the only assignment in a single place. IMO this is a : : quite natural style, because you don't have anything in the code, before : : it is needed: Get the first pointer; if something is wrong, bail out; : : get the second pointer - the second pointer does not (textually) exist : : before it is needed. : : It is ugly. Hunting for declarations sucks, and it is one of the : things I really like about BSD code is that I don't have to. : : This is a religious point, and we're dangerously close to saying my : religion is better than your religion. I don't like this part of the : proposal at all. I can see the value in relaxing it for when you have : a series of variables that are initialized, but relaxing it to the : point where you intermix code and declarations goes way too far. It : is bad enough to have to deal with inner scopes, but tolerable. It is : intolerable to have to look for it anywhere in a big function. It : tends to encourage spaghetti code, which is one of the things that : style(9) tries to discourage in many subtle ways. This came off a little more absolute than I wanted. I should have added "in the absence of hard data..." Warner ___ 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: C99: Suggestions for style(9)
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 confusion here, so the rule even contradicts the rule,
: >> which states not to use redundant parentheses. Maybe, decades ago it was
: >> just a workaround for a broken compiler, which does not exist anymore.
: >
: > FYI, the idea behind this rule is said to be to able to use
: > a macro return(), f.e. for debugging you then can do:
: > #define return(x) do {
\
: > printf("returning from %s with %d\n", __func__, (x)); \
: > return (x); \
: > } while (0)
: >
: > Given the this is a nifty feature and parentheses around the
: > return value don't hurt maintainability in any way IMO this
: > rule should stay.
:
: This is mentioned nowhere in style(9) (in general it is lacking reasons
: why something is some way or the other).
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.
: Also I consider this as gross abuse: Macro names shall be in all
: uppercase, so it is clear that there is a macro at work. Therefore
: "return" is not a candidate. So this would violate yet another rule in
: style(9) (the original return already violates the no-redundant
: parentheses rule).
: Also I would not mention __func__: there were objections against using
: it in the past (though I, logically, prefer its use).
It is a debugging aid, but one of dubious value for a far more
fundamental reason:
return;
will break any macro.
Warner
___
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: C99: Suggestions for style(9)
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 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 bar *bp; : > : > : > : > fp = get_foo(); : > : > if (!fp) return; : > : > bp = fp->bp; : > : > : > : > this can't easily be translated to the more natural: : > : > : > : > struct foo *fp = get_foo(); : > : > struct bar *bp = fp->bp; : > : > : > : > 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'. : > : : > : I thought we were talking about C99, in which case this is perfectly legal. : > : I certainly use it all the time in my C99 code. : > : > Hmmm, looks like that was added. That's ugly as C++... : : I do not think, this is ugly. On the contrary, it aids maintainability, : because it reduces the scope of variables. Also quite some variables are : only initialised and not changed afterwards, so it's nice to have the : declaration and the only assignment in a single place. IMO this is a : quite natural style, because you don't have anything in the code, before : it is needed: Get the first pointer; if something is wrong, bail out; : get the second pointer - the second pointer does not (textually) exist : before it is needed. It is ugly. Hunting for declarations sucks, and it is one of the things I really like about BSD code is that I don't have to. This is a religious point, and we're dangerously close to saying my religion is better than your religion. I don't like this part of the proposal at all. I can see the value in relaxing it for when you have a series of variables that are initialized, but relaxing it to the point where you intermix code and declarations goes way too far. It is bad enough to have to deal with inner scopes, but tolerable. It is intolerable to have to look for it anywhere in a big function. It tends to encourage spaghetti code, which is one of the things that style(9) tries to discourage in many subtle ways. Warner ___ 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: C99: Suggestions for style(9)
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 some of them applied to style(9). So, please consider the : > : >proposed changes individually and not a as a all-or-nothing package. : > : : > : One area you do not address is code consistency. Currently, the : > : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : > : compliant - ie the entire codebase is mostly written in the same : > : style. Whilst you may not like it (and I don't know that anyone : > : completely agrees with everything in style(9)), it does mean that : > : the code is consistent. : > : : > : Changing style(9) in a way that is not consistent with current code : > : means that either existing code must be brought into line with the : > : new standard - which incurs a one-off cost - or the code base becomes : > : split into "old" and "new" style - incurring an ongoing maintenance : > : cost as maintainers switch between styles. Both approaches incur a : > : risk of introducing new bugs. : > : : > : Note that I'm not saying that style(9) can never be changed, I'm just : > : saying that any change _will_ incur a cost and the cost as well as : > : the potential benefits need to be considered. : > : > This is my biggest worry about changing style(9) quickly. We don't : > want needless churn in the tree for just style changes since it makes : > it harder to track bug fixes into the past. : : I'm not saying that all the code has to be changed at once, but no new : code of the "old" style should be added. E.g. you should never use K&R : declarations when adding a new function. And if you are going to make a : big change somewhere, then it is sensible to use the "new" style. Mixing and matching style has proven to be bad when it has been practiced in the past. At least when practiced on a sub-file level. : > : [Reduce declaration scope as far as possible, initialise variables where : > : they are declared, sort by name] : > : : > : Whilst my personal preference is for the style suggested by Christoph : > : (and I generally agree with the points he makes), this is also the : > : change that incurs the biggest stylistic change. This is not a change : > : that can be practically retrofitted to existing code and therefore its : > : implementation would result in a mixture of code styles - increasing : > : the risk of bugs due to confusion as to which style was being used. I : > : am not yet sure whether the benefits outweigh the costs, : > : > This is the biggest one, and I think it may be too soon. Also, we : : This is the reason, why I explicitly mentioned, that the proposed : changes should be examined independently. : : > 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 bar *bp; : > : > fp = get_foo(); : > if (!fp) return; : > bp = fp->bp; : > : > this can't easily be translated to the more natural: : > : > struct foo *fp = get_foo(); : > struct bar *bp = fp->bp; : > : > 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 this isn't : : You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) : §6.8.2:1. In short: you can mix statements and declarations. : : > the case that it should be allowed. We should separate the : > initialization part of this from the scope part of this too. The : > initialization part is already leaking into the code, while instances : > of the scope restriction is rarer. : : Sorry, I do not understand these sentences. It's a stupid idea and I don't think we should do it. It is a bad practice to intermix statements and declarations, and I think a too radical departure from the current style. : > : [Don't parenthesize return values] : > : >Removed, because it does not improve maintainability in any way. : > : : > : This change could be made and tested mechanically. But there is : > : no justification for making it - stating that the existing rule : > : is no better than the proposed rule is no reason to change. : > : > I'm fine with this. : > : > : [No K&R declarations] : > : >Removed, because there is no need to use them anymore. : > : : > : Whilst this is a change that could be performed mechanically, there : > : are some gotchas relating to type promotion (as you point out). : > : The kernel already contains a mixture of ANSI & K&R declarations and : > : style(9) recommends using ANSI. IMHO, there is no need to make this : > : change until all K&R code is removed from FreeBSD. : > : > I'm fine with this change. : > :
Re: IPsec in GENERIC kernel config
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 fine if the IPsec would be enabled in it by default. Now I have to build a custom kernel just for IPsec btw IPsec is even mandatory for a host supporting IPv6. IETF just says that IPsec support is mandatory in IPv6, but IPsec use is not. Most of current IPv6 implementations do not include IPsec, and there is nothing unusual with that. It is mainly about the performance, but there are also other issues, mainly security ones, e.g. it actually cannot defend against DoS attacks and cannot strictly eliminate spoofing, it is only a network-level security tool.. and there are still lots of incompatibility issues between different vendors' implementations of IPsec.. etc.. Ana ___ 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"
vfs_cache panic, 7.2-prerelease (stable)
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/stress running from a liveCD). About 20 minutes ago, I booted into the version of FreeBSD I had built previously to try to debug a DRI problem (which turned out not to exist, evidently). The build has every debugging option I could find enabled (WITNESS, INVARIANTS, etc). Upon trying to build the 'lmmon' port, I was greeted with a panic. I was dropped into ddb and thinking that the relevent crash info would be saved, I rebooted. It wasn't saved. The panic is reproducable: it always occurs in vfs_cache.c:345. How can I get all the info I need saved in order to file a PR? thanks, xw ___ 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: C99: Suggestions for style(9)
> 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, decades ago it was
> > just a workaround for a broken compiler, which does not exist anymore.
>
> FYI, the idea behind this rule is said to be to able to use
> a macro return(), f.e. for debugging you then can do:
> #define return(x) do {
> \
> printf("returning from %s with %d\n", __func__, (x)); \
> return (x); \
> } while (0)
>
> Given the this is a nifty feature and parentheses around the
> return value don't hurt maintainability in any way IMO this
> rule should stay.
short version:
not nifty, dirty yes!
long version:
it's already quiet difficult to read the sources with so many MaCrOs roaming
around, but if you change if, return, then, else, switch etc, etc
to a macro invocation, there will be a slight discrepancy between
the undertsanding of the code and its running effect.
btw, what if x is a pointer?, or a quad? or a complex ...
my .02$
danny
___
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: C99: Suggestions for style(9)
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 here, so the rule even contradicts the rule,
> >>which states not to use redundant parentheses. Maybe, decades ago it was
> >>just a workaround for a broken compiler, which does not exist anymore.
> >
> >FYI, the idea behind this rule is said to be to able to use
> >a macro return(), f.e. for debugging you then can do:
> >#define return(x) do { \
> > printf("returning from %s with %d\n", __func__, (x)); \
> > return (x); \
> >} while (0)
> >
> >Given the this is a nifty feature and parentheses around the
> >return value don't hurt maintainability in any way IMO this
> >rule should stay.
>
> This is mentioned nowhere in style(9) (in general it is lacking reasons
> why something is some way or the other).
I agree that style(9) lacks explanations, however this doesn't
necessarily mean that non-obvious rules are "silly" and should
be removed.
> Also I consider this as gross abuse: Macro names shall be in all
> uppercase, so it is clear that there is a macro at work. Therefore
> "return" is not a candidate. So this would violate yet another rule in
> style(9) (the original return already violates the no-redundant
> parentheses rule).
> Also I would not mention __func__: there were objections against using
> it in the past (though I, logically, prefer its use).
In general this is correct, a return() macro (in which case
the parentheses are not redundant) would be for local debugging
only and not ever hit the tree just like any other printf()-
debugging should not, so neither is relevant here. Besides,
a macro without side effects, which a return() macro typically
shouldn't have, is fine to be named all lowercase according
to style(9).
Marius
___
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: NetBSD 5.0 statistics
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 and serious performance regression in CAM > relating to tgged queueing, and the generic disk sort routine, > introduced 7.1, which will be fixed in 7.2. I can't speak more > generally to the benchmarks -- we'll need to run them in a controlled > environment and see if we can reproduce the results. > Well, there is also r185801 of vfs_cache.c which all but destroys the usefulness of negative name caching and surely can account for a large percentage of reported performance drop in 7.1, especially with build.sh benchmarks. The bug was fixed in stable/7 soon after 7.1 was released. -- Alexander Kabaev signature.asc Description: PGP signature
Re: C99: Suggestions for style(9)
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 standard was published a decade ago,
compilers implementing that standard are still not ubiquitous.
HEAD recently
switched to C99 as default (actually gnu99, but that's rather close).
Note that gcc 4.2 (the FreeBSD base compiler) states that it is not
C99 compliant.
It's good enough. Only one proposed change (mixing declarations and
statements) actually needs C99. GCC supports this for many years.
Maybe using all of these changes is a bit too big change at once, but
I'd like some of them applied to style(9). So, please consider the
proposed changes individually and not a as a all-or-nothing package.
One area you do not address is code consistency. Currently, the
FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9)
compliant - ie the entire codebase is mostly written in the same
style. Whilst you may not like it (and I don't know that anyone
completely agrees with everything in style(9)), it does mean that
the code is consistent.
Changing style(9) in a way that is not consistent with current code
means that either existing code must be brought into line with the
new standard - which incurs a one-off cost - or the code base becomes
split into "old" and "new" style - incurring an ongoing maintenance
cost as maintainers switch between styles. Both approaches incur a
risk of introducing new bugs.
Note that I'm not saying that style(9) can never be changed, I'm just
saying that any change _will_ incur a cost and the cost as well as
the potential benefits need to be considered.
I see no problem with removing/changing the existing rules to make sure
new code is not forced to use them just because it always has been done
this way. Nobody will change all the source code at once, because its
insane to check and change millions of lines of code at once.
Considering this, you pretty much said, that style(9) cannot be changed.
I see no problem in improving the rules and then gradually changing the
code when it is convenient. Especially new code will profit from the
changes, because it is not condemned to use the old rules for eternity.
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?
[Reduce declaration scope as far as possible, initialise variables where
they are declared, sort by name]
Whilst my personal preference is for the style suggested by Christoph
(and I generally agree with the points he makes), this is also the
change that incurs the biggest stylistic change. This is not a change
that can be practically retrofitted to existing code and therefore its
implementation would result in a mixture of code styles - increasing
the risk of bugs due to confusion as to which style was being used. I
am not yet sure whether the benefits outweigh the costs,
There is no need to change all the existing code at once. But new code
should be enabled to use the improved style.
[Don't parenthesize return values]
Removed, because it does not improve maintainability in any way.
This change could be made and tested mechanically. But there is
no justification for making it - stating that the existing rule
is no better than the proposed rule is no reason to change.
Just remove the rule. There's no need to add more redundant parentheses.
Again: There is no need to change all existing code at once, but the
rule is removed so that not anymore redundant parentheses are added.
[No K&R declarations]
Removed, because there is no need to use them anymore.
Whilst this is a change that could be performed mechanically, there
are some gotchas relating to type promotion (as you point out).
The kernel already contains a mixture of ANSI & K&R declarations and
style(9) recommends using ANSI. IMHO, there is no need to make this
change until all K&R code is removed from FreeBSD.
Again: No need to change all the code at once, but the rule is removed,
so not any more old style declarations are added.
The current attempts to compile FreeBSD using LLVM/clang revealed
several existing bugs in functions with old style declarations.
[ Don't insert an empty line if the function has no local variables.]
This change could be made and tested mechanically. IMHO, this change
has neglible risk and could be safely implemented.
Again: No need for immediate global change, but just do not add anymore
of those. There are already quite some functions, which do not have the
unnecessary empty line.
+.Sh LOCAL VARIABLES
Last, but definitely not least, I added this paragraph about the use of
local variables. This
Re: C99: Suggestions for style(9)
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 variables as you have logically distinct entities in the function. I suppose, this is what you mean, but I want to clarify this point. Why don't just put "logically distinct entities" into separate functions on their own? It's a good indicator that the re-factoring is due when you reach this point. -Maxim ___ 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: C99: Suggestions for style(9)
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 statements.
I can see moving declarations to an inner scope {} in some cases but
I think allowing us to declare them mixed in with the code,
(even though some compilers allow it) will be a mistake.
Some compilers? According to my information every compiler, which is
even remotely relevant, supports it. Even PCC claims it does!
The only compiler, which I am aware of and which has a relevant
distribution, which doesn't support it, is MSVC - but I highly doubt,
that it is relevant in any way for FreeBSD.
I think this was done to allow macros to declare vars they needed.
I'd hate to see it in our code..
You are accusing me for proposing changes because "I felt like it", but
all you give is "I'd hate [...] it" and "[it] will be a mistake" without
any further justification. It seems to me, that you're applying double
standards. /:
Christoph
___
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: C99: Suggestions for style(9)
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, decades ago it was
> just a workaround for a broken compiler, which does not exist anymore.
FYI, the idea behind this rule is said to be to able to use
a macro return(), f.e. for debugging you then can do:
#define return(x) do { \
printf("returning from %s with %d\n", __func__, (x)); \
return (x); \
} while (0)
Given the this is a nifty feature and parentheses around the
return value don't hurt maintainability in any way IMO this
rule should stay.
Marius
___
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: C99: Suggestions for style(9)
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 parentheses. Maybe, decades ago it was
just a workaround for a broken compiler, which does not exist anymore.
FYI, the idea behind this rule is said to be to able to use
a macro return(), f.e. for debugging you then can do:
#define return(x) do { \
printf("returning from %s with %d\n", __func__, (x)); \
return (x); \
} while (0)
Given the this is a nifty feature and parentheses around the
return value don't hurt maintainability in any way IMO this
rule should stay.
This is mentioned nowhere in style(9) (in general it is lacking reasons
why something is some way or the other).
Also I consider this as gross abuse: Macro names shall be in all
uppercase, so it is clear that there is a macro at work. Therefore
"return" is not a candidate. So this would violate yet another rule in
style(9) (the original return already violates the no-redundant
parentheses rule).
Also I would not mention __func__: there were objections against using
it in the past (though I, logically, prefer its use).
Christoph
___
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: C99: Suggestions for style(9)
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 be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp->bp; Well more natural for you, but not necessarily for everyone, and NOT the same as what is there now, as you noticed. You partially misquoted this (only my name is seen above). I did not write this, Warner did. But I agree with Warner, that it is more natural. Also Warner had the wrong impression that declarations and statements cannot be mixed. But this is not true and so you can put the if inbetween, which is seen below. 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 this isn't You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) §6.8.2:1. In short: you can mix statements and declarations. now, but not all C compilers are C99 and a lot of FreeBSD code is taken and run in other situations. There is FreeBSD code in all sorts of environments, not all of which have new compilers. There are already several C99 features in use (like designated initialisers). So this is obviously not a problem. Besides which I'd vote against that just on principle that it breaks current style too much, and it makes it hard to find where things are declared. "Changes cannot be done because something would be different" is - of course - the killer pseudo-argument against any kind of change ever. ): : [No K&R declarations] : >Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI & K&R declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all K&R code is removed from FreeBSD. This is not new. It's already policy to remove them whenever you are working in the area. it improves code error checking.. So clearly style(9) should reflect this by removing the paragraph. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. Would you commit these three proposals? : >> +.Sh LOCAL VARIABLES : : >Last, but definitely not least, I added this paragraph about the use of : >local variables. This is to clarify, how today's compilers handle : >unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using non-primitive types or when optimisation is not enabled (though : I'm not sure if this is supported). Assuming that gcc (and icc and : clang) behaves as stated in all supported optimisation modes, this : change would appear to be quite safe to make. Agreed, in general. We don't want to optimize our code style based on what one compiler does, perhaps on x86. it does however make it harder to find stuff in gdb Can you elaborate on this? Because I cannot follow what you mean by this. "p i" will still print the value of "i". As a general rule, one of the things that is good about BSD code is that it all looks about the same. This makes it easier to read, once you have got used to it. Again this is the same "any change cannot happen, because it changes something which not already is this way" circular argument. ): If you don't dare to take the first step at some point, nothing can ever change and no improvement can take place ever. It's sad that changes (like designated initialisers) have to creep in via the backdoor and then at some point you can say "See? The world did not end.", because for any proposed change always somebody objects with "this is bad, because it is different than before". ): changing it for no reason except "I felt like it" will and I think should, meet stiff opposition. I want to make absolutely clear, that I in no way said or implied "I felt like it". I explained the reason for any of the changes I propsed and none of the reasons is even close to "I felt like it". Christoph ___ 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: C99: Suggestions for style(9)
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 this isn't > > > > You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 > > (E) §6.8.2:1. In short: you can mix statements and declarations. > > now, but not all C compilers are C99 and a lot of FreeBSD code > is taken and run in other situations. There is FreeBSD code > in all sorts of environments, not all of which have new compilers. > Doesn't FreeBSD already use C99 features such as stdint and named initializers? I don't think sys/cam/scsi/scsi_ses.c would compile with a C89 compiler for example. -- Bruce Cran ___ 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: C99: Suggestions for style(9)
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
: > 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 bar *bp;
: > : > fp = get_foo();
: > if (!fp) return;
: > bp = fp->bp;
: > : > this can't easily be translated to the more natural:
: > : > struct foo *fp = get_foo();
: > struct bar *bp = fp->bp;
: > : > 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'.
: : I thought we were talking about C99, in which case this is
perfectly legal.
: I certainly use it all the time in my C99 code.
Hmmm, looks like that was added. That's ugly as C++...
I do not think, this is ugly. On the contrary, it aids maintainability,
because it reduces the scope of variables. Also quite some variables are
only initialised and not changed afterwards, so it's nice to have the
declaration and the only assignment in a single place. IMO this is a
quite natural style, because you don't have anything in the code, before
it is needed: Get the first pointer; if something is wrong, bail out;
get the second pointer - the second pointer does not (textually) exist
before it is needed.
: And I thought this was the point of this discussion, to be able to
declare
: variables when you first use them.
That's one of the proposed changes, which I think is a mistake and
would cause the most code churn. And it isn't one of the items that's
being discussed: only moving variables into inner scopes is on the
table...
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 statements.
I can see moving declarations to an inner scope {} in some cases but
I think allowing us to declare them mixed in with the code,
(even though some compilers allow it) will be a mistake.
I think this was done to allow macros to declare vars they needed.
I'd hate to see it in our code..
Christoph
___
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"
Re: C99: Suggestions for style(9)
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 natural: struct foo *fp = get_foo(); struct bar *bp = fp->bp; Well more natural for you, but not necessarily for everyone, and NOT the same as what is there now, as you noticed. 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 this isn't You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) §6.8.2:1. In short: you can mix statements and declarations. now, but not all C compilers are C99 and a lot of FreeBSD code is taken and run in other situations. There is FreeBSD code in all sorts of environments, not all of which have new compilers. Besides which I'd vote against that just on principle that it breaks current style too much, and it makes it hard to find where things are declared. : [Don't parenthesize return values] : >Removed, because it does not improve maintainability in any way. : : This change could be made and tested mechanically. But there is : no justification for making it - stating that the existing rule : is no better than the proposed rule is no reason to change. I'm fine with this. I find return values being parenthesised is easier to for me to read. I'd vote against his too : [No K&R declarations] : >Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI & K&R declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all K&R code is removed from FreeBSD. This is not new. It's already policy to remove them whenever you are working in the area. it improves code error checking.. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. Would you commit these three proposals? : >> +.Sh LOCAL VARIABLES : : >Last, but definitely not least, I added this paragraph about the use of : >local variables. This is to clarify, how today's compilers handle : >unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using non-primitive types or when optimisation is not enabled (though : I'm not sure if this is supported). Assuming that gcc (and icc and : clang) behaves as stated in all supported optimisation modes, this : change would appear to be quite safe to make. Agreed, in general. We don't want to optimize our code style based on what one compiler does, perhaps on x86. it does however make it harder to find stuff in gdb As a general rule, one of the things that is good about BSD code is that it all looks about the same. This makes it easier to read, once you have got used to it. changing it for no reason except "I felt like it" will and I think should, meet stiff opposition. ___ 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"
