Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Jeremiahs wrote: I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. As the original author of the PR, I'll point out that this chagne does *not* add rules. It clarifies the wording of a rule that's already there. If the rule is wrong, it should be removed. The reason I didn't post if for wider review was because it wasn't changing any rules. My thanks to Giorgos for moving this PR towards closure. I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 11:35:52PM -0700, M. Warner Losh wrote:
: I was giving one. :-)
: style(9) documents the practices of /sys. Thus we should not arbitaryly
: add rules w/o them being backed up in code.
I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends
to follow this rule. If you are looking for examples.
Older code than PCCARD. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes: Poul-Henning Kamp [EMAIL PROTECTED] types: In message [EMAIL PROTECTED], Mike Meyer writes: I'm advocating that the rule focus on readability rather than trying to enforce a type which doesn't exist. Excellent idea. Can you provide verbiage and examples? All you have to do is get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use And as far as I'm concerned the confusion is gone. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
patch for review, mountlist vnode scan generalization (vnlru() related) (current)
The vnode recycle code is currently not able to recycle vnodes in an
LRU fashion because we cannot move vnodes within the mount's vnodelist
without causing a number of filesystems, including UFS, to lose track
when scanning the mount's vnodelist and start doing loop-restarts,
resulting in O(dirty_vnode_count^2) operation.
For example, if the #if 0'd section in vlruvp() in vfs_subr.c were to
be enabled, the filesystem syncing daemon would suddenly start eating
insane amounts of cpu if a significant number of dirty vnodes exists
(like rm -rf /usr/ports or cp -r or cvs checkout, etc...).
This patch is intended to begin solving this problem. The main purpose
of the patch is to generalize the vnode scan that virtually all
filesystems do when they are sync'd (see *_sync() in [*/]*/*vfsops.c*).
The patch defines a new API that does all the hard work of keeping
track of the scan position and doing the vnode scan itself and makes
callbacks to flush individual vnodes as appropriate.
The patch implements this API and modifies UFS to use the new API to
prove it out. As part of this API, a new vnode type called VMARKER
has been added. This type allows us to initialize a dummy vnode and
use it to mark our position in the mountlist. All other code that
does not use the new API to scan the vnodes under the mount must ignore
this dummy vnode in their scans. A sysctl, debug.vlruvp_enable, is
provided to enable the previously #if 0'd section of vlruvp() (i.e.
turn on LRU ordering for the vnode recycle code), for testing purposes.
This defaults to off (0) since only UFS has been fixed.
I've done some moderate testing on -current. I intend to commit this
some time tomorrow unless there are hicups or someone has a bright idea.
It will eventually get into -stable as well.
The main thing I am looking for review-wise is that the existing
ffs_sync() code is equivalent to the new ffs_sync()-using-new-API code.
There should be no operational differences, it should simply be cut-up
differently. i.e. this commit stage is not supposed to make any major
operational changes to the codebase.
-Matt
Index: isofs/cd9660/cd9660_vnops.c
===
RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vnops.c,v
retrieving revision 1.73
diff -u -r1.73 cd9660_vnops.c
--- isofs/cd9660/cd9660_vnops.c 12 Sep 2001 08:37:43 - 1.73
+++ isofs/cd9660/cd9660_vnops.c 6 Mar 2002 08:14:05 -
@@ -110,6 +110,7 @@
case VFIFO:
case VNON:
case VBAD:
+ case VMARKER:
return (0);
}
}
Index: kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.347
diff -u -r1.347 vfs_subr.c
--- kern/vfs_subr.c 5 Mar 2002 19:45:45 - 1.347
+++ kern/vfs_subr.c 6 Mar 2002 08:46:03 -
@@ -335,6 +335,92 @@
}
/*
+ * vfs_scan_init: Initialize a vfs_scan_info structure for use.
+ *
+ * The info structure is cleared and initialized for use. The caller
+ * may initialize additional fields after calling this function.
+ *
+ */
+void
+vfs_scan_init(struct vfs_scan_info *info)
+{
+ bzero(info, sizeof(struct vfs_scan_info));
+ info-vs_doloop = 1;
+}
+
+/*
+ * vfs_scan_vnodes:Scan the vnodes under a mount point
+ *
+ * The caller passes the mount point, pre-initialized information
+ * structure, and two function callbacks.
+ *
+ * The fast function is called as an optimization, with the mountlist
+ * mutex still held. This function may not block or release the mutex.
+ * A negative return value will cause the scan code to skip the vnode
+ * (never call the slow function). This function may be NULL.
+ *
+ * The slow function is called if the fast function returns = 0. This
+ * function will be called without the mountlist mutex held and is allowed
+ * to block. It may also be NULL.
+ *
+ * If either function wishes a rescan to occur after the current scan
+ * finishes, they should set vs_tryagain to 1. If either function wishes
+ * to abort the loop entirely, vs_doloop should be set = 0 (and
+ * vs_tryagain should also be set to 0 if you had previously modified
+ * it).
+ */
+int
+vfs_scan_vnodes(struct mount *mp, struct vfs_scan_info *info, vfs_vnfast_t fastfunc,
+vfs_vnslow_t slowfunc)
+{
+ struct vnode *vp;
+ struct vnode *nvp;
+
+ info-vs_mount = mp;
+ info-vs_marker.v_mount = mp;
+ info-vs_marker.v_type = VMARKER;
+
+ mtx_lock(mntvnode_mtx);
+ info-vs_tryagain = 1;
+ while (info-vs_tryagain) {
+ info-vs_tryagain = 0;
+ for (vp =
Re: aio_read() oddness
On Wednesday 06 March 2002 07:03, Tony Arcieri wrote: I'm not currently subscribed to this list, so please cc replies to me. I was playing around with aio_read() and ran into some seemingly aberrant behavior, although not with aio_read() itself, but the resulting signal. Within struct aiocb I was setting: aio_sigevent.sigev_notify = SIGEV_SIGNAL; aio_sigevent.sigev_value.sigval_int = 42; iocb.aio_sigevent.sigev_signo = SIGUSR1; Then in the sigaction structure: sa_flags = SA_SIGINFO; Upon completion of the requested read, a signal is sent. Within the siginfo structure, si_signo is set properly. However, si_value.sigval_int is zero. Is this just not implemented completely yet or am I missing something? I have a set of aio test tools and it indeed seems it is not implemenented. I am getting a zero value too. Tony Arcieri To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
David O'Brien [EMAIL PROTECTED] types:
On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote:
David O'Brien [EMAIL PROTECTED] types:
As the original author of the PR, I'll point out that this chagne does
*not* add rules. It clarifies the wording of a rule that's already
there. If the rule is wrong, it should be removed. The reason I didn't
post if for wider review was because it wasn't changing any rules. My
thanks to Giorgos for moving this PR towards closure.
I don't think it is clarifying a rule. I think it is in fact adding a
rule. You are extrapolating too much I think. All the rule is trying
to prevent is if (!strcmp(a,b)) which when read is extremely wrong of
that is actually happening.
Ok, I was attempting to clarify a rule, but misinterpreted. Which just
reinforces the need for clarifing it.
Being an old lisp hand, I'm used to functions that return a value or
nil to indicate an error of some kind, and programs that just check
the value are SOP.
I'll grant that the change Paul suggested makes it clear - the
programmer knows when the function is returning an int or not. But
it's not clear that it achieves his intent. is
char *p;
if (p = somerandomfunction(with, args)) {
}
really less readable than:
char *p;
if ((p = somerandomfunction(with, args)) != NULL) {
}
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes:
I'll grant that the change Paul suggested makes it clear - the
programmer knows when the function is returning an int or not. But
it's not clear that it achieves his intent. is
char *p;
if (p = somerandomfunction(with, args)) {
}
really less readable than:
char *p;
if ((p = somerandomfunction(with, args)) != NULL) {
}
Ahh, but here you hit one of my pet-peeves. I hate assignments inside
conditionals. I prefer the above written as:
char *p;
p = somerandomfunction(with, args);
if (p != NULL) {
}
Anyway, if you want it spelled out the way I would want it:
0. No assignments in if()
1. In conditions, pointers should be explicitly compared against NULL:
if (foo == NULL)
or
if (foo != NULL)
2. In conditions, non-interger numeric types should be explicitly compared
to zero
if (float_t == 0.0)
3. Integers need not be explicitly compared to zero:
if (foo MASK)
not
if ((foo MASK) != 0)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] types: Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: Anyway, if you want it spelled out the way I would want it: 0. No assignments in if() 1. In conditions, pointers should be explicitly compared against NULL: if (foo == NULL) or if (foo != NULL) 2. In conditions, non-interger numeric types should be explicitly compared to zero if (float_t == 0.0) 3. Integers need not be explicitly compared to zero: if (foo MASK) not if ((foo MASK) != 0) I would like it spelled out. Since style(9) uses assignments in conditionals in it's examples, rule 0 probably won't fly. Rule 1 and 2 are redundant. Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. Thank you, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Sun idlc broken with our libc_r [Please help]
Hi all,
Rev. 1.20 of src/lib/libc_r/uthread/uthread_join.c still breaks
Openoffice build.
During the build, the idl compiler from sun just hangs, and stays
there in the endless loop.
+ while (_thread_run-join_status.thread == pthread) {
+ /* Schedule the next thread: */
+ _thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__);
+ }
The same idlc code works fine in Solaris, Linux, and NetBSD (they do
not have threads).
So it is definitly a FreeBSD libc_r bug.
I cannot finish and deliver a working Openoffice port if this does not get
fixed for some part :-((
I'm very happy if you have more clues than I have.
To build openoffice:
cd /usr/ports/editors/openoffice
and see the build hanging.
Martin
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Four misc. questions related to jail usage
Patrick Thomas [EMAIL PROTECTED] writes: No, procfs is pretty much useless these days (except for truss). In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail if their jail does not have a proc file system mounted in their /proc ? Only 'ps -e'. Everything else will work just fine. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: On Tuesday 05 March 2002 11:28 am, Kenneth Mays wrote: [SNIP] Besides, it's not C++ that provides whatever questionable benefits it provides; it's OO methodology which can come in handy, and there are more elegant OO solutions than C++ around. Hear, Hear! In my small, insignificant opinion, I thought the creators of C++ were cracked for taking a small, concise, procedural, and beautiful, language like C and obfuscating (read: corrupting) it with all that overloading stuff. Most of the class stuff can be implemented in C, though perhaps not as transparently. They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. I'll go away now. Dave -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote:
Hi all,
Rev. 1.20 of src/lib/libc_r/uthread/uthread_join.c still breaks
Openoffice build.
During the build, the idl compiler from sun just hangs, and stays
there in the endless loop.
+ while (_thread_run-join_status.thread == pthread) {
+ /* Schedule the next thread: */
+ _thread_kern_sched_state(PS_JOIN, __FILE__, __LINE__);
+ }
This loop is correct, like I've said twice before.
The same idlc code works fine in Solaris, Linux, and NetBSD (they do
not have threads).
So it is definitly a FreeBSD libc_r bug.
Did you even try the patch I sent you to uthread_detach.c?
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
Hi, This loop is correct, like I've said twice before. Did you even try the patch I sent you to uthread_detach.c? I've not recieved any patch. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
BPF - Locally Generated Packet Reception
Hi, In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter BIOCSSEESENT, which is by default set to 1. Hence the packets both from remote systems and locally generated are received. If locally generated packets needs to be filtered, we can use the option BIOCSSEESENT and set the value to 0. But even after setting this value to 0 (using the ioctl call), the locally generated packets are received. Am I missing something ? Plese throw light on this issue. TIA Raj Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
(No Subject)
Hi, In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter BIOCSSEESENT, which is by default set to 1. Hence the packets both from remote systems and locally generated are received. If locally generated packets needs to be filtered, we can use the option BIOCSSEESENT and set the value to 0. But even after setting this value to 0 (using the ioctl call), the locally generated packets are received. Am I missing something ? Plese throw light on this issue. TIA Raj Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On 2002-03-05 16:54, Terry Lambert wrote:
Giorgos Keramidas wrote:
The steeper learning curve of C++ is indeed steeper, not because of
some magic property of the object-oriented programming paradigm, but
because there are a lot more things to learn, before a complete
program can be written, IMHO.
Uh... Hello World looks the same in ANSI C and C++, unless
you insist on using I/O streams and cout, which no one ever
really does, unless they are writing a C++ book or trying to
impress a student.
Well, to be frank, I've seen a few C++ coding style documents, that suggest
avoiding stdout.h altogether when writing in C++. The fact that parts of
the C++ libraries already use the I/O stream classes, which have their own
buffers, combined with the buffered I/O that stdout.h does by default,
can and usually does result in all hell being let loose.
But then, I'm probably starting to go off topic here...
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: aio_read() oddness
FreeBSD does not support queued signals (part of RT Posix) which is required for this. -Kip = For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Peter J. Blok wrote: On Wednesday 06 March 2002 07:03, Tony Arcieri wrote: I'm not currently subscribed to this list, so please cc replies to me. I was playing around with aio_read() and ran into some seemingly aberrant behavior, although not with aio_read() itself, but the resulting signal. Within struct aiocb I was setting: aio_sigevent.sigev_notify = SIGEV_SIGNAL; aio_sigevent.sigev_value.sigval_int = 42; iocb.aio_sigevent.sigev_signo = SIGUSR1; Then in the sigaction structure: sa_flags = SA_SIGINFO; Upon completion of the requested read, a signal is sent. Within the siginfo structure, si_signo is set properly. However, si_value.sigval_int is zero. Is this just not implemented completely yet or am I missing something? I have a set of aio test tools and it indeed seems it is not implemenented. I am getting a zero value too. Tony Arcieri To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Giorgos Keramidas writes: On 2002-03-05 16:54, Terry Lambert wrote: Giorgos Keramidas wrote: The steeper learning curve of C++ is indeed steeper, not because of some magic property of the object-oriented programming paradigm, but because there are a lot more things to learn, before a complete program can be written, IMHO. Uh... Hello World looks the same in ANSI C and C++, unless you insist on using I/O streams and cout, which no one ever really does, unless they are writing a C++ book or trying to impress a student. Well, to be frank, I've seen a few C++ coding style documents, that suggest avoiding stdout.h altogether when writing in C++. The fact that parts of the C++ libraries already use the I/O stream classes, which have their own buffers, combined with the buffered I/O that stdout.h does by default, can and usually does result in all hell being let loose. I assume you mean stdio.h? Anyway, I *really* can't see any reason not to use iostream, fstream, sstream and friends. I also cannot see any reason not to use exceptions, the standard containers, the string classes etc. Used properly, these make it possible to write code that is inherently safer than anything built around printf/scanf, char *, longjump, etc. Without these (and a few others) you may just as well stay with standard C. Then again, if you want to do object-oriented programming, C++ is probably not the right choice. If you want to use several different paradigms simulataneously in one language, C++ may be a better fit - although Common Lisp is a much better choice :-) //Raymond. -- Raymond WikerMail: [EMAIL PROTECTED] Senior Software Engineer Web: http://www.fast.no/ Fast Search Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Again, look at current. The RNG is _really_ fast. I know. I know. I wish we could use it. Unfortunately this is for an appliance type application and I just don't feel comfortably shipping -CURRENT as product. I'm only just now making the effort to get up to speed on -CURRENT so that we can be ready to use it later this year. Also - have you looked at STABLE's /dev/urandom? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kqueue example code - suggestions?
Could anyone suggest a package I might look at to get an example of real world kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). Thanks. -- Conrad Sabatier [EMAIL PROTECTED] Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kqueue example code - suggestions?
thttpd = For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Conrad Sabatier wrote: Could anyone suggest a package I might look at to get an example of real world kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). Thanks. -- Conrad Sabatier [EMAIL PROTECTED] Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kqueue example code - suggestions?
On 10:33-0600, Mar 6, 2002, Conrad Sabatier wrote: Could anyone suggest a package I might look at to get an example of real world kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). /usr/src/usr.bin/tail/forward.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote:
Hi Daniel,
Unfortunatly the patch doesn't work ...
Try adding this patch also (keep other patch in):
Index: uthread_cancel.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_cancel.c,v
retrieving revision 1.11
diff -u -r1.11 uthread_cancel.c
--- uthread_cancel.c16 Dec 2001 13:26:44 - 1.11
+++ uthread_cancel.c6 Mar 2002 16:57:18 -
@@ -70,6 +70,9 @@
if (pthread-join_status.thread != NULL) {
pthread-join_status.thread-joiner
= NULL;
+ pthread-join_status.thread = NULL;
+ pthread-join_status.ret = NULL;
+ pthread-join_status.error = 0;
}
pthread-cancelflags |= PTHREAD_CANCELLING;
PTHREAD_NEW_STATE(pthread, PS_RUNNING);
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], David O'Brien cleopede: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. Too bad strcmp wasn't named strdiff--just think of all the hassle that would have prevented over the years... Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Wed, Mar 06, 2002 at 11:43:16AM -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: On Tuesday 05 March 2002 06:32 pm, Zhihui Zhang wrote: I apologize for all who have followed this. I made a typo in the original email. What I observed is that writing LESS performs WORSE. Since all blocks are laid out contiguously and I write them sequentially, there should not be any seek problem. Hmmm . . . perhaps I misunderstood you, but I thought that you said that in the original mail that you were writing to the same number of disk blocks eiteher way but in some cases you were writing partial blocks and in some cases full blocks. How do you do that if you don't seek? If you aren't seeking, then you must be, in the slower case, writing partial blocks. Well, there is some size where the disk has physical blocks. On some disks, writes are always done in full physical blocks. To write a partial block, the block is read from disk, the data to be written is substituted and then the entire block is written. This would certainly be likely to be slower than writing a whole block. In the case of partial block writes, I move to the next block which is contiguous to the current block. So the start address of each write in both cases are exactly the same. The only difference is that one write full blocks, the other write partial blocks. I also do not read anything during the partial block write, and I think the disk controller should not do that either. If 'moving to the next block' means a seek, that is, if write_block() seeks forward, then maybe this part of an earlier message in the thread by Brian T.Schellenberger would be helpful: : If, however, the later mail is right and the earlier mail is wrong, this : *would* be easily explained: Many disks have optimization for the case of : linear writes and seeking slows them down a *lot*. Why? Because it's very : common to do linear writes, and it make sense to optimize the common case. Besides the linear optimization case, which would definitely slow down the seeking (second method), please do try to factor caching out of the equation, as several people suggested several times, by transferring much more data, like a couple of GB or at least twice as much as your physical memory, and post the results of that. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because thit is not a word. msg32500/pgp0.pgp Description: PGP signature
Re: A weird disk behaviour
On Wed, 6 Mar 2002, Peter Edwards wrote: Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? First off, I am not writing through any file system. I access the raw device directly. Secondly, the bytes written are always a multiple of 512 bytes. If one sector is the I/O unit of a disk controller, why should it read anything to prevent overwritten? -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
[ Moving this thread over to -chat as well. We'll get them all over in time ] Raymond Wiker writes: Giorgos Keramidas writes: Well, to be frank, I've seen a few C++ coding style documents, that suggest avoiding stdout.h altogether when writing in C++. I assume you mean stdio.h? Anyway, I *really* can't see any reason not to use iostream, fstream, sstream and friends. The fact that the programmer has no control over *how* the data is displayed, and relies on the person who wrote the class to display the data is one good reason. iostreams gives all the control the the person who writes the class, so in order to print things out, you have to extend the class (which often means peeking into it's private data, a violation of layering), or doing all sort of kludges/hacks to get things working. I also cannot see any reason not to use exceptions, the standard containers, the string classes etc. Because exceptions are *still* not portable across multiple platforms. There are N different implementations of exceptions, 'standard containers', and all behave slightly different. IMO, this is probably the biggest single stumbling block for using C++ extended features. Very few people know how to use these features correctly, and since they were so unportable, they are essentially unused except by those folks who worked very hard at using them, and as such have a higher clue-factor than most. Used properly, these make it possible to write code that is inherently safer than anything built around printf/scanf, char *, longjump, etc. Without these (and a few others) you may just as well stay with standard C. Safer? The intracacies of printf/scanf are *well* known, so I wouldn't say that it's any more/less safe. At least with the above functions, you *know* ahead of time the issues, vs. some random implementation of a class you don't want to look at. Exceptions are great, but there are too many gotchas because the behavior is not standardizes well enough to depend on them. (And, if you're not careful, you can cause yourself *all* sorts of problems using them.) Then again, if you want to do object-oriented programming, C++ is probably not the right choice. If you want to use several different paradigms simulataneously in one language, C++ may be a better fit - although Common Lisp is a much better choice :-) Except that it's *obnoxiously* hard to deploy it. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
I need hack, I would like a clock like the xdaliclock but reads the time out in HEX.
Does someone have this availale already. I am not a programer, but wish I could. There is a lot of neet things I would like to try. But I can't afford to take night classes as of this time If there is anyone out there that could mentor me in C or C++ ( I have minimal exposure to these.) I have looked a Python and found it a bit confusing not having to delare everything and aslo it has no unary opperator. Is there a Master Yoda sensing a disturbance in the force? Until then... So long, and thanks for all the fish! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Wed, Mar 06, 2002 at 12:12:44PM -0500, Zhihui Zhang wrote: On Wed, 6 Mar 2002, Peter Edwards wrote: Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? First off, I am not writing through any file system. I access the raw device directly. Secondly, the bytes written are always a multiple of 512 bytes. If one sector is the I/O unit of a disk controller, why should it read anything to prevent overwritten? I think Peter was referring to the (more common IMHO) case when one sector was not quite the I/O unit of the disk controller, especially WRT caching. That is, the disk controller does not actually do a physical disk write for each and every sector, but only in larger blocks. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI msg32504/pgp0.pgp Description: PGP signature
Re: A weird disk behaviour
Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? This was *exactly* my experience in FreeBSD 3.2, which was the last time I looked into this in detail. The performance of writing full blocks instead of partitial blocks was at least an order of magnitude better. (By blocks here I mean the size the filesystem was formatted with, the -b parameter to newfs.) I found that a filesystem formatted as -b8192 -f8192 performed so much faster than the usual -b8192 -f1024 that it was well worth taking the hit in wasted allocation space for small files. When I instrumented code in various places to try to track down why there was such a huge difference when fragsize != blocksize I found that the killer was repeated read-modify-write cycles, especially on filesystem metadata. Creating a file and writing a few bytes to it could result in dozens of blocks read then written, and some of the blocks got re-read several times in the process. It was always a mystery to me why the same sectors would get read over and over again (isn't that what buffer and filesystem caches are for?) But I know for certain the physical reads were happening because the instrumentation for that was in a custom raid driver of our own. But, FreeBSD 3.2 is ancient history now, I have no idea whether filesystem performance is still this bad (and surely softupdates would ameliorate this problem anyway). Also, this may not be relevant to Zhilhui Zang's situation because filesystem behavior is probably different than working directly with the /dev/da device. (Or maybe not, I guess there must be an implied blocksize from an incore disklabel or something.) It would be interesting to see if formatting a filesystem with blocksize == fragsize still makes a big difference in performance these days, but I remember all the instrumentation I had to do to prove the read-modify-write was happening last time being a BIG hassle, and nobody is paying me to do it anymore. :-) -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
and here is the output generated in /var/tmp -DSUPD=641 -DUPD=641 -I. -I.. -I../../../.. -I../../../../inc -I../../../../unxfbsd.pro/idl -I../../../../unxfbsd.pro/inc -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/idl -I/usr/ports/editors/openoffice-work/work/oo_641c_src/solver/641/unxfbsd.pro/inc -O../../../../unxfbsd.pro/ucr/com/sun/star/lang ArrayIndexOutOfBoundsException.idl ClassNotFoundException.idl DisposedException.idl EventObject.idl IllegalAccessException.idl etc ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Wed, 6 Mar 2002, Ian wrote: Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? This was *exactly* my experience in FreeBSD 3.2, which was the last time I looked into this in detail. The performance of writing full blocks instead of partitial blocks was at least an order of magnitude better. (By blocks here I mean the size the filesystem was formatted with, the -b parameter to newfs.) I found that a filesystem formatted as -b8192 -f8192 performed so much faster than the usual -b8192 -f1024 that it was well worth taking the hit in wasted allocation space for small files. When I instrumented code in various places to try to track down why there was such a huge difference when fragsize != blocksize I found that the killer was repeated read-modify-write cycles, especially on filesystem metadata. Creating a file and writing a few bytes to it could result in dozens of blocks read then written, and some of the blocks got re-read several times in the process. It was always a mystery to me why the same sectors would get read over and over again (isn't that what buffer and filesystem caches are for?) But I know for certain the physical reads were happening because the instrumentation for that was in a custom raid driver of our own. Could you tell me where is your custom raid driver? I mean, is it part of the operating system or inside the disk controller? But, FreeBSD 3.2 is ancient history now, I have no idea whether filesystem performance is still this bad (and surely softupdates would ameliorate this problem anyway). Also, this may not be relevant to Zhilhui Zang's situation because filesystem behavior is probably different than working directly with the /dev/da device. (Or maybe not, I guess there must be an implied blocksize from an incore disklabel or something.) I feel that the slowness of the file system is due to its sort of out-of-date on-disk structures. Many modern file systems are use B+tree nowadays. Softupdate helps a lot, but it can not solve the problem completely. It would be interesting to see if formatting a filesystem with blocksize == fragsize still makes a big difference in performance these days, but I remember all the instrumentation I had to do to prove the read-modify-write was happening last time being a BIG hassle, and nobody is paying me to do it anymore. :-) -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Wed, 6 Mar 2002, Peter Pentchev wrote: On Wed, Mar 06, 2002 at 12:12:44PM -0500, Zhihui Zhang wrote: On Wed, 6 Mar 2002, Peter Edwards wrote: Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? First off, I am not writing through any file system. I access the raw device directly. Secondly, the bytes written are always a multiple of 512 bytes. If one sector is the I/O unit of a disk controller, why should it read anything to prevent overwritten? I think Peter was referring to the (more common IMHO) case when one sector was not quite the I/O unit of the disk controller, especially WRT caching. That is, the disk controller does not actually do a physical disk write for each and every sector, but only in larger blocks. This makes sense. So you are saying that the read-modify-write cycle actually happens within the disk controller? If so, I would love to know the unit of the disk controller I/O to avoid it! -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
hi Daniel, + pthread-join_status.thread = NULL; + pthread-join_status.ret = NULL; + pthread-join_status.error = 0; it still hangs :-( How should a detach routine in the client code look like ? Does the client have to catch a signal or something ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 11:37:42AM +0100, Poul-Henning Kamp wrote: Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: It does not matter. Style(9) does not [intentionally] avoid PHK's pet peeves. It documents the style used by the CSRG with some modernizations. All this IMO does not matter as much as showing actual code examples from /sys. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: please remove blank line
The coding style guide for freebsd says that a blank line shalll be above the code and below teh variable declarations.. most peopple take this to read that the blank line still appears if there are no variables. I'm sorry if this offends your personal style, but a group has to have SME style guide and we all use this one when writing for FreeBSD even if we have our own syles for different code.. otherwise it would get unreadable. On Wed, 6 Mar 2002, David Xu wrote: could anyone remove a blank line in /sys/kern/kern_sysctl.c ? in FreeBSD 4.5 STABLE, it's at line 151, function sysctl_ctx_init(). -- David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote: hi Daniel, + pthread-join_status.thread = NULL; + pthread-join_status.ret = NULL; + pthread-join_status.error = 0; it still hangs :-( Actually, the patch I gave you to uthread_detach was wrong. Here is the correct one (apply by hand if you have to). Index: uthread_detach.c === RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_detach.c,v retrieving revision 1.16 diff -u -r1.16 uthread_detach.c --- uthread_detach.c2001/05/20 23:08:32 1.16 +++ uthread_detach.c2002/03/06 19:00:17 @@ -66,7 +66,9 @@ PTHREAD_NEW_STATE(joiner, PS_RUNNING); /* Set the return value for the woken thread: */ - joiner-error = ESRCH; + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; /* * Disconnect the joiner from the thread being detached: How should a detach routine in the client code look like ? Does the client have to catch a signal or something ? No, there is no signal. BTW, if the code is expecting a signal to interrupt a join operation, it is wrong. A thread that is in a join can catch a signal, but if it returns from the signal handler normally (without longjmp'ing out of it) then it resumes the join operation. That is why there is a loop in uthread_join.c. It is to allow the thread to execute a signal handler and when it returns it will resume the join operation. Removing the loop breaks signal handling. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message p0510150fb8ac11d15f26@[128.113.24.47], Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
disks don't work in 512 byte blocks. they work inTRACKS these days.. if you ask for an entire track to be written, that is almost certainly quicker than if you ask for every 2ns block in that track to be written because the second option requires that it read the track first. ALso the seek may trigger code that asks the drive to start syncing to disk while it may hold off doing so if you do a sequential write. Just some ideas.. On Wed, 6 Mar 2002, Zhihui Zhang wrote: On Wed, 6 Mar 2002, Peter Edwards wrote: Zhihui Zhang wrote: snip ... I also do not read anything during the partial block write, and I think the disk controller should not do that either. If you do a partial block write, surely at some point the block must be read in order to preserve that segment of data you are _not_ overwriting? First off, I am not writing through any file system. I access the raw device directly. Secondly, the bytes written are always a multiple of 512 bytes. If one sector is the I/O unit of a disk controller, why should it read anything to prevent overwritten? -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, 6 Mar 2002, Martin Blapp wrote: Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) OK, I just committed the fixes. Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? I don't know enough about how and when OSVERSION is suppose to change to make that call. See if there is anything in the handbook about it. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: aio_read() oddness
Note: Please cc replies to me as I'm not currently subscribed. Kip Macy [EMAIL PROTECTED] wrote: FreeBSD does not support queued signals (part of RT Posix) which is required for this. -Kip I guess I'll have to take a look at kqueues then. On a similar note, I was wondering why FreeBSD declares the sigval union with the following members: int sigval_int; void*sigval_ptr; when other operating systems (namely Solaris and Irix) declare it with something like: int32_t sival_int; caddr32_t sival_ptr; The difference I'm refering to is the member names, sival versus sigval. (The above snippet is from Solaris's sys/siginfo.h) Is there some reason I don't know about for FreeBSD doing it differently? Tony Arcieri To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: aio_read() oddness
I'd asked myself the same thing. In code that uses it I have to do an #ifdef FreeBSD. My guess was that it was because it is more conformant with the structure name and no one of consequence noticed because the underlying functionality is not really there. -Kip = For RAIDANT status see: http://cranford.eng.netapp.com:8080/cgi-bin/ant4/index.cgi To submit RAIDANT test descriptions go to: http://web.netapp.com/engineering/projects/raidv2/testing/ Ontap on the web: http://web.netapp.com/engineering/projects/raidv2/testing/global/ On Wed, 6 Mar 2002, Tony Arcieri wrote: Note: Please cc replies to me as I'm not currently subscribed. Kip Macy [EMAIL PROTECTED] wrote: FreeBSD does not support queued signals (part of RT Posix) which is required for this. -Kip I guess I'll have to take a look at kqueues then. On a similar note, I was wondering why FreeBSD declares the sigval union with the following members: int sigval_int; void*sigval_ptr; when other operating systems (namely Solaris and Irix) declare it with something like: int32_t sival_int; caddr32_t sival_ptr; The difference I'm refering to is the member names, sival versus sigval. (The above snippet is from Solaris's sys/siginfo.h) Is there some reason I don't know about for FreeBSD doing it differently? Tony Arcieri To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
When I instrumented code in various places to try to track down why there was such a huge difference when fragsize != blocksize I found that the killer was repeated read-modify-write cycles, especially on filesystem metadata. Creating a file and writing a few bytes to it could result in dozens of blocks read then written, and some of the blocks got re-read several times in the process. It was always a mystery to me why the same sectors would get read over and over again (isn't that what buffer and filesystem caches are for?) But I know for certain the physical reads were happening because the instrumentation for that was in a custom raid driver of our own. Could you tell me where is your custom raid driver? I mean, is it part of the operating system or inside the disk controller? It was custom hardware and software for an embedded system. We had a motherboard with 18 adaptec AIC 78xx chips on it, and our own software raid layer (modified freebsd kernel) that did special-purpose stuff (striping and error recovery using custom parity-generating hardware also on the mobo). I mentioned the raid driver only as a way of indicating that I was sure I was instrumenting real physical IO at the very lowest talk-to-the-drive layer, and I was seeing read-modify-write cycles at that layer that indicated the same sectors were being read over and over again (filesystem metadata sectors) during the higher-level operation of create-file, write 1 byte to file, close file. -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Mike Meyer wrote: Joe Halpin [EMAIL PROTECTED] types: 1. C++ is a more difficult language than C because it does more stuff than C. Ditto vs Java. No, it doesn't do more stuff than C, Neither does Java. See the Church-Turing thesis. Java and C++ are harder to learn because they have more *features* than C. Sorry, I thought had more features was something like did more. For example, assembly language doesn't do anything Python can't, but Python does more (at least, per statement) than assembly language. I'm not sure I understand your point. Are you trying to say that all Turing complete languages are equally difficult? For years I have been seeing this assertion on the net over and over. I still don't see the expected result (ie, Java applications displacing C/C++ applications). I see it happening, then the products vanish because they can't compete on a speed basis. VM's were a good idea when UCSD did it back in the mid 70s. I think the hardware is fast enough to support it now, but you've got to tie the parts together write. So are you agreeing with me? My experience is that most performance problems come about from the way something was coded, not the language it was coded in. Even in Java, you can do JNI functions if performance is really an issue. Python is succeeding in some strange places, because it's trivial to take a collection of subroutines that deal with a data structure they pass back and forth as arguments, and turn it into a Python object. Which means you get to play with those complex, compiled environments in an interpreted environment that could be used as a shell, if you were really crazy. Don't know anything about Python. How does this affect C vs C++? Or Java vs C++? or perfomance, or ... ? Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HEX.
minimal exposure to these.) I have looked a Python and found it a bit confusing not having to delare everything and aslo it has no unary opperator. All languages have unary operators - at the very least negate, both loagical and arithmeatic. Most modern ones have a boolean negate as well. Is there a Master Yoda sensing a disturbance in the force? Well, Python 2.0 has unary assignment operators if that's what you meant. Personally, I think python is the most readable thing I've found, and would gladly write you such a tool just to show off python, except I'm currently bedridden and can't get access ot a machine with an X server to test it on. If you still don't have one in two weeks, drop me a note about it, as I should be up and about by then. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kqueue example code - suggestions?
On Wed, 6 Mar 2002, Conrad Sabatier wrote: Could anyone suggest a package I might look at to get an example of real world kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). misc/wait_on (not yet committed - ports/34414). Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sun idlc broken with our libc_r [Please help]
On Wed, Mar 06, 2002 at 02:31:32PM -0500, Daniel Eischen wrote: On Wed, 6 Mar 2002, Martin Blapp wrote: Thanks Daniel ! + joiner-join_status.error = ESRCH; + joiner-join_status.ret = NULL; + joiner-join_status.thread = NULL; Oh wonder. It works no like a charm. :-)) OK, I just committed the fixes. Do you know in what case we can bump the osversion ? Is this one case we can do it so I could check the OSVERSION in the port ? I don't know enough about how and when OSVERSION is suppose to change to make that call. See if there is anything in the handbook about it. There's no harm in bumping OSVERSION frequently (but don't go overboard). If there's something out there which needs to differentiate between versions older and newer than a certain version of the OS, it's appropriate to bump OSVERSION. Kris msg32525/pgp0.pgp Description: PGP signature
Re: A weird disk behaviour
On Wednesday 06 March 2002 11:43 am, Zhihui Zhang wrote: | In the case of partial block writes, I move to the next block which is | contiguous to the current block. So the start address of each write in | both cases are exactly the same. The only difference is that one write | full blocks, the other write partial blocks. I also do not read anything | during the partial block write, and I think the disk controller should not | do that either. I guess this was settled pretty well by later mail while I was off-line but, yes, that's exactly what I would suspect is happening. -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
in_pcblookup_hash() called multiple times
There are redundant calls to the in_pcblookup_hash() in the ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the ip_input path. Would it be useful to modify the (*pr_input) function pointer in the struct ipprotosw to take a fourth argument (perhaps it should be cast to a void * to keep it generalized?) to pass the pre-looked-up struct inpcb * to TCP, if the lookup has already been done? Profiling indicates that this is one of the most expensive calls in the code path, particularly when there are a lot of sockets open. Increasing the hash table size only works so far; at a lot, the number of connections makes the lookup expensive anyway (it's a linear traversal of the collision chain for the bucket). Since there are reasons other than firewalling to do the lookup early, it seems that it would be useful to pass a pointer the a pointer that was non-NULL, if the lookup had already taken place. For example, moving the ipflow to use an overlay structure for the inpcb would mean that a single lookup was used for fast forwarding, firewalling, and inpcb identification for tcpcb retrieval for TCP. Note that I'm only talking about the packet input path here, at this time, so the firewall code isn't really generalizable (the inpcb is already known on output, except to the ip_fw code; it probably doesn't make sense to push knwledge of it into the ip_output path, at least without more thought). Right now, I'm just talking about a way ip_input could pass the already looked up input inpcb to tcp_input, udp_input, or udp_ctlinput -- all of which repeat the lookup operation. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in_pcblookup_hash() called multiple times
sounds good.. can you send us a patch to look at? On Wed, 6 Mar 2002, Terry Lambert wrote: There are redundant calls to the in_pcblookup_hash() in the ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the ip_input path. Would it be useful to modify the (*pr_input) function pointer in the struct ipprotosw to take a fourth argument (perhaps it should be cast to a void * to keep it generalized?) to pass the pre-looked-up struct inpcb * to TCP, if the lookup has already been done? Profiling indicates that this is one of the most expensive calls in the code path, particularly when there are a lot of sockets open. Increasing the hash table size only works so far; at a lot, the number of connections makes the lookup expensive anyway (it's a linear traversal of the collision chain for the bucket). Since there are reasons other than firewalling to do the lookup early, it seems that it would be useful to pass a pointer the a pointer that was non-NULL, if the lookup had already taken place. For example, moving the ipflow to use an overlay structure for the inpcb would mean that a single lookup was used for fast forwarding, firewalling, and inpcb identification for tcpcb retrieval for TCP. Note that I'm only talking about the packet input path here, at this time, so the firewall code isn't really generalizable (the inpcb is already known on output, except to the ip_fw code; it probably doesn't make sense to push knwledge of it into the ip_output path, at least without more thought). Right now, I'm just talking about a way ip_input could pass the already looked up input inpcb to tcp_input, udp_input, or udp_ctlinput -- all of which repeat the lookup operation. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Terry Lambert wrote: Kenneth Culver wrote: Why are you being so sarcastic? Everyone here is assuming that it's harder to write C++ code, so you should only use it if necessary. It isn't necessary to use it for something like a daemon. Because that underlying assumption is false, and I'm making fun of it. If you don't use C++ specific features, you're just writing C code anyway. Not exactly. There are semantic differences even in the code looking just like C. It's not harder to write C++ code that uses the special features of the language; it may be harder for a programmer unfamiliar Yes, it is. To make things right with these features you need to write a few times more lines of code. This gives you a few times more opportunities to make mistakes and requires a few times more of testing. There are a lot of benefits to the use of C++ that outweigh the downside, particularly if you are a company paying for Sure, as long as your project grows big enough, the benefits start outweighing the troubles. something, and you want to invest the value in the code base instead of investing it in people who can walk out the door and sign with your competition tomorrow. Makes no difference in this respect. You have the codebase anyway and you need people who understand it anyway too. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
netgear GA622T problem
I have several machines with Netgear GA622T. They all run FreeBSD 4.5-REL and are connected via a Netgear gigabit switch. My problem is that the nge driver more often than not does not bring up the link. The cards are always detected but the link LED does not come up. I wonder if any one else has this problem. Thanks. John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Lowell Gilbert [EMAIL PROTECTED] wrote:
C-99 requires a fully specified type before the unspecified array (and
requires said array to be the last element in the structure). So this
example is *not* valid in C99, but the following would be:
struct foo {
int bar;
char array[];
};
[Which makes sense; it forces a structure to have a non-zero size.]
Although there has been some discussion in the committee about allowing
zero-sized objects in C, the standard doesn't allow them. This is perhaps
why it doesn't follow gcc's [0] syntax for variable length arrays at the
end of structures.
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST OR SOUTHWEST 5 TO 7 DECREASING 4.
DRIZZLE DYING OUT. MODERATE, OCCASIONALLY POOR, BECOMING GOOD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. How much bitching do we get because CVSup is written in Modula-3? It is a type-safer language than C. It has some OO-like constructs and its threading model and GUI lib allow JDP to quickly create a really nice application. But all the benefits of Modula-3 are lost on the I only do C crowd that is demanding CVSup be rewritten. Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. I'll go away now. thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 02:37:45PM -0500, Garance A Drosihn wrote: At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... Implies??? I thought I was quite explicit: to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. ! is pronounced NOT. When read if not string compare a with b then do X, is the opposite of the the logic of the expression does. Which is if string compare a with b is equal then do X. [if (strcmp(a,b) == 0)] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
David O'Brien says: On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: ... application. But all the benefits of Modula-3 are lost on the I only do C crowd that is demanding CVSup be rewritten. If all you have is a hammer... everything looks like a nail. -- Diane Bruce, http://www.db.net/~db [EMAIL PROTECTED] --- I got bored with the last witty aphorism. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. Then they aren't hackers. I'm certainly willing to learn new language. I generally relish the opportunity. The trick is finding employers who are willing to let me do that, or tasks I want to do that the language in question is the proper tool. Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. That is true. C++ is as ugly as C, but has all the problems of Object Orient Languages. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Mar 06, at 07:17 PM, David O'Brien wrote: On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. How much bitching do we get because CVSup is written in Modula-3? It is a type-safer language than C. It has some OO-like constructs and its threading model and GUI lib allow JDP to quickly create a really nice application. But all the benefits of Modula-3 are lost on the I only do C crowd that is demanding CVSup be rewritten. First, you're ascribing me to a group I don't belong. While I don't know Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I bitch about such-and-such being written with them (well, not publicly, anyway). Many's the time I've wanted to modify a program written in a language I didn't/don't know, and learned enough of it to re-write it in a language I do know, just to do the changes I wanted. Second, you're not addressing my comments at all. I maintain that the creators of C++ should have either created yet another OOPL, or advocated any of the existing ones. Taking a procedural language, particularly one as accepted and popular as C, and wreaking havoc on it (IMHO) to produce another, was a gross mis-step. Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. By whom? C programmers? If you're even half-right, their logic was flawed - the general concensus that I'm aware of is that most C folk think little of C++. I won't address the opinions of PHBs who didn't get much further than flow-charts, or the C++ folk who hadn't experience with C when they learned C++, if either of those groups are the people you're writing of. I'll go away now. thank you. Snideness doesn't get you anything but. Dave Don't mess with me, I'm not a zealot. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Hey, devnull, if you're gonna perticipate, the least you could do is present a mailing address that accepts mail. *sheesh* Dave -- Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] wrote: I had a discussion with Eric Allman about this very thing recently where he advocated everything inside if, while, for and so on should be true booleans. Now, IFF the C language had a type called boolean that would make a lot of sense. Unfortunately, it does not (at present ?) have a boolean type, and while one could simulate it with typedefs, there is no way to get the compiler to enforce the rule. C99 has a boolean type, but neither the comparison operators nor the logical operators nor the ! operator return a bool, and conditional contexts (like if, while, ?:) don't expect a bool. Pretty useless, really. Tony. -- f.a.n.finch [EMAIL PROTECTED] ROCKALL: WEST BACKING SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST, DECREASING 5 FOR A TIME. OCCASIONAL RAIN. MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
D J Hawkey Jr wrote: Second, you're not addressing my comments at all. I maintain that the creators of C++ should have either created yet another OOPL, or advocated any of the existing ones. Taking a procedural language, particularly one as accepted and popular as C, and wreaking havoc on it (IMHO) to produce another, was a gross mis-step. I guess I won't wax nostalgic about the merits of RATFOR... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: BPF - Locally Generated Packet Reception
It could be that this fails for interfaces that perform hardware loopback, since it relies on the behavior of software loop. There may also be some other circumstances where this occurs. Basically, the BPF device can tell it's locally sourced because it has a NULL interface pointer associated with it. If the packet ends up with a none-NULL interface pointer for some reason, it will be considered a non-locally sourced packet. In practice, we've used this successfully on a variety of ethernet devices -- which interface type are you using? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Wed, 6 Mar 2002, Rajesh P Jain wrote: Hi, In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an interface to send and receive packets, there is an ioctl parameter BIOCSSEESENT, which is by default set to 1. Hence the packets both from remote systems and locally generated are received. If locally generated packets needs to be filtered, we can use the option BIOCSSEESENT and set the value to 0. But even after setting this value to 0 (using the ioctl call), the locally generated packets are received. Am I missing something ? Plese throw light on this issue. TIA Raj Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] wrote: Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? If that is ok, then why is p = malloc(sizeof(*p)); if (!p) return ENOMEM; not ok, given that is even more well-defined? I am of the opinion that expressions in a conditional context (i.e. argument of ! || ?: if while) should be boolean-valued (i.e. either 0 or 1 corresponding to false or true). If they aren't then an appropriate comparison should be done. Tony. -- f.a.n.finch [EMAIL PROTECTED] FAEROES SOUTHEAST ICELAND: EASTERLY, BECOMING CYCLONIC THEN WESTERLY, 4 OR 5. SNOW OR SNOW SHOWERS. GOOD OCCASIONALLY POOR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On March 06, 2002 at 19:17, David O'Brien wrote: *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. How much bitching do we get because CVSup is written in Modula-3? It is a My only problem with modula-3 was the lack of compiler support on alternative platforms. I couldn't figure out how to port the one I found (well, I figured it out: it was a _huge_ amount of work). Now, Oberon, there's a language! Byron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HE
Thank you for the kind reply Mike. I have been shown the elitist attude by others at times, and man I tell you its can bring a buy down. On March 6, 2002 04:54 pm, you wrote: minimal exposure to these.) I have looked a Python and found it a bit confusing not having to delare everything and aslo it has no unary opperator. All languages have unary operators - at the very least negate, both loagical and arithmeatic. Most modern ones have a boolean negate as well. My comment was't meant to knock Python. I have read about Python and very much like what I have read. Just to tell you where I am coming from. I have taken a ten week night class in C++ 2 years ago. This was my first experience with programming. This just gave me the basics like , looping, functions, arrays, pointers as such. Since coming to Freebsd unix I found the majority of things is done in C. So I picked up the book Teach yourself C in 21 Days. Things are different here but they do make sense. Now looking at Python books things are a lot differently done. like how do you do a for loop as you would in C or C++. for ( x=0: x 10 ; x ++ ) Is the ++ not the unary operator? What is the same thing in Python? Maybe Sams will put out a Teach Yourself Python in 21 Days. I'd like to learn Perl as well but good books for newbies are hard to find. Is there a Master Yoda sensing a disturbance in the force? Well, Python 2.0 has unary assignment operators if that's what you meant. Personally, I think python is the most readable thing I've found, and would gladly write you such a tool just to show off python, except I'm currently bedridden and can't get access ot a machine with an X server to test it on. If you still don't have one in two weeks, drop me a note about it, as I should be up and about by then. I would appriciate that so much. I would really like to learn a language that I could use to make things when I want. Like a clock that reads out in HEX. My day job, I drive transport truck. I could see writing a program for the palm pilot for other truck drivers to do their daily log book calculations. I will pray that you gett better real soon Mike. Take care. Paul... mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
D J Hawkey Jr [EMAIL PROTECTED] types: First, you're ascribing me to a group I don't belong. While I don't know Eiffel, or Lisp, or Modula, Snobol, etc., I don't demean them, nor do I bitch about such-and-such being written with them (well, not publicly, anyway). Many's the time I've wanted to modify a program written in a language I didn't/don't know, and learned enough of it to re-write it in a language I do know, just to do the changes I wanted. Ack! That makes believe the comments about people not wanting to learn new languages. I would do it the other way around, and learn enough of the language it's written in to make the changes I wanted. In fact, I think that's a good way to learn a language, providing you have a stylisticly good example to start with. I'll leave the conclusions to be drawn about Linux from that to someone else. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Try this text instead: In C, there is no boolean type but there are boolean concepts, contexts that express or test yes/no, good/bad, error/success, pointer initialized/not initialized, object created/not created, and so on. Where a conceptually boolean operand is expected and you have a value that is not conceptually boolean, use an operator (e.g., ==, !=) that translates the operand to something that is conceptually boolean. This applies to if expressions, the operand of !, function parameters that want a conceptually boolean value, and so on. This is actually a special case of a more general rule, which might be stated: saving a few keystrokes but violating the expectations of strangers reading your code is not a good way to write maintainable code. Ensure that the code and your intention are congruent *in the mind of your readers*. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], David O'Brien writes: Implies??? I thought I was quite explicit: to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. ! is pronounced NOT. When read if not string compare a with b then do X, is the opposite of the the logic of the expression does. Which is if string compare a with b is equal then do X. [if (strcmp(a,b) == 0)] Well, we're clearly into IMO land here, so lets ignore that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message: p05101510b8ac2005b34b@[128.113.24.47] Garance A Drosihn [EMAIL PROTECTED] writes: : At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: : Garance A Drosihn writes: : In one message, : At 12:52 AM -0800 3/6/02, David O'Brien wrote: : I don't think it is clarifying a rule. I think it is in fact adding : a rule. You are extrapolating too much I think. All the rule is : trying to prevent is if (!strcmp(a,b)) which when read is extremely : wrong of that is actually happening. : : If we change boolean to integer, then the proposed rule will not : prevent if (!strcmp(a,b)) , because strcmp() *does* return an : integer value. Or am I missing something here? : : Right, and since the integer is well defined, : if (!strcmp(a, b)) : is perfectly understandable so what is the problem ? : : Well, that's my question. David's comment implies that it is not : good to do '!strcmp()', and I was wondering why it is not good... if (strcmp()) is the problem with if (!strcmp()) Which one is right? The first one should mean are the same but really means are different and likewise for the second one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], M. Warner Losh writes : : Well, that's my question. David's comment implies that it is not : good to do '!strcmp()', and I was wondering why it is not good... if (strcmp()) is the problem with if (!strcmp()) Which one is right? The first one should mean are the same but really means are different and likewise for the second one. Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I need hack, I would like a clock like the xdaliclock but reads the time out in HE
On Wednesday 06 March 2002 11:38 pm, Paul C. Boyle wrote: | Thank you for the kind reply Mike. | I have been shown the elitist attude by others at times, | and man I tell you its can bring a buy down. | | On March 6, 2002 04:54 pm, you wrote: | minimal exposure to these.) I have looked a Python and found it a bit | confusing not having to delare everything and aslo it has no unary | opperator. | | All languages have unary operators - at the very least negate, both | loagical and arithmeatic. Most modern ones have a boolean negate as | well. | | My comment was't meant to knock Python. I have read about Python and | very much like what I have read. | Just to tell you where I am coming from. I have taken a ten week night | class in C++ 2 years ago. This was my first experience with programming. | This just gave me the basics like , looping, functions, arrays, pointers as | such. Since coming to Freebsd unix I found the majority of things is done | in C. So I picked up the book Teach yourself C in 21 Days. Things are | different here but they do make sense. | Now looking at Python books things are a lot differently done. | like how do you do a for loop as you would in C or C++. | | for ( x=0: x 10 ; x ++ ) | | Is the ++ not the unary operator? No, ++ is *a* unary operator, not *the* unary operator. -- is another. - is another. ! is another. ~ is another. There are a bunch: a unary operator is any operator that takes a single operand, just as a binary operator is an operator that takes two operaands.And a ternary operator is an operator that takes three operands. (There is a ternary operator, though; of commonly-used languages, C is unique in having a ternary operator, and it only has one of them: the ? : operator.) Python doesn't have pre- and post- inrement- and decrment? Well, neither do most languages--they are pretty much a quirky C construct created, I suspect because they correlated to PDP-11 machine instructions (addressing modes), which has since infiltrated a number of other languages. But the lack of same is hardly a big deal. It'll cost you just a few keystrokes. OTOH, I do rather like x += 1 -- I think it clarifies what's going on as compared to x = x + 1 . . . . -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RouteD is limited - how can I?
Hi All, With help from teh questions group I have managed to run RIPV2 on a single NIC computer using the following command routed -s ripv2 However, there are several aliased IP addresses on this interface and they are being advertized and found in the RIP table. Now I want to exclude one of the aliased addresses from being advertized. I have tried to put the following in my /etc/gateways file, net 0.0.0.0 gateway x.x.x.x metric 16 extern where x.x.x.x is the alias that I want to exclude, but it doesn't do the job. Can you guide me on how I can remove a network from the advertized list? thanks in advance ~koroush ps. please CC me on the reply To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Thu, Mar 07, 2002 at 07:14:49AM +0100, Poul-Henning Kamp wrote: Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... We are not trying to hide anything. Style(9) says to don't do that, so we shouldn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: please remove blank line
On Wed, Mar 06, 2002 at 10:39:16AM -0800, Julian Elischer wrote: The coding style guide for freebsd says that a blank line shalll be above the code and below teh variable declarations.. most peopple take this to read that the blank line still appears if there are no variables. style(9): /* Insert an empty line if the function has no local variables. */ Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
