Re: 3.3 to 4.5 remote upgrade possible?
On Mon, Mar 04, 2002 at 11:03:47PM -0500 I heard the voice of Jim Durham, and lo! it spake thus: Is this Mission Impossible? I have no one at the site that can do this. If I say make installworld is the whole thing going to come to a grinding halt? When I did a 2.2.8-STABLE to 4.3-STABLE upgrade, I ended having to do it in one broken-up step. First (and the only sane way, IMO) is to do the buildworld on a 4.x system; get all those lib conflicts and crap out of the picture. Then I installed the 4.x kernel, did the necessary frobbing (installing loader, re-disklabel -B'ing, sd-da renames in /var with mknod, etc), booted up the 4.x kernel, THEN did the installworld, mergemaster, reboot. Some issues I found: - Some apps (portmap in particular) caused no end of trouble when the 2.2 app ran under the 4 kernel. Like, kernel-panic type trouble. - Device renamings are a bitch. In theory, a 3-4 upgrade should be easier than this, since you don't I think need to do any device renaming, which solves a bunch of my problems right off. I'd still be pretty leery about doing it remotely, though. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtime video capture/divx encoding (brooktree) beta testersrequired
At 7:48 Uhr +0100 05.03.2002, Steve O'Hara-Smith wrote: PS: I am more interested in mpeg1 than DivX because with mpeg1 the stream can be watched as it is being made. Would it help to hint it on the fly like it is done with mpeg4ip ? H. Btw, mpeg4ip did not compile here, 4.4 R, saw it on Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Extending loader(8) for loading kerels/modules split across several disks
Hi folks, Please review attached patch, which adds long overdue feature to our loader(8), allowing it to load sequence of files as a single object. This should allow us to lift 1.44M limit on compressed kernel for the installation diskette. Please note, that to use this feature to load gzip-compressed objects you need to split the object first and then compress each piece individually, not compress first and then split already compressed file. Therefore tight fitting of each piece to the 1.44M limit could be a little tricky, but not impossible. Other way around is to use kgzip(8) utility to compress kernel and then split it into pieces 1.44M each. If there are no objections I would like to commit it ASAP, so that our RE team is able to use this feature in the forthcoming 5.0-DP1 release. Any feedback is appreciated. -Maxim Index: src/lib/libstand/close.c === RCS file: /home/ncvs/src/lib/libstand/close.c,v retrieving revision 1.3 diff -d -u -r1.3 close.c --- src/lib/libstand/close.c30 Sep 2001 22:28:00 - 1.3 +++ src/lib/libstand/close.c5 Mar 2002 09:22:00 - @@ -88,6 +88,7 @@ if (f-f_devdata != NULL) devclose(f); f-f_flags = 0; +f-f_udata = NULL; if (err1) { errno = err1; return (-1); Index: src/lib/libstand/open.c === RCS file: /home/ncvs/src/lib/libstand/open.c,v retrieving revision 1.6 diff -d -u -r1.6 open.c --- src/lib/libstand/open.c 30 Sep 2001 22:28:01 - 1.6 +++ src/lib/libstand/open.c 5 Mar 2002 09:22:00 - @@ -108,6 +108,7 @@ f-f_ops = (struct fs_ops *)0; f-f_offset = 0; f-f_devdata = NULL; +f-f_udata = NULL; file = (char *)0; error = devopen(f, fname, file); if (error || Index: src/lib/libstand/stand.h === RCS file: /home/ncvs/src/lib/libstand/stand.h,v retrieving revision 1.28 diff -d -u -r1.28 stand.h --- src/lib/libstand/stand.h18 Feb 2002 20:35:19 - 1.28 +++ src/lib/libstand/stand.h5 Mar 2002 09:22:00 - @@ -164,6 +164,7 @@ char *f_rabuf; /* readahead buffer pointer */ size_t f_ralen;/* valid data in readahead buffer */ off_t f_raoffset; /* consumer offset in readahead buffer */ +void *f_udata; /* user data */ #define SOPEN_RASIZE 512 }; Index: src/sys/boot/alpha/libalpha/alpha_copy.c === RCS file: /home/ncvs/src/sys/boot/alpha/libalpha/alpha_copy.c,v retrieving revision 1.5 diff -d -u -r1.5 alpha_copy.c --- src/sys/boot/alpha/libalpha/alpha_copy.c3 Aug 2000 09:49:44 - 1.5 +++ src/sys/boot/alpha/libalpha/alpha_copy.c5 Mar 2002 09:22:00 - @@ -33,6 +33,7 @@ #include stand.h #include libalpha.h +#include sread.h ssize_t alpha_copyin(const void *src, vm_offset_t dest, const size_t len) @@ -51,7 +52,7 @@ ssize_t alpha_readin(const int fd, vm_offset_t dest, const size_t len) { -return(read(fd, (void *) dest, len)); +return(sread(fd, (void *) dest, len)); } Index: src/sys/boot/common/Makefile.inc === RCS file: /home/ncvs/src/sys/boot/common/Makefile.inc,v retrieving revision 1.12 diff -d -u -r1.12 Makefile.inc --- src/sys/boot/common/Makefile.inc27 Mar 2001 11:59:21 - 1.12 +++ src/sys/boot/common/Makefile.inc5 Mar 2002 09:22:00 - @@ -2,7 +2,7 @@ SRCS+= bcache.c boot.c commands.c console.c devopen.c interp.c SRCS+= interp_backslash.c interp_parse.c load_aout.c load_elf.c ls.c misc.c -SRCS+= module.c panic.c +SRCS+= module.c panic.c sread.c .if defined(LOADER_NET_SUPPORT) SRCS+= dev_net.c Index: src/sys/boot/common/boot.c === RCS file: /home/ncvs/src/sys/boot/common/boot.c,v retrieving revision 1.28 diff -d -u -r1.28 boot.c --- src/sys/boot/common/boot.c 11 Sep 2001 01:09:19 - 1.28 +++ src/sys/boot/common/boot.c 5 Mar 2002 09:22:00 - @@ -65,7 +65,7 @@ } /* find/load the kernel module */ - if (mod_loadkld(argv[1], argc - 2, argv + 2) != 0) + if (mod_loadkld(1, argv + 1, argc - 2, argv + 2) != 0) return(CMD_ERROR); /* we have consumed all arguments */ argc = 1; @@ -340,11 +340,11 @@ static int loadakernel(int try, int argc, char* argv[]) { -char *cp; +char *filesv[1]; - for (try = 0; (cp = getbootfile(try)) != NULL; try++) - if (mod_loadkld(cp, argc - 1, argv + 1) != 0) - printf(can't load '%s'\n, cp); + for (try = 0; (filesv[0] = getbootfile(try)) != NULL; try++) + if (mod_loadkld(1, filesv, argc - 1, argv + 1) != 0) + printf(can't load '%s'\n,
Invitation letter from the Organisation Committee of the First World Congress of Future Science and Culture
Dear Sir/Madam, Many of us who came to work in the sciences or similar areas did so because we wanted to explore the unknown and gain more knowledge and ultimately make this world a better place. It is undoubtedly true that modern science has brought immense benefits to humanity but also encountered many unsolved questions and problems including environmental pollution. Perhaps it is now time for a different approach: Falun Dafa takes a holistic view of life and the universe. It builds on the insights of modern science and combines them with the insights from ancient Chinese science and culture. We, scientists who understand Falun Dafa, invite you to participate in the First World Congress of Future Science and Culture that will be held at Cambridge on March 9th and 10th of 2002. This congress will see state of the art research in this field and serve as a forum for discussing how these new ideas could exert a profound influence on the future science and culture of humankind. Renowned specialists and professors in diverse academic disciplines from many different parts of the world will be participating. A schedule for March 9th is attached. On March 10 we will be holding an informal discussion session at which participants at the conference can raise issues with the speakers. We do hope that you will be able to find the time to attend. Please let us know if you have any questions. Yours sincerely, Dr Guihua Li Organisation Committee of First World Congress of Future Science and Culture [EMAIL PROTECTED] http://www.fsc-congress.org Invitation-Peter2.doc Description: MS-Word document
Re: cannot get more than 32 PTYs in 4.4-RELEASE
On Mon, 4 Mar 2002, Patrick Thomas wrote: In my kernel, I have: maxusers128 pseudo-device pty 128 Not sure if the above steps are actually required. Actually, neither matter. I duplicated your steps anyway, and was greeted with the same messages. However, In my /dev directory, I have used `sh MAKEDEV` to make all 256 /dev/pty files. They are all there, and all have correct major/minor numbers. I know I won't be using all 256 of them, but I just made them all anyway. I believe the above steps are wrong, looking at /dev/MAKEDEV: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; interestingly enough the command ./MAKEDEV pty3 will create (as indicated) heh.. I was assuming too much, something is screwy here. *confused* it actually only created 64 terminals. Added the line: 4) offset=192 name=t;; ~# ./MAKEDEV pty4 kill -HUP 1 interesting, now I have 96, but can only use 64. Reboot.. Anyone care to take over? In /etc/ptys, I didn't change anything, because all 256 pty entries are ALREADY in there: # Pseudo Terminals ttyp0 nonenetwork ttyp1 nonenetwork ... ttySu nonenetwork ttySv nonenetwork So those are all there. I have used `sysctl -a | grep maxuser` to verify that maxusers is indeed 128. BUT - if I log on via ssh and start screen, and start 31 new screen windows, then nobody else can log on to the system - I cannot create any more screen windows AND nobody else can ssh in - the machine has run out of ptys. I use `fstat` to inquire, and I am maxed out at exactly 32 ptys. SO THE question is, why am I stuck at 32 ptys ? I have done it all - everything that is in any doc or news post, and everything I was told to do here and on -hackers, and yet I am still stuck at 32 !!! Please tell me the secret lore for getting more than 32 ptys in 4.4-RELEASE. thanks, PT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Paul H. ___ http://dp.penix.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
C vs C++
Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Help! serious problem.
Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. Here's the kernel panic message: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Fatal trap 12: page fault while in kernel mode Mar 5 03:04:03 predator /kernel: fault virtual address = 0x0 Mar 5 03:04:03 predator /kernel: fault code= supervisor read, page not present Mar 5 03:04:03 predator /kernel: instruction pointer = 0x8:0x0 Mar 5 03:04:03 predator /kernel: stack pointer = 0x10:0xe75d5ea8 Mar 5 03:04:03 predator /kernel: frame pointer = 0x10:0xe75d5ebc Mar 5 03:04:03 predator /kernel: code segment = base 0x0, limit 0xf, type 0x1b Mar 5 03:04:03 predator /kernel: = DPL 0, pres 1, def32 1, gran 1 Mar 5 03:04:03 predator /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Mar 5 03:04:03 predator /kernel: current process = 4326 (ipfw) Mar 5 03:04:03 predator /kernel: interrupt mask= none Mar 5 03:04:03 predator /kernel: trap number = 12 Mar 5 03:04:03 predator /kernel: panic: page fault Mar 5 03:04:03 predator /kernel: Any ideas? Thanks! -- ICA Canada Online 2601 Matheson Blvd. E. Unit #29 Mississauga, Ontario L4W 5A8 (905) 624-8566 http://www.ica.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cannot get more than 32 PTYs in 4.4-RELEASE
dp *confused* Read URL:http://www.daemonnews.org/199902/answerman.html#ptys, I'm always running out of xterms because I have too many pseduo-ttys open. How can I increase my number of ptys? article at DaemonNews. You may find an example to create more ptys with MAKEDEV. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Help! serious problem.
On Tue, Mar 05, 2002 at 09:20:14AM -0500, ICA Canada Online wrote: Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. You are probably using an out of date kernel module. Use ls -l /modules to check the modules were all installed at the same time as the kernel. If you are uing the trafcount module from ports then you will need to recompile that also. (You should be able to use kldstat to check which modules are loaded.) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Tue, Mar 05, 2002 at 05:07:12PM +0300, Eugene L. Vorokov wrote: Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. Properly used there are not really any disadvantages of C++ over C. Since C is (almost) a subset of C++, most C programs will work just the same when compiled as C++. Proper use of the various extra features of C++ can make programs easier to write and make them more maintainable but this requires that the programmer actually know how to use them. The main difference between C++ and C is the support for object-oriented programming. One can of course write in an object-oriented manner in almost any programming language, including C, but it is easier in languages that has direct support for it, like C++. Now, not all problems are well-suited for being solved with an object-oriented approach so in those cases the extra features of C++ won't be of much help. I suspect that for the type programs you are writing using C++ wouldn't really have any advantage over C, but it won't have any disadvantage either. Does your boss insist on you actually writing your programs in idiomatic C++ or would he be satisfied if you wrote them using a subset of C++ which is very close to C. (if the latter your programs would still look almost the same as before, while technically being written in C++.) Using something just because 'it is cool' is just about the worst reason there is of doing anything (closely followed by 'we have always done it this way' which seems to be your reason :-) .) I apologize for the offtopic whenever it happens, but this issue really pisses me off now. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Tue, 5 Mar 2002, Eugene L. Vorokov wrote: ELVI have a small problem. I work for software development company and ELVwrite daemons and console tools for Unix. My boss wants everything ELVto be written in C++, because he thinks C++ is cool. I prefer C ELVfor such tasks, but I cannot really put good arguments of why and ELVwhere C++ can be worse than C. I know many of you prefer C too. ELVCan you please explain some disadvantages of C++ comparing to C ? ELVIs it slower, does it produce less effective code, why is it like ELVthat, etc ... or please direct me to some articles where this can ELVbe explained. ELV ELVI apologize for the offtopic whenever it happens, but this issue ELVreally pisses me off now. Well there are (at least) two reasons, why I wouldn't use C++ for the type of program I suppose you are writing: 1. The machine model used by C more or less maps directly into the machines used by most computers. By looking at a statement you can more or less guess what the compiler will do. In C++ this is not the case for (at least) two features: exceptions and virtual methods. Both of these features have an overhead, that cannot be estimated in advance. You can of course not use these features. 2. C++ turns out to be harder to read except it is extremly good written. This stems from several features of the language: a) operator overloading. Seeing a '+' doesn't mean that something is added. It may even actuall be a subtraction. It may be an assignment (a once popular GUI library used '+' to add dialog elements to the window on the left side of the '+'). b) function overloading. In C it is simple to lookup a function when you find it called in a program. In C++ you have first to lookup the argument types. If these are objects, you have also to find out the entire inheritance hierarchy. Then you have a quite complicated ruleset to find out, what function is really called. c) hidden function calls all over the places. You never know, whether a statement does something simple or call a lot of functions. 'a = b' can invoke dozens of constructors and other functions you are not aware of. Also there were rumours that C++ is less efficient because the resulting object code tends to consist of many small functions scattered all over the address space calling each other. This may badly hit cache performance. Well, the main problem with this type of question is that the choice of language depends on the problem you try to solve. For number crunching Fortran may still be the language of choice, for GUI programming surely it is C++ (or objc or java, you name it), for inetd it is probably C. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.5-RELEASE upgrade..didnt??
did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? 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: cannot get more than 32 PTYs in 4.4-RELEASE
In a message written on Tue, Mar 05, 2002 at 07:52:09AM -0600, Paul Halliday wrote: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; interestingly enough the command ./MAKEDEV pty3 will create (as indicated) heh.. I was assuming too much, something is screwy here. *confused* it actually only created 64 terminals. Added the line: 4) offset=192 name=t;; ~# ./MAKEDEV pty4 kill -HUP 1 interesting, now I have 96, but can only use 64. Reboot.. I think if you look at a more recent MAKEDEV, you'll find your answer: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; # Note that xterm (at least) only look at p-s. 4) offset=128 name=P;; 5) offset=160 name=Q;; 6) offset=192 name=R;; 7) offset=224 name=S;; # This still leaves [tuTU]. So: sh MAKEDEV pty0 # 0-31 sh MAKEDEV pty1 # 32-63 sh MAKEDEV pty2 # 64-95 sh MAKEDEV pty3 # 96-127 sh MAKEDEV pty4 # 128-159 xterm won't recognize by default sh MAKEDEV pty5 # 160-191 xterm won't recognize by default sh MAKEDEV pty6 # 192-223 xterm won't recognize by default sh MAKEDEV pty7 # 224-255 xterm won't recognize by default It's fairly trival to patch xterm to look for additional letters. It may have made it in the XFree source already. *shrug* -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. My main problem with C++ is that it adds a lot of overhead, and it's slow. Also, it drives me nuts when people code in C++ and write all kinds of classes when using classes for certain things just doesn't make sense, and makes the code much more convoluted. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Extending loader(8) for loading kerels/modules split across
On 05-Mar-02 Maxim Sobolev wrote: Hi folks, Please review attached patch, which adds long overdue feature to our loader(8), allowing it to load sequence of files as a single object. This should allow us to lift 1.44M limit on compressed kernel for the installation diskette. Please note, that to use this feature to load gzip-compressed objects you need to split the object first and then compress each piece individually, not compress first and then split already compressed file. Therefore tight fitting of each piece to the 1.44M limit could be a little tricky, but not impossible. Other way around is to use kgzip(8) utility to compress kernel and then split it into pieces 1.44M each. If there are no objections I would like to commit it ASAP, so that our RE team is able to use this feature in the forthcoming 5.0-DP1 release. Any feedback is appreciated. Looks good to me I guess. :) Do you have an example loader.conf that can be used on the floppies to demonstrate it? -Maxim -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
My main problem with C++ is that it adds a lot of overhead, and it's slow. Well written C++ code can be very fast, have a look at http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html and http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html and http://www.oonumerics.org/blitz/ Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Honestly, there are differences but both are tools to get the job done. Why you use both are really up to you since it depends if your shop wants object oriented programming for maintenance and troubleshooting. I had this happen when dealing with Ada vs. C++ vs. C. The programmers didn't want to use Ada because it wasn't cool or practical. Reality was that many of them didn't know how to program in Ada but had college knowledge on C and no training on object oriented programming. Same happened when C++ became popular. Fact is, managers may understand that the code in C++ is easier to read and maintain. There are reasons to use C++ because of the software engineering methodology and beliefs of its superioriy of C. If that real or not is up to you and the rest of the world. Ken Mays _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.5-RELEASE upgrade..didnt??
No, I didnt. Thanks! Will do that and report back. On Tue, 5 Mar 2002, Kenneth Culver wrote: did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? 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 --- Geoff Mohler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. Ken On Tue, 5 Mar 2002, Martin Ankerl wrote: My main problem with C++ is that it adds a lot of overhead, and it's slow. Well written C++ code can be very fast, have a look at http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html and http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html and http://www.oonumerics.org/blitz/ Martin 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++
I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Second is size, C will generate smaller executables. C++ to do its things adds overhead that increases the size of the object files. Steve B. - Original Message - From: Eugene L. Vorokov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 6:07 AM Subject: C vs C++ Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. Regards, Eugene 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++
Kenneth Culver writes: The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. That's *not* unique to C++. On my machine, /usr/lib contains 73 shared libs, and these are mainly C libraries. If you want arguments against C++, try any of these: C++ programs use a *lot* of header files, and these do in general cause more work for the compiler than do the C header files. This boils down to noticeably longer compile times. C++ is a *much* larger language, with *much* more complicated semantics and behaviour. A large proportion of C++ programmers do not know the language well enough that they should be allowed to program in it. -- 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: 4.5-RELEASE upgrade..didnt??
No, still have this from uname -a: 4.3-RELEASE FreeBSD 4.3-RELEASE #3: On Tue, 5 Mar 2002, Kenneth Culver wrote: did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? 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 --- Geoff Mohler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Tuesday 05 March 2002 11:28 am, Kenneth Mays wrote: Fact is, managers may understand that the code in C++ is easier to read and maintain. This I must disagree with. Most of the time, I think that C++ is harder to read *and* maintain. Well-written C++ is probably easier to read and maintain, but it's harder to write C++ well, and just telling everybody to switch compilers won't help at all -- it's likely to obfuscate the code more. If you want the benefits you've got to re-train everybody to use C++ *well*, which doesn't seem to be what was being suggested in this case. 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. There are reasons to use C++ because of the software engineering methodology and beliefs of its superioriy of C. If that real or not is up to you and the rest of the world. Ken Mays _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- 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
Re: C vs C++
In message: [EMAIL PROTECTED] Kenneth Culver [EMAIL PROTECTED] writes: : I have a small problem. I work for software development company and : write daemons and console tools for Unix. My boss wants everything to be : written in C++, because he thinks C++ is cool. I prefer C for such : tasks, but I cannot really put good arguments of why and where C++ can : be worse than C. I know many of you prefer C too. Can you please explain : some disadvantages of C++ comparing to C ? Is it slower, does it produce : less effective code, why is it like that, etc ... or please direct me to : some articles where this can be explained. : : My main problem with C++ is that it adds a lot of overhead, and it's slow. : Also, it drives me nuts when people code in C++ and write all kinds of : classes when using classes for certain things just doesn't make sense, and : makes the code much more convoluted. C++ doesn't add noticable overhead and isn't slow, unless you are a dumbass about how you write it. All languages give you plenty of ways to write speghetti fortran code :-). C++ gives you a number of ways to obfuscate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On March 05, 2002 at 08:37, Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. My 2 cents, Design first. In my experience the language used is largely irrelevant until the skill set of the people implementing the project are taken into account. With a good design you can match the requirements of the project to the skills of the people. The language and approach (OO, procedural, data driven, etc.) will usually be obvious at that point. Naturally, political issues will come into play, too. Just remember the old saw: you can write bad fortran in any language. It is up to the implementer to structure the software for maintainability, regardless of the language used. Byron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Extending loader(8) for loading kerels/modules split across
John Baldwin wrote: On 05-Mar-02 Maxim Sobolev wrote: Hi folks, Please review attached patch, which adds long overdue feature to our loader(8), allowing it to load sequence of files as a single object. This should allow us to lift 1.44M limit on compressed kernel for the installation diskette. Please note, that to use this feature to load gzip-compressed objects you need to split the object first and then compress each piece individually, not compress first and then split already compressed file. Therefore tight fitting of each piece to the 1.44M limit could be a little tricky, but not impossible. Other way around is to use kgzip(8) utility to compress kernel and then split it into pieces 1.44M each. If there are no objections I would like to commit it ASAP, so that our RE team is able to use this feature in the forthcoming 5.0-DP1 release. Any feedback is appreciated. Looks good to me I guess. :) Do you have an example loader.conf that can be used on the floppies to demonstrate it? You probably meant loader.rc? Very simple: load -n3 /kernel /kernel.1 /kernel.2 This will load kernel out of 3 pieces - they could be either /kernel, /kernel.1 and /kernel.2 or /kernel.gz, /kernel.1.gz and /kernel.2.gz or any combination of those. Just as an example I've split stock kern.flp image from 4.5-RELEASE into two images - they could be downloaded from http://people.freebsd.org/~sobomax/kern.flp.bz2 and http://people.freebsd.org/~sobomax/kern1.flp.bz2; -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
C++ doesn't add noticable overhead and isn't slow, unless you are a dumbass about how you write it. All languages give you plenty of ways to write speghetti fortran code :-). C++ gives you a number of ways to obfuscate. I hate to enter such a fray, but I can pass on my experience working with a group of engineers porting an application. This was about 6 years ago, so perhaps they cleared up the semantics of the problem I describe. We had a revenue management application which ran very well on an HP-9000/G70 (a dual process PA-RISC machine). We moved it to an 18 processor Sequent machine and it dominated the machine. After investigation we found that the application code was spending 95% of it's time in Memmove. After even more investigation there was an argument of interpretation on semantics. The HP compiler passed a pointer as a reference to an object and the Compiler from Edinburg was actually copying the object (which was not small by any means). Such problems would be easy to spot in a regular 'C' program because it would render a compiler error. The point made about having competant experience with C++ is very well noted and I think the strongest argument. So put simply, ask the boss if he want's to add risk to the project because there is perhaps a lack of adequate experience in C++. If the boss has his wits about him (???) he should take the path that would be less risky--DISPITE his own preferences (unless he want's to pay more for well trained engineers). Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Eugene L. Vorokov wrote: I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. One of the main disadvantages of C++ is that it requires self discipline, and object oriented programming is harder to learn. The other main disadvantage is that, if you use prototypes in your code, you can simply compile C programs with a C++ compiler, and call the code C++. Another disadvantage is that you can reuse the code when you are done with it, so you can't get paid for writing the same code over and over again. Inheritance compounds this problem, since it means that you can't even rewrite mostly similar code over and over again, since you end up inheriting everything from the base class that was similar in the first place, and can only spend time writing the parts that are different. This makes it really hard to pad a contract properly, while allowing you to play Quake for hours on end. A really annoying thing about C++ is that you can't create an uninitialized object; this makes it a lot harder to get the good bugs. A really really annoying thing is private vs. public, and protected member data and functions. This makes it nearly impossible to call the wrong function from the middle of three routines up, or otherwise violate the API layering in such a way as to simplify your code considerably, even if it does break the abstration model. A good example of this is the Microsoft PAP/CHAP PPP authentication. Everyone knows that the layering violations they introduced are good things, simplifying their life immensely, at the paltry cost of all of your security. That's why the TCP-over-DNS hack works to get you free internet connectivity using the MSN 800 number without having to log in. Imagine if they had not violated the layering, and adhered to the silly end to end requirements the IETF normally imposes on standards on the Internet... why, there would be no free dialup Internet connectivity at Microsoft's expense today! What a poorer place this world would be! Exceptions are really a pain; they make it nearly impossible to obfuscate code with a huge number of: if( condition) { undo everything I did so far return failure; } statements. They also lead to things like single-entry, single-exit, which make it nigh impossible to hide things from ASSERTs about whether or not things are locked (sure, coders who are interested in working code instead of money can do single-entry, single-exit in C, using underhanded techniques like negative logic, but it's easy to convert such code so as to hide it's true function). Probably most unforgivably, they make you handle exceptional conditions away from the main code path, which leaves no room for order-of-magnitude improvements in gradual steps, as you remove things from the common case later, and look like a hero for doing the job you were paid to do in the first place. A royal pain is the fact that using pure virtual base classes, which can't be properly instnaced without having real member functions, means that you can't create e.g. file system modules with unimplemented members like you can with structs containing lists of function pointers, so that you can later reap the rewards of NULL pointer dereference related crashes. Probably the absolute worst, most unforgivable attribute if C++ is dynamic scoping, with automatic deconstruction; it means that if I simply declare an instance of an object as an auto variable on the stack, that when I leave the scope the object is automatically deconstructed. This is evil, in that it makes it impossible to be subtle about leaking memory: no matter how you try to hide your memory leaks, if you use this approach, they become glaringly obvious. Worse, intentional leaks using new with no corresponding delete stick out like a sore thumb, no matter how you try to hide them. About the only upside is that if you use pure virtual base classes, or templates, such that a single class instance needs to be constructed at runtime by the .init and then deconstructed by the .fini at the end of the run, you can't use the code in the kernel, because the startup doesn't call these initializers for you, like the crt0 code calls it for user space programs, so you can avoid using C++ in the kernel, if you gratuitously use these constructs, and don't tell anyone why they won't work in the kernel so that you can be
Re: Help! serious problem.
ICA Canada Online wrote: Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. Here's the kernel panic message: [ ... ] Any ideas? I don't see the output of the ps you typed at the debugger prompt to see what process was running at the time of the panic. At a guess: check your crontab. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Kenneth Culver wrote: My main problem with C++ is that it adds a lot of overhead, and it's slow. Also, it drives me nuts when people code in C++ and write all kinds of classes when using classes for certain things just doesn't make sense, and makes the code much more convoluted. This is a serious concern for console tools, which are interacting with humans, which are capable of providing commands much faster than a 1.5GHz processor can accept and dispose of them... sorry I missed this downside in my first response. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Help! serious problem.
Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. had two similar problem's #1, client computer, 4:59pm every weekday, rebooted. Seems luser plugged their POSTAGE METER into same UPS as the computer 4:59pm, luser gets up and 'stamps' today's outgoing email! (massive surge, big magnets, negative neutrinos flying around) #2, 8:15am (and then 9:15am after DST change) lights in building turned on. T1 line from TELCO was shorted to house ground. House wiring was NOT grounded, so house wiring found ground through T1! (then again, check your cron also . turn on dumpdev. -- Michael Scheidell SECNAP Network Security, LLC (561) 368-9561 [EMAIL PROTECTED] http://www.secnap.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about write important code and you have a job forever no longer apply. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Help! serious problem.
It actually did a jmp 0 (or call 0) do you have any out-of date modules loaded? maybe an out of date firewall module? (it happens when you are doing some firewall code) On Tue, 5 Mar 2002, ICA Canada Online wrote: Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. Here's the kernel panic message: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Mar 5 03:04:03 predator /kernel: Fatal trap 12: page fault while in kernel mode Mar 5 03:04:03 predator /kernel: fault virtual address = 0x0 Mar 5 03:04:03 predator /kernel: fault code= supervisor read, page not present Mar 5 03:04:03 predator /kernel: instruction pointer = 0x8:0x0 Mar 5 03:04:03 predator /kernel: stack pointer = 0x10:0xe75d5ea8 Mar 5 03:04:03 predator /kernel: frame pointer = 0x10:0xe75d5ebc Mar 5 03:04:03 predator /kernel: code segment = base 0x0, limit 0xf, type 0x1b Mar 5 03:04:03 predator /kernel: = DPL 0, pres 1, def32 1, gran 1 Mar 5 03:04:03 predator /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Mar 5 03:04:03 predator /kernel: current process = 4326 (ipfw) Mar 5 03:04:03 predator /kernel: interrupt mask= none Mar 5 03:04:03 predator /kernel: trap number = 12 Mar 5 03:04:03 predator /kernel: panic: page fault Mar 5 03:04:03 predator /kernel: Any ideas? Thanks! -- ICA Canada Online 2601 Matheson Blvd. E. Unit #29 Mississauga, Ontario L4W 5A8 (905) 624-8566 http://www.ica.net 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: RS232/V24 Driver
On Sat, Mar 02, 2002 at 05:21:08PM -0700, Doug Russell wrote: On Sun, 3 Mar 2002, Volker Sturm wrote: I want to write a driver for a device on the serial port. The problem is that I dont get any info on the protocol that is used for data .. there already? If not, are there ways to analyze the protocol by a monitor or whatever technique appropriate? You might take a look at ports/comms/snooper Better try: http://www.gphoto.org/ because afaik this model is already supported :-) -- 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
Re: C vs C++
Well, that too, I guess I was just using KDE as an example of something being extremely slow due to a lot of libs being loaded. Ken On Tue, 5 Mar 2002, Raymond Wiker wrote: Kenneth Culver writes: The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. That's *not* unique to C++. On my machine, /usr/lib contains 73 shared libs, and these are mainly C libraries. If you want arguments against C++, try any of these: C++ programs use a *lot* of header files, and these do in general cause more work for the compiler than do the C header files. This boils down to noticeably longer compile times. C++ is a *much* larger language, with *much* more complicated semantics and behaviour. A large proportion of C++ programmers do not know the language well enough that they should be allowed to program in it. -- 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: 4.5-RELEASE upgrade..didnt??
How exactly did you upgrade? did you cvsup your sourcecode and then recompile from there? Ken On Tue, 5 Mar 2002, Geoff Mohler wrote: No, still have this from uname -a: 4.3-RELEASE FreeBSD 4.3-RELEASE #3: On Tue, 5 Mar 2002, Kenneth Culver wrote: did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? 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 --- Geoff Mohler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I think what I was trying to say is that a lot of C++ programmers will obfuscate their code by using features of the language that don't fit with what they were trying to accomplish. Ken On Tue, 5 Mar 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Kenneth Culver [EMAIL PROTECTED] writes: : I have a small problem. I work for software development company and : write daemons and console tools for Unix. My boss wants everything to be : written in C++, because he thinks C++ is cool. I prefer C for such : tasks, but I cannot really put good arguments of why and where C++ can : be worse than C. I know many of you prefer C too. Can you please explain : some disadvantages of C++ comparing to C ? Is it slower, does it produce : less effective code, why is it like that, etc ... or please direct me to : some articles where this can be explained. : : My main problem with C++ is that it adds a lot of overhead, and it's slow. : Also, it drives me nuts when people code in C++ and write all kinds of : classes when using classes for certain things just doesn't make sense, and : makes the code much more convoluted. C++ doesn't add noticable overhead and isn't slow, unless you are a dumbass about how you write it. All languages give you plenty of ways to write speghetti fortran code :-). C++ gives you a number of ways to obfuscate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
This is a serious concern for console tools, which are interacting with humans, which are capable of providing commands much faster than a 1.5GHz processor can accept and dispose of them... sorry I missed this downside in my first response. I'm not sure if you are being sarcastic or not, but if you are, it is definitely not appreciated. C code is generally easier to make more simple than C++. That said, gui code is probably better written in C++ since the whole idea of objects lends itself to that. However, daemons/console based progs don't really have any real reason to be written in C++ becuase that usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that. Geez... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
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. Ken On Tue, 5 Mar 2002, Terry Lambert wrote: Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about write important code and you have a job forever no longer apply. 8-(. -- Terry 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++
On Tuesday 05 March 2002 09:07 am, Eugene L. Vorokov wrote: Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. I apologize for the offtopic whenever it happens, but this issue really pisses me off now. Since C++ is, with a few trifling exceptions, a superset of C, why not just write C code like you always have and compile with the C++ compiler to make him happy? Unless your boss is way more clueful than most (and I doubt it or he wouldn't want daemons written in C++, I don't think), he won't know the difference. If he wants oo programming and accessor functions for everything and design meetings where you roleplay the different objects and all that jazz, thet's a different matter, and it's worth fighting. But if he just wants you to compile with C++, I'd advise just giving in. The compiles will be a little slower and the warning messages will be more strict, but you won't have to change much of what you're doing, unless you're writing pretty fast loose C code now. -- 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
Re: C vs C++
The quest continues... Just another blurb... The paradigm shift in all of this is what the theories and beliefs fabled around C++ have surmounted from debate after many years. C++ is an OO based language and falls under the reasoning of of use that other OO languages fall under. Not because its C++, but because it is an OO based language. I used the reasoning that managers think C++ is easier to read and maintain not because that is in fact, but that it is SUPPOSED to be by design and reason. Meaning, you are meant to learn how to write modular and reusable code based on the OO principles of software engineering. Not that you will, but that you can. C++ is nothing more than a tool but you are suppose to follow guidelines and rules that are suppose to make your code more readable, elegant, stylish (ha!), and maintainable as well as reusable. Now, you can take this rhetoric for what you will but that was some of the old beliefs. You can fight the cause by writing what needs to be written in C++, true C++, and showing code written in C only where it benefits but documented and written well (not spaghetti-fied). The gift of style and design is in the hands of the programmer (the toolmaster) and not really the code itself. That is the basics of software engineering over standard computer progamming. C++ vs. C can be a political debate filled with fluff. I think once you understand that a hammer is a hammer for a reason instead of a brick or stone being a hammer (which they can be in a sense), then you understand the purposes for C++ and/or C. Just make a TRUE analysis of factual information of WHY C++ was created in the first place and what are its true benefits over C (documented in many literary programming books, even C++ for Dummies) or why is C is better in other areas than using C++ (ask a game programmer). Start there and let your thumbs be your guide. Ken M. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Help! serious problem.
In message [EMAIL PROTECTED], Michael Scheidell cleopede: Running FreeBSD 4.5 and it keeps rebooting around the same time late during the night. had two similar problem's #1, client computer, 4:59pm every weekday, rebooted. Seems luser plugged their POSTAGE METER into same UPS as the computer 4:59pm, luser gets up and 'stamps' today's outgoing email! (massive surge, big magnets, negative neutrinos flying around) #2, 8:15am (and then 9:15am after DST change) lights in building turned on. T1 line from TELCO was shorted to house ground. House wiring was NOT grounded, so house wiring found ground through T1! Another one I've seen is that the building air conditioners all get turned off at the end of the workday, and it takes a certain amount of time before the room the computers is in gets so hot that the computers start getting flaky. Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
On Mon, 4 Mar 2002, Terry Lambert wrote: Mark Murray wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. Agreed. Anything that stops the harvesting entropy from sitting in the interrupt processing path for the most important interrupts on the box can only be a good thing. -- Terry I thought some one out there would be interested... Attached are our diffs relative to 4.4-RELEASE. They are mostly a direct port of the OpenBSD drivers and their integration into the stock random device entropy pool. We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. To this end, we have an entropy buffer in kernel memory that pulls large blocks of entropy from the RNG if it's going to read from it at all. The device puts out several orders of magnitude more entropy than the original drivers captured, and we needed as much as we could grab. Ideally we would not mix the entropy into the entropy pool and just use the high quality entropy from the buffer, but we decided to minimize divergence from the original sources and not switch to 100% hardware entropy. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. I cc'd Kaj Groner, who actually did the work for us. He's not on this list, so don't drop his address. I was more involved at the higher levels of what we needed to get done when we rebased our appliance from OpenBSD to FreeBSD last Summer. cheers, Adrian -- [ [EMAIL PROTECTED] ] --- i386/isa/ic/i82802.hWed Oct 17 12:44:23 2001 +++ i386/isa/ic/i82802.hMon Oct 8 11:55:22 2001 @@ -0,0 +1,21 @@ +/* This is where the first 82802 firmware hub is found. */ +#define FWH_BASE0xffb0 + +/* This is the offset where the RNG is found. */ +#define RNG_OFFSET 0xc015f + +/* Number of RNG ports */ +#define RNG_SPAN3 + +/* RNG registers */ +#define RNG_HWSTAT 0x00 +#define RNG_DATASTAT0x01 +#define RNG_DATA0x02 + +/* RNG hardware status register (RNG_HWSTAT) */ +#define RNG_PRESENT 0x40 +#define RNG_ENABLED 0x01 + +/* RNG data status register (RNG_DATASTAT) */ +#define RNG_READY 0x01 + --- kern/kern_random.c.orig Sun Oct 28 16:06:31 2001 +++ kern/kern_random.c Sun Oct 28 16:06:49 2001 @@ -224,20 +224,41 @@ /* Prevent overflow */ if (r-entropy_count POOLBITS) r-entropy_count = POOLBITS; if (r-entropy_count = 8) selwakeup(random_state.rsel); } void +add_true_randomness(u_int32_t num) +{ +add_entropy_word(random_state, num); + +random_state.entropy_count += sizeof (num) * 8; + + /* Prevent overflow */ + if (random_state.entropy_count POOLBITS) + random_state.entropy_count = POOLBITS; + + if (random_state.entropy_count = 8) + selwakeup(random_state.rsel); +} + +u_int +get_entropy_deficit(void) +{ +return (POOLBITS - random_state.entropy_count); +} + +void add_keyboard_randomness(u_char scancode) { add_timer_randomness(random_state, keyboard_timer_state, scancode); } void add_interrupt_randomness(void *vsc) { int intr; struct random_softc *sc = vsc; --- pci/pcisupport.c15 Aug 2001 04:04:59 - 1.154.2.7 +++ pci/pcisupport.c22 Oct 2001 18:39:54 - @@ -48,7 +48,15 @@ #include sys/systm.h #include sys/malloc.h #include sys/kernel.h + +#include machine/resource.h +#include machine/bus.h +#include machine/clock.h + +#include sys/rman.h #include sys/bus.h +#include sys/random.h +#include sys/sysctl.h #include pci/pcivar.h #include pci/pcireg.h @@ -57,6 +65,8 @@ #include vm/vm_object.h #include vm/pmap.h +#include i386/isa/ic/i82802.h + /*- ** ** Intel chipsets for 486 / Pentium processor @@ -669,6 +679,170 @@ return descr; } +#define RNG_RESERVE 0x1 + +struct pcib_softc { + /* RNG stuff */ + struct { +int rid; +struct resource *res; +bus_space_tag_t bt; +bus_space_handle_t bh; + +struct callout_handle toh; + +u_int8_t reserve[RNG_RESERVE]; +int reserve_start, reserve_end; + }
Re: Intel 820 RNG
On Mon, 4 Mar 2002, Sam Leffler (at Usenix) wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. I ported the openbsd crypto stuff to -stable for the purpose of making the soekris vpn1211 card usable (Hifn 7951). As part of this I tied the RNG on the Hifn to /dev/random; all that was required was to add a call to inject the data as entropy (or so I believed). Are your diff's available? We have a handful of idle powercrypt cards, which are Hifn's IIRC, idle here, and we have boxes without the i810 entropy device on their motherboards. This would be handy. Did you just dump the entropy into the existing entropy pool of the standard random(4) driver, or does it replace the driver with 100% hardware entropy? What kind of entropy bandwidth are you able to get? cheers, Adrian -- [ [EMAIL PROTECTED] ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
At 5:07 PM +0300 3/5/02, Eugene L. Vorokov wrote: Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Anyone who thinks C++ is some kind of magic bullet because it is cool is just fooling themselves. You may be able to do some great stuff in C++, but only if you take the time to really learn the language, and it's pitfalls (so you know what to avoid). I prefer C over C++ because there is less there to really learn. but this is probably one of those personal-preference things which is impossible for any one side to prove their position to any other side... -- 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: C vs C++
I wouldn't say C++ is THAT much harder to write, it does have a steeper initial learning curve than C. Most of that is due to needing to learn OOP at the same time. It is easier for C++ to come back and bite you than C if you don't spend enough time up front in design. IMO the biggest problem is people trying to treat C and C++ as one language. That is only good is you want to use C++ and as a better C compiler for the lint like features of C++ language. Steve B. - Original Message - From: Kenneth Culver [EMAIL PROTECTED] To: Terry Lambert [EMAIL PROTECTED] Cc: Steve B. [EMAIL PROTECTED]; Eugene L. Vorokov [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 10:25 AM Subject: Re: C vs C++ 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. Ken On Tue, 5 Mar 2002, Terry Lambert wrote: Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about write important code and you have a job forever no longer apply. 8-(. -- Terry 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
RFC: style(9) isn't explicit about booleans for testing.
The following is the largest part of the audit trail of PR docs/28555. At the end of the audit trail, Dima Dorfman asked Mike Meyer to seek review and comments from a wider audience than -doc. Since this documentation PR has been open for quit some time now, I'm posting the patch the PR was about, hoping to get comments from our style(9) meisters, and everyone else that can help with this. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ --- Audit trail --- On 2001-06-30 21:26, Mike Meyer wrote: The style(9) page says not to use ! for testing values unless the value is a boolean. It also says to test pointers against NULL. This leaves open the question of how other values that aren't booleans should be tested. How-To-Repeat: Read the man page to try and decide if you should write if (x) or if (x != 0). Fix: Apply the attached page to the style(9) man page. --- /usr/src/share/man/man9/style.9 Fri May 18 07:27:37 2001 +++ style.9 Sat Jun 30 16:23:34 2001 @@ -449,14 +449,37 @@ !(p = f()) .Ed .Pp -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. +For pointers, use: +.Bd -literal +if (p != NULL) +.Ed +.Pp +not +.PP +.Bd -literal +if (!p) +.Ed +.Pp +For other values, use: .Bd -literal if (*p == '\e0') .Ed .Pp not .Bd -literal -if (!*p) +if (*p) +.Ed +.Pp +unless the value is a boolean. In that case, use: +.Bd -literal +if (p) +.Ed +.Pp +and +.Bd -literal +if (!p) .Ed .Pp Routines returning void * should not have their return values cast On 2002-06-30 21:57, Dima Dorfman wrote: I think it is quite clear on the subject. If it's not a boolean, don't treat it like one; i.e., compare it against the value you're looking for. '0' may not always be that value. Regardless, this does not belong as a PR, let alone in the docs/ category. It belongs as a post on -hackers, asking what people think, not as a change request. Since *developers* are expected to follow style(9), it is the *developers* (i.e., -hackers@) that you should be proposing the change to. On 2001-06-30 22:55, Mike Meyer wrote: We both agree I'm not proposing a change in the style they have to follow; I'm just proposing making something explicit instead of implicit. As such, I'm not sure it warrants discussion. If the PR belongs in another category, please feel free to move it to either move it or suggest one for someone else to move it to. On 2001-06-02 23:13, Dima Dorfman wrote: I'm not suggesting that you should get every developer's approval, but I am suggesting that wider review than the -doc list would be nice, esp. for a document that defines policy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Kenneth Culver wrote: This is a serious concern for console tools, which are interacting with humans, which are capable of providing commands much faster than a 1.5GHz processor can accept and dispose of them... sorry I missed this downside in my first response. I'm not sure if you are being sarcastic or not, but if you are, it is definitely not appreciated. C code is generally easier to make more simple than C++. That said, gui code is probably better written in C++ since the whole idea of objects lends itself to that. However, daemons/console based progs don't really have any real reason to be written in C++ becuase that usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that. A good programmer can write FORTRAN in any language. If you are getting usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that, then you need to look at your programmers, not at the tools they are using. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
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. It's not harder to write C++ code that uses the special features of the language; it may be harder for a programmer unfamiliar with the language, but it's not harder for everyone. It's harder for me to write code in languages with which I'm unfamiliar. Big deal. That's a problem with my familiarity, not with the language. There are a lot of benefits to the use of C++ that outweigh the downside, particularly if you are a company paying for 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. Again... big deal. If it was something you'd do anyway, then they wouldn't be paying you to get you to do it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
A weird disk behaviour
I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
more writes fit in the disk's write cache? On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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.
On Tue, 5 Mar 2002, Giorgos Keramidas wrote: Read the man page to try and decide if you should write if (x) or if (x != 0). Fix: Apply the attached page to the style(9) man page. [...] the one that I stop to think about is: if (!(flags FLAGSET)) or should that be if ((flags FLAGSET) == 0) it depends on what you define as a Boolean. If FLAGSET has 1 bit in it then it it still possibly a boolean? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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: Realtime video capture/divx encoding (brooktree) beta testers required
On the subject of Re: Realtime video capture/divx encoding (brooktree) beta testers required, Heiko Recktenwald stated: At 7:48 Uhr +0100 05.03.2002, Steve O'Hara-Smith wrote: PS: I am more interested in mpeg1 than DivX because with mpeg1 the stream can be watched as it is being made. Would it help to hint it on the fly like it is done with mpeg4ip ? I dont get it? You can play raw .avi streams without doing anything, just play it as its being created. -Crh Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Because that underlying assumption is false, and I'm making fun of it. Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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++
On Tue, Mar 05, 2002 at 04:43:22PM -0500, Kenneth Culver wrote: Because that underlying assumption is false, and I'm making fun of it. Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. But you don't need to write OO code just because you use C++. You can write code in C++ exactly the way you do it in C if you want. There is no advantage of C++ over C when used this way but no disadvantage either. I do agree that when the extra features of C++ are used this often results in bloated programs but this can at least in part be blamed on insufficiently skilled programmers. Note that C++ is not really an OO language. It is probably better to call it a language with support for object-oriented programming (as well as support for other programming styles.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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: cannot get more than 32 PTYs in 4.4-RELEASE
Ok, see the point is, I have _already done this_ sh MAKEDEV pty0 # 0-31 sh MAKEDEV pty1 # 32-63 sh MAKEDEV pty2 # 64-95 sh MAKEDEV pty3 # 96-127 sh MAKEDEV pty4 # 128-159 xterm won't recognize by default sh MAKEDEV pty5 # 160-191 xterm won't recognize by default sh MAKEDEV pty6 # 192-223 xterm won't recognize by default sh MAKEDEV pty7 # 224-255 xterm won't recognize by default These are the exact commands I used with `sh MAKEDEV` to create my 256 pty /dev entries. So to recap, all 256 /dev files are there, all 256 entries are in /etc/ttys (and were there by default) and I have: maxusers128 and pseudo-device pty 128 in my kernel. And when I create 32 screens with `screen`, nobody else can login by any method (ssh, telnet, etc.). (No more PTYs error, etc.) What am I missing here ? Please note that this is 4.4-RELEASE - this doesn't seem to be a problem in 4.5 thanks, PT 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: 1. Does each jail need to have its own proc filesystem mounted? No, procfs is pretty much useless these days (except for truss). 2. Does kern.maxproc scale in a linear fashion with maxusers ? The default value for kern.maxproc is 20 + 16 * maxusers. 4. Why is it that some linux utilities, run inside a jail, get the hostname of the host machine, and not the hostname of the jail itself? It's a bug. It was fixed recently (in the last few days) in -CURRENT. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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 -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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 -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California 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: Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. How much less in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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 -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
Several times slower! The point is that writing less data performs worse. So I call it weird. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. How much less in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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 -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California 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 12:10, Steve B. wrote: I wouldn't say C++ is THAT much harder to write, it does have a steeper initial learning curve than C. Most of that is due to needing to learn OOP at the same time. A point which is made irrelevant if you want to make a comparison of the learning curves, by taking two persons who have no prior experience to programming, and teach procedural programming to one of them, while teaching object-oriented programming to the second. 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. 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: C vs C++
[ Top-posting edited off. Please, try to avoid top-posting. ] On 2002-03-05 13:25, Kenneth Culver wrote: On Tue, 5 Mar 2002, Terry Lambert wrote: Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about write important code and you have a job forever no longer apply. 8-(. 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. Apart from the obvious reason that someone has to be the devil's advocate, otherwise the thread will die, and I won't have anything to download in my mailboxes... Terry is right, although he chose a humorous[1] way to list his arguments :-) Terry suggested in his post (yes, the same one you find sarcastic), that C++ code can be written in ways that will help maintaining it later on. The object oriented methodology of programming, is not necessarily bad, and the Evil That Should Die(TM). There are good things about it, and there are bad things about it too. [1] Let us not forget that sarcasm, is in fact a form of humour. 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: A weird disk behaviour
Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. How much less in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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 -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: A weird disk behaviour
Wait a minute, you are saying that it takes longer to write the incomplete blocks? Doc At 18:19 5-3-2002 -0500, Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
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. I have modified the kernel in kern_physio.c and find out that physio() is called by expected number of times. I even add some code to record the time elapsed there: t1 = time_second; BUF_STRATEGY(bp, 0); spl = splbio(); while ((bp-b_flags B_DONE) == 0) tsleep((caddr_t)bp, PRIBIO, physstr, 0); splx(spl); t2 = time_second; physio_time += t2 - t1; the physio_time (a sysctl variable) is close to the time reported by the user program. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. How much less in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user program writing each contiguously laid out block sequentially using /dev/daxxx interface. There are a lot of them, say 15000. I write the blocks in two ways (the data used in writing are garbage): (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. Exactly how many bytes are written inside each block is determinted by a random number between 512 .. 8192 bytes (rounded up a to multiple of 512 bytes). I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? Thanks for any suggestions or hints. -Zhihui 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
Re: A weird disk behaviour
On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Um yeah that is what all my suggestions were based on.. Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. Have you looked at the Yarrow algorithm? To this end, we have an entropy buffer in kernel memory that pulls large blocks of entropy from the RNG if it's going to read from it at all. The device puts out several orders of magnitude more entropy than the original drivers captured, and we needed as much as we could grab. Ideally we would not mix the entropy into the entropy pool and just use the high quality entropy from the buffer, but we decided to minimize divergence from the original sources and not switch to 100% hardware entropy. In CURRENT, I have implemented Yarrow to achieve just this purpose. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. I cc'd Kaj Groner, who actually did the work for us. He's not on this list, so don't drop his address. I was more involved at the higher levels of what we needed to get done when we rebased our appliance from OpenBSD to FreeBSD last Summer. :-) You may be pleasantly surprised :-) M (Thanks for the sources!) -- 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
Re: RFC: style(9) isn't explicit about booleans for testing.
On 2002-03-05 12:59, Julian Elischer wrote: On Tue, 5 Mar 2002, Giorgos Keramidas wrote: Read the man page to try and decide if you should write if (x) or if (x != 0). Fix: Apply the attached page to the style(9) man page. [...] the one that I stop to think about is: if (!(flags FLAGSET)) or should that be if ((flags FLAGSET) == 0) it depends on what you define as a Boolean. If FLAGSET has 1 bit in it then it it still possibly a boolean? I was reading parts of the sys/netinet tree lately. Most of the places I have seen so far use the second style, even for flags that are stored in bitfields. Quoting ip_input.c: if ((m-m_pkthdr.rcvif-if_flags IFF_LOOPBACK) == 0) { ipstat.ips_badaddr++; goto bad; } This is what I prefer too, but my own personal preference is probably based on what I've seen so far, which is (I have to admit) very limited. 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: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. +For pointers, use: +.Bd -literal +if (p != NULL) +.Ed +.Pp +not +.PP +.Bd -literal +if (!p) +.Ed +.Pp +For other values, use: .Bd -literal if (*p == '\e0') .Ed .Pp not .Bd -literal -if (!*p) +if (*p) +.Ed +.Pp +unless the value is a boolean. In that case, use: +.Bd -literal +if (p) +.Ed +.Pp +and +.Bd -literal +if (!p) Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. 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.
msg.pgp Description: PGP message
Re: C vs C++
[ moved to -chat ] Because that underlying assumption is false, and I'm making fun of it. Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. Not so. Having done C professionally for umpteen years, C++ for a little less than umpteen years, and Java for 4, I can say w/out reservation that C++ sucks. OOP programming doesn't *have* to be hard. C++ puts too many roadblocks in your way. It not just because Java is newer that it's displacing C++ as the primary development language. It's because C++ as a language is *NOT* well-designed (design my commitee). C is becoming more and more like C++ in this regard. (And before Terry starts whining about strongly typed languages, let me state that IMO strongly typed languages are a good thing, since they allow you to verify your code at *COMPILE* time, vs. at runtime.) I can get more done in a shorter period of time with Java than with C++. However, when speed is of the issues, the computer get more done in a shorter amount of time with C than I can with either Java/C++. My Java programs can often-times run *faster* than my own C++ programs, simply because Java (the language) makes it easier to produce a good design. I don't find the limitations to be limitations so much, and they tend to force me to do better design up front. Both are OOP languages, but C++ *feels* like a non-OOP language with some hooks to make it more OOP like. (I'd like to play with Smalltalk, but alas there's no market for it, and there's no time left in my day to work on what I need to get done, let alone for things like playing with ST.) C++ in it's simple form *can* be easier to maintain, but it rarely turns out that way. As programmers, it's difficult to not succumb to the temptation to use the latest/greatest feature of the language, since at the time it certainly *seems* like it would help things out in the long-term. :) Finally, well-written/optimized C++ code is an abomination to look at, and requires sacrificing small animals at alters whenever you need to modify it. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Tue, 5 Mar 2002, Brian T.Schellenberger wrote: On Tuesday 05 March 2002 06:29 pm, Julian Elischer wrote: On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Um yeah that is what all my suggestions were based on.. 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. But the write in both cases are done sequentially. In the second case, I merely skip some sectors by writing less-than-full blocks. For example, I could write 3584, 5120, 7680, 7168, 8192 bytes in each successive 8192 byte blocks. But all these blocks are contiguous. Maybe the disk controller is not smart enough to figure out this is actually sequential. Only 8192, 8192, 8192, 8192 are regarded as sequential? -Zhihui But it'll be easier for us all to explain away the results if you can tell us what the results actually are :-) Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- 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
Re: C vs C++
I do agree that when the extra features of C++ are used this often results in bloated programs but this can at least in part be blamed on insufficiently skilled programmers. Note that C++ is not really an OO language. It is probably better to call it a language with support for object-oriented programming (as well as support for other programming styles.) I'll agree to that... :-D It's basically what I've been trying to say. That and if he's using gcc to compile, he might not get completely un-buggy code when he compiles c++ apps. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Myson drivers for 4.x
On Wed, Feb 27, 2002 at 02:52:41AM -0500, Matthew N. Dodd wrote: On Tue, 26 Feb 2002, Julian Elischer wrote: I have been speaking with the author. he is adding a BSD copyright. also he says we can KNFify (style(9)ify?) as it doesn't have to remain compatible with anything else. It might be nice if it could be folded into the driver it was copied from, if thats still possible. It would be nice, but other than admitting he has cards of this type; Bill Paul refused to answer if he is planning on supporting them. I think we need to commit the `my' driver as-is. 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:08:07AM +0200, Giorgos Keramidas wrote: On 2002-03-05 15:58, David O'Brien wrote: On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. ... Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. Actually I was asking for comments, but anyways. 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unionfs and getcwd problem.
Takanori Watanabe [EMAIL PROTECTED] wrote: Hi, I had trouble with unionfs when it calles getcwd(3) when I mount some directory on the directry in same file system,like mount -t union /usr/home/foo/bar /usr/src/sys/ . I investigate the problem by inserting debug print in getcwd.c. Then I found issuing __getcwd(2) in getcwd(3) failed, and climb up filesystem tree as the next way. But it failed when it reaches to mount point. It seems that st_dev and st_ino member returns the same number as the underlying filesystem so it failed to recognize mount point. So I tried the patch as follows taken from nullfs. Are there any problem with this patch? It looks fine to me. I know you definitely need to provide this behavior when doing a wrapper filesystem to behave like the system's stat() :) Takanori Watanabe a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html; Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A --- union_vnops.c~Tue Oct 2 00:01:37 2001 +++ union_vnops.c Mon Feb 25 22:44:51 2002 @@ -957,6 +957,8 @@ union_newsize(ap-a_vp, VNOVAL, vap-va_size); } + ap-a_vap-va_fsid = ap-a_vp-v_mount-mnt_stat.f_fsid.val[0]; + if ((vap != ap-a_vap) (vap-va_type == VDIR)) ap-a_vap-va_nlink += vap-va_nlink; return (0); -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
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. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
On Tuesday 05 March 2002 06:29 pm, Julian Elischer wrote: On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Um yeah that is what all my suggestions were based on.. 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. But it'll be easier for us all to explain away the results if you can tell us what the results actually are :-) Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- 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
Re: C vs C++
Brian T.Schellenberger wrote: On Tuesday 05 March 2002 03:26 pm, 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. Reality check: How can you possibly contend that it is no more difficult to write code in a language which *so* much more massive? It's not *so* much more massive. Hardly anyone who wants to write understandable code uses operator overloading, unless the are definiing a String or ImaginaryNumber class, and then it's incredibly clear-cut what's going on. The private vs. public is incredibly useful for data hiding, as well as namespace seperation. It means you can't spam values accidently, if you can't spam them on purpose. If you have a hard time with default private, then use struct instead of class for declaring things, and the default will be public instead. The protected and friend features are seldom used; if you understand FORTRAN mutual recursion as a means of implementing recursion in FORTRAN, which doesn't support it by default, then you understand friend functions. Inheritance is logical, to anyone who has ever programmed in the FreeBSD networking stack or VM system, both of which use structure casts to implement inheritance, whether you want it or not. Multiple inheritance is like protected... for the most part, you can ignore it. And one, I might add, which is intentionally UNdesigned. Yeah, and ANSI-C has prototypes because the compiler vendors were too damn lazy to change their object format to include a third field in the symbol table so that the problems that prototypes catch at compile time could be caught at link-time. The hidden reason for ANSI-C prototypes, of course, is, and always has been, so that C code could be compiled with a C++ compiler, with the intent that the C++ language supercede the C language. So now, I expect you to vehemently protect the existance of ANSI-C prototypes at every future opportunity. C++ was designed, but the design was constrained by the C language, just as the design of ANSI-C was constrained by the C language. C++ is a language which I really liked until I really started to learn about it. Well, there's a ringing condemnation. Have you looked at the source code for libXt or libXm lately? Ah, the beauty of pure C code, applied to the Object Oriented programming model... Object oriented programming is not some mystery, it's a means of solving problems that are best modeled by abstracting implementation details complexity into objects, so that you can concentrate on writing the code, and not on the details of the implementation. It's also a way of enhancing code reusability, through the use of design patterns. Once you've written one binary search, you've written them all. If you understand functional decomposition, then you unsertand the most fundamental tenet of object oriented programming already. Can we all move on to something more useful, like criticizing Java? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Kenneth Culver wrote: Because that underlying assumption is false, and I'm making fun of it. Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. C++ is not an O-O language. It is a language based on C that has O-O constructs which are lacking in C. It enables you to do O-O programming, but it doesn't constraing you to doing O-O programming. Just as Java doesn't constrain you (indeed, a number of Sun APIs break the O-O model by being able to instance unconstructed objects on which you have to post-call an initializer, which is incredibly broken). It's actually easier for humans to use an abstraction for complexity; if it weren't all rental cars would come with manual transmissions and two levers for steering. I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. A trout is a fish. Therefore all fish are trout. I think you just failed set theory... ;^). -- Terry 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: 1. Does each jail need to have its own proc filesystem mounted? 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 ? --pt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Trout (was: C vs C++)
On Tuesday 05 March 2002 07:15 pm, Terry Lambert wrote: Kenneth Culver wrote: I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. A trout is a fish. Therefore all fish are trout. I think you just failed set theory... ;^). I couldn't pass this up... The original comment has nothing to do with set theory per se; it has to do with the validity of extrapolation of data. The reason I couldn't pass this up is because I've just been reading Newton's Principia, in which he addresses this very point (in his third rule of reasoning in philosophy). He would say that if all observed C++ programs are slower and have more bloat, then we should assume all possible C++ programs are slower and have more bloat. Not a question of mathematics. Whether or not the premise is true is an entirely different question, and one which I'll leave to the professional coders :) -David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. A trout is a fish. Therefore all fish are trout. I think you just failed set theory... ;^). Uhh, ok... Not that this had anything to do with set theory, although I see you were trying to be funny... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A weird disk behaviour
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. Does this possibly explain what you are seeing? Note that I have no clue whether this happens with many real disks, or even with any made in the last 20 years, but I have heard tell of such things. I have modified the kernel in kern_physio.c and find out that physio() is called by expected number of times. I even add some code to record the time elapsed there: t1 = time_second; BUF_STRATEGY(bp, 0); spl = splbio(); while ((bp-b_flags B_DONE) == 0) tsleep((caddr_t)bp, PRIBIO, physstr, 0); splx(spl); t2 = time_second; physio_time += t2 - t1; the physio_time (a sysctl variable) is close to the time reported by the user program. -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Several times slower! The point is that writing less data performs worse. So I call it weird. Huh? You originally said: (1) Write each block fully and sequentially, ie. 8192 bytes. (2) I still write these blocks sequentially, but for each block I only write part of it. ... I find out the the performance of (2) is several times better than the performance of (1). Can anyone explain to me why this is the case? If (2) is better than (1), then writing *less* data is faster. Which is it, now? Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: Zhihui Zhang wrote: Well, the core of my program is as follows (RANDOM(x) return a value between 0 and x): blocksize = 8192; write_size_low = 512; time(time1); for (i = 0; i write_count; i++) { write_size = write_size_low + RANDOM(write_size_high-write_size_low); write_size = roundup(write_size, DEV_BSIZE); if (testcase == 1) write_size = blocksize; write_block(rawfd, sectorno, buf, write_size); sectorno += blocksize / DEV_BSIZE; } time(time2); If testcase is one, then the time elapsed (time2 - time1) is much less. How much less in milliseconds? Also, in your original mail, you said you had 15,000 of these 8K blocks, which is only 120MB or so. Use 150,000 or 1,500,000 and check your results then. Lars -Zhihui On Tue, 5 Mar 2002, Lars Eggert wrote: I agree that it's probably caching at some level. You're only writing about 120MB of data (and half that in your second case). Bump these to a couple of GB and see what happens. Also, could you post your actual measurements? Lars Zhihui Zhang wrote: The machine has 128M memory. I am doing physical I/O one block at a time, so there should be no memory copy. -Zhihui On Tue, 5 Mar 2002, Rogier R. Mulhuijzen wrote: At 16:03 5-3-2002 -0500, Zhihui Zhang wrote: On Tue, 5 Mar 2002, Julian Elischer wrote: more writes fit in the disk's write cache? For (1), it writes 15000 * 8192 bytes in all. For (2), it writes 15000 * 4096 bytes in all (assuming the random number distributes evenly between 0 and 8192). So your suggestion does not make sense to me. How large is your buffercache? it might be that the 15000 * ~4096 roughly matches with your cache, and 15000 * 8912 doesn't. Case (1) would require a lot more physical IO in that case than case (2) would require. Doc -Zhihui On Tue, 5 Mar 2002, Zhihui Zhang wrote: I am doing some raw I/O test on a seagate SCSI disk running FreeBSD 4.5. This situation is like this: +-++++++++++---+-- | |||||||||| | +-++++++++++---+-- Each block is of fixed size, say 8192 bytes. Now I have a user
Re: C vs C++
On Tuesday 05 March 2002 08:10 pm, Terry Lambert wrote: | Brian T.Schellenberger wrote: | On Tuesday 05 March 2002 03:26 pm, 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. | | Reality check: How can you possibly contend that it is no more difficult | to write code in a language which *so* much more massive? | | It's not *so* much more massive. Hardly anyone who wants | to write understandable code uses operator overloading, unless | the are definiing a String or ImaginaryNumber class, and | then it's incredibly clear-cut what's going on. | | The private vs. public is incredibly useful for data | hiding, as well as namespace seperation. It means you | can't spam values accidently, if you can't spam them on | purpose. | | If you have a hard time with default private, then use | struct instead of class for declaring things, and the | default will be public instead. | | The protected and friend features are seldom used; if | you understand FORTRAN mutual recursion as a means of | implementing recursion in FORTRAN, which doesn't support | it by default, then you understand friend functions. | | Inheritance is logical, to anyone who has ever programmed | in the FreeBSD networking stack or VM system, both of which | use structure casts to implement inheritance, whether you | want it or not. | | Multiple inheritance is like protected... for the most | part, you can ignore it. In other words it *is* so much more massive but most of that is junk and can be safely ignored. We would be in agreement there but it still gets in the way of learning it. | And one, I might add, which is intentionally UNdesigned. | | Yeah, and ANSI-C has prototypes because the compiler vendors | were too damn lazy to change their object format to include | a third field in the symbol table so that the problems that | prototypes catch at compile time could be caught at link-time. Have you ever *read* Stroustup's philosophy that a language should not have a philosophy? This is precisely what's wrong with C++, and what I mean by UNdesigned. It's deliberate! Stroustup considers it a virtue! I beg to differ. | The hidden reason for ANSI-C prototypes, of course, is, and | always has been, so that C code could be compiled with a C++ | compiler, with the intent that the C++ language supercede the | C language. | | So now, I expect you to vehemently protect the existance of | ANSI-C prototypes at every future opportunity. Prototypes are a good idea, and they did come from C++. I never said that C++ was devoid of good ideas; I just think it has _too_many_ ideas. | C++ was designed, but the design was constrained by the C | language, just as the design of ANSI-C was constrained by | the C language. Mostly it was constrained by a lack of constraint. Upward compatibility is a problem, but needn't be deadly. I happen to do the majority of my programming in a C-based OO language, but it's not C++. Actually, it's proprietary but it's closely modeled on Objective C, which is a much better OO language IMHO. | C++ is a language which I really liked until I really started | to learn about it. | | Well, there's a ringing condemnation. | | Have you looked at the source code for libXt or libXm | lately? Ah, the beauty of pure C code, applied to the | Object Oriented programming model... I have, and it's not real pretty. But if bad code condemned C++ I think you'd have a lot more to answer for--indeed, I believe you've rejected precisely this logic in arguing against others. Ok, you're in love with C++ but it's *not* the be-all and end-all of programming languages. Actually I think it's a crock of unmentionability, but that's just me. | Object oriented programming is not some mystery, it's a means | of solving problems that are best modeled by abstracting | implementation details complexity into objects, so that you | can concentrate on writing the code, and not on the details | of the implementation. True . . . | It's also a way of enhancing code reusability, through the | use of design patterns. Once you've written one binary | search, you've written them all. True . . . | If you understand functional decomposition, then you | unsertand the most fundamental tenet of object oriented | programming already. I write in OO all the time, though I admit that I feel pretty feel to cheat where it makes the problem easier to solve express. And I admit that sometimes I've cheated where it *didn't* in order to meet deadlines, and that I've almost always regretted. But OO != C++. | Can we all move on to something more useful, like criticizing | Java? Hmm . . . a little pot - kettle thing going on there, is there? | | -- Terry
add me
please add me too _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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 12:41:20PM +0800, 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(). Uh.. why? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
aio_read() oddness
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? Tony Arcieri 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 [EMAIL PROTECTED] writes: : On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: : On 2002-03-05 15:58, David O'Brien wrote: : On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: : -Don't use '!' for tests unless it's a boolean, e.g. use : +For tests, always compare the value to the appropriate 0 instead of : +checking it directly, unless the value is a boolean. : ... : : Please show examples from /sys that back up this change. To state this : explicitly, I think a significant number of /sys files should be : following it. : : Actually I was asking for comments, but anyways. : : 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. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Geeze, spend a day at the doctors, and look what happens. The mst interesting thing to show up on -chat in the entire time I've been reading it. Language debates are such fun. Steve B. [EMAIL PROTECTED] types: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. But for large projects, the disadvantages of C++ kick in, so you don't really gain much. Almost every OO language design decision in C++ is wrong. So you get all the disadvantages of C, bundled with all the disadvantages of OO as well. - Original Message - From: Eugene L. Vorokov [EMAIL PROTECTED] I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. If he wants to wrinte in C++ because C++ is hot, then just write C and compile it with the C++ compiler. If he wants an O-O language, then shell out the bucks to get Eiffel and it's IDE from Meyer (I'd like to claim a relationship, but I doubt it), so you actually get the benefits of O-O. 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. That's a different thing, and doesn't necessarily make the language more powerful. One of my favorite languages is Scheme, where the general design principle was to make the language more powerful by removing things. I quit using it before they added macros, in part because I couldn't get the DECWRL Scheme-C compiler to compile with SAS C 6.0. Maybe I'll take another look. I use Python these days, which doesn't have macros - which are the most powerful programming construct in modern LISP. 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. 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. In fact, that's one of the things most VM designs have that Java (and Perl) is missing - the REPL. When I have to write Java, I debug my classes by firing up JPython, then playing with the Java objects in the JPython REPL loop. 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.
David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas 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. 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: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas 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 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. I belive the overall purpose of style(9) is to make the code readable, and I happen to think that if (somerandomfunction(argthis, functionthat(something), onemore)) { chugchugchug(argthisa; } is just a tiny bit more readable than if ((somerandomfunction(argthis, functionthat(something), onemore) != 0) { chugchugchug(argthisa; } for instance. -- 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: In message [EMAIL PROTECTED], Mike Meyer writes: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: Now, IFF the C language had a type called boolean that would make a lot of sense. So you're advocating that the rule be dropped. I belive the overall purpose of style(9) is to make the code readable, and I happen to think that if (somerandomfunction(argthis, functionthat(something), onemore)) { chugchugchug(argthisa; } is just a tiny bit more readable than if ((somerandomfunction(argthis, functionthat(something), onemore) != 0) { chugchugchug(argthisa; } I agree with you. Under the rules as they exist now, the first form would only be valid if somerandomfunctoin returned either 0 or true. 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: Poul-Henning Kamp [EMAIL PROTECTED] types: In message [EMAIL PROTECTED], Mike Meyer writes: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: Now, IFF the C language had a type called boolean that would make a lot of sense. So you're advocating that the rule be dropped. I'm advocating that the rule focus on readability rather than trying to enforce a type which doesn't exist. Type-enforcement is a task for the compiler, not for a manpage. -- 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