Re: 3.3 to 4.5 remote upgrade possible?

2002-03-05 Thread Matthew D. Fuller

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

2002-03-05 Thread Heiko Recktenwald

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

2002-03-05 Thread Maxim Sobolev

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

2002-03-05 Thread Dr Guihua Li



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

2002-03-05 Thread Paul Halliday

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++

2002-03-05 Thread Eugene L. Vorokov

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.

2002-03-05 Thread ICA Canada Online

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

2002-03-05 Thread Makoto Matsushita


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.

2002-03-05 Thread David Malone

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++

2002-03-05 Thread Erik Trulsson

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++

2002-03-05 Thread Harti Brandt

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??

2002-03-05 Thread Kenneth Culver

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

2002-03-05 Thread Leo Bicknell

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++

2002-03-05 Thread Kenneth Culver

 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

2002-03-05 Thread John Baldwin


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++

2002-03-05 Thread Martin Ankerl

 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++

2002-03-05 Thread Kenneth Mays

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 world’s 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??

2002-03-05 Thread Geoff Mohler

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++

2002-03-05 Thread Kenneth Culver

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++

2002-03-05 Thread Steve B.

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++

2002-03-05 Thread Raymond Wiker

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??

2002-03-05 Thread Geoff Mohler

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++

2002-03-05 Thread Brian T . Schellenberger

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 world’s 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++

2002-03-05 Thread M. Warner Losh

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++

2002-03-05 Thread Byron Servies

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

2002-03-05 Thread Maxim Sobolev

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++

2002-03-05 Thread Andy Sporner

 
 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++

2002-03-05 Thread Terry Lambert

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.

2002-03-05 Thread Terry Lambert

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++

2002-03-05 Thread Terry Lambert

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.

2002-03-05 Thread Michael Scheidell

  
  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++

2002-03-05 Thread Terry Lambert

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.

2002-03-05 Thread Julian Elischer

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

2002-03-05 Thread Mark Santcroos

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++

2002-03-05 Thread Kenneth Culver

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??

2002-03-05 Thread Kenneth Culver

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++

2002-03-05 Thread Kenneth Culver

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++

2002-03-05 Thread Kenneth Culver

 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++

2002-03-05 Thread Kenneth Culver

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++

2002-03-05 Thread Brian T . Schellenberger


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++

2002-03-05 Thread Kenneth Mays

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.

2002-03-05 Thread Greg Shenaut

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

2002-03-05 Thread Adrian Filipi-Martin

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

2002-03-05 Thread Adrian Filipi-Martin

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++

2002-03-05 Thread Garance A Drosihn

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++

2002-03-05 Thread Steve B.

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.

2002-03-05 Thread Giorgos Keramidas

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++

2002-03-05 Thread Terry Lambert

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++

2002-03-05 Thread Terry Lambert

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

2002-03-05 Thread Zhihui Zhang


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

2002-03-05 Thread Julian Elischer


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.

2002-03-05 Thread Julian Elischer



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

2002-03-05 Thread Zhihui Zhang



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

2002-03-05 Thread Charles Henrich

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++

2002-03-05 Thread Kenneth Culver

 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

2002-03-05 Thread Rogier R. Mulhuijzen

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++

2002-03-05 Thread Erik Trulsson

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

2002-03-05 Thread Zhihui Zhang


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

2002-03-05 Thread Patrick Thomas


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

2002-03-05 Thread Dag-Erling Smorgrav

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

2002-03-05 Thread Lars Eggert

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

2002-03-05 Thread Zhihui Zhang


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

2002-03-05 Thread Lars Eggert

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

2002-03-05 Thread Zhihui Zhang


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++

2002-03-05 Thread Giorgos Keramidas

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++

2002-03-05 Thread Giorgos Keramidas

[ 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

2002-03-05 Thread Lars Eggert

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

2002-03-05 Thread Rogier R. Mulhuijzen

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

2002-03-05 Thread Zhihui Zhang


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

2002-03-05 Thread Julian Elischer



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

2002-03-05 Thread Mark Murray

   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.

2002-03-05 Thread Giorgos Keramidas

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.

2002-03-05 Thread David O'Brien

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.

2002-03-05 Thread Giorgos Keramidas


msg.pgp
Description: PGP message


Re: C vs C++

2002-03-05 Thread Nate Williams

[ 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

2002-03-05 Thread Zhihui Zhang


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++

2002-03-05 Thread Kenneth Culver

 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

2002-03-05 Thread David O'Brien

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.

2002-03-05 Thread David O'Brien

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.

2002-03-05 Thread Brian F. Feldman

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++

2002-03-05 Thread Terry Lambert

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

2002-03-05 Thread Brian T . Schellenberger

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++

2002-03-05 Thread Terry Lambert

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++

2002-03-05 Thread Terry Lambert

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

2002-03-05 Thread Patrick Thomas


 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++)

2002-03-05 Thread David Syphers

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++

2002-03-05 Thread Kenneth Culver

  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

2002-03-05 Thread Brian T . Schellenberger

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++

2002-03-05 Thread Brian T . Schellenberger

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

2002-03-05 Thread AHMAD MASOOD

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

2002-03-05 Thread David O'Brien

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

2002-03-05 Thread Tony Arcieri

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.

2002-03-05 Thread M. Warner Losh

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++

2002-03-05 Thread Mike Meyer

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.

2002-03-05 Thread Mike Meyer

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.

2002-03-05 Thread Poul-Henning Kamp

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.

2002-03-05 Thread Mike Meyer

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.

2002-03-05 Thread Poul-Henning Kamp

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