Giant
I'm interested in learning more about Giant. Is there any helpful websites people can recommend? TIA, Chris Dempsey __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 14:34:07 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BE We are (or at least I am) talking about changing it to prevent links to a BE string that can _never_ be a valid pathname. Fortunately, in POSIX there BE is only one such string (the empty string). Maybe, but it seems a harmless special case to me, and others seem to find it useful. BE Here's an example of a standard utility being clueless about symlinks to BE nothing: BE BE $ ln -s '' foo BE $ cp foo bar BE cp: foo is a directory (not copied) That *is* broken, it should make bar a symlink to '' IMHO. BE cp is also broken for symlinks to valid pathnames for nonexistent files; BE BE $ rm -f foo BE $ ln -s /nonesuch foo BE $ cp foo bar BE BE This duplicates foo as a symlink, but should just fail. This is correct behaviour IMHO - why on earth should it fail. If I copy a directory containing symlinks I don't want them do vanish just because the target is unavailable. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Mbuf Allocator (some graphs)
* Jonathan Lemon [EMAIL PROTECTED] [010616 00:56] wrote: On Fri, Jun 15, 2001 at 07:44:59PM -0400, Bosko Milekic wrote: Here are some performance results. Keep in mind that we're still under Giant. http://people.freebsd.org/~bmilekic/code/mb_alloc/results.html Just for comparision, 6-way results are at: http://www.flugsvamp.com/~jlemon/fbsd/netpipe/ Are you sure those aren't inverted? (i.e. swap(present, mb_alloc)?) In any case, the mb_alloc code you used still has the malloc() and free() calls during cluster allocation and freeing and still, it looks to me as very comparable nonetheless. I've updated the page with results from running Bosko's latest code (without the malloc/free calls). The results are at the above URL. The performance of the new allocator on this benchmark comes out ahead of the old one. It would be better if we could allocate/free clusters+mbufs+refcounts under a single lock. It would simplify the API and save a boatload of cycles and i-cache by avoiding the mutex operations. Not that I object to the current code, I'm just wondering when this important optimization is going to be made, or that the interface will settle down enough so that I can get started on it. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote: On Sat, 16 Jun 2001 14:34:07 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BE cp is also broken for symlinks to valid pathnames for nonexistent files; BE BE $ rm -f foo BE $ ln -s /nonesuch foo BE $ cp foo bar BE BE This duplicates foo as a symlink, but should just fail. This is correct behaviour IMHO - why on earth should it fail. If I copy a directory containing symlinks I don't want them do vanish just because the target is unavailable. Because cp copies file contents, not file nodes (unless the -R flag is specified). This is clarified in current POSIX drafts. gnu cp gets this right. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
support Pentium3 SSE
--- Forwarded Message
Date: Thu, 14 Jun 2001 04:20:46 +0900 (JST)
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: support Pentium3 SSE
From: [EMAIL PROTECTED] (NAKAMURA Kazushi)
Hello! Don't lose to Linux2.4.x!
I use FreeBSD as graphic workstation. I made a patch for support
Pentium3's SSE extension. The PR# is kern/28070 .
http://www.freebsd.org/cgi/query-pr.cgi?pr=28070
And there are WWW pages about SSE on FreeBSD environment.
#(poor) english
http://kobe1995.net/~kaz/FreeBSD/SSE.en.html
#(native) japanese
http://kobe1995.net/~kaz/FreeBSD/SSE.html
#test code
http://kobe1995.net/~kaz/FreeBSD/loop.C.gz
MMX instructions can be used without any difficult. But SSE
instructions are needs kernel support. I tested ONLY single
cuppermine celeron. Please test Pentium3/4 or SMP environment.
I afraid that it does NOT work in SMP environment, because the
access of (static) svxmm may conflicts. Allocate in stack,
insted static, is difficult to align 16 Byte boundary.
#Most SSE instructions are needs 16Byte alignment.
Any good idea?
SSE instructions are effective to audio or visual applications.
For example, MP3 encoding by celeron/667@750MHz:
###without SSE(may be using MMX)
% gogo -lang eng -nopsy -test -off sse
GOGO-no-coda ver. 2.39 (Jun 8 2001)
Copyright (C) 1999, 2000 PEN@MarineCat and shigeo
Special thanks to Keiichi SAKAI, URURI, Noisyu and Kei
test time 600sec
*** at bench in the early afternoon [benchmark mode] ***
MPEG 1, layer 3 j-stereo
inp sampling-freq=44.1kHz out sampling-freq=44.1kHz bitrate=128kbps
input file `stdin'
output file `default.mp3'
{ 22968/ 22968} 100.0% ( 16.93x) re:[00:00:00.00] to:[00:00:35.43]
End of encoding
time= 35.433sec ( 16.93x)
^^
###with SSE
% gogo -lang eng -nopsy -test
GOGO-no-coda ver. 2.39 (Jun 8 2001)
Copyright (C) 1999, 2000 PEN@MarineCat and shigeo
Special thanks to Keiichi SAKAI, URURI, Noisyu and Kei
test time 600sec
*** at bench in the early afternoon [benchmark mode] ***
MPEG 1, layer 3 j-stereo
inp sampling-freq=44.1kHz out sampling-freq=44.1kHz bitrate=128kbps
input file `stdin'
output file `default.mp3'
{ 22968/ 22968} 100.0% ( 35.58x) re:[00:00:00.00] to:[00:00:16.86]
End of encoding
time= 16.852sec ( 35.60x)
^^
Thank you!
--- End of Forwarded Message
--
mailto:[EMAIL PROTECTED] NAKAMURA Kazushi@KOBE
http://kobe1995.net/~kaz/index-e.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 17:27:00 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BEThis is correct behaviour IMHO - why on earth should it fail. If I BE copy a directory containing symlinks I don't want them do vanish just because BE the target is unavailable. BE BE Because cp copies file contents, not file nodes (unless the -R flag is BE specified). This is clarified in current POSIX drafts. gnu cp gets BE this right. *WHAT*, let me get this straight POSIX drafts now suggest that cp *should* turn a symlink into a file ? I truly dread to think how much that would break. Please tell me I have the wrong end of the stick here, failing that someone please tell me that FreeBSD will not follow this madness. Hang on, the target of a symlink *is* the content of the symlink not the content of the file that may or may not be at the target. At least it always used to be that way. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote: On Sat, 16 Jun 2001 17:27:00 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BE This is correct behaviour IMHO - why on earth should it fail. If I BE copy a directory containing symlinks I don't want them do vanish just because BE the target is unavailable. BE BE Because cp copies file contents, not file nodes (unless the -R flag is BE specified). This is clarified in current POSIX drafts. gnu cp gets BE this right. *WHAT*, let me get this straight POSIX drafts now suggest that cp *should* turn a symlink into a file ? I truly dread to think how much that would break. cp always did this (except in the broken case of a broken symlink). POSIX just clarifies it. From the FreeBSD manpage for cp(1): -RIf source_file designates a directory, cp copies the directory and the entire subtree connected at that point. This option also causes symbolic links to be copied, rather than indirected through, ... Symbolic links are always followed unless the -R flag is set, in which case symbolic links are not followed, by default. ... Please tell me I have the wrong end of the stick here, failing that someone please tell me that FreeBSD will not follow this madness. You have the wrong end of the stick :-). Hang on, the target of a symlink *is* the content of the symlink not the content of the file that may or may not be at the target. At least it always used to be that way. No. Wrong end... Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Sat, 16 Jun 2001 22:30:58 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: BE cp always did this (except in the broken case of a broken symlink). POSIX BE just clarifies it. From the FreeBSD manpage for cp(1): Ignore me, I think I must be going temporarily insane. -- Directable Mirrors - A Better Way To Focus The Sun http://www.best.com/~sohara To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The PR db is not for -current problems, right?
Hello fellow PR drivers, just before I hit more people over the head that have submitted PRs against problems on -current: my understanding is that -current users know what they are doing, especially that they're living on the bleeding edge and that they must be subscribed to current@ where they shall discuss -current-related malfunctions. Right? BTW, why does each and every PR seem to have this line: Submitter-Id: current-users This is mildly confusing to me. What's the purpose of the Submitter-Id? Another one I don't understand and which is (almost?) always empty: Quarter: Whazzat? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The PR db is not for -current problems, right?
Hello, On Sat, Jun 16, 2001 at 02:51:38PM +0200, Jens Schweikhardt wrote: Hello fellow PR drivers, just before I hit more people over the head that have submitted PRs against problems on -current: my understanding is that -current users know what they are doing, especially that they're living on the bleeding edge and that they must be subscribed to current@ where they shall discuss -current-related malfunctions. Right? It was my understanding this far, that is why I always bug this list when something is wrong:-P BTW, why does each and every PR seem to have this line: Submitter-Id: current-users It is what it this field is set to by default. Consider this snippet from my build logs: === gnu/usr.bin/send-pr sed -e 's,@DATADIR@,/etc,g' -e 's/@DEFAULT_RELEASE@/`uname -rsm`/g' -e 's/^SUB MITTER=.*/SUBMITTER=current-users/' /usr/src/gnu/usr.bin/send-pr/send-pr.sh s end-pr (line wrap) As you can see there some sort of customization going on here, otherwise people would have to figure out a whole lot more by themselves. As to why exactly the name current-users has been selected, well... I guess because there used to be the current users of this product (ie those using it at present) and eg past-users. Of course, some installation problems should be reported by future-users by this token:-) Yes it is confusing to some extent but this is the best explanation I could come up with. I think all the BSDs have it set to this value by default. Note that this field does not appear on the web pr form under http://www.freebsd.org/send-pr.html. This is mildly confusing to me. What's the purpose of the Submitter-Id? Another one I don't understand and which is (almost?) always empty: Quarter: Whazzat? No idea... This certainly does not appear on the form nor on the pr-form that the send-pr command itself presents you with. BTW while we are at it, I have thought about this for quite some time: OpenBSD calls their version of send-pr sendbug (and I note that on FreeBSD this name is also a symlink to send-pr at least on -CURRENT). I think that this or some other name would be more appropriate than send-pr ie send Problem Report. Why? Because people then have a hard time understanding why their problem reports (like: I cannot boot) are closed and they are referred to the mailing lists instead. As I see it, our PR system is used more for reporting actual software bugs, so sendbug would be ok. (although sometimes I get the feeling that not even that, PRs should only be filed against bugs that are officially acknowledged to exist after talking to the developer in question, in which case the PR db is more like a filofax but I am getting way off-topic here) I recognize that send-pr is what this piece of software is called and that most users have no problem deciding what to use it for (including myself) but maybe a better name would explain it better to a new user... after all, send-pr *could* be used as a general support tool, but we do not use it for this purpose. Just my HUF 0.02 and the heat... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New Mbuf Allocator (some graphs)
On Sat, Jun 16, 2001 at 03:11:21AM -0400, Alfred Perlstein wrote: It would be better if we could allocate/free clusters+mbufs+refcounts under a single lock. It would simplify the API and save a boatload of cycles and i-cache by avoiding the mutex operations. Not that I object to the current code, I'm just wondering when this important optimization is going to be made, or that the interface will settle down enough so that I can get started on it. Well, as I've mentionned to you previously, I don't think this will be an optimization. The mb_alloc code already shares the same lock for both mbufs and clusters and, as for counters, it is not efficient to allocate them from the mb_alloc allocation routines (due to their extremely small size, we would consume double the memory to manage them). So what I've done in mb_alloc is have the counters malloc()ed. However, as I've mentionned, and as I've already (although quickly) implemented in order to perform testing, I'm going to change it so that for clusters, the space for the reference counter will actually be located at the end of the unused portion of the cluster. As for the other types of buffers, I'll have to sit and think about it some more but there are obvious solutions that are more optimal than the present malloc() scheme which I've put in for simplicity purposes. In any case, I don't *think* it will be an actual optimization (because the lists are now per-CPU and there doesn't seem to be a genuine reason for it), but if, once the dust settles, you can figure out a way to easily implement it without pessimizing any of the code to do it, then it's certainly worth a shot. After all, you were right about some of these not-so-obvious things before. :-) I think that once we have the new code in, and once I fix the little malloc() thing, that we should really focus on the remainder of the net code simply because I want to see Giant get lifted from this area. -- -Alfred Perlstein [[EMAIL PROTECTED]] Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom. Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The PR db is not for -current problems, right?
On Sat, 16 Jun 2001 14:51:38 +0200, Jens Schweikhardt [EMAIL PROTECTED] said: against problems on -current: my understanding is that -current users know what they are doing, especially that they're living on the bleeding edge and that they must be subscribed to current@ where they shall discuss -current-related malfunctions. Right? Wrong. -current users know what they are doing, and are (supposed to be) smart enough to be able to tell the difference between a glitch and a bug. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
In message [EMAIL PROTECTED], Jordan Hubbard writes: From: Matt Dillon [EMAIL PROTECTED] Subject: Re: symlink(2) [Was: Re: tcsh.cat] Date: Fri, 15 Jun 2001 22:01:47 -0700 (PDT) Symlinks do not have to contain paths. People use them for all sorts of things so it would be totally inappropriate to put any sort of True. It would break phk's malloc debugging features to disable this, for example. Not only that, but considerning that a symlink can point into a different filesystem even in normal use, there is no simple way to validate the valididty of the name. Consider this symlink: ln -s /my_FAT16_filesystem/foo:bar /tmp/blaf as a silly example of this. The only two real restrictions on symlinks are that they cannot contain NUL characters and that '/' means what '/' does in all filesystem naming on UNIX. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
convert libgmp to a port?
I was looking at PR/9233 from Dec 1998 the other day, and I saw that the version of libgmp thats included in the base-system seems to be very outdated (version 2.x in our tree, while version 3.x is available at the homepage of libgmp). After discussing this with [EMAIL PROTECTED] about it through mail, I started looking through the sources to see where libgmp is used. It may be a false impression of mine, but in the -STABLE sources that I checked, I didn't seem to find anyone in the base-system `using' libgmp. I tried grepping through the entire /usr/src to find one place except for contrib/libgmp that seems to be using functions from libgmp (I was looking for functions that matched \mp[.]*_.*). I dont seem to be able to find some part of the base system that actually *does* use libgmp. Being out of date as it is, do you think it's proper to remove it from the base system and make it a port? /me ducks to save his head from the flames -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCCARD and -current
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : I make a short patch to sharing IRQ between a PCIC and a PC Card when using : PCI IRQ routing. : #Does this patch help you? Yes. I've made a larger patch and committed it that mostly works without changes (you still need to add -I, but not -i) to the old configuration. Your patch motivated me to make it. I think this will fix some problems that people with multiple slots. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
In message [EMAIL PROTECTED] Karsten W. Rohrbach writes: : lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock - 1.0.0.127:6= : 12 : this is actually more performant than writing ascii text into a file and : checking the file by opening and parsing it. you simply do not have to : fopen() and stuff. very convenient ;-) ls -l /etc/malloc.conf :-) Warnr To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
In message [EMAIL PROTECTED] Steve O'Hara-Smith writes: : I would argue loud and long that changing that *would* be broken. There : is never a guarantee (or even an implication) that a symlink points to a : valid directory entry (think unmounted filesystems, NFS ...). I find it hard : to imagine why creation time should be special in that regard. And it would break /etc/malloc.conf! I'd have to agree 100% here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ps 'D' state - ?
Sat, Jun 16, 2001 at 23:21:33, Tor.Egge ([EMAIL PROTECTED]) wrote about Re: ps 'D' state - ?: Are `select' and `nanosleep' disk uninterruptable waits? ;| No. The ps command gave wrong output. flag = k-ki_p-ki_flag; - sflag = k-ki_p-ki_flag; + sflag = k-ki_p-ki_sflag; OK, it seems fixed. Let's commit it. ;) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
