Re: HEADS UP: Removal of libobjc from the base system
Yeah it's too outdated to be of any use. IMHO, you can axe libf2c too... cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Removal of libobjc from the base system
--- On Mon, 4/18/11, Scott Long wrote: ... > > Yeah it's too outdated to be of any use. > > > > IMHO, you can axe libf2c too... > > > > Honest question here, is there a newer version of libf2c > that lives in ports and is adopted by people who use > fortran? The one that I find in the base system seems > to be a similar match to the one in ports/devel/f2c. > Is the one in the base system a pain to maintain or > otherwise holding back other work, or has it been made > obsolete by something in ports? Is removing it from > the base system anything more than just churn? > I am a moderate user of Fortran: when I need it I use gfortran instead of f2c. lang/f2c is in the ports tree, and the one port I made (tochnog) that actually depends on libf2c uses the port, not the system library. Considering we are not carrying fortran in base anymore, it would seem logical to kill libf2c, but it must be said the f2c port originates in netlib, I have no idea where the GPL'd libf2c comes from or if there is any significant difference. cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Removal of libobjc from the base system
--- On Mon, 4/18/11, Scott Long wrote: ... > > > > We do not have f2c in tree and it was disconnected > from the build even > > longer than that. > > > > Guess I was looking on an old system, sorry for the noise. > > Scott > Ugh.. pointyhat is all mine please... It's still linked in the wiki, so I got confused: http://wiki.freebsd.org/ContribSoftware Pedro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Anyone that can check a dtrace bug/fix?
Hello; I was checking out some dtrace links and I noticed a bug found by Bryan Cantrill here: http://dtrace.org/blogs/bmc/2011/03/09/when-magic-collides/ the patch is rather easy and looks like it applies to our code (i386 and amd64) too: http://dtrace.org/resources/bmc/dtrace-signal.patch I don't really use Dtrace and the bug itself is pretty rare to bitten by so I am not the right guy to even PR it. While here, I should also mention that the Joyent llquantize patch is here: http://dtrace.org/resources/bmc/dtrace-llquantize.patch And if you are curious on what the Joyent/dtrace guys are doing lately, you can watch about 2 Hrs of video here: http://www.ustream.tv/recorded/12123446 cheers, Pedro. cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
FWIW; Christopher Bergström and Pathscale delivered the EKOPath Compiler Suite, but no one followed up: (From the WantedPorts Wiki) https://github.com/pathscale/path64-suite There has been very low interest in the FreeBSD port, and unfortunately this is a bad signal that we give to companies that want to contribute :(. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrade contributed gperf, m4 and flex
Thank you Baptiste!! I understand exactly why you want this :). Please close gnu/161289 when you are done. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
Hi Daniel; --- On Sat, 12/3/11, Daniel Eischen wrote: ... > > I would love to mirror the SVN repo in the same way > and have an 'svn' in base, or at least something that > could replace CVS in the above scenario. > I have to say I am surprised by all the people that still use CVS (for their own good reasons). It still would be helpful if cvs users could evaluate OpenCVS: it's been experimental for ages now. It does seem to have some advantage (other than the license) in that it's smaller and better maintained (or at least not too dead). cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVS removal from the base
--- Dom 11/12/11, Julian H. Stacey ha scritto: ... > > I have to say I am surprised by all the people that > > still use CVS (for their own good reasons). > > > > It still would be helpful if cvs users could evaluate > > OpenCVS: it's been experimental for ages now. It does > > seem to have some advantage (other than the license) > > in that it's smaller and better maintained (or at > > least not too dead). > > Did you test it with > cd /usr/src/release ; make release > TBH, I don't use CVS at all. I learned to use SVN first and for the things I needed CVS was pretty similar to SVN but pretty obnoxious when trying to check out the history due to the lack of atomic commits. I would prefer to just use the same SVN server for everything. OpenCVS is an intermediate step, at least acceptable for GPL cleaning purposes, for people that just can't move to SVN right away. Still SVN is much better and once we move we will not look back (IMHO). Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: calling all fs experts
--- Dom 11/12/11, Kostik Belousov ha scritto: > > If you wanted to get responses from experts only, sorry in > advance. > I am no fs expert but just thought I'd mention some things based on my playing with the BSD ext2fs ... > The fs (AKA UFS) uses clustering provided by the block > cache. The clustering > code, mainly located in the kern/vfs_cluster.c, coalesces > sequence of > reads or writes that are targeting the consequtive blocks, > into single > physical read or write of the maximal size of MAXPHYS. > Current definition > of MAXPHYS is 128KB. > The clustering code is really cool and the idea is that it gives UFS the advantages of an extent based fs. I haven't seen benchmarks in UFS2 but on ext2 it didn't seem to work as it should though. One issue is that ext2 doesn't support fragments and as a consequence ext2 will not use big blocksizes. This is a limitation in the ext2 design that UFS doesn't have, but still linux's ext2fs outperforms UFS in async mode (we do shine in sync mode). It was never clear exactly why this happens but it would appear there is a bottleneck in geom that is not good in writing many contiguous blocks. > Clustering allows filesystem to improve the layout of the > files by calling > VOP_REALLOCBLKS() to redo the allocation to make the > writing sequence of > blocks sequential if it is not. > > Even if file is not layed out ideally, or the i/o pattern > is random, most > writes scheduled are asynchronous, and for reads, the > system tries to > schedule read-aheads for some limited number of blocks. > This allows the > lower layers, i.e. geom and disk drivers, to optimize the > i/o queue > to coalesce requests that are consequitive on disk, but not > on the queue. > > BTW, some time ago I was interested in the effect on the > fragmentation > on UFS, due to some semi-abandoned patch, which could make > the > fragmentation worse. I wrote the tool that calculated the > percentage > of non-consequtive spots in the whole filesystem. > Apparently, even > under the hard load consisting of writing a lot of files > under the > megabytes in size, UFS managed to keep the number of spots > under 2-3% on > sufficiently free volume. > Yes, the realloc_blk code is very efficient in that. In fact it is so good it actually hides some inefficient operations in UFS. Bruce had a patch for this that I cc'd to Kirk but the difference was not big because the realloc_blk code does it's job in memory. Zheng Liu did the reallocation thing for ext2fs and it gave better results than preallocation but the results are not as spectacular as in UFS (the UFS code takes advantage of fragments there too). I do expect to commit it (kern/159233) once my mentor reviews and approves it. cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
more on non-executable mappings on NetBSD
Hi; I know everyone is busy with the upcoming release, but JIC someone is interested on this, I found this recent progress report post on NetBSD's lists: __ Subject: more on non-executable mappings To: None <[EMAIL PROTECTED]> From: Chuck Silvers <[EMAIL PROTECTED]> List: tech-kern Date: 11/28/2003 11:57:21 I'm getting back to looking at the rest of the non-executable mapping work from openbsd. (well, really this goes beyond that, to what they're calling "W^X", meaning that any given part of the user address space should not be both writable and executable.) the remaining items are: (1) update the kernel ELF code to handle more than 2 PT_LOAD sections. (2) change the linker to put the PLT, GOT and rodata into their PT_LOAD sections so that they can have different permissions than the existing "text" and "data" load sections. (3) change the runtime linker to use mprotect() to enable write access to the PLT only when needed, leaving it read-only the rest of the time. (4) other MD issues with kernel support for non-executable mappings (a) i386 currently only supports non-execute for the part of the address space where the traditional unix stack lives. this doesn't do anything for the data or bss sections, or the heap or mmap()d files (eg. shared libraries), or pthread stacks. the openbsd guys rearranged their user address space layout on i386 fairly drastically to put all the executable mappings below a certain threshold. (b) powerpc OEA hardware only supports execute permissions at a segment (256MB) granularity. ideally we would rearrange the user address space layout here as well to put all the executable mappings down in segment 0 in the usual case. the first of these should be non-controversial and I have attached a patch which implements it. I'll commit it in a week or so if there are no objections. as for the other items, I'd like opinions on whether or not we want them, and if we do, how we might achieve them with the fewest headaches. -Chuck The patch is here: http://mail-index.netbsd.org/tech-kern/2003/11/28/0019.html ___ FWIW, I posted the CVS commit log of the initial work on the -hackers list some time ago. cheers, Pedro. ps. I attempted to post this on -security but there was some error on my side of the network. Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs http://www.yahoo.co.uk/robbiewilliams ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FYI: Scalability update
http://bulk.fefe.de/scalability/#newdata "[Nov 1 2003] I got an email suggesting that I re-check NetBSD. The results are nothing short of astonishing. In two weeks time the NetBSD team made dramatic improvements. socket: previously O(n), now O(1). bind: greatly improved, but still O(n). Much less steep, though. fork: a modest O(n) for dynamically linked programs, O(1) for statically linked. mmap: a bad O(n) before, now O(1) with a small O(n) shadow. touch after mmap: a bad strange graph in 1.6.1, a modest O(n) a week ago, now O(1). http request latency: previously O(n), now O(1). Congratulations, NetBSD! NetBSD now has better scalability than FreeBSD. " __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: misc/53327: Important fix for Latin-american keymap(Latin-amer.kbd)
Hi guys, Last time I submitted a change to this file it took like a year to get it committed.. any chance this can be committed and MFC really soon? It would make a continent happy :). cheers, Pedro. --- [EMAIL PROTECTED] ha scritto: > Thank you very much for your problem report. > It has the internal identification `misc/53327'. > The individual assigned to look at your > report is: freebsd-bugs. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=53327 > > >Category: misc > >Responsible:freebsd-bugs > >Synopsis: Important fix for Latin-american keymap > >Arrival-Date: Sat Jun 14 14:10:14 PDT 2003 __ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5-STABLE Roadmap
About benchmarks... FWIW, the reiserfs people were excited about SCO's release of AIM: http://caldera.com/developers/community/contrib/aim.html but the announcement went rather unnoticed in freebsd-fs. cheers, Pedro. __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH 5.x] netns
Guys; I have to agree with Terry that the fixes for netns should be committed, and furthermore they should be MFC (using his first patch perhaps). It's a nightmare to try to rescue anything from the Attic, at least it would be nice to have it in better shape before killing it. The flame fest on removing it or not can go on ;). cheers, Pedro. __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
