Re: Replacing rc(8) (Was: FreeBSD Boot Times)
All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. ... and to be able to switch between two configurations at runtime, without taking down services listed active in both configurations preferably. i already proposed how to make this easily with single rc.conf only. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other true. can be actually added easily. - monitor running services and restart them if they crash should not be done, or at least not default. Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file it's a requirement not just adventage :) Yes. I don't even think it *needs* improving, but "service profiles" including "network profiles" would be really nice and worth looking into. If we can get that without loosing the simple text-file-based configuration, the better. we can. but from what i've seen about openrc it is overly complicated. For sure better that other things used in linux distros but still not tolerable. why replace something very good? ___ 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)
Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) "runlevels" with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable="YES" service2_enable="NO" service3_enable="foolevel maintenance" service4_enable="YES -foolevel" (or ALL -funkyrunlevel) name of default runlevel may be "full" or "multiuser" service 1 will always work, service 2 never, service 3 only at runlevels "foolevel" and "maintenance", service4 with any runlevel except "foolevel". still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. ___ 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)
ifconfig_em0="inet ..." ( default (or unknown) runlevel ) ifconfig_em0_foolevel="inet ..." ( foolevel runlevel ) ifconfig_em0_maintenance="inet ..." ( maintanence runlevel ) too ? well - possible BUT... but well. this will not require only changing "launcher" script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script. Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present. i will think about it, not doing it but allowing to easy make it then. ___ 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)
Am 21.06.2012, 12:22 Uhr, schrieb Wojciech Puchar : Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) "runlevels" with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable="YES" service2_enable="NO" service3_enable="foolevel maintenance" service4_enable="YES -foolevel" (or ALL -funkyrunlevel) name of default runlevel may be "full" or "multiuser" service 1 will always work, service 2 never, service 3 only at runlevels "foolevel" and "maintenance", service4 with any runlevel except "foolevel". still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Nicely thought. Count me in for testing. Do you think it would be possible to have something along the lines of ifconfig_em0="inet ..." ( default (or unknown) runlevel ) ifconfig_em0_foolevel="inet ..." ( foolevel runlevel ) ifconfig_em0_maintenance="inet ..." ( maintanence runlevel ) too ? Michael ___ 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)
Am 21.06.2012, 12:56 Uhr, schrieb Wojciech Puchar : ifconfig_em0="inet ..." ( default (or unknown) runlevel ) ifconfig_em0_foolevel="inet ..." ( foolevel runlevel ) ifconfig_em0_maintenance="inet ..." ( maintanence runlevel ) too ? well - possible BUT... but well. this will not require only changing "launcher" script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script. Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present. I thought that network would be more complicated. My use case: I maintain a business application consisting of - FreeBSD - several ports - my software and I run this system: a) for development, in a VM on my laptop on my local network; b) for demonstration and customer guided planning, in a VM on my laptop on the customers network, c) for production, on a machine on the customers network, d) for production, in a VM on the laptops of the customers team. The software is the same for all 4, but they differ in services started and in network settings. Having "service profiles" and "network profiles" would allow me to have a convenient method of delegating the whole setup to the application: System boots, no services default network, application starts, detects machine role (devel, demo, server, portable), configures the network and starts the appropriate services. As in: I have a configuration file for the application anyway. This configuration file contains the machine role (devel, demo ...) anyway. If I could send this role as a parameter to "rc mode " and network and services would be configured accordingly, I could have an identical rc.conf over all roles, and I'd consider that a big plus. Michael ___ 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 Jun 20, 2012 11:03 PM, "Wojciech Puchar" wrote: >>> >>> scripts, i deleted most of it and put startup sequence in single file. >>> >>> It was plain horror. >> >> >> You would weep if you saw Solaris's SMF, then. Everything is > > > i don't really know what i've seen. i've installed latest solaris demo downloaded from oracle. After nearly an hour of installation over which i had really no control and no real clue what's going on i finally after over 5 minutes got the system booted, logged as root and tried to understand the /etc tree, boot process and gave up really quickly. > just seeing a files and directories (both numerous) of just a kernel binaries was truly enough. > > Now... lets go back to FreeBSD which is controllable and understandable by a human. Your arrogance is astounding. Did you read man hier? Unfamiliarity does not make it incomprehensible. 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: EFI development tools
On Monday, June 18, 2012 4:46:32 pm Mike Meyer wrote: > On Mon, 18 Jun 2012 13:42:27 -0500 > Nathan Whitehorn wrote: > > > On 06/17/12 19:43, Mike Meyer wrote: > > > Eric McCorkle 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. Note that all the current boot bits on amd64 use -m32 and work fine. I think this is not nearly as complicated as you are making it out to be. > The header unification has been "in progress" for years. Actually, jilles@ has only been working on that for x86 in the last year or so. -- John Baldwin ___ 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: Fast syscalls via sysenter
On Monday, June 18, 2012 2:56:30 pm Daniil Cherednik wrote: > 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 */ Some system calls return two return values (pipe(2)) or return a 64-bit off_t (lseek(2)). Those system calls change %edx's value and need that changed value to make it out to userland. > 2. see http://people.freebsd.org/~davidxu/sysenter/kernel/sysenter.s > movl PCPU(CURPCB),%esi > call syscall > > Why do we movl PCPU(CURPCB),%esi before calling syscall? syscall is just c- > function. No clue on this one, looks like it is not needed. -- John Baldwin ___ 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: newbus / snd_hdspe(4) trouble
On Wednesday, June 20, 2012 4:44:41 pm Ruslan Bukin wrote: > Hi. > > I have the problem with different behavior of snd_hdspe(4) sound card > driver initialization. > > If I load the driver by hand using kldload everything works fine, > but in case of loading driver at boot time (loader.conf) or compile > in kernel the driver can't initialize propertly. > > The snd_hdspe(4) driver is designed to create a pcm child device per > each pair of sound channels. > > The problem is that snd_hdspe loaded normally, but pcm child devices > are not appears. hdspe_pcm_probe() in driver is not called at all. > However snd_hdspe_pcm driver exists in kldstat -v after boot: > 51 0x81377000 a2c8 snd_hdspe.ko (/boot/kernel/snd_hdspe.ko) > Contains modules: > Id Name > 7 hdspe/snd_hdspe_pcm >6 pci/snd_hdspe > > and I have checked, device_add_child() returns not NULL. > > I played with MODULE_DEPEND as done in snd_hda(4) but no luck. > What can I do to debug the problem? The snd_hdspe driver probably needs to use DRIVER_MODULE_ORDERED() to ensure the other modules in its kld are registered with new-bus before it tries to attach to devices. -- John Baldwin ___ 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 2012-Jun-18 19:18:57 -0400, Brandon Falk wrote:
>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.
I've videoed my netbook rebooting and gone through the video in slow
motion and that definitely doesn't match what I see.
>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.
In my case, starting from when the screen blanks after a reboot, the
breakdown is:
7.4s - POST + BIOS splash (including ~1s waiting for input)
4.4s - boot0/1/2, starting loader (including boot spinners)
1.5s - loading kernel
11.0s - loader countdown
7.0s - kernel startup
32.0s - rc scripts ("mounting root" through VTY login prompt)
5.0s - X + xdm startup
Note that the majority of kernel probe time is:
2000ms - atkbd
750ms - ata
500ms - memory probe
500ms - ath0
450ms - psm0
So, in my case, rc scripts account for just under 50% of the total
boot time and 50% of the remainder are various "waiting for input"
timeouts. The kernel amounts for 10% of the total time and 50% of
that is 4 devices. I intend to work through the rc process in more
detail to see where I can reduce the elapsed time.
--
Peter Jeremy
pgpfk36pZhHvM.pgp
Description: PGP signature
libmagic issue
Hi all, I m using libmagic for my application on FreeBSD. I have some problems. libmagic doenst return properly mimetype of file. For example : system is FreeBSD 8.2-RELEASE . file --mime-type example.7z > application/octet-stream file example.7z > 7-zip archive data, version 0.3 and when i try to test same file on linux (ubuntu 12.04) : file --mime-type example.7z > application/x-7z-compressed file example.7z > 7-zip archive data, version 0.3 why does not FreeBSD behave like linux and if i need to update magic.mgc , how can i do that ? i need the result application/x-7z-compressed after i type as command file --mime-type example.7z.. Any help would be appreciated. Thanks ... I.Yasar ___ 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: libmagic issue
file --mime-type example.7z > application/x-7z-compressed file example.7z > 7-zip archive data, version 0.3 why does not FreeBSD behave like linux you answered it yourself just below. and if i need to update magic.mgc , how can i do that ? i need the edit/update /usr/share/misc/magic and use file -C to rebuild magic.mgc file. then post your added/fixed/updated entries using send-pr tool so it will be included.___ 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: MAGIC with HP KVM - someone will help?
no ideas? On Wed, 20 Jun 2012, Wojciech Puchar wrote: i am not sure if it is related at all to FreeBSD, but maybe someone here know the solution. Anyway it is somewhat FreeBSD related for sure as you will see from description. I bought used IP 16 port KVM connected to few servers, in between them FreeBSD 8 server running on Dell PowerEdge T110. As this KVM have PS/2 connectors to keyboard and mouse i added USB to dual-PS/2 converter. So: 1)when KVM is used locally with plugged monitor, keyboard and mouse everything is fine. 2)when it is used remotely before FreeBSD is booted or after successful multiuser boot everything is fine. 3)when kernel boots and waits for GELI password, and i SLOOOWLY type it (at most one keypress per second) over remote KVM connection - everything is fine. 4)when i type the password faster keyboard locks. you have to turn off server and on again to recover. Please don't laught from 3 and 4 as it is true, tested several times. The problem happens ONLY at FreeBSD but before mounting root, when geli ask for password. And it is serious as ability to enter geli password is the main reason for this KVM to be installed! And really not forgetting to type password very slowly isn't easy. Any idea what it is and how to fix it. It really looks like magic. ___ 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 Thu, 21 Jun 2012 17:10:06 +0200 Daniel Gerzo wrote: > Hello, > > > Just picking a random message related to this issue. Maybe Tom might > update us a bit with the status of his project ;-) Oh, put me on the spot, thanks Daniel! :) > > Citát Wojciech Puchar : > >>> - monitor running services and restart them if they crash > > > > should not be done, or at least not default. > > http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) > http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control > So, I'm not following the -hackers list (too much email, too little personal time); however, I did take a few moments to familarize myself with the conversation. First off, my project was an attempt to pull what I liked from SMF without some of the annoying parts. I hadn't found it overly complicated, but very SYSV like (for very obvious reasons). At point, I wondered how interesting it would be to replace rc or augment it in some way that we could have several of the very interesting ideas that are floating around out there. Like parallel start up, control of base and ports rc, control of inetd and xinet services, and a quick way to get their status. But it was a passing interest that, without some additional hands, will never turn into a real project. Though, my services control stuff is in the ports collection now (see sysutils/fsc) but that is a post-startup mechanism. Sorry I don't really have more to contribute right now, thanks, -- Tom Rhodes ___ 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)
Hello, Just picking a random message related to this issue. Maybe Tom might update us a bit with the status of his project ;-) Citát Wojciech Puchar : - monitor running services and restart them if they crash should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control -- S pozdravom / Best 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: > Lets make a summary. > > What functionality would be good to have in FreeBSD that doesn't exist: > > 1) "runlevels" with arbitrary names. runlevel change would start and stop > right services. > 2) exploit startup parallelism. > > > What we do not want to change: > > - file structure which is simple. one file in rc.d/ per service and one > global config file (rc.conf) > - anything else that would make things more complicated. > > > As for > > 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel > list for each service or runlevel exclusion list for service. > > > examples: > > service1_enable="YES" > service2_enable="NO" > service3_enable="foolevel maintenance" > service4_enable="YES -foolevel" (or ALL -funkyrunlevel) > > name of default runlevel may be "full" or "multiuser" > > service 1 will always work, service 2 never, service 3 only at runlevels > "foolevel" and "maintenance", service4 with any runlevel except > "foolevel". > > still single rc.conf, not much bigger in practice. > > 2) no change in rc.d/* scripts and rc.conf, but change in scripts. > > > If everyone agree i think i may write this new scripts. Sorry but I completely disagree here. Why ? Because do one thing and do one thing well. What do you mean ? service_enable="YES" - enables the service ... IT IS NOT TO ALSO ADD MORE CRAP TO. Try something like the following... service_runlevels="1 2 3 4 5" And provide a way to say... allservice_runlevels="3 4 5" which would basically state that every service runs under runlevel 3,4,5 unless specifically stated. Lets not bastardize this overly simple process by modifying already existing variables. Add a framework to coexist and teach rc to respect and comply with it. current rc scripts would not have to be modified if done correctly as well. You can short circuit the _enable= vars early on by just inspecting its _runlevel= var... Same thing could be had for a service profile script. nothing in etc/rc.d/ would have to be modified. -- - (2^(N-1)) pgpAPKdQ8kFpq.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Try something like the following... service_runlevels="1 2 3 4 5" And provide a way to say... Well - i agree with you. just invent a syntax to define service runlevels as "all except ...". ___ 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 Jun 21, 2012 5:15 PM, "Jason Hellenthal" wrote: > > > > On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: > > Lets make a summary. > > > > What functionality would be good to have in FreeBSD that doesn't exist: > > > > 1) "runlevels" with arbitrary names. runlevel change would start and stop > > right services. > > 2) exploit startup parallelism. > > > > > > What we do not want to change: > > > > - file structure which is simple. one file in rc.d/ per service and one > > global config file (rc.conf) > > - anything else that would make things more complicated. > > > > > > As for > > > > 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel > > list for each service or runlevel exclusion list for service. > > > > > > examples: > > > > service1_enable="YES" > > service2_enable="NO" > > service3_enable="foolevel maintenance" > > service4_enable="YES -foolevel" (or ALL -funkyrunlevel) > > > > name of default runlevel may be "full" or "multiuser" > > > > service 1 will always work, service 2 never, service 3 only at runlevels > > "foolevel" and "maintenance", service4 with any runlevel except > > "foolevel". > > > > still single rc.conf, not much bigger in practice. > > > > 2) no change in rc.d/* scripts and rc.conf, but change in scripts. > > > > > > If everyone agree i think i may write this new scripts. > > Sorry but I completely disagree here. Why ? > > Because do one thing and do one thing well. What do you mean ? He means the UNIX philosophy. http://www.faqs.org/docs/artu/ch01s06.html 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: Replacing rc(8) (Was: FreeBSD Boot Times)
should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. ___ 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 Thu, Jun 21, 2012 at 05:19:27PM +0100, Chris Rees wrote: > On Jun 21, 2012 5:15 PM, "Jason Hellenthal" wrote: > > > > > > > > On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: > > > Lets make a summary. > > > > > > What functionality would be good to have in FreeBSD that doesn't exist: > > > > > > 1) "runlevels" with arbitrary names. runlevel change would start and > stop > > > right services. > > > 2) exploit startup parallelism. > > > > > > > > > What we do not want to change: > > > > > > - file structure which is simple. one file in rc.d/ per service and one > > > global config file (rc.conf) > > > - anything else that would make things more complicated. > > > > > > > > > As for > > > > > > 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or > runlevel > > > list for each service or runlevel exclusion list for service. > > > > > > > > > examples: > > > > > > service1_enable="YES" > > > service2_enable="NO" > > > service3_enable="foolevel maintenance" > > > service4_enable="YES -foolevel" (or ALL -funkyrunlevel) > > > > > > name of default runlevel may be "full" or "multiuser" > > > > > > service 1 will always work, service 2 never, service 3 only at runlevels > > > "foolevel" and "maintenance", service4 with any runlevel except > > > "foolevel". > > > > > > still single rc.conf, not much bigger in practice. > > > > > > 2) no change in rc.d/* scripts and rc.conf, but change in scripts. > > > > > > > > > If everyone agree i think i may write this new scripts. > > > > Sorry but I completely disagree here. Why ? > > > > Because do one thing and do one thing well. What do you mean ? > > He means the UNIX philosophy. > > http://www.faqs.org/docs/artu/ch01s06.html > Thanks.. I didn't have a link at hand for that. -- - (2^(N-1)) ___ 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/21/2012 05:28 AM, Peter Jeremy wrote:
> 32.0s - rc scripts ("mounting root" through VTY login prompt)
I think that there is some confusion about what I wrote originally, so
let me clarify. From the time that /etc/rc starts through the time that
the prompt appears almost all of the time is spent waiting for the
services to start. There is very little time spent IN the rc scripts
themselves (barring something that is poorly written of course). It's
also worth noting that because the time spent in this phase is heavily
dependent on what services you're starting, different people are going
to have vastly different experiences.
So the only way to improve the time from /etc/rc to "usable system"
(whatever that means for the user) is to see what we can parallelize.
The problem is that this is a really hard problem. :) And as someone
pointed out, changing from a serial to a parallel process is going to be
disruptive because it will uncover the inadequately specified
dependencies that we have now which are hidden by the serial process ...
and that's just the base. The over 800 rc.d scripts in the ports are
(sadly) more wrong than right when it comes to specifying their rcorder
stuff. This is mostly a holdover from the old days when the local
scripts were all run in the same spot regardless of what was in
PROVIDE/REQUIRE. Ever since I brought the local scripts into the overall
rcorder (over 6 years ago now) we've been refining this, but dealing
with this issue has to be something that is carefully considered in the
planning for any proposed modifications.
Personally, if we were going to undergo the amount of work it would take
to handle parallelization of the existing rc.d framework; I'd rather put
that work into designing and building a better system that does other
things we need in addition to booting faster.
To that end I like the direction that the thread is going in terms of
discussing what a new system should have. I have some thoughts about
that, but I'd like to let others talk for a while first.
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)
On Thu, 21 Jun 2012 12:22:08 +0200 (CEST) Wojciech Puchar wrote: > Lets make a summary. > > What functionality would be good to have in FreeBSD that doesn't exist: > > 1) "runlevels" with arbitrary names. runlevel change would start and stop > right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. - it should be easy to see which runlevels a service is on at. > 2) exploit startup parallelism. > > > What we do not want to change: > > - file structure which is simple. one file in rc.d/ per service and one > global config file (rc.conf) > - anything else that would make things more complicated. > > > As for > > 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel > list for each service or runlevel exclusion list for service. > > > examples: > > service1_enable="YES" > service2_enable="NO" > service3_enable="foolevel maintenance" > service4_enable="YES -foolevel" (or ALL -funkyrunlevel) Using two symbols to indicate negation - one to start, and then one on each runlevel - is overkill. There's not a use case where you have a keyword YES or ALL and then runlevels that you start. Personally, I'd restrict YES/NO/ALL to being single symbols, and use "NOT runlevels" to mean "All but these". A bare "NOT" should get the same treatment as a YES/NO/ALL with text after it. > name of default runlevel may be "full" or "multiuser" > > service 1 will always work, service 2 never, service 3 only at runlevels > "foolevel" and "maintenance", service4 with any runlevel except > "foolevel". > > still single rc.conf, not much bigger in practice. But each line has become more complicated, going from a simple on/off setting to a small language that can even have errors (like "foolevel -barlevel"). This violates the second thing on your list of things we don't want to change. Further, while you can easily tell what runlevels a service is on at, you can't easily tell what services are on at a given runlevel - that begs for a tool to be written. If you instead violate the requirement that we stick with a single rc.conf, the conf files can continue to have the same contents. For instance, create rc.conf.d/. If rc.conf exists, we just ignore the directory. Otherwise, use rc.conf/. Or maybe rc.conf gets is a link to rc.conf/default. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. This also begs for a tool to be written. Given the choice between having a file that wants a tool for reading, or one that wants a tool for writing, I'll take the latter. > 2) no change in rc.d/* scripts and rc.conf, but change in scripts. That's also true for my proposal. 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)
1) "runlevels" with arbitrary names. runlevel change would start and stop right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. already proposed in rc.conf - it should be easy to see which runlevels a service is on at. same. service2_enable="NO" service3_enable="foolevel maintenance" service4_enable="YES -foolevel" (or ALL -funkyrunlevel) Using two symbols to indicate negation - one to start, and then one on each runlevel - is overkill. There's not a use case where you have a better method already proposed by jhellent...@dataix.net But each line has become more complicated, going from a simple on/off setting to a small language that can even have errors (like "foolevel -barlevel"). This violates the second thing on your list of things we see above. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. i unable to understand this sentence. rc.d scripts would be exactly as they currently are. extra data in rc.conf would define "runlevels" at which they are active. doing this as currently (_enable=YES) would mean every "runlevel". my point is that if you put new startup system in place of old, nothing will change with your existing rc.conf! ___ 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 Thu, 21 Jun 2012 20:01:41 +0200 (CEST) Wojciech Puchar wrote: > >> 1) "runlevels" with arbitrary names. runlevel change would start and stop > >> right services. > > > > With a couple of additions: > > - it should be easy to see which services are on at a given runlevel. > > already proposed in rc.conf > > > - it should be easy to see which runlevels a service is on at. > same. No, harder. > > The downside is that it adding a service now becomes harder - you have > > to edit each runlevel script instead of just one. > i unable to understand this sentence. rc.d scripts would be exactly as > they currently are. Because you're taking it out of context. You removed the counter proposal above it. > extra data in rc.conf would define "runlevels" at which they are active. > doing this as currently (_enable=YES) would mean every "runlevel". Not in the counter proposal. > my point is that if you put new startup system in place of old, nothing > will change with your existing rc.conf! Also true in the counter proposal. 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)
z> my point is that if you put new startup system in place of old, nothing will change with your existing rc.conf! Also true in the counter proposal. so i miss something about the counterproposal. please point me 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: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 21, 2012 at 5:13 AM, Chris Rees wrote: > Your arrogance is astounding. > > Did you read man hier? Unfamiliarity does not make it incomprehensible. There's more going on than just unfamiliarity. Earlier versions were unfamiliar to someone used to Linux or BSD, but easy to understand because they were mostly configured by flat files. Modern Solaris has deliberately moved away from this and toward opaque configuration tools that modify stuff you aren't supposed to touch, behind the scenes. It's a bit like Windows that way; it's made it easier to manage if you're doing something pre-configured (like starting/stopping an existing service), but if you want to do something custom you have to do a *lot* of digging to figure out how to make it work. Some of the new stuff (like NWAM network configuration) is not even configurable without a GUI. -- David Brodbeck System Administrator, Linguistics University of Washington ___ 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)
manage if you're doing something pre-configured (like starting/stopping an existing service), but if you want to do something custom you have to do a *lot* of digging to figure out how to make it work. Some of the new stuff (like NWAM network configuration) is not even configurable without a GUI. Fortunately FreeBSD is not solaris so we shouldn't care about how solaris do this. ___ 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"
(no subject)
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.
>
> With very very very few exceptions, all analog NTSC broadcasts have
> been switched to digital, by the FCC mandated deadline of June 12,
> 2009.
As long as there remain some NTSC broadcasts, there might be some
that you wish to watch. That's why I wrote:
You'll need to know if you have any NTSC (analog) stations you
care about or if everything is ATSC (digital).
Aryeh may or may not have any NTSC stations of interest. Given
"we are using a broadcast signal only [current US {NYC} standards]"
I rather doubt that Aryeh has any PAL stations to worry about.
> You absolutely do NOT have to reencode a stream
I did not say anything about RE-encoding anything. Only about
encoding/compressing the high bandwidth datastream the tuner
generates from NTSC. And to be clear, this only applies to
NTSC, not to ATSC.
> Tuners do NOT provide raw audio/video to the system in any case.
http://corona.homeunix.net/cx88wiki/Overview/RawVideo
___
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
On Sun, 17 Jun 2012 02:01:35 -0400 David Schultz wrote: > On Wed, May 30, 2012, Aldis Berjoza wrote: > > On Sat, 26 May 2012 22:45:37 +1200 > > Sam Lin wrote: > > > > > Hi FreeBSD fellows, > > > > > > Those who are using LaTeX on FreeBSD must know that tetex has been > > > discontinued years ago and that TeXLive is now recommended, > > > however TeXLive has never been merged in the ports tree on > > > FreeBSD and that tetex is still used on FreeBSD ports. Although > > > there have been some "customized" work so that FreeBSD users can > > > install and use TeXLive on FreeBSD machine (for example, > > > http://code.google.com/p/freebsd-texlive/wiki/Installing), this is > > > quite confusing and may still cause conflict on the system side > > > when using or maintaining it. > > > > > > There has also been years of gossips that a Japanese developer > > > Hiroki Sato (hrs@freebsd) has been working on this matter for the > > > last years and therefore the FreeBSD admin panel don't want > > > anyone else to work on this and merge it into the ports tree. > > > > > > I actually contacted Hiroki Sato in the beginning of last year > > > (2011) regarding this, and in his reply he said that there had > > > been several technical issues but most of them had been solved > > > and almost ready to merge into the port tree, and that he was > > > planning to go forward after the 8.2/7.4 releases (one or two > > > weeks later from that time stage) are out. However, more than a > > > year has passed since then and still nothing happened. I tried to > > > contact him several times after that (email, tweet, etc) but > > > haven't heard anything back from him at all. > > > > > > Is TeXLive really going to be merged into the FreeBSD ports tree > > > as Hiroki Sato mentioned previously? Or is this just a myth?? > > > > > > I am now thinking that this should be put into the "FreeBSD > > > Project ideas List" [http://wiki.freebsd.org/IdeasPage]. > > > > > > Regards, > > > Sam > > > > > > > Hey, Sam! > > > > I which TeXLive would be merged in FreeBSD ports. Romain is doing > > great job maintaining it. And it work, And it work now. In fact it > > works for more than a year. > > I have used his TeXLive ports through portshaker for a while. > They work pretty well, but there are some issues due to the fact > that the TeXLive folks have some strange ideas. For one, TeXLive > is split into over 2000 packages, many of which are tiny; the > FreeBSD package system doesn't handle that very well. For another, > TeXLive now has its own (dubious) package manager, tlmgr, which > doesn't play well with other package management systems. > > I'm not a ports committer, but perhaps a good first step to > getting TeXLive working better in FreeBSD is to introduce a > TeTeX vs TeXLive knob in the ports tree so that people don't > wind up accidentally clobber their TeXLive install when TeTex > gets pulled in as a dependency. > ___ > 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" When I was using Linux, my favourite distro was Gentoo. Packages on Gentoo are installed in a fashion very alike to FreeBSD - in fact, Gentoos portage was modeled after FreeBSD ports. In portage, there is a knob package_provided meaning that the package referenced as being provided is installed externally and that portage does not need to resolve said dependancy, as it is already there. I do not know of a similar FreeBSD-construct, but have really wished for something alike to stop the pulling in of the teTeX-tree. Cheers, -- Christopher TZ: GMT + 2h signature.asc Description: PGP signature
Re: TeXLive merge into FreeBSD ports tree - FreeBSD project idea
On 21/06/2012 21:41, Christopher J. Ruwe wrote:
> In portage, there is a knob package_provided meaning that the package
> referenced as being provided is installed externally and that portage
> does not need to resolve said dependancy, as it is already there.
>
> I do not know of a similar FreeBSD-construct, but have really wished for
> something alike to stop the pulling in of the teTeX-tree.
Ports sort of does this automatically. Some of the time. It depends on
how the port is written.
If you've got a dependency line like:
RUN_DEPENDS=fc-cache:${PORTSDIR}/x11-fonts/fontconfig
or
LIB_DEPENDS=expat:${PORTSDIR}/textproc/expat2
then in the first instance the ports will check for the existence of
fc-cache as an executable on $PATH, and in the second instance for
libexpat.so as a shared library known to ld.so(1). There's nothing to
say that either of those files should have been installed from the
ports, and you can install quite happily against a non-ports-installed
dependency. Ports management software like portmaster(8) or
portupgrade(8) can get confused by this and may try and install the
dependency from ports in some circumstances.
However, if you've got a dependency that looks like so:
BUILD_DEPENDS= p5-BerkeleyDB>0:${PORTSDIR}/databases/p5-BerkeleyDB
ie. with > or >= and a version number, then the ports checks for the
installation of a package of at least the specified version. So in this
case, the ports has to be used to fulfil the dependency. (Perl module
dependencies are pretty much always done in this form nowadays in order
to avoid having to use ${SITE_PERL} in dependency lines.)
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 2012-Jun-21 10:09:01 -0700, Doug Barton wrote:
>On 06/21/2012 05:28 AM, Peter Jeremy wrote:
>> 32.0s - rc scripts ("mounting root" through VTY login prompt)
>
>I think that there is some confusion about what I wrote originally, so
>let me clarify. From the time that /etc/rc starts through the time that
>the prompt appears almost all of the time is spent waiting for the
>services to start. There is very little time spent IN the rc scripts
>themselves (barring something that is poorly written of course).
Agreed - I (and I expect everyone else) am using "rc script" to cover
the total wall time between exec()ing the script and it returning - in
most cases, this is almost entirely synchronous service startup time.
The end-user experience is governed by "how long does it take between
rebooting or turning the power on and when I can login or interact
with my service". Reducing this total time is going to require a
combination of changes in multiple areas.
One point I'd make is that the rc scripts run with cold caches so
reads cause physical I/O. There are somewhat over 150 scripts in
/etc/rc.d and a variable number in /usr/local/etc/rc.d (I have between
6 & 33 on different systems). rcorder(8) needs to read each script
so, on a system using spinning rust, this amounts to 2-3 seconds
overhead.
>So the only way to improve the time from /etc/rc to "usable system"
>(whatever that means for the user) is to see what we can parallelize.
>The problem is that this is a really hard problem. :) And as someone
>pointed out, changing from a serial to a parallel process is going to be
>disruptive because it will uncover the inadequately specified
>dependencies that we have now which are hidden by the serial process ...
(I mentioned this problem). One (though intrusive) way would be to
use the approach the ports system used when it enabled parallelism
within port builds: Add new keyword(s) within each script to control
parallelism for that script. Initially, the infrastructure would
assume "serial" unless scripts were explicitly marked "parallel" or
"background" but once the situation was sufficiently under control, it
could be flipped to assume "parallel" unless a script specifically
specified "serial". (Note that I haven't looked at the detail of
actually implementing this).
As an aside, "usable system" is a relevant point. My Netbook
originally came with Linpus and it took about 30s from poweron until
the Linpus GUI was displayed and allowed user interaction. This
looked quite impressive but it took another 30-60s before the system
was actually usable because the GUI was started quite early before
(eg) the network was up.
--
Peter Jeremy
pgpXRyu725r3y.pgp
Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote: > There's no need to do a wholesale replacement of the RC system in > FreeBSD to support this concept. What you are describing are "service > profiles". And we already have a single file that describes the > default "service profile" for FreeBSD: /etc/rc.conf. That lists > every service that should be started (or stopped). > > All that's missing is a way to tell the RC system to use a different > rc.conf file (like rc.conf.mobile, or rc.conf.wireless or > rc.conf.whatever), and to run through the RC setup based on that file. > > Our current RC system does everything needed except: > - parallel execution of items that don't depend on each other > - monitor running services and restart them if they crash - Service dependencies: if a service fails that is required by another service, the other is stopped as well. - Monitoring services and ability to configure the service supervisor behaviour: if service fails and is restarted X times in period Y, execute action Z. - Extending the concept of service beyond userland. Kernel services are services too, if eg. network is down, you probably don't want to even try to start a dozen jails. - Permission control (like possible in jails now, "limited root"), non-root users can be delegated permissions to start/stop selected services and configure their behaviour. It's clearly arguable as to which of these features and to what extent is reasonable to implement and whether or not it can or should be done in the existing rc system, instead of implementing a new one that just supports the old rc system as it is. There are real benefits in some of these features, but they can easily turn out as esoteric features in a bloated piece of code, if not implemented with great care. I don't know the internals of current rc system well enough to form educated opinion on how any of this could be done in practice, but I have plentyful experience in how and why projects fail and in this particular case I see a lot of chances for fail with relatively little gain. Just something to think about.. Might be worth noting that I work with Linux systems most of the time and over-engineering is a chronic problem there. I've always admired the simple but effective BSD approach, rather do less but well than a lot badly. -- 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)
On 2012-Jun-21 00:17:11 +0200, Wojciech Puchar wrote: >> - Lack of dependency handling for manual start/stop > >which is not really a problem and often an adventage. In your opinion. IMO, "runlevels" are a mostly a work-around to hide the lack of proper dependency handling. One obvious use for dependencies is where I have an occasional need for a box to be a NFS server. Given proper dependency handling, I can say "service nfsserver onestart" and it will automatically start rpcbind, statd, lockd and mountd. Another case is doing single-user maintenance on a ZFS system. It would be nice to be able to just say "service zfs start" instead of having to remember to start hostname and hostid first. I agree there are cases where you might want to ignore dependencies. This is easily handled with at "ignore dependencies" flag on service. >> - No provision to automatically restart a daemon if it dies. > >but it should not be a part of rc subsystem at all. Both the monitoring tool and rc subsystem have to interwork to ensure that services aren't inappropriately started or stopped. You can treat them as separate if you insist but the interactions make it much easier if they are designed together. >First - deamons should not die without reason. Agreed but sometimes they can for a wide variety of reasons. > If they do, admin should clearly know it Agreed. But this still requires infrastructure that is not currently avaliable in the base system and is irrelevant to the issue of whether the daemon should be restarted automatically. > and feel it's effects, Some of this can be automated. And a fallback of "try starting it a few times and complain loudly if that doesn't work" is easily implemented (init(8) does it now) and generally works. > and after fixing a source problem , restart it manually. This can present difficulties if you can't actually login remotely because it's sshd that has aborted unexpectedly. And it can be irritating when you get woken at 0300 just to restart some random service that glitched. >in case when you are for some reason required (temporarily of course) to >use daemons that often dies, then just make restart wrapper shell script >and put it in place of actual daemon in rc.d script. It's nothing to do with "often dies". Unless you have bug-free sotfware, you can have "rarely-and-unexpectedly dies" - which is just as annoying if it occurs when you (or a customer) needs it. And, with this approach, you wind up with N protected daemons and a further N (or 2N if you're paranoid) monitoring daemons - each thrown together independently. A single, central process that can detect when a process dies (or fails some pre-defined "working normally" test) and optionally take some pre-defined action would seem preferable. (Hint: init(8) can already do a lot of this). >there is IMHO already too much automata in default FreeBSD: >default /etc/crontab, /etc/newsyslog.conf and /etc/periodic directory. > >All gets deleted by me as soon as i install FreeBSD. You are free to disable or delete as much of FreeBSD as you like but I personally prefer my systems to reduce my workload by automating normal maintenance tasks. -- Peter Jeremy pgp749EyaVr0n.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/21/2012 06:49 PM, Atte Peltomäki wrote: > On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote: >> There's no need to do a wholesale replacement of the RC system in >> FreeBSD to support this concept. What you are describing are "service >> profiles". And we already have a single file that describes the >> default "service profile" for FreeBSD: /etc/rc.conf. That lists >> every service that should be started (or stopped). >> >> All that's missing is a way to tell the RC system to use a different >> rc.conf file (like rc.conf.mobile, or rc.conf.wireless or >> rc.conf.whatever), and to run through the RC setup based on that file. >> >> Our current RC system does everything needed except: >> - parallel execution of items that don't depend on each other OpenRC does this. >> - monitor running services and restart them if they crash OpenRC does not do monitoring, but it has the prerequisites in place necessary to implement that. It will tell you which services crashed if you run `rc-status`. It should be possible to implement daemon-tools-like monitoring. > - Service dependencies: if a service fails that is required by another > service, the other is stopped as well. It is possible to implement this in OpenRC. > - Monitoring services and ability to configure the service supervisor > behaviour: if service fails and is restarted X times in period Y, > execute action Z. This is also possible to implement, although it would be a pain. > - Extending the concept of service beyond userland. Kernel services are > services too, if eg. network is down, you probably don't want to even > try to start a dozen jails. OpenRC does this. > - Permission control (like possible in jails now, "limited root"), > non-root users can be delegated permissions to start/stop selected > services and configure their behaviour. This description is too vague for me to be able to comment on it. > It's clearly arguable as to which of these features and to what extent > is reasonable to implement and whether or not it can or should be done > in the existing rc system, instead of implementing a new one that just > supports the old rc system as it is. > > There are real benefits in some of these features, but they can easily > turn out as esoteric features in a bloated piece of code, if not > implemented with great care. I don't know the internals of current rc > system well enough to form educated opinion on how any of this could be > done in practice, but I have plentyful experience in how and why projects > fail and in this particular case I see a lot of chances for fail with > relatively little gain. > > Just something to think about.. Might be worth noting that I work with > Linux systems most of the time and over-engineering is a chronic problem > there. I've always admired the simple but effective BSD approach, rather > do less but well than a lot badly. OpenRC is about 10,000 lines of code and is a mix of C and POSIX shell. Performance critical code is written in C. Debian's sysvinit is 3,000 lines of bash. POSIX shell is more verbose than bash and C is even more verbose than POSIX shell, but I would consider it to be fairly lean. If I recall correctly, I was told that Upstart is 80,000 lines of code and systemd is roughly 200,000 lines of code. If you consider of all of systemd's dependencies, it becomes 2,000,000 lines of code. ___ 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 Thu, 21 Jun 2012 18:20:44 +0200 (CEST) Wojciech Puchar wrote: > >> should not be done, or at least not default. > > > > http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) > > http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control > separate and optional program. > that's acceptable, except i have no idea why this fscadm enable/disable. > editing config is enough. I don't think I understand "i have no idea why this fscadm enable/disable. editing config is enough." and would ask you elaborate for me. Thanks, -- Tom Rhodes ___ 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)
separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. I don't think I understand "i have no idea why this fscadm enable/disable. editing config is enough." and would ask you elaborate for me. Thanks, why adding solaris style command to add a line in text file. just edit a text file. ___ 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 Jun 22, 2012 7:33 AM, "Wojciech Puchar" wrote: >>> >>> separate and optional program. >>> that's acceptable, except i have no idea why this fscadm enable/disable. >>> editing config is enough. >> >> >> I don't think I understand >> "i have no idea why this fscadm enable/disable. editing config is enough." >> and would ask you elaborate for me. Thanks, > > > why adding solaris style command to add a line in text file. just edit a text file. > Scripting? 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"
