DTrace built-in variables
Are the build-in variables cpu and curcpu supported in a 8.1-RELEASE DTrace? Dr. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: [PREVIEW] bsdconfig(8)
-Original Message- From: Alexander Best [mailto:arun...@freebsd.org] Sent: Tuesday, March 06, 2012 1:10 AM To: Devin Teske Cc: freebsd-hackers@freebsd.org; Ron McDowell Subject: Re: [PREVIEW] bsdconfig(8) On Mon Mar 5 12, Devin Teske wrote: [snip] Some here may already know that Ron McDowell and I have been hard at- work developing the replacement for sysinstall(8)'s Configure menu -- which we have named bsdconfig(8). [snip] 3) when bsdconfig starts the note regarding the packages shouldn't state Pascal. most people probably don't know what pascal is. ;) how about VirtualBox or chromium? these packages are probably used by a lot more users. 4) do we really need fdisk and disklabel? hasn't freebsd moved onto gpart and glabel? Both of these issues are addressed in the latest snapshot tarball... http://druidbsd.sf.net/download/bsdconfig/ Latest is bsdconfig.120307.txz -- Thanks Alex, Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
mfid, raid monitoring daemon
I'm trying to decide if I should cram mfid for mfi(4) controllers into the src tree or if we should package it up into a ports package. I suspect that either one is acceptible, but it seems to make more sense to put it into the src tree since mfiutil is also there. Comments? Sean ref: http://svnweb.freebsd.org/base/user/sbruno/mfid/ signature.asc Description: This is a digitally signed message part
De-warning...ing clang Kernel Builds
Is there anyone actively working on cleaning up the codebase to not throw warnings when built with clang. I realize these warnings do not matter, but I generally prefer to get rid of warnings if possible. I can't imagine it would take too long, although I could see an issue with developers not familiar with the clang warning system forgetting to check clang builds for warnings while they add new code. -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: De-warning...ing clang Kernel Builds
On 2012-03-08 19:16, Brandon Falk wrote: Is there anyone actively working on cleaning up the codebase to not throw warnings when built with clang. I realize these warnings do not matter, but I generally prefer to get rid of warnings if possible. I can't imagine it would take too long, although I could see an issue with developers not familiar with the clang warning system forgetting to check clang builds for warnings while they add new code. Take care saying these warnings do not matter. Unfortunately, it is not as simple as that. In some cases, the warnings are indeed superfluous, and it is rather annoying to fix them (a.k.a shut up the compiler). In other cases, however, the warnings point out real problems. Obviously, those problems can be fixed, but sometimes that is either very hard, or very disruptive, or both. And there are even cases where the problem may be very subtle, and cannot be fixed without extremely careful inspection (and retrospection). Last but not least, applying fixes may break code in unexpected ways. Especially if the code has been sitting untouched for years, it is prone to be sensitive to even the smallest changes... One big issue is that there are no tinderbox builds that use clang, and therefore people don't notice that commits introduce new warnings (or errors, even) when building with clang. This is something that should be fixed sooner rather than later. On the other hand, if -CURRENT would be switched to use clang by default, the problems would hopefully be taken care of sooner. :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DTrace built-in variables
On Thu, Mar 8, 2012 at 8:27 AM, Dr. Baud drb...@yahoo.com wrote: Are the build-in variables cpu and curcpu supported in a 8.1-RELEASE DTrace? Dr. Unfortunately not. However, you can approximate them with (IIRC) curthread-td_oncpu. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DTrace built-in variables
On Thu, Mar 8, 2012 at 8:27 AM, Dr. Baud drb...@yahoo.com wrote: Are the build-in variables cpu and curcpu supported in a 8.1-RELEASE DTrace? Dr. Unfortunately not. However, you can approximate them with (IIRC) curthread-td_oncpu. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Graphical Terminal Environment
On 03/07/12 08:04, Dieter BSD wrote: Brandon writes: (If you haven't noticed, I'm going to keep finding excuses to write this as I really am kindof excited to learn/work on it) ideas: Display PostScript rio (from Plan 9) If you're mainly looking for a low-level graphics project, maybe reverse engineer something on the GPU (e.g. UVD) Looks like I may have been a little late to the party, but I'd suggest looking at Plan9 for ideas - this is exactly what it does. It is an OS with windows capabilities builtin (unlike Windows ironically enough, despite its dependencies), Rio itself is a WM like DWM or similar. I'd be surprised if it didn't have a similar api structure as you have outlined previously. For reference to access it like you would ssh on unix you use Drawterm instead, if that gives you any indication of its workings. Essentially no matter which way you look at it you'll be reinventing the wheel; but it does sound like fun! :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
