I've added you as a friend on Doostang
Hi, I’ve requested to add you as a friend on Doostang, an invite-only career community started at Harvard, Stanford, and MIT. You can use Doostang to find a job or internship, network, and access valuable career information from peers and industry professionals. Regards, Huy To accept this invitation, please visit: http://www.doostang.com/s/u?s=GPWsZraXuW --- If you don't want to receive future invitations or emails from Doostang, click here: http://www.doostang.com/logins/noemail?arg=200d26c9721196d0d5ca76a9d231b0fc4a6c2d98___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding sysctls
Zane C.B. wrote: Any one know of any recent documentation for adding a sysctl to a kernel module for FreeBSD 6 and 7? This might help: Title: "An Introduction to FreeBSD 6 Kernel Hacking" URL: http://caia.swin.edu.au/reports/070622A/CAIA-TR-070622A.pdf Disclaimer: I co-wrote it. Cheers, Lawrence ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding sysctls
In the last episode (Jun 18), Zane C.B. said: > Any one know of any recent documentation for adding a sysctl to a > kernel module for FreeBSD 6 and 7? man 9 sysctl -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
adding sysctls
Any one know of any recent documentation for adding a sysctl to a kernel module for FreeBSD 6 and 7? signature.asc Description: PGP signature
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Dag-Erling Smørgrav wrote: Andrey Chernov <[EMAIL PROTECTED]> writes: "BSD sort" as an idea will be a good project indeed, but "BSD sort" implementation we currently have at hand is totally misleading and should be rewritten from the scratch, I realize it when long time ago I try to localize it for single byte locales. I think part of the problem is that there aren't enough people who truly understand localization. I think I understand most of it, but I'm pretty sure I *don't* understand how collation works, or is supposed to work. Amongst other things, I don't understand how (or whether) it handles cases like "aa" and "å", which are considered the same letter in Norwegian. Perhaps you could create a Localization page on wiki.freebsd.org which addresses these issues, or at least points to relevant resources? Good regression test suite which would include cases in different single and multi-byte locates for grep/sort/etc could also be a big help. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Mon, 16 Jun 2008, Dag-Erling Smørgrav wrote: Doug Barton <[EMAIL PROTECTED]> writes: Andrey Chernov <[EMAIL PROTECTED]> writes: Please note that BSD grep is not localized (and can't be per design) and works only with standard C locale. It may not affect ports system processing but shurely affects real texts handling. That is very troubling. In this day and age localization is a requirement. I cannot imagine being supportive of adding something to the base that does not have this capability. We don't have a locale-aware regex implementation. Henry Spencer wrote one for Tcl 8, and it seems to be under an MIT-equivalent license, but I'm not sure how hard it would be to extirpate. It might be easier to lift it from PostgreSQL, which also uses it. Other BSD-license-friendly regex libraries: 1. PCRE (http://www.pcre.org/) (has a POSIX compliant interface too) 2. Oniguruma (http://www.geocities.jp/kosako3/oniguruma/) (from Ruby) 3. Lrexlib (http://lrexlib.luaforge.net/) (no apparent POSIX interface) Sean -- [EMAIL PROTECTED]___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output
John Baldwin wrote: > Try this change: > > jhb 2007-10-27 22:07:40 UTC > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. Awesome. Thanks. That looks like it'll do the trick. I'll deploy it and keep the list posted. Stef ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How do I list what CPU core is on what package?
Hi Everybody: Simple question, if I want to know if a cpu X is on a particular package is there an easy way to list this? Normally my understanding is on most machines, every other LAPIC id is on the same package. So 0,2,4,6 would be on one package and 1,3,5,7 would be on another (say in a 2-way quad-core) and I am assuming (I haven't checked source) that the OS lists them in LAPIC order. Thanks! -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output
On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > I've been trying to track down a deadlock on some newish production > servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > specific (although mundane) hardware configuration, and each of several > servers running this hardware deadlock about once per week. > > Although I suspect that this is not hardware related, from a (naive) > perusal of the attached stack traces. > > Forgive me if my interpretation of this is all wrong, but I'm pretty > desperate for help. So here's my basic understanding of the deadlock: > > These processes seem to be waiting on the page queue mutex: > sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) > bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) > httpd (in trap > trap_pfault > vm_fault) > [g_up] (in g_vfs_done > bufdone) > > The page queue mutex is held by rsync process: > rsync (in trap > trap_pfault > vm_fault > pmap_enter) > > Rsync kernel process (in pmap_enter) was interrupted while holding the > page queue lock? > > > Giant is enabled in loader.conf due to the needs of the pf firewall when > dealing with user credentials lookups. I do not believe that Giant plays > into this deadlock. Kernel config attached. > > Any and all help or info is welcome. Thanks in advance. Try this change: jhb 2007-10-27 22:07:40 UTC FreeBSD src repository Modified files: sys/kern sched_4bsd.c Log: Change the roundrobin implementation in the 4BSD scheduler to trigger a userland preemption directly from hardclock() via sched_clock() when a thread uses up a full quantum instead of using a periodic timeout to cause a userland preemption every so often. This fixes a potential deadlock when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held by a thread pinned or bound to another CPU. The current thread on that CPU will never be preempted while softclock is blocked. Note that ULE already drives its round-robin userland preemption from sched_clock() as well and always enables IPI_PREEMPT. MFC after: 1 week Revision ChangesPath 1.108 +8 -29 src/sys/kern/sched_4bsd.c We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD when softclock() (swi4: clock) blocks on a lock like Giant. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Decent 3D acceleration in 64bit mode?
Hi, Given that Nvidia aren't offering a driver for their cards for 64bit FreeBSD, is anyone else having success using another (preferably PCI-E) card with 3D acceleration? Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Wed, Jun 18, 2008 at 11:14:16AM +0200, Konrad Jankowski wrote: > I think the best place for this type of information is currently my SoC > wiki. > http://wiki.freebsd.org/KonradJankowski/Collation > I know currently it has very little information, however. > I can also create another page dedicated to explaining the workings of > collation in UCA, given enough interest. Please look at ICU library. Almong other thing they implement Unicode collation: http://icu-project.org/userguide/Collate_Intro.html -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Wed, Jun 18, 2008 at 12:40:24PM +0200, Dag-Erling Sm??rgrav wrote: > For grep, I believe it should simply be a matter of calling setlocale(), > using wide strings, and using a multibyte regex engine (for appropriate > values of "simply"). See my prev reply telling more details. Using wide strings is not so easy, f.e. all ctype BSD grep now uses should be converted to wctype, input conversion added, etc. > Another thing I'm unsure about is the matter of input and output. Do > mbstowcs() / mbtowc() simply trust the input to conform to LC_CTYPE and > convert accordingly? When reading UTF, do they recognize and handle They return EILSEQ on wrong sequence. -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Wed, Jun 18, 2008 at 11:39:10AM +0200, Dag-Erling Sm??rgrav wrote: > Does that mean our wcsxfrm() doesn't work? IIUC, it should convert > wide strings to strings that can be compared directly with strcmp()? (directly with wcscmp()) For single byte locales wcsxfrm() and wcscoll() works, but for multibyte they do just raw binary. > In any case, this is a libc issue, right? As long as sort / grep uses > the API correctly, they will work fine once libc is fixed? GNU grep and sort will work just fine. BSD grep not calls setlocale() but even it will be added, BSD grep have other places where multibyte is not handled proberly. I already notice two of them: ignore case comparison and word boundary sensing, perhaps other places exists, I not study the code enough to cach them all. BSD sort uses upper half of 256 char table on its own purposes so badly damage both single byte and multibyte locales and of couse not use wcscoll() at all etc. -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Konrad Jankowski <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > In any case, this is a libc issue, right? As long as sort / grep > > uses the API correctly, they will work fine once libc is fixed? > Correct. Given sort uses strcoll()/wcscoll()/strxfrm()/wcsxfrm() and > call setlocale(). I don't know about grep. For grep, I believe it should simply be a matter of calling setlocale(), using wide strings, and using a multibyte regex engine (for appropriate values of "simply"). Another thing I'm unsure about is the matter of input and output. Do mbstowcs() / mbtowc() simply trust the input to conform to LC_CTYPE and convert accordingly? When reading UTF, do they recognize and handle BOMs, or simply treat them as zero-width non-breaking space? In the absence of a BOM, do they assume that the input follows the system's native byte order? (IMHO, the API is broken, since there is no way for the same program to simultaneously handle streams with different encodings, but I guess it's too late to fix that) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Andrey Chernov <[EMAIL PROTECTED]> writes: > Single byte locales collation works through strcoll() via chains, i.e. > seek all chains starting with given letter. Multibyte locales collation > currently is not implemented and can't be properly implemented under > existen single byte framework (it will consume resourses badly in that > case). I know semi-hacking attempts to implement multibyte collattion via > single byte one, but all they are only for small ASCII + national alphabet > subset, rest of Unicode left unsorted. Does that mean our wcsxfrm() doesn't work? IIUC, it should convert wide strings to strings that can be compared directly with strcmp()? In any case, this is a libc issue, right? As long as sort / grep uses the API correctly, they will work fine once libc is fixed? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Wed, Jun 18, 2008 at 10:22:31AM +0200, Dag-Erling Sm??rgrav wrote: > I think part of the problem is that there aren't enough people who truly > understand localization. I think I understand most of it, but I'm > pretty sure I *don't* understand how collation works, or is supposed to > work. Amongst other things, I don't understand how (or whether) it > handles cases like "aa" and "??", which are considered the same letter in > Norwegian. Single byte locales collation works through strcoll() via chains, i.e. seek all chains starting with given letter. Multibyte locales collation currently is not implemented and can't be properly implemented under existen single byte framework (it will consume resourses badly in that case). I know semi-hacking attempts to implement multibyte collattion via single byte one, but all they are only for small ASCII + national alphabet subset, rest of Unicode left unsorted. > Perhaps you could create a Localization page on wiki.freebsd.org which > addresses these issues, or at least points to relevant resources? IMHO single byte collating will be obsolete soon when Unicode collation will be implemented as SoC project, we needs something like ICU library which performs as described below, i.e. unified sorting for all possible chars: http://unicode.org/reports/tr10/ -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Tue, Jun 17, 2008 at 12:58:12PM +0200, Gabor Kovesdan wrote: > >> Yes, and once this is done, sort will work out of he box, if it uses > >> strcoll. Already tried on a prototype. > >> > > > > Only GNU sort for multibyte chars. BSD sort is programmed too badly and > > can't be fixed even for single byte sorting. > > > BSD sort was going to be the next item of my SoC project. As it is so > badly constructed would it be reasonable to give more priority to BSD > diff and continue with that one? "BSD sort" as an idea will be a good project indeed, but "BSD sort" implementation we currently have at hand is totally misleading and should be rewritten from the scratch, I realize it when long time ago I try to localize it for single byte locales. The next nice idea in that area will be updating our regexp engine to most recent public code, both for speed and minor compatibility reasons, as des@ mentions. I don't have an opinion for BSD diff. -- http://ache.pp.ru/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Andrey Chernov <[EMAIL PROTECTED]> writes: > "BSD sort" as an idea will be a good project indeed, but "BSD sort" > implementation we currently have at hand is totally misleading and should > be rewritten from the scratch, I realize it when long time ago I try to > localize it for single byte locales. I think part of the problem is that there aren't enough people who truly understand localization. I think I understand most of it, but I'm pretty sure I *don't* understand how collation works, or is supposed to work. Amongst other things, I don't understand how (or whether) it handles cases like "aa" and "å", which are considered the same letter in Norwegian. Perhaps you could create a Localization page on wiki.freebsd.org which addresses these issues, or at least points to relevant resources? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
