Date: Fri, 17 Feb 2012 18:36:18 -0800 From: matt <sendtomatt@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? Message-ID: <4F3F0EA2.7010709@gmail.com> In-Reply-To: <4F3EF18F.5020301@freebsd.org> References: <CAOjFWZ6WM1bLEwaBiUE50Gj4MrwxefDWFb85ecRtYkSDuZ0erg@mail.gmail.com> <mailpost.1329495670.7246668.67851.mailing.freebsd.hackers@FreeBSD.cs.nctu.edu.tw> <4F3E8225.9030501@FreeBSD.org> <E1RyRKJ-000Ioa-Ec@hans3> <4F3E8C26.3080900@FreeBSD.org> <E1RyRq0-000Iqy-3l@hans3> <4F3EA5F2.9070804@gmail.com> <E1RyTZo-000J0R-0Y@hans3> <4F3EAE5F.6070903@gmail.com> <E1RyUv6-000J5e-0E@hans3> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EF18F.5020301@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/17/12 16:32, Julian Elischer wrote: >> On 02/17/12 14:08, rank1seeker@gmail.com wrote: >>>> For me as a user, that would be a much preferable approach, instille= d >>>> long ago by Linux. I don't like unused stuff around, and I like to >>>> understand what I am using. >>>> >>>> Some build kernel confutation parameters "minimum modules", "medium >>>> modules", "maximum modules" might be utilized. I would be using >>>> "medium" or most likely "maximum", leaving me with a minimal kernel.= >>>> >>>> -- Alex -- alex-goncharov@comcast.net -- >>> NO. >>> >>>> Thinking bigger picture (beyond sound), would it make sense to keep >>>> GENERIC very minimal, but provide an extensive loader.conf with a >>>> default install...so most things worked, but were loaded as modules?= >>>> >>>> Matt >>> NO. >>> >>> >>> You can't base a "wish" on a solution for YOURS problems! >>> >>> GENERIC must be as giantic as possible, to make as many machines as >>> possible to BOOT and enable all what can be enabled in/on them. >>> THEN ... individual "strips" unhooked parts -> custom kernel, via >>> wich you "specialize it", for your hardware! >>> >>> That is, unless individual is passive/bored (lazy?) and prefer >>> everything on a silver plate ... >>> There are many paths in that case ... >>> Windows are the easiest solution. THEY THINK FOR YOU! >>> ;) >>> >>> >>> Domagoj Smol=E8i=E6 >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> I'm tired of Linux and "everything should be in the kernel, implemente= d >> 4 ways" approach. >> >> I think you misunderstood. GENERIC should be able to boot anything >> bootable within the architecture, right? We agree on that. Is sound >> required for booting? >> >> We have a modular kernel. It makes best-practices-sense to keep the >> kernel true to what's required to boot and initialize the hardware >> required to come up multiuser. I am actually against having sound in >> there at all. >> >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. >> >> Do we still disagree? > > I think we probably should go two ways long and short term > 1/ generic is installed at boot > a) also install a truely "minimal" kernel and configure modules to > use with it. > but only once up and running with GENERIC. > 2/ in the logn term we should add teh ability to detect devices and > load modules > needed.. either from the loader, or in early boot. >> Matt >> >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> >> > I really agree with 2 the most. 1 is true, and subsection a is manual as usual. I can recompile for that. I don't think anything *needs* to be done at all, and this really started on my part with a hypothetical. In the long run, though, option 2 is best. I certainly am not advocating removing tons of stuff from GENERIC, which is what people seem to hear in some cases. I'm advocating the KISS principle (Keep It Simple Stupid) and building a system out from there. Why lock in drivers not necessary to bring up a system? It's more danger (boot hangs, driver bugs, security vulnerabilities) for no benefit. If it's loaded as a module, there is the potential to prevent the load and continue on with boot or bring up the system. Sometimes that counts! Same goes for debugging, troubleshooting, trying to get poorly documented hardware to go through system S3 sleep...etc. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3F0EA2.7010709>