From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 00:36:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16BB106564A for ; Sun, 26 Apr 2009 00:36:19 +0000 (UTC) (envelope-from zachriggle@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 858678FC1D for ; Sun, 26 Apr 2009 00:36:19 +0000 (UTC) (envelope-from zachriggle@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1297780qwe.7 for ; Sat, 25 Apr 2009 17:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=4oHUsppIVARjNRYaUpZPYRTemgbjaL5v4WGA8c5EEMs=; b=gnmmr90fARTz/zfSAFTPDM/RK+b/HyiXCUEo4wlRngt6YhohEAo5MUvhpYIgTgLTxw KPToOnxFAr9g1ydpziqhpuyBN3+AS/rUVTHBd0UiGogNVOs0C1ixF+XN+NrePsMXHVjd pYwwBlcxbUSL+KcFtRH1P2exlmVN7Ok3tAhRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=rD6EbcGhHQEvUrvtJostW8vvYlKT3TE9mDKRsMcHRfwCaItwxxluMmzfxwrXeh/qqw oXS1EO4HZktbWVUUQILITk42Q0A80+S3xJaxH6lFOXBduBU8JZDMIMeQUJbF+s2uGEbD cqmx9h7HfY7OUyG62UhZssS55Eh/HXPmxsBiQ= Received: by 10.224.89.82 with SMTP id d18mr4445443qam.49.1240704529298; Sat, 25 Apr 2009 17:08:49 -0700 (PDT) Received: from ?172.16.0.94? (c-69-140-137-189.hsd1.md.comcast.net [69.140.137.189]) by mx.google.com with ESMTPS id 5sm4561473qwh.24.2009.04.25.17.08.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 17:08:48 -0700 (PDT) Message-Id: <91EAF988-F10A-48DA-B021-6C6D755CB300@gmail.com> From: Zach Riggle To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPod Mail 5H11a) Date: Sat, 25 Apr 2009 19:52:30 -0400 X-Mailer: iPod Mail (5H11a) X-Mailman-Approved-At: Sun, 26 Apr 2009 01:01:24 +0000 Subject: GSoC introduction X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 00:36:20 -0000 Hello all! My name is Zach Righle, and I'm a sophomore at Michigan State University. I'll be working with George Neville-Neil this summer on TCP regression testing, to provide a suite of tests that FreeBSD can use to... prevent regression errors. Http://wiki.freebsd.org/ZachRiggle for more info Zach Riggle From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 02:24:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2480106566C for ; Sun, 26 Apr 2009 02:24:35 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 567E98FC13 for ; Sun, 26 Apr 2009 02:24:35 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n3Q2OYXl063603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Apr 2009 19:24:34 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n3Q2OYx2063602; Sat, 25 Apr 2009 19:24:34 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01589; Sat, 25 Apr 09 19:22:01 PDT Date: Sat, 25 Apr 2009 19:19:35 -0700 From: perryh@pluto.rain.com To: dforsyth@freebsd.org Message-Id: <49f3c4b7.zX/ozx/uX5tTDhXT%perryh@pluto.rain.com> References: In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: SoC2009: libpkg, pkg tools rewrite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 02:24:35 -0000 David Forsythe wrote: > This summer I'll be working on creating a package library and > using that library to rewrite the pkg tools ... As of last July there seemed to be no way to specify a mixture of local and remote repositories for pkg_add (discussion here): http://lists.freebsd.org/pipermail/freebsd-questions/2008-July/178710.html It would be good to get that capability added if it has not already been done. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 07:29:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC8331065674 for ; Sun, 26 Apr 2009 07:29:19 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 506F88FC12 for ; Sun, 26 Apr 2009 07:29:19 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 26 Apr 2009 07:02:36 -0000 Received: from p54A3FD45.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.253.69] by mail.gmx.net (mp061) with SMTP; 26 Apr 2009 09:02:36 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+VIktlW/OVlj3pBafSPRriwhjOmn0lpcN/jq0Q0l MgO29mu+1NJuQE Message-ID: <49F4070C.2000108@gmx.de> Date: Sun, 26 Apr 2009 09:02:36 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: Maxim Sobolev , Roman Divacky , Ed Schouten , Warner Losh Subject: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 07:29:20 -0000 Hi hackers@, as some of you may have noticed, several years ago a new millenium started and a decade ago there was a new C standard. HEAD recently switched to C99 as default (actually gnu99, but that's rather close). So it's finally time to re-examine wether style(9) needs to be accomodated. The diff with the proposed changes is attached. Below are the changes with some further explanations. They are in the order as they appear in style(9). 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. > -Do not put declarations > -inside blocks unless the routine is unusually complicated. > +Prefer declaring loop iterators in the for-statement to limit their scope. > .Bd -literal > - for (; cnt < 15; cnt++) { > + for (int cnt = 0; cnt < 15; cnt++) { [...] > -When declaring variables in functions declare them sorted by size, > -then in alphabetical order; multiple ones per line are okay. > +When declaring variables in functions declare them sorted in alphabetical order; > +prefer one declaration per line, especially when pointer declarators or > +initializations are involved. > If a line overflows reuse the type keyword. > .Pp > -Be careful to not obfuscate the code by initializing variables in > -the declarations. > -Use this feature only thoughtfully. > -DO NOT use function calls in initializers. > +Prefer initializing variables right at their declaration. > +When the value is not supposed to change in the function, make the variable > +const. > +This makes it easier for a reader to identify the where the value of a variable > +originates. > +Do not reuse the same variable in a different context, declare a new variable. > .Bd -literal > - struct foo one, *two; > - double three; > - int *four, five; > - char *six, seven, eight, nine, ten, eleven, twelve; > + struct foo *bar; > + struct foo baz = { 42, "qux" }; > > - four = myfunction(); > + FILE *const f = fopen("name", "r"); > + if (f == NULL) > + err("Failed to open file"); > + /* We can safely assume that f is not changed anymore, even if the > + * function is a hundred lines long */ This change is to reduce the scope of local variables. For reasons why this does not cost anything in terms of stack space, please see the last change, which adds explanations about local variables. Smaller scopes and distinct variables for distinct contexts make it easier for readers of the code to identify the def-use-chains of variables, because there are less places with assignments to a variable and the scope is smaller. Also, when a variable is initialised right at its declaration and is not supposed to change, you can emphasize this by making it const. I looked at older discussions regarding this topic and identified several concerns, which were raised. I'll address them below: - It does not add anything to the language. Well, yes, just like if, do, for, goto, the comma operator, compound assignment (+=, ...), ++/-- and many other things. All you need to be Turing complete is lambda calculus - there hardly can be less syntax. But, like all mentioned constructs, it makes the code more concise. - It leads to sloppy code. You could reuse another variable or should think again whether you really need this variable. Reusing variables in different contexts is error prone and bad for maintainability. You could reuse a variable, which is not as dead as you thought. More local variables cost nothing, especially no stack space, see the last proposed changed below. It is good to use more local variables, because it gives the reader a name, which carries information. Also it makes it easier for a reader (and the compiler!) to identify, which expressions are the same. You could repeat foo->long_name->even_longer_name[2 * i + 1] five times or just declare a local variable and cache the value to make it easier to read. It also enables the compiler to produce better warnings: If you declare a new variable, it is not initialised and if you do not initialise it on all paths before a use, the compiler will warn you. But if you reuse an older variable, it is already initialised by its former uses and so you get no warning, but operate on garbage values (the old value from the previous use). So it does not lead to slopyy code, but better code, which is easier to comprehend, the compiler can better help you to prevent bugs, and as a side effect the compiler can produce better code (aliasing is a major problem for common subexpression elimination). - You can determine the stack usage with all the variable declarations at the top. This is not true. There is no relation between the declared variables and the stack used. Especially, more stack than suggested by the declarations can be used due to various optimisations - less space can be used, too, of course. - It is harder to find the declaration of a variable. Every editor, which is more advanced than ed, has facilities to jump to the declaration of a variable (e.g. in vim it's "gd"). And most often this is not necessary, because the declaration is just a few lines above instead of all the way up at the top of the function, so no jumping around is required at all. - You could accidently shadow a variable. All modern compilers have warnings for this. FreeBSD uses -Wshadow for GCC (and all relevant compilers understand this very option). > -Values in > -.Ic return > -statements should be enclosed in parentheses. > -.Pp 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. > -Old-style function declarations look like this: > -.Bd -literal > -static char * > -function(a1, a2, fl, a4) > - int a1, a2; /* Declare ints, too, don't default them. */ > - float fl; /* Beware double vs. float prototype differences. */ > - int a4; /* List in order declared. */ > -{ > -.Ed > -.Pp > -Use ANSI function declarations unless you explicitly need K&R compatibility. > +Use ANSI function declarations. Old-style function declarations: Removed, because there is no need to use them anymore. The C99 standard considers them obsolescent[1], too. All headers use prototype declarations, there's no reason to handle the function definitions different. Also they are a source of bugs - or did you know that the following is wrong: void wrong(char /* sic! */); void wrong(x) char x; {} And this is correct[2]: void right(int /* sic! */); void right(x) char x; {} (It's a bug in GCC that it does not complain about the former.) > - > -static void > -usage() > -{ > - /* Insert an empty line if the function has no local variables. */ Empty line when there are no local variables: Removed, because it does not improve readability and it actually hinders readability for very short functions, e.g. static inline functions, which just consist of one or two lines of code without any local variables except for parameters. Further, it makes even less sense with the changed recommendations for declarations. > +.Sh LOCAL VARIABLES > +Unaliased local variables are for free on modern compilers. > +They do not unconditionally use stack space. > +In fact there is no relation between their number and the used stack space. > +A local variable is guaranteed to be unaliased, if its address has not been > +taken (e.g. &i). > +Do not use the same local variable in different context just because it happens > +that the same type is needed. > +It does not improve the generated code in any way, but it makes it harder for a > +reader to determine all definitions and uses which belong together. > +Further, a new variable can be given a meaningful name (even if it is very > +short), which automatically serves as documentation and so improves > +comprehensibility. > +Especially avoid re-using variables, whose address has been taken: > +.Bd -literal > + int i; > + foo(&i); > + printf("%d\\n", i); > + for (i = 0; i != 10; ++i) { > + /* BAD: i will be needlessly moved to and from memory in > + * the loop, because its address was taken before. This > + * results in larger and slower code. > + * Declare a new variable for the loop instead. */ > + printf("%d\\n", i); > + } > +.Ed > + 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. There is absolutely no need to reuse them in different contexts. Trying to optimise stack usage in this way is misguided and is a source of bugs, when a reused variable is not as dead as thought. For more reasons, please read the quoted diff. Maxim, you requested this paragraph: Does this addition suit you? Hopefully at least some of these suggestions are considered improvements and are applied to style(9). Regards Christoph [1] ISO/IEC 9899:1999 (E) §6.11.6 and §6.11.7 [2] ISO/IEC 9899:1999 (E) §6.7.5.3:15 From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 11:17:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF2971065674; Sun, 26 Apr 2009 11:17:37 +0000 (UTC) (envelope-from kimelto@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 160618FC17; Sun, 26 Apr 2009 11:17:36 +0000 (UTC) (envelope-from kimelto@gmail.com) Received: by bwz9 with SMTP id 9so1726328bwz.43 for ; Sun, 26 Apr 2009 04:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uRUhMkbF+dOa3kl4oVM/kPV5Z6VUKQmcFlyUg9abXSA=; b=fy/xTfdJgwkkyFRb8+/kI4eCNZ6cq8CVTHc1wh44MplFHfxCS5OWjL3Qu9OPF0JqKd femPN+/8WtztvwTWpgzO5y50nN/IHJHIB7j7q63T3MFS1smM3aj7wiBwj3QdISlZ3Mdl 4t7Zjm49N0DP/a0Tzu5Wu1u7Vg2lWeUNBb9fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xasyPLUSozHOIOj8SiIAHNc/QBinjz5M80BgsQG2yhD+c+wO+HBv/6suAwVGFInofi kiRK9N4WziorrDzbltFPFQJbfo+2nb1oQYzxz1lNu9/tHOQ2psIWxNqm2o9FsbghV5Ji PXIFyEHJOgALI1e+1skIhRauPZRGrKjFh/nwo= MIME-Version: 1.0 Received: by 10.204.72.129 with SMTP id m1mr4094312bkj.61.1240743294285; Sun, 26 Apr 2009 03:54:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Apr 2009 12:54:54 +0200 Message-ID: From: Julien Laffaye To: David Forsythe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: SoC2009: libpkg, pkg tools rewrite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 11:17:38 -0000 On Sat, Apr 25, 2009 at 9:20 PM, David Forsythe wrot= e: > Hi, > I'm David Forsythe, 3rd year student at the University of Maryland, Colle= ge > Park. =A0For SoC2008 I worked on added parallel build support and databas= e > locks to ports. =A0I've been using FreeBSD for a while, and have taken > particular interest in ports and packages. > This summer I'll be working on creating a package library and using that > library to rewrite the pkg tools. =A0A package library has been discussed= and > even started before, but FreeBSD still does not have one. =A0This summer = I'd > like to get enough of the library done to atleast have a new set of pkg > tools completed with the current features, but ideally I'd like to get fa= r > enough to splice in some of the ideas I have for new features. > Here's the wiki page: http://wiki.freebsd.org/SoC2009DavidForsythe > Dave Hi, It'll be nice if libpkg can deal with all the infos in the INDEX with an elegant API. You have to read the packages names in the INDEX for `pkg_version -I` but maybe other tools will enjoy to get other infos (especially the one line description, the categories and the run time dependencies). So basically, an API which understand "give me all the packages names you have in the INDEX", "give me the description for _this_ package", "give me all the names plus the categories", "give me..." Regards, Julien Laffaye From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 12:38:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D84110656E2; Sun, 26 Apr 2009 12:38:47 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id CE08D8FC21; Sun, 26 Apr 2009 12:38:46 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n3QCKaXd027517; Sun, 26 Apr 2009 14:20:37 +0200 (CEST) Received: from ana-kukecs-macbook.local ([89.164.49.202]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 14:20:15 +0200 Message-ID: <49F4517E.5080005@fer.hr> Date: Sun, 26 Apr 2009 14:20:14 +0200 From: Ana Kukec User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2009 12:20:15.0400 (UTC) FILETIME=[5ACCB280:01C9C669] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: freebsd-net@freebsd.org Subject: GSoC - SeND X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 12:38:49 -0000 Hi all, I am Ana Kukec, a research assistant and a PhD student at University of Zagreb. I will be working on the IPv6 Secure Neighbor Discovery (SeND - rfc3971, rfc4861) - the implementation of native kernel APIs for FreeBSD, within GSoC, with my mentor Bjoern Zeeb. More informations will be provided on http://wiki.freebsd.org/SOC2009AnaKukec. Regards, Ana From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 17:01:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C997106566C for ; Sun, 26 Apr 2009 17:01:00 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by mx1.freebsd.org (Postfix) with ESMTP id 1707D8FC15 for ; Sun, 26 Apr 2009 17:00:58 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANgp9EnUnw4R/2dsb2JhbADKL4N0BQ Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.pcl-ipout02.plus.net with ESMTP; 26 Apr 2009 17:32:17 +0100 Received: from [81.174.211.119] (helo=81-174-211-119.pth-as4.dial.plus.net) by pih-relay04.plus.net with esmtp (Exim) id 1Ly7H5-00042E-Sp; Sun, 26 Apr 2009 17:32:17 +0100 From: Frank Mitchell To: sarawgi.aditya@gmail.com, freebsd-hackers@freebsd.org Date: Sun, 26 Apr 2009 15:26:32 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200904261526.32528.mitchell@wyatt672earp.force9.co.uk> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Plusnet-Relay: d35e8842366ee2f1dd24d954ff90b310 Cc: Subject: Ext2fs & DVD+RW X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 17:01:00 -0000 Improved Ext2fs: What a great idea. I like trying different Unix flavours, and Ext2fs is the only filesystem they all understand. I put all my data on a separate Partition formatted Ext2, and every so often I'm glad: Like the recent occasion when the NetBSD Boot Selector altered something and prevented FreeBSD from starting, leaving me with no alternative but to reinstall. Also, under Linux, you can use Ext2fs on DVD+RW. Plain DVD-RW is unsuitable because it uses Superblocks of 16*2048 bytes, but CD-RW should be okay. Currently you can't do this under FreeBSD, probably because CD and DVD use 2048-byte Sectors, and FreeBSD wants 512-byte. Somebody said you can put UFS on DVD+RW, but I couldn't get that to work. So possibly Ext2fs would be a viable alternative to UDF, though I don't know enough about Filesystems myself to tell whether this idea has some enormous drawback. Yours truly: Frank Mitchell ======================================================================== From: Aditya Sarawgi I'm Aditya Sarawgi from India. I will be working on FreeBSD's ext2fs as a part of this year's summer of code program. I will be improving the current implementation and I will also rewrite parts of ext2fs under GPL. My mentor is Ulf Lilleengen. For more details you can visit http://wiki.freebsd.org/SOC2009AdityaSarawgi Cheers, Aditya Sarawgi From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 17:01:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712B910656ED; Sun, 26 Apr 2009 17:01:08 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) Received: from relay.ptn-ipout01.plus.net (relay.ptn-ipout01.plus.net [212.159.7.35]) by mx1.freebsd.org (Postfix) with ESMTP id B6F388FC1B; Sun, 26 Apr 2009 17:01:07 +0000 (UTC) (envelope-from mitchell@wyatt672earp.force9.co.uk) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOco9EnUnw4R/2dsb2JhbADKMIN0BQ Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.ptn-ipout01.plus.net with ESMTP; 26 Apr 2009 17:32:15 +0100 Received: from [81.174.211.119] (helo=81-174-211-119.pth-as4.dial.plus.net) by pih-relay04.plus.net with esmtp (Exim) id 1Ly7H4-00042E-SJ; Sun, 26 Apr 2009 17:32:15 +0100 From: Frank Mitchell To: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Date: Sun, 26 Apr 2009 14:55:26 +0100 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904261455.26952.mitchell@wyatt672earp.force9.co.uk> X-Plusnet-Relay: 04d793b6d1709c62d3c49c6d7479f591 Cc: Subject: cd9660 Lowercasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 17:01:10 -0000 I've developed a CD/DVD Backup Utility using the Enhanced Volume Descriptor specified in ISO9660:1999. It doesn't have Rock Ridge yet, so the first thing you notice on mounting is the automatic Lowercase, which interferes with Backup Verification using "diff -qr". There's a simple solution using the "gens" mount option, which has Case Preservation as a side-effect, but it's still annoying. There must be some reason behind it, because NetBSD and Linux have a similar feature, with options to disable it like: "nomaplcase" and "map=off". But their manpages make it look like a throwback to MS-DOS, and a time when all filenames were accessed from the Primary Volume Descriptor. By default you can't have filenames in ASCII using the Supplementary or Enhanced Volume Descriptors either. I think I tracked this feature down to cd9660_util.c, in Function isofntrans, around Line 200: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< for (; infn != infnend; ) { infn += isochar(infn, infnend, joliet_level, &c, &clen, flags, handle); if (!original && !joliet_level && c >= 'A' && c <= 'Z') c += ('a' - 'A'); else if (!original && c == ';') { outp -= (d == '.'); break; } d = c; while(clen--) *outp++ = c >> (clen << 3); } >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This only alters ASCII characters. Accented uppercase letters from the top half of ISO8859-1 are unaffected. And it doesn't apply to Joliet either. I don't see the point. Why not just zap it away? Yours Truly: Frank Mitchell From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 18:13:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3770C106564A for ; Sun, 26 Apr 2009 18:13:45 +0000 (UTC) (envelope-from admin@mercurysquad.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 19F808FC15 for ; Sun, 26 Apr 2009 18:13:44 +0000 (UTC) (envelope-from admin@mercurysquad.com) Received: by wf-out-1314.google.com with SMTP id 24so1366295wfg.7 for ; Sun, 26 Apr 2009 11:13:44 -0700 (PDT) MIME-Version: 1.0 Sender: admin@mercurysquad.com Received: by 10.142.44.11 with SMTP id r11mr1046974wfr.186.1240768325431; Sun, 26 Apr 2009 10:52:05 -0700 (PDT) Date: Sun, 26 Apr 2009 23:22:05 +0530 X-Google-Sender-Auth: 3cbdd346b6650fd0 Message-ID: <66b068eb0904261052q678320bcm63618c65bba2c429@mail.gmail.com> From: Prashant Vaibhav To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SoC 2009: Redesign the callout API X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 18:13:45 -0000 Hello, I am Prashant Vaibhav, a 22 year old Indian guy (undergrad from Germany) and I'm a Google Summer of Code participant for 2009. My work will be focused on improving the callout/timeout API in the kernel. It was inspired by the tickless kernel feature present in XNU and Linux (since recent releases), and discussions made on the mailing lists a few years back about problems with the current implementation. Basically, the callout API will be redesigned to use opaque 'ticks' instead of explicitly x/HZ, and provide for certain additional features (like specifying a time range while arming). Beneath the hood, the implementation will be completely redesigned to use more efficient method of storing the callout list, and using any available timer in a hardware-independent way. It will then be extended to support deadline mode on capable systems (ie. dynamic HZ). This means for machines having an HPET or similar deadline-capable timer with a long range, the kernel will be completely tickless. On other machines with only a PIT, the 'ticks' could be as infrequent as a few times a second to once every 2 seconds, instead of 100 Hz. The major advantages are that the usage of hardware-dependent ticks and abstracting out timer hardware will make higher-resolution callouts possible, and in turn, making the kernel tickless will allow for better power savings, more efficient usage of CPU clock cycles, and better performance in virtual machines. More details can be found at the wiki page: http://wiki.freebsd.org/SOC2009PrashantVaibhav Best regards, Prashant Vaibhav From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 26 19:07:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86B671065706 for ; Sun, 26 Apr 2009 19:07:19 +0000 (UTC) (envelope-from marinosi@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 376688FC08 for ; Sun, 26 Apr 2009 19:07:19 +0000 (UTC) (envelope-from marinosi@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id A3495EB5E5A for ; Sun, 26 Apr 2009 21:44:04 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 94BF7450C6 for ; Sun, 26 Apr 2009 21:44:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVgHSPsfFxHe for ; Sun, 26 Apr 2009 21:44:04 +0300 (EEST) Received: from marinos.ceid.upatras.gr (marinos.ceid.upatras.gr [150.140.140.17]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 6D1F44503F for ; Sun, 26 Apr 2009 21:44:04 +0300 (EEST) Received: by marinos.ceid.upatras.gr (Postfix, from userid 1001) id 55E3C2287E; Sun, 26 Apr 2009 21:44:04 +0300 (EEST) Date: Sun, 26 Apr 2009 21:44:04 +0300 From: Ilias Marinos To: freebsd-hackers@freebsd.org Message-ID: <20090426184404.GA97073@marinos.ceid.upatras.gr> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline X-PGP-Key: http://diogenis.ceid.upatras.gr/~marinosi/pubkey.asc X-PGP-Fingerprint: B034 ED35 B46E 7AEE D281 2B23 FD63 11AD AFBD 04F9 User-Agent: Mutt/1.5.19 (2009-01-05) Subject: SoC 2009: Application-Specific Audit Trails X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 19:07:19 -0000 Hi people, my name is Ilias Marinos and I am an undergraduate student at Computer Engineering & Informatics Department at University of Patras, Greece. I was accepted to work this summer with my mentor Robert Watson, on designing and impelementing an application-specific audit system, as part of the TrustedBSD project. More information about me and my project can be found at: http://wiki.freebsd.org/IliasMarinos Regards, Ilias Marinos -- echo "Sysadmin know better bash than english." | sed s/min/mins/ \ | sed 's/better bash/bash better/' From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 00:02:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BD6D106564A; Mon, 27 Apr 2009 00:02:49 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id CE43D8FC15; Mon, 27 Apr 2009 00:02:48 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n3QNoWMA027686; Mon, 27 Apr 2009 01:50:32 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Mon, 27 Apr 2009 01:50:31 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904270150.31912.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-performance@freebsd.org Subject: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 00:02:49 -0000 Dear hackers, While fiddling with the sysctl kern.timecounter.hardware, I found out that on my system HPET is significantly faster than ACPI-fast. Using the program below I measured the number of clock_gettime() calls the system can execute per second. I ran the program 10 times for each configuration and here are the results: x ACPI-fast + HPET +-------------------------------------------------------------------------+ |x +| |x +| |x ++| |x ++| |x ++| |x ++| |A |A| +-------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 822032 823752 823551 823397.8 509.43254 + 10 1498348 1506862 1502830 1503267.4 2842.9779 Difference at 95.0% confidence 679870 +/- 1918.94 82.5688% +/- 0.233052% (Student's t, pooled s = 2042.31) System details: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (3200.02-MHz 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated today. Unfortunately I only have one system with a HPET timecounter, so I cannot verify these results on another system. If similar results are obtained on other machines, I think the HPET timecounter quality needs to be increased beyond that of ACPI-fast. Regards, Pieter de Goeje ----- 8< ----- clock_gettime.c ----- 8< ------ #include #include #include #define COUNT 1000000 int main() { struct timespec ts_start, ts_stop, ts_read; double time; int i; clock_gettime(CLOCK_MONOTONIC, &ts_start); for(i = 0; i < COUNT; i++) { clock_gettime(CLOCK_MONOTONIC, &ts_read); } clock_gettime(CLOCK_MONOTONIC, &ts_stop); time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec - ts_start.tv_nsec) * 1E-9; printf("%.0f\n", COUNT / time); } From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 03:00:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DEB106566C; Mon, 27 Apr 2009 03:00:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 73DE48FC1A; Mon, 27 Apr 2009 03:00:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk18 with SMTP id 18so1848438gxk.19 for ; Sun, 26 Apr 2009 20:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pUsvqDt7M19zmTn73Ua5JkFaCAcDPz5upV4j6KHS6gU=; b=EqBhSoTUo8WleHQEQGXUYWp492f6G4Sz1J1zyEIYTpKJ/YO2x3NScnkxXTs0dgYR+B wC1+KIctsOikschyc8WRFj4rbR4cwqso7EnhGTsYXuwFkCwenx2lQRe3Nb7oLLc1e6F3 yS88oojYEv0k4azpzErgpA9o/OB9se1MrCfFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rbtBMdtv6Z/FGX7UUBBjW1dyUnXlVLffL7WNEVR3qjvYOFnTkBtKEsKiXbIpZVJKyr n9MmiG22AoaUIfNJHbt7WQ3ZxG42hdBPaOufyBEMgvXjmqpXfG08VNDErnDA3NoTWGwQ iXPu/kxbCoKWBjayHhvlMKVMx0MM+UKsLuVi8= MIME-Version: 1.0 Received: by 10.151.137.5 with SMTP id p5mr7844582ybn.223.1240799262908; Sun, 26 Apr 2009 19:27:42 -0700 (PDT) In-Reply-To: <200904270150.31912.pieter@degoeje.nl> References: <200904270150.31912.pieter@degoeje.nl> Date: Sun, 26 Apr 2009 19:27:42 -0700 Message-ID: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> From: Garrett Cooper To: Pieter de Goeje Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: acpi , freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:00:32 -0000 On Sun, Apr 26, 2009 at 4:50 PM, Pieter de Goeje wrote: > Dear hackers, > > While fiddling with the sysctl kern.timecounter.hardware, I found out tha= t on > my system HPET is significantly faster than ACPI-fast. Using the program > below I measured the number of clock_gettime() calls the system can execu= te > per second. I ran the program 10 times for each configuration and here ar= e > the results: > > x ACPI-fast > + HPET > +------------------------------------------------------------------------= -+ > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |x =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0++| > |A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|A| > +------------------------------------------------------------------------= -+ > =A0 =A0N =A0 =A0 =A0 =A0 =A0 Min =A0 =A0 =A0 =A0 =A0 Max =A0 =A0 =A0 =A0M= edian =A0 =A0 =A0 =A0 =A0 Avg =A0 =A0 =A0 =A0Stddev > x =A010 =A0 =A0 =A0 =A0822032 =A0 =A0 =A0 =A0823752 =A0 =A0 =A0 =A0823551= =A0 =A0 =A0823397.8 =A0 =A0 509.43254 > + =A010 =A0 =A0 =A0 1498348 =A0 =A0 =A0 1506862 =A0 =A0 =A0 1502830 =A0 = =A0 1503267.4 =A0 =A0 2842.9779 > Difference at 95.0% confidence > =A0 =A0 =A0 =A0679870 +/- 1918.94 > =A0 =A0 =A0 =A082.5688% +/- 0.233052% > =A0 =A0 =A0 =A0(Student's t, pooled s =3D 2042.31) > > System details: Intel(R) Core(TM)2 Duo CPU E6750 =A0@ 2.66GHz (3200.02-MH= z > 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updat= ed > today. > > Unfortunately I only have one system with a HPET timecounter, so I cannot > verify these results on another system. If similar results are obtained o= n > other machines, I think the HPET timecounter quality needs to be increase= d > beyond that of ACPI-fast. > > Regards, > > Pieter de Goeje > > ----- 8< ----- clock_gettime.c ----- 8< ------ > #include > #include > #include > > #define COUNT 1000000 > > int main() { > =A0 =A0 =A0 =A0struct timespec ts_start, ts_stop, ts_read; > =A0 =A0 =A0 =A0double time; > =A0 =A0 =A0 =A0int i; > > =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_start); > =A0 =A0 =A0 =A0for(i =3D 0; i < COUNT; i++) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_read); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0clock_gettime(CLOCK_MONOTONIC, &ts_stop); > > =A0 =A0 =A0 =A0time =3D (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_= nsec - > ts_start.tv_nsec) * 1E-9; > =A0 =A0 =A0 =A0printf("%.0f\n", COUNT / time); > } I'm seeing similar results. [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "' Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "HPET" frequency 14318180 Hz quality 900 [root@orangebox /usr/home/gcooper]# ./cgt 1369355 [root@orangebox /usr/home/gcooper]# sysctl kern.timecounter.hardware=3D"ACPI-fast" kern.timecounter.hardware: HPET -> ACPI-fast [root@orangebox /usr/home/gcooper]# ./cgt 772289 Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =3D])? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 03:13:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1E5C106564A for ; Mon, 27 Apr 2009 03:13:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3D28FC0A for ; Mon, 27 Apr 2009 03:13:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1424778yxb.13 for ; Sun, 26 Apr 2009 20:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DmLr2JoR9kOibyGOAjVFnIgsAkDVI/KTBkFc4DGB9Rk=; b=EJd8kxPIeGYSTP2cps+uLuFp+MI/Z4Uw5O5uWlukw+C5W0s+TBEVLykAUR0xw/qQGH O7nrj4DEn+riEcRqmzJKLtMocT6+V9uHcdoAiAjMVynOsFZZIuXVFZzQpEE2Aim72gcZ RQjZMTJF6UjzC+aY8GdzxYYWXftZ6yZJET7Do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fB4kTxOk185EERZxTa5QyjqcVz9ukPTfD+K5ElqGC6uNC+UBj3JZqJM1NVFn2uAMvr 82LtC5nmJ1QWiZrO4oAgeU+P2WVEJHZaZeZKKmiFxqIuI4UKqSa0ridlNG2G4cmw/dJZ xHn7IIaS28HRJbtI9UpwP9jGcOHFo5AvZx27E= MIME-Version: 1.0 Received: by 10.151.138.4 with SMTP id q4mr8032288ybn.157.1240801979596; Sun, 26 Apr 2009 20:12:59 -0700 (PDT) In-Reply-To: <49F260E5.3080505@FreeBSD.org> References: <49F260E5.3080505@FreeBSD.org> Date: Sun, 26 Apr 2009 20:12:59 -0700 Message-ID: <7d6fde3d0904262012r7a0e176coc5d0cbcdbfbfec01@mail.gmail.com> From: Garrett Cooper To: Gabor PALI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: SoC2009: Design and Implementation of Subsystem Support Libraries for Monitoring and Management X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:13:00 -0000 On Fri, Apr 24, 2009 at 6:01 PM, Gabor PALI wrote: > Hi there, > > I am Gabor Pali from Hungary, a PhD student at Eotvos Lorand University, > Budapest and Babes-Bolyai University, Cluj-Napoca. =A0Offically, I have > been working on FreeBSD for a year, and I got a doc commit bit for my > Hungarian translations and documentation work, and now I also received a > ports commit bit for my further contributions to the ports tree. =A0I hav= e > been using FreeBSD for almost eight years now, and I am interested in > development of operating systems. > > During Summer of Code 2009, I will be working on wrapper libraries for > the network and process functions to support monitoring and management > applications to avoid direct use of the FreeBSD kernel memory interface. > This approach would allow the kernel implementation to change and > monitoring applications to be extended without breaking applications and > requiring them to be recompiled. =A0For this project, my mentor will be > Oleksandr Tymoshenko (gonzo@). > > A more detailed version of my Summer of Code 2009 proposal can be found > on the FreeBSD Wiki: > > http://wiki.freebsd.org/PGJSoC2009 > > > Feel free to review and comment on it. > > > Cheers, > :g Sounds like good work to do Gabor. Good luck on the project :). Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 03:29:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDC29106564A for ; Mon, 27 Apr 2009 03:29:49 +0000 (UTC) (envelope-from upczhsh@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 76FE48FC0A for ; Mon, 27 Apr 2009 03:29:49 +0000 (UTC) (envelope-from upczhsh@gmail.com) Received: by qyk3 with SMTP id 3so4397527qyk.3 for ; Sun, 26 Apr 2009 20:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dzdu5FTl5BoFiZywifjvAnbg4nkhr4ANITpG3TtuB1M=; b=TSMX071uDVxEfnJhWevxlxy5kEukKnG2y9WW75f0pcI7EEjwx4oSWumxy/V+Rkod9m TKZ2VduB9zc5ZMrgPl8XdJLLLs8YUjXld0eq0rKVZjyXeLHJZGo9+nsZaDC3D5HVhEaH VnXAwvw5cyQVi0ybIZEIJdvtrZ0ddcgYh4d0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Bdd9QgZI35iDfEZR91VgT6YgJLJZ0peknU16yowOsnJJmJQpE3Epqv4k4VZjDlJaGI m7jAvlv8AZ+uBZiFWTDn4A8FuiPOaB900R57YbCImpLjXKtnRA3WAPUnIllhTPrjRbhg 1EZw1zmjmIlrFueNJ4ZV0axy7p7ol4sBLkxEk= MIME-Version: 1.0 Sender: upczhsh@gmail.com Received: by 10.229.96.10 with SMTP id f10mr2179072qcn.72.1240801337636; Sun, 26 Apr 2009 20:02:17 -0700 (PDT) Date: Mon, 27 Apr 2009 11:02:17 +0800 X-Google-Sender-Auth: c3865922f3ed1612 Message-ID: <8126ef5c0904262002p58b9a494l29fa20ef0fc34547@mail.gmail.com> From: Zhao Shuai To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GSoC - FIFO Optimizations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:29:50 -0000 Hi there, My name is Zhao Shuai and I am a postgraduate from China. This summer I will work on FIFO optimization project with my mentor John Baldwin. More details on my project, visit the wiki page: http://wiki.freebsd.org/SOC2009ZhaoShuai -- Regards, Zhao From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 13:46:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD811106566B for ; Mon, 27 Apr 2009 13:46:30 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 883888FC1A for ; Mon, 27 Apr 2009 13:46:30 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 4202F6670C for ; Mon, 27 Apr 2009 15:46:23 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 6F41B1BDC9E; Mon, 27 Apr 2009 15:46:18 +0200 (CEST) Date: Mon, 27 Apr 2009 15:46:18 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20090427134617.GA688@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200904270150.31912.pieter@degoeje.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904270150.31912.pieter@degoeje.nl> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:46:31 -0000 On Mon, Apr 27, 2009 at 01:50:31AM +0200, Pieter de Goeje wrote: > While fiddling with the sysctl kern.timecounter.hardware, I found out > that on my system HPET is significantly faster than ACPI-fast. I did some extensive testing on a variety of AMD and Intel boards and never found a system where HPET is slower than ACPI-fast. In addition, HPET provides a higher resolution. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 13:45:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B301065670 for ; Mon, 27 Apr 2009 13:45:31 +0000 (UTC) (envelope-from jan@melen.org) Received: from foxgw.melen.org (unknown [IPv6:2001:14b8:400:f00::ffff]) by mx1.freebsd.org (Postfix) with ESMTP id E7AB68FC14 for ; Mon, 27 Apr 2009 13:45:30 +0000 (UTC) (envelope-from jan@melen.org) X-Bogosity: Ham, spamicity=0.000000 Received: from despair.unknown.com (foxgw.melen.org [IPv6:2001:14b8:400:f00::ffff]) by foxgw.melen.org (8.14.2/8.14.2) with ESMTP id n3RDjSAc027496 for ; Mon, 27 Apr 2009 16:45:29 +0300 (EEST) (envelope-from jan@melen.org) Message-ID: <49F5B6F8.4040808@melen.org> Date: Mon, 27 Apr 2009 16:45:28 +0300 From: Jan Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20090418) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at foxgw.melen.org X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 27 Apr 2009 13:53:43 +0000 Subject: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:45:32 -0000 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. Regards, Jan From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 16:10:17 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D6910656E8 for ; Mon, 27 Apr 2009 16:10:17 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 006B38FC20 for ; Mon, 27 Apr 2009 16:10:16 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LyTPO-0002iu-OI for freebsd-hackers@FreeBSD.org; Mon, 27 Apr 2009 20:10:18 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id AB26FF895 for ; Mon, 27 Apr 2009 20:10:51 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 24352108841; Mon, 27 Apr 2009 20:09:30 +0400 (MSD) Date: Mon, 27 Apr 2009 20:09:30 +0400 From: Dmitry Marakasov To: freebsd-hackers@FreeBSD.org Message-ID: <20090427160930.GB48365@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: [patch] kernel iconv improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:10:17 -0000 Hi! Here's a little improvement for kernel iconv. It makes kiconv ignore case of character set names (and also store them in uppercase for consistency), so mount_cd9660 -C koi8-r /dev/acd0 /mnt mount_cd9660 -C KOI8-r /dev/acd0 /mnt mount_cd9660 -C KOI8-R /dev/acd0 /mnt mount_cd9660 -C Koi8-r /dev/acd0 /mnt will no longer lead to loading four similar charset conversion tables instead of one. See also ports/sysutils/kiconvtool - can it be integrated into the base system? The purpose of all this is more convenient and effective handling of filesystem charset conversion (especially for usermounts). --- iconv.c.patch begins here --- Index: sys/libkern/iconv.c =================================================================== --- sys/libkern/iconv.c (revision 191469) +++ sys/libkern/iconv.c (working copy) @@ -33,6 +33,7 @@ #include __FBSDID("$FreeBSD$"); +#include #include #include #include @@ -171,8 +172,8 @@ struct iconv_cspair *csp; TAILQ_FOREACH(csp, &iconv_cslist, cp_link) { - if (strcmp(csp->cp_to, to) == 0 && - strcmp(csp->cp_from, from) == 0) { + if (strcasecmp(csp->cp_to, to) == 0 && + strcasecmp(csp->cp_from, from) == 0) { if (cspp) *cspp = csp; return 0; @@ -207,12 +208,16 @@ if (!ucsto) { strcpy(cp, to); csp->cp_to = cp; - cp += strlen(cp) + 1; + for (; *cp; cp++) + *cp = toupper(*cp); + cp++; } else csp->cp_to = iconv_unicode_string; if (!ucsfrom) { strcpy(cp, from); csp->cp_from = cp; + for (; *cp; cp++) + *cp = toupper(*cp); } else csp->cp_from = iconv_unicode_string; csp->cp_data = data; --- iconv.c.patch ends here --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 18:08:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7504106567D for ; Mon, 27 Apr 2009 18:08:39 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 698368FC1F for ; Mon, 27 Apr 2009 18:08:39 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n3RI8cku090274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 11:08:38 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49F5F4A6.8050902@freebsd.org> Date: Mon, 27 Apr 2009 11:08:38 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Jan Melen References: <49F5B6F8.4040808@melen.org> In-Reply-To: <49F5B6F8.4040808@melen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:08:40 -0000 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. IPsec incurs a performance hit. Fix that and it can be enabled in GENERIC. Sam From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 18:38:16 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91CF11065675 for ; Mon, 27 Apr 2009 18:38:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 505A78FC08 for ; Mon, 27 Apr 2009 18:38:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n3RIcb1V010844; Mon, 27 Apr 2009 14:38:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n3RIcan7010843; Mon, 27 Apr 2009 14:38:36 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 27 Apr 2009 14:38:36 -0400 From: David Schultz To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= Message-ID: <20090427183836.GA10793@zim.MIT.EDU> Mail-Followup-To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: hackers@FreeBSD.ORG Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:38:17 -0000 On Thu, Apr 23, 2009, Gábor Kövesdán wrote: > Hello all, > > my name is Gábor Kövesdán. I'm a Hungarian student and I'll be working on > a BSD-licensed libiconv implementation for FreeBSD during this year's > Summer of Code program. It'll be based on NetBSD's Citrus iconv but there > is a lot to do besides porting. My mentor is Xin Li. Nice. I'm sure many people will thank you for this. One complaint I've heard about both our wide character implementation and Citrus iconv is that the internal (wchar_t) encoding depends on the current locale. (Basically it uses a packed binary version of whatever the external representation is.) The relevant standards allow this, but it can be a pain for application and library writers. One thing to think about is whether it would make more sense to standardize on something like UCS-4 for the internal representation. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 18:46:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8242C106566B; Mon, 27 Apr 2009 18:46:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 39DBA8FC18; Mon, 27 Apr 2009 18:46:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DD4B041C795; Mon, 27 Apr 2009 20:30:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pUq4qg33Q40G; Mon, 27 Apr 2009 20:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 87E6D41C76D; Mon, 27 Apr 2009 20:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 3F74C4448E6; Mon, 27 Apr 2009 18:29:46 +0000 (UTC) Date: Mon, 27 Apr 2009 18:29:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Sam Leffler In-Reply-To: <49F5F4A6.8050902@freebsd.org> Message-ID: <20090427182917.W15361@maildrop.int.zabbadoz.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jan Melen , freebsd-hackers@freebsd.org Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 18:46:55 -0000 On Mon, 27 Apr 2009, Sam Leffler wrote: Hi, > 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. > IPsec incurs a performance hit. Fix that and it can be enabled in GENERIC. There is even a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 19:13:57 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69CF6106564A for ; Mon, 27 Apr 2009 19:13:57 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 278218FC15 for ; Mon, 27 Apr 2009 19:13:56 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n3RInfki061286; Mon, 27 Apr 2009 11:49:42 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 8bfjacvdreu9fddp8ccf7725re; Mon, 27 Apr 2009 11:49:41 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49F5FE45.2090101@freebsd.org> Date: Mon, 27 Apr 2009 11:49:41 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> In-Reply-To: <20090427183836.GA10793@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:13:57 -0000 David Schultz wrote: > ... whether it would make more sense to standardize on something like > UCS-4 for the internal representation. YES. Without this, wchar_t is useless. Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 19:33:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57CCF1065686 for ; Mon, 27 Apr 2009 19:33:24 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id D31688FC0C for ; Mon, 27 Apr 2009 19:33:23 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 3F6F26674D; Mon, 27 Apr 2009 21:33:21 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 30D4D1BDCD5; Mon, 27 Apr 2009 21:33:27 +0200 (CEST) Date: Mon, 27 Apr 2009 21:33:26 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20090427193326.GA7654@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F5FE45.2090101@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:33:24 -0000 On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > David Schultz wrote: >> ... whether it would make more sense to standardize on something like >> UCS-4 for the internal representation. > > YES. Without this, wchar_t is useless. I strongly disagree. Everything can be represented as UCS-4 is a bad assumption, but something Americans and Europeans naturally don't have to care about. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 19:48:42 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE5B106566B for ; Mon, 27 Apr 2009 19:48:42 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id A9DD38FC19 for ; Mon, 27 Apr 2009 19:48:42 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n3RJn4hO011170 for ; Mon, 27 Apr 2009 15:49:04 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n3RJn4Vk011169 for freebsd-hackers@freebsd.org; Mon, 27 Apr 2009 15:49:04 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 27 Apr 2009 15:49:04 -0400 From: David Schultz To: freebsd-hackers@FreeBSD.ORG Message-ID: <20090427194904.GA11137@zim.MIT.EDU> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090427193326.GA7654@britannica.bec.de> Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:48:43 -0000 On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > > David Schultz wrote: > >> ... whether it would make more sense to standardize on something like > >> UCS-4 for the internal representation. > > > > YES. Without this, wchar_t is useless. > > I strongly disagree. Everything can be represented as UCS-4 is a bad > assumption, but something Americans and Europeans naturally don't have > to care about. ...but isn't this moot at present because there are no widely-accepted encodings that include characters that aren't supported by UCS-4? Citrus doesn't seem to support any such encodings in any case. If this ever really becomes an issue, we could always stuff locale-dependent encodings into unused UCS-4 code pages. However, it doesn't seem worthwhile to deliberately burden programmers over concerns that are presently, and for the foreseeable future, hypothetical. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 19:49:43 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E67A3106567D for ; Mon, 27 Apr 2009 19:49:43 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3758FC23 for ; Mon, 27 Apr 2009 19:49:43 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 3F6F26674D; Mon, 27 Apr 2009 21:33:21 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 30D4D1BDCD5; Mon, 27 Apr 2009 21:33:27 +0200 (CEST) Date: Mon, 27 Apr 2009 21:33:26 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Message-ID: <20090427193326.GA7654@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F5FE45.2090101@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:49:44 -0000 On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: > David Schultz wrote: >> ... whether it would make more sense to standardize on something like >> UCS-4 for the internal representation. > > YES. Without this, wchar_t is useless. I strongly disagree. Everything can be represented as UCS-4 is a bad assumption, but something Americans and Europeans naturally don't have to care about. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 20:08:18 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07BFA1065670 for ; Mon, 27 Apr 2009 20:08:18 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id B5E5A8FC15 for ; Mon, 27 Apr 2009 20:08:17 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 51C9D6674D for ; Mon, 27 Apr 2009 22:08:16 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 469DF1BDCD5; Mon, 27 Apr 2009 22:08:22 +0200 (CEST) Date: Mon, 27 Apr 2009 22:08:22 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20090427200821.GA6665@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090427194904.GA11137@zim.MIT.EDU> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:08:18 -0000 On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > ...but isn't this moot at present because there are no > widely-accepted encodings that include characters that > aren't supported by UCS-4? Citrus doesn't seem to support > any such encodings in any case. "Just" using UCS-4 not necessarily buys you the desired affect. Keep in mind that UCS-4 is still a variable width encoding, as soon as you factor combining characters and some other interesting parts in. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 02:42:21 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780CB1065674 for ; Tue, 28 Apr 2009 02:42:21 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 363BC8FC1C for ; Tue, 28 Apr 2009 02:42:21 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n3S2gkpU012945 for ; Mon, 27 Apr 2009 22:42:46 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n3S2gkZ5012944 for freebsd-hackers@freebsd.org; Mon, 27 Apr 2009 22:42:46 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 27 Apr 2009 22:42:46 -0400 From: David Schultz To: freebsd-hackers@FreeBSD.ORG Message-ID: <20090428024246.GA12887@zim.MIT.EDU> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <20090427200821.GA6665@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090427200821.GA6665@britannica.bec.de> Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 02:42:21 -0000 On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > > ...but isn't this moot at present because there are no > > widely-accepted encodings that include characters that > > aren't supported by UCS-4? Citrus doesn't seem to support > > any such encodings in any case. > > "Just" using UCS-4 not necessarily buys you the desired affect. > Keep in mind that UCS-4 is still a variable width encoding, as soon as > you factor combining characters and some other interesting parts in. This is true, but unfortunately C99 wasn't really designed to support combining characters. I don't understand how this relates to the present discussion. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 06:58:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320091065670 for ; Tue, 28 Apr 2009 06:58:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id B6C678FC1F for ; Tue, 28 Apr 2009 06:58:21 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by fxm6 with SMTP id 6so343520fxm.43 for ; Mon, 27 Apr 2009 23:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=N7FF2f24FoG2jl3Tn9e0eaCXS4Gmp+8q3Jm8eXEtxU8=; b=RBS+mSj2pWcMiBtp/OamIzvzQZy8VR6Jf5WCGnqOArmJe/h7Dm+gQds3rrj30Kfynv es3We4tvRzFUC0j1TGJrXkPFo/bLc1ce2QdY4kEZOP8DiN+sjezTH5dfnFXPGSsn9gp9 dOAbDEYXhwYzvzNW8rwMokSiE/ik+j8KnWezc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=wYuItQmJ6dq1FafxC4Oge+OaG6iGV5JdHhJuZs4e1loO0Q8ctNm7ObISf7DIRe85dh UNFRQ/5+wWN+zrPCLZ3OQhJDq4JLrHMeGuuFyYFo1OKp7dYCavy6ZhWoYjJWO5mldu/W zkOETQpP79RlREwzPf9O9s04c/HySwPL3T6CY= MIME-Version: 1.0 Sender: ndenev@gmail.com Received: by 10.223.107.198 with SMTP id c6mr2149181fap.32.1240900422476; Mon, 27 Apr 2009 23:33:42 -0700 (PDT) In-Reply-To: <20090427182917.W15361@maildrop.int.zabbadoz.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> Date: Tue, 28 Apr 2009 09:33:42 +0300 X-Google-Sender-Auth: eccc9fa052eefab2 Message-ID: <2e77fc10904272333j60151a0au2682ae39e201c015@mail.gmail.com> From: Niki Denev To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:58:22 -0000 On Mon, Apr 27, 2009 at 9:29 PM, Bjoern A. Zeeb wrote: > On Mon, 27 Apr 2009, Sam Leffler wrote: > > Hi, > >> Jan Melen wrote: >>> >>> Hi, >>> >>> Again when I compiled a custom kernel just to enable IPsec in the FreeB= SD >>> 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. >> >> IPsec incurs a performance hit. =A0Fix that and it can be enabled in >> GENERIC. > > There is even a PR for this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dconf/128030 > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The greatest ri= sk is not taking one. Hello, Does anyone have any numbers on how much the performance degrades with IPSEC enabled? I'm just curious. Regards, Niki From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 08:50:37 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00DD106566B for ; Tue, 28 Apr 2009 08:50:37 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1A08FC12 for ; Tue, 28 Apr 2009 08:50:37 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 82DFC14D5379; Tue, 28 Apr 2009 10:34:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 617Ydm55RFyW; Tue, 28 Apr 2009 10:34:00 +0200 (CEST) Received: from [192.168.1.105] (catv-80-98-231-64.catv.broadband.hu [80.98.231.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id AAF3E14D536F; Tue, 28 Apr 2009 10:34:00 +0200 (CEST) Message-ID: <49F6BF6C.1050903@FreeBSD.org> Date: Tue, 28 Apr 2009 10:33:48 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= , hackers@FreeBSD.ORG References: <20090427183836.GA10793@zim.MIT.EDU> In-Reply-To: <20090427183836.GA10793@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:50:38 -0000 David Schultz escribió: > On Thu, Apr 23, 2009, Gábor Kövesdán wrote: > >> Hello all, >> >> my name is Gábor Kövesdán. I'm a Hungarian student and I'll be working on >> a BSD-licensed libiconv implementation for FreeBSD during this year's >> Summer of Code program. It'll be based on NetBSD's Citrus iconv but there >> is a lot to do besides porting. My mentor is Xin Li. >> > > Nice. I'm sure many people will thank you for this. > I hope my work will be useful for the community. Btw, I suspected that you might be interested in this and I wrote a mail personally to you when I was looking for a mentor. Then I didn't resend it because delphij@ volunteered to be my mentor. Have you ever got that mail? If you find this an interesting project your comments, review, etc. are still highly welcome. > One complaint I've heard about both our wide character > implementation and Citrus iconv is that the internal (wchar_t) > encoding depends on the current locale. (Basically it uses a > packed binary version of whatever the external representation is.) > The relevant standards allow this, but it can be a pain for > application and library writers. One thing to think about is > whether it would make more sense to standardize on something like > UCS-4 for the internal representation. > I haven't got to such details yet, so I didn't know this. But UCS-4 seems to be reasonable for me. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 09:25:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67D06106564A for ; Tue, 28 Apr 2009 09:25:38 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id D0DD58FC08 for ; Tue, 28 Apr 2009 09:25:37 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 7C65E14D5379 for ; Tue, 28 Apr 2009 11:08:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7NP5MpY8x3Yr for ; Tue, 28 Apr 2009 11:08:50 +0200 (CEST) Received: from [192.168.1.105] (catv-80-98-231-64.catv.broadband.hu [80.98.231.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 00DC014D536F for ; Tue, 28 Apr 2009 11:08:49 +0200 (CEST) Message-ID: <49F6C7A1.6070708@FreeBSD.org> Date: Tue, 28 Apr 2009 11:08:49 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> In-Reply-To: <20090427194904.GA11137@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:25:38 -0000 David Schultz escribió: > On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > >> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: >> >>> David Schultz wrote: >>> >>>> ... whether it would make more sense to standardize on something like >>>> UCS-4 for the internal representation. >>>> >>> YES. Without this, wchar_t is useless. >>> >> I strongly disagree. Everything can be represented as UCS-4 is a bad >> assumption, but something Americans and Europeans naturally don't have >> to care about. >> > > ...but isn't this moot at present because there are no > widely-accepted encodings that include characters that > aren't supported by UCS-4? Citrus doesn't seem to support > any such encodings in any case. > Citrus is based on UCS-4 as an internal encoding, just like the another BSD-licensed iconv library. This is a barrier to support encodings that aren't supported by UCS-4. > If this ever really becomes an issue, we could always stuff > locale-dependent encodings into unused UCS-4 code pages. > However, it doesn't seem worthwhile to deliberately burden > programmers over concerns that are presently, and for the > foreseeable future, hypothetical. > I'm not a Unicode expert, but isn't the reason of periodical standard reviews and changes to cover more and more human languages? We could just support the latest Unicode standard and let the Unicode workgroups map those new characters into unused code points. The Latin-based, Cyrillic, Devanagari and CJK encodings are well-supported, I think. I don't know too much about CJK encondings, though, if the thousands of ideographs are all supported or not. But I'd say the most significant languages that are used on the Internet are supported, the rest might have another problems... [OFF] It's possible that there are little poor countries with an own writing system but probably their writing system is unsupported because the starvation, poorness and lack of water and electricity are more serious problems there. My ex-girlfriend is working in Nepal in a cooperation program (it's kinda scholarship) and she told me that they only have electricity in 8 hours a day, 4 during the night and 4 during the day. There are no sidewalks for pedestrians, they go along with the cars on the street and the pollution is extremely high. Even this country's encoding is supported. What I am trying to say is that countries with unsupported languages probably won't really care about character encodings if they rarely have computers... I can just hope that their living conditions will get better and their language will be supported. I can also hope that the Unicode people will focus more on these countries instead of fucking up the time with fictionary languages from fairy tales... [1] Probably I'll go to visit her in Nepal in January, it will be an interesting experience. I'll check if I can help the IT world there with anything. [ON] Another idea to consider. Are all of our utilities wchar-clean? What about library functions? (regex is surely not) Do we lack any important utility or library? (we still do lack iconv and gettext and what else...?) What about standards, like C99 wchar functions? Is there something missing? What about POSIX if it has something related? Personally, I think that these are more important questions than support of some extremely rare languages. It's worth to consider how to deal with them later but the basic problems need a higher priority. [1] http://en.wikipedia.org/wiki/Tengwar#Unicode Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 10:19:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B5391065670 for ; Tue, 28 Apr 2009 10:19:16 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id AD8F78FC14 for ; Tue, 28 Apr 2009 10:19:15 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id F416E6674D for ; Tue, 28 Apr 2009 12:19:12 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 213DC1BDD7B; Tue, 28 Apr 2009 12:19:20 +0200 (CEST) Date: Tue, 28 Apr 2009 12:19:19 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20090428101919.GA552@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <20090427200821.GA6665@britannica.bec.de> <20090428024246.GA12887@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090428024246.GA12887@zim.MIT.EDU> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:19:16 -0000 On Mon, Apr 27, 2009 at 10:42:46PM -0400, David Schultz wrote: > On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: > > On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: > > > ...but isn't this moot at present because there are no > > > widely-accepted encodings that include characters that > > > aren't supported by UCS-4? Citrus doesn't seem to support > > > any such encodings in any case. > > > > "Just" using UCS-4 not necessarily buys you the desired affect. > > Keep in mind that UCS-4 is still a variable width encoding, as soon as > > you factor combining characters and some other interesting parts in. > > This is true, but unfortunately C99 wasn't really designed to > support combining characters. I don't understand how this relates > to the present discussion. The main reason people want to use wchar_t is because they want to use a fixed width presentation of characters. Just using UCS-4 doesn't give you that if you ever want to support Level 2 and higher. It also highlights UCS-4 is not that state independent as it is often thought to be. That is again something undesirable. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 10:45:55 2009 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2F331065677; Tue, 28 Apr 2009 10:45:54 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id BC5178FC20; Tue, 28 Apr 2009 10:45:54 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n3SARNL1077741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 03:27:24 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49F6DA03.2010404@FreeBSD.org> Date: Tue, 28 Apr 2009 03:27:15 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ivan Voras References: <49F6CA67.6030302@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Improving geom_mirror(4)'s read balancing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 10:45:55 -0000 Ivan Voras wrote: > Maxim Sobolev wrote: > >> The patch is available here: >> http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like to >> get input on the functionality/code itself, as well on what is the best >> way to add this functionality. Right now, it's part of the round-robin >> balancing code. Technically, it could be added as a separate new >> balancing method, but for the reasons outlined above I really doubt >> having "pure" round-robin has any practical value now. The only case >> where previous behavior might be beneficial is with solid-state/RAM >> disks where there is virtually no seek time, so that by reading close >> sectors from two separate disks one could actually get a better speed. >> At the very least, the new method should become default, while "old >> round-robin" be another option with clearly documented shortcomings. I >> would really like to hear what people think about that. > > Have you perhaps seen this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885 > > I'm using the patch in the PR and it helps a bit, similar to what you > have seen. Pawel is silent about the issue so I guess it can also be > taken as silent approval :) Oh, great! I am curious as to if there is any background behind "distance to use delay" metric? To me it seems the current number of outstanding requests is much more important when selecting between disk X and disk Y. I am not a storage expert, so that I could be wrong though. One way or another the load-balancing has be improved and the new more intelligent scheduling IMHO should be the default one. -Maxim From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 06:36:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 881CA1065672; Tue, 28 Apr 2009 06:36:28 +0000 (UTC) (envelope-from jan@melen.org) Received: from foxgw.melen.org (unknown [IPv6:2001:14b8:400:f00::ffff]) by mx1.freebsd.org (Postfix) with ESMTP id 092038FC13; Tue, 28 Apr 2009 06:36:27 +0000 (UTC) (envelope-from jan@melen.org) X-Bogosity: Ham, spamicity=0.000000 Received: from despair.unknown.com (foxgw.melen.org [IPv6:2001:14b8:400:f00::ffff]) by foxgw.melen.org (8.14.2/8.14.2) with ESMTP id n3S6aQkp068463; Tue, 28 Apr 2009 09:36:26 +0300 (EEST) (envelope-from jan@melen.org) Message-ID: <49F6A3EA.3090905@melen.org> Date: Tue, 28 Apr 2009 09:36:26 +0300 From: Jan Melen User-Agent: Thunderbird 2.0.0.7pre (X11/20090418) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> In-Reply-To: <20090427182917.W15361@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at foxgw.melen.org X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 28 Apr 2009 11:37:34 +0000 Cc: freebsd-hackers@freebsd.org, Sam Leffler Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:36:29 -0000 Hi, Bjoern A. Zeeb wrote: > On Mon, 27 Apr 2009, Sam Leffler wrote: > > Hi, > >> 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. >> IPsec incurs a performance hit. Fix that and it can be enabled in >> GENERIC. > > There is even a PR for this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128030 > Just to understand the problem correctly I guess you are talking about performance hit on outgoing packets as the IPsec tries to find a security policy even for packets that should not be encrypted? For incoming traffic I don't see any reason for performance hit. Has anyone done any measurements on magnitude of performance loss we get from trying to match the outgoing packets for non-existent IPsec policies? I would guess that if you have zero SPD entries in your system it can't be a lot as it a matter of calling: ip_ipsec_output -> ipsec4_checkpolicy -> ipsec_getpolicybyaddr/sock -> key_allocsp which in turn searches through an empty list. Jan From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 11:48:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A28B1065674 for ; Tue, 28 Apr 2009 11:48:00 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7798FC19 for ; Tue, 28 Apr 2009 11:47:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n3SBltg8018406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 21:47:57 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n3SBlsKD090048; Tue, 28 Apr 2009 21:47:54 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n3SBlskM090047; Tue, 28 Apr 2009 21:47:54 +1000 (EST) (envelope-from peter) Date: Tue, 28 Apr 2009 21:47:54 +1000 From: Peter Jeremy To: Christoph Mallon Message-ID: <20090428114754.GB89235@server.vk2pj.dyndns.org> References: <49F4070C.2000108@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <49F4070C.2000108@gmx.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:48:00 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Apr-26 09:02:36 +0200, Christoph Mallon w= rote: >as some of you may have noticed, several years ago a new millenium=20 >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=20 >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. >Maybe using all of these changes is a bit too big change at once, but=20 >I'd like some of them applied to style(9). So, please consider the=20 >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. [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, [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. [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. [ 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. >> +.Sh LOCAL VARIABLES >Last, but definitely not least, I added this paragraph about the use of=20 >local variables. This is to clarify, how today's compilers handle=20 >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. --=20 Peter Jeremy --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkn27OoACgkQ/opHv/APuIesggCZAYozgHNOftliuEVWqEHVRqZR fREAnjb2liAo0fpJ+9oyqhnxIksXWm4A =HkGc -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 12:10:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1AA1065686 for ; Tue, 28 Apr 2009 12:10:38 +0000 (UTC) (envelope-from admin@mercurysquad.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id C91928FC12 for ; Tue, 28 Apr 2009 12:10:37 +0000 (UTC) (envelope-from admin@mercurysquad.com) Received: by wf-out-1314.google.com with SMTP id 24so320606wfg.7 for ; Tue, 28 Apr 2009 05:10:37 -0700 (PDT) MIME-Version: 1.0 Sender: admin@mercurysquad.com Received: by 10.142.13.14 with SMTP id 14mr1450182wfm.108.1240920637425; Tue, 28 Apr 2009 05:10:37 -0700 (PDT) In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> Date: Tue, 28 Apr 2009 17:40:37 +0530 X-Google-Sender-Auth: 66ac82ba21c5886d Message-ID: <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> From: Prashant Vaibhav To: Gabor Kovesdan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:10:38 -0000 > > My ex-girlfriend is working in Nepal [...] Even this country's encoding i= s > supported. Probably because Nepali language doesn't have a separate script, they use Devanagari! :-) On Tue, Apr 28, 2009 at 2:38 PM, Gabor Kovesdan wrote: > David Schultz escribi=C3=B3: > >> On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: >> >> >>> On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: >>> >>> >>>> David Schultz wrote: >>>> >>>> >>>>> ... whether it would make more sense to standardize on something like >>>>> UCS-4 for the internal representation. >>>>> >>>>> >>>> YES. Without this, wchar_t is useless. >>>> >>>> >>> I strongly disagree. Everything can be represented as UCS-4 is a bad >>> assumption, but something Americans and Europeans naturally don't have >>> to care about. >>> >>> >> >> ...but isn't this moot at present because there are no >> widely-accepted encodings that include characters that >> aren't supported by UCS-4? Citrus doesn't seem to support >> any such encodings in any case. >> >> > Citrus is based on UCS-4 as an internal encoding, just like the another > BSD-licensed iconv library. This is a barrier to support encodings that > aren't supported by UCS-4. > >> If this ever really becomes an issue, we could always stuff >> locale-dependent encodings into unused UCS-4 code pages. >> However, it doesn't seem worthwhile to deliberately burden >> programmers over concerns that are presently, and for the >> foreseeable future, hypothetical. >> >> > I'm not a Unicode expert, but isn't the reason of periodical standard > reviews and changes to cover more and more human languages? We could just > support the latest Unicode standard and let the Unicode workgroups map th= ose > new characters into unused code points. The Latin-based, Cyrillic, > Devanagari and CJK encodings are well-supported, I think. I don't know to= o > much about CJK encondings, though, if the thousands of ideographs are all > supported or not. But I'd say the most significant languages that are use= d > on the Internet are supported, the rest might have another problems... > > [OFF] > It's possible that there are little poor countries with an own writing > system but probably their writing system is unsupported because the > starvation, poorness and lack of water and electricity are more serious > problems there. My ex-girlfriend is working in Nepal in a cooperation > program (it's kinda scholarship) and she told me that they only have > electricity in 8 hours a day, 4 during the night and 4 during the day. Th= ere > are no sidewalks for pedestrians, they go along with the cars on the stre= et > and the pollution is extremely high. Even this country's encoding is > supported. What I am trying to say is that countries with unsupported > languages probably won't really care about character encodings if they > rarely have computers... I can just hope that their living conditions wil= l > get better and their language will be supported. I can also hope that the > Unicode people will focus more on these countries instead of fucking up t= he > time with fictionary languages from fairy tales... [1] > Probably I'll go to visit her in Nepal in January, it will be an > interesting experience. I'll check if I can help the IT world there with > anything. > [ON] > > Another idea to consider. Are all of our utilities wchar-clean? What abou= t > library functions? (regex is surely not) Do we lack any important utility= or > library? (we still do lack iconv and gettext and what else...?) What abou= t > standards, like C99 wchar functions? Is there something missing? What abo= ut > POSIX if it has something related? Personally, I think that these are mor= e > important questions than support of some extremely rare languages. It's > worth to consider how to deal with them later but the basic problems need= a > higher priority. > > > [1] http://en.wikipedia.org/wiki/Tengwar#Unicode > > > Cheers, > > -- > Gabor Kovesdan > FreeBSD Volunteer > > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 12:14:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300421065678 for ; Tue, 28 Apr 2009 12:14:06 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E02DE8FC2C for ; Tue, 28 Apr 2009 12:14:05 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id EF9F42798B8; Tue, 28 Apr 2009 13:55:30 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 304B61705A; Tue, 28 Apr 2009 14:03:11 +0200 (CEST) Date: Tue, 28 Apr 2009 14:03:11 +0200 From: VANHULLEBUS Yvan To: Jan Melen Message-ID: <20090428120311.GA68397@zeninc.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> <49F6A3EA.3090905@melen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F6A3EA.3090905@melen.org> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-hackers@freebsd.org Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:14:06 -0000 On Tue, Apr 28, 2009 at 09:36:26AM +0300, Jan Melen wrote: > Hi, [...] > Just to understand the problem correctly I guess you are talking about > performance hit on outgoing packets as the IPsec tries to find a > security policy even for packets that should not be encrypted? For > incoming traffic I don't see any reason for performance hit. The (more or less) same check is done for incoming packets, because we NEED to ensure that IPsec traffic comes from the appropriate IPsec tunnel, and non IPsec traffic comes without IPsec.... > Has anyone done any measurements on magnitude of performance loss we get > from trying to match the outgoing packets for non-existent IPsec > policies? I would guess that if you have zero SPD entries in your system > it can't be a lot as it a matter of calling: > ip_ipsec_output -> ipsec4_checkpolicy -> ipsec_getpolicybyaddr/sock -> > key_allocsp which in turn searches through an empty list. We (my company) already tried such a hack, which completely skips IPsec process if we know that SPD (both in and out) is empty. It works, and has the expected impact on performance loss. Yvan. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 12:22:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9F7106566B for ; Tue, 28 Apr 2009 12:22:24 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF9B8FC1F for ; Tue, 28 Apr 2009 12:22:24 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 553AC6674D for ; Tue, 28 Apr 2009 14:22:19 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id C543F1BDD7B; Tue, 28 Apr 2009 14:22:25 +0200 (CEST) Date: Tue, 28 Apr 2009 14:22:25 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20090428122225.GA2862@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:22:25 -0000 On Tue, Apr 28, 2009 at 11:08:49AM +0200, Gabor Kovesdan wrote: > Citrus is based on UCS-4 as an internal encoding, just like the another > BSD-licensed iconv library. This is a barrier to support encodings that > aren't supported by UCS-4. More precisely is that Citrus can and will use UCS-4 as appropiate. It does not enforce it. Which is an important difference. One reason that it is often used is that it helps to avoid exponential growth of the translation tables. It just isn't worth the time to write ISO-8859-1 to ISO-8859-15 (trivial), if the translation to and from UCS4 gives the same result with marginally more work. > It's possible that there are little poor countries with an own writing > system but probably their writing system is unsupported because the > starvation, poorness and lack of water and electricity are more serious > problems there. I wouldn't call all both parts of Korea little poor countries and it is a wonderful example for why UCS 4 Level 1 can be problematic. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 12:32:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FB410656E5; Tue, 28 Apr 2009 12:32:02 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id E449D8FC16; Tue, 28 Apr 2009 12:32:01 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7ED629CB0A1; Tue, 28 Apr 2009 14:13:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOadVSl43OyX; Tue, 28 Apr 2009 14:13:28 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id DDE539CB1B5; Tue, 28 Apr 2009 14:13:27 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n3SCDROB043302; Tue, 28 Apr 2009 14:13:27 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 28 Apr 2009 14:13:27 +0200 From: Roman Divacky To: Christoph Mallon Message-ID: <20090428121327.GA41168@freebsd.org> References: <49F4070C.2000108@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F4070C.2000108@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , Warner Losh , Ed Schouten , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:32:03 -0000 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.. On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote: > Hi hackers@, > > as some of you may have noticed, several years ago a new millenium > started and a decade ago there was a new C standard. HEAD recently > switched to C99 as default (actually gnu99, but that's rather close). So > it's finally time to re-examine wether style(9) needs to be accomodated. > The diff with the proposed changes is attached. Below are the changes > with some further explanations. They are in the order as they appear in > style(9). > 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. > > >-Do not put declarations > >-inside blocks unless the routine is unusually complicated. > >+Prefer declaring loop iterators in the for-statement to limit their scope. > > .Bd -literal > >- for (; cnt < 15; cnt++) { > >+ for (int cnt = 0; cnt < 15; cnt++) { > [...] > >-When declaring variables in functions declare them sorted by size, > >-then in alphabetical order; multiple ones per line are okay. > >+When declaring variables in functions declare them sorted in alphabetical > >order; > >+prefer one declaration per line, especially when pointer declarators or > >+initializations are involved. > > If a line overflows reuse the type keyword. > > .Pp > >-Be careful to not obfuscate the code by initializing variables in > >-the declarations. > >-Use this feature only thoughtfully. > >-DO NOT use function calls in initializers. > >+Prefer initializing variables right at their declaration. > >+When the value is not supposed to change in the function, make the > >variable > >+const. > >+This makes it easier for a reader to identify the where the value of a > >variable > >+originates. > >+Do not reuse the same variable in a different context, declare a new > >variable. > > .Bd -literal > >- struct foo one, *two; > >- double three; > >- int *four, five; > >- char *six, seven, eight, nine, ten, eleven, twelve; > >+ struct foo *bar; > >+ struct foo baz = { 42, "qux" }; > > > >- four = myfunction(); > >+ FILE *const f = fopen("name", "r"); > >+ if (f == NULL) > >+ err("Failed to open file"); > >+ /* We can safely assume that f is not changed anymore, even if the > >+ * function is a hundred lines long */ > > This change is to reduce the scope of local variables. For reasons why > this does not cost anything in terms of stack space, please see the last > change, which adds explanations about local variables. > Smaller scopes and distinct variables for distinct contexts make it > easier for readers of the code to identify the def-use-chains of > variables, because there are less places with assignments to a variable > and the scope is smaller. Also, when a variable is initialised right at > its declaration and is not supposed to change, you can emphasize this by > making it const. > I looked at older discussions regarding this topic and identified > several concerns, which were raised. I'll address them below: > > - It does not add anything to the language. > Well, yes, just like if, do, for, goto, the comma operator, compound > assignment (+=, ...), ++/-- and many other things. All you need to be > Turing complete is lambda calculus - there hardly can be less syntax. > But, like all mentioned constructs, it makes the code more concise. > > - It leads to sloppy code. You could reuse another variable or should > think again whether you really need this variable. > Reusing variables in different contexts is error prone and bad for > maintainability. You could reuse a variable, which is not as dead as you > thought. More local variables cost nothing, especially no stack space, > see the last proposed changed below. It is good to use more local > variables, because it gives the reader a name, which carries > information. Also it makes it easier for a reader (and the compiler!) to > identify, which expressions are the same. You could repeat > foo->long_name->even_longer_name[2 * i + 1] five times or just declare a > local variable and cache the value to make it easier to read. > It also enables the compiler to produce better warnings: If you declare > a new variable, it is not initialised and if you do not initialise it on > all paths before a use, the compiler will warn you. But if you reuse an > older variable, it is already initialised by its former uses and so you > get no warning, but operate on garbage values (the old value from the > previous use). > So it does not lead to slopyy code, but better code, which is easier to > comprehend, the compiler can better help you to prevent bugs, and as a > side effect the compiler can produce better code (aliasing is a major > problem for common subexpression elimination). > > - You can determine the stack usage with all the variable declarations > at the top. > This is not true. There is no relation between the declared variables > and the stack used. Especially, more stack than suggested by the > declarations can be used due to various optimisations - less space can > be used, too, of course. > > - It is harder to find the declaration of a variable. > Every editor, which is more advanced than ed, has facilities to jump to > the declaration of a variable (e.g. in vim it's "gd"). And most often > this is not necessary, because the declaration is just a few lines above > instead of all the way up at the top of the function, so no jumping > around is required at all. > > - You could accidently shadow a variable. > All modern compilers have warnings for this. FreeBSD uses -Wshadow for > GCC (and all relevant compilers understand this very option). > > > >-Values in > >-.Ic return > >-statements should be enclosed in parentheses. > >-.Pp > > 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. > > > >-Old-style function declarations look like this: > >-.Bd -literal > >-static char * > >-function(a1, a2, fl, a4) > >- int a1, a2; /* Declare ints, too, don't default them. */ > >- float fl; /* Beware double vs. float prototype differences. */ > >- int a4; /* List in order declared. */ > >-{ > >-.Ed > >-.Pp > >-Use ANSI function declarations unless you explicitly need K&R > >compatibility. > >+Use ANSI function declarations. > > Old-style function declarations: > Removed, because there is no need to use them anymore. The C99 standard > considers them obsolescent[1], too. All headers use prototype > declarations, there's no reason to handle the function definitions > different. Also they are a source of bugs - or did you know that the > following is wrong: > void wrong(char /* sic! */); > void wrong(x) char x; {} > And this is correct[2]: > void right(int /* sic! */); > void right(x) char x; {} > (It's a bug in GCC that it does not complain about the former.) > > > >- > >-static void > >-usage() > >-{ > >- /* Insert an empty line if the function has no local variables. */ > > Empty line when there are no local variables: > Removed, because it does not improve readability and it actually hinders > readability for very short functions, e.g. static inline functions, > which just consist of one or two lines of code without any local > variables except for parameters. Further, it makes even less sense with > the changed recommendations for declarations. > > > >+.Sh LOCAL VARIABLES > >+Unaliased local variables are for free on modern compilers. > >+They do not unconditionally use stack space. > >+In fact there is no relation between their number and the used stack > >space. > >+A local variable is guaranteed to be unaliased, if its address has not > >been > >+taken (e.g. &i). > >+Do not use the same local variable in different context just because it > >happens > >+that the same type is needed. > >+It does not improve the generated code in any way, but it makes it harder > >for a > >+reader to determine all definitions and uses which belong together. > >+Further, a new variable can be given a meaningful name (even if it is very > >+short), which automatically serves as documentation and so improves > >+comprehensibility. > >+Especially avoid re-using variables, whose address has been taken: > >+.Bd -literal > >+ int i; > >+ foo(&i); > >+ printf("%d\\n", i); > >+ for (i = 0; i != 10; ++i) { > >+ /* BAD: i will be needlessly moved to and from memory in > >+ * the loop, because its address was taken before. This > >+ * results in larger and slower code. > >+ * Declare a new variable for the loop instead. */ > >+ printf("%d\\n", i); > >+ } > >+.Ed > >+ > > 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. There is absolutely no need to reuse them in > different contexts. Trying to optimise stack usage in this way is > misguided and is a source of bugs, when a reused variable is not as dead > as thought. For more reasons, please read the quoted diff. > Maxim, you requested this paragraph: Does this addition suit you? > > > Hopefully at least some of these suggestions are considered improvements > and are applied to style(9). > > Regards > Christoph > > > [1] ISO/IEC 9899:1999 (E) ?6.11.6 and ?6.11.7 > [2] ISO/IEC 9899:1999 (E) ?6.7.5.3:15 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 14:10:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A2E106564A; Tue, 28 Apr 2009 14:10:37 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB328FC14; Tue, 28 Apr 2009 14:10:37 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 44DD814D537E; Tue, 28 Apr 2009 15:51:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k2TWYvqGbxcp; Tue, 28 Apr 2009 15:51:11 +0200 (CEST) Received: from webmail.kovesdan.org (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 8C83314D536F; Tue, 28 Apr 2009 15:51:11 +0200 (CEST) Received: from 152.66.70.33 (SquirrelMail authenticated user gabor) by webmail.kovesdan.org with HTTP; Tue, 28 Apr 2009 15:51:11 +0200 (CEST) Message-ID: <5b541e6fbf41b780b8eb99ac00b4d16c.squirrel@webmail.kovesdan.org> In-Reply-To: <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <66b068eb0904280510g7a1e50dfm455d96fd49c6eae@mail.gmail.com> Date: Tue, 28 Apr 2009 15:51:11 +0200 (CEST) From: =?iso-8859-2?Q?G=E1bor_K=F6vesd=E1n?= To: "Prashant Vaibhav" User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 28 Apr 2009 15:20:20 +0000 Cc: freebsd-hackers@freebsd.org, Gabor Kovesdan Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:10:38 -0000 >> >> My ex-girlfriend is working in Nepal [...] Even this country's encoding >> is >> supported. > > > Probably because Nepali language doesn't have a separate script, they use > Devanagari! :-) I know, what I wanted to say was that even Nepali is covered by the supported scripts. -- Gábor Kövesdán From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 14:10:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17721065672 for ; Tue, 28 Apr 2009 14:10:37 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2488FC16 for ; Tue, 28 Apr 2009 14:10:37 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 2E06914D537F for ; Tue, 28 Apr 2009 15:53:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tPtiMkHrv-hh for ; Tue, 28 Apr 2009 15:53:10 +0200 (CEST) Received: from webmail.kovesdan.org (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id DCFDC14D536F for ; Tue, 28 Apr 2009 15:53:09 +0200 (CEST) Received: from 152.66.70.33 (SquirrelMail authenticated user gabor) by webmail.kovesdan.org with HTTP; Tue, 28 Apr 2009 15:53:10 +0200 (CEST) Message-ID: <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> In-Reply-To: <20090428122225.GA2862@britannica.bec.de> References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <20090428122225.GA2862@britannica.bec.de> Date: Tue, 28 Apr 2009 15:53:10 +0200 (CEST) From: =?iso-8859-2?Q?G=E1bor_K=F6vesd=E1n?= To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 28 Apr 2009 15:29:34 +0000 Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:10:38 -0000 >> It's possible that there are little poor countries with an own writing >> system but probably their writing system is unsupported because the >> starvation, poorness and lack of water and electricity are more serious >> problems there. > > I wouldn't call all both parts of Korea little poor countries and it is > a wonderful example for why UCS 4 Level 1 can be problematic. > I didn't know about Korea. Then I insist even more on that Unicode should be extended to cover them instead of making implementation-specific solutions. -- Gábor Kövesdán From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 17:00:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72DF61065696 for ; Tue, 28 Apr 2009 17:00:27 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 52BC68FC24 for ; Tue, 28 Apr 2009 17:00:27 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n3SGoDo06329; Tue, 28 Apr 2009 09:50:13 -0700 (PDT) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n3SGoD718129; Tue, 28 Apr 2009 09:50:13 -0700 (PDT) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Tue, 28 Apr 2009 09:50:13 -0700 (PDT) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Peter Jeremy In-Reply-To: <20090428114754.GB89235@server.vk2pj.dyndns.org> Message-ID: References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers , Christoph Mallon Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:00:27 -0000 On Tue, 28 Apr 2009, Peter Jeremy wrote: > 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. However, if you take a look at http://gcc.gnu.org/gcc-4.2/c99status.html , you will see that it is very close. The vast majority of C99 features are implemented and working correctly. Even those which are marked as "broken" generally work in most cases, and fail only in rather obscure corner cases that real programs are unlikely to encounter. In particular, the features Christoph proposes to use work fine. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 18:06:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7766310656AB for ; Tue, 28 Apr 2009 18:06:25 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id C43698FC16 for ; Tue, 28 Apr 2009 18:06:24 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 2928A6670C for ; Tue, 28 Apr 2009 20:06:17 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id A5F8F1BDD7C; Tue, 28 Apr 2009 20:06:24 +0200 (CEST) Date: Tue, 28 Apr 2009 20:06:24 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20090428180624.GA2223@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> <20090428122225.GA2862@britannica.bec.de> <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24e9a86bf5995ba551db8f27aa204191.squirrel@webmail.kovesdan.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:06:26 -0000 On Tue, Apr 28, 2009 at 03:53:10PM +0200, G?bor K?vesd?n wrote: > >> It's possible that there are little poor countries with an own writing > >> system but probably their writing system is unsupported because the > >> starvation, poorness and lack of water and electricity are more serious > >> problems there. > > > > I wouldn't call all both parts of Korea little poor countries and it is > > a wonderful example for why UCS 4 Level 1 can be problematic. > > > > > I didn't know about Korea. Then I insist even more on that Unicode should > be extended to cover them instead of making implementation-specific > solutions. Unicode covers Korean. It just violates the "one logic character equals one UCS-4 character" or however you want to put. More trivial example can be obtained when looking at both your and my name. Diacrets have historically been part of the character, but it is possible to use combining characters in unicode for the cleaner description. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 20:32:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04C9C106566C for ; Tue, 28 Apr 2009 20:32:13 +0000 (UTC) (envelope-from julidaoc@online.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 727248FC14 for ; Tue, 28 Apr 2009 20:32:12 +0000 (UTC) (envelope-from julidaoc@online.de) Received: from server2go (p54A12E3D.dip0.t-ipconnect.de [84.161.46.61]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MKv5w-1LytmB02aT-0001mT; Tue, 28 Apr 2009 22:19:35 +0200 Date: Tue, 28 Apr 2009 22:19:34 +0200 To: freebsd-hackers@freebsd.org From: "Julian Bangert" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (Linux) X-Provags-ID: V01U2FsdGVkX18wWrayBFLchXyr2saVeql9GzBDgWVe2tx4843 H/Wzdv51n0O/lVGgC5gaKgJ+dXtcZJmFvFgWBVXOT2e/I46o8Z uyRrnhCunTibY14z+WyrpInbzL2xaon X-Mailman-Approved-At: Tue, 28 Apr 2009 20:47:06 +0000 Subject: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:32:13 -0000 Hello, I am currently trying to work a bit on the remaining "missing feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. For now, I am trying to extend the current system call and implementation to add cache control ( the type of memory caching used) . This feature inherently is very architecture specific- but it can lead to enormous performance improvements for memmapped devices ( useful for drivers, etc). I would do this at the user site by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to the various caching options ( like Uncacheable,Write Combining, etc... ) with the same numbers as the PAT_* macros from i386/include/specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is assigned the meaning "feature not used, use default cache control". For each cache behaviour there would of course also be a macro expanding to the rigth combination of these flags for enhanced useability. The mmap system call would, if any of these flags are set, decode them and get a corresponding PAT_* value, perform the mapping and then call into the pmap module to modify the cache attributes for every page. My first question is if there is a more elegant way of solving that - the 3 flags would be architecture specific ( they could be used for other things on other architectures though if need be ) and I do not know the policy on architecture specific syscall flags, therefore I appreciate any input. The second question goes to all those great VM/pmap gurus out there: As far as I understand, at the moment the pmap_change_attr can only cange the cache flags for kernel pages. Is there a particular reason why this function might not be adapted/extended to userspace mappings? If not, I would either add a new function to iterate over all pages and set cache flags for a particular region or add a new member (possibly just add the 3 flags again ? ) to the md part of vm_page_t. Or one could just keep track and return errors as soon as someone tries to map a memory region ( cache-customized mapping is usually done to device memory ) already mapped with different cache behaviour. I thank you for your assistance & happy coding, --Julian Bangert From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 21:43:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60442106566B for ; Tue, 28 Apr 2009 21:43:19 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 274688FC08 for ; Tue, 28 Apr 2009 21:43:18 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by gxk24 with SMTP id 24so598464gxk.19 for ; Tue, 28 Apr 2009 14:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.133.5 with SMTP id k5mr11741206ybn.199.1240953795119; Tue, 28 Apr 2009 14:23:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Apr 2009 23:23:15 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Julian Bangert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 21:43:19 -0000 On Tue, Apr 28, 2009 at 22:19, Julian Bangert wrote: > Hello, > > I am currently trying to work a bit on the remaining "missing feature" th= at > NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests =A0or a b= ack > post in this ML) - =A0the improved mmap system call. > =A0For now, I am trying to extend the current system call and implementat= ion > to add cache control ( the type of memory caching used) . This feature > inherently is very architecture specific- but it can lead to enormous > performance improvements for memmapped devices ( useful for drivers, etc)= . I > would do this at the user site by adding 3 flags to the mmap system call > (MEM_CACHE__ATTR1 to MEM_CACHE__ATTR3 ) which are a single octal digit > corresponding to the various caching options ( like Uncacheable,Write > Combining, etc... ) with the same numbers as the PAT_* macros from > i386/include/specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is > replaced with value 2 ( undefined), whereas value 0 ( all 3 flags cleared= ) > is assigned the meaning "feature not used, use default cache control". > For each cache behaviour there would of course also be a macro expanding = to > the rigth combination of these flags for enhanced useability. Hmm, I don't like that. What about using something like PAT_WC directly for the userland? Afaik a userland app that uses stuff like this is md anyway. > =A0The mmap system call would, if any of these flags are set, decode them= and > get a corresponding PAT_* value, perform the mapping and then call into t= he > pmap module to modify the cache attributes for every page. > > =A0My first question is if there is a more elegant way of solving that - = the 3 > flags would be architecture specific ( they could be used for other thing= s > on other architectures though if need be ) and I do not know the policy o= n > architecture specific syscall flags, therefore I appreciate any input. > > The second question goes to all those great VM/pmap gurus out there: As f= ar > as I understand, at the moment the pmap_change_attr can only cange the ca= che > flags for kernel pages. Is there a particular reason why this function mi= ght > not be adapted/extended to userspace mappings? If not, I would either add= a > new function to iterate over all pages and set cache flags for a particul= ar > region or add a new member (possibly just add the 3 flags again ? ) to th= e > md part of vm_page_t. Or one could just keep track and return errors as s= oon > as someone tries to map a memory region ( cache-customized mapping is > usually done to device memory ) already mapped with =A0different cache > behaviour. Do you know how other OS handle this stuff? Maybe there is some inspiration there for a clean interface. I'm not sure if I remember correctly but there is something in my mind that we must take care that no virtual pages have different PAT settings for the same physical page. Maybe I read something like this in the AMD's documentation of PAT. Sorry I don't remember exactly but perhaps someone else can explain it better. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 22:25:55 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F363106564A for ; Tue, 28 Apr 2009 22:25:55 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id E1C8B8FC17 for ; Tue, 28 Apr 2009 22:25:54 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n3SMQTYL017936; Tue, 28 Apr 2009 18:26:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n3SMQT8i017935; Tue, 28 Apr 2009 18:26:29 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 28 Apr 2009 18:26:29 -0400 From: David Schultz To: Gabor Kovesdan Message-ID: <20090428222629.GA17881@zim.MIT.EDU> Mail-Followup-To: Gabor Kovesdan , freebsd-hackers@FreeBSD.ORG References: <20090427183836.GA10793@zim.MIT.EDU> <49F5FE45.2090101@freebsd.org> <20090427193326.GA7654@britannica.bec.de> <20090427194904.GA11137@zim.MIT.EDU> <49F6C7A1.6070708@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F6C7A1.6070708@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SoC 2009: BSD-licensed libiconv in base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:25:55 -0000 On Tue, Apr 28, 2009, Gabor Kovesdan wrote: > Another idea to consider. Are all of our utilities wchar-clean? What > about library functions? (regex is surely not) Do we lack any important > utility or library? (we still do lack iconv and gettext and what > else...?) What about standards, like C99 wchar functions? Is there > something missing? What about POSIX if it has something related? > Personally, I think that these are more important questions than support > of some extremely rare languages. It's worth to consider how to deal > with them later but the basic problems need a higher priority. There's a fair number of utilities that are not locale-aware, and we don't have any of the *_l() functions in POSIX.1-2008. There are also some second-order issues in libraries, e.g., they assume multibyte encodings don't contain embedded low ASCII characters, or they are far less efficient than they could be. > I hope my work will be useful for the community. Btw, I suspected that > you might be interested in this and I wrote a mail personally to you > when I was looking for a mentor. Then I didn't resend it because > delphij@ volunteered to be my mentor. Have you ever got that mail? If > you find this an interesting project your comments, review, etc. are > still highly welcome. I did reply on 3/19, basically to say that I'd be happy to offer advice, but it's not really my area. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 22:06:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DE31065676 for ; Tue, 28 Apr 2009 22:06:08 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 51C9C8FC15 for ; Tue, 28 Apr 2009 22:06:08 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (localhost.your.org [127.0.0.1]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 298FF2AD55A5; Tue, 28 Apr 2009 21:48:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=dragondata.com; h=cc :message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; s=selector1; bh=+tGGjWNsBnraHZiNnl1w8KoGBXI=; b=fuWm2WN6uNwhdW+ b2MEn0Qtg/k0If5fHgwbWoQIvgNWrgVy70EBz3tU3JqVkWwRbPvz0hkq6V91Wm/M X2TL3M1Y0gocceBAKcb0T2FsanjzolPW/PuVKenBCviRhhIYjuZq3oa3N6ePSBFe kop7cuuOYDwwW79GAOPtFzWHg1IY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dragondata.com; h=cc:message-id :from:to:in-reply-to:content-type:content-transfer-encoding :mime-version:subject:date:references; q=dns; s=selector1; b=c8x NasUhGRVSVDxtb//wcL2z6FqAZhc/MawfQvGnGv7tB1fVN/rj9epAgVMD6bKCJLe M+ewJ5mH3rsgosqLVkcJCBRM2ijlXtW5uwoXNCke24UFyknt2K9quosHZwFmvXA6 SRI4eo+d5gHpOhjEmAEaJ7bkGOTT4uhJXTFtp2R4= Received: from mail.your.org (server2-a.your.org [216.14.97.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by tokyo01.jp.mail.your.org (Postfix) with ESMTPS id E481C2AD555A; Tue, 28 Apr 2009 21:48:37 +0000 (UTC) Received: from [216.14.99.244] (unknown [216.14.99.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 0A4282C9011; Tue, 28 Apr 2009 21:48:35 +0000 (UTC) Message-Id: From: Kevin Day To: "Julian Bangert" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 16:48:35 -0500 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 28 Apr 2009 22:29:42 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:06:09 -0000 On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > Hello, > > I am currently trying to work a bit on the remaining "missing > feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > or a back post in this ML) - the improved mmap system call. > For now, I am trying to extend the current system call and > implementation to add cache control ( the type of memory caching > used) . This feature inherently is very architecture specific- but > it can lead to enormous performance improvements for memmapped > devices ( useful for drivers, etc). I would do this at the user site > by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to > MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to > the various caching options ( like Uncacheable,Write Combining, > etc... ) with the same numbers as the PAT_* macros from i386/include/ > specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced > with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is > assigned the meaning "feature not used, use default cache control". > For each cache behaviour there would of course also be a macro > expanding to the rigth combination of these flags for enhanced > useability. > > The mmap system call would, if any of these flags are set, decode > them and get a corresponding PAT_* value, perform the mapping and > then call into the pmap module to modify the cache attributes for > every page. Have you looked at mem(4) yet? Several architectures allow attributes to be associated with ranges of physical memory. These attributes can be manipulated via ioctl() calls performed on /dev/mem. Declarations and data types are to be found in . The specific attributes, and number of programmable ranges may vary between architectures. The full set of supported attributes is: MDF_UNCACHEABLE The region is not cached. MDF_WRITECOMBINE Writes to the region may be combined or performed out of order. MDF_WRITETHROUGH Writes to the region are committed synchronously. MDF_WRITEBACK Writes to the region are committed asynchronously. MDF_WRITEPROTECT The region cannot be written to. This requires knowledge of the physical addresses, but I believe that's probably already necessary for what it sounds like you're trying to accomplish. Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP graphics controller, and setting the MTRR flags for the exposed buffer was a definite improvement (200-1200% faster in most cases). -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 23:45:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A76106564A for ; Tue, 28 Apr 2009 23:45:43 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE7C8FC2A for ; Tue, 28 Apr 2009 23:45:43 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.151] (adsl-157-58-93.bna.bellsouth.net [70.157.58.93]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3SNjZ5x019488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 19:45:36 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Kevin Day In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-loYsyV1uDDXXiRqy5MNO" Organization: FreeBSD Date: Tue, 28 Apr 2009 18:45:28 -0500 Message-Id: <1240962328.2021.10.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org, Julian Bangert Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:45:43 -0000 --=-loYsyV1uDDXXiRqy5MNO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: >=20 > > Hello, > > > > I am currently trying to work a bit on the remaining "missing =20 > > feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRe= quests=20 > > or a back post in this ML) - the improved mmap system call. > > For now, I am trying to extend the current system call and =20 > > implementation to add cache control ( the type of memory caching =20 > > used) . This feature inherently is very architecture specific- but =20 > > it can lead to enormous performance improvements for memmapped =20 > > devices ( useful for drivers, etc). I would do this at the user site =20 > > by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to =20 > > MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to =20 > > the various caching options ( like Uncacheable,Write Combining, =20 > > etc... ) with the same numbers as the PAT_* macros from i386/include/=20 > > specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced =20 > > with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is =20 > > assigned the meaning "feature not used, use default cache control". > > For each cache behaviour there would of course also be a macro =20 > > expanding to the rigth combination of these flags for enhanced =20 > > useability. > > > > The mmap system call would, if any of these flags are set, decode =20 > > them and get a corresponding PAT_* value, perform the mapping and =20 > > then call into the pmap module to modify the cache attributes for =20 > > every page. >=20 > Have you looked at mem(4) yet? >=20 > Several architectures allow attributes to be associated with =20 > ranges of > physical memory. These attributes can be manipulated via =20 > ioctl() calls > performed on /dev/mem. Declarations and data types are to be =20 > found in > . >=20 > The specific attributes, and number of programmable ranges may =20 > vary > between architectures. The full set of supported attributes is: >=20 > MDF_UNCACHEABLE > The region is not cached. >=20 > MDF_WRITECOMBINE > Writes to the region may be combined or performed out of =20 > order. >=20 > MDF_WRITETHROUGH > Writes to the region are committed synchronously. >=20 > MDF_WRITEBACK > Writes to the region are committed asynchronously. >=20 > MDF_WRITEPROTECT > The region cannot be written to. >=20 > This requires knowledge of the physical addresses, but I believe =20 > that's probably already necessary for what it sounds like you're =20 > trying to accomplish. >=20 > Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP =20 > graphics controller, and setting the MTRR flags for the exposed buffer =20 > was a definite improvement (200-1200% faster in most cases). This is MTRR, which is what we currently do, when we can. The issue is that often times the BIOS maps ranges in a way that prevents us from using MTRR. This is generally ideal for things like agp and framebuffers when it works, since they have a specific physical range that you want to work with. With PCI(E) cards it isn't as cut and dry... In the ATI and Nouveau cases, we map scatter gather pages into the GART, which generally are allocated using contigmalloc behind the scenes, so it is also possible for it to work in that case. Moving forward, we may actually be mapping random pages into and out of the GART (GEM / TTM). In those cases we really don't have a large contiguous range that we could set MTRR on. Intel CPUs are limited to 8 MTRR registers for the entire system also, so that can become an issue quickly if you are trying to manipulate several areas of memory. With PAT we can manipulate the caching properties on a page level. PAT also allows for some overlap conditions that MTRR won't, such as mapping a page write-combining on top on an UNCACHEABLE MTRR. jhb@ has started some work on this, since I've been badgering him about this recently as well. robert. > -- Kevin >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-loYsyV1uDDXXiRqy5MNO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn3lRgACgkQM4TrQ4qfRONACACfSQWc0NK+JjhV2TO2R7eCSr3h v+UAnRMS4ndJlbT5z1l7olgY7v261wsb =aFxH -----END PGP SIGNATURE----- --=-loYsyV1uDDXXiRqy5MNO-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 23:58:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCD69106566B for ; Tue, 28 Apr 2009 23:58:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB698FC21 for ; Tue, 28 Apr 2009 23:58:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 899D514DFB3; Tue, 28 Apr 2009 16:58:51 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BE74D2D61EC; Tue, 28 Apr 2009 16:58:49 -0700 (PDT) Message-ID: <49F79841.9030702@elischer.org> Date: Tue, 28 Apr 2009 16:58:57 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Noland References: <1240962328.2021.10.camel@wombat.2hip.net> In-Reply-To: <1240962328.2021.10.camel@wombat.2hip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Julian Bangert , Kevin Day Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:58:51 -0000 Robert Noland wrote: > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: >> >>> Hello, >>> >>> I am currently trying to work a bit on the remaining "missing >>> feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests >>> or a back post in this ML) - the improved mmap system call. you might check with jhb (john Baldwin) as I think (from his p4 work) that he may be doing something in this area in p4. >>> For now, I am trying to extend the current system call and >>> implementation to add cache control ( the type of memory caching >>> used) . This feature inherently is very architecture specific- but >>> it can lead to enormous performance improvements for memmapped >>> devices ( useful for drivers, etc). I would do this at the user site >>> by adding 3 flags to the mmap system call (MEM_CACHE__ATTR1 to >>> MEM_CACHE__ATTR3 ) which are a single octal digit corresponding to >>> the various caching options ( like Uncacheable,Write Combining, >>> etc... ) with the same numbers as the PAT_* macros from i386/include/ >>> specialreg.h except that the value 0 ( PAT_UNCACHEABLE ) is replaced >>> with value 2 ( undefined), whereas value 0 ( all 3 flags cleared) is >>> assigned the meaning "feature not used, use default cache control". >>> For each cache behaviour there would of course also be a macro >>> expanding to the rigth combination of these flags for enhanced >>> useability. >>> >>> The mmap system call would, if any of these flags are set, decode >>> them and get a corresponding PAT_* value, perform the mapping and >>> then call into the pmap module to modify the cache attributes for >>> every page. >> Have you looked at mem(4) yet? >> >> Several architectures allow attributes to be associated with >> ranges of >> physical memory. These attributes can be manipulated via >> ioctl() calls >> performed on /dev/mem. Declarations and data types are to be >> found in >> . >> >> The specific attributes, and number of programmable ranges may >> vary >> between architectures. The full set of supported attributes is: >> >> MDF_UNCACHEABLE >> The region is not cached. >> >> MDF_WRITECOMBINE >> Writes to the region may be combined or performed out of >> order. >> >> MDF_WRITETHROUGH >> Writes to the region are committed synchronously. >> >> MDF_WRITEBACK >> Writes to the region are committed asynchronously. >> >> MDF_WRITEPROTECT >> The region cannot be written to. >> >> This requires knowledge of the physical addresses, but I believe >> that's probably already necessary for what it sounds like you're >> trying to accomplish. >> >> Back in the FreeBSD-3.0 days, I was writing a custom driver for an AGP >> graphics controller, and setting the MTRR flags for the exposed buffer >> was a definite improvement (200-1200% faster in most cases). > > This is MTRR, which is what we currently do, when we can. The issue is > that often times the BIOS maps ranges in a way that prevents us from > using MTRR. This is generally ideal for things like agp and > framebuffers when it works, since they have a specific physical range > that you want to work with. > > With PCI(E) cards it isn't as cut and dry... In the ATI and Nouveau > cases, we map scatter gather pages into the GART, which generally are > allocated using contigmalloc behind the scenes, so it is also possible > for it to work in that case. Moving forward, we may actually be mapping > random pages into and out of the GART (GEM / TTM). In those cases we > really don't have a large contiguous range that we could set MTRR on. > Intel CPUs are limited to 8 MTRR registers for the entire system also, > so that can become an issue quickly if you are trying to manipulate > several areas of memory. With PAT we can manipulate the caching > properties on a page level. PAT also allows for some overlap conditions > that MTRR won't, such as mapping a page write-combining on top on an > UNCACHEABLE MTRR. > > jhb@ has started some work on this, since I've been badgering him about > this recently as well. > > robert. > >> -- Kevin >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 29 18:22:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098E310656B1 for ; Wed, 29 Apr 2009 18:22:47 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 821768FC14 for ; Wed, 29 Apr 2009 18:22:46 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by bwz9 with SMTP id 9so1326932bwz.43 for ; Wed, 29 Apr 2009 11:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=URl135aMvQi1eiOoo5yziCru/oRtbDGmZssZwOLHvy8=; b=almhM9Pr+uf5phHLc7nRTDAnUDyVdrBr+rCeX60yoSepIUYT0tjZNN06fK6UfpAdsw riLLKx9Erq5gULdUHSU0stlOEdNq1wgIZime8wOvuKl2bO66wJjgV8aKhRz2woOt+XeB hsdy+8MTNKxauaBrtHnzVoiM00tMP6iA3pGag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Yhq9vXDI5BCWL3ETFVLU9tSZoexT03BmsWDUd4l/G2lLJaWD5NVxhkL2Z5xTzbitcx kVEzz53YNv/l0fNRpKic4kVZwRL+QD05pkGuesibfnMlEWmrgRXZfdXX48vgXNM56XrP nrkAHT8SHACXFCS7PdctL+yOlmyaUiG3Xp5lg= Received: by 10.103.117.9 with SMTP id u9mr415480mum.55.1241029365368; Wed, 29 Apr 2009 11:22:45 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id j2sm3283395mue.41.2009.04.29.11.22.44 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 11:22:44 -0700 (PDT) Message-ID: <49F89B6E.7030303@gmail.com> Date: Wed, 29 Apr 2009 20:24:46 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <49F4070C.2000108@gmx.de> In-Reply-To: <49F4070C.2000108@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:22:47 -0000 Christoph Mallon wrote: >> -When declaring variables in functions declare them sorted by size, >> -then in alphabetical order; multiple ones per line are okay. >> +When declaring variables in functions declare them sorted in >> alphabetical order; What's wrong with logical grouping, especially when the new localized declaration style is used (so tons of variables are not declared at a time anymore)? From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 29 19:22:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A57106566B for ; Wed, 29 Apr 2009 19:22:59 +0000 (UTC) (envelope-from john.gemignani@isilon.com) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 16FAC8FC1C for ; Wed, 29 Apr 2009 19:22:58 +0000 (UTC) (envelope-from john.gemignani@isilon.com) Received: from 10.10.2.114 ([10.10.2.114]) by seaxch10.desktop.isilon.com ([10.10.2.97]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Apr 2009 19:10:58 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: Date: Wed, 29 Apr 2009 12:10:44 -0700 Message-ID: <108501c9c8fe$3a30ab0e$72020a0a@desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: C99: Suggestions for style(9) thread-index: AcnI/jowNoVO9nN4RrCJmY4mxXoXtA== From: "John Gemignani" To: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:22:59 -0000 QmVjYXVzZSB0aGUgbG9naWNhbCBncm91cGluZyBtYWtlcyB0aGUgbW9zdCBzZW5zZSB0byB0aGUg YXV0aG9yIG9mIHRoZSBjb2RlLCBub3QgdGhlIHBlcnNvbiB3aG8gaGFzIHRvIGxlYXJuIG9yIG1h aW50YWluIGl0Lg0KDQpBcmUgbG9jYWwgdmFyaWFibGVzIGFsbG9jYXRlZCBvbi10aGUtZmx5IG9u IHRoZSBzdGFjayBvciBkb2VzIHRoZSBjb21waWxlciBwcmVhbGxvY2F0ZSB0aGUgc3BhY2Ugb24g ZW50cnk/IElmIEkgaGF2ZSB0byBkZWx2ZSBpbnRvIGEgY3Jhc2hkdW1wLCBoYXZpbmcgdGhlIHZh cmlhYmxlcyBvbiB0aGUgYmlnIGVudHJ5IGFsbG9jYXRpb24gaGFzIGJlZW4gdmVyeSBoZWxwZnVs IGluIHRoZSBwYXN0Lg0KDQpKb2huDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBkZWVwdGVjaDcxQGdtYWlsLmNvbSA8ZGVlcHRlY2g3MUBnbWFpbC5jb20+DQpTZW50OiBXZWRu ZXNkYXksIEFwcmlsIDI5LCAyMDA5IDExOjIzIEFNDQpUbzogZnJlZWJzZC1oYWNrZXJzQGZyZWVi c2Qub3JnIDxmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTogQzk5OiBT dWdnZXN0aW9ucyBmb3Igc3R5bGUoOSkNCg0KQ2hyaXN0b3BoIE1hbGxvbiB3cm90ZToNCj4+IC1X aGVuIGRlY2xhcmluZyB2YXJpYWJsZXMgaW4gZnVuY3Rpb25zIGRlY2xhcmUgdGhlbSBzb3J0ZWQg Ynkgc2l6ZSwNCj4+IC10aGVuIGluIGFscGhhYmV0aWNhbCBvcmRlcjsgbXVsdGlwbGUgb25lcyBw ZXIgbGluZSBhcmUgb2theS4NCj4+ICtXaGVuIGRlY2xhcmluZyB2YXJpYWJsZXMgaW4gZnVuY3Rp b25zIGRlY2xhcmUgdGhlbSBzb3J0ZWQgaW4gDQo+PiBhbHBoYWJldGljYWwgb3JkZXI7DQoNCldo YXQncyB3cm9uZyB3aXRoIGxvZ2ljYWwgZ3JvdXBpbmcsIGVzcGVjaWFsbHkgd2hlbiB0aGUgbmV3 IGxvY2FsaXplZCANCmRlY2xhcmF0aW9uIHN0eWxlIGlzIHVzZWQgKHNvIHRvbnMgb2YgdmFyaWFi bGVzIGFyZSBub3QgZGVjbGFyZWQgYXQgYSANCnRpbWUgYW55bW9yZSk/DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmcmVlYnNkLWhhY2tlcnNAZnJl ZWJzZC5vcmcgbWFpbGluZyBsaXN0DQpodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9mcmVlYnNkLWhhY2tlcnMNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRv ICJmcmVlYnNkLWhhY2tlcnMtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 11:45:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA91106566C for ; Thu, 30 Apr 2009 11:45:13 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 291AF8FC17 for ; Thu, 30 Apr 2009 11:45:12 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by qyk3 with SMTP id 3so3593069qyk.3 for ; Thu, 30 Apr 2009 04:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qtiO4YlLWGzt4J4lDzQPWusfeqi7V29vNbW5xh/+NW8=; b=GHlaqgMQ0dGv/Jw3sBlsCK3nsDDl/ytrSXNptyHysMSyDVeGaV+lsv4CUACzNGn0DU u9/kN8Yt/aRDtaC46KH3QaEAHBrywb3f1CqQO5l/36bmn5uDIO/E+tbHoDlhmj8ih3VH Xla7HbY633trQG8BCivnSADLqDrsj352sJs78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hKYmpmZmtdr4gagmC9kJvajdFQLKOqIP6A7BxL7VmtEY4pIexoOrqS3RkCNpO79yNG oRblzzHVbNLDxJz5Dt+VYw/liBR7shDPRgX0zxr3v730qc/MspJn5vu3TYdQ4lO7i7+1 VMjAnYtF8BYXf0KZaKF3Iu2MWC9Bb/qge47+w= MIME-Version: 1.0 Received: by 10.224.20.80 with SMTP id e16mr1644167qab.163.1241091912313; Thu, 30 Apr 2009 04:45:12 -0700 (PDT) Date: Thu, 30 Apr 2009 13:45:12 +0200 Message-ID: <671bb5fc0904300445n73edcf95pf2139250fc8ff68d@mail.gmail.com> From: Alexej Sokolov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: killing process from interrupt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:45:13 -0000 Hello, I have in my interrupt function the pointer to structure of some process. What is the safe way to kill the process? psignal (p, 9); ? Thanx Alexej From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 15:07:13 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30483106566B for ; Thu, 30 Apr 2009 15:07:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D17898FC0A for ; Thu, 30 Apr 2009 15:07:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n3UF2ORH017382; Thu, 30 Apr 2009 09:02:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 30 Apr 2009 09:02:26 -0600 (MDT) Message-Id: <20090430.090226.1569754707.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20090428114754.GB89235@server.vk2pj.dyndns.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, christoph.mallon@gmx.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:07:13 -0000 In message: <20090428114754.GB89235@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. : [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 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 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. : [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. : [ 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. : >> +.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. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 15:17:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E38E9106566B for ; Thu, 30 Apr 2009 15:17:56 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 720298FC17 for ; Thu, 30 Apr 2009 15:17:56 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by bwz9 with SMTP id 9so1850994bwz.43 for ; Thu, 30 Apr 2009 08:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=P9bVHZYyfWyHMUyPTxjYN045QwRWdTl+WSUeZ7lY1g4=; b=dfFk3vDKWBDlIPWYdGi5K/jZBBPhaBCwNByNVXn7UGPn1OQhzHAX/bQHXV2hWs9qWJ OUWoQVel2QXo9rbzN7fo/YMBTtaIIwbZ6ArWghIfGy3VsDLO9Iowx8pM4SA6nUoZpvwI mBD6MtvcNBEIdhFM3NezyXKBTjqPGi9YixoAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=x3QMFkjJEvMM1d6J97p3M0nxGv9xOLJgeQXXUog4/2aggeUlAAzmGLJeJqq0KkoADm CcSrWHv7bgqOE5BT3sT/mhJ0p+a1IQmgjp0GcUI5EwB5qHW/q6y+xIDVPxI+1ur30lbm N83qNGWAxamdCV9jf3qYnISlgU4T/ZDSixmqA= MIME-Version: 1.0 Received: by 10.103.24.17 with SMTP id b17mr1028331muj.21.1241103032099; Thu, 30 Apr 2009 07:50:32 -0700 (PDT) Date: Thu, 30 Apr 2009 16:50:32 +0200 Message-ID: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> From: Oliver Pinter To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: NetBSD 5.0 statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:17:57 -0000 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? http://www.netbsd.org/~ad/50/img0.html From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 18:33:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82D631065676 for ; Thu, 30 Apr 2009 18:33:39 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 38CDD8FC0A for ; Thu, 30 Apr 2009 18:33:38 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1212174ywe.13 for ; Thu, 30 Apr 2009 11:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=poHQBsG56VeLAqlNVIctBfT/FUQHNwGI4lTa2UYQYNA=; b=AByrOlih9lqHNyUsyfr/6Q6jWt2RP5UKLebsbpDBM8e1Bx4bNvGmLpZOQzZCaXan+i xic/DIENpZbs7ys//BIYYrrG5irnHdavz6nflvP6YlkcXocpAe7cLs0MqYUtOKc+FxWS D1Dwlfzxc8dvkwZoL8ezEPNJjgTx9+nBHI1F8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Dg0NYNwxC8sWuURB5q2PGb7FES7veW48lVsbqlRWbwLCaSEQwCRNmBdakaJv8/Xj/5 PZgdAVjuVXVLR3VHKXeUlQC3WZgP+uGXiMtgXthT7YAw77vuiHMSrj9rA8vhsE9wSjD8 Z7vc23djlk9XMC409RVY2wCr1WRJ9CpVTzJdU= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.44.4 with SMTP id r4mr3658153anr.157.1241116418461; Thu, 30 Apr 2009 11:33:38 -0700 (PDT) In-Reply-To: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Date: Thu, 30 Apr 2009 11:33:38 -0700 X-Google-Sender-Auth: 0c5758de672e728c Message-ID: <3c1674c90904301133w702d98feh88457677388a0a61@mail.gmail.com> From: Kip Macy To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: NetBSD 5.0 statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:33:39 -0000 On Thu, Apr 30, 2009 at 7:50 AM, 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? > > > http://www.netbsd.org/~ad/50/img0.html We would need more information about the disk hardware, amount of memory etc. to really provide an answer. We've had a lot of difficulties testing against NetBSD in the past because NetBSD wouldn't boot on recent hardware (ACPI issues IIRC). Looking at the processor he is using it would appear that that has probably been fixed. -Kip From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 19:32:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F39F106566B for ; Thu, 30 Apr 2009 19:32:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 29B478FC14 for ; Thu, 30 Apr 2009 19:32:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C1EFF46B0C; Thu, 30 Apr 2009 15:32:00 -0400 (EDT) Date: Thu, 30 Apr 2009 20:32:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oliver Pinter In-Reply-To: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> Message-ID: References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: NetBSD 5.0 statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 19:32:02 -0000 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. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 21:41:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD82106567E; Thu, 30 Apr 2009 21:41:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 902F38FC22; Thu, 30 Apr 2009 21:41:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4507146B09; Thu, 30 Apr 2009 17:41:23 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 294918A023; Thu, 30 Apr 2009 17:41:22 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 30 Apr 2009 08:46:41 -0400 User-Agent: KMail/1.9.7 References: <200904270150.31912.pieter@degoeje.nl> <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> In-Reply-To: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904300846.41576.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 30 Apr 2009 17:41:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: acpi , Garrett Cooper , freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org, Pieter de Goeje Subject: Re: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:41:24 -0000 On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: > I'm seeing similar results. > > [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "' > Timecounter "i8254" frequency 1193182 Hz quality 0 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > Timecounter "HPET" frequency 14318180 Hz quality 900 > [root@orangebox /usr/home/gcooper]# ./cgt > 1369355 > [root@orangebox /usr/home/gcooper]# sysctl > kern.timecounter.hardware="ACPI-fast" > kern.timecounter.hardware: HPET -> ACPI-fast > [root@orangebox /usr/home/gcooper]# ./cgt > 772289 > > Why's the default ACPI-fast? For power-saving functionality or because > of the `quality' factor? What is the criteria that determines the > `quality' of a clock as what's being reported above (I know what > determines the quality of a clock visually from a oscilloscope =])? I suspect that the quality of the HPET driver is lower simply because no one had measured it previously and HPET is newer and less "proven". -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 21:41:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04368106575A; Thu, 30 Apr 2009 21:41:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AD8428FC17; Thu, 30 Apr 2009 21:41:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 403EB46B7F; Thu, 30 Apr 2009 17:41:31 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 04C2C8A023; Thu, 30 Apr 2009 17:41:30 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 30 Apr 2009 17:36:51 -0400 User-Agent: KMail/1.9.7 References: <1240962328.2021.10.camel@wombat.2hip.net> <49F79841.9030702@elischer.org> In-Reply-To: <49F79841.9030702@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904301736.52325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 30 Apr 2009 17:41:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.2 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Julian Bangert , Julian Elischer , Robert Noland , Kevin Day Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:41:32 -0000 On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: > Robert Noland wrote: > > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > >> > >>> Hello, > >>> > >>> I am currently trying to work a bit on the remaining "missing > >>> feature" that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests > >>> or a back post in this ML) - the improved mmap system call. > > > you might check with jhb (john Baldwin) as I think (from his > p4 work) that he may be doing something in this area in p4. After some promptings from Robert and his needs for Xorg recently I did start hacking on this again. However, I haven't tested it yet. What I have done so far is in //depot/user/jhb/pat/... and it does the following: 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've only done the MD portions of this work for amd64 so far). Every arch must at least define a value for VM_CACHE_DEFAULT. 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then passed down to a few pmap functions: pmap_object_init_pt(), pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as vm_map_insert() and vm_map_find() now take a cache mode to use when adding a new mapping. 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the object is used. 4) A new VM object type: OBJT_SG. This object type has its own pager that is sort of like the device pager. However, instead of invoking d_mmap() to determine the physaddr for a given page, it consults a pre-created scatter/gather list (an ADT from my branch for working on unmapped buffer I/O) to determine the backing physical address for a given virtual address. 5) A new callback for device mmap: d_mmap_single(). One of the features of this is that it can return a vm_object_t to be used to satisfy the mmap() request instead of using the device's device pager VM object. 6) A new mcache() system call similar to mprotect(), except that it changes the cache mode of an address range rather than the protection. This may not be all that useful really. Given all this, a driver could do the following to map a "thing" as WC in both userland and the kernel: 1) When it learns about a "thing" it creates a SG list to describe it. If the "thing" consists of userland pages, it has to wire the pages first. The driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets the object's cache mode to VM_CACHE_WC (if the arch supports that). 2) When userland wants to map the "thing" it does a device mmap() with a proper length and a file offset that is a cookie for the "thing". The device driver's d_mmap_single() recognizes the magic file offset and returns the "thing"'s VM object. Since the mapping info is now part of a normal object mapping, it will go away via munmap(), etc. The driver no longer has to do weird gymnastics to invalidate mappings from its device pager as "transient" mappings are no longer stored in the device pager. 3) When the driver wants to map the "thing" into the kernel, it can use vm_map_find() to insert the "thing"'s VM object into kernel map. And I think that is all there is to it. I need to test this somehow to make sure though, and make sure this meets the needs of Robert and Nvidia. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 21:52:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD299106566C; Thu, 30 Apr 2009 21:52:22 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AEF468FC14; Thu, 30 Apr 2009 21:52:22 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-156-5-217.bna.bellsouth.net [70.156.5.217]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3ULqEIo033810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 17:52:14 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: John Baldwin In-Reply-To: <200904301736.52325.jhb@freebsd.org> References: <1240962328.2021.10.camel@wombat.2hip.net> <49F79841.9030702@elischer.org> <200904301736.52325.jhb@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ZFJl4dhNjBf/ZVMBvz0B" Organization: FreeBSD Date: Thu, 30 Apr 2009 16:52:05 -0500 Message-Id: <1241128325.1848.0.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org, Julian Bangert , Julian Elischer , Kevin Day Subject: Re: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:52:23 -0000 --=-ZFJl4dhNjBf/ZVMBvz0B Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-04-30 at 17:36 -0400, John Baldwin wrote: > On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: > > Robert Noland wrote: > > > On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: > > >> On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: > > >> > > >>> Hello, > > >>> > > >>> I am currently trying to work a bit on the remaining "missing =20 > > >>> feature" that NVIDIA requires (=20 > http://wiki.freebsd.org/NvidiaFeatureRequests=20 > > >>> or a back post in this ML) - the improved mmap system call. > >=20 > >=20 > > you might check with jhb (john Baldwin) as I think (from his > > p4 work) that he may be doing something in this area in p4. >=20 > After some promptings from Robert and his needs for Xorg recently I did s= tart=20 > hacking on this again. However, I haven't tested it yet. What I have do= ne=20 > so far is in //depot/user/jhb/pat/... and it does the following: >=20 > 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (= I've=20 > only done the MD portions of this work for amd64 so far). Every arch mus= t at=20 > least define a value for VM_CACHE_DEFAULT. >=20 > 2) Stores a cache mode in each vm_map_entry struct. This cache mode is t= hen=20 > passed down to a few pmap functions: pmap_object_init_pt(),=20 > pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines suc= h as=20 > vm_map_insert() and vm_map_find() now take a cache mode to use when addin= g a=20 > new mapping. >=20 > 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAU= LT). =20 > When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of t= he=20 > object is used. >=20 > 4) A new VM object type: OBJT_SG. This object type has its own pager tha= t is=20 > sort of like the device pager. However, instead of invoking d_mmap() to=20 > determine the physaddr for a given page, it consults a pre-created=20 > scatter/gather list (an ADT from my branch for working on unmapped buffer= =20 > I/O) to determine the backing physical address for a given virtual addres= s. >=20 > 5) A new callback for device mmap: d_mmap_single(). One of the features = of=20 > this is that it can return a vm_object_t to be used to satisfy the mmap()= =20 > request instead of using the device's device pager VM object. >=20 > 6) A new mcache() system call similar to mprotect(), except that it chang= es=20 > the cache mode of an address range rather than the protection. This may = not=20 > be all that useful really. >=20 > Given all this, a driver could do the following to map a "thing" as WC in= both=20 > userland and the kernel: >=20 > 1) When it learns about a "thing" it creates a SG list to describe it. I= f=20 > the "thing" consists of userland pages, it has to wire the pages first. = The=20 > driver can use vm_allocate_pager() to create a OBJT_SG VM object. It set= s=20 > the object's cache mode to VM_CACHE_WC (if the arch supports that). >=20 > 2) When userland wants to map the "thing" it does a device mmap() with a=20 > proper length and a file offset that is a cookie for the "thing". The de= vice=20 > driver's d_mmap_single() recognizes the magic file offset and returns=20 > the "thing"'s VM object. Since the mapping info is now part of a normal=20 > object mapping, it will go away via munmap(), etc. The driver no longer = has=20 > to do weird gymnastics to invalidate mappings from its device pager=20 > as "transient" mappings are no longer stored in the device pager. >=20 > 3) When the driver wants to map the "thing" into the kernel, it can use=20 > vm_map_find() to insert the "thing"'s VM object into kernel map. >=20 > And I think that is all there is to it. I need to test this somehow to m= ake=20 > sure though, and make sure this meets the needs of Robert and Nvidia. I think this sounds pretty good... I need to get my perforce foo up to speed so I can try it out... robert. --=20 Robert Noland FreeBSD --=-ZFJl4dhNjBf/ZVMBvz0B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkn6HYQACgkQM4TrQ4qfROOQZACfTlbG6blWYjN1761Mnrc7LDM3 2CUAoIZVk1BnMN1wfacpbbpQAMDNstFa =ZyU1 -----END PGP SIGNATURE----- --=-ZFJl4dhNjBf/ZVMBvz0B-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 21:52:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E2E3106564A; Thu, 30 Apr 2009 21:52:52 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBF3B8FC28; Thu, 30 Apr 2009 21:52:51 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 9B2B11900F; Thu, 30 Apr 2009 22:52:54 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 30 Apr 2009 22:52:54 +0000 (GMT) Date: Thu, 30 Apr 2009 22:52:45 +0100 From: Bruce Cran To: John Baldwin Message-ID: <20090430225245.538d073e@gluon.draftnet> In-Reply-To: <200904300846.41576.jhb@freebsd.org> References: <200904270150.31912.pieter@degoeje.nl> <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com> <200904300846.41576.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Pieter, freebsd-acpi@freebsd.org, Goeje , Garrett Cooper , freebsd-performance@freebsd.org Subject: Re: ACPI-fast default timecounter, but HPET 83% faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:52:52 -0000 On Thu, 30 Apr 2009 08:46:41 -0400 John Baldwin wrote: > On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: > > Why's the default ACPI-fast? For power-saving functionality or > > because of the `quality' factor? What is the criteria that > > determines the `quality' of a clock as what's being reported above > > (I know what determines the quality of a clock visually from a > > oscilloscope =])? > > I suspect that the quality of the HPET driver is lower simply because > no one had measured it previously and HPET is newer and less "proven". > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_hpet.c shows some of the history behind the decision. Apparently it used to be slower but it was hoped it would get faster as systems supported it better. I guess that's happening now. -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 22:08:09 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4C611065690; Thu, 30 Apr 2009 22:08:09 +0000 (UTC) (envelope-from reg@openpave.org) Received: from mx1.ucdavis.edu (mx1.ucdavis.edu [128.120.32.31]) by mx1.freebsd.org (Postfix) with ESMTP id 87E1B8FC1D; Thu, 30 Apr 2009 22:08:09 +0000 (UTC) (envelope-from reg@openpave.org) Received: from flint.openpave.org ([169.237.230.40]) by mx1.ucdavis.edu (8.13.7/8.13.1/it-defang-5.4.0) with ESMTP id n3ULjKIx018760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 14:45:20 -0700 (PDT) Received: from sandy.local (flint.local [192.168.1.5]) by flint.openpave.org (8.14.3/8.14.3) with ESMTP id n3ULjKvC038337; Thu, 30 Apr 2009 21:45:20 GMT (envelope-from reg@sandy.local) Received: (from reg@localhost) by sandy.local (8.14.3/8.14.3/Submit) id n3ULjKxu038336; Thu, 30 Apr 2009 14:45:20 -0700 (PDT) (envelope-from reg) Date: Thu, 30 Apr 2009 14:45:20 -0700 From: Jeremy Lea To: David Forsythe Message-ID: <20090430214520.GA37974@flint.openpave.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on av3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.57 on 128.120.32.31 Cc: freebsd-hackers@FreeBSD.ORG, kientzle@FreeBSD.ORG Subject: Re: SoC2009: libpkg, pkg tools rewrite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 22:08:10 -0000 Hi, On Sat, Apr 25, 2009 at 03:20:59PM -0400, David Forsythe wrote: > This summer I'll be working on creating a package library and using > that library to rewrite the pkg tools. A package library has been > discussed and even started before, but FreeBSD still does not have > one. This summer I'd like to get enough of the library done to atle > ast have a new set of pkg tools completed with the current features, > but ideally I'd like to get far enough to splice in some of the ideas > I have for new features. Since I've already done most of the work on this already, please, please, please, don't ignore what I have done. I know that it is not perfect, and that it is now five plus years out of date. But I have covered half of the bullet points on your to-do list already. The code is at http://sourceforge.net/projects/fpkg and some README stuff is at http://fpkg.sourceforge.net/ Some things which I think are critical: 1. The library needs a global "package manager". This needs to perform all of the tasks, and it should ideally do this through a task queue (which I didn't implement). See the lib/lib.h header in FreePKG. 2. The package manager must be able to separate out a structure of variables which can be determined without opening the +CONTENTS file. This must also include a package state, and the package manager must move these package headers from state to state. 3. There needs to be proper depends handling in the packages, so that we can maintain the correct dependency graph. This is vital for upgrading. This means adding @libdep and @filedep types to the package file. 4. bsd.port.mk should do everything through the tools. It should have no knowledge of the contents of /var/db/pkg. These are all done, to some degree in the code. The mistakes I made: 1. I made the file->pkg database to sensitive. If there is a miss it rebuilds the database for scratch - it should do a search through the +CONTENTS files and only rebuild it if there was a hit (meaning the database was wrong). 2. There needs to be a pkgname and origin database, which can be loaded at startup to prime the package manager. The dependency graph should also be stored in a database. These should be rebuilt if any directory in /var/db/pkg has a mtime later than the database (so could the file database). 3. There needs to be a set of flags which indicate how a package got installed (as a dependency or by the user), and if it has been upgraded in-place and might have old leftover libraries. These could go in +CONTENTS. In addition I also began the design of a new on disk package format. This was back when there was a group called openpackages which was trying to standardize ports/packages between the BSDs. In particular it has some ideas on package signing, which is an often requested feature. http://people.freebsd.org/~reg/opdesign.html Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 22:50:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 783E0106568F; Thu, 30 Apr 2009 22:50:03 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 6324B8FC15; Thu, 30 Apr 2009 22:50:03 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [172.24.106.157] (natint3.juniper.net [66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KIX001XPONAC520@asmtp018.mac.com>; Thu, 30 Apr 2009 14:50:01 -0700 (PDT) Message-id: <78367CB5-7DAD-4DB1-99DA-2618CFACF376@mac.com> From: Marcel Moolenaar To: Robert Watson In-reply-to: Date: Thu, 30 Apr 2009 13:41:42 -0700 References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-hackers@freebsd.org, Oliver Pinter Subject: Re: NetBSD 5.0 statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 22:50:03 -0000 On Apr 30, 2009, at 12:32 PM, 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. Also :-) I recall that our "make -j X" actually limits the number of make processes/jobs to X. I don't know anything about build.sh, so I don't know if our make is at all being involved, but it would be good to know how the load varies per OS. We may simply have less parallelism in the build. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 00:38:48 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06E581065670 for ; Fri, 1 May 2009 00:38:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BA0BD8FC16 for ; Fri, 1 May 2009 00:38:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n410bOEl025192; Thu, 30 Apr 2009 18:37:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 30 Apr 2009 18:37:27 -0600 (MDT) Message-Id: <20090430.183727.803597558.imp@bsdimp.com> To: rick-freebsd2008@kiwi-computer.com From: "M. Warner Losh" In-Reply-To: <20090430233648.GA95360@keira.kiwi-computer.com> References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <20090430233648.GA95360@keira.kiwi-computer.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 00:38:48 -0000 In message: <20090430233648.GA95360@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++... : 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... Warner From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 05:49:42 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EC51106566B for ; Fri, 1 May 2009 05:49:42 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 047CA8FC13 for ; Fri, 1 May 2009 05:49:41 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 05:49:40 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp060) with SMTP; 01 May 2009 07:49:40 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+vfvAn41qvBjAPOSz08+WbtVmOP8GpsJqvix3sPy zHxFSwAzFJxK/G Message-ID: <49FA8D73.6040207@gmx.de> Date: Fri, 01 May 2009 07:49:39 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: "M. Warner Losh" References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> In-Reply-To: <20090430.090226.1569754707.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 05:49:42 -0000 M. Warner Losh schrieb: > In message: <20090428114754.GB89235@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. > : [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. > : [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. > > : [ 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. I'm not sure whether I understand this - in particular the last three words. Christoph From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 05:54:21 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB7CA106566B for ; Fri, 1 May 2009 05:54:21 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 3C7DB8FC08 for ; Fri, 1 May 2009 05:54:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 05:54:19 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp008) with SMTP; 01 May 2009 07:54:19 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+4W/0ZJgS4D8paoqvaloiuCITtly6QI9ugP1ciAm cKwrHQdcNHgRS7 Message-ID: <49FA8E88.1040905@gmx.de> Date: Fri, 01 May 2009 07:54:16 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> In-Reply-To: <20090430.183727.803597558.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 05:54:22 -0000 M. Warner Losh schrieb: > In message: <20090430233648.GA95360@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. Christoph From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 05:57:04 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9D11065678 for ; Fri, 1 May 2009 05:57:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 69C148FC20 for ; Fri, 1 May 2009 05:57:03 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 05:57:02 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp047) with SMTP; 01 May 2009 07:57:02 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/HezMuZSvH31Kv/kSvWfO+ZhAB4pig7IdreuoSBa UuaBqRlxll7pFM Message-ID: <49FA8F2D.5090708@gmx.de> Date: Fri, 01 May 2009 07:57:01 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Roman Divacky References: <49F4070C.2000108@gmx.de> <20090428121327.GA41168@freebsd.org> In-Reply-To: <20090428121327.GA41168@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Cc: FreeBSD Hackers , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 05:57:04 -0000 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. Christoph From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 08:30:27 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A91F5106564A for ; Fri, 1 May 2009 08:30:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF1E8FC17 for ; Fri, 1 May 2009 08:30:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3E2D9C055E; Fri, 1 May 2009 01:30:27 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id B6EA22D60F9; Fri, 1 May 2009 01:30:26 -0700 (PDT) Message-ID: <49FAB322.9030103@elischer.org> Date: Fri, 01 May 2009 01:30:26 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> In-Reply-To: <49FA8D73.6040207@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:30:27 -0000 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. From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 08:33:29 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698571065689 for ; Fri, 1 May 2009 08:33:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 495048FC28 for ; Fri, 1 May 2009 08:33:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 85869E4BFB; Fri, 1 May 2009 01:33:29 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 802B72D606C; Fri, 1 May 2009 01:33:28 -0700 (PDT) Message-ID: <49FAB3D8.90607@elischer.org> Date: Fri, 01 May 2009 01:33:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> In-Reply-To: <49FA8E88.1040905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:33:29 -0000 Christoph Mallon wrote: > M. Warner Losh schrieb: >> In message: <20090430233648.GA95360@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-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 08:41:40 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 634FE106564A for ; Fri, 1 May 2009 08:41:40 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8FF8FC20 for ; Fri, 1 May 2009 08:41:40 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id E09F21900F; Fri, 1 May 2009 09:41:43 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 1 May 2009 09:41:43 +0000 (GMT) Date: Fri, 1 May 2009 09:41:34 +0100 From: Bruce Cran To: Julian Elischer Message-ID: <20090501094134.77b6de04@gluon.draftnet> In-Reply-To: <49FAB322.9030103@elischer.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Christoph Mallon Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:41:40 -0000 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 =3D get_foo(); > >> if (!fp) return; > >> struct bar *bp =3D fp->bp; > >> > >> which isn't legal in 'C'. However, we have enough where this isn't > >=20 > > You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 > > (E) =A76.8.2:1. In short: you can mix statements and declarations. >=20 > 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. >=20 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. --=20 Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 11:30:19 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA50106566C for ; Fri, 1 May 2009 11:30:19 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E46EF8FC26 for ; Fri, 1 May 2009 11:30:18 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 11:30:17 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp044) with SMTP; 01 May 2009 13:30:17 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+JQCxrfDiJvGy4XkSq3YfyZ5gqJBDFcpoHk+Po6x H06S28DK2z1+uh Message-ID: <49FADD47.7060507@gmx.de> Date: Fri, 01 May 2009 13:30:15 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> In-Reply-To: <49FAB322.9030103@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 11:30:20 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 11:37:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A851065679 for ; Fri, 1 May 2009 11:37:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 5E04F8FC17 for ; Fri, 1 May 2009 11:37:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 11:37:24 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp058) with SMTP; 01 May 2009 13:37:24 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19CInFHY/pCDnlJj+Oita6mJZpYPx/ZUIv2gTt5gS Mb7ipfRAfVeFCs Message-ID: <49FADEF3.5010106@gmx.de> Date: Fri, 01 May 2009 13:37:23 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Marius Strobl References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> In-Reply-To: <20090501112239.GA23199@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 11:37:26 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 11:45:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D35A106564A; Fri, 1 May 2009 11:45:01 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id DABE08FC0C; Fri, 1 May 2009 11:45:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n41BMeqw023340; Fri, 1 May 2009 13:22:40 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n41BMd5u023339; Fri, 1 May 2009 13:22:39 +0200 (CEST) (envelope-from marius) Date: Fri, 1 May 2009 13:22:39 +0200 From: Marius Strobl To: Christoph Mallon Message-ID: <20090501112239.GA23199@alchemy.franken.de> References: <49F4070C.2000108@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F4070C.2000108@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 11:45:01 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 11:46:50 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F76C106566B for ; Fri, 1 May 2009 11:46:50 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D9B858FC18 for ; Fri, 1 May 2009 11:46:49 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 11:46:48 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp060) with SMTP; 01 May 2009 13:46:48 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19GE8pVJ7lGIwTYO2Bmfvc4njZ+1ttgjLZdozsvqI 8ECId6aOhp03iy Message-ID: <49FAE126.5050903@gmx.de> Date: Fri, 01 May 2009 13:46:46 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <49FAB3D8.90607@elischer.org> In-Reply-To: <49FAB3D8.90607@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 11:46:50 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 11:56:58 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BECA106564A for ; Fri, 1 May 2009 11:56:58 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 027EF8FC08 for ; Fri, 1 May 2009 11:56:57 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id n41Butnh011282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 04:56:56 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <49FAE36D.9030109@FreeBSD.org> Date: Fri, 01 May 2009 04:56:29 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090428121327.GA41168@freebsd.org> <49FA8F2D.5090708@gmx.de> In-Reply-To: <49FA8F2D.5090708@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , FreeBSD Hackers , Roman Divacky , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 11:56:58 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 12:02:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D40C610656AC for ; Fri, 1 May 2009 12:02:52 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 468938FC15 for ; Fri, 1 May 2009 12:02:52 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 12:02:50 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp017) with SMTP; 01 May 2009 14:02:50 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/FM+YIUdnF+/vHYQRxqcg8bGwwpxpP7h5A5gfp1X EnLIRNM0MbHk0S Message-ID: <49FAE4EA.1010205@gmx.de> Date: Fri, 01 May 2009 14:02:50 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Peter Jeremy References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> In-Reply-To: <20090428114754.GB89235@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: FreeBSD Hackers Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:02:55 -0000 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 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. Most local variables are scalars (pointers, ints, ...). A struct or array as local variable is rare and then usually used in one context. So IMO this is fine. Even considereing the extremly rare case of multiple non-scalar declarations in a function, then a compiler can coalesce them if their life ranges are disjoint. It is easier to do so for a compiler to do so, if they are declared with smaller life ranges, example: struct Foo { int x[16]; }; struct Bar { int* y[16]; }; void f(struct Foo*); void g(struct Bar*); void e(int x) { struct Foo a; struct Bar b; if (x) { f(&a); } else { g(&b); } } Stack usage: subl $140, %esp moving the declarations into the branches: subl $76, %esp So, apart from improved readability, it also can lead to better code. But I consider the latter way less important the benefits observed by a reader of the code. Christoph From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 12:05:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674221065670 for ; Fri, 1 May 2009 12:05:29 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 177818FC0A for ; Fri, 1 May 2009 12:05:28 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1791485qwe.7 for ; Fri, 01 May 2009 05:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=kTTAtd1eOjb2QoZiXm4eGrAPAYrvoLkc20mSI/I7uM4=; b=A26SfCf6/kGtp+0kxT5xkqmfucLoIx7f91j0pOwxHIQLF9BdNCvOiP6cR78gbH/u6l cbJPA41z6CD/lXQmmHhdI3lNVIqOVwyOMxbTzUW7Ftl3v76t7TbRXZRPE4oVtdM6BQbF BrOQGNQrfyAN8i2yXft9UHN6hFZtDScq4sjL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=JI9xOnES1tblmtZ1l1rchIFBrGZ6WiIUwKYw49BFAN+ENUyiAdEUWKN8pqHBi4/v+h kxRJlQy3ijhDEvIBolm6J4HLXmw0AWRHd+d8I0EiCkNJl/Dum6HhQey1ogILRWdB9OaQ jbqE1TcoyNdnY43dzBjfNqMR2gvuA2wEhChLM= Received: by 10.224.28.73 with SMTP id l9mr2929029qac.288.1241177554170; Fri, 01 May 2009 04:32:34 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 5sm6122853qwh.4.2009.05.01.04.32.32 (version=SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 04:32:33 -0700 (PDT) Date: Fri, 1 May 2009 07:32:24 -0400 From: Alexander Kabaev To: freebsd-hackers@freebsd.org Message-ID: <20090501073224.518cb833@kan.dnsalias.net> In-Reply-To: References: <6101e8c40904300750i3e86fc0cnef09b0d4533627f7@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/u949MyjUD1ePg/KG9l0_9.y"; protocol="application/pgp-signature" Cc: Oliver Pinter Subject: Re: NetBSD 5.0 statistics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:05:29 -0000 --Sig_/u949MyjUD1ePg/KG9l0_9.y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 30 Apr 2009 20:32:00 +0100 (BST) Robert Watson wrote: >=20 > On Thu, 30 Apr 2009, Oliver Pinter wrote: >=20 > > 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? >=20 > 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. >=20 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. --=20 Alexander Kabaev --Sig_/u949MyjUD1ePg/KG9l0_9.y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ+t3OQ6z1jMm+XZYRAsb+AKCU/Jz50i6qngEIcp7u8A0T7hx3qQCfY2L2 WX6gF+bByq/xY20Xpapu4Os= =4YwD -----END PGP SIGNATURE----- --Sig_/u949MyjUD1ePg/KG9l0_9.y-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 12:10:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04C94106564A; Fri, 1 May 2009 12:10:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2D68FC20; Fri, 1 May 2009 12:10:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n41CAIFT023708; Fri, 1 May 2009 14:10:18 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n41CAIu4023707; Fri, 1 May 2009 14:10:18 +0200 (CEST) (envelope-from marius) Date: Fri, 1 May 2009 14:10:18 +0200 From: Marius Strobl To: Christoph Mallon Message-ID: <20090501121018.GC2943@alchemy.franken.de> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49FADEF3.5010106@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:10:21 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 12:31:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA28D1065675 for ; Fri, 1 May 2009 12:31:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 99FC58FC1C for ; Fri, 1 May 2009 12:31:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Lzrtu-0006cn-Pp; Fri, 01 May 2009 15:31:34 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Marius Strobl In-reply-to: <20090501112239.GA23199@alchemy.franken.de> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> Comments: In-reply-to Marius Strobl message dated "Fri, 01 May 2009 13:22:39 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 2009 15:31:33 +0300 From: Danny Braniss Message-ID: Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , Christoph Mallon , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 12:31:37 -0000 > 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 13:05:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735671065674 for ; Fri, 1 May 2009 13:05:40 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 056F88FC1D for ; Fri, 1 May 2009 13:05:39 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so2335636ewy.43 for ; Fri, 01 May 2009 06:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=xyb4ojSi56jb9j87hB1s9QsvWMs9nQZRxESx0TJ7YwQ=; b=lAnCpchNMuTOJEhElj0KrjDfryQEeXbE3XJ0wES/wFbd36Bbr2nx99KVgmcbMPRiVb jHHDSLFIIbumCQ3fYR9xbQzTtrFum999tqliQK+WHHybpXnqGtj0Em4yAhCww8jgRHZH 25j5fhLOAZOoHxmBmEorl4wUri6XBvKvf1qSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=IvAhTtiEQr/4ltdqsuJZ5G5tWGmLf25XD8BHce1guJHSudxKLKsFeBEPBc+OjX55mH FpgtAWg67QARxmB9SDY1ZUDrbm/RgvEAKRYu1KqDSIPWicJIcTZdctcg/k4Omy08VV+E yZFtgy06eJ2BrcNZSb7YGvR9ug6sYiKmpZCVM= Received: by 10.210.35.5 with SMTP id i5mr2918929ebi.14.1241183138975; Fri, 01 May 2009 06:05:38 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 25sm4046375ewy.47.2009.05.01.06.05.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 May 2009 06:05:38 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id BD54A5C40; Fri, 1 May 2009 13:05:36 +0000 (UTC) Date: Fri, 1 May 2009 14:05:36 +0100 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20090501130536.GA95601@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 13:05:40 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14:01:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EF8F10656D5 for ; Fri, 1 May 2009 14:01:54 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id E65D48FC1E for ; Fri, 1 May 2009 14:01:53 +0000 (UTC) (envelope-from anchie@fer.hr) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n41E29rp015268 for ; Fri, 1 May 2009 16:02:10 +0200 (CEST) Received: from ana-kukecs-macbook.local ([89.164.43.248]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 16:01:48 +0200 Message-ID: <49FB00CB.5080402@fer.hr> Date: Fri, 01 May 2009 16:01:47 +0200 From: Ana Kukec User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jan Melen References: <49F5B6F8.4040808@melen.org> In-Reply-To: <49F5B6F8.4040808@melen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 14:01:48.0756 (UTC) FILETIME=[5EC9C940:01C9CA65] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: freebsd-hackers@freebsd.org Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:01:54 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14:14:16 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5CF010656D9 for ; Fri, 1 May 2009 14:14:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 767D58FC13 for ; Fri, 1 May 2009 14:14:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n41E9OQc042088; Fri, 1 May 2009 08:09:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 01 May 2009 08:09:27 -0600 (MDT) Message-Id: <20090501.080927.-1923761682.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <49FA8D73.6040207@gmx.de> References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:14:17 -0000 In message: <49FA8D73.6040207@gmx.de> Christoph Mallon writes: : M. Warner Losh schrieb: : > In message: <20090428114754.GB89235@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 t= he = : > : >proposed changes individually and not a as a all-or-nothing pack= age. : > : = : > : One area you do not address is code consistency. Currently, the : > : FreeBSD kernel (and, to a lesser extent, userland) are mostly sty= le(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 co= de : > : means that either existing code must be brought into line with th= e : > : new standard - which incurs a one-off cost - or the code base bec= omes : > : split into "old" and "new" style - incurring an ongoing maintenan= ce : > : 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 a= s : > : 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 mak= es : > 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 ne= w = : 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 variable= s where : > : they are declared, sort by name] : > : = : > : Whilst my personal preference is for the style suggested by Chris= toph : > : (and I generally agree with the points he makes), this is also th= e : > : change that incurs the biggest stylistic change. This is not a c= hange : > : that can be practically retrofitted to existing code and therefor= e its : > : implementation would result in a mixture of code styles - increas= ing : > : the risk of bugs due to confusion as to which style was being use= d. 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 =3D get_foo(); : > if (!fp) return; : > bp =3D fp->bp; : > = : > this can't easily be translated to the more natural: : > = : > struct foo *fp =3D get_foo(); : > struct bar *bp =3D fp->bp; : > = : > since really you'd want to write: : > = : > struct foo *fp =3D get_foo(); : > if (!fp) return; : > struct bar *bp =3D 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)= : =A76.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 instanc= es : > 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, the= re : > : 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 t= his : > : change until all K&R code is removed from FreeBSD. : > = : > I'm fine with this change. : > = : > : [ Don't insert an empty line if the function has no local variabl= es.] : > : = : > : This change could be made and tested mechanically. IMHO, this ch= ange : > : has neglible risk and could be safely implemented. : > = : > I'm fine with this change. : = : Would you commit these three proposals? Yes. : > : >> +.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 handl= e = : > : >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 (th= ough : > : I'm not sure if this is supported). Assuming that gcc (and icc a= nd : > : clang) behaves as stated in all supported optimisation modes, thi= s : > : 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. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14:15:18 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E83106570B for ; Fri, 1 May 2009 14:15:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A8E218FC12 for ; Fri, 1 May 2009 14:15:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n41ECQpP042145; Fri, 1 May 2009 08:12:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 01 May 2009 08:12:29 -0600 (MDT) Message-Id: <20090501.081229.1359784281.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <49FA8E88.1040905@gmx.de> References: <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:15:18 -0000 In message: <49FA8E88.1040905@gmx.de> Christoph Mallon writes: : M. Warner Losh schrieb: : > In message: <20090430233648.GA95360@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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14:21:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCDAC106567D; Fri, 1 May 2009 14:21:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 891F68FC22; Fri, 1 May 2009 14:21:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n41EKGim042260; Fri, 1 May 2009 08:20:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 01 May 2009 08:20:20 -0600 (MDT) Message-Id: <20090501.082020.698246310.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <49FADEF3.5010106@gmx.de> References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sobomax@freebsd.org, freebsd-hackers@freebsd.org, rdivacky@freebsd.org, ed@freebsd.org, marius@alchemy.franken.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:21:12 -0000 In message: <49FADEF3.5010106@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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 14:40:07 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45362106564A for ; Fri, 1 May 2009 14:40:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD898FC1A for ; Fri, 1 May 2009 14:40:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n41Eb8kd042460; Fri, 1 May 2009 08:37:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 01 May 2009 08:37:12 -0600 (MDT) Message-Id: <20090501.083712.396385864.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <20090501.081229.1359784281.imp@bsdimp.com> References: <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:40:07 -0000 In message: <20090501.081229.1359784281.imp@bsdimp.com> M. Warner Losh writes: : In message: <49FA8E88.1040905@gmx.de> : Christoph Mallon writes: : : M. Warner Losh schrieb: : : > In message: <20090430233648.GA95360@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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 16:09:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D9E81065678 for ; Fri, 1 May 2009 16:09:13 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 00BC18FC19 for ; Fri, 1 May 2009 16:09:12 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 08:57:34 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E02ACA843@seaxch09.desktop.isilon.com> In-Reply-To: <49FAE4EA.1010205@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ incompatability, was C99: Suggestions for style(9) Thread-Index: AcnKVOrLOASvMCbnRYWtAm5tTqsg4QAH/vtQ References: <49F4070C.2000108@gmx.de><20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> From: "Matthew Fleming" To: "FreeBSD Hackers" Subject: C++ incompatability, was C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:09:13 -0000 [snip exciting discussion on style] > There are several C99 features used already, e.g. designated initializers: > bla bli =3D { .blub =3D "foo", .arr[0] =3D 42 }; > Do you suggest that this should not be used, because it is inconsistent=20 > 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=20 #ifdef __cplusplus extern "C" { #endif to sys/sys/*.h and other headers that can be included by a kernel module. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 16:16:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0574106566C for ; Fri, 1 May 2009 16:16:23 +0000 (UTC) (envelope-from justin@sigsegv.ca) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 897008FC12 for ; Fri, 1 May 2009 16:16:23 +0000 (UTC) (envelope-from justin@sigsegv.ca) Received: by yx-out-2324.google.com with SMTP id 8so1518706yxb.13 for ; Fri, 01 May 2009 09:16:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.119.10 with SMTP id w10mr5948702ybm.167.1241192909202; Fri, 01 May 2009 08:48:29 -0700 (PDT) From: "Justin G." Date: Fri, 1 May 2009 08:48:09 -0700 Message-ID: <5da021490905010848q441781den54eefba85a69f342@mail.gmail.com> To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 May 2009 16:22:41 +0000 Subject: Cobalt Raq 550 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:16:24 -0000 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. From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 16:50:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C39A1065674 for ; Fri, 1 May 2009 16:50:51 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3438FC29 for ; Fri, 1 May 2009 16:50:51 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 576465B3B; Fri, 1 May 2009 09:31:08 -0700 (PDT) To: "Matthew Fleming" In-reply-to: Your message of "Fri, 01 May 2009 08:57:34 PDT." <06D5F9F6F655AD4C92E28B662F7F853E02ACA843@seaxch09.desktop.isilon.com> References: <49F4070C.2000108@gmx.de><20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> <06D5F9F6F655AD4C92E28B662F7F853E02ACA843@seaxch09.desktop.isilon.com> Comments: In-reply-to "Matthew Fleming" message dated "Fri, 01 May 2009 08:57:34 -0700." Date: Fri, 01 May 2009 09:31:08 -0700 From: Bakul Shah Message-Id: <20090501163108.576465B3B@mail.bitblocks.com> Cc: FreeBSD Hackers Subject: Re: C++ incompatability, was C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:50:52 -0000 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. From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 17:00:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88ED1106564A for ; Fri, 1 May 2009 17:00:09 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6939B8FC0C for ; Fri, 1 May 2009 17:00:09 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 10:00:32 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E02ACA852@seaxch09.desktop.isilon.com> In-Reply-To: <20090501163108.576465B3B@mail.bitblocks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ incompatability, was C99: Suggestions for style(9) Thread-Index: AcnKejyLzFz6WmGjQfShaU2MxkuXxgAA54ng References: <49F4070C.2000108@gmx.de><20090428114754.GB89235@server.vk2pj.dyndns.org> <49FAE4EA.1010205@gmx.de> <06D5F9F6F655AD4C92E28B662F7F853E02ACA843@seaxch09.desktop.isilon.com> <20090501163108.576465B3B@mail.bitblocks.com> From: "Matthew Fleming" To: "Bakul Shah" Cc: FreeBSD Hackers Subject: RE: C++ incompatability, was C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:00:09 -0000 > > [snip exciting discussion on style] > >=20 > > > There are several C99 features used already, e.g. designated initializers: > > > bla bli =3D { .blub =3D "foo", .arr[0] =3D 42 }; > > > Do you suggest that this should not be used, because it is inconsistent > > > with all the other existing compound initialisations? > >=20 > > 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). >=20 > 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 17:03:32 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECCA81065687 for ; Fri, 1 May 2009 17:03:32 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id D33808FC0C for ; Fri, 1 May 2009 17:03:32 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from vesper.usenix.org (vesper.usenix.org [131.106.3.142]) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id n41Gtpd2029179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 May 2009 10:03:32 -0700 (PDT) Message-Id: From: Lionel Garth Jones To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 10:03:32 -0700 X-Mailer: Apple Mail (2.930.3) X-DCC-Usenix-Metrics: lonestar; whitelist X-Spam-Status: No, score=-1.4 required=6.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on lonestar X-Mailman-Approved-At: Fri, 01 May 2009 17:10:41 +0000 Subject: USENIX WebApps '10 Call for Papers Now Available X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:03:33 -0000 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 =20 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 =20 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=9625, 2010, in Boston, MA. The technical sessions = will take place on June 23=9625. I look forward to receiving your submissions! Sincerely, John Ousterhout, Stanford University WebApps '10 Program Chair webapps10chair@usenix.org ------------------------------------------------------------------------ Call for Papers: USENIX Conference on Web Application Development (WebApps '10) June 20=9625, 2010 Boston, MA http://www.usenix.org/webapps10/cfpa Paper submissions deadline: January 11, 2010 ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 17:35:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D036C106564A for ; Fri, 1 May 2009 17:35:16 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5AC8FC13 for ; Fri, 1 May 2009 17:35:16 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so2442740ewy.43 for ; Fri, 01 May 2009 10:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to; bh=QSsUznc3bc9NlhSgo/gQCf8kMrk9pN0lopAHcZN9OLo=; b=u9nQPEKic7kewreCN3YYTUk5oeiZHiTH2kRFnHSU1I9hY6PGILyPuCoD9uNhWmZZ8P 8CoxaWDDMHARuzcSUd3I0HtmeWiSJODXMXepjpmdn28eidIAuZjqbyxER2z8bxwQdVeQ hbSL0SSAY5usErv1ABmdRyP44/7CnNDJWn4Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=nVSfHL9aQXbw17e0tSI1wVhKdpm6zc3qarZjD8jleUKniN8CE5jOh2YG77PVcbC7zc JOPKCApEZTYkROVj+/0nxdqWs/wABhcx09iBLE0g4AFbCyl6WRWffs0FBI0/aGTUDz1n AtgvGfecyyudb9+QDM1UF3otTG9KPIKonnWGI= Received: by 10.210.10.11 with SMTP id 11mr3143161ebj.71.1241199315474; Fri, 01 May 2009 10:35:15 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 5sm4193647ewy.76.2009.05.01.10.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 May 2009 10:35:15 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id D63695C31; Fri, 1 May 2009 17:35:13 +0000 (UTC) Date: Fri, 1 May 2009 18:35:13 +0100 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20090501173513.GA27141@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090501130536.GA95601@logik.internal.network> Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:35:17 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 17:42:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC0571065676 for ; Fri, 1 May 2009 17:42:12 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 145C58FC18 for ; Fri, 1 May 2009 17:42:10 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so2445246ewy.43 for ; Fri, 01 May 2009 10:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=p6nrfgkZjV1wRARxOCHhpqg24tDKMkegGBUP32RXGyI=; b=BOWqW7H/HVITFfSISghXKOHyLCYVshzITZAIgB+8c7hinfnfE+DiyTDPStl+NzzuBO DLhPAvRG8qBGlvliqF6d0xylLqSHQ+jkp+gaXDNknD5cyOpSY2KgcpR2/0tUdSCIwZ0j wHu/cLvwP0wHL7ljBUfRDQrjUJQid43ltO5L4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=tUFwVS8lgHli7Pn7QvoR9RyW6770XXPJPitJHL8OTmCuoKFrUT0T/NIj2s0+q9xyiX seaZcDX2JTBGo3UzFKjnl7HshcNWAL1RG8zoPkZj/Jhuci1QeJnlPOWyfVgQ62Z9AkUC 2sxMGiUedi8x5WK2rKSkwPGPKAduN5BH2Ekl4= Received: by 10.210.126.18 with SMTP id y18mr326485ebc.95.1241199730346; Fri, 01 May 2009 10:42:10 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 9sm4042241ewy.9.2009.05.01.10.42.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 May 2009 10:42:10 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 668D75C31; Fri, 1 May 2009 17:42:08 +0000 (UTC) Date: Fri, 1 May 2009 18:42:08 +0100 From: xorquewasp@googlemail.com To: Attilio Rao Message-ID: <20090501174208.GA42682@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> <20090501173513.GA27141@logik.internal.network> <3bbf2fe10905011039o7af18b98n70202ecf78ec7904@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10905011039o7af18b98n70202ecf78ec7904@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:42:12 -0000 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:0xffffffff80509409 stack pointer = 0x10:0xffffffff7a3d46b0 frame pointer = 0x10:0xffffffff7a3d46e0 code segment = base 0x0, limit 0xfffff, 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 (0xffffffff80be9940) locked @ /usr/src/sys/kern/vfs_cache.c:345 exclusive sleep mutex Name Cache r = 0 (0xffffffff80be9940) locked @ /usr/src/sys/kern/vfs_cache.c:345 exclusive sx so_rcv_sx r = 0 (0xffffff0005b42970) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 The web interface mangled the whitespace somewhat. xw From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 17:58:04 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B412106564A for ; Fri, 1 May 2009 17:58:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outk.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0DF8FC15 for ; Fri, 1 May 2009 17:58:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3EB15E3FC0; Fri, 1 May 2009 10:58:04 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4BF7C2D60D0; Fri, 1 May 2009 10:58:03 -0700 (PDT) Message-ID: <49FB382B.6030406@elischer.org> Date: Fri, 01 May 2009 10:58:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "M. Warner Losh" References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> <20090501.082020.698246310.imp@bsdimp.com> In-Reply-To: <20090501.082020.698246310.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sobomax@freebsd.org, freebsd-hackers@freebsd.org, rdivacky@freebsd.org, ed@freebsd.org, marius@alchemy.franken.de, christoph.mallon@gmx.de Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 17:58:04 -0000 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-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 18:05:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519E9106568E for ; Fri, 1 May 2009 18:05:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CD4BD8FC2C for ; Fri, 1 May 2009 18:05:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz9 with SMTP id 9so2390256bwz.43 for ; Fri, 01 May 2009 11:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=kab0UsYq4RSpaLjfqCfA2v740RCCtEamY/LWl54cjHc=; b=t4I+/0bFA7gsMXYXB7ggMtaPMbAYB+n4RNgLFgkSKgFV4AagVKZOxg0dnwgbMGdd6q xjZ0xEhQJnUKk+X2kv6B9LyJ+jeZkdLrTZRFPFf7kHqhExTJCJnbAwqCElHyME6c2wVN kdGQrgsp6jZl/wWQxzEoLGI/Kzw1MvFCBk2YA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UBjBl/UIGFHQEPJocWcdNzdry5YXnig5fXDB0l0C0Lw+q6p92mcfqmQHJDRQLu8P0Y FMgAuqKtdiu9tPnOWf0StSNlE/6ei/Zr/Zazt7MVbP/lKOo0Gp556qDJDrTas+WntNzN 0gVQurOP1zGHmaGBTXHaWQsaHicrpduvgUW7w= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.112.202 with SMTP id x10mr1237751fap.68.1241199583584; Fri, 01 May 2009 10:39:43 -0700 (PDT) In-Reply-To: <20090501173513.GA27141@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> <20090501173513.GA27141@logik.internal.network> Date: Fri, 1 May 2009 19:39:43 +0200 X-Google-Sender-Auth: 53a4b2b925d8b226 Message-ID: <3bbf2fe10905011039o7af18b98n70202ecf78ec7904@mail.gmail.com> From: Attilio Rao To: xorquewasp@googlemail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:05:55 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 18:28:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 404EB106564A for ; Fri, 1 May 2009 18:28:06 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6BA8FC08 for ; Fri, 1 May 2009 18:28:06 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-35-171.dsl.snfc21.pacbell.net [71.139.35.171]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n41IS47A094959 for ; Fri, 1 May 2009 11:28:04 -0700 (PDT) Message-ID: <49FB3F32.2010800@rawbw.com> Date: Fri, 01 May 2009 11:28:02 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Why top never shows ~100% CPU usage with heavy PCU load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:28:06 -0000 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 USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 85422 yuri 1 99 0 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 18:50:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7159F1065670 for ; Fri, 1 May 2009 18:50:57 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 43C1D8FC18 for ; Fri, 1 May 2009 18:50:56 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-35-171.dsl.snfc21.pacbell.net [71.139.35.171]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n41Ioupj000906 for ; Fri, 1 May 2009 11:50:56 -0700 (PDT) Message-ID: <49FB448A.9050607@rawbw.com> Date: Fri, 01 May 2009 11:50:50 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090419) MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <49FB3F32.2010800@rawbw.com> <20090501183847.GB47845@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090501183847.GB47845@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Why top never shows ~100% CPU usage with heavy PCU load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:50:57 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 19:00:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3EBE106566C for ; Fri, 1 May 2009 19:00:45 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A90E8FC16 for ; Fri, 1 May 2009 19:00:45 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 52820199498; Fri, 1 May 2009 20:38:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 45B70199496; Fri, 1 May 2009 20:38:49 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 2894D199491; Fri, 1 May 2009 20:38:49 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009050120384746-27689 ; Fri, 1 May 2009 20:38:47 +0200 Received: by wep4035 (sSMTP sendmail emulation); Fri, 1 May 2009 20:38:47 +0200 Date: Fri, 1 May 2009 20:38:47 +0200 From: Alexey Shuvaev To: Yuri Message-ID: <20090501183847.GB47845@wep4035.physik.uni-wuerzburg.de> References: <49FB3F32.2010800@rawbw.com> MIME-Version: 1.0 In-Reply-To: <49FB3F32.2010800@rawbw.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/01/2009 08:38:47 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 05/01/2009 08:38:48 PM, Serialize complete at 05/01/2009 08:38:48 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-hackers@freebsd.org Subject: Re: Why top never shows ~100% CPU usage with heavy PCU load? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:00:46 -0000 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 USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND > 85422 yuri 1 99 0 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 USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 48032 lexx 1 118 0 2624K 604K CPU1 1 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 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 ~> cat bbb.c int main(void) { for (;;); return; } My $0.02, Alexey. From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 19:13:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013941065676 for ; Fri, 1 May 2009 19:13:17 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id A7DA98FC17 for ; Fri, 1 May 2009 19:13:16 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk3 with SMTP id 3so5152175qyk.3 for ; Fri, 01 May 2009 12:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=dJxxG+tpH0fnt1RSksN6aV9YJ0Ha1Zwfyi6iRSHoZVk=; b=DIET6LlDHbbEW0NNVbclEhc52FZh3fDaX9666TElxGeZ1eQKFbNm3kN4C2KkY4GB62 T0C6W+aQ4DzZXHxP6gtg909Xj2HV9PTg3CAWRQFrdJKAhaH32SB3SDx8ElyuCR5h3mbv U6kXVuJ0+Pc44TVuknhFE1lYkzC7zwzJ1nsIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Thkv0R6aJ8wNEpbKHTsQ0BPc2C6uwqpGZdFT+bt2aTPas8qNx6Ay0BKoVOI7bLar72 SPtOD7jEyTAP2WkooPLwuJkGh/rTslUMbc5XUwWtVM2Cz9t2vCvR2YJP0MkGWzJKoQVt f6g+wrU602mGAbCDIE7WFsWaZrxYykwfFVgLo= Received: by 10.224.37.79 with SMTP id w15mr3517946qad.231.1241205195934; Fri, 01 May 2009 12:13:15 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 8sm7032129qwj.1.2009.05.01.12.13.14 (version=SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 12:13:15 -0700 (PDT) Date: Fri, 1 May 2009 15:13:08 -0400 From: Alexander Kabaev To: xorquewasp@googlemail.com Message-ID: <20090501151308.5c9109da@kan.dnsalias.net> In-Reply-To: <20090501130536.GA95601@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/McDmvGxFspZHqW8jXdY+oTj"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:13:17 -0000 --Sig_/McDmvGxFspZHqW8jXdY+oTj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. --=20 Alexander Kabaev --Sig_/McDmvGxFspZHqW8jXdY+oTj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ+0nJQ6z1jMm+XZYRAhcCAKDYq3dftmCidwLtQYzV5E/BqfQ0rACg3QFI 2UaWifGXQbgODgvL/pzwQpc= =0XYu -----END PGP SIGNATURE----- --Sig_/McDmvGxFspZHqW8jXdY+oTj-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 19:21:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BE310656C0 for ; Fri, 1 May 2009 19:21:17 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 594568FC16 for ; Fri, 1 May 2009 19:21:16 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so2482392ewy.43 for ; Fri, 01 May 2009 12:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=OjKiRz3W1gJKij904bb3tH8yoZUp7cPldz5d2YapYE4=; b=YeVfwoRS3b8STAdR1o1TGSw5hp/qlJbY9gS3pv20xoKj2wii8NKZBv+6gSd/zFgEM7 L5Dy+9zoItnGnGvOt4x/IYNiNuMY7zznIHQ4CFBxNFruQFSchXWPnCmR9fw10oUjNw6n w0GFpfWogjWqziGkEI/+12dbbrAojyvUo6Q5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=kIUUU9P1UCRxVL1s5TwqFfxJpNLviW0JtPyQNYpeWI1jewI8MPM0ZEx3X0yPwBlzr3 OyIb8Q+wW2id9jrnrQH/cXtKFYOW7rmdEkLM3OxU8RVVnZj0qGlgp72nMYgA3V9f5p5t EuRX3FC/QvhLTEvhgfeExc0+2gvv1uNRbp9Js= Received: by 10.210.82.13 with SMTP id f13mr838994ebb.48.1241205674941; Fri, 01 May 2009 12:21:14 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 2sm1706134ewy.14.2009.05.01.12.21.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 May 2009 12:21:14 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 3FD915C31; Fri, 1 May 2009 19:21:13 +0000 (UTC) Date: Fri, 1 May 2009 20:21:13 +0100 From: xorquewasp@googlemail.com To: Alexander Kabaev Message-ID: <20090501192113.GA15572@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> <20090501151308.5c9109da@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090501151308.5c9109da@kan.dnsalias.net> Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:21:17 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 19:50:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7D7106564A for ; Fri, 1 May 2009 19:50:47 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9058FC08 for ; Fri, 1 May 2009 19:50:46 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1587202yxb.13 for ; Fri, 01 May 2009 12:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=S2P4kdU43mvQCRq86rzu5ljEn4xVUACiPGSxZdNVHJc=; b=KSI1Ig6UlV9mc3xCYPUOmWnTDev7Ef0vieTe1RuPpmG7Cq8sfc3lSk8BH12EHp0mOG v9cvSlKYh65lLH9TefRVMQJXi86ClgUyYJByBfHtU2bI80lOElH3YVpZreIpWUudvFuS reuqe3NW5dHbnDeOB5YCOWKZgeRPVmX3xiBtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=fZqRljanmbViF+aGzqzEkdJvgko6Rd/sMWGCw8eWdxYLDufhPUxBtxSe9kLpVLs2Yd k6EcocJTkZ9QjuBY3IZdysSRAwKAl3r5Ydbz5QQXQLmov57ZWyJH87JPjVrXqycVOFQz dm1F4c2fW814wv1VIj5pStUvHBaVJ+vZEQRMw= Received: by 10.90.33.15 with SMTP id g15mr2545831agg.48.1241207446328; Fri, 01 May 2009 12:50:46 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 21sm6002201agd.11.2009.05.01.12.50.44 (version=SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 12:50:45 -0700 (PDT) Date: Fri, 1 May 2009 15:50:38 -0400 From: Alexander Kabaev To: xorquewasp@googlemail.com Message-ID: <20090501155038.692eb891@kan.dnsalias.net> In-Reply-To: <20090501192113.GA15572@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> <20090501151308.5c9109da@kan.dnsalias.net> <20090501192113.GA15572@logik.internal.network> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.ZdznANb64jNvlAUtQ6XCsf"; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:50:47 -0000 --Sig_/.ZdznANb64jNvlAUtQ6XCsf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 1 May 2009 20:21:13 +0100 xorquewasp@googlemail.com wrote: > Hello. >=20 > 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. >=20 > The machine was so new that I hadn't even set the clock, so the kernel > timestamps appear to be Jan 1. >=20 > 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.=20 You can always try to bypass namecache altogether while you are building the new kernel: do sysctl debug.vfscache=3D0 --=20 Alexander Kabaev --Sig_/.ZdznANb64jNvlAUtQ6XCsf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFJ+1KTQ6z1jMm+XZYRAoVcAJ0SJsFkpxo5Ndo3AJHhehLhNZCG3gCeOS1Q PccQ6jQiJlGEADo4DvYffq0= =qwNA -----END PGP SIGNATURE----- --Sig_/.ZdznANb64jNvlAUtQ6XCsf-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:22:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42EEE106564A; Fri, 1 May 2009 20:22:34 +0000 (UTC) (envelope-from marta@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0A74B8FC12; Fri, 1 May 2009 20:22:33 +0000 (UTC) (envelope-from marta@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 1002) id 6CCCD730A1; Fri, 1 May 2009 22:09:31 +0200 (CEST) Date: Fri, 1 May 2009 22:09:31 +0200 From: Marta Carbone To: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Message-ID: <20090501200931.GA55379@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: SoC2009: Ipfw and dummyent improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:22:34 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:32:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E196610656A8 for ; Fri, 1 May 2009 20:32:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 420768FC17 for ; Fri, 1 May 2009 20:32:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 20:32:24 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp069) with SMTP; 01 May 2009 22:32:24 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+FxJQjFxKFpONrnRjRUsP5ccuf4FXm7LJ+lhA/HF rz9+uHCagXoAQI Message-ID: <49FB5C57.6050407@gmx.de> Date: Fri, 01 May 2009 22:32:23 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Zaphod Beeblebrox References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> In-Reply-To: <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:32:27 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:38:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA4C4106564A for ; Fri, 1 May 2009 20:38:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 9B83F8FC12 for ; Fri, 1 May 2009 20:38:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1979DE4BD6; Fri, 1 May 2009 13:38:14 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2D8732D6180; Fri, 1 May 2009 13:38:12 -0700 (PDT) Message-ID: <49FB5DB3.9030200@elischer.org> Date: Fri, 01 May 2009 13:38:11 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> <49FB5C57.6050407@gmx.de> In-Reply-To: <49FB5C57.6050407@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Zaphod Beeblebrox Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:38:14 -0000 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-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:42:04 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1743D1065674 for ; Fri, 1 May 2009 20:42:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id F1F118FC08 for ; Fri, 1 May 2009 20:42:02 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 20:42:01 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp007) with SMTP; 01 May 2009 22:42:01 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/rvwYjDGbrP/u4Pf8nMdr3QZjyTZJmhH/DJ4yNSU cymcOUefHcYr9P Message-ID: <49FB5E99.5070004@gmx.de> Date: Fri, 01 May 2009 22:42:01 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> <49FB5C57.6050407@gmx.de> <49FB5DB3.9030200@elischer.org> In-Reply-To: <49FB5DB3.9030200@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: freebsd-hackers@freebsd.org, Zaphod Beeblebrox Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:42:04 -0000 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. From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:48:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F112106564A for ; Fri, 1 May 2009 20:48:48 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8A94E8FC1E for ; Fri, 1 May 2009 20:48:47 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by ewy19 with SMTP id 19so2515144ewy.43 for ; Fri, 01 May 2009 13:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8/aynW+rH3syutbaGitYDSMw0GTw5jC9DenY2kiE2F4=; b=NpKyTXmbnGokoH0VtThn2KZ1jryTzL7tXojX+8QO7asHNhnHNHb/5fxRzrnuq3lPXa C89fSeqSv3Kz96ltsCtpX+A9mujlbcn/9yIwrueHcFWSIfYk/cK3Sk0gHjgTiF9TS2Fl zthmFHia+nPmyW5+tQ16yMc0teEm8T5e1p2pk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qDcuWITKdN5cB7w1xhZYRQHv4pci228SDxamB9uciTIoJh6A7RhblOc8IvnfnFKdHS uB3ntBJMSRi+OuusP2FBvwWwvK+DL5n9g/ZOSN5KPI2zfn+VZ4q5pHJEDvzuRqLQqWnI JatdSDm14K6y0EG9hxYRSN8v4mBti531zsDIc= MIME-Version: 1.0 Received: by 10.210.10.8 with SMTP id 8mr903815ebj.49.1241209445081; Fri, 01 May 2009 13:24:05 -0700 (PDT) In-Reply-To: <49FAB322.9030103@elischer.org> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> Date: Fri, 1 May 2009 16:24:05 -0400 Message-ID: <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> From: Zaphod Beeblebrox To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Christoph Mallon Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:48:48 -0000 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 =3D get_foo(); >>> if (!fp) return; >>> bp =3D fp->bp; >>> >>> this can't easily be translated to the more natural: >>> >>> struct foo *fp =3D get_foo(); >>> struct bar *bp =3D 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 =3D get_foo(); >>> if (!fp) return; >>> struct bar *bp =3D 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) >> =A76.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= . From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:55:18 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4721065714 for ; Fri, 1 May 2009 20:55:18 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 65C608FC12 for ; Fri, 1 May 2009 20:55:17 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 20:55:16 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp007) with SMTP; 01 May 2009 22:55:16 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19kllJQI2xkRsCdeaUQjM3uLMm6NlSqPh8WQpbunv bKsObBUsB3jjcU Message-ID: <49FB61B3.4090604@gmx.de> Date: Fri, 01 May 2009 22:55:15 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Daniel Eischen References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> <49FB5C57.6050407@gmx.de> <49FB5DB3.9030200@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: freebsd-hackers@freebsd.org, Zaphod Beeblebrox , Julian Elischer Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:55:19 -0000 Daniel Eischen schrieb: > +1 for leaving style(9) alone. Have you looked at all the proposed changes? I ask to consider them individually. Christoph From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 20:55:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEEEE1065831 for ; Fri, 1 May 2009 20:55:41 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1A2B98FC24 for ; Fri, 1 May 2009 20:55:40 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 20:55:40 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp024) with SMTP; 01 May 2009 22:55:40 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18ujs95Gx0uUq9aQyWB8xsGbpCSyVW8+7L3b6X/wr Su4dryMOk5Zu9P Message-ID: <49FB61CB.80906@gmx.de> Date: Fri, 01 May 2009 22:55:39 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Marius Strobl References: <49F4070C.2000108@gmx.de> <20090501112239.GA23199@alchemy.franken.de> <49FADEF3.5010106@gmx.de> <20090501121018.GC2943@alchemy.franken.de> In-Reply-To: <20090501121018.GC2943@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:55:42 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 21:01:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFA5106564A for ; Fri, 1 May 2009 21:01:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 644BC8FC1D for ; Fri, 1 May 2009 21:01:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n41L1oTD015907; Fri, 1 May 2009 17:01:50 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 01 May 2009 17:01:50 -0400 (EDT) Date: Fri, 1 May 2009 17:01:50 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Christoph Mallon In-Reply-To: <49FB61B3.4090604@gmx.de> Message-ID: References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <49FAB322.9030103@elischer.org> <5f67a8c40905011324s2ad5e02dy47c73ae950845b54@mail.gmail.com> <49FB5C57.6050407@gmx.de> <49FB5DB3.9030200@elischer.org> <49FB61B3.4090604@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Zaphod Beeblebrox , Julian Elischer Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:01:52 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 21:03:29 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9451065674 for ; Fri, 1 May 2009 21:03:29 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E10B78FC16 for ; Fri, 1 May 2009 21:03:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 May 2009 21:03:27 -0000 Received: from p54A3F073.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.240.115] by mail.gmx.net (mp056) with SMTP; 01 May 2009 23:03:27 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+ND+pFSluNt3eDUHeLiZxWyAMnEDFv5tRGqh252F u1/x5JpK7E/5y+ Message-ID: <49FB639E.9020401@gmx.de> Date: Fri, 01 May 2009 23:03:26 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> <49FA8D73.6040207@gmx.de> <20090501.080927.-1923761682.imp@bsdimp.com> In-Reply-To: <20090501.080927.-1923761682.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:03:29 -0000 M. Warner Losh schrieb: > In message: <49FA8D73.6040207@gmx.de> > Christoph Mallon writes: > : M. Warner Losh schrieb: > : > In message: <20090428114754.GB89235@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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 21:04:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E9A106568E for ; Fri, 1 May 2009 21:04:16 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id B82F38FC19 for ; Fri, 1 May 2009 21:04:15 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [193.205.82.7] (HELO gandalf.sssup.it) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 50442066 for freebsd-hackers@freebsd.org; Fri, 01 May 2009 21:56:28 +0200 Received: from smaug.retis (smaug.retis [10.30.3.72]) by gandalf.sssup.it (8.12.10/8.12.10) with ESMTP id n41K4Fxi023126 for ; Fri, 1 May 2009 22:04:15 +0200 Received: by smaug.retis (Postfix, from userid 1000) id D8603538C3; Fri, 1 May 2009 22:10:45 +0200 (CEST) Date: Fri, 1 May 2009 22:10:45 +0200 From: Fabio Checconi To: freebsd-hackers@freebsd.org Message-ID: <20090501201045.GA8738@gandalf.sssup.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: SoC2009: Geom-based Disk Schedulers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:04:17 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 21:39:49 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07581065674 for ; Fri, 1 May 2009 21:39:49 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 64F0F8FC33 for ; Fri, 1 May 2009 21:39:48 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so2532792ewy.43 for ; Fri, 01 May 2009 14:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=RTndoaBDlsxH0zxpuQbQM/Rsj3qKi8FoAMykZHgqGoo=; b=RFeSReD5bholiP+g4XYrhWpDyaRyyqimeFx07bpUtkZtMuQWjAvkSLuEh2viHJVKW+ qo3eP/E2FCoRpTk6evglD33O1YufelR3kMnU2+vUany9MnIDPy3VBQLfHPD+vpBjF/2h q08JHZiDCjsIq5a1irPUNq4zsPpzlfDQKxPJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=kXywa9yOw9C0rmOtHaWQQNf+hQdceba9YeF/XVx6ORKdRwCT+M2bee+HLEn9Z80ENB TAZD5WGOaD8ZN9X8I1JE1NrXByYpZtFybQ0xcMWcPKijeqL7vbo9Mwr7Tl9ZkjmMgF+9 iGdqQBGOo7jW9nQ2FcgkjJQxyk4NvAUBbPIe8= Received: by 10.210.82.13 with SMTP id f13mr54168ebb.24.1241213987302; Fri, 01 May 2009 14:39:47 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 25sm4468640ewy.119.2009.05.01.14.39.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 May 2009 14:39:46 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 4BE625C31; Fri, 1 May 2009 21:39:45 +0000 (UTC) Date: Fri, 1 May 2009 22:39:45 +0100 From: xorquewasp@googlemail.com To: Alexander Kabaev Message-ID: <20090501213945.GA87334@logik.internal.network> References: <20090501130536.GA95601@logik.internal.network> <20090501151308.5c9109da@kan.dnsalias.net> <20090501192113.GA15572@logik.internal.network> <20090501155038.692eb891@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090501155038.692eb891@kan.dnsalias.net> Cc: freebsd-hackers@freebsd.org Subject: Re: vfs_cache panic, 7.2-prerelease (stable) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:39:50 -0000 On 2009-05-01 15:50:38, Alexander Kabaev wrote: > On Fri, 1 May 2009 20:21:13 +0100 > xorquewasp@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 From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 02:32:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C22E710658C2 for ; Sat, 2 May 2009 02:32:43 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 471328FC14 for ; Sat, 2 May 2009 02:32:43 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1049389mue.3 for ; Fri, 01 May 2009 19:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rM/5FM8+mvWf3S+pzKmZKcd4wTPz8KoF9yIkWcd7I34=; b=PUHeJhoLIrYdmVeMmXTNxY0cOeZ8JqTAzhceeZPyvNTUHEaCSlpJDhc6rfw/uxkPbo qsr4H2vyB1V9hHr6u7/s6f1oI+RC/nf9lnEuWvblsAW7odfzdaHiyY/nSo3XSdhKnGhX Emn/ntIaXNOoVxq37OgL+XhuX4DIiVQ9CoNds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ubOutkfwnxa8kPx8Ddzy8xFUaC3uA/tVZctt+CiIQ1vGZatjP7Zu6vXwC/ZNeFupns GRY4oCQc95XMdJScFIucQHChgsTa3JlJ/tj2cwIQ1Y0Lwg5qhNhzBticzCOzU2YnUeHn LGvsOEUXrh0Vqo7c//YiLJ8T1bN/+O9GutoBo= Received: by 10.103.198.15 with SMTP id a15mr2024494muq.60.1241231562343; Fri, 01 May 2009 19:32:42 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id y2sm9703768mug.13.2009.05.01.19.32.41 (version=SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 19:32:41 -0700 (PDT) Message-ID: <49FBB147.4060305@gmail.com> Date: Sat, 02 May 2009 04:34:47 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <20090430233648.GA95360@keira.kiwi-computer.com> <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> In-Reply-To: <20090501.081229.1359784281.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 02:32:44 -0000 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?]. From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 02:38:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BB3106567F for ; Sat, 2 May 2009 02:38:17 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 38D758FC21 for ; Sat, 2 May 2009 02:38:16 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so137598fga.12 for ; Fri, 01 May 2009 19:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=4BC7XNv/bwQIkRcxn7i5ivEPZU+RTZABoO/49V6Hu2I=; b=W61fBIKItwtT/7wZgRdOXGNra/fvk1VjpepkwRXMlxuXjukSbIXsUSC721yfXmn1LO zhZ3OZstPYvLTICWIjjvHiePckjnnyA/IohRWYBgbEuAH8Q86eQJkp1wG6Z8llhWJRZY +322ealxfs6/gjpkQgnL8S0UszSFzYRmxUilc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=A+bDyhJ1zKnelRLm53uuwLzlIG3IloT8Bt+u8q4L9ipk8hi9+FEaNWhHlmGiLGIyWe IAt5xPOz/IhmIgz2rUiL6C0nBJQIEdUQfeFK1SD7D5/a/vs5B2TIZ25b6FYuo5oqBSPQ PSCxkXhdw2/BmI3deDBRPVSc5uQKBW6RHlVMc= Received: by 10.86.51.10 with SMTP id y10mr3457092fgy.9.1241231896210; Fri, 01 May 2009 19:38:16 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id e11sm1816683fga.11.2009.05.01.19.38.15 (version=SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 19:38:15 -0700 (PDT) Message-ID: <49FBB295.5030301@gmail.com> Date: Sat, 02 May 2009 04:40:21 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 02:38:17 -0000 Well I agree with the proposed changes. What about allowing // comments? From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 04:03:30 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5615B106564A for ; Sat, 2 May 2009 04:03:30 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (gw1.SetFilePointer.com [63.224.10.6]) by mx1.freebsd.org (Postfix) with SMTP id DE8C88FC08 for ; Sat, 2 May 2009 04:03:29 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 95396 invoked by uid 2001); 30 Apr 2009 23:36:48 -0000 Date: Thu, 30 Apr 2009 18:36:48 -0500 From: "Rick C. Petty" To: "M. Warner Losh" Message-ID: <20090430233648.GA95360@keira.kiwi-computer.com> References: <49F4070C.2000108@gmx.de> <20090428114754.GB89235@server.vk2pj.dyndns.org> <20090430.090226.1569754707.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090430.090226.1569754707.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 04:03:30 -0000 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 From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 07:27:56 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8319106566B for ; Sat, 2 May 2009 07:27:56 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1CF628FC15 for ; Sat, 2 May 2009 07:27:55 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 07:27:53 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp048) with SMTP; 02 May 2009 09:27:53 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19g9f5M7OxgmTbkWlL4Wu1QZ5hUtpSGzN8X/NFeH+ B6es1PDHWvfHK1 Message-ID: <49FBF5F7.7000600@gmx.de> Date: Sat, 02 May 2009 09:27:51 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090430.183727.803597558.imp@bsdimp.com> <49FA8E88.1040905@gmx.de> <20090501.081229.1359784281.imp@bsdimp.com> <20090501.083712.396385864.imp@bsdimp.com> In-Reply-To: <20090501.083712.396385864.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@FreeBSD.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:27:56 -0000 M. Warner Losh schrieb: > In message: <20090501.081229.1359784281.imp@bsdimp.com> > M. Warner Losh writes: > : In message: <49FA8E88.1040905@gmx.de> > : Christoph Mallon writes: > : : M. Warner Losh schrieb: > : : > In message: <20090430233648.GA95360@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..." There is hard data: For example look at r190098 and the following discussion, which you took part in. Obviously style(9) is too subtle at best or counterproductive at worst to achieve the desired goal. It is worrisome that somebody is inclined to obfuscate the code (in this case replacing multiple variables with descriptive names by a single variable with a generic name) because it is less hassle to conform to style(9) this way. I also have to object, that it leads to hunting for declarations. Actually it usually reduces scrolling around in the code: Many variables are only assigned once. A typical example is getting the softc of a device; especially there the type is important, because device_get_softc() returns void*. So it is very convenient to have this single assignment and its declaration at the same place. Not only the type of a variable is important, but also its value, so this assignment needs to be looked up, too. Doing declaration and initialisation at once you only have to look at one place instead of two. If you use vim as editor, then the current way makes it hard to find this assignment: "gd" jumps only to the declaration, the assignment is somewhere else. But if the declaration and the only assignment are the same, you get both at the same place and time. Even if there are multiple assignments, the first one often is a point of interest, e.g. int found = 0; followed by a search loop. Of course, if you abuse a variable in multiple contexts, then there are multiple "first" assignments and this coupling of declaration and first assignment gets lost. Therefore I am against re-using a variable in multiple contexts. In conclusion, I argue that declaring a variable right at its first (and often only) assignment does not lead to "spaghetti code" or "sloppy code", but in contrary makes the code more concise and easier to navigate. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 07:28:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84297106564A for ; Sat, 2 May 2009 07:28:37 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id C23758FC14 for ; Sat, 2 May 2009 07:28:36 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 07:28:35 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp026) with SMTP; 02 May 2009 09:28:35 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18Brol1nuIBrkwe5JLTixc6N2V4YSJVwLvxbXrLyH gJZA/ckaIe/Y0c Message-ID: <49FBF622.2050208@gmx.de> Date: Sat, 02 May 2009 09:28:34 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: deeptech71@gmail.com References: <49FBB295.5030301@gmail.com> In-Reply-To: <49FBB295.5030301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: freebsd-hackers@freebsd.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:28:37 -0000 deeptech71@gmail.com schrieb: > Well I agree with the proposed changes. > > What about allowing // comments? These are already widely used. grep shows hundreds of hits in sys/. Probably a clause should be added to style(9) to allow them "officially", but not right now. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 07:37:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D591065670; Sat, 2 May 2009 07:37:01 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 9CFCF8FC0C; Sat, 2 May 2009 07:37:00 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 2 May 2009 08:36:59 +0100 (BST) Date: Sat, 2 May 2009 08:36:58 +0100 From: David Malone To: Christoph Mallon Message-ID: <20090502073658.GA65633@walton.maths.tcd.ie> References: <49F4070C.2000108@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F4070C.2000108@gmx.de> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:37:02 -0000 FWIW, I'd rarely support changing style(9), unless it is actually causing people to write bad code. It's designed to produce consistent code, and changing it does not encourage consistency. > >-Do not put declarations > >-inside blocks unless the routine is unusually complicated. > >+Prefer declaring loop iterators in the for-statement to limit their scope. I usually don't like this style - I like being able to review the variables used in a function at the top. > >-When declaring variables in functions declare them sorted by size, > >-then in alphabetical order; multiple ones per line are okay. > >+When declaring variables in functions declare them sorted in alphabetical > >order; > >+prefer one declaration per line, especially when pointer declarators or > >+initializations are involved. The change to prefer one declaration per line seems like an unnecessary, except to better accomodate the declare-at-initialisation below. > >+Prefer initializing variables right at their declaration. While I buy your argument about scope, as I said, I prefer to see everything declared at the top. I don't think it outweighs the advantage of being able to look through the declarations. > >+When the value is not supposed to change in the function, make the > >variable > >+const. Using const seems sensible, and a good example of a time where declaring at initialisation makes sense. > >+This makes it easier for a reader to identify the where the value of a > >variable > >+originates. I'm not sure I buy this - the initialisation is unlikely to move in a piece of code, so it's as hard to find now as it was before. Editors supporting finding declarations should be able to find initialisations just as easily. (I'm old fashioned and do it via regexps.) Note that I also compile code from time to time to versions of FreeBSD that don't support C99. I understand that this will get more difficult over time, but mixing declarations and code is one of the things that I trip over that are just an annoying unnecessary change. For me it makes my life more difficult for a small gain. > >+Do not reuse the same variable in a different context, delare a new > >variable. I buy this largely - though it should be applied with common sense as usual. > >-Values in > >-.Ic return > >-statements should be enclosed in parentheses. > >-.Pp This is another change that isn't worth making - style(9) has had this rule for years and changing it because you don't think it adds anything isn't a good reason. > >-Use ANSI function declarations unless you explicitly need K&R > >compatibility. > >+Use ANSI function declarations. Seems reasonable for modern code - I guess it might be worth noting that when converting from K&R to ANSI changes should be made with care to avoid the sort problems you mention. > (It's a bug in GCC that it does not complain about the former.) I thought gcc had some magic glue to make functions with ANSI declarations and K&R definitions work. Bruce would know the details. > Empty line when there are no local variables: > Removed, because it does not improve readability and it actually hinders > readability for very short functions, e.g. static inline functions, > which just consist of one or two lines of code without any local > variables except for parameters. Further, it makes even less sense with > the changed recommendations for declarations. FWIW, I buy the empty line rule as a matter of consistency. A better reason for getting rid of it (IMHO) would be that it is one of the rules that is not so well followed by our existing code base. On balance I'd leave this rule here, because I don't think the changes to decalarations are good and because changing for no good reason produces less consistent code in the long run. (The example of very short static inline functions is probably a good one where no one would complain anyway if the code was missing the blank line. As always, style needs to be applied with good sense.) > 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. There is absolutely no need to reuse them in > different contexts. Trying to optimise stack usage in this way is > misguided and is a source of bugs, when a reused variable is not as dead > as thought. For more reasons, please read the quoted diff. > Maxim, you requested this paragraph: Does this addition suit you? This paragraph looks useful. If I were you I'd hook it in to the recommendation to not reuse the same variable in a different context. The only thing is that it reads a bit more like programming advice rather than style advice. I'd also suggest you run any changes by Bruce. David. From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 12:46:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5891A1065674 for ; Sat, 2 May 2009 12:46:53 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id E141F8FC18 for ; Sat, 2 May 2009 12:46:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1782542yxb.13 for ; Sat, 02 May 2009 05:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hLJW5AATvXNM48nW/9bm79sQMb7dAfcXdpy8OArrPxA=; b=jdqaIjZ175ca8wEVyBqx0VakXSeEKzzSkyBrKKskBUjBfF9++S3XPH/P69l2EDoRaA yDACJhKs6H4ss09ewxpZ+z3SS+kmelNMRy5AUuxFDrDsvhHxf7BqJkYh0onyajU6XBc4 KxItricenN1t8qqvqbnxJE5slLV5zb3CMbcnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oSkcvPn2CxZVH72HH7bPdXCGsWx4nHdYVCmdiHlVFRxCxb/xGrIr3965LLpcghETWj l8rxweFnDRt/G9ouRknKxCX9b8180X8F816AVWzO9EaGujh7/GG51sphNkhZjNxEhekL RH6qI3InjkElDI0BZkdAPxiTTuGAyrzV43qtE= MIME-Version: 1.0 Received: by 10.150.189.2 with SMTP id m2mr7853363ybf.38.1241268412046; Sat, 02 May 2009 05:46:52 -0700 (PDT) In-Reply-To: <20090430214520.GA37974@flint.openpave.org> References: <20090430214520.GA37974@flint.openpave.org> Date: Sat, 2 May 2009 05:46:52 -0700 Message-ID: <7d6fde3d0905020546s697ad5f6r2098ff6c80a80e1e@mail.gmail.com> From: Garrett Cooper To: Jeremy Lea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Forsythe , freebsd-hackers@freebsd.org, kientzle@freebsd.org Subject: Re: SoC2009: libpkg, pkg tools rewrite X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 12:46:54 -0000 On Thu, Apr 30, 2009 at 2:45 PM, Jeremy Lea wrote: > Hi, > > On Sat, Apr 25, 2009 at 03:20:59PM -0400, David Forsythe wrote: >> This summer I'll be working on creating a package library and using >> that library to rewrite the pkg tools. =A0A package library has been >> discussed and even started before, but FreeBSD still does not have >> one. =A0This summer I'd like to get enough of the library done to atle >> ast have a new set of pkg tools completed with the current features, >> but ideally I'd like to get far enough to splice in some of the ideas >> I have for new features. > > Since I've already done most of the work on this already, please, > please, please, don't ignore what I have done. =A0I know that it is not > perfect, and that it is now five plus years out of date. =A0But I have > covered half of the bullet points on your to-do list already. > > The code is at http://sourceforge.net/projects/fpkg and some README > stuff is at http://fpkg.sourceforge.net/ > > Some things which I think are critical: > > 1. The library needs a global "package manager". =A0This needs to perform > all of the tasks, and it should ideally do this through a task queue > (which I didn't implement). =A0See the lib/lib.h header in FreePKG. > > 2. The package manager must be able to separate out a structure of > variables which can be determined without opening the +CONTENTS file. > This must also include a package state, and the package manager must > move these package headers from state to state. > > 3. There needs to be proper depends handling in the packages, so that we > can maintain the correct dependency graph. =A0This is vital for upgrading= . > This means adding @libdep and @filedep types to the package file. > > 4. bsd.port.mk should do everything through the tools. =A0It should have > no knowledge of the contents of /var/db/pkg. > > These are all done, to some degree in the code. =A0The mistakes I made: > > 1. I made the file->pkg database to sensitive. =A0If there is a miss it > rebuilds the database for scratch - it should do a search through the > +CONTENTS files and only rebuild it if there was a hit (meaning the > database was wrong). > > 2. There needs to be a pkgname and origin database, which can be loaded > at startup to prime the package manager. =A0The dependency graph should > also be stored in a database. =A0These should be rebuilt if any directory > in /var/db/pkg has a mtime later than the database (so could the file > database). > > 3. There needs to be a set of flags which indicate how a package got > installed (as a dependency or by the user), and if it has been upgraded > in-place and might have old leftover libraries. =A0These could go in > +CONTENTS. > > In addition I also began the design of a new on disk package format. > This was back when there was a group called openpackages which was > trying to standardize ports/packages between the BSDs. =A0In particular i= t > has some ideas on package signing, which is an often requested feature. > > http://people.freebsd.org/~reg/opdesign.html > > Regards, > =A0-Jeremy There's also http://libpkg.berlios.de/ that you could use as a starting point, and please, PLEASE, don't neglect the SoC work that was done last year by Anders Nore. It was committed to p4, but hasn't made it upstream to CVS yet... Also, don't fall into the trap I fell into 2 years ago by trying to reinvent the wheel. Plenty of people have been down this road already, and can help you in finding your way if you ask. Best of luck, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 15:59:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCED71065670 for ; Sat, 2 May 2009 15:59:05 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CB34A8FC15 for ; Sat, 2 May 2009 15:59:04 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by bwz9 with SMTP id 9so2732171bwz.43 for ; Sat, 02 May 2009 08:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=d8JKvANX/38fYk25AKEzoiAQiYUgjMtrKfi++/6BURg=; b=MPjlREXBVYyo+tju3o3dxn2/0r19nKJs7s6OW4l/iZK3j3zINe+ALPBOOaNoGCA4EX NHiIEcgQedB6HwmS0Jn2wKvkZbQmbmRVULVntC50qcxJ4KlxRRO9fkTwM8RiAgHg6UhX PMbRyWMJJQ0Q1G8ViRbjgUzp9tUZIBXuqOwzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=uG1TxNvMLsSlcjfDHsDSpGFNzQabNF8zQ00cQUs56YQ7E9gBSNpFLZojkb6BVNseOg 6S263WaFWbC8heaiwj2a057A8STz3TU1yXz/9UHT1Ejq2lJORusubFOhEOI8IEAJFM6Q EWv8TV1KKZ56lsyGvv/yDQYS4xQ2wfzHZYBHg= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.223.116.72 with SMTP id l8mr1452901faq.33.1241279943677; Sat, 02 May 2009 08:59:03 -0700 (PDT) Date: Sat, 2 May 2009 16:59:03 +0100 X-Google-Sender-Auth: db136479a5ce41dd Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Definition of NULL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 15:59:06 -0000 I'm writing a C++ Kernel Module, and one thing that has been bugging me is the kernel's definition of NULL. sys/sys/_null.h (in CURRENT): #if defined(_KERNEL) || !defined(__cplusplus) #define NULL ((void *)0) #else #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 #define NULL __null #else #if defined(__LP64__) #define NULL (0L) #else #define NULL 0 #endif /* __LP64__ */ #endif /* __GNUG__ */ #endif /* _KERNEL || !__cplusplus */ >From what I've read online the definition of NULL in C is (void *)0, whereas in C++ it should be 0, or 0L (on 64bit machines). Now, my C++ kernel module is built with _KERNEL definited, like any other C kernel module. This leads to NULL being defined incorrectly. So I have a question and two suggestions. Firstly, why is the #if defined(_KERNEL) in _null.h? Is it to stop userland application applications picking up this definition? Or for another reason? and two, how about we change the first line of _null.h so that we use a && instead of a || like so: #if defined(_KERNEL) && !defined(__cplusplus) That should ensure the definition is correct. Or, a more radical approach, we could remove the check for _KERNEL, since I can't figure out why it is needed and do something like: #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 # define NULL __null #elif !defined(__cplusplus) # define NULL ((void *)0) #elif defined(__LP64__) # define NULL (0L) #else # define NULL 0 #endif That way, if we are using GCC 4+ we use their __null definition, otherwise if we are not c++ we use the standard (void *)0, and then if we are 64bit we use 0L, and finally anything else uses 0. A quick amd64 kernel compile seems to allow my new definition I hope this makes sense, and I welcome all feedback. Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 16:15:18 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852C51065676 for ; Sat, 2 May 2009 16:15:18 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E756F8FC16 for ; Sat, 2 May 2009 16:15:17 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 16:15:16 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp009) with SMTP; 02 May 2009 18:15:16 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18th/F4gyUtz7ePYLFZsM4YuvTWKVUqjFh2c5W38b HBtMXJU4eYapWu Message-ID: <49FC7193.40200@gmx.de> Date: Sat, 02 May 2009 18:15:15 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: David Malone References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> In-Reply-To: <20090502073658.GA65633@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:15:18 -0000 David Malone schrieb: >>> +When the value is not supposed to change in the function, make the >>> variable >>> +const. > > Using const seems sensible, and a good example of a time where > declaring at initialisation makes sense. > >>> +This makes it easier for a reader to identify the where the value of a >>> variable >>> +originates. > > I'm not sure I buy this - the initialisation is unlikely to move in > a piece of code, so it's as hard to find now as it was before. Editors > supporting finding declarations should be able to find initialisations > just as easily. (I'm old fashioned and do it via regexps.) But why not combine the benefits and find both at once in one place instead of of having an arbitrary amount of code between them? For example vim used "gd" to go to a local declaration. > Note that I also compile code from time to time to versions of > FreeBSD that don't support C99. I understand that this will get > more difficult over time, but mixing declarations and code is one > of the things that I trip over that are just an annoying unnecessary > change. For me it makes my life more difficult for a small gain. This is one thing, which I don't understand from the point of view of compiler construction: It is really simple to handle declarations, which are not at the beginning of a block. Other C99 features are way harder to implement. E.g. designator initialisers (bla bli = { .blub[23].gna = { 42, "narf" } };) require *way* more effort. In the C99 standard initialisation covers 3 pages followed by another 3 pages of examples - which are quite some explanations and a *lot* of examples compared to the other parts of the standard. >>> +Do not reuse the same variable in a different context, delare a new >>> variable. > > I buy this largely - though it should be applied with common sense > as usual. Of course, every rule has to be applied with common sense. >>> -Use ANSI function declarations unless you explicitly need K&R >>> compatibility. >>> +Use ANSI function declarations. > > Seems reasonable for modern code - I guess it might be worth noting > that when converting from K&R to ANSI changes should be made with > care to avoid the sort problems you mention. Removing the rule is in the first place about not adding any more old-style declarations. Removing the existing ones is a separate matter. rdivacky@ already did a good job at removing the defective declarations. >> (It's a bug in GCC that it does not complain about the former.) > > I thought gcc had some magic glue to make functions with ANSI > declarations and K&R definitions work. Bruce would know the details. The standard explains in detail, what are compatible declarations. ISO/IEC 9899:1999 (E) §6.7.5.3:15 handles compatible function types. GCC plain violates this. >> Empty line when there are no local variables: >> Removed, because it does not improve readability and it actually hinders >> readability for very short functions, e.g. static inline functions, >> which just consist of one or two lines of code without any local >> variables except for parameters. Further, it makes even less sense with >> the changed recommendations for declarations. > > FWIW, I buy the empty line rule as a matter of consistency. A better > reason for getting rid of it (IMHO) would be that it is one of the > rules that is not so well followed by our existing code base. On > balance I'd leave this rule here, because I don't think the changes > to decalarations are good and because changing for no good reason > produces less consistent code in the long run. Why leave it as it is? Just remove it, so no more of these empty lines are added. There is no need to remove the existing ones at once. Just slowly get rid of them. > (The example of very short static inline functions is probably a > good one where no one would complain anyway if the code was missing > the blank line. As always, style needs to be applied with good sense.) > >> 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. There is absolutely no need to reuse them in >> different contexts. Trying to optimise stack usage in this way is >> misguided and is a source of bugs, when a reused variable is not as dead >> as thought. For more reasons, please read the quoted diff. >> Maxim, you requested this paragraph: Does this addition suit you? > > This paragraph looks useful. If I were you I'd hook it in to the > recommendation to not reuse the same variable in a different context. It is rather long, so it should be kept separate. > The only thing is that it reads a bit more like programming advice > rather than style advice. It has two sides: On the one side it is easier for a reader to understand the data flow. On the other side if aliasing comes into play (taking the address of a variable), then it is also beneficial from the point of view of code generation to keep different contexts separate. My main concern is the reader of a piece of code. Better generated code is a nice side effect. It also shows that clarity for a reader and quality of the generated code nicely correlate here. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 16:30:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C04BD106566C for ; Sat, 2 May 2009 16:30:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6C78FC12 for ; Sat, 2 May 2009 16:30:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 109D9B994B; Sat, 2 May 2009 09:30:37 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EFC562D63ED; Sat, 2 May 2009 09:30:35 -0700 (PDT) Message-ID: <49FC752D.5080807@elischer.org> Date: Sat, 02 May 2009 09:30:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: David Malone References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> In-Reply-To: <20090502073658.GA65633@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , Christoph Mallon , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:30:38 -0000 David Malone wrote: > FWIW, I'd rarely support changing style(9), unless it is actually > causing people to write bad code. It's designed to produce consistent > code, and changing it does not encourage consistency. > >>> -Do not put declarations >>> -inside blocks unless the routine is unusually complicated. >>> +Prefer declaring loop iterators in the for-statement to limit their scope. > > I usually don't like this style - I like being able to review the > variables used in a function at the top. me too though I've softenned a bit regarding puting variables in blocks, I do NOT want to see variable declaration "not at the top of a block". > >>> -When declaring variables in functions declare them sorted by size, >>> -then in alphabetical order; multiple ones per line are okay. >>> +When declaring variables in functions declare them sorted in alphabetical >>> order; >>> +prefer one declaration per line, especially when pointer declarators or >>> +initializations are involved. > > The change to prefer one declaration per line seems like an unnecessary, > except to better accomodate the declare-at-initialisation below. the 'size' bit used to be to save space.. all the chars would be grouped together, etc. > >>> +Prefer initializing variables right at their declaration. > I have gone the other way on this. Unless 'const' is being used I find I prefer to see them separately initialized. > While I buy your argument about scope, as I said, I prefer to see > everything declared at the top. I don't think it outweighs the > advantage of being able to look through the declarations. > >>> +When the value is not supposed to change in the function, make the >>> variable >>> +const. > > Using const seems sensible, and a good example of a time where > declaring at initialisation makes sense. > >>> +This makes it easier for a reader to identify the where the value of a >>> variable >>> +originates. yeah.. at the top of the function.. > > I'm not sure I buy this - the initialisation is unlikely to move in > a piece of code, so it's as hard to find now as it was before. Editors > supporting finding declarations should be able to find initialisations > just as easily. (I'm old fashioned and do it via regexps.) > > Note that I also compile code from time to time to versions of > FreeBSD that don't support C99. I understand that this will get > more difficult over time, but mixing declarations and code is one > of the things that I trip over that are just an annoying unnecessary > change. For me it makes my life more difficult for a small gain. > >>> +Do not reuse the same variable in a different context, delare a new >>> variable. > > I buy this largely - though it should be applied with common sense > as usual. hmm. I think an exception might be made for our old friends i,j,k everyone knows them and what they are doing.. otherwise,yes this makes sense. > >>> -Values in >>> -.Ic return >>> -statements should be enclosed in parentheses. >>> -.Pp > > This is another change that isn't worth making - style(9) has had > this rule for years and changing it because you don't think it adds > anything isn't a good reason. > amen >>> -Use ANSI function declarations unless you explicitly need K&R >>> compatibility. >>> +Use ANSI function declarations. > Everyone shuld be doing that already. In new code, and in old code that they touch. > Seems reasonable for modern code - I guess it might be worth noting > that when converting from K&R to ANSI changes should be made with > care to avoid the sort problems you mention. > >> (It's a bug in GCC that it does not complain about the former.) > > I thought gcc had some magic glue to make functions with ANSI > declarations and K&R definitions work. Bruce would know the details. > >> Empty line when there are no local variables: >> Removed, because it does not improve readability and it actually hinders >> readability for very short functions, e.g. static inline functions, >> which just consist of one or two lines of code without any local >> variables except for parameters. Further, it makes even less sense with >> the changed recommendations for declarations. > > FWIW, I buy the empty line rule as a matter of consistency. A better > reason for getting rid of it (IMHO) would be that it is one of the > rules that is not so well followed by our existing code base. On > balance I'd leave this rule here, because I don't think the changes > to decalarations are good and because changing for no good reason > produces less consistent code in the long run. > > (The example of very short static inline functions is probably a > good one where no one would complain anyway if the code was missing > the blank line. As always, style needs to be applied with good sense.) > >> 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. There is absolutely no need to reuse them in >> different contexts. Trying to optimise stack usage in this way is >> misguided and is a source of bugs, when a reused variable is not as dead >> as thought. For more reasons, please read the quoted diff. >> Maxim, you requested this paragraph: Does this addition suit you? > > This paragraph looks useful. If I were you I'd hook it in to the > recommendation to not reuse the same variable in a different context. > The only thing is that it reads a bit more like programming advice > rather than style advice. > > I'd also suggest you run any changes by Bruce. > > David. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 16:50:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9BE106566B for ; Sat, 2 May 2009 16:50:52 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2438FC26 for ; Sat, 2 May 2009 16:50:51 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:50818 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1M0IBe-00067F-4b for freebsd-hackers@freebsd.org; Sat, 02 May 2009 18:35:40 +0200 Received: (qmail 29888 invoked from network); 2 May 2009 18:35:35 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 May 2009 18:35:35 +0200 Received: (qmail 17087 invoked by uid 1001); 2 May 2009 18:35:35 +0200 Date: Sat, 2 May 2009 18:35:35 +0200 From: Erik Trulsson To: Andrew Brampton Message-ID: <20090502163535.GA17027@owl.midgard.homeip.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1M0IBe-00067F-4b. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1M0IBe-00067F-4b 5b478a627850c02c1b8e9d6a3f3afa1f Cc: freebsd-hackers@freebsd.org Subject: Re: Definition of NULL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:50:53 -0000 On Sat, May 02, 2009 at 04:59:03PM +0100, Andrew Brampton wrote: > I'm writing a C++ Kernel Module, and one thing that has been bugging > me is the kernel's definition of NULL. Is the use of C++ inside the kernel really supported? I don't think so, but I could be wrong. > > sys/sys/_null.h (in CURRENT): > > #if defined(_KERNEL) || !defined(__cplusplus) > #define NULL ((void *)0) > #else > #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 > #define NULL __null > #else > #if defined(__LP64__) > #define NULL (0L) > #else > #define NULL 0 > #endif /* __LP64__ */ > #endif /* __GNUG__ */ > #endif /* _KERNEL || !__cplusplus */ > > >From what I've read online the definition of NULL in C is (void *)0, > whereas in C++ it should be 0, or 0L (on 64bit machines). Not quite. Any of those (as well as a whole bunch more) are legal definitions of NULL in C. NULL is defined (in the C standard) to be a null pointer constant. A null pointer constant is defined as a constant integer expression with value zero, or such an expression cast to (void*). (In C++ it the cast to (void*) is not allowed.) This means that it would be perfectly legal (but of dubious utility) to have NULL defined as (5*5L+('1'-'0')-26) for example. The decision to define NULL as 0 or 0L or ((void*)0) is pretty much just a question of which buggy programs one wishes to break, or hide the bugs in. A correct C program should work regardless of which of those is used. > > Now, my C++ kernel module is built with _KERNEL definited, like any > other C kernel module. This leads to NULL being defined incorrectly. > > So I have a question and two suggestions. Firstly, why is the #if > defined(_KERNEL) in _null.h? Is it to stop userland application > applications picking up this definition? Or for another reason? Perhaps to stop people from mistakenly using C++ inside the kernel? > > and two, how about we change the first line of _null.h so that we use > a && instead of a || like so: > #if defined(_KERNEL) && !defined(__cplusplus) > > That should ensure the definition is correct. Or, a more radical > approach, we could remove the check for _KERNEL, since I can't figure > out why it is needed and do something like: > > #if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4 > # define NULL __null > #elif !defined(__cplusplus) > # define NULL ((void *)0) > #elif defined(__LP64__) > # define NULL (0L) > #else > # define NULL 0 > #endif > > That way, if we are using GCC 4+ we use their __null definition, > otherwise if we are not c++ we use the standard (void *)0, and then if > we are 64bit we use 0L, and finally anything else uses 0. A quick > amd64 kernel compile seems to allow my new definition If you want to keep things simple you could just define NULL as 0 everywhere, and see what bugs are exposed that way. > > I hope this makes sense, and I welcome all feedback. > Andrew -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 16:52:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 832921065715 for ; Sat, 2 May 2009 16:52:40 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-fx0-f162.google.com (mail-fx0-f162.google.com [209.85.220.162]) by mx1.freebsd.org (Postfix) with ESMTP id 086A48FC08 for ; Sat, 2 May 2009 16:52:34 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by fxm6 with SMTP id 6so2795902fxm.43 for ; Sat, 02 May 2009 09:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3SMHgXvwAI8CCEVuaYQiELw/mUUNnV0O2BxShBMakXc=; b=Bhfx6dw85oekn8+fSlbfbZduAxRBphScZcYBg8In9X44J1rQQXOyNm+rt6VZT/eG1i En+2DcTMKuS8OtfJq4nCLIFV/bbleN34mPYvRVhmav4LUZ4tVcTpdPQUnB/JoPLiVtNQ AgS3CDlSqG1DXRZcKWz4Kfn/fMLwhjpZWIx/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LonxkTVlZV7KpH/NuxiweuW9fv67UokChWIyAPXacNqrEh27IVMIqLS8DmQ2V0GGHJ BmSk6PH0cymZDSMYs1mJoRRalrQmMOpFtvUDXTar03tjlFeHAauA+8hyNm1f5VbLD7WM avSDZYl3hy+moQ2G8yedbTv99w7TLWmxAs+oI= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.223.126.69 with SMTP id b5mr1416949fas.54.1241283153704; Sat, 02 May 2009 09:52:33 -0700 (PDT) In-Reply-To: <20090502163535.GA17027@owl.midgard.homeip.net> References: <20090502163535.GA17027@owl.midgard.homeip.net> Date: Sat, 2 May 2009 17:52:33 +0100 X-Google-Sender-Auth: 138b7ed3b5492a08 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Definition of NULL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:52:41 -0000 2009/5/2 Erik Trulsson : > On Sat, May 02, 2009 at 04:59:03PM +0100, Andrew Brampton wrote: >> I'm writing a C++ Kernel Module, and one thing that has been bugging >> me is the kernel's definition of NULL. > > Is the use of C++ inside the kernel really supported? =C2=A0I don't think= so, > but I could be wrong. There are a few projects (other than mine) which uses C++ inside the kernel, the biggest being the Click modular router. So, with minimal effort and no kernel patches it is easy to build a C++ kernel module, thus I must assume it is supported even if it is unofficial. The question of if C++ is sensible inside the kernel is left for another day, and perhaps has been answered in numerous other freebsd-hackers@ threads. >> >From what I've read online the definition of NULL in C is (void *)0, >> whereas in C++ it should be 0, or 0L (on 64bit machines). > > Not quite. =C2=A0Any of those (as well as a whole bunch more) are legal > definitions of NULL in C. =C2=A0NULL is defined (in the C standard) to be= a null > pointer constant. =C2=A0A null pointer constant is defined as a constant = integer > expression with value zero, or such an expression cast to (void*). (In C+= + > it the cast to (void*) is not allowed.) > This means that it would be perfectly legal (but of dubious utility) to h= ave > NULL defined as (5*5L+('1'-'0')-26) for example. > > The decision to define NULL as 0 or 0L or ((void*)0) is pretty much just = a > question of which buggy programs one wishes to break, or hide the bugs in= . > A correct C program should work regardless of which of those is used. Thanks for the additional information. > > >> >> Now, my C++ kernel module is built with _KERNEL definited, like any >> other C kernel module. This leads to NULL being defined incorrectly. >> >> So I have a question and two suggestions. Firstly, why is the #if >> defined(_KERNEL) in _null.h? Is it to stop userland application >> applications picking up this definition? Or for another reason? > > Perhaps to stop people from mistakenly using C++ inside the kernel? The definition doesn't stop C++, it just generates additional warnings and sometimes errors. I have avoided those warning by defining NULL myself, however, I thought changing it in _null.h might help others, even if you think they are mistakenly using C++. > > ... > > Erik Trulsson > ertr1013@student.uu.se > Thanks for your input. Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:08:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D031065674; Sat, 2 May 2009 17:08:35 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 786558FC13; Sat, 2 May 2009 17:08:34 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 2 May 2009 18:08:32 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 2 May 2009 17:38:24 +0100 (BST) To: Christoph Mallon In-reply-to: Your message of "Sat, 02 May 2009 18:15:15 +0200." <49FC7193.40200@gmx.de> X-Request-Do: Date: Sat, 02 May 2009 17:38:24 +0100 From: David Malone Message-ID: <200905021738.aa71693@walton.maths.tcd.ie> Cc: FreeBSD Hackers , Roman Divacky , Ed Schouten , Warner Losh , Maxim Sobolev Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:08:36 -0000 > > I'm not sure I buy this - the initialisation is unlikely to move in > > a piece of code, so it's as hard to find now as it was before. Editors > > supporting finding declarations should be able to find initialisations > > just as easily. (I'm old fashioned and do it via regexps.) > But why not combine the benefits and find both at once in one place > instead of of having an arbitrary amount of code between them? For > example vim used "gd" to go to a local declaration. As I said, I like having all the declarations in one place so I can review all of them as a unit. I find it helps me understand the function. You can never have all the initialisations in one place, because they may depend on complicated code, so I accept that I have to search for initialisations. > > Note that I also compile code from time to time to versions of > > FreeBSD that don't support C99. I understand that this will get > > more difficult over time, but mixing declarations and code is one > > of the things that I trip over that are just an annoying unnecessary > > change. For me it makes my life more difficult for a small gain. > This is one thing, which I don't understand from the point of view of > compiler construction: It is really simple to handle declarations, which > are not at the beginning of a block. Other C99 features are way harder > to implement. E.g. designator initialisers (bla bli = { .blub[23].gna = > { 42, "narf" } };) require *way* more effort. In the C99 standard > initialisation covers 3 pages followed by another 3 pages of examples - > which are quite some explanations and a *lot* of examples compared to > the other parts of the standard. True - but that's the compilers that I have to work with. I've tripped over other C99 features considerably less often for some reason. > > Seems reasonable for modern code - I guess it might be worth noting > > that when converting from K&R to ANSI changes should be made with > > care to avoid the sort problems you mention. > Removing the rule is in the first place about not adding any more > old-style declarations. Removing the existing ones is a separate matter. > rdivacky@ already did a good job at removing the defective declarations. Indeed! > > FWIW, I buy the empty line rule as a matter of consistency. A better > > reason for getting rid of it (IMHO) would be that it is one of the > > rules that is not so well followed by our existing code base. On > > balance I'd leave this rule here, because I don't think the changes > > to decalarations are good and because changing for no good reason > > produces less consistent code in the long run. > Why leave it as it is? Just remove it, so no more of these empty lines > are added. There is no need to remove the existing ones at once. Just > slowly get rid of them. As I said, the point of a style guide is consistency. Changing it doesn't promote consistency, so there needs to be a good reason for the change, rather than a good reason not to change. In my opinion, there isn't a strong reason. Similarly for parens around return values - there's nothing (substantial) wrong with either rule, so they should probably be left as-is. > > This paragraph looks useful. If I were you I'd hook it in to the > > recommendation to not reuse the same variable in a different context. > It is rather long, so it should be kept separate. Maybe include a forward ref then, to say the rational is explained in a later section? David. From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:40:07 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936291065673 for ; Sat, 2 May 2009 17:40:07 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 131528FC15 for ; Sat, 2 May 2009 17:40:06 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 17:40:05 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp036) with SMTP; 02 May 2009 19:40:05 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+xBstqmG+xEpHktQ6ORYM7K8DEkmdL68vJX4a4Qv EPdC/xp/B7xtZh Message-ID: <49FC8574.5060205@gmx.de> Date: Sat, 02 May 2009 19:40:04 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> In-Reply-To: <49FC752D.5080807@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:40:08 -0000 Julian Elischer schrieb: > David Malone wrote: >>>> -Do not put declarations >>>> -inside blocks unless the routine is unusually complicated. >>>> +Prefer declaring loop iterators in the for-statement to limit their >>>> scope. >> >> I usually don't like this style - I like being able to review the >> variables used in a function at the top. > > me too > though I've softenned a bit regarding puting variables in blocks, > I do NOT want to see variable declaration "not at the top of a block". I find this kind of strange, because this in-beetwen makes least sense to me: Neither are all declarations grouped together nor are declarations nicely connected to their initialisation and their scope is minimal. >>>> -When declaring variables in functions declare them sorted by size, >>>> -then in alphabetical order; multiple ones per line are okay. >>>> +When declaring variables in functions declare them sorted in >>>> alphabetical order; >>>> +prefer one declaration per line, especially when pointer >>>> declarators or +initializations are involved. >> >> The change to prefer one declaration per line seems like an unnecessary, >> except to better accomodate the declare-at-initialisation below. > > the 'size' bit used to be to save space.. all the chars > would be grouped together, etc. Today's compilers plain do not care in which order you declare variables. Sorting them in a beneficial way for space efficiency is better left to them (and it is a rather trivial thing to do). Also you cannot control if more spill slots have to be inserted or some values do not live in memory at all, so only the compiler can determine, which order is best. But a compiler can do more: It could coalesce the space of variables with disjoint life ranges. But this is much harder, because you have to properly determine the life ranges. Finding an arbitrary overestimation is easy, but the fun starts when looking at called functions, which get passed addresses of local variables. Also finding an optimal coalescence for known life ranges is NP-complete in the general case. But that's another story. (: >>>> +Prefer initializing variables right at their declaration. >> > > I have gone the other way on this. Unless 'const' is being used I find > I prefer to see them separately initialized. So you like hunting in multiple places instead of having both type and value conveniently in one place? >>>> +This makes it easier for a reader to identify the where the value >>>> of a variable >>>> +originates. > > yeah.. at the top of the function.. Currently only the *declaration* is at the top of the function. This bears absolutely no relation to where the *value* originates. >>>> +Do not reuse the same variable in a different context, delare a new >>>> variable. >> >> I buy this largely - though it should be applied with common sense >> as usual. > > hmm. I think an exception might be made for our old friends i,j,k Especially they should be declared right where they are needed. C99 even conveniently allows the iterator variable to be declared in the first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By limiting their scope, this prevents accidently re-using stale values in a different place or other mistakes like the following: int i, j; for (i = 0;; ++i) { for (i = 0;; ++i) { /* oops, but compiler is happy */ } } for (j = 0;; ++j) { /* more */ } vs. for (int i = 0;; ++i) { for (int i = 0;; ++i) { /* warning about shadowed variable */ } } for (int j = 0;; ++j) { /* more */ } > everyone knows them and what they are doing.. otherwise,yes this makes > sense. > >> >>>> -Values in >>>> -.Ic return >>>> -statements should be enclosed in parentheses. >>>> -.Pp >> >> This is another change that isn't worth making - style(9) has had >> this rule for years and changing it because you don't think it adds >> anything isn't a good reason. >> > > amen This is no church. I presented reasons, I do not want beliefs in return. Also stating that it should not be changed because it was always this way is a very slippery slope. >>>> -Use ANSI function declarations unless you explicitly need K&R >>>> compatibility. >>>> +Use ANSI function declarations. >> > > Everyone shuld be doing that already. > In new code, and in old code that they touch. So, is this pro or contra removing the K&R-clause? Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:40:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305C91065711 for ; Sat, 2 May 2009 17:40:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA628FC2B for ; Sat, 2 May 2009 17:40:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A71D42366; Sat, 2 May 2009 10:40:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A42582D62C0; Sat, 2 May 2009 10:40:40 -0700 (PDT) Message-ID: <49FC859B.20906@elischer.org> Date: Sat, 02 May 2009 10:40:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: David Malone References: <200905021738.aa71693@walton.maths.tcd.ie> In-Reply-To: <200905021738.aa71693@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , Christoph Mallon , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:40:44 -0000 David Malone wrote: > > As I said, the point of a style guide is consistency. Changing it > doesn't promote consistency, so there needs to be a good reason for > the change, rather than a good reason not to change. In my opinion, > there isn't a strong reason. Similarly for parens around return > values - there's nothing (substantial) wrong with either rule, so > they should probably be left as-is. Many of the previous changes to style(9) came from cases where the existing rules led to programmers increasing their chances of making errors, or people found themselves often misinterpreting code in the same way, over and over again. Changing them to bring them closer to someone's personal style has never been an acceptable reason. There is a barrier to entry that any change must overcome which is "It will decrease code consistency (by definition) so it it worth it?" . "parens on return statements is an example.. there are some posibilities as to what one can do with this, but I really do find that the parens are part of the style that I'd notice as inconsistent. > From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 17:55:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03EB7106567F for ; Sat, 2 May 2009 17:55:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id D5B7A8FC1F for ; Sat, 2 May 2009 17:55:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8DB0F961DC; Sat, 2 May 2009 10:55:42 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id A2AF92D6115; Sat, 2 May 2009 10:55:41 -0700 (PDT) Message-ID: <49FC8920.6050408@elischer.org> Date: Sat, 02 May 2009 10:55:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> In-Reply-To: <49FC8574.5060205@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 17:55:43 -0000 Christoph Mallon wrote: > Julian Elischer schrieb: >> David Malone wrote: >>>>> -Do not put declarations >>>>> -inside blocks unless the routine is unusually complicated. >>>>> +Prefer declaring loop iterators in the for-statement to limit >>>>> their scope. >>> >>> I usually don't like this style - I like being able to review the >>> variables used in a function at the top. >> >> me too >> though I've softenned a bit regarding puting variables in blocks, >> I do NOT want to see variable declaration "not at the top of a block". > > I find this kind of strange, because this in-beetwen makes least sense > to me: Neither are all declarations grouped together nor are > declarations nicely connected to their initialisation and their scope is > minimal. I only have to look just after the enclosing "{" I actually prefer to see them all at the top but as I said I have seen cases where having them elsewhere makes sense. > >>>>> -When declaring variables in functions declare them sorted by size, >>>>> -then in alphabetical order; multiple ones per line are okay. >>>>> +When declaring variables in functions declare them sorted in >>>>> alphabetical order; >>>>> +prefer one declaration per line, especially when pointer >>>>> declarators or +initializations are involved. >>> >>> The change to prefer one declaration per line seems like an unnecessary, >>> except to better accomodate the declare-at-initialisation below. >> >> the 'size' bit used to be to save space.. all the chars >> would be grouped together, etc. > > Today's compilers plain do not care in which order you declare I said "used to" > variables. Sorting them in a beneficial way for space efficiency is > better left to them (and it is a rather trivial thing to do). Also you > cannot control if more spill slots have to be inserted or some values do > not live in memory at all, so only the compiler can determine, which > order is best. > But a compiler can do more: It could coalesce the space of variables > with disjoint life ranges. But this is much harder, because you have to > properly determine the life ranges. Finding an arbitrary overestimation > is easy, but the fun starts when looking at called functions, which get > passed addresses of local variables. Also finding an optimal coalescence > for known life ranges is NP-complete in the general case. But that's > another story. (: re-using space or having block-local variables means that when you are in the debugger, you can not look at the final value that a variable had when you left (unexpectedly) the block. This can be a pain in the neck. (but only a debugging feature) > >>>>> +Prefer initializing variables right at their declaration. >>> >> >> I have gone the other way on this. Unless 'const' is being used I >> find I prefer to see them separately initialized. > > So you like hunting in multiple places instead of having both type and > value conveniently in one place? Actually.. yes unconditional initialization is right at the top, AFTER the blank line. Conditional initialization must of course come after the condition, and can not be in the same line as the declaration anyhow. > >>>>> +This makes it easier for a reader to identify the where the value >>>>> of a variable >>>>> +originates. >> >> yeah.. at the top of the function.. > > Currently only the *declaration* is at the top of the function. This > bears absolutely no relation to where the *value* originates. As I said.. unconditional values originate just after that, at the top. :-) > >>>>> +Do not reuse the same variable in a different context, delare a >>>>> new variable. >>> >>> I buy this largely - though it should be applied with common sense >>> as usual. >> >> hmm. I think an exception might be made for our old friends i,j,k > > Especially they should be declared right where they are needed. C99 even > conveniently allows the iterator variable to be declared in the first > part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By limiting > their scope, this prevents accidently re-using stale values in a > different place or other mistakes like the following: > int i, j; > for (i = 0;; ++i) { > for (i = 0;; ++i) { > /* oops, but compiler is happy */ > } > } > for (j = 0;; ++j) { > /* more */ > } > vs. > for (int i = 0;; ++i) { > for (int i = 0;; ++i) { > /* warning about shadowed variable */ > } > } > for (int j = 0;; ++j) { > /* more */ > } while tempting, I can't see that hapenning.. it stops teh following: for (;;) { blah if (foo) break; } if (i == end_condition) { then we didn't break out; } > >> everyone knows them and what they are doing.. otherwise,yes this makes >> sense. >> >>> >>>>> -Values in >>>>> -.Ic return >>>>> -statements should be enclosed in parentheses. >>>>> -.Pp >>> >>> This is another change that isn't worth making - style(9) has had >>> this rule for years and changing it because you don't think it adds >>> anything isn't a good reason. >>> >> >> amen > > This is no church. I presented reasons, I do not want beliefs in return. > Also stating that it should not be changed because it was always this > way is a very slippery slope. > >>>>> -Use ANSI function declarations unless you explicitly need K&R >>>>> compatibility. >>>>> +Use ANSI function declarations. >>> >> >> Everyone shuld be doing that already. >> In new code, and in old code that they touch. > > So, is this pro or contra removing the K&R-clause? K&R code should be changed as part of related changes if possible. A sweep to change a whole file is probably also ok. changing them one at a time is probably not ok. > > Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 18:19:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B757E1065678 for ; Sat, 2 May 2009 18:19:02 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E94078FC1C for ; Sat, 2 May 2009 18:19:01 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 18:18:59 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp006) with SMTP; 02 May 2009 20:18:59 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18P8bRKzukPjbnhb/ln+e9xpOvDsskFcb3SE7rruY ACtdgQp5OgfVWS Message-ID: <49FC8E92.1090207@gmx.de> Date: Sat, 02 May 2009 20:18:58 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> In-Reply-To: <49FC8920.6050408@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 18:19:03 -0000 Julian Elischer schrieb: > Christoph Mallon wrote: >> variables. Sorting them in a beneficial way for space efficiency is >> better left to them (and it is a rather trivial thing to do). Also you >> cannot control if more spill slots have to be inserted or some values >> do not live in memory at all, so only the compiler can determine, >> which order is best. >> But a compiler can do more: It could coalesce the space of variables >> with disjoint life ranges. But this is much harder, because you have >> to properly determine the life ranges. Finding an arbitrary >> overestimation is easy, but the fun starts when looking at called >> functions, which get passed addresses of local variables. Also finding >> an optimal coalescence for known life ranges is NP-complete in the >> general case. But that's another story. (: > > re-using space or having block-local variables means that when you > are in the debugger, you can not look at the final value that > a variable had when you left (unexpectedly) the block. This can > be a pain in the neck. (but only a debugging feature) I'm talking about an optimized build - no matter what the style of the original source was, you will have a hard time debugging it. >>>>>> +Prefer initializing variables right at their declaration. >>>> >>> >>> I have gone the other way on this. Unless 'const' is being used I >>> find I prefer to see them separately initialized. >> >> So you like hunting in multiple places instead of having both type and >> value conveniently in one place? > > Actually.. yes So at the one hand you argue that hunting things is bad, but at the same time you prefer it? I am confused. > unconditional initialization is right at the top, AFTER the blank line. > Conditional initialization must of course come after the condition, and > can not be in the same line as the declaration anyhow. It is perfectly valid to do so. Warner presented a simple example. You just have to limit the scope of the variable, which is a good for other reasons, which were explained, too. >>>>>> +Do not reuse the same variable in a different context, delare a >>>>>> new variable. >>>> >>>> I buy this largely - though it should be applied with common sense >>>> as usual. >>> >>> hmm. I think an exception might be made for our old friends i,j,k >> >> Especially they should be declared right where they are needed. C99 >> even conveniently allows the iterator variable to be declared in the >> first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By >> limiting their scope, this prevents accidently re-using stale values >> in a different place or other mistakes like the following: >> int i, j; >> for (i = 0;; ++i) { >> for (i = 0;; ++i) { >> /* oops, but compiler is happy */ >> } >> } >> for (j = 0;; ++j) { >> /* more */ >> } >> vs. >> for (int i = 0;; ++i) { >> for (int i = 0;; ++i) { >> /* warning about shadowed variable */ >> } >> } >> for (int j = 0;; ++j) { >> /* more */ >> } > > while tempting, I can't see that hapenning.. > > it stops teh following: > > > for (;;) { > blah > if (foo) > break; > } > if (i == end_condition) { > then we didn't break out; > } You reject a common case because of one special case? This is sad. (Also there are multiple ways to resolve this nicely, e.g. split the loop into a function or invert the condition and restructure the code slightly) >>>>>> -Use ANSI function declarations unless you explicitly need K&R >>>>>> compatibility. >>>>>> +Use ANSI function declarations. >>>> >>> >>> Everyone shuld be doing that already. >>> In new code, and in old code that they touch. >> >> So, is this pro or contra removing the K&R-clause? > > K&R code should be changed as part of related changes if possible. > A sweep to change a whole file is probably also ok. > changing them one at a time is probably not ok. But this is what actually is practiced. You still did not answer my question: Do you agree to remove the clause so no new old style declarations may be added? Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 18:30:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FFE81065678 for ; Sat, 2 May 2009 18:30:57 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 94D608FC13 for ; Sat, 2 May 2009 18:30:56 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 18:30:55 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp013) with SMTP; 02 May 2009 20:30:55 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+7EPA0CrS77DLDhipm9Rv/995A3CQ7iybhIWSl6P /bWuzbbOTDXUbh Message-ID: <49FC915E.4050006@gmx.de> Date: Sat, 02 May 2009 20:30:54 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <200905021738.aa71693@walton.maths.tcd.ie> <49FC859B.20906@elischer.org> In-Reply-To: <49FC859B.20906@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 18:30:57 -0000 Julian Elischer schrieb: > David Malone wrote: >> As I said, the point of a style guide is consistency. Changing it >> doesn't promote consistency, so there needs to be a good reason for >> the change, rather than a good reason not to change. In my opinion, >> there isn't a strong reason. Similarly for parens around return >> values - there's nothing (substantial) wrong with either rule, so >> they should probably be left as-is. > > Many of the previous changes to style(9) came from cases where > the existing rules led to programmers increasing their chances > of making errors, or people found themselves often misinterpreting > code in the same way, over and over again. Changing them to bring > them closer to someone's personal style has never been an acceptable > reason. There is a barrier to entry that any change must overcome > which is "It will decrease code consistency (by definition) so > it it worth it?" . For every proposed changed, I presented comprehensible reasons why I propose it. I never used "because I like it" as a pseudo-reason. Yes, these changes reflect my personal preferences, but they are my preferences for a reason and I try really hard to convey these reasons. > "parens on return statements is an example.. there are some posibilities > as to what one can do with this, but I really do find that the parens > are part of the style that I'd notice as inconsistent. What does this mean in one simple sentence? Should the clause be removed so they may not be added anymore? Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 19:05:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC19C1065675 for ; Sat, 2 May 2009 19:05:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4C18FC15 for ; Sat, 2 May 2009 19:05:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C0825B98A1; Sat, 2 May 2009 12:05:42 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2E65F2D604D; Sat, 2 May 2009 12:05:42 -0700 (PDT) Message-ID: <49FC9988.2070306@elischer.org> Date: Sat, 02 May 2009 12:05:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> In-Reply-To: <49FC8E92.1090207@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:05:44 -0000 Christoph Mallon wrote: > > I'm talking about an optimized build - no matter what the style of the > original source was, you will have a hard time debugging it. but by removing -Ox I can debug it and you can't From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 19:07:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D57106568C for ; Sat, 2 May 2009 19:07:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 83E498FC14 for ; Sat, 2 May 2009 19:07:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4A3D422C2; Sat, 2 May 2009 12:07:44 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id AA3C62D62B4; Sat, 2 May 2009 12:07:43 -0700 (PDT) Message-ID: <49FC9A02.6080901@elischer.org> Date: Sat, 02 May 2009 12:07:46 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> In-Reply-To: <49FC8E92.1090207@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:07:46 -0000 Christoph Mallon wrote: > Julian Elischer schrieb: >> Christoph Mallon wrote: > > So at the one hand you argue that hunting things is bad, but at the same > time you prefer it? I am confused. well, I won't hold your problems against you.. :-) From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 19:38:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E33106566C for ; Sat, 2 May 2009 19:38:51 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id C40DF8FC13 for ; Sat, 2 May 2009 19:38:50 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 19:38:49 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp012) with SMTP; 02 May 2009 21:38:49 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+4yb4SfMy4veX2x6Fbz/Og8cXhTS//eTA7yqJd1d F1JYufEdSowzPi Message-ID: <49FCA148.9060707@gmx.de> Date: Sat, 02 May 2009 21:38:48 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> <49FC9A02.6080901@elischer.org> In-Reply-To: <49FC9A02.6080901@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:38:51 -0000 Julian Elischer schrieb: > Christoph Mallon wrote: >> Julian Elischer schrieb: >>> Christoph Mallon wrote: > >> >> So at the one hand you argue that hunting things is bad, but at the >> same time you prefer it? I am confused. > > well, I won't hold your problems against you.. :-) It is sad that you are just toying around instead of answering a simple question: Christoph Mallon wrote: >> K&R code should be changed as part of related changes if possible. >> A sweep to change a whole file is probably also ok. >> changing them one at a time is probably not ok. > > But this is what actually is practiced. > You still did not answer my question: Do you agree to remove the clause so no new old style declarations may be added? From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 19:39:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 714DC1065674 for ; Sat, 2 May 2009 19:39:59 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B111E8FC1C for ; Sat, 2 May 2009 19:39:58 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 19:39:56 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp040) with SMTP; 02 May 2009 21:39:56 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+hAhEB2y+hXre3W6zyWlwe52HV0Y/05HJufEHogn FInefICnHq+k1n Message-ID: <49FCA18B.6060502@gmx.de> Date: Sat, 02 May 2009 21:39:55 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> <49FC9988.2070306@elischer.org> In-Reply-To: <49FC9988.2070306@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:39:59 -0000 Julian Elischer schrieb: > Christoph Mallon wrote: >> I'm talking about an optimized build - no matter what the style of the >> original source was, you will have a hard time debugging it. > > but by removing -Ox I can debug it and you can't Declaring variables earlier does not magically fill meaningful values into them any earlier. Christoph From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 20:16:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45012106566C for ; Sat, 2 May 2009 20:16:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 23F9C8FC08 for ; Sat, 2 May 2009 20:16:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id F14559751C; Sat, 2 May 2009 13:16:26 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 648632D6385; Sat, 2 May 2009 13:16:26 -0700 (PDT) Message-ID: <49FCAA1D.1080208@elischer.org> Date: Sat, 02 May 2009 13:16:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christoph Mallon References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> <49FC9A02.6080901@elischer.org> <49FCA148.9060707@gmx.de> In-Reply-To: <49FCA148.9060707@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 20:16:27 -0000 Christoph Mallon wrote: > Julian Elischer schrieb: >> Christoph Mallon wrote: >>> Julian Elischer schrieb: >>>> Christoph Mallon wrote: >> >>> >>> So at the one hand you argue that hunting things is bad, but at the >>> same time you prefer it? I am confused. >> >> well, I won't hold your problems against you.. :-) > > It is sad that you are just toying around instead of answering a simple > question: > > Christoph Mallon wrote: >>> K&R code should be changed as part of related changes if possible. >>> A sweep to change a whole file is probably also ok. >>> changing them one at a time is probably not ok. >> >> But this is what actually is practiced. >> You still did not answer my question: Do you agree to remove the >> clause so no new old style declarations may be added? I think a new clause should be added specifying what should happen and replacing the old clause. From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 20:40:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0352106567A for ; Sat, 2 May 2009 20:40:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id AE9418FC1A for ; Sat, 2 May 2009 20:40:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 02 May 2009 20:40:03 -0000 Received: from p54A3DE1D.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.29] by mail.gmx.net (mp070) with SMTP; 02 May 2009 22:40:03 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18/OsUSHgo/yphJBAD+7fIi5Lr67ulOJC1LsSEjWy uSCiQ/EfmJfqPJ Message-ID: <49FCAFA2.60603@gmx.de> Date: Sat, 02 May 2009 22:40:02 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Julian Elischer References: <49F4070C.2000108@gmx.de> <20090502073658.GA65633@walton.maths.tcd.ie> <49FC752D.5080807@elischer.org> <49FC8574.5060205@gmx.de> <49FC8920.6050408@elischer.org> <49FC8E92.1090207@gmx.de> <49FC9A02.6080901@elischer.org> <49FCA148.9060707@gmx.de> <49FCAA1D.1080208@elischer.org> In-Reply-To: <49FCAA1D.1080208@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: Maxim Sobolev , FreeBSD Hackers , Roman Divacky , Ed Schouten , David Malone , Warner Losh Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 20:40:05 -0000 Julian Elischer schrieb: >> Christoph Mallon wrote: >>>> K&R code should be changed as part of related changes if possible. >>>> A sweep to change a whole file is probably also ok. >>>> changing them one at a time is probably not ok. >>> >>> But this is what actually is practiced. >>> You still did not answer my question: Do you agree to remove the >>> clause so no new old style declarations may be added? > > I think a new clause should be added specifying what should happen > and replacing the old clause. This is not sensible. style(9) says right at the start that it "[...] specifies the preferred style for kernel source files [...]". The preferred style would be to use ANSI function declarations - what else is there to say? There is no point in adding more when less is sufficient. From owner-freebsd-hackers@FreeBSD.ORG Sat May 2 21:21:21 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782611065670; Sat, 2 May 2009 21:21:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7B78FC1D; Sat, 2 May 2009 21:21:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n42LJPOr028953; Sat, 2 May 2009 15:19:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 02 May 2009 15:19:31 -0600 (MDT) Message-Id: <20090502.151931.1396014860.imp@bsdimp.com> To: christoph.mallon@gmx.de From: "M. Warner Losh" In-Reply-To: <49FCAFA2.60603@gmx.de> References: <49FCA148.9060707@gmx.de> <49FCAA1D.1080208@elischer.org> <49FCAFA2.60603@gmx.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sobomax@FreeBSD.org, freebsd-hackers@FreeBSD.org, rdivacky@FreeBSD.org, ed@FreeBSD.org, dwmalone@maths.tcd.ie, julian@elischer.org Subject: Re: C99: Suggestions for style(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 21:21:21 -0000 In message: <49FCAFA2.60603@gmx.de> Christoph Mallon writes: : Julian Elischer schrieb: : >> Christoph Mallon wrote: : >>>> K&R code should be changed as part of related changes if possible. : >>>> A sweep to change a whole file is probably also ok. : >>>> changing them one at a time is probably not ok. : >>> : >>> But this is what actually is practiced. : >>> You still did not answer my question: Do you agree to remove the : >>> clause so no new old style declarations may be added? : > : > I think a new clause should be added specifying what should happen : > and replacing the old clause. : : This is not sensible. style(9) says right at the start that it "[...] : specifies the preferred style for kernel source files [...]". The : preferred style would be to use ANSI function declarations - what else : is there to say? There is no point in adding more when less is sufficient. Actually, in a style guide, there is a point. Adding language that says we're actively removing K&R-style declarations and definitions reinforces this point and explains to people what's going on when they see this in the tree today. This would have been understandable by some folks if I'd left it at the first paragraph, but by adding the second it becomes clear the reasoning behind my post. Warner