Re: 40% slowdown with dynamic /bin/sh
On Nov 24, 2003, at 8:09 PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. Yep :). I feel like saying set the default to static and make the dynamic bins the option so the people who can't be bothered to compile their own system even though everyone I know does this for tuning purposes anyway can stop whining. But I won't say that. Dave Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: SiI3112 SATA controller problems - status
Gabriel, Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) SS Hmm, PR? pricing? I guess its easier to make people shell out $$ SS for a pretty expensive 36G drive if you add SATA to the mix of features :) Actually, that drive is more like a SCSI drive with SATA connectors. FWIW, it's still cheaper than a SCSI drive with the same specs and it got 5 years warranty so I hope it is actually built better than the desktop crap we see dying like the flies here (hint: massive airstream over the disks helps a lot, cooler disks live much longer, so if you can accept the noise, get some badass 12CM fan to cool them ;-). I feel less betrayed now. Regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
On Sep 30, 2003, at 3:30 PM, Soren Schmidt wrote: It seems Will Andrews wrote: On Tue, Sep 30, 2003 at 10:22:33PM +0200, Soren Schmidt wrote: No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) Hmm, PR? pricing? I guess its easier to make people shell out $$ for a pretty expensive 36G drive if you add SATA to the mix of features :) Yeah... I feel somewhat betrayed. Time to switch to a different drive brand :) Thanks for your work, btw. I try :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
Hey Will and Soren! :) On Sep 29, 2003, at 2:38 PM, Will Andrews wrote: On Mon, Sep 29, 2003 at 09:13:48PM +0200, Soren Schmidt wrote: First off, there is ONLY support for Promise and HPT soft RAID in the ATA driver, other vendors products are *not* supported (yet). Second, there seem to be a problem with some sil3112 setups where timeouts and what not ruins the lunch, but so far I've not been able to reproduce.. I am still unable to use my SATA drive, it's probed incorrectly as I posted earlier. Reverting to the August 10th 00:00 UTC kernel fixes this problem, so I concluded that ATAng broke this. I am not running a very recent CURRENT but I do have ATAng from a fairly early point and it works here. [I have the same chipset as Will SiI3112A RAID] If it makes any difference, my model is a SiI3112 RAID controller, but I only have one drive and it probes as ad4... the situation doesn't improve any if I add ataraid. But maybe ATAng doesn't take into account the difference between a normal and a RAID SiI 3112, if any? Even Linux probes both disks even though I have but one. I don't use any RAID capabilities beyond enabling the hardware to access SATA. Here are my dmesg's again (Sep 18th, Aug 10th kernels): http://csociety.org/~will/dmesg.badATAng http://csociety.org/~will/dmesg.Aug10.preATAng The problem shown in the first dmesg still showed itself when I tried a new kernel on Sep 25th. I'd have to reboot and see how recent my FreeBSD stuff is... I have been rather distracted by the job which pays me salary :). Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
On Sep 29, 2003, at 4:07 PM, Will Andrews wrote: On Mon, Sep 29, 2003 at 04:05:11PM -0500, David Leimbach wrote: I'd have to reboot and see how recent my FreeBSD stuff is... I have been rather distracted by the job which pays me salary :). If you can do that, I'll check out a copy of the kernel from that day and try to narrow down when the SiI3112A/WD Raptor probe broke. Hopefully that will be of more use to Soren. Ok... I built mine on Thu Sep 18 22:42:16 CDT 2003. I think that's post ATAng commit. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HFS+ driver kernel options?
On Sep 19, 2003, at 5:45 AM, Terry Lambert wrote: David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... I am going to try experimenting with building a ppc cross-build environment and try to install FreeBSD on my iPod and boot from it :) (1) iPod's default to MSDOSFS for compatability with PC's. (2) iPod's do not have a PPC, they have two ARM chips. There's a Linux that runs on iPod's that you might want to look at, if you are truly interested in doing a port of FreeBSD, but it would be an ARM port. You've misunderstood me. I want to build FreeBSD-PPC and install it on an iPod [filesystem wise] then use the iPod to boot my Mac. It doesn't really matter to me what CPU is in the iPod... just that its a handy firewire disk. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HFS+ driver kernel options?
On Sep 19, 2003, at 1:55 AM, Christian Brueffer wrote: On Thu, Sep 18, 2003 at 11:22:37PM -0500, David Leimbach wrote: Hey... just looking to see what option I need to enable to get HFS+ support... All you need should be here: http://people.freebsd.org/~yar/hfs/ Doesn't compile under CURRENT it seems. I can give more details later but right now I have to drive for a few hours so see ya later! - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HFS+ driver kernel options?
Hey... just looking to see what option I need to enable to get HFS+ support... I am going to try experimenting with building a ppc cross-build environment and try to install FreeBSD on my iPod and boot from it :) Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question related to FreeBSD Serial Console...
On Sep 1, 2003, at 6:36 PM, Nicole wrote: *SIGH* No what I want is NO serial console. DO NOT FOR ANY REASON turn off/not resp ond to the keyboard port -Dh means both keyboard and serial console... what's the problem? And please stop shouting. Dave Nicole On 01-Sep-03 Unnamed Administration sources reported Scott Long said : Aaron Wohl wrote: My notes on getting a serial console at 115200 -must be com1 -com1 must be at port 0x3F8 irq 4 -in bios set the port and irq as above -in bios set serial redirection to com1 -in bios set baud rate 115200 -in bios set RTS/CTS flow control -edit (or create) /etc/make.conf to add these lines: BOOT_COMCONSOLE_PORT= 0x3F8 BOOT_COMCONSOLE_SPEED= 115200 -cd /sys/boot -make clean -make -make install -fdisk -B No im not kidding. Part of the boot knowing baud rate loader lives in the main disk boot block. -cd /boot -edit loader.conf -add a line: console=comconsole -edit /boot.config make it read (with a return after it): -Dh (the above is minus D h return, thats 4 characters) -cd /usr/src/sys/i386/conf -edit PASODOBLE (or whatever your kernconf is called) -add: options CONSPEED=115200 # Console Redirection -cd /usr/src -make buildkernel KERNCONF=PASODOBLE -make installkernel KERNCONF=PASODOBLE -reboot -pray At one time I was working on patches to the loader to make the console speed configurable. At the time, at least, I didn't see any evidence that the settings were stored in the boot0 block, but maybe I was wrong. In any case, finishing this up is on my TODO list. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- Daemons will now be known as spiritual guides -Politically Correct UNIX Page Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One. -C.A. Burland, Echoes of Magic Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive. -James Redfield, The Celestine Prophecy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question related to FreeBSD Serial Console...
On Sep 1, 2003, at 2:47 PM, Scott M. Likens wrote: I have a question related to FreeBSD Serial console, I am aware you can use -Dh for both internal and serial, but is it possible to see the 'kernel' boot messages sent on both the serial and the console? If your BIOS supports serial port redirection you can do GRUB over serial :) I used to. I don't know that FreeBSD can run its serial driver before its kernel that loads the driver is loaded. [got that? I didn't :)] Of course the boot loader could always support it right? It was a question that was asked to me by a client, and after researching it more, it seems that it's not possible. Am i wrong? or did I miss an option that's not documented? Sincerely, Scott M. Likens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
I am rather naive on the topic but don't many drives have a single drive jumper which works better than a master with no slave at times? On Wednesday, August 13, 2003, at 5:43 AM, Gavin Atkinson wrote: On Wed, 13 Aug 2003, Soeren Schmidt wrote: It seems Gavin Atkinson wrote: ata1: spurious interrupt - status=0x7f error=0x7f reason=0x7f ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 acd0: CDROM SAMSUNG CD-ROM SC-152A at ata1-slave PIO4 OK, your CDROM doesn't like to be a sole master it appears... I hate it when people respond with this, but I'm going to join them and say It works under Windows... Also, under the new code, this problem prevents the booting of the machine, but under the old code the machine carries on booting after giving up on the drive. Is it possible for this failure mode to not prevent the booting of the machine at least? Gavin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AW: new.h is missing
On Tuesday, July 29, 2003, at 5:51AM, Kai Mosebach wrote: Tried that too, but wasnt working either. [EMAIL PROTECTED]:/usr/sapdb/src/FreeBSD/sys/src/SAPDB] # locate new|grep include /usr/include/c++/3.3/backward/new.h /usr/include/c++/3.3/new /usr/include/c++/3.3/new ought to be it. did you try your program with #include new yet? is that sufficient for g++ to find ? regards Kai -Ursprüngliche Nachricht- Von: Michael Reifenberger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 12:03 An: Kai Mosebach Cc: [EMAIL PROTECTED] Betreff: Re: new.h is missing On Tue, 29 Jul 2003, Kai Mosebach wrote: Date: Tue, 29 Jul 2003 11:54:25 +0200 From: Kai Mosebach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: new.h is missing Hi, I am running FreeBSD 5.1-CURRENT (22.07.03) im trying to port a software, and on compile time i get Tools_List.hpp:51:17: new.h: No such file or directory Shouldn't that be: ... #include new ... since new.h is not standart any longer... Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on S-ATA and ICH5 (now owns hardware :)
atapci1: Intel ICH5 SATA150 controller port 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 9 at device 31.2 on pci0 ... ata2: at 0xc000 on atapci1 ad4: success setting UDMA133 on Intel ICH5 chip ad4: ST3120023AS/3.01 ATA-6 disk at ata2-master ad4: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA133 ad4: piomode=12 dmamode=34 udmamode=70 cblid=1 Shouldn't this drive be found as a SATA150 device? Well, technically yes, but in practice the modes the drives reports back as supported are the old UDMA ones, however the interface will run at SATA150 speed no matter what. I've not found a surefire way to tell this apart yet that also gives resonable results if you use a SATA-PATA dongle and other wierd comboes now possible... Yeah. My drive shows up as UDMA133 also. What I did notice is that my WD Raptor was slightly outperformed a few times on UFS2 by my actual ATA-100 Western Digital drive. This seems somewhat bad as the Raptor costs a hell of a lot more and one would hope that it would pound the ATA-100 drive pretty thoroughly. Even the CPU overheads on both drives were about the same. Maybe its that 8MB caching :). I haven't found a good reason yet. Soeren, do you actually have SATA drives to test with or do you just have SATA adapters with SATA-PATA dongles? Do you need more hardware to run some benchmarks yourself? [I don't know that I can afford to buy you a SATA disk but I wonder anyway :)] Dave -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Monday, July 14, 2003, at 01:33PM, Terry Lambert [EMAIL PROTECTED] wrote: David Leimbach wrote: This is a good policy in general, however, one could easily argue that what is trying to be determined with signedness and such being less-than-compared to 0 isn't really a big deal and possibly the only way to implement this numeric_limitsT::digits thing without any type introspection which C++ currently lacks. The following would work for example in a template function: [ ... ] True... but I don't think I was talking about a one-shot disabling of the message. I was thinking more about how a compliant C++ compiler can determine the signedness of a datatype without type introspection or type metadata available at compile time. [which seems to be what numeric_limitsT is all about doesn't it?] Dave Gcc needs a #pragma to disable specific warnings as a one-shot. This was discussed in detail on the GCC mailing list. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Saturday, July 12, 2003, at 11:05PM, Alexander Kabaev wrote:
On Sat, 12 Jul 2003 23:13:12 -0400
Craig Rodrigues [EMAIL PROTECTED] wrote:
I am guessing that the C preprocessor does not think that it is
in a system header, and thus prints out the warning.
We specifically disable automatic warning suppression for system
headers, because we _want_ to know about them. Your Linux distribution
apparently does not care.
This is a good policy in general, however, one could easily argue that
what
is trying to be determined with signedness and such being
less-than-compared
to 0 isn't really a big deal and possibly the only way to implement this
numeric_limitsT::digits thing without any type introspection which
C++ currently
lacks.
The following would work for example in a template function:
template typname T
void foo(T const f)
{
if (numeric_limitsT::digits % 2)
//type is signed
else
//type is unsigned
}
However to implement digits we have that nasty macro that makes the
comparison
which is meaningless for unsigned types of 0.
This is probably a perfect example of where the C++ standards committee
folks should
be queried about the best way to implement numeric_limitsT::digits.
Some of them
have had no trouble pointing out that C99's tgmath.h header cannot be
implemented in
pure standard C99. This may also be true of numeric_limitsT::digits.
I am going to the newsgroups... My old college advisor is/was a
moderator on
comp.lang.c++.moderated and he may just know the answer :).
Any GCC/FreeBSD expert care to comment? ;)
Short of fixing offending files in FSF libstdc++ or turning warning
suppression back on for standard C++ include files selectively, I have
no suggestion.
I'd rather we fix the problem in gcc but this extra verbosity when
there is nothing
wrong with user code also seems incorrect. I think the gcc developers
should have a
separate command line option for internal headers don't you?
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 8:13AM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Craig Rodrigues [EMAIL PROTECTED] writes: : I think that this is a FreeBSD issue. I compiled : the same file under Linux, with a GCC 3.3.1 checked out on 7/11 : and did not encounter this warning. keep in mind that on linux the -wno-system-headers is default, while it isn't default on freebsd, which is why we see it and you don't there... Ah, excellent... this is exactly what I was looking for. :) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. See section 6.2.6.2 of the C99 standard which enumerates the following 3 negative number representations: ¡Xthe corresponding value with sign bit 0 is negated (sign and magnitude); ¡Xthe sign bit has the value-(2^N )(two¡¦s complement); ¡Xthe sign bit has the value-(2^N -1) (one¡¦s complement). further: Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one¡¦s complement), is a trap representation or a normal value. Inthe case of sign and magnitude and one¡¦scomplement, if this representation is a normal value it is called a negative zero. Yes... a negative 0. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: : 134 #define __glibcpp_signed(T) ((T)(-1) 0) : #define __glibcpp_signed(T) (!((T)(-1) 0)) Why not the simpler: #define __glibcpp_signed(T) ((T)(-1) = 0) that way we have an overlap on the range of the two types, so we won't get a warning. We know for a fact that -1 != 0 for all known machine types (all machines are two's complement, or are required to behave as if they are two's complement, per the standard). You keep saying this... where is this must behave as two's compliment stated? (unsigned int) -1 == 0x (assuming 32-bit int). or with a valid one's compliment C99 compliant system (unsigned int) -1 = 0xfffe; even on a one's complement's machine, without the standard conversion, the 'type punning' conversion of -1 would yield 0xfffe, which is still 0. Correct :). I still don't think C enforces two's compliment. Dave Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. So for the one way conversion of signed to unsigned it will behave like 2's compliment all the time. What about back to signed? I assume that it defaults back to the platform's implementation of the signed type which due to the conversion to unsigned would also, logically, be encouraged to behave as a 2's compliment signed number. Cute way to make the standard seem flexible. The overhead of type conversion is often overlooked in coding it seems... On some platforms like the PPC going from int to float takes a lot longer than one might think... but that is another story :). [no need to answer this... unless we take it out of this thread] And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. No arguments here. :) Sorry if we wandered off too far. It was at least enlightening for me and hopefully others. Dave -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
Heh that's because the offending macro __glibcpp_digits calls
__glibcpp_signed (T)
on an unsigned type which does a compareison.
std::numeric_limits signed long::digits on a 32bit FBSD will yield 31
because its
got 31 bits for magnitude.
Unfortunately the way it seems to go about calculating that stuff at
compile time
seems to be invalid due to the fact that it does 0 compares on
unsigned types.
Is this a gcc issue or a FBSD issue? [is this the original gcc c++
header file or has
it been tweaked?]
Dave
On Saturday, July 12, 2003, at 10:53AM, Craig Rodrigues wrote:
Hi,
If I compile the following program:
#include iostream
int main(int argc, char *argv[] { return 0; }
with the following flags:
g++ -W -Wall b.cc
I get lots of warnings that did not appear in GCC 3.2:
In file included from /usr/include/c++/3.3/bits/locale_facets.tcc:43,
from /usr/include/c++/3.3/locale:47,
from /usr/include/c++/3.3/bits/ostream.tcc:37,
from /usr/include/c++/3.3/ostream:535,
from /usr/include/c++/3.3/iostream:45,
from b.cc:1:
/usr/include/c++/3.3/limits:630: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:631: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:730: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:731: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:830: warning: comparison of unsigned
expression 0
is always false
/usr/include/c++/3.3/limits:831: warning: comparison of unsigned
expression 0
is always false
Is there a way to fix the limits header file?
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
Hi, I think that this is a FreeBSD issue. I compiled the same file under Linux, with a GCC 3.3.1 checked out on 7/11 and did not encounter this warning. I think you hit it on the head. I looked in the source code of gcc and found this: /usr/src/contrib/gcc/c-common.c 2597 case LT_EXPR: 2598 if (extra_warnings !in_system_header 2599! (TREE_CODE (primop0) == INTEGER_CST 2600 ! TREE_OVERFLOW (convert (c_common_signed_typ e (type), 2601 primop0 2602 warning (comparison of unsigned expression 0 is alway s false); 2603 value = boolean_false_node; 2604 break; I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. If I take the following preprocessed source (test.ii) and compile it under FreeBSD with g++ -W -c test.ii: === # 1 test.cc # 1 built-in # 1 command line # 1 test.cc # 1 /usr/include/c++/3.3/iostream 1 3 # 43 /usr/include/c++/3.3/iostream 3 static const int digits = (sizeof(unsigned int) * 8 - ((unsigned int)(-1) 0)); === I get: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false If I compile the same file on my Linux box, with a gcc checked out from the FSF CVS repository (gcc version 3.3.1 20030711 (prerelease)), I do not get the warning. I am not an expert on the GNU C preprocessor format, but I changed two of the lines in the above file to: # 1 /usr/include/c++/3.3/iostream 1 # 43 /usr/include/c++/3.3/iostream and when I recompiled it under Linux, I also got the warning: In file included from test.cc:1: /usr/include/c++/3.3/iostream:44: warning: comparison of unsigned expression 0 is always false Any GCC/FreeBSD expert care to comment? ;) -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Silicon Image SiI 3112 Serial ATA controller support?
Yeah... and it works wonderfully On Sunday, July 6, 2003, at 11:13AM, Arjan van Leeuwen wrote: On Sunday 06 July 2003 18:01, Soeren Schmidt wrote: It seems Arjan van Leeuwen wrote: (...) I committed support for that couple of days ago: ata-chipset.c: revision 1.32 date: 2003/07/02 10:50:44; author: sos; state: Exp; lines: +114 -46 Update the SATA support code to work more correctly with real SATA disks now that I can test it. Add support for the SiI 3112 SATA chip using memory mapped I/O. Update the support for the SiI 0680 to use the memio interface as well. Thanks! I'll update immediately. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 4.7 to 5.1 buildworld failed! (fwd)
What is the exact problem? I think I had an issue with one of the config utilities not running so I clobbered it and ran the one in /usr/src/usr.sbin/ manually and things started to work again. Did you have a different issue? Dave On Thursday, July 03, 2003, at 01:26PM, Nick Wood [EMAIL PROTECTED] wrote: Did you ever figure out this problem? I'm running into the same thing? Nick ProHosting ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftream errors under g++ 3.2.2
On Sunday, June 29, 2003, at 1:19PM, Allan Bowhill wrote:
I recently updated one of my machines to -current to adapt some code to
build under the new version of gcc (3.2.2). However, file IO using
fstream
gives error messages about implicit typenames being deprecated, and I
can't
for the life of me figure out what to do my code to make the compiler
happy.
Has anyone encountered this?
Below is a small example illustrating the problem. The source below
should
compile fine on a previous version of g++, as in -stable. However, it
will
not compile on -current using g++ 3.3.2. Does anyone know what to do
to the
simple source below to get it to compile happily under -current?
(yes, I have checked gnu gcc's mailing list and FAQ/docs. I can't find
an
adequate explanation for it. I suspect it has something to do with
stricter
conformance to the finalized C++ standard, but since I am still a
novice any
explanation by gcc developers would probably have slipped by me)
Your code below is fine... there is something wrong with the C++
headers used
in the FreeBSD tree. I haven't seen this on other platforms. I don't
think that those with commit access generally do a lot with C++
[possibly a bad assumption, but I have
a hard time believing the problem would have lived so long if this
weren't the case]
Dave
-
#include fstream
int main()
{
std::ofstream afile(test.txt);
afile some data;
}
--
gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.2 [FreeBSD] 20030205 (release)
-
g++ test.cc
In file included from test.cc:1:
/usr/include/g++/fstream:304: warning: `typename
std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:304: warning: implicit typename is deprecated,
please
see the documentation for details
/usr/include/g++/fstream:309: warning: `typename
std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:309: warning: implicit typename is deprecated,
please
see the documentation for details
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftream errors under g++ 3.2.2
On Sunday, June 29, 2003, at 1:44PM, Jeffrey Hsu wrote:
file IO using fstream gives error messages about implicit typenames
being deprecated, and I can't for the life of me figure out what to do
my code to make the compiler happy
Change your /usr/include/g++/fstream as follows:
Can someone commit this change so we don't all have to do this every
time
we rebuild? :) I think there might be other offending headers too.
Dave
--- /usr/include/g++/fstreamSun Jun 29 09:17:46 2003
+++ fstream Sun Jun 29 11:33:38 2003
@@ -299,12 +299,12 @@
// Generic definitions.
template typename _CharT, typename _Traits
-basic_filebuf_CharT, _Traits::int_type
+typename basic_filebuf_CharT, _Traits::int_type
basic_filebuf_CharT, _Traits::underflow()
{ return _M_underflow_common(false); }
template typename _CharT, typename _Traits
-basic_filebuf_CharT, _Traits::int_type
+typename basic_filebuf_CharT, _Traits::int_type
basic_filebuf_CharT, _Traits::uflow()
{ return _M_underflow_common(true); }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
I don't think you understand what I believe he was trying to say. Commits to CVS are NOT atomic therefore getting a copy of FBSD in between David's start and finish of commits would be broken. When he says he is finished.. I bet it will work again. Now if we were all using Perforce this would be different as commits are atomic I think :). Its free to use for open source projects too but the practicality of making everyone learn something new is not necessarily a good idea :). Dave On Saturday, June 28, 2003, at 04:47 AM, David Schultz wrote: On Sat, Jun 28, 2003, David Xu wrote: I begin to commit KSE signal code, libkse will be broken for a while. Umm...if it's known to be broken, then why did you commit it? If you want people to test KSE and report bugs, the version in the tree needs to be of consistently good quality. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
Because we aren't working on anything and need something to do... so we find ways to think about how we can enforce quality without understanding how stuff works first maybe? :) Just a guess. Dave On Saturday, June 28, 2003, at 02:20 PM, Julian Elischer wrote: he means that between the time the commits start and finish there may be an inconsistant period.. Why is everyone so eager to jump down everyone else's throat these days? On Sat, 28 Jun 2003, David Schultz wrote: On Sat, Jun 28, 2003, David Xu wrote: I begin to commit KSE signal code, libkse will be broken for a while. Umm...if it's known to be broken, then why did you commit it? If you want people to test KSE and report bugs, the version in the tree needs to be of consistently good quality. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
On Saturday, June 28, 2003, at 3:18PM, David Schultz wrote: On Sat, Jun 28, 2003, David Leimbach wrote: Because we aren't working on anything and need something to do... so we find ways to think about how we can enforce quality without understanding how stuff works first maybe? Umm...no, but thanks for the insult. How about: Because we are working at 3 AM to figure out why signals aren't getting delivered to java properly and we see an email saying that things will be more broken ``for a while'' and misinterpret what ``for a while'' means in this context. See previous post. Well I apologize... it seemed we had yet another person ready to jump on someone for bothering to commit an important piece of code. My email was caught in a state where it was neither sent nor delivered but I replied to your original mail hours ago... I even think I cancelled the one that offended you but apparently not early enough. I apologize again for the insult... I just thought you were being somewhat harsh on someone who may have had a minor english language barrier. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
No problem... I still should have watched my mouth and not shot it off at the other David when he had a valid question. Its amazing how much of an attitude one can read into another person's email. Sometimes I think we project how we are feeling at that moment in time into what we read in other's mail. Emoticons are clearly not enough to express the full story that is lost through voice inflections and body language. I am sure there is interesting psychological and sociological research to be done there :) Anyway... thanks for your hard work despite illness. I appreciate it very much [both of you: Xu and Schultz] Dave On Saturday, June 28, 2003, at 5:54PM, David Xu wrote: David Leimbach, Thank you for your reply and explain the reason for me, I normally won't reply such complain. At that time, I was very tire and sick, after one week of hardwork and sleep late at night for KSE signal code, I think nothing is important than committing the code and let it be tested widely. Thank you again, David Xu - Original Message - From: David Leimbach [EMAIL PROTECTED] To: David Schultz [EMAIL PROTECTED] Cc: David Xu [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 28, 2003 8:42 PM Subject: Re: HEADS UP: new KSE signal code I don't think you understand what I believe he was trying to say. Commits to CVS are NOT atomic therefore getting a copy of FBSD in between David's start and finish of commits would be broken. When he says he is finished.. I bet it will work again. Now if we were all using Perforce this would be different as commits are atomic I think :). Its free to use for open source projects too but the practicality of making everyone learn something new is not necessarily a good idea :). Dave On Saturday, June 28, 2003, at 04:47 AM, David Schultz wrote: On Sat, Jun 28, 2003, David Xu wrote: I begin to commit KSE signal code, libkse will be broken for a while. Umm...if it's known to be broken, then why did you commit it? If you want people to test KSE and report bugs, the version in the tree needs to be of consistently good quality. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Friday, June 27, 2003, at 05:46 PM, Doug White wrote: On Fri, 27 Jun 2003, Glenn Johnson wrote: I have a P4 processor on order that will support hyperthreading. I was wondering what the general opinion is on enabling HTT for FreeBSD-5 (current). Thanks for any input. He didn't ask how... he asked for OPINIONs. Its been my experience that most OSes don't do any better with hyperthreading on.. Now I haven't tried with FreeBSD but at my company we disable hyperthreading in the BIOS by default. Supposedly the brand spanking new Intel chip will have better hyperthreading but the real results remain to be seen. man 4 smp See the machdep.hlt_logical_cpus sysctl. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ReiserFS
I certainly have heard of no such plans. FreeBSD 5 comes with UFS2 as the default filesystem and you can achieve many of the benefits of a journaling file system by enabling soft-updates. I believe the FreeBSD handbook has more on the topic and you can browse it online at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html Dave On Saturday, June 21, 2003, at 06:19 AM, Simon Watson wrote: Are there any plans for including reiserFS support in FreeBSD? I plan to move my desktop over to FreeBSD 5 at some point, but I can't seem to find any mention of reiser for it. Thanks Simon -- Simon Watson [EMAIL PROTECTED] http://swat.me.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about developers handbook definition of encumbered.
As I am slowly trying to get my feet wet with kernel programming I was browsing through the developers handbook. The following surprised me a bit: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ policies-encumbered.html So this claims that GNU licensing is *not* encumbered... is this correct? Based on recent discussion threads on this list I would assume it is not correct. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE can't find SIL 0680 IDE controller
On Thursday, June 12, 2003, at 06:15 PM, Mike Schreckengost wrote: Hello everyone, First off, let me express my appreciation for all of the hard work that has been put into the 5.1-RELEASE of FreeBSD. I have installed it, and am extremely happy with the way that it performs on my system. Having said that, here is my dilemma: I have a Silicon Image 0680 IDE hard drive controller that (for the most part) works flawlessly in FreeBSD. The problem is that it gets detected during the boot process *ONLY IF* I first boot into another operating system (Linux, in my case), issue the 'shutdown -r now' command, and then reboot into FreeBSD. If I power up the system and immediately try booting FreeBSD, it is not found. I had a friend who had an ISA PNP sound card that did that exact thing with linux. He had to initialize it with DOS then reboot and it worked... Sounds like some PCI initialization/detection bug? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libevent for FreeBSD ?
Interesting. I don't believe it needs to be in the source tree. I am not saying its bad code or isn't useful... I just don't understand what it has to do with FreeBSD. Does any of the other base code need this library? If so it would already be there wouldn't it? Dave On Tuesday, June 10, 2003, at 06:18 PM, Martin Blapp wrote: Hi, Has anybody seen this the recent NetBSD posting about libevent ? http://mail-index.netbsd.org/tech-userlevel/2003/06/08/.html What do you think about it ? Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386-undermydesk-freebsd?
I thought it was the Monica Lewinsky edition of FreeBSD. On Thursday, June 5, 2003, at 07:20 PM, Mike Barcroft wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What does i386-undermydesk-freebsd refer to? What is it used for? Is there an i386-inthedrawer-freebsd, or i386-intheXbox-freebsd? As a general rule of thumb, FreeBSD boxes should be kept under desks. If your system isn't under a desk, consider moving it. Best regards, Mike Barcroft ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
interesting problem
So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? Currently I can only get Mandrake linux 9.1 to install on this disk as it has the 2.4.21[pre release I assume] linux kernel that does recognize this controller [even Windows XP Pro does not recognize this newer hardware and I didn't get a floppy drive yet for the new machine]. Can I cross compile FreeBSD 5.1 [RC or otherwise] from Mandrake Linux to include the necessary support then burn a CD of the generated ISO images? It would be super-cool if I could :) and a decent learning experience Might be worth documenting it if I can figure it out. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wednesday, May 28, 2003, at 01:23 AM, Terry Lambert wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. The FreeBSD DDI/DKI is not well enough documented, let alone versioned, let alone stable enough over time for this to work. Consider how long a third party binary-only driver would keep working for someone following -current, and you will see the problem. I think for current all bets are off anyway. I think supporting a 3rd party driver should really only have-to support releases. Now I may have to re-evaluate that thought for a stable tree as there is a level of confidence there that everything else will probably still work... it could be tricky :) [just scrambling to put the worms back in the can] Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach [EMAIL PROTECTED] wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Either which way I doubt either driver will go into the tree. I don't see any good reason to stick any of it in the kernel unless its absolutely necessary. I am not a religious person when it comes to licensing. I just don't like GPL style restrictions. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
. Well, network driver is a special case as it is this weird binary 'kernel' + OS shim combination which is getting popular lately. Have you thought about getting NVidia's permission to link non-GPLed shims with their binary object? I have thought about it... but don't know enough to pursue it at the moment. I am quite the amatuer... A quick scan through NVidia audio driver sources suggests that the device is very similar to Intel ICH2 AC'97-based cards. Should you see is BSD-led ich.c driver can be reused instead of the Linux driver? From the release notes: the audio driver is based on the open source i810 audio driver but has been modified to work with NVIDIA hardware. I don't want to guess how much modification will be needed to make the nvidia one work. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Remember that's it's legal to to distribute seperate binaries, as long as you comply with the GPL for the GPL'ed binary, but it's a violation of clause 6(b) of the GPL to combine them into one binary and distribute them, if you are legally obligated to not give out the source code for the non-GPL'ed portion. And since the only thing that gives you the right to use the code in the first place is the license... IANAL but I think the GPL has provisions for binaries that contain code that is not necessarily dependant but merely aggregated into one package. Still I agree... it must be a module for more than one very good reason :). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Just give me a good smack...
I don't know what the hell happened but it won't happen again as I am now vowing to avoid using the Safari, .mac webmail combination. For some reason it kept coming back with no server response and giving me no confirmation that the mail was ever sent via webmail... I just retried a few times and apparently all of them went but I was never told. now's your chance to get free hits on me! Deep apologies... Dave Leimbach ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Just building the lib part of world
Or even better would be just building libc. I have been working on my getpwnam_r assignment... examining implementations in both Darwin and NetBSD and started trying to implement some of this code for FreeBSD... Its not anywhere even near the goal in sight as I am still learning the build system. Do I always have to build world or can I get away with just making some subdirectories? If so what is the best way to do this? Rebuilding gcc each time I just want to test out my code is a real drag :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just building the lib part of world
Hmmm for some reason I thought that would be the simple answer... also at one point in time unistd.h gave me trouble when I didn't build libc under world. Is libc_r the correct place to put getpwnam_r anyway? My understanding is that just where the userland thread implementation goes. I never got a clear answer to that question either... basically I haven't made much progress due to being unclear on several of these little issues. Dave On Sunday, March 23, 2003, at 07:33 AM, Matthew Emmerton wrote: - Original Message - From: David Leimbach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 8:29 AM Subject: Just building the lib part of world Or even better would be just building libc. I have been working on my getpwnam_r assignment... examining implementations in both Darwin and NetBSD and started trying to implement some of this code for FreeBSD... Its not anywhere even near the goal in sight as I am still learning the build system. Do I always have to build world or can I get away with just making some subdirectories? If so what is the best way to do this? If you're just experimenting wiht getpwnam_r, you can just rebuild libc_r: cd /usr/src/lib/libc_r make make install -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just building the lib part of world
Whew... :) Me too unfortunately. I know basically what it takes to make a thread safe function... and I have found good implementations of getpwnam_r in other OSes and some not so good looking ones as well but I haven't really been able to integrate one into our current system which appears to be centralized in lib/libc/net/nsdispatch.c. There is a lot of global state in there that would hinder the ability to make a fully reentrant function. It may be that the whole subsystem must be replaced before this is really possible in a clean way. Take that above statement however you wish... I am pretty new to this whole kernel/OS thing :). Dave On Sunday, March 23, 2003, at 07:50 AM, Matthew Emmerton wrote: Sorry, you're right. libc is where you want to be putting your code. (I'm suffering from multiple-OS-itis right now.) -- Matt - Original Message - From: David Leimbach [EMAIL PROTECTED] To: Matthew Emmerton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 8:46 AM Subject: Re: Just building the lib part of world Hmmm for some reason I thought that would be the simple answer... also at one point in time unistd.h gave me trouble when I didn't build libc under world. Is libc_r the correct place to put getpwnam_r anyway? My understanding is that just where the userland thread implementation goes. I never got a clear answer to that question either... basically I haven't made much progress due to being unclear on several of these little issues. Dave On Sunday, March 23, 2003, at 07:33 AM, Matthew Emmerton wrote: - Original Message - From: David Leimbach [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 8:29 AM Subject: Just building the lib part of world Or even better would be just building libc. I have been working on my getpwnam_r assignment... examining implementations in both Darwin and NetBSD and started trying to implement some of this code for FreeBSD... Its not anywhere even near the goal in sight as I am still learning the build system. Do I always have to build world or can I get away with just making some subdirectories? If so what is the best way to do this? If you're just experimenting wiht getpwnam_r, you can just rebuild libc_r: cd /usr/src/lib/libc_r make make install -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just building the lib part of world
Thanks for all the helpful responses... :) On Sunday, March 23, 2003, at 01:38PM, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] David Leimbach [EMAIL PROTECTED] writes: : Or even better would be just building libc. I have been working on my : getpwnam_r assignment... : examining implementations in both Darwin and NetBSD and started trying : to implement some of : this code for FreeBSD... Its not anywhere even near the goal in sight : as I am still learning the : build system. : : Do I always have to build world or can I get away with just making some : subdirectories? If so : what is the best way to do this? : : Rebuilding gcc each time I just want to test out my code is a real drag : :) First off, make -DNOCLEAN for incremental things isn't so bad. Second, after a buildworld/installworld, cd src/lib/libc make depend make will do the trick. I've used this several times. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CVSROOT directory gone?
I can't seem to get a mirror copy of the CVSROOT directory with my cvsup script. This worked fine a few days ago. cvsup2.FreeBSD.org is the server I used. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. --- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) --- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVSROOT directory gone?
Ah... my bad thanks for the response. I wish I actually had time to read all the emails I actually get :) Dave On Wednesday, March 5, 2003, at 08:34 AM, Michael Hostbaek wrote: The following mail was sent to current@ from Peter Wemm yesterday: snip Anybody who uses the cvs-supfile example to get the repository should add cvsroot-all to their supfile. This is in addition to src-all, ports-all, doc-all etc. This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you use tag=. or tag=RELENG_4, then you are not affected by this. I have updated cvs-supfile in -current but not RELENG_4 yet. Cheers, -Peter /snip /mich David Leimbach (leimy2k) writes: I can't seem to get a mirror copy of the CVSROOT directory with my cvsup script. This worked fine a few days ago. cvsup2.FreeBSD.org is the server I used. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Well there are firewire hubs and the machines I typically do this on are Macs which generally have 2 firewire ports... you can make a small ring network that way. Dave On Wednesday, March 5, 2003, at 08:36 AM, Cagle, John (ISS-Houston) wrote: Wouldn't you need a firewire switch to do a cluster of more than 2 nodes? Or are you thinking of using multiple firewire interfaces per node? -Original Message- From: David Leimbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:32 AM To: Christopher Fowler Cc: [EMAIL PROTECTED] Subject: Re: IP over IEEE1394? True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
I hadn't thought of this Interesting :) Dave On Wednesday, March 5, 2003, at 08:41 AM, Christopher Fowler wrote: You can run IP via PPP. PPPD is used all the time for VPN. I've got 2 networks that are combined via PPPD over a tunnel because they are both on private networks and have only 1 public IP. However, The overhead could get you. I'm not sure you want to go down the writer of creating another interface. Maybe you could use the SLIP interface and capture that IP stuff and send across. On Wed, 2003-03-05 at 09:32, David Leimbach wrote: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
On Wednesday, March 5, 2003, at 10:13 AM, Christopher Fowler wrote: If toy are using PVM or similar technologies, would'nt the best route to be to pick a transport that is the fastest. Last thing you want is messages to be bogged down in transport. Assuming you can afford the hundreds of thousands of dollars to purchase such a good transport sure :). Personally I don't think people should purchase clusters but they should purchase cluster time on a well configured server like a utility. IBM seems to believe this is true also. I would stay away from message passing over slow links. You could use the firewall for heartbeat. People do clustering with fast ethernet all the time. ... I know because we sell a lot of it where I work :). Gigabit ethernet is better but switches are costly. Dave On Wed, 2003-03-05 at 09:32, David Leimbach wrote: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
The interconnect is just 10% of the whole cluster story. Firewire is one possibility, but Fibrechannel you could do today if you wanted to. We have Fibrechannel support in the Qlogic isp(4) driver (thanks Matt!) today. Yeah... if you are lucky 10% :). In fact latency in messages isn't as important as some people would like you to believe either. A well written MPI library [and MPI application] allows overlap of communication and computation that improves the overall wall clock time of the job... which is the ultimate goal. Get it done correctly and get it done ASAP! :) but that's WY offtopic now :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
I believe i386 compatible code was disabled in the kernel because it was hindering the performance of more advanced Intel based architectures. Supposedly you can build it back in but that would either require building a release yourself or finding someone who already built the i386 version. Might be nice to have two x86 ISO versions for releases in that case so people don't feel screwed :). Dave On Thursday, February 27, 2003, at 04:24 AM, Poul-Henning Kamp wrote: --- Forwarded Message Return-Path: [EMAIL PROTECTED] Date: Thu, 27 Feb 2003 05:19:48 -0500 (EST) From: Geoffrey [EMAIL PROTECTED] To: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Re: Volunteer with genuine i386 cpu lots of time wanted. In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `][!RL*!!,$i!`[=! X-Spam-Status: No, hits=0.00 required=0.90 On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: Is there anybody out there who can try to run a straight -current on a _real_ i386 class CPU ? Ie, not a i486, not a Cyrix, not an AMD but a genuine Intel i386DX (SX would be but too suicidal to be informative). Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: int=0006 err= efl=00010086 eip=c0211a71 eax=0004 ebx=c0389154 ecx= edx=c036dc60 esi=c0389238 edi=c0389148 ebp=c082dd5c esp=c082dd5c cs=0008 ds=0010 es=0010 fs=0018 gs=0010 ss=0010 cs:eip=0f b1 15 1a 20 37 c0 0f-94 c0 0f bb c0 85 c0 74 02 c9 c3 6a 00 6a 00 6a 00 6a-00 68 00 20 37 c0 a8 1a ss:esp=94 dd 82 c0 de 0b 00 c0-00 00 00 00 00 00 00 00 00 00 00 77 00 c0 91-38 c0 00 00 00 00 00 00 BTX halted hmmm .. you think it doesn't like my hardware? I could try installing something previous (like 4.7) and cvsupping if you are interested. Please let me know - I'm game for this and it is a pleasant break from wrangling world weary sun3s back into some semblance of service. Thankyou. --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Posix testsuites?
I have been looking into helping with the C99 conformance stuff and I wondered if the following would be helpful? http://posixtest.sourceforge.net/ I am sure some of you knew about this... I guess I wonder if a link on the C99 web page is appropriate under resources and links. Also in my attempts to decide what to do about getpwnam_r I have been contacted by someone else who is taking a crack at this... I am going to try to synchronize with them so we don't end up in any kind of competition. This person is also familiar with the code [I think may have written the existing non-reentrant version] and will probably get much farther along than I can in my meager spare time I have dedicated to this. I will at least be able to serve as a tester of sorts. I will also try to find any other ways to help that I can. Dave Leimbach [sorry if this is the wrong list] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
error in nsdispatch.c
There is a potential bug in src/lib/libc/net/nsdispatch.c in the function const ns_dbt * _nsdbtget(const char * name). The static variable static time_t confmod; is not initialized to anything. It may have some random value the first time this function is called and if you look at the program logic its the first value tested as well and it controls a lot of deallocation via free. Bug? I have been having trouble writing to standards... sending to current. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: error in nsdispatch.c
Bug? no. static variables are initialized with all-zeroes. Groovy... /me goes to buy electronic ANSI C standard :P Dave /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Best method to produce patches?
I am about to try to make some changes to FreeBSD current... Should I begin to use read-only CVS instead of CVSup for this work or is it possible to generate diffs based on CVSup'd sources? What is the recommend method to use for playing with the source? I already found a small change in libc that should probably get committed but I want to generate the patch properly for everyone's approval. Thanks! Dave Leimbach To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: printf....!
Isn't it ultimately interrupt 08 on the PC with an index in the EAX register for the write subroutine? I am pretty sure that's correct. I might have the interrupt value wrong though. Dave On Saturday, February 8, 2003, at 04:12 PM, Auge Mike wrote: Hi all, I was trying to know how printf works in FreeBSD... I hvae reached to this point : #define _write(fd, s, n) \ __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n)) I'am not really familiar with the way FreeBSD handle interrupts. I like from any one of you to tell me what functions will be called next and in which files, till we get the string of the printf function argment displayed in the terminal. Yours, _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Interested in helping the C99 integration project
Hi, I am a software developer who has benefitted greatly from using FreeBSD the past few years as well as other software like KDE. I have been doing what I can here and there to make sure big projects like KDE will build and run on FreeBSD as well as other operating systems. I came to the realization that we [FreeBSD users/developers] are missing some thread safe functions like getpwnam_r. I was wondering if I could somehow help ease the burden either by testing or implementing some of these functions. Who do I want to organize with to help with this stuff? Thanks! Dave Leimbach To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interested in helping the C99 integration project
See http://www.freebsd.org/projects/c99/ Wes Peters has been assigned this task for a while. Perhaps you could co-ordinate with him. Yes and no offense to him... I am sure he is busy. Its not done yet :) I will contact him and see if I can lend a hand in any way. Thanks for the information! Dave Leimbach Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
Hey lets find a way to keep this goddamned thread going.. huh can we... yeah... please... I love hitting delete!!! Keep it up and we'll be as cool as [EMAIL PROTECTED] ... /sarcasm On Sunday, September 1, 2002, at 07:12 PM, Matthew Jacob wrote: Matthew Jacob wrote: Yes, as best as I can. But I didn't see a GCC 3.2 import on anyone's bullet list. To quote Robert Watson: My list basically consists of: General - GEOM as default storage management on all platforms, related dependencies - Switch in sysinstall to easily turn on ufs2 - Final resolution of any perl removal related problems - rcNG as the default boot mechanism - New gcc? Small bullet item. Alexander is new at working within our operation so we should give him some room to get fully up to speed. I'm glad that somebody other than me is dealing with this. :-) We really did need this to be done before 5.0-R as the gcc prerelease was a bit of a showstopper when it cannot compile a whole bunch of 'must have' packages. (eg: KDE etc) Lets say that developer awareness of the pending import should have been dealt with better and chalk it up as a learning experience. Of course. And being accused of 'trolling' is also a learning experience. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2 in progress
On Sunday, September 1, 2002, at 07:14 PM, David W. Chapman Jr. wrote: Of course. And being accused of 'trolling' is also a learning experience. I would have to agree with your sarcasm, seems like there is a big troll hunt and everyone is being accused. I wouldn't call it trolling but I would call it stretching the bounds of being on topic. The accusation was unfair however the amount of exchange on the topic [and off] may have gotten out of hand. This tends to irritate people. Dave -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX Loader issue with today current
Make a GRUB floppy root (hd0,0,a) [first partition, first slice, first drive] kernel=/boot/loader boot have fun :) On Friday, Aug 30, 2002, at 11:33AM, David W. Chapman Jr. [EMAIL PROTECTED] wrote: GTX Loader 1.0 BTX Version 0.00 Error: Client format not supported Anyone have any ideas to be able to boot. I'm seeing this as well. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.1 / streambuf.h broken with using namespace std;
sstream is the correct header. This is not a bug On Tuesday, August 27, 2002, at 08:21 PM, Alexander Langer wrote: Thus spake Terry Lambert ([EMAIL PROTECTED]): What's going on wrong here? GCC 2.9x can compile this, 3.1 cannot: Delete and reinstall your header files. They must match the compiler you are using, and you must not have stale header files from the previous compiler version. The -STABLE - -CURRENT upgrade path is broken then. Use at least GCC 3.2, if you feel compelled to use a buggy non-maintenance release level GCC; alternately, wait for 3.3. I felt like using -CURRENT's 3.1, as it is expected. Well, I'll try to look if a new world fixes the problem, though I bet it won't. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
