Re: if_dc in v4.0 - Forcing store and forward?
[EMAIL PROTECTED] wrote: I suspect a generic chipset fault, or some design quirk that we are not working around. Note that the windoze drivers for these devices put them permanently in store-and-forward mode. if_de has the exact same problem on all of the systems above. ... Store and forward mode introduces a horrible performance hit... Artesyn wouldn't show us the source to their workaround :-( It should be noted that I was able to saturate a 100 Mbps Ethernet with FreeBSD 2.2 and a 21140 based card, using around 56% of the CPU of a PPro-200. This was done almost exactly three years ago, using the (then) standard if_de driver. I have no idea whether the card was operating in store-and-forward mode or not - but the performance was perfectly fine. I can guarantee that it was not running in store and forward mode if you were exceeding 30 Mbit throughput. Was this a 21140, 21140A or other stepping? These variations varied pretty wildly in their behavior (and I suspect in their actual implementation as well). Cheers, J. Hicks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dc in v4.0 - Forcing store and forward?
Dennis wrote: At 10:48 PM 6/7/00 -0700, W Gerald Hicks wrote: Peter Wemm wrote: I suspect a generic chipset fault, or some design quirk that we are not working around. Note that the windoze drivers for these devices put them permanently in store-and-forward mode. if_de has the exact same problem on all of the systems above. Well we never saw these problems in v3.4...so what changed? DB The chips vary widely, we experienced great behavioral differences between steppings. The 21143 was particulary worrisome, as were some of the 21140 variants. I definitely experienced tx underruns on FreeBSD 3.4 with a 21140A. Never saw them with a good old 21040 though. After I was told by Intel that they're killing the device off, we decided to stop developing boards with them and eliminated at least *that* source of aggravation ;-) -- Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An IA-64 port?
Arun Sharma wrote: I don't know if the gas support is public, but you can certainly get the Intel assembler for IA-64, which has been open sourced under the BSD license from developer.intel.com. It may not be of much practical use, but might help in understanding the architecture (which requires a significant effort because of its complexity). -Arun Anyone know the URL for this? I've got all the documentation but can't seem to find the Intel assembler release. Thanks, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can we use this for the JDK? (was: Motif goes open source)
"Koster, K.J." wrote: Dear all, Is there someone on this list who's into the finer points of copyrighting? I would like to know what the implications are of this for the soon-to-be-coming native FreeBSD JDK port. In what form is Motif going to be available to the general FreeBSD developer? Am I going to find /usr/ports/x11-toolkits/motif anytime soon, or is this going to be more complicated than that? As Poul-Henning Kamp noted earlier we have licenses in the ports tree that are *much* stranger than this one. I'd be very surprised if we don't see an entry in ports/x11-toolkits for Motif sometime soon. I'd also be very interested in what the "Hungry Programmers" have to say about this new development. All in all, I think this was a good day for open-source software. :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
Once again I must ask... What do you know of Open Source? Aside from your enlightened criticisms I've seen nothing in the way of any sort of contribution. No ports maintenance, no code contribution. Nothing other than pure profiteering and never returning anything but a kick in the nuts. Thanks (not) -- Jerry Hicks [EMAIL PROTECTED] From: Dennis [EMAIL PROTECTED] Subject: Re: Is FreeBSD dead? Well, not in theory... Date: Sat, 11 Mar 2000 13:36:31 -0500 [EMAIL PROTECTED] writes... The very fact that source is available means that you can pay any scruffy unshaven hacker to fix it for you, instead of suffering at the hands and whims of, say, a FreeBSD "vendor" as you are doing. I would figure that at least you (of all people) realize that someone else can come in and get it done, and that you could optionally pay someone to do this. Not realistically. First of all, most "scruffy unshaven hackers" are not qualified to... [rant and shameless self-promotion elided] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting CPU usage in FreeBSD
Hi Felipe, (You should probably be targeting -current for software under development) Perhaps consulting /usr/src/usr.bin/top/machine.c might offer up some clues. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
I'm sorry Dennis but I find it a bit difficult to swallow your assessment of other people's business acumen and their ability to relate to markets. The race isn't over yet, hell everybody's just warming up :-) -- Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
nothing is not a word at all, so it can't be expanded, so I think bash is corrent to complain about a syntax error. Epsilon anyone? I really don't care (honestly) but a null word can be considered a word too! In yacc-like terms: wordlist: | wordlist WORD ; It doesn't really matter until one considers perverse abuses of a shell, such as those embedded in a Makefile somewhere. FreeBSD's shell (and ksh93) both perform "correctly" IMHO and wouldn't make the change. I'm also not likely to declare a Jihad against such a change either :-) It doesn't hurt anything the way it is and represents a better generalization (IMHO again). Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
I agree that this is not the time to change it. But in the long run, if the ports framework is misusing /bin/sh then the framework needs to be fixed. We shouldn't let bugs there influence what we do with the shell. Haven't been convinced yet they are bugs :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
bash and ksh complain about unexpected ';'. /bin/sh (FreeBSD) thinks it's ok and does nothing. Which behaviour is more POSIXly correct? Neither bash nor ksh claim to be particularly POSIX compliant. our /bin/sh does. I seem to remember POSIX being ambiguous on this one, but my books are at the office. If you haven't gotten a more conclusive answer by Monday, mail me and I'll look it up. I much prefer the current behavior and believe there may be many things which depend on it. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
From: Doug Barton [EMAIL PROTECTED] Subject: Re: empty lists in for Date: Sun, 05 Mar 2000 11:39:49 -0800 W Gerald Hicks wrote: bash and ksh complain about unexpected ';'. /bin/sh (FreeBSD) thinks it's ok and does nothing. Which behaviour is more POSIXly correct? Neither bash nor ksh claim to be particularly POSIX compliant. our /bin/sh does. I seem to remember POSIX being ambiguous on this one, but my books are at the office. If you haven't gotten a more conclusive answer by Monday, mail me and I'll look it up. I much prefer the current behavior and believe there may be many things which depend on it. Given that Bash in both standard and POSIX mode complains about 'for i in ; do echo $i; done', I would say that it's not POSIX compatible. What could/does depend on this behavior "working?" Even though it's my preferred shell, I certainly wouldn't say that Bash is any sort of standard, certainly not in the POSIX sense. Imagine processing a possibly empty list constructed from a 'make' expansion... Without this behavior one would have to code a guard of some sort around the 'for' construct. If everything is checked through make release, I would hold little objection to a change *after* 4.0-RELEASE. That includes all conditional paths through make release ... -- Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
From: Doug Barton [EMAIL PROTECTED]
John Polstra already pointed this out, and Bash handles this like you
would expect. There is a difference between expanding an empty list and
trying to expand a list that isn't there.
Convince me that nothing like the following exists in the
ports framework and /usr/src and I'd be ok with a change
*after* 4.0 release (repeats himself)
# Makefile.foo
FOOVAR=
.
.
.
BARVAR=${FOOVAR}
baz:
for i in ${BARVAR} ; do \
${BLAP} $$i ; \
done
To me, changing it right now on the eve of -release
would be gratuitous. Later I would be fine with it.
I still prefer /bin/sh being able to handle an empty
literal list but would yield to the desires of others.
--
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: powerpc cross compiler?
From: "Jason Allum" [EMAIL PROTECTED]
Subject: powerpc cross compiler?
Date: Fri, 25 Feb 2000 09:58:01 -0500
i'm trying to setup gcc 2.95.2 as a powerpc (7400/G4) cross compiler on
freebsd 3.4-release... i'm having no luck, as it keeps bombing out when it
tries to build libgcc.a... anyone got any ideas? alpha people? ;)
Hi Jason,
You need some header files :-)
You might pick up newlib-1.8.2.tar.gz and use the headers from
there.
For my own embedded work I contruct a "crosstree" and build
the binutils, gcc and newlib components as an integral release
the same way Cygnus builds their GNUpro tool chains. You can
get an outdated version of their script from:
ports/devel/crossm68k-devel/scripts (this will need some
tweaking to make it work with the new components)
The distfiles you want are:
gcc-core-2.95.tar.gz (FSF)
binutils-2.9.1.tar.gz (FSF)
newlib-1.8.2.tar.gz (Cygnus)
gdb-4.18.tar.gz (FSF - optional but has a useful simulator)
I use powerpc-eabi for my ${TARGET} since I'm doing
embedded development, don't know what to recommend for
yours.
I'd also recommend installing David Obriens updated GCC from
ports first and using that to build the crosstree.
Good Luck,
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Re/Fwd: freebsd specific search
What sort of quality-control measures does Slackware have? Where do I access their cvs tree? Where do I access their problem reports? Where do I subscribe to get every commit message? How long are their code freezes? How many committers do they have? What mechanism creates their releases? Where do I get release-candidates? Hmmm. my face is red. These aren't quite technical limitations as they are political ones. [snip] Not having an orderly development process has caused quite a few technical limitations for Linux. Not having any sort of standardized and reproducible release process is notable; lack of version control is one of the more serious problems I have with Linux. Not really political, but (dis)organizational To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
--enable-haifa
Just curious what effect using the --enable-haifa flag for building gcc-2.95.1/x86 would have so I did a comparison using the Dhrystone benchmark from /usr/ports/benchmarks/bytebench. This was run on a Ziatech 200Mhz Pentium cPCI system. I don't know if this is really worth further testing but it seems interesting. Cheers, Jerry Hicks [EMAIL PROTECTED] stock -current (1999/10/05) gcc = Dhrystone 2 without register variables 321955.8 lps (10 secs, 6 samples) BASELINE RESULT INDEX Dhrystone 2 without register variables 22366.3 321955.8 14.4 i386-portbld-FreeBSD4.0 --enable-haifa = Dhrystone 2 without register variables 323767.4 lps (10 secs, 6 samples) BASELINE RESULT INDEX Dhrystone 2 without register variables 22366.3 323767.4 14.5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Search a symbol in the source tree
I find it ironic that nobody has suggested global yet; That sure would make a nice port, especially since we could easily recommend gozilla as a nice way to browse and search the source tree. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Search a symbol in the source tree
Er, global is part of the base system. :-) Hehe, I knew that. My point was that the entire package isn't built and the author's going GPL anyway and since nobody recommended it ... That sure would make a nice port ;-) For the original poster gtags/htags is an excellent tool for your purposes. In its full installation it can generate html versions of your code and is chock full of other features too. Give it a test drive :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
Could things be done in such a way that like QNX, it can kill and restart a misbehaving driver? What other cool things can be done? QNX doesn't do that. Actually, in many cases it does. There are numerous advantages in a well-designed/optimized micro-kernel that FreeBSD will never have. Well, the implication was that QNX implements this as a kernel policy and that it's done automatically. A handful of drivers can be stopped and restarted, notably the network devices. The QNX filesystem resource managers and disk device drivers are notoriously finicky and aren't restartable in the general sense. Still, I like QNX a lot and have a major telecomm app widely deployed on it, going on five years in the field now. However, as has been shown by the plethora of poor micro-kernel implementations (QNX not withstanding), it's hard to implement a well-designed/optimized micro-kernel, especially one that is not architecture dependent. Amen! :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
On Slashdot, ... Under QNX, if your driver crashes, the kernel just restarts it. That's not in the least bit how QNX works... oh well, it's slashdot. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A bug in the sppp driver?
doing state machines with switch statements is a big mess. Still, you'll find a lot of them around. Do you have a favored technique for coding complex state machines? (I'm a collector :) One scheme I've been using for quite some time is to use a function pointer as a 'state variable', sometimes making a stack of them for a more flexible machine. Sometimes I use a transition matrix for selection of the 'state function' but more often the functions themselves perform 'next state' selection. To be honest though, most of the time the machinery I need for an application has from four to six states. Anything more than a simple switch on a state variable seems to be overkill for those. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
I think that Jerry, in using GLOBAL as an example to push his desire for a smaller FreeBSD, rather clouded the issue. I would wish that, if Shigio doesn't actually assign the copyright to the FSF, then he can release it under both copyrights, and please everyone. If Jerry wants to have FreeBSD be smaller, I think that this method wasn't a good way to start his campaign. Perhaps; this is why I rescinded my offer to do all the legwork and take on the burden of maintaining the port :-) Seriously, I believe GLOBAL and FreeBSD would _both_ be better served by having it installed from ports anyway. Note that gozilla isn't even installed by the version in /usr/src, owing to its need for things coming from ports (X, Netscape). Shigio was probably taken aback by Jerry's proposal. But not nearly as taken aback as I was that a BSD package is going GPL. :-( -- Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
imho, global (a fine software package) shouldn't have been in the
OS source tree anyway. To me, the proper place seems to be in the
ports collection along with many other development utilities.
It seems that you misunderstand.
Current GLOBAL(3.53 and earlier) is BSD-style licensed and it is true
for ever. I agree with the plan to make a ports of GNU/GLOBAL in the
future. But you need not remove BSD/GLOBAL from source tree.
Well, perhaps I am an extremist :-)
I am only an end-user, and not having commit priviledges anyway could
only submit a change request. So don't interpret my opinion as what
will actually be done. I haven't submitted a change request yet and
will probably hold off until a more authoritative consensus has been
reached.
My concern is mostly with the increasing size of the base src tree
and the intermediate files generated by make {world,release}.
In the interest of moving toward a more modular FreeBSD and smaller
base system, I believe that anything not absolutely essential to
make {kernel,world,release} should be moved to ports.
So even without the license change I would be in favor of moving
GLOBAL to ports. Ports is not a second-rate place to have a package
located, to the contrary, it often permits more active development
since fears of breaking make {world,release} do not exist there.
Best Regards,
Jerry Hicks
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
I don't see much of a problem, other than requiring its removal from the FreeBSD source tree. Although FreeBSD has a 'contrib' and 'gnu' hierarchy in the source tree, I believe the trend should be to reduce the existing members there and also to avoid adding new ones. imho, global (a fine software package) shouldn't have been in the OS source tree anyway. To me, the proper place seems to be in the ports collection along with many other development utilities. I don't agree with your perceptions of the GNU license but do respect your decision as the author to choose whatever license you wish. I'll be preparing a port for global this afternoon and submitting a change request to have it removed from the source tree in favor of using the port on FreeBSD. Thank you very much for global! :-) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
I don't see much of a problem, other than requiring its removal from the FreeBSD source tree. Although FreeBSD has a 'contrib' and 'gnu' hierarchy in the source tree, I believe the trend should be to reduce the existing members there and also to avoid adding new ones. imho, global (a fine software package) shouldn't have been in the OS source tree anyway. To me, the proper place seems to be in the ports collection along with many other development utilities. I don't agree with your perceptions of the GNU license but do respect your decision as the author to choose whatever license you wish. I'll be preparing a port for global this afternoon and submitting a change request to have it removed from the source tree in favor of using the port on FreeBSD. Thank you very much for global! :-) Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[no subject]
To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Book Question
Sorry if this is off topic for this list, but I'm about to dive head first into more advanced FreeBSD and I'm badly in need of a good reference book. [snip] I've not missed having a shelf of books about FreeBSD, mainly because of the reference materials served by the FreeBSD CVSup servers. If you *really* want to dig into FreeBSD's inner workings, I'd suggest setting up a local repository and mirror of the mail archives. There's gold in there! :) Good Luck, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: getopt.c in gnu/*/*
It would be better to create src/gnu/lib/libgnugetopt/Makefile and point .PATH: to the newest src file we have in the tree. If some package gets updated and there is a newer GNUgetopt(), then we change the .PATH:. JDP suggested this is a cleaner way than extracting part of a GNU package, and I have to agree with him. (I am considering something simular with libiberty and libbfd) Cygnus cautions against merging libiberty/libbfd from binutils with GDB. Never made sense to me tho... :-) Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD native xanim
I'd really rather have the cross-compilers. Me too, but for other reasons. If you are using CVS then the problems you mention of working between systems will be greatly minimized. Besides, we'd really like to see you try FreeBSD :-) My major problem with the approach you are considering really relates to quality control issues. Have you earnestly tried to reason for release from NDA? Sometimes it really works. :-) Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
