Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Thu, Feb 21, 2008 at 10:29:09PM -0800, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: So I'd be happier with warnings about deep indentation (but how do you count it? Will people then try to fake things out by using 4-space indents and then deep indentations will look like just a couple of tabs?) and against complex expressions (ie if ((a = xyz()) == NULL) .. should just be split up into a = xyz(); if (!a) .., but there are sometimes reasons for those things too! Deep indentation should be fairly easy, given that you already have rules in place that says Tabs are 8 characters. So if you find a line that begins with more than say 4 SP, you can flag that as already bogus (i.e. does not indent with HT), more than 8 SP definitely so. ... Checkpatch already has an error use tabs not spaces. And people should realize that checkpatch is not a tool for janitors but for authors and maintainers to easily spot some of the possible problems in a driver and thereby automate some part of patch review. E.g. in this driver we are talking about checkpatch warns about the 2000 lines over 80 characters. And that's not a surprise and a symptom when code is 6 tabs indented. If someone said fixing that should not delay the merge of a 16.500 lines driver I would agree with that since fixing that would require a huge amount of work for a not that big gain. But that a merged driver contains 250 checkpatch errors is really not nice. Most of them are easy to fix stylistic errors that simply make the driver easier to read and whose fixing would only take a few hours altogether. [1] And the 13 checkpatch errors about volatile usage are not stuff for janitors (unless you count our number one cleanup person Al as janitor) but indicate really fishy code. cu Adrian [1] one might argue whether easier to read really applies when checkpatch gives errors for e.g. the usage of C99 comments, but different from overly long lines that's at least stuff that can be fixed very quickly and in a quite automatic way -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] post_recv question
On 2/22/08 12:09 AM, Roland Dreier [EMAIL PROTECTED] wrote: I think we can assume that the ringing of the doorbell is synchronous, i.e. when the processor completes it's write, the card knows there are RQ WQE available in host memory, It doesn't affect your larger point, but to be pedantically precise, writes across PCI will be posted, so the CPU may fully retire a write to MMIO long before that write completes at its final destination. You're right. In fact, I think up to 4 words for the common implementation. But I think this speaks again to the claim that guarantees between adapters on different busses can't work because posted writes go to different FIFO's. - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Purchase software at surprisingly low prices!
Get original and perfectly functioning software at low prices. All software can be downloaded immediately after purchase. Impressive selection of programs even for Macintosh! Programs in many languages are available. We provide help in installing software. You can ask any question and get a free of charge consultation. Guaranteed access to all updates! Friendly and professional service! http://geocities.com/austinfinch24 Incredible selection of programs and applications! ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
On Fri, 22 Feb 2008 01:05:26 +0100 Krzysztof Halasa [EMAIL PROTECTED] wrote: Jeff Garzik [EMAIL PROTECTED] writes: If a driver is full of lines of length 80, that's a problem. I'm not sure. We all have more than 80-chars wide displays for years, don't we? The Even a vt132 serial terminal or later can do 132. Decades not years. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Hello
Hello with love, I am ruth tall slim that love sightseeing, i was going over the computer today and came across your email and got interested in knowing more about you for important discussion reply to me via my mail address if you care ( [EMAIL PROTECTED]) i will send my pics later. Thanks, ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ofa_1_3_kernel 20080222-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_3/linux-2.6.git git_branch: ofed_kernel Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-mlx4-mod --with-core-mod --with-addr_trans-mod --with-rds-mod --with-cxgb3-mod --with-nes-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.12 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.13 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on x86_64 with linux-2.6.16.43-0.3-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.17 Passed on x86_64 with linux-2.6.18-1.2798.fc6 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.18-53.el5 Passed on x86_64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.22.5-31-default Passed on x86_64 with linux-2.6.9-42.ELsmp Passed on x86_64 with linux-2.6.9-55.ELsmp Passed on ia64 with linux-2.6.13 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.16 Passed on ia64 with linux-2.6.15 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.16.21-0.8-default Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.19 Passed on powerpc with linux-2.6.12 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.24 Passed on powerpc with linux-2.6.14 Passed on powerpc with linux-2.6.13 Passed on powerpc with linux-2.6.15 Passed on ppc64 with linux-2.6.14 Passed on ppc64 with linux-2.6.13 Passed on ppc64 with linux-2.6.12 Passed on ppc64 with linux-2.6.15 Passed on ppc64 with linux-2.6.16 Passed on ppc64 with linux-2.6.17 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Passed on ppc64 with linux-2.6.18-8.el5 Passed on ppc64 with linux-2.6.24 Failed: ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Fri, Feb 22, 2008 at 2:46 AM, David Newall [EMAIL PROTECTED] wrote: Krzysztof Halasa wrote: Perhaps we should increase line length limit, 132 should be fine. Especially useful with long printk() lines and long arithmetic expressions. Yes; or even longer. 80 characters might have made sense on a screen when the alternative was 80 characters on a punched card, but on a modern computer it's very restrictive. That's especially true with the deep indents that you quickly get in C. Even short lines often need to be split when you put a few tabs in front of them, and that makes comprehension that bit harder, not to mention looks ugly. There is a reason to limit line length: scientific research has shown that readability of regular texts is optimal for a line length between 55 and 65 characters. My experience is that the readability of source code decreases when the lines are very long (more than 160 characters). Bart Van Assche. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
Bart Van Assche wrote: There is a reason to limit line length: scientific research has shown that readability of regular texts is optimal for a line length between 55 and 65 characters. Putting aside the point that we're talking code, not regular text, I've heard that said before and I don't think it's quite like that. Perhaps the numbers you said might assume various things such as the width of the eye's field of view, the distance to the image and the size of each character? My experience is that the readability of source code decreases when the lines are very long (more than 160 characters). The point is that the width, excluding leading and trailing white space, is what really matters. Even deeply indented code can be a snap to understand if you don't have to fight artificial line breaks. And we've got a much wider -- and taller! -- space available than we had in the old 80x24 (and 80x1) days. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] OpenSM Console Ideas?
Hi Tim, On Thu, 2008-02-21 at 16:27 -0800, Timothy A. Meier wrote: LLNL uses the remote console feature in OpenSM. We have a need to secure this remote connection with authentication/authorization and encryption (specifically PAM and OpenSSL). I have a working prototype, and would like to formalize it and share/include this with OpenSM. Before I go down this path too far, I would like to solicit ideas from others who use the console. Currently, the console can be used in local, loopback, or remote modes. If security is added, should it replace other modes, or be an additional mode? IMO the old modes should be preserved and I would view authentication/authorization and encryption as an orthogonal dimension to be supported with any of those modes. The intention is to use PAM for the AA framework, and OpenSSL for secure sockets. Are there any serious objections to this implementation plan? Is the license compatible with OpenFabrics ? The console feature has always been a configuration/command line option, but should the secure console be conditionally compiled/linked as well? (eliminate dependency on the PAM and OpenSSL libs, pam, pam_misc, cryto, ssl). This might depend on the licensing. Also, on one hand, it would be nice to minimize the build options, but for those where space is an issue, the separate configurability of this would be useful. (Not knowing the additional size of this but it sounds like it will be large enough to not make this a mandatory requirement of the console). -- Hal The secure console would require a relatively primitive client application, which I will probably package under opensm, just like osmtest. Make sense? Do you have any other ideas or suggestions for the remote console? ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Let's chat
Hello! I am bored today. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. Will send some of my pictures ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
***SPAM*** Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Sat, 2008-02-23 at 00:55 +1030, David Newall wrote: Bart Van Assche wrote: There is a reason to limit line length: scientific research has shown that readability of regular texts is optimal for a line length between 55 and 65 characters. Putting aside the point that we're talking code, not regular text, I've heard that said before and I don't think it's quite like that. Perhaps the numbers you said might assume various things such as the width of the eye's field of view, the distance to the image and the size of each character? Not in my experience. My experience is that the readability of source code decreases when the lines are very long (more than 160 characters). The point is that the width, excluding leading and trailing white space, is what really matters. Even deeply indented code can be a snap to understand if you don't have to fight artificial line breaks. And we've got a much wider -- and taller! -- space available than we had in the old 80x24 (and 80x1) days. I have 2 24 screens running at 1920x1200 with X forced to 75dpi and use a 8pt Monospace font. (Yes, I can read that from more than 3ft away) Using a fullscreen gvim (without the icons, but with the menu) with 3 vertical splits gives me 4 columns of 113 rows and 95 chars. So, yes, I have the screen estate for very long lines, but I find that long lines require more effort to read (that very much includes leading whitespace). Also, since long lines are rare (and they should be, if you nest too deep you have other issues) accommodating them would waste a lot of screen estate otherwise useful for another column of text. Even with e-mail, I can easily show over 200 characters wide with a large font (say 11pt) but find it harder to read emails that don't nicely wrap at 78. So much so that I often find myself not reading the mail, or restyling it if I find it important enough to read anyway. Please, lets keep the 80 as a guideline, and not trip over the occasional lines that exceed it in good style (read: wrapping them would indeed give uglier code) ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Cheapest software prices!
Don't waste time waiting for delivery of your software on a CD. Download and install it immediately. Choose the program you need from more than 270 programs in many languages. We are glad to help you to install your software. Feel free to ask questions and receive highly professional consultations. If you failed to find software you need in our list, we can try to find it for you. http://geocities.com/rogelio_knowles Take this time and money saving offer! ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Sat, Feb 23, 2008 at 12:55:03AM +1030, David Newall wrote: Bart Van Assche wrote: There is a reason to limit line length: scientific research has shown that readability of regular texts is optimal for a line length between 55 and 65 characters. Putting aside the point that we're talking code, not regular text, I've heard that said before and I don't think it's quite like that. Perhaps the numbers you said might assume various things such as the width of the eye's field of view, the distance to the image and the size of each character? I'm sure all those assumptions are baked-in to the estimate. Yet the fact remains that people's eyes are only so good and most people will be reading at similar distances from the screen. So I don't see any reason to invalidate those assumptions. FWIW, I find reading longer lines to be painful -- it is easier to loose one's place in the text. I would also echo a point Jeff Garzik made elsewhere that it is often beneficial to have multiple windows oppen side-by-side. Longer lines makes it harder to do that in a useful way. Instead the lines either wrap or just trail off the screen. See the output of sdiff for how this limits usefulness. My experience is that the readability of source code decreases when the lines are very long (more than 160 characters). The point is that the width, excluding leading and trailing white space, is what really matters. Even deeply indented code can be a snap to understand if you don't have to fight artificial line breaks. And we've got a much wider -- and taller! -- space available than we had in the old 80x24 (and 80x1) days. I'm not sure deeply indented code is ever a snap to understand. And FWIW, I'd rather deal with artificial line breaks than parameter lists that just stream off the side of the page. The line breaks make long parameters lists easier to digest. I'll sacrifice the occasional odd breakage of a long string. John -- John W. Linville [EMAIL PROTECTED] ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] scsi transport layer for srp
When I worked on OFED-1.3-rc2, I happened to notice that even though ib_rcp.c includes the scsi_transport_srp.h header and called into the functions in scsi_transport_srp.c such as srp_remove_host, however, scsi_transport_srp.ko has never been loaded in my system. However it seems to be working fine. Would it mean that that piece of source have been patched out? I'm now in the process of debugging an issue on srp and would like to trace into the stack. Really confusing about the situation. Would anyone familiar with topic gives me some guidances? Thanks. Stoney ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] post_recv question
Tom Tucker wrote: Ok. So what does the HW do with the packet while it's pondering it's options? It has to put it somewhere. At the point where the RQ/SRQ would be checked the HW should not have to put the packet anywhere. At least not until it can allocate a WQE or declare a no-buffer-available error. RDMA is incompatible with cut-through placement directly into a user buffer. The hardware has to capture the entire packet before it can legitimately allocate the correct receive WQE. So it is distinctly feasible for a HW implementation to simply leave the packet where it is while it completes a more extended check to ensure that there really is no available recv WQE. Or an implementation could adopt the strategy of ensuring that all RQ/SRQ WQEs must be very easy for the Hardware to find, and the posting routine must do whatever is necessary to ensure that this has been done. Which of many solutions is deployed is up to the implementation. The semantics are that after the recv wqe is posted that it *is* in the RQ/SRQ. Wherever the RQ/SRQ is represented in host and/or adapter memory, a QP is responsible for guaranteeing that it has searched the entire there before it declares that the recv wqe is not there. That involves work on the part of posting recv wqes and/or on allocating them. But it is up to those entities to divide the work. They cannot decide that the application should solve the problem for them. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] post_recv question
On Thu, 2008-02-21 at 22:15 -0800, Shirley Ma wrote: Hello Ralph, ib_ipoib uses shared receive queues and doesn't try to manage posted buffer credits so the RNR NAK issue isn't the same as what Steve is trying to do. I meant the problem you saw might be the same reason. How many connections did you have when you hit this problem? Probably more than 1? thanks Shirley Possibly. I haven't had RNR NAK problems running the RC5 bits with netperf between two systems. I'll try iperf and see what happens. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] opensm/libvendor: use CL_HTON64() macro for constant conversion
Use CL_HTON64() macro for constant conversion instead of cl_ntoh64()
function. Also it changes conversion direction since this value used in
network byte order.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/libvendor/osm_vendor_ibumad.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/opensm/libvendor/osm_vendor_ibumad.c
b/opensm/libvendor/osm_vendor_ibumad.c
index 679f06a..39c5fb3 100644
--- a/opensm/libvendor/osm_vendor_ibumad.c
+++ b/opensm/libvendor/osm_vendor_ibumad.c
@@ -128,7 +128,7 @@ Exit:
static osm_madw_t *get_madw(osm_vendor_t * p_vend, ib_net64_t * tid)
{
umad_match_t *m, *e;
- ib_net64_t mtid = (*tid cl_ntoh64(0xllu));
+ ib_net64_t mtid = (*tid CL_HTON64(0xllu));
osm_madw_t *res;
/*
--
1.5.4.1.122.gaa8d
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] for-2.6.25: ib/cm: flush workqueue when removing device
When a cm mad is received, it is queued to a cm workqueue for
processing. The queued work item references the port and device
on which the mad was received. If that device is removed from
the system before the work item can execute, the work item will
reference freed memory.
To fix this, flush the workqueue after unregistering to receive
mads, and before the device can be freed.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Bug found with SDP testing on OFED 1.3. The patch is also available at:
git://git.openfabrics.org/~shefty/rdma-dev.git for-roland
drivers/infiniband/core/cm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index b10ade9..4df4051 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -3759,6 +3759,7 @@ static void cm_remove_one(struct ib_device *device)
port = cm_dev-port[i-1];
ib_modify_port(device, port-port_num, 0, port_modify);
ib_unregister_mad_agent(port-mad_agent);
+ flush_workqueue(cm.wq);
cm_remove_port_fs(port);
}
kobject_put(cm_dev-dev_obj);
@@ -3813,6 +3814,7 @@ static void __exit ib_cm_cleanup(void)
cancel_delayed_work(timewait_info-work.work);
spin_unlock_irq(cm.lock);
+ ib_unregister_client(cm_client);
destroy_workqueue(cm.wq);
list_for_each_entry_safe(timewait_info, tmp, cm.timewait_list, list) {
@@ -3820,7 +3822,6 @@ static void __exit ib_cm_cleanup(void)
kfree(timewait_info);
}
- ib_unregister_client(cm_client);
class_unregister(cm_class);
idr_destroy(cm.local_id_table);
}
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
* Linus Torvalds [EMAIL PROTECTED] wrote: I'm personally of the opinion that a lot of checkpatch fixes are anything but. That mainly concerns fixing overlong lines (where the fixed version is usually worse than the original), but it's been true for some other warnings too. that was certainly the case for the earlier checkpatch releases which treated overlong lines as an error. So here's a quick list of negative and positive aspects of current versions of checkpatch, as i see them. But let me first declare it that when scripts/checkpatch.pl was initially merged last year i immediately ran it over my own files and became a deep sceptic of it. (check the lkml archives, i complained alot about it) Now i've got more than half a year of experience with using checkpatch as an integral part of scheduler maintenance, and we've now got 4 months of experience with using checkpatch in arch/x86 maintenance. Based on this first hand experience, my opinion about checkpatch has changed, rather radically: i now believe that checkpatch is almost as important to the long term health of our kernel development process as BitKeeper/Git turned out to be. If i had to stop using it today, it would be almost as bad of a step backwards to me as if we had to migrate the kernel source code control to CVS. Lets see the Bad Side of checkpatch: 1) checkpatch errors shouldnt be taken too seriously for newly introduced leaf driver code, which code we dont at all know whether we'll be maintaining in any serious manner in the future. Slowing down a submission by requirig it to pass checkpatch is not as clear-cut as it is for core infrastructure and architecture code. It's far more important to get _any_ code to users (as long as it's not outright harmful) than to nitpick about style details. 2) it still has some false positives. (They are quite rare in the latest versions, about 1 out of 100 for code that is already clean. I send them over to Andy whenever i see them, and they get fixed quickly. The false positives were a big annoyance in early checkpatch.pl versions, these days they are not - to me at least.) 3) it's _really_ annoying when sometimes i stumble over some old, crufty piece of code that according to checkpatch is in high need of some good, thorough cleanup - and when i take a look at the code it turns out that the original author of that crap piece of code turns out to be ... me. Those moments can be pretty embarrasing and sobering ;-) The Good Side of checkpatch (and here i'll only list the non-obvious advantages): 1) 90% of the scheduler related checkpatch fixes today you'll never recognize in a commit! The fixes all happen before code is submitted, and the fixes are seemlessly embedded in nice looking patches. (in that sense checkpatch is a bit like lockdep: 90% of the errors they detect wont hit lkml, ever.) 2) you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird feeling that there's something wrong about the patch. It's totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code. That feeling i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a library of patterns of good and bad looking coding practices. If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the code is peppered with random style noise, it's a lot harder (for me at least) to notice real bugs. I can notice bugs in a squeeky clean code base about 5 times easier than in a noisy codebase. This effect alone makes checkpatch indispensible for the scheduler and for arch/x86. Sidenote: i dont really need fancy metrics trying to tell me how good an algorithm _truly_ is (although it certainly would be interesting to have). I can _see_ that at a glance - provided the code follows common kernel practices and a common, consistent style. Checkpatch makes visual code patterns universal and eases the human maintainance work enormously, for a 150+ KLOC subsystem like arch/x86. I'm not distracted (visually and mentally) by the thick fog of small silly details and quirks in coding style. Others might have radar eyes and radar brains, i dont :-) 3) checkpatch also keeps _my_ bugs out of the kernel in an interesting way. I'm sure many of you are like me: i've got weaker moments when i write rather crappy code, and i've got stronger moments when i'm in the flow and can write a few thousand lines of code with nary a hickup. What makes things worse is it's really hard to tell the two apart. It turns out - and this surprised me a
Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Fri, Feb 22, 2008 at 04:17:17PM +0100, Peter Zijlstra wrote: Even with e-mail, I can easily show over 200 characters wide with a large font (say 11pt) but find it harder to read emails that don't nicely wrap at 78. So much so that I often find myself not reading the mail, or restyling it if I find it important enough to read anyway. Yes, ditto. And since most of my patch review is done inside mutt... -- John W. Linville [EMAIL PROTECTED] ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] opensm/osm_vendor_ibumad: simplify put_madw() prototype
In put_madw() pass transaction id by value as it used there and not by
refernce.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/libvendor/osm_vendor_ibumad.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/opensm/libvendor/osm_vendor_ibumad.c
b/opensm/libvendor/osm_vendor_ibumad.c
index 39c5fb3..d51bd6d 100644
--- a/opensm/libvendor/osm_vendor_ibumad.c
+++ b/opensm/libvendor/osm_vendor_ibumad.c
@@ -154,7 +154,7 @@ static osm_madw_t *get_madw(osm_vendor_t * p_vend,
ib_net64_t * tid)
}
static void
-put_madw(osm_vendor_t * p_vend, osm_madw_t * p_madw, ib_net64_t * tid)
+put_madw(osm_vendor_t * p_vend, osm_madw_t * p_madw, ib_net64_t tid)
{
umad_match_t *m, *e, *old_lru, *lru = 0;
osm_madw_t *p_req_madw;
@@ -165,7 +165,7 @@ put_madw(osm_vendor_t * p_vend, osm_madw_t * p_madw,
ib_net64_t * tid)
pthread_mutex_lock(p_vend-match_tbl_mutex);
for (m = p_vend-mtbl.tbl, e = m + p_vend-mtbl.max; m e; m++) {
if (m-tid == 0) {
- m-tid = *tid;
+ m-tid = tid;
m-v = p_madw;
m-version =
cl_atomic_inc((atomic32_t *) p_vend-mtbl.
@@ -185,9 +185,9 @@ put_madw(osm_vendor_t * p_vend, osm_madw_t * p_madw,
ib_net64_t * tid)
p_bind = p_req_madw-h_bind;
p_req_madw-status = IB_CANCELED;
pthread_mutex_lock(p_vend-cb_mutex);
- (*p_bind-send_err_callback) (p_bind-client_context, old_lru-v);
+ (*p_bind-send_err_callback) (p_bind-client_context, p_req_madw);
pthread_mutex_unlock(p_vend-cb_mutex);
- lru-tid = *tid;
+ lru-tid = tid;
lru-v = p_madw;
lru-version =
cl_atomic_inc((atomic32_t *) p_vend-mtbl.last_version);
@@ -1081,7 +1081,7 @@ osm_vendor_send(IN osm_bind_handle_t h_bind,
Resp:
if (resp_expected)
- put_madw(p_vend, p_madw, p_mad-trans_id);
+ put_madw(p_vend, p_madw, p_mad-trans_id);
#ifdef VENDOR_RMPP_SUPPORT
sent_mad_size = p_madw-mad_size;
--
1.5.4.1.122.gaa8d
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Fri, Feb 22, 2008 at 7:54 PM, Ingo Molnar [EMAIL PROTECTED] wrote: If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the code is peppered with random style noise, it's a lot harder (for me at least) to notice real bugs. I can notice bugs in a squeeky clean code base about 5 times easier than in a noisy codebase. This effect alone makes checkpatch indispensible for the scheduler and for arch/x86. I also appreciate style uniformity in kernel code. My (limited) experience with checkpatch is that most checkpatch complaints are easy to resolve. Bart Van Assche. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
Ingo Molnar wrote: 2) you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird feeling that there's something wrong about the patch. It's totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code. That feeling i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a library of patterns of good and bad looking coding practices. If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the [...] The best programmers are the ones who have a good eye for details - and that subconsciously extends to style details too. I've yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise. (Newbies will make style mistakes a lot more often - and for them checkpatch is a nice and easy experience at reading other people's code and trying to learn the style of the kernel.) [...] 4) there's a psychological effect as well: clean _looking_ code is more attractive to coders to improve upon. Once the code _looks_ clean (mechanically), the people with the real structural cleanups are not far away either. Code that just looks nice is simply more of a pleasure to work with and to improve, so there's a strong psychological relationship between the small, seemingly unimportant details cleanups and the real, structural cleanups. The above deserved to be quoted... just because I agree with all of it so strongly :) Bugs really do hide in ugly code, in part because my brain has been optimized to review clean code. Like everything else in life, one must strike a balance between picking style nits with someone's patch, and making honest criticisms of a patch because said patch is too unclean to be reviewed by anyone. Jeff ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
On Fri, Feb 22, 2008 at 02:20:12PM -0500, Jeff Garzik wrote: Ingo Molnar wrote: 2) you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird feeling that there's something wrong about the patch. It's totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code. That feeling i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a library of patterns of good and bad looking coding practices. If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the [...] The best programmers are the ones who have a good eye for details - and that subconsciously extends to style details too. I've yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise. (Newbies will make style mistakes a lot more often - and for them checkpatch is a nice and easy experience at reading other people's code and trying to learn the style of the kernel.) [...] 4) there's a psychological effect as well: clean _looking_ code is more attractive to coders to improve upon. Once the code _looks_ clean (mechanically), the people with the real structural cleanups are not far away either. Code that just looks nice is simply more of a pleasure to work with and to improve, so there's a strong psychological relationship between the small, seemingly unimportant details cleanups and the real, structural cleanups. The above deserved to be quoted... just because I agree with all of it so strongly :) Bugs really do hide in ugly code, in part because my brain has been optimized to review clean code. Like everything else in life, one must strike a balance between picking style nits with someone's patch, and making honest criticisms of a patch because said patch is too unclean to be reviewed by anyone. I totally agree with all of this. checkpatch.pl is a useful tool to use, and is quite handy for helping the kernel code for all of the above reasons. /aol thanks, greg k-h ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
On Thu 2008-02-21 14:08:55, Arjan van de Ven wrote: On Thu, 21 Feb 2008 23:01:24 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: [ Linus Added to the To: since I want to hear his opinion on this issue. ] On Thu, Feb 21, 2008 at 12:28:55PM -0800, Roland Dreier wrote: This driver should really have gotten some review before being included in the kernel. Even a simple checkpatch run finds more than 250 stylistic errors (not code bugs but cases where the driver violates the standard code formatting rules of kernel code). Linus has strongly stated that we should merge hardware drivers early, and I agree: although the nes driver clearly needs more work, there's no advantage to users with the hardware in forcing them to wait for 2.6.26 to merge the driver, since they'll just have to patch the grungy code in themselves anyway. And by merging the driver early, we get fixed up for any tree-wide changes and allow janitors to help with the cleanup. Is it really intended to merge drivers without _any_ kind of review? No of course not. I totally agree we should be more agressive in merging drivers earlier. A minimal review needs to happen so for a few things imo 1) That the driver doesn't break the build 2) That the driver has no obvious huge security holes (this is a big deal for unsuspecting users) 3) that there's not an obscene amount of uses deprecated api compiler warnings (since those are annoying for everyone else) 4) that people who don't have the hardware are not negatively affected (say crashes without the hw or so) 5) does not introduce new and ugly user-kernel we'll have problems fixing/removing? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
On Fri 2008-02-22 01:05:26, Krzysztof Halasa wrote: Jeff Garzik [EMAIL PROTECTED] writes: If a driver is full of lines of length 80, that's a problem. I'm not sure. We all have more than 80-chars wide displays for years, don't we? The No. Zaurus is one example, second is small screen where you need big font to keep it readable (x60 on desk). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] divisas ganadoras
___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
Linus Torvalds [EMAIL PROTECTED] writes: Will people then try to fake things out by using 4-space indents and then deep indentations will look like just a couple of tabs?) There is no point in faking it as it's only advisory, it's to help the author who should be free to ignore the advice. People upstream won't be fooled by some cheap tab tricks I guess. -- Krzysztof Halasa ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: Merging of completely unreviewed drivers
Pavel Machek [EMAIL PROTECTED] writes: Zaurus is one example, second is small screen where you need big font to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? -- Krzysztof Halasa ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
Peter Zijlstra [EMAIL PROTECTED] writes: So, yes, I have the screen estate for very long lines, but I find that long lines require more effort to read (that very much includes leading whitespace). Also, since long lines are rare (and they should be, if you nest too deep you have other issues) accommodating them would waste a lot of screen estate otherwise useful for another column of text. Either they are rare and you can wrap them and still use 80 columns, or it turns out they are not so rare and you may want to use wider windows (not necessarily 132 but perhaps 100). I think the question isn't if they are rare or not, or if people have 3 * 1920 pixels/line or just 1280. The question is: is the code more readable with hard limit equal to 80 characters, or maybe is it better to limit code block complexity instead, and let the maximum number of those small pictures in a line alone? (Limiting at 132 would have technical sense IMHO). Better code readability = less bugs without any additional effort. Even with e-mail, I can easily show over 200 characters wide with a large font (say 11pt) but find it harder to read emails that don't nicely wrap at 78. Sure - because email is not C code. Actually you don't read C code, word by word, as you read books - do you? -- Krzysztof Halasa ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: Merging of completely unreviewed drivers
On Fri, Feb 22, 2008 at 11:59:35PM +0100, Krzysztof Halasa wrote: Sure - because email is not C code. Actually you don't read C code, word by word, as you read books - do you? If it's decently written - sure, why not? Unfortunately, more common case is somewhere between the writing on the lavatory wall and appartment lease agreement, with several high school essays mixed in... ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] TakeALookAddtoCartSoftTabs
ForValuedCustomerSpecialPricesCertified http://joycearcostu.blogspot.com ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
