Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits 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
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Replacing rc(8) has a lot of risks and not many benefits. Current system if you make single-use system (for eg. X11 terminal) just delete most of files from /etc including /etc/rc and write your own - the simplest possibe, just put command to run all needed things. that's all. ___ 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: TeXLive merge into FreeBSD ports tree - FreeBSD project idea
Hi all, Summary of below. I have started an effort to get TeXLive into the FreeBSD ports. See github.com/DragonSA/texlive for details. Volunteers welcome. On Sunday, 17 June 2012 22:04:15 David Schultz wrote: On Sun, Jun 17, 2012, Jan Henrik Sylvester wrote: Even with a knob instead of checking if print/texlive-core is installed, it would put a lot of mess into the ports tree. Some maintainers will not agree to introduce these conditions, if there is no general agreement that we want to transition to TeXLive that way. teTeX hasn't been updated since 2006 and the maintainer of teTeX has discontinued development and recommends using TeXLive. Undoubtably updating the TeXLive will break some things but the same could be said about teTeX if an update existed. Are there any people who don't want to migrate to TeXLive? As far as I remember, both romain@ and hrs@ have stated that they do not want both teTeX and TeXLive in the tree concurrently. Looking through the list of bundled packages for TeXLive it will be quite difficult to have both TeXLive and teTeX in the tree concurrently. There are a group of support ports, such as xdvik and ptex that require special integration into either teTeX or TeXLive. To switch between either will require reinstalling many dependencies, not just the TeXLive or teTeX ports. With that said, it is not impossible nor, I think, will it impose a big maintenance burden. In that case, it sounds like using TeXLive in FreeBSD will be a bit tricky until someone steps in and does all the work required for integration. Unfortunately I'm a bit time-constrained for the next few months, but I do use TeXLive and would be happy to test any proposed patches. I have started working on just this, getting TeXLive into FreeBSD ports. It is still early days and I have only two monolithic ports, with texlive-base requiring lots of love. I believe my work is in a state ready for initial testing (verifying the ports) and some feedback. Some open questions are: - how to split texlive-texmf (OpenBSD has an approach) - how to handle bundled software that has existing (sometimes outdated) ports Also, I am looking for a sponsor: someone who will commit the ports when they are ready, and to provide feedback so that the ports may get to a ready state. For details about the project, and to get the ports, please see: github.com/DragonSA/texlive Regards P.S. I am not subscribed to freebsd-ports@ so please CC me. signature.asc Description: This is a digitally signed message part.
Re: how to turn my computer into a TV
a lot of CPU or hardware compression. Decoding either takes a lot of CPU (or hardware decoding which AFAIK FreeBSD doesn't have). You can use watching SDTV movie takes very little part of one core of any modern CPU including intel atom. encoding SDTV will take more but still not much. watching HDTV should work on almost ANY modern PC CPU, including dual core/quad thread atom D525+included graphics, but with no other load as it will be close to saturating all cores/threads. most people vastly underestimate power of modern CPUs. ___ 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: proper newfs options for SSD disk
OK, but I wanted to have most of the space of the 4 GB SSD encrypted with geli(8); so I should make there some slice containing /boot (unencrypted) and a second slice which later will contain my HOME and encrypted; wrong? right. but do not forget bootloader requires things to be in /boot directory on boot partition so do it that way 20MB /b partition (a) rest - geli encrypted / partition (d) on / partition make link /boot - /b/boot put /boot things in /b/boot well done custom kernel should fit in 10MB /b partition including boot loader. and you can gzip /boot/kernel/kernel ___ 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: how to turn my computer into a TV
On Sun, Jun 17, 2012 at 6:31 PM, Dieter BSD dieter...@engineer.com wrote:
[ Added multimedia@ as that is a more appropriate list than hackers ]
I just moved into a very cramped apartment
we are using a broadcast signal only [current US {NYC} standards]
Recording ATSC takes very little CPU. Recording NTSC takes either
a lot of CPU or hardware compression. Decoding either takes a lot of CPU
(or hardware decoding which AFAIK FreeBSD doesn't have). You can use
at(1) for automated recordings. A full ATSC channel is 19.3 Mbps.
Some tuners allow filtering by PID, which saves disk space.
Recording doesn't require any compression unless you are transcoding
in real-time. There's no difference between recording ATSC, NTSC, PAL,
etc, and it's actually irrelevant what the stream is. The broadcast
streams are digital so when you record them, you are actually just
saving the stream to some type of media (usually a harddrive). It's
like saving a file where the file contents is audio/video, and it
takes however long your show/timer/etc is. The only impact on the cpu
is the same impact you have when you save any big file -- very little
on any modern cpu.
Lastly, it's possible to save a single channel or the entire stream
which usually contains several channels. Even when saving the full
stream, it likely uses far less bandwidth than your media offers so
there's no problem there.
___
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: Replacing rc(8) (Was: FreeBSD Boot Times)
On 18/06/2012 09:11, Atte Peltomäki wrote: On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. There was even some work done to get it working for FreeBSD if anyone feels like taking it up again. http://wiki.freebsd.org/launchd ___ 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: how to turn my computer into a TV
user.vdr writes: Recording doesn't require any compression unless you are transcoding in real-time. There's no difference between recording ATSC, NTSC, PAL, etc, and it's actually irrelevant what the stream is. This is incorrect. ATSC is compressed before broadcast, so you receive the data already compresed. NTSC and PAL are broadcast in analog. The tuner performs A-to-D which gives an uncompressed data stream. Have fun trying to store that. As a practical matter, you have to compress the data in real time. Some, not all, tuners include hardware compression. Lastly, it's possible to save a single channel or the entire stream which usually contains several channels. Even when saving the full stream, it likely uses far less bandwidth than your media offers so there's no problem there. This appariently refers to ATSC. Yes, modern disks have plenty of bandwidth to store the entire ATSC stream. The main reason to filter PIDs is to save disk *space*. Also, some software can't select which program to decode. Wojciech writes: most people vastly underestimate power of modern CPUs. Many people overestimate the moderness of most people's CPUs. ___ 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: EFI development tools
This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. People build 32 bit binaries on 64 bit systems all the time. It is called cross-compiling. I rather doubt that just setting the -m32 flag is sufficient to set up a proper cross-compiling 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
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/18/2012 01:12 PM, Vincent Hoffman wrote: On 18/06/2012 09:11, Atte Peltomäki wrote: On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. There was even some work done to get it working for FreeBSD if anyone feels like taking it up again. http://wiki.freebsd.org/launchd Would someone elaborate on what launchd and SMF do well in comparison to OpenRC (or FreeBSD's init)? Gentoo does active OpenRC development. If there is anything that it could do better, please do not hesitate to let us know so that improvements can be made. Would licensing be a problem for either SMF or launchd? I know that CDDL code is not allowed in GENERIC kernels, so I would be surprised if SMF would be acceptable for FreeBSD's init system. I am not sure what the situation is for Apache 2.0 licensed code, but I would think that FreeBSD would code that is available under the 2-clause BSD license. With that said, the Gentoo developers already have OpenRC working on FreeBSD and OpenRC is available under the 2-clause BSD license, so it should have a compatible license. ___ 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
/proc filesystem
where can i find description of field of files /proc/*/map ? ___ 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: EFI development tools
On 06/17/12 19:43, Mike Meyer wrote: Eric McCorklee...@shadowsun.net wrote: The -m32 flag seems to be the culprit; removing it fixes the problem. This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE were wrong. In any case, this is a pretty serious error, and someone should try to reproduce it and take a look at it. This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. Doesn't look like anyone has opened a PR for it. This isn't as complicated as you make it seem. buildworld already does it to build the things in lib32 and on some platforms (mips and powerpc) the headers are the same for both 32- and 64-bit systems and so -m32 works perfectly already. All that is needed on x86 is some further header unification, which seems to be in progress. Moreover, if you are building standalone binaries (which the EFI stuff probably is) it should just work now, since standalone code doesn't depend on system headers. -Nathan ___ 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: how to turn my computer into a TV
On Mon, Jun 18, 2012 at 10:21 AM, Dieter BSD dieter...@engineer.com wrote: user.vdr writes: Recording doesn't require any compression unless you are transcoding in real-time. There's no difference between recording ATSC, NTSC, PAL, etc, and it's actually irrelevant what the stream is. This is incorrect. ATSC is compressed before broadcast, so you receive the data already compresed. NTSC and PAL are broadcast in analog. The tuner performs A-to-D which gives an uncompressed data stream. Have fun trying to store that. As a practical matter, you have to compress the data in real time. Some, not all, tuners include hardware compression. All consumer digital broadcasts are compressed typically with mpeg2 or mpeg4. With very very very few exceptions, all analog NTSC broadcasts have been switched to digital, by the FCC mandated deadline of June 12, 2009. Tuners perform demodulation, not decompression. There are a few premium or full-featured devices which have an on-board decoder such as a Hauppauge Nexus-s or the TechnoTrend S2-6400. You absolutely do NOT have to reencode a stream unless you want to alter the resolution, bitrate, or compression method. Tuners do NOT provide raw audio/video to the system in any case. Lastly, it's possible to save a single channel or the entire stream which usually contains several channels. Even when saving the full stream, it likely uses far less bandwidth than your media offers so there's no problem there. This appariently refers to ATSC. Yes, modern disks have plenty of bandwidth to store the entire ATSC stream. The main reason to filter PIDs is to save disk *space*. Also, some software can't select which program to decode. It refers to ANY multiplex. Again, the standard used for broadcast is irrelevant. Also, any program that can tune a channel has the ability to filter the pids, otherwise it would be impossible to tune a channel. Wojciech writes: most people vastly underestimate power of modern CPUs. Many people overestimate the moderness of most people's CPUs. An old Pentium 4 3ghz can decode HD with plenty of cpu resources to spare so unless a person using something older than that, they've certainly got modern cpu power. ___ 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
Fast syscalls via sysenter
Hi! I am trying to continue the work started by DavidXu on implemention of fast syscalls via sysenter/sysexit. http://people.freebsd.org/~davidxu/sysenter/kernel/ I have ported it on FreeBSD9. It looks like it works. Unfortunately I am a beginner in kernel so I have some questions: 1. see http://people.freebsd.org/~davidxu/sysenter/kernel/kernel.patch /* * If %edx was changed, we can not use sysexit, because it * needs %edx to restore userland %eip. */ if (orig_edx != frame.tf_edx) td-td_pcb-pcb_flags |= PCB_FULLCTX; What is the reason why we have to do this additional check? In http://people.freebsd.org/~davidxu/sysenter/kernel/sysenter.s we store %edx to the stack in pushl %edx /* ring 3 next %eip */ and we restore the register in popl%edx/* ring 3 %eip */ 2. see http://people.freebsd.org/~davidxu/sysenter/kernel/sysenter.s movlPCPU(CURPCB),%esi callsyscall Why do we movl PCPU(CURPCB),%esi before calling syscall? syscall is just c- function. -- Daniil Cherednik ___ 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: /proc filesystem
On 6/18/12 10:31 PM, Wojciech Puchar wrote: where can i find description of field of files /proc/*/map ? Use procstat -v instead. All fields are documented in procstat(1). -- Andrey Zonov ___ 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: EFI development tools
On Mon, 18 Jun 2012 13:42:27 -0500 Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 06/17/12 19:43, Mike Meyer wrote: Eric McCorklee...@shadowsun.net wrote: The -m32 flag seems to be the culprit; removing it fixes the problem. This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE were wrong. In any case, this is a pretty serious error, and someone should try to reproduce it and take a look at it. This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. Doesn't look like anyone has opened a PR for it. This isn't as complicated as you make it seem. buildworld already does it to build the things in lib32 and on some platforms (mips and powerpc) the headers are the same for both 32- and 64-bit systems and so -m32 works perfectly already. All that is needed on x86 is some further header unification, which seems to be in progress. It isn't as simple as you make it seem, either. buildworld has been cross-compiling for years now. But buildworld builds against system headers/libraries/etc other than those installed on the system, so making it use the appropriate ones for a cross-compile is a straightforward modification. Changing a build process that expect to build against the headers/libraries/etc installed on the system is a lot more work. The header unification has been in progress for years. We still don't have general-purpose cross-compiling working - at least not for FreeBSD targets. I admit that I haven't been following the issue, as my need for it vanished with my last 32-bit system (years ago), so it may be possible with the right set of ports installed, as it is for non-FreeBSD targets. Moreover, if you are building standalone binaries (which the EFI stuff probably is) it should just work now, since standalone code doesn't depend on system headers. Except the headers they do depend on (like ctype.h) depend on system headers. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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: Replacing rc(8) (Was: FreeBSD Boot Times)
It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
As the original poster of this thread, I can also say that Doug is correct. The issue is not rc, it is the actual kernel boot process. Maybe I could see rc becoming an issue in a massive server environment where there are a lot of userland processes to start, but that delay would most likely be in the programs themselves and not rc (I think of rc as more of a dispatcher). When it comes to a desktop/laptop/simple server and all you do with rc is configure a static IP, start dbus/hal/sshd, and maybe launch a few jails... at least 90-98% of the boot process is spent doing the kernel work. -Brandon On 6/18/2012 6:53 PM, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug ___ 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 ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/18/2012 06:53 PM, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Here are instructions: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail Is there anything else that you need? ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. indeed. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. most of boot time consist of - delay in bootloader. setting autoboot_delay can partially delay it, delay to zero can be achieved by patching first stage booter that too add delay - delay in kernel initialization. making custom kernel helps of course but still it takes eg 10 seconds on my laptop. putting things that are not needed instantly at boot - as module - may help. USB being prime example. - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. ___ 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: /proc filesystem
that is what i need. but still need some explanation after using it and reading manual say: PID STARTEND PRT RES PRES REF SHD FL TP PATH 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn /usr/local/bin/Xorg 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn /usr/local/bin/Xorg 1378 0x7bc000 0x80 rw- 140 1 0 C-- df 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn /libexec/ld-elf.so.1 13780x8007c30000x8007f rw- 430 1 0 C-- df 13780x8007f0x8007f2000 rw-10 4 0 --- dv 13780x8007f20000x8007f4000 rw-20 4 0 --- dv 13780x8007f40000x800874000 rw- 110 4 0 --- dv 13780x8008740000x800884000 rw- 160 4 0 --- dv 13780x8008840000x800895000 rw- 100 1 0 CN- df 13780x8009c20000x8009c5000 rw-30 1 0 C-- df 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But what REF really means here and why it is 2 once and 1 second. 2) what really PRES (private resident) means? df (default) mappings are IMHO anonymous maps==private data of process. so why RES is nonzero while PRES is zero, while on shared code PRES is nonzero and large. what does it really means? thanks. On Tue, 19 Jun 2012, Andrey Zonov wrote: On 6/18/12 10:31 PM, Wojciech Puchar wrote: where can i find description of field of files /proc/*/map ? Use procstat -v instead. All fields are documented in procstat(1). -- Andrey Zonov ___ 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 ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 6:39 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. indeed. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. most of boot time consist of - delay in bootloader. setting autoboot_delay can partially delay it, delay to zero can be achieved by patching first stage booter that too add delay - delay in kernel initialization. making custom kernel helps of course but still it takes eg 10 seconds on my laptop. putting things that are not needed instantly at boot - as module - may help. USB being prime example. - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. Please, re-read already sent mails in this thread about that statement so we don't get stuck in a loop. ___ 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 ___ 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
