Re: ifconfig output: ipv4 netmask format
On Fri, Apr 08, 2011 at 10:33:17PM -0700, Garrett Cooper wrote: On Fri, Apr 8, 2011 at 9:54 PM, J. Hellenthal jh...@dataix.net wrote: On Fri, Apr 08, 2011 at 07:36:45PM +0400, Sergey Vinogradov wrote: On 08.04.2011 19:23, Mike Oliver wrote: On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradovboo...@lazybytes.org wrote: Hi, hackers. I have a question: why ipv4 netmask is displayed by ifconfig in hex format? Isn't dot-decimal notation more human-readable? Will the attached patch break something in the very bad way? Who's using IPv4 anymore? ;-) Long live IPv4! :) Seriously though, if you give a small amount of time to learning the hex - binary translations then you would see how convenient it is to use hex rather than decimal when representing what are ultimately binary numbers. See this blog entry by Jeff Doyle... http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skills The article is great, but dot-decimal notation is de-facto standard for stand-alone network mask representation. Like CIDR is standard for IP blocks represenation. That's the reason I've started this thread. And despite the greatness of the article you've mentioned, I think it's a bad itea to hardcode its URL into ifconfig's output. You know, for every single user reading it, and choosing the way of hex ;) This is the year 2011 right ? when are we going to support new users rather than supporting old outdated washed up scripts ? I for one am for this change, given that there are lots of users from the PC-BSD community that do not read hexadecimal, octal and other such forms like a programmer does. And just because the change can be made does not mean that a compatibility shim cannot be put into place that restores the old functionality. It is time to stop living in the past and start thinking about the future. These types of things are what causes forks of projects to happen ultimately yielding in less contributors and developers. I for one hate to see things like that happen. I understand your pain and while I've been on your side of the fence several times in the past dealing with different things of this sort, having to maintain backwards compatibility is a painful reality of past design choices or mistakes. pkg_install and sysinstall are one of many examples, but there are of course other areas as well. Although I see the value of your and Sergey's argument, the problem is that it may cause unexpected breakage for other third parties that depend on a particular behavior in FreeBSD as Bjoern and others have suggested; I have a script at least that does properly parse out the hex output in order to set IPs properly with ipmitool, and I would be perturbed to have to hack around this further in my script. Mind you, this script is in my workspace, but having to track minor output changes like this across versions of FreeBSD, or interface changes like the semi-gratuitous removal of /dev/devicec in 8.x still had to be worked out on many branches my group maintains at $WORK. Getting back on track, I think that more 'user friendly' variants of FreeBSD, e.g. PCBSD, etc, could and should diverge with this one line patch as they're not mainline FreeBSD and the change is trivial for less hex inclined users as you suggest. Granted, this is just one of many bikeshed topics. Funny how many lines of debate have been written and how many feathers have been unnecessarily ruffled over the output of one printf. Yeah I can agree with that. In either case right now (to me) it makes utterly no difference and is just a cosmetic fix as I can read hex, oct, dec in either fashion and convert between them quickly. I just hate to see other non-technical users fall subject to the same things that have been support way past a deprecation period that should have ended 10+ years ago. Anyway there are so many views on this, in any case the right decision is made going forth and positives and negatives can be discussed then. -- J. Hellenthal pgpOEzTg9C6fE.pgp Description: PGP signature
Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011
Hello, I would like to remind you that the submission due date (April 15th) is approaching quickly and to this date I have received _only_ 3 submissions. Please try to find a few minutes and submit your reports so that we can inform our community about the progress made in the first quarter of 2011. Thanks! Original Message Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 Date: Mon, 21 Mar 2011 18:19:23 +0100 From: Daniel Gerzo dan...@freebsd.org Organization: The FreeBSD Project To: curr...@freebsd.org, hack...@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2011 is due on April 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo ___ 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: ifconfig output: ipv4 netmask format
Warner Losh i...@bsdimp.com wrote: Non-contigous netmasks are legal in IPv4 ... They have become illegal in the fullness of time. and/or the fullness of the address space, I suspect :) Even if they were legal, I have a hard time imagining a practical use case. ___ 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: ifconfig output: ipv4 netmask format
On 4/9/11 7:33 AM, Garrett Cooper wrote: Although I see the value of your and Sergey's argument, the problem is that it may cause unexpected breakage for other third parties that depend on a particular behavior in FreeBSD as Bjoern and others have suggested; I have a script at least that does properly parse out the hex output in order to set IPs properly with ipmitool, and I would be perturbed to have to hack around this further in my script. Thanks, -Garrett ___ 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 If the proposed change was made an option via a knob as has been suggested, that would leave your script unscathed. One might or might not like the option, and then choose to use it or disregard it. Given that one can configure their interfaces by giving a CIDR notation (like: ifconfig re0 inet 192.168.0.1/24) , it makes sense that one should be able to output the CIDR notation as well. I for one see absolutely no valid reason why the change should be rejected if it doesn't change ifconfig's default behaviour and doesn't cause any regression ? A valid reason would be: nobody wants it. But then, some people do seem to want it. I would like this option really, would prolly alias it while I'm at it. ___ 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
Kernel Tracking Question.. regarding kernel and boot files
Hi all, I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? Is ktrace the best trace suite for freebsd kernel? What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. Yours, Chris ___ 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: ifconfig output: ipv4 netmask format
Paul Schenkeveld writes: Although non-contiguous netmasks are not legal anymore in IPv4, our ifconfig still allows to do something like: # ifconfig em0 inet 10.0.5.2 netmask 255.0.255.0 # ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_M AGIC ether xx:xx:xx:xx:xx:xx inet 10.0.5.2 netmask 0xff00ff00 broadcast 10.255.5.255 media: Ethernet autoselect (1000baseT full-duplex) status: active If this is no longer legal, should ifconfig issue a warning? J. Hellenthal writes: This is the year 2011 right ? when are we going to support new users rather than supporting old outdated washed up scripts ? Change for the sake of change is not progress. Perhaps when you get more experience you will understand the joy of spending massive amounts of time attempting to deal with gratuitious changes. Personally, I'd prefer to be spending my time fixing things that are truly broken rather than repainting the bikeshed in today's fashionable color. And unfortunately there are things that are badly broken. Things that cause data loss. Hardware that isn't supported properly. Some of these are in the PR database if you need a list of useful things to work on. As far as ifconfig goes, I'm in the camp that says 1) Leave the default alone to avoid breaking scripts. 2) Add an option for those who want it. (Put some thought into it, don't just do the first thing that springs to mind.) 3) Those that want a different default can use an alias. ___ 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: ifconfig output: ipv4 netmask format
On Fri, Apr 08, 2011 at 11:43:16AM -0600, Warner Losh wrote: Non-contigous netmasks are legal in IPv4. What do you do if someone adds the CIDR flag but the netmask cannot be represented in CIDR notation? They have become illegal in the fullness of time. I'll rephrase my point, then: not all netmasks, legal or otherwise, that are accepted by ifconfig, can be represented in CIDR notation (see below). I guess the fact that ifconfig accepts them is a bug - but that merely changes my comment to Non-contigous netmasks are accepted for IPv4 addresses by some (buggy) utilities. What do you do if someone adds the CIDR flag, but the netmask cannot be represented in CIDR notation?. Cheers, Mike [root@cheddar ~]# ifconfig bridge99 create [root@cheddar ~]# ifconfig bridge99 127.255.0.1 netmask 255.255.255.1 [root@cheddar ~]# ifconfig bridge99 bridge99: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether d6:c6:07:a9:7e:b9 inet 127.255.0.1 netmask 0xff01 broadcast 127.255.0.255 [root@cheddar ~]# uname -a FreeBSD cheddar.urgle.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 24 23:04:32 GMT 2011 r...@cheddar.urgle.com:/usr/obj/usr/src/sys/GENERIC amd64 [root@cheddar ~]# -- Mike Bristow m...@urgle.com ___ 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
imposing memory limits in FreeBSD 8
While I am thrilled about the newfound zfs stability that upgrading to 8 has brought, one of the things that seems to have been dropped is support for process memory limits. I have a few servers that occasionally run out of swap due to runaway httpd daemons, and the ulimit -m settings in the startup scripts we use stopped working upon upgrading from FreeBSD 6. I've tried fiddling with the daemon class in login.conf to no avail either. About the only thing I haven't tried is running httpd under djb's softlimit executable. Here's my daemon class in login.conf: daemon:\ :memoryuse=1g:\ :datasize=1g:\ :stacksize=1g:\ :tc=default: and proof that `limits` groks the config: # limits -eHC daemon ulimit -t unlimited; ulimit -f unlimited; ulimit -d 1048576; ulimit -s 1048576; ulimit -c unlimited; ulimit -m 1048576; ulimit -l unlimited; ulimit -u unlimited; ulimit -n unlimited; ulimit -b unlimited; ulimit -v unlimited; ulimit -p unlimited; ulimit -w unlimited; Any tips from admins who have successfully imposed memory constraints in 8.x? ___ 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: imposing memory limits in FreeBSD 8
On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer joes...@gmail.com wrote: While I am thrilled about the newfound zfs stability that upgrading to 8 has brought, one of the things that seems to have been dropped is support for process memory limits. I have a few servers that occasionally run out of swap due to runaway httpd daemons, and the ulimit -m settings in the startup scripts we use stopped working upon upgrading from FreeBSD 6. I've tried fiddling with the daemon class in login.conf to no avail either. About the only thing I haven't tried is running httpd under djb's softlimit executable. Here's my daemon class in login.conf: daemon:\ :memoryuse=1g:\ :datasize=1g:\ :stacksize=1g:\ :tc=default: and proof that `limits` groks the config: # limits -eHC daemon ulimit -t unlimited; ulimit -f unlimited; ulimit -d 1048576; ulimit -s 1048576; ulimit -c unlimited; ulimit -m 1048576; ulimit -l unlimited; ulimit -u unlimited; ulimit -n unlimited; ulimit -b unlimited; ulimit -v unlimited; ulimit -p unlimited; ulimit -w unlimited; Any tips from admins who have successfully imposed memory constraints in 8.x? If I recall it correctly, in -8 malloc defaults to mmap for memory allocations, so RLIMIT_DATA no longer applies. You have to set RLIMIT_VMEM, but be careful as that would include everything mmapped in even if it does not use much of that. rpc.statd is one example of that -- it mmaps in ~256M but has only ~400K resident set size. Another option would be to make malloc() switch back to sbrk() with MALLOC_OPTIONS=D. This way datasize limit will still be in effect. --Artem ___ 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: imposing memory limits in FreeBSD 8
On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich a...@freebsd.org wrote: On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer joes...@gmail.com wrote: While I am thrilled about the newfound zfs stability that upgrading to 8 has brought, one of the things that seems to have been dropped is support for process memory limits. I have a few servers that occasionally run out of swap due to runaway httpd daemons, and the ulimit -m settings in the startup scripts we use stopped working upon upgrading from FreeBSD 6. I've tried fiddling with the daemon class in login.conf to no avail either. About the only thing I haven't tried is running httpd under djb's softlimit executable. Here's my daemon class in login.conf: daemon:\ :memoryuse=1g:\ :datasize=1g:\ :stacksize=1g:\ :tc=default: and proof that `limits` groks the config: # limits -eHC daemon ulimit -t unlimited; ulimit -f unlimited; ulimit -d 1048576; ulimit -s 1048576; ulimit -c unlimited; ulimit -m 1048576; ulimit -l unlimited; ulimit -u unlimited; ulimit -n unlimited; ulimit -b unlimited; ulimit -v unlimited; ulimit -p unlimited; ulimit -w unlimited; Any tips from admins who have successfully imposed memory constraints in 8.x? If I recall it correctly, in -8 malloc defaults to mmap for memory allocations, so RLIMIT_DATA no longer applies. You have to set RLIMIT_VMEM, but be careful as that would include everything mmapped in even if it does not use much of that. rpc.statd is one example of that -- it mmaps in ~256M but has only ~400K resident set size. Another option would be to make malloc() switch back to sbrk() with MALLOC_OPTIONS=D. This way datasize limit will still be in effect. Thanks for the tip. My concern is with runaway processes that are pushing the server into swap, so it's pretty easy to pick them out based on what top reports for their SIZE. I'll try the vmem limit and let you know how that works out. ___ 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: imposing memory limits in FreeBSD 8
On Sat, Apr 9, 2011 at 3:17 PM, Joe Schaefer joes...@gmail.com wrote: On Sat, Apr 9, 2011 at 3:06 PM, Artem Belevich a...@freebsd.org wrote: On Sat, Apr 9, 2011 at 10:15 AM, Joe Schaefer joes...@gmail.com wrote: While I am thrilled about the newfound zfs stability that upgrading to 8 has brought, one of the things that seems to have been dropped is support for process memory limits. I have a few servers that occasionally run out of swap due to runaway httpd daemons, and the ulimit -m settings in the startup scripts we use stopped working upon upgrading from FreeBSD 6. I've tried fiddling with the daemon class in login.conf to no avail either. About the only thing I haven't tried is running httpd under djb's softlimit executable. Here's my daemon class in login.conf: daemon:\ :memoryuse=1g:\ :datasize=1g:\ :stacksize=1g:\ :tc=default: and proof that `limits` groks the config: # limits -eHC daemon ulimit -t unlimited; ulimit -f unlimited; ulimit -d 1048576; ulimit -s 1048576; ulimit -c unlimited; ulimit -m 1048576; ulimit -l unlimited; ulimit -u unlimited; ulimit -n unlimited; ulimit -b unlimited; ulimit -v unlimited; ulimit -p unlimited; ulimit -w unlimited; Any tips from admins who have successfully imposed memory constraints in 8.x? If I recall it correctly, in -8 malloc defaults to mmap for memory allocations, so RLIMIT_DATA no longer applies. You have to set RLIMIT_VMEM, but be careful as that would include everything mmapped in even if it does not use much of that. rpc.statd is one example of that -- it mmaps in ~256M but has only ~400K resident set size. Another option would be to make malloc() switch back to sbrk() with MALLOC_OPTIONS=D. This way datasize limit will still be in effect. Thanks for the tip. My concern is with runaway processes that are pushing the server into swap, so it's pretty easy to pick them out based on what top reports for their SIZE. I'll try the vmem limit and let you know how that works out. Sweet- if the expected behavior is to send the process a SIGABORT when it hits the limit, it's working perfectly. ___ 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
*printf(9) and PRINTF_BUFR_SIZE
While working on other problems with *printf(9), log(9), etc. I stumbled upon: options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed to prevent this: ada2: 300.000MB/s transfuhub2: 3 ports with 3 removable, self powered ers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled Question 2: Why is vprintf() the only function that does this buffering? As far as I can tell, the various functions that call kvprintf() directly without going through vprintf() do not get buffered. I'm thinking that kvprintf() would be a better place for the buffering. Or would this break something? ___ 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: Fwd: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011
For my short post [to everyone], I'll top post. I am/have-been trying to write a user-side audio, key-click driver for every Open OS--essentially the BSD distros and the Linux. I am looking for people interested and who know both python and C/C++. -g On Sat, Apr 09, 2011 at 09:43:54AM +0200, Daniel Gerzo wrote: Hello, I would like to remind you that the submission due date (April 15th) is approaching quickly and to this date I have received _only_ 3 submissions. Please try to find a few minutes and submit your reports so that we can inform our community about the progress made in the first quarter of 2011. Thanks! Original Message Subject: HEADSUP: Call for FreeBSD Status Reports - 1Q/2011 Date: Mon, 21 Mar 2011 18:19:23 +0100 From: Daniel Gerzo dan...@freebsd.org Organization: The FreeBSD Project To: curr...@freebsd.org, hack...@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the first quarter of 2011 is due on April 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo ___ 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 -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org ___ 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: *printf(9) and PRINTF_BUFR_SIZE
On Sat Apr 9 11, dieter...@engineer.com wrote: While working on other problems with *printf(9), log(9), etc. I stumbled upon: options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed to prevent this: ada2: 300.000MB/s transfuhub2: 3 ports with 3 removable, self powered ers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled Question 2: Why is vprintf() the only function that does this buffering? As far as I can tell, the various functions that call kvprintf() directly without going through vprintf() do not get buffered. I'm thinking that kvprintf() would be a better place for the buffering. Or would this break something? i remember this issue was discussed a few times before. you might want to take a look at [1]. cheers. alex [1] http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPhcc8Z_BdvoEQUv-ZXlHAYOTQJwlUQDVO8iJ9 -- a13x ___ 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: Kernel Tracking Question.. regarding kernel and boot files
On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swiger cswi...@mac.com wrote: Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. Is ktrace the best trace suite for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. What about if I wanna see the interaction between boot process and kernel loading. What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Yeah. this file provides me with the stages in theoretical way. How about implementing it using qemu to emulate livecd to see what is going on boot0. Do you have an idea about that ? Good Luck, Regards, -- -Chuck ___ 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: Kernel Tracking Question.. regarding kernel and boot files
Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. Is ktrace the best trace suite for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Regards, -- -Chuck ___ 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: ifconfig output: ipv4 netmask format
On Sat, Apr 09, 2011 at 12:41:05PM -0400, dieter...@engineer.com wrote: Paul Schenkeveld writes: Although non-contiguous netmasks are not legal anymore in IPv4, our ifconfig still allows to do something like: # ifconfig em0 inet 10.0.5.2 netmask 255.0.255.0 # ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_M AGIC ether xx:xx:xx:xx:xx:xx inet 10.0.5.2 netmask 0xff00ff00 broadcast 10.255.5.255 media: Ethernet autoselect (1000baseT full-duplex) status: active If this is no longer legal, should ifconfig issue a warning? J. Hellenthal writes: This is the year 2011 right ? when are we going to support new users rather than supporting old outdated washed up scripts ? Change for the sake of change is not progress. Perhaps when you get more experience you will understand the joy of spending massive amounts of time attempting to deal with gratuitious changes. Perhaps making blind assumptions and shouting from an advertisement domain about experience of others might cause some assumptions to be made, but I won't go there with my thoughts of that. Bold moves that aid the user deciphering what they see correctly spurs further community involvement rather than driving them away. Given this is a small change and one that would only play a small role in a similar light, there are much greater issues that surround this and all of them play a part in the final result, not just the bigger ones. I know where to find those. Anyway... Thanks for broadening the Service Window with your ``experience'' -- J. Hellenthal pgpmKXvkcqiP3.pgp Description: PGP signature
Re: *printf(9) and PRINTF_BUFR_SIZE
While working on other problems with *printf(9), log(9), etc. I stumbled upon: options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. Question 1: Am I correct in thinking that PRINTF_BUFR_SIZE is supposed to prevent this: ada2: 300.000MB/s transfuhub2: 3 ports with 3 removable, self powered ers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled Question 2: Why is vprintf() the only function that does this buffering? As far as I can tell, the various functions that call kvprintf() directly without going through vprintf() do not get buffered. I'm thinking that kvprintf() would be a better place for the buffering. Or would this break something? http://docs.freebsd.org/cgi/mid.cgi?AANLkTinPhcc8Z_BdvoEQUv-ZXlHAYOTQJwlUQDVO\ 8iJ9 Thanks, Alex! That was a useful thread, I now know more about the problem and how to fix it. I gather the answer to Q1 is yes. Given that the word transfers is broken, I still think this example is most likely due to my changes that use unbuffered kvprintf() rather than buffered vprintf(). So question 2 remains. BTW, I see some threads where people think this is due to SMP. It happens on uniprocessor machines too. ___ 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: Kernel Tracking Question.. regarding kernel and boot files
On 4/9/11 2:51 PM, Chris Richardson wrote: On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swigercswi...@mac.com wrote: Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. Is ktrace the best trace suite for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. What about if I wanna see the interaction between boot process and kernel loading. either you run it under an emulator that allows you to single step it. or you just add a lot of printf() to the boot loader. (some parts are required to fit in small code sizes to adding prints will cause overflow..) best to read the docs and then the sources. then it wil become apparent to you what you want to find out. What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Yeah. this file provides me with the stages in theoretical way. How about implementing it using qemu to emulate livecd to see what is going on boot0. Do you have an idea about that ? Good Luck, Regards, -- -Chuck ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: Kernel Tracking Question.. regarding kernel and boot files
Chuck Swiger cswi...@mac.com wrote: ... Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor ... Eclipse is, or at least can be configured to be, much more than an editor. In my experience it is an integrated development environment incorporating various debugging displays and controls. The OP is presumably referring to a plugin that integrates Qemu into the Eclipse environment. ___ 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
