From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:27:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:27:33 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:50309 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 13:27:18 -0500 Date: Mon, 14 Jan 2002 13:10:50 -0500 From: "Eric S. Raymond" To: Alan Cox Cc: "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Hardwired drivers are going away? Message-ID: <20020114131050.E14747@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Mon, Jan 14, 2002 at 06:08:32PM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > For 2.5 if things go to plan there will be no such thing as a "compiled in" > driver. They simply are not needed with initramfs holding what were once the > "compiled in" modules. This is something of a bombshell. Not necessarily a bad one, but... Alan, do you have *any* *freakin'* *idea* how much more complicated the CML2 deduction engine had to be because the basic logical entity was a tristate rather than a bool? If this plan goes through, I'm going to be able to drop out at least 20% of the code, with most of that 20% being in the nasty complicated bits where the maintainability improvement will be greatest. And I can get rid of the nasty "vitality" flag, which probably the worst wart on the language. Yowza...so how soon is this supposed to happen? -- Eric S. Raymond Government should be weak, amateurish and ridiculous. At present, it fulfills only a third of the role. -- Edward Abbey From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:46:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:45:37 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:20486 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 13:44:15 -0500 Subject: Re: Hardwired drivers are going away? To: esr@thyrsus.com Date: Mon, 14 Jan 2002 18:56:02 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), babydr@baby-dragons.com (Mr. James W. Laferriere), cate@debian.org (Giacomo Catenazzi), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: <20020114131050.E14747@thyrsus.com> from "Eric S. Raymond" at Jan 14, 2002 01:10:50 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > that 20% being in the nasty complicated bits where the maintainability > improvement will be greatest. And I can get rid of the nasty "vitality" > flag, which probably the worst wart on the language. > > Yowza...so how soon is this supposed to happen? Subject to availability. No contract implied or etc.. Its something to tackle after the rest of initramfs works. Even if not then the lsmod case can be made to work since its just a matter of putting the names in a segment for the linker to collate. We already have module_init/module_exit which is a big chunk of the cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:54:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:53:29 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:33286 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 13:53:01 -0500 Subject: Re: Hardwired drivers are going away? To: david.lang@digitalinsight.com (David Lang) Date: Mon, 14 Jan 2002 19:04:34 +0000 (GMT) Cc: esr@thyrsus.com (Eric S. Raymond), alan@lxorguk.ukuu.org.uk (Alan Cox), babydr@baby-dragons.com (Mr. James W. Laferriere), cate@debian.org (Giacomo Catenazzi), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: from "David Lang" at Jan 14, 2002 10:50:20 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 1. security, if you don't need any modules you can disable modules entirly > and then it's impossible to add a module without patching the kernel first > (the module load system calls aren't there) Urban legend. > 2. speed, there was a discussion a few weeks ago pointing out that there > is some overhead for useing modules (far calls need to be used just in > case becouse the system can't know where the module will be located IIRC) I defy you to measure it on x86 > 3. simplicity in building kernels for other machines. with a monolithic > kernel you have one file to move (and a bootloader to run) with modules > you have to move quite a few more files. tar or nfs mount; make modules_install. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:51:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:50:56 -0500 Received: from [208.29.163.248] ([208.29.163.248]:4288 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 13:50:36 -0500 From: David Lang To: "Eric S. Raymond" Cc: Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Date: Mon, 14 Jan 2002 10:50:20 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114131050.E14747@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I can see a couple reasons for building a kernel without useing modules. 1. security, if you don't need any modules you can disable modules entirly and then it's impossible to add a module without patching the kernel first (the module load system calls aren't there) 2. speed, there was a discussion a few weeks ago pointing out that there is some overhead for useing modules (far calls need to be used just in case becouse the system can't know where the module will be located IIRC) 3. simplicity in building kernels for other machines. with a monolithic kernel you have one file to move (and a bootloader to run) with modules you have to move quite a few more files. modules are good for distros and for machines that have to worry about hotpluged equipment (but even that is less nessasary then it used to be) but for servers that don't change their hardware they aren't nessasary, why should they have to deal with them? David Lang On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Date: Mon, 14 Jan 2002 13:10:50 -0500 > From: Eric S. Raymond > To: Alan Cox > Cc: Mr. James W. Laferriere , > Giacomo Catenazzi , > Linux Kernel List > Subject: Hardwired drivers are going away? > > Alan Cox : > > For 2.5 if things go to plan there will be no such thing as a "compiled in" > > driver. They simply are not needed with initramfs holding what were once the > > "compiled in" modules. > > This is something of a bombshell. Not necessarily a bad one, but... > > Alan, do you have *any* *freakin'* *idea* how much more complicated > the CML2 deduction engine had to be because the basic logical entity > was a tristate rather than a bool? If this plan goes through, I'm > going to be able to drop out at least 20% of the code, with most of > that 20% being in the nasty complicated bits where the maintainability > improvement will be greatest. And I can get rid of the nasty "vitality" > flag, which probably the worst wart on the language. > > Yowza...so how soon is this supposed to happen? > -- > Eric S. Raymond > > Government should be weak, amateurish and ridiculous. At present, it > fulfills only a third of the role. -- Edward Abbey > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:57:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:56:23 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:3718 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 13:55:40 -0500 Date: Mon, 14 Jan 2002 13:39:11 -0500 From: "Eric S. Raymond" To: Alan Cox Cc: "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020114133911.B17522@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List In-Reply-To: <20020114131050.E14747@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Mon, Jan 14, 2002 at 06:56:02PM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > > Yowza...so how soon is [the end of hard-compiled drivers] supposed to > > happen? > > Subject to availability. No contract implied or etc.. Its something to > tackle after the rest of initramfs works. Dang. This will make the CML2 inference engine work better in some funky corner cases, too. And its behavior will be easier to understand all around. Sign me up. This will be a good change; I like it when I can make things better by taking features *out* of my code. -- Eric S. Raymond Every Communist must grasp the truth, 'Political power grows out of the barrel of a gun.' -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:02:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:01:46 -0500 Received: from ns1.baby-dragons.com ([199.33.245.254]:44419 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:00:13 -0500 Date: Mon, 14 Jan 2002 14:00:01 -0500 (EST) From: "Mr. James W. Laferriere" To: Alan Cox cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello Alan , On Mon, 14 Jan 2002, Alan Cox wrote: > > 1. security, if you don't need any modules you can disable modules entirly > > and then it's impossible to add a module without patching the kernel first > > (the module load system calls aren't there) > > Urban legend. I do not agree . Got proof ? Yes that is a valid question . > > 2. speed, there was a discussion a few weeks ago pointing out that there > > is some overhead for useing modules (far calls need to be used just in > > case becouse the system can't know where the module will be located IIRC) > I defy you to measure it on x86 OK ,How about sparc-64/alpha/ia64/... ? > > 3. simplicity in building kernels for other machines. with a monolithic > > kernel you have one file to move (and a bootloader to run) with modules > > you have to move quite a few more files. > tar or nfs mount; make modules_install. Please my laugh'o meter is stuck already . Sorry . JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:07:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:05:39 -0500 Received: from [208.29.163.248] ([208.29.163.248]:51880 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 14:04:23 -0500 From: David Lang To: Alan Cox Cc: esr@thyrsus.com, babydr@baby-dragons.com, cate@debian.org, linux-kernel@vger.kernel.org Date: Mon, 14 Jan 2002 10:57:19 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, Alan Cox wrote: > > 1. security, if you don't need any modules you can disable modules entirly > > and then it's impossible to add a module without patching the kernel first > > (the module load system calls aren't there) > > Urban legend. > If this is the case then why do I get systemcall undefined error messages when I make a mistake and attempt to load a module on a kernel without modules enabled? > > 2. speed, there was a discussion a few weeks ago pointing out that there > > is some overhead for useing modules (far calls need to be used just in > > case becouse the system can't know where the module will be located IIRC) > > I defy you to measure it on x86 during the discussion a few weeks ago there were people pointing out cases where this overhead would be a problem. > > 3. simplicity in building kernels for other machines. with a monolithic > > kernel you have one file to move (and a bootloader to run) with modules > > you have to move quite a few more files. > > tar or nfs mount; make modules_install. > not on my firewalls thank you. David Lang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:08:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:07:16 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:46342 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:05:51 -0500 Subject: Re: Hardwired drivers are going away? To: babydr@baby-dragons.com (Mr. James W. Laferriere) Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: from "Mr. James W. Laferriere" at Jan 14, 2002 02:00:01 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > Urban legend. > I do not agree . Got proof ? Yes that is a valid question . Most of the rootkit type stuff I see nowdays includes code for loading patches into module free kernels. Its a real no win. The better ones support regexp scanning so they can patch kernels where the sysadmin thinks he/she is cool and has hidden or crapped in System.map > > > case becouse the system can't know where the module will be located IIRC) > > I defy you to measure it on x86 > OK ,How about sparc-64/alpha/ia64/... ? Not generally found in your grandmothers PC > > > 3. simplicity in building kernels for other machines. with a monolithic > > > kernel you have one file to move (and a bootloader to run) with modules > > > you have to move quite a few more files. > > tar or nfs mount; make modules_install. > Please my laugh'o meter is stuck already . Sorry . JimL Then fix it, because the above works well. Also remember that autoconfig tools won't be able to guess remote machines very well 8) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:11:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:09:49 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:48134 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:09:17 -0500 Subject: Re: Hardwired drivers are going away? To: david.lang@digitalinsight.com (David Lang) Date: Mon, 14 Jan 2002 19:21:01 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), esr@thyrsus.com, babydr@baby-dragons.com, cate@debian.org, linux-kernel@vger.kernel.org In-Reply-To: from "David Lang" at Jan 14, 2002 10:57:19 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > Urban legend. > > If this is the case then why do I get systemcall undefined error messages > when I make a mistake and attempt to load a module on a kernel without > modules enabled? Because you are using insmod. The guys who break into your computer probably are not in their own language "that lame". > > I defy you to measure it on x86 > > during the discussion a few weeks ago there were people pointing out cases > where this overhead would be a problem. TLB miss overhead for kernel modules is very very hard to measure, at least on the x86 platform. It can be an issue in userspace as you address much larger objects and in certain cases like scanning an element in an array of objects hit a TLB reload each scan or two (think about vertical line draw unaccelerated in X11) > > tar or nfs mount; make modules_install. > > > not on my firewalls thank you. If you are that worried just burn a new root file system on CD when you upgrade your firewall. At least I hope if you are going to pretend to be so secure that tar is a bad idea you have no writable file store on the machine ? Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:10:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:09:52 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:35797 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:09:18 -0500 Date: Mon, 14 Jan 2002 14:09:16 -0500 (EST) From: Alexander Viro To: "Eric S. Raymond" cc: Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114131050.E14747@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Alan Cox : > > For 2.5 if things go to plan there will be no such thing as a "compiled in" > > driver. They simply are not needed with initramfs holding what were once the > > "compiled in" modules. > > This is something of a bombshell. Not necessarily a bad one, but... > > Alan, do you have *any* *freakin'* *idea* how much more complicated > the CML2 deduction engine had to be because the basic logical entity > was a tristate rather than a bool? If this plan goes through, I'm > going to be able to drop out at least 20% of the code, with most of > that 20% being in the nasty complicated bits where the maintainability > improvement will be greatest. And I can get rid of the nasty "vitality" > flag, which probably the worst wart on the language. > > Yowza...so how soon is this supposed to happen? Two technical obstacles: a) on some architecures modular code is slower (IIRC, the problem is with medium-range calls being faster than far ones and usable only in the kernel proper). We probaly want to leave a gap after the .text and remap .text of module in there - if I understand the problem that should be enough, but that's really a question to folks dealing with these ports (PPC64 and Itanic?) b) current differences between options parsing in case of built-in and modular drivers. The rest is trivial and should be done in 2.5.4-pre* or so. But it still leaves you with tristate - instead of yes/module/no it's yes/yes, but don't put it on initramfs/no. However, dependencies become simpler - all you need is "I want this, that and that on initramfs" and the rest can be found by depmod (i.e. configurator doesn't have to deal with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there (== can't be M)"). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:16:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:15:26 -0500 Received: from ns1.system-techniques.com ([199.33.245.254]:48003 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:14:43 -0500 Date: Mon, 14 Jan 2002 14:14:31 -0500 (EST) From: "Mr. James W. Laferriere" To: Alan Cox cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello Alan , On Mon, 14 Jan 2002, Alan Cox wrote: > > > Urban legend. > > I do not agree . Got proof ? Yes that is a valid question . > Most of the rootkit type stuff I see nowdays includes code for loading > patches into module free kernels. Its a real no win. The better ones support > regexp scanning so they can patch kernels where the sysadmin thinks he/she > is cool and has hidden or crapped in System.map Same as I am seeing . This does not eleviate the fact that modules can & are a still a security issue . Yes , sloppy administration is still the biggest culprit in 'most' compromises . > > > > case becouse the system can't know where the module will be located IIRC) > > > I defy you to measure it on x86 > > OK ,How about sparc-64/alpha/ia64/... ? > Not generally found in your grandmothers PC No, But it is -mine- ! If I can not have complete control over my system due to the way the Fathers of this operating system are taking it I will have no choice but to use another or be stuck at a non-maintained version . Now mind you I LIKE LINUX ! > > > > 3. simplicity in building kernels for other machines. with a monolithic > > > > kernel you have one file to move (and a bootloader to run) with modules > > > > you have to move quite a few more files. > > > tar or nfs mount; make modules_install. > > Please my laugh'o meter is stuck already . Sorry . JimL > Then fix it, because the above works well. Also remember that autoconfig > tools won't be able to guess remote machines very well 8) Show me , Please . I am not convinced . I shall try out the new level of kernel without a doubt . But , I find the concept that -everything- is dynamic to be wrong . Mind you My opinion . Twyl , JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:20:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:19:17 -0500 Received: from chmls18.ne.ipsvc.net ([24.147.1.153]:17800 "EHLO chmls18.ne.ipsvc.net") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:18:50 -0500 Date: Mon, 14 Jan 2002 14:03:57 -0500 To: David Lang Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020114140357.B4762@pimlott.ne.mediaone.net> Mail-Followup-To: David Lang , linux-kernel@vger.kernel.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i From: Andrew Pimlott Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2002 at 10:57:19AM -0800, David Lang wrote: > On Mon, 14 Jan 2002, Alan Cox wrote: > > > > 1. security, if you don't need any modules you can disable modules entirly > > > and then it's impossible to add a module without patching the kernel first > > > (the module load system calls aren't there) > > > > Urban legend. > > If this is the case then why do I get systemcall undefined error messages > when I make a mistake and attempt to load a module on a kernel without > modules enabled? It's an urban legend that this is a security benefit. grep the hacker zines for injecting code into a non-modular kernel. > > > 2. speed, there was a discussion a few weeks ago pointing out that there > > > is some overhead for useing modules (far calls need to be used just in > > > case becouse the system can't know where the module will be located IIRC) > > > > I defy you to measure it on x86 ^^^^^^^^^^ > during the discussion a few weeks ago there were people pointing out cases > where this overhead would be a problem. Above. > > > 3. simplicity in building kernels for other machines. with a monolithic > > > kernel you have one file to move (and a bootloader to run) with modules > > > you have to move quite a few more files. > > > > tar or nfs mount; make modules_install. > > > not on my firewalls thank you. You won't install tar on your firewalls? Weird :-) Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:15:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:13:58 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:52742 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:12:34 -0500 Subject: Re: Hardwired drivers are going away? To: viro@math.psu.edu (Alexander Viro) Date: Mon, 14 Jan 2002 19:24:17 +0000 (GMT) Cc: esr@thyrsus.com (Eric S. Raymond), alan@lxorguk.ukuu.org.uk (Alan Cox), babydr@baby-dragons.com (Mr. James W. Laferriere), cate@debian.org (Giacomo Catenazzi), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: from "Alexander Viro" at Jan 14, 2002 02:09:16 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > a) on some architecures modular code is slower (IIRC, the problem is > with medium-range calls being faster than far ones and usable only in the > kernel proper). We probaly want to leave a gap after the .text and remap Also with TLB mapping sizes (4Mb versus 4K) > .text of module in there - if I understand the problem that should be > enough, but that's really a question to folks dealing with these ports (PPC64 > and Itanic?) For x86 you just need to leave a nice chunk of physical memory that is there to copy the module text/data into as you insmod them during boot then give the rest of the pool back to the paging system. This also solves the problem with "can't be a module because I need 1Mb of linear space" drivers. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:27:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:26:07 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:775 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:25:40 -0500 Subject: Re: Hardwired drivers are going away? To: babydr@baby-dragons.com (Mr. James W. Laferriere) Date: Mon, 14 Jan 2002 19:37:36 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: from "Mr. James W. Laferriere" at Jan 14, 2002 02:14:31 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > No, But it is -mine- ! If I can not have complete control over > my system due to the way the Fathers of this operating system > are taking it I will have no choice but to use another or be stuck > at a non-maintained version . Now mind you I LIKE LINUX ! Right but you aren't going to go and use autoconfig except maybe to get an initial Configuration to frob with ? Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:30:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:29:11 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:22773 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 14:27:58 -0500 Date: Mon, 14 Jan 2002 14:27:55 -0500 (EST) From: Alexander Viro To: David Lang cc: "Eric S. Raymond" , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, David Lang wrote: > I can see a couple reasons for building a kernel without useing modules. > > 1. security, if you don't need any modules you can disable modules entirly > and then it's impossible to add a module without patching the kernel first > (the module load system calls aren't there) Oh, please... Give me permissions sufficient to make these syscalls and in a couple of minutes your kernel will be replaced with ELIZA. As a bonus - ELIZA running under TOPS-10 on PDP-10 emulator. And talking to PARRY. Anyway, it's trivial to disable said system calls just before doing execve("/sbin/init",...). It won't buy you any security, but if you insist... > 2. speed, there was a discussion a few weeks ago pointing out that there > is some overhead for useing modules (far calls need to be used just in > case becouse the system can't know where the module will be located IIRC) _That_ has to be addressed - regardless of anything else, if that suckitude can be fixed it should be. > 3. simplicity in building kernels for other machines. with a monolithic > kernel you have one file to move (and a bootloader to run) with modules > you have to move quite a few more files. FVO"quite a few" equal to 2. Kernel and initramfs.cpio.gz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 13:57:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 13:56:10 -0500 Received: from ns1.system-techniques.com ([199.33.245.254]:43139 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 13:54:38 -0500 Date: Mon, 14 Jan 2002 13:54:31 -0500 (EST) From: "Mr. James W. Laferriere" To: "Eric S. Raymond" cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114131050.E14747@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello All , And on that day linux will loose one small person . Taf , JimL On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Alan Cox : > > For 2.5 if things go to plan there will be no such thing as a "compiled in" > > driver. They simply are not needed with initramfs holding what were once the > > "compiled in" modules. > > This is something of a bombshell. Not necessarily a bad one, but... > > Alan, do you have *any* *freakin'* *idea* how much more complicated > the CML2 deduction engine had to be because the basic logical entity > was a tristate rather than a bool? If this plan goes through, I'm > going to be able to drop out at least 20% of the code, with most of > that 20% being in the nasty complicated bits where the maintainability > improvement will be greatest. And I can get rid of the nasty "vitality" > flag, which probably the worst wart on the language. > > Yowza...so how soon is this supposed to happen? > -- > Eric S. Raymond > > Government should be weak, amateurish and ridiculous. At present, it > fulfills only a third of the role. -- Edward Abbey > +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:48:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:46:49 -0500 Received: from [208.29.163.248] ([208.29.163.248]:41181 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 14:45:10 -0500 From: David Lang To: Alan Cox Cc: babydr@baby-dragons.com, linux-kernel@vger.kernel.org Date: Mon, 14 Jan 2002 11:44:59 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, Alan Cox wrote: > Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT) > From: Alan Cox > To: babydr@baby-dragons.com > Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org > Subject: Re: Hardwired drivers are going away? > > > > Urban legend. > > I do not agree . Got proof ? Yes that is a valid question . > > Most of the rootkit type stuff I see nowdays includes code for loading > patches into module free kernels. Its a real no win. The better ones support > regexp scanning so they can patch kernels where the sysadmin thinks he/she > is cool and has hidden or crapped in System.map > > > > > case becouse the system can't know where the module will be located IIRC) > > > I defy you to measure it on x86 > > OK ,How about sparc-64/alpha/ia64/... ? > > Not generally found in your grandmothers PC doesn't matter, they are likly to be found on dedicated servers where the flexibility of modules is not needed and the slight performance advantage is desired. making everything modular is fine for desktops/laptops but why should dedicated servers pay the price? > > > > 3. simplicity in building kernels for other machines. with a monolithic > > > > kernel you have one file to move (and a bootloader to run) with modules > > > > you have to move quite a few more files. > > > tar or nfs mount; make modules_install. > > Please my laugh'o meter is stuck already . Sorry . JimL > > Then fix it, because the above works well. Also remember that autoconfig > tools won't be able to guess remote machines very well 8) I don't want autoconfig to detect my remote machines I want to specify them directly. (there are likly to be things on the motherboards of machines that I don't want to compile into the kernel, sound cards for servers are one example, video drivers are another, and USB is a third) autoconfig is supposed to be an option, not the only way to compile a kernel (or are you saying that you don't want to be able to use your 1.2G athlon to build the kernel for your 486?) David Lang From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 14:57:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 14:56:26 -0500 Received: from [208.29.163.248] ([208.29.163.248]:49315 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 14:55:07 -0500 From: David Lang To: Alan Cox Cc: babydr@baby-dragons.com, linux-kernel@vger.kernel.org Date: Mon, 14 Jan 2002 11:54:27 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org note: this discussion has moved away from autoconfig to requiring everything to be modules. autoconfig is a useful tool in some cases, but is not going to be used everywhere. I view modules as being in the same catagory. David Lang On Mon, 14 Jan 2002, Alan Cox wrote: > Date: Mon, 14 Jan 2002 19:17:46 +0000 (GMT) > From: Alan Cox > To: babydr@baby-dragons.com > Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org > Subject: Re: Hardwired drivers are going away? > > > > Urban legend. > > I do not agree . Got proof ? Yes that is a valid question . > > Most of the rootkit type stuff I see nowdays includes code for loading > patches into module free kernels. Its a real no win. The better ones support > regexp scanning so they can patch kernels where the sysadmin thinks he/she > is cool and has hidden or crapped in System.map > > > > > case becouse the system can't know where the module will be located IIRC) > > > I defy you to measure it on x86 > > OK ,How about sparc-64/alpha/ia64/... ? > > Not generally found in your grandmothers PC > > > > > 3. simplicity in building kernels for other machines. with a monolithic > > > > kernel you have one file to move (and a bootloader to run) with modules > > > > you have to move quite a few more files. > > > tar or nfs mount; make modules_install. > > Please my laugh'o meter is stuck already . Sorry . JimL > > Then fix it, because the above works well. Also remember that autoconfig > tools won't be able to guess remote machines very well 8) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:11:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:10:10 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:6587 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 15:09:31 -0500 Date: Mon, 14 Jan 2002 15:09:26 -0500 (EST) From: Alexander Viro To: David Lang cc: Alan Cox , babydr@baby-dragons.com, linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, David Lang wrote: > doesn't matter, they are likly to be found on dedicated servers where > the flexibility of modules is not needed and the slight performance > advantage is desired. > > making everything modular is fine for desktops/laptops but why should > dedicated servers pay the price? There should be no price. And AFAICS that's doable. > autoconfig is supposed to be an option, not the only way to compile a > kernel (or are you saying that you don't want to be able to use your 1.2G > athlon to build the kernel for your 486?) autoconfig is completely separate story. There are very good reasons to avoid built-in/modular crap, regardless of the autoconf. Every #ifdef MODULE is a bug waiting to happen - simply because the stuff gets out of sync. Every place that consists of #ifdef CONFIG_FOO init_foo(); #endif .... is a permanent source of PITA for out-of-tree drivers/patch merging/etc. And that's aside of the fun with ordering, etc. If we can get rid of performance hit on modular code - we should go for that variant simply because it reduces the amount of bug sources. Autoconfig and other details of ESR's Aunt Tillie fetish belong to alt.sex.* - from time to time they may be amusing, but let's not mix them with the technical arguments, OK? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:31:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:29:41 -0500 Received: from ns1.system-techniques.com ([199.33.245.254]:56707 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 15:29:11 -0500 Date: Mon, 14 Jan 2002 15:28:59 -0500 (EST) From: "Mr. James W. Laferriere" To: Alan Cox cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello Alan , On Mon, 14 Jan 2002, Alan Cox wrote: > > No, But it is -mine- ! If I can not have complete control over > > my system due to the way the Fathers of this operating system > > are taking it I will have no choice but to use another or be stuck > > at a non-maintained version . Now mind you I LIKE LINUX ! > Right but you aren't going to go and use autoconfig except maybe to get > an initial Configuration to frob with ? Ok , Now I am confused . I guess it's not hard to do . Is the Kernel headed toward Soft drivers or not ? I get my initial Config (say from autoconf.) how will that keep the Drivers in the Kernel ? Tia , JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:36:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:35:17 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:36486 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 15:34:56 -0500 Date: Mon, 14 Jan 2002 15:17:48 -0500 From: "Eric S. Raymond" To: Alexander Viro Cc: Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020114151748.B19776@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alexander Viro , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List In-Reply-To: <20020114131050.E14747@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@math.psu.edu on Mon, Jan 14, 2002 at 02:09:16PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro : > But it still leaves you with tristate - instead of yes/module/no it's > yes/yes, but don't put it on initramfs/no. However, dependencies become > simpler - all you need is "I want this, that and that on initramfs" and > the rest can be found by depmod (i.e. configurator doesn't have to deal > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > (== can't be M)"). Actually I think we may no longer be in tristate-land. Instead, some devices have the property "This belongs in initramfs if it's configured at all" -- specifically, drivers for potential boot devices. Everything else can dynamic-load after boot time. In CML2 you can assign a symbol properties, which are written into trailing comments in the config file on the same line as the symbol value assignment. One such property, "PRIVATE", is already interpreted by the postprocessor that generates autoconf.h from the configuration output; it prevents the symbol from being written to autoconf.h. The critical-for-boot property could be interpreted by the same postprocessor script and turned into a manifest for initramfs. There would be no need for the inference engine or configurator to know about this property at all, just as it doesn't need to know anything about PRIVATE. -- Eric S. Raymond "To disarm the people... was the best and most effectual way to enslave them." -- George Mason, speech of June 14, 1788 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:44:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:44:26 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]:11146 "EHLO zcars0m9.ca.nortel.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 15:43:54 -0500 Message-ID: <3C43445D.24D5415F@nortelnetworks.com> Date: Mon, 14 Jan 2002 15:49:33 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Viro Cc: David Lang , Alan Cox , babydr@baby-dragons.com, linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro wrote: > > On Mon, 14 Jan 2002, David Lang wrote: > > > doesn't matter, they are likly to be found on dedicated servers where > > the flexibility of modules is not needed and the slight performance > > advantage is desired. > > > > making everything modular is fine for desktops/laptops but why should > > dedicated servers pay the price? > > There should be no price. And AFAICS that's doable. I haven't been following the initramfs stuff, but now I have a question. Currently we're using initrd to store a kernel and compressed ramdisk bundled together as an ~7MB single file that gets netbooted by firmware in a card. Will it be possible to bundle initramfs together with the kernel into a single file in this same manner? Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:52:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:52:44 -0500 Received: from [208.29.163.248] ([208.29.163.248]:40910 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 15:52:29 -0500 From: David Lang To: "Eric S. Raymond" Cc: Alexander Viro , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Date: Mon, 14 Jan 2002 12:51:23 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114151748.B19776@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org some systems don't want modules to be loaded after boot (yes it's security that can be bypassed, but as long as it's not your only security it's still worth doing) also with hardwired drivers going away does this mean that other things that are currently compiled in will become modules, like say the IP stack? David Lang On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Date: Mon, 14 Jan 2002 15:17:48 -0500 > From: Eric S. Raymond > To: Alexander Viro > Cc: Alan Cox , > Mr. James W. Laferriere , > Giacomo Catenazzi , > Linux Kernel List > Subject: Re: Hardwired drivers are going away? > > Alexander Viro : > > But it still leaves you with tristate - instead of yes/module/no it's > > yes/yes, but don't put it on initramfs/no. However, dependencies become > > simpler - all you need is "I want this, that and that on initramfs" and > > the rest can be found by depmod (i.e. configurator doesn't have to deal > > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > > (== can't be M)"). > > Actually I think we may no longer be in tristate-land. Instead, some > devices have the property "This belongs in initramfs if it's configured > at all" -- specifically, drivers for potential boot devices. Everything > else can dynamic-load after boot time. > > In CML2 you can assign a symbol properties, which are written into > trailing comments in the config file on the same line as the symbol > value assignment. One such property, "PRIVATE", is already > interpreted by the postprocessor that generates autoconf.h from the > configuration output; it prevents the symbol from being written to > autoconf.h. > > The critical-for-boot property could be interpreted by the same > postprocessor script and turned into a manifest for initramfs. There > would be no need for the inference engine or configurator to know > about this property at all, just as it doesn't need to know anything > about PRIVATE. > -- > Eric S. Raymond > > "To disarm the people... was the best and most effectual way to enslave them." > -- George Mason, speech of June 14, 1788 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 15:56:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 15:55:45 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:60060 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 15:55:29 -0500 Date: Mon, 14 Jan 2002 15:55:27 -0500 (EST) From: Alexander Viro To: Chris Friesen cc: David Lang , Alan Cox , babydr@baby-dragons.com, linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: <3C43445D.24D5415F@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, Chris Friesen wrote: > I haven't been following the initramfs stuff, but now I have a question. > Currently we're using initrd to store a kernel and compressed ramdisk bundled > together as an ~7MB single file that gets netbooted by firmware in a card. Will > it be possible to bundle initramfs together with the kernel into a single file > in this same manner? kernel unpacks to rootfs after init_vfs_caches(). It does populate_root(archive_start, archive_size); followed by releasing that area. That's it. If you have these variables set - it will work, no matter how did the archive get there. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 16:10:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 16:10:31 -0500 Received: from pcow034o.blueyonder.co.uk ([195.188.53.122]:42502 "EHLO blueyonder.co.uk") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 16:09:28 -0500 Date: Mon, 14 Jan 2002 20:51:24 +0000 From: Ian Molton To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-Id: <20020114205124.2f05fc56.spyro@armlinux.org> In-Reply-To: In-Reply-To: Reply-To: spyro@armlinux.org Organization: The dragon roost X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On a sunny Mon, 14 Jan 2002 11:44:59 -0800 (PST) David Lang gathered a sheaf of electrons and etched in their motions the following immortal words: > doesn't matter, they are likly to be found on dedicated servers where > the flexibility of modules is not needed and the slight performance > advantage is desired. Exactly WHAT performance advantage? once the module is loaded, its loaded. most modules use the same code to handle modular and non-modular builds anyhow (look at the ide drivers, for example) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:12:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:12:06 -0500 Received: from warden.digitalinsight.com ([208.29.163.2]:36546 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 17:11:58 -0500 Date: Mon, 14 Jan 2002 14:11:48 -0800 (PST) From: David Lang To: Ian Molton cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114205124.2f05fc56.spyro@armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org the impact is in all calls to the module, if they are far calls instead of near calls each and every call is (a hair) slower. so the code can be the same and still be slower to get to. you can argue that it's not enough slower to matter, but even Alan admits there is some impact. David Lang On Mon, 14 Jan 2002, Ian Molton wrote: > Date: Mon, 14 Jan 2002 20:51:24 +0000 > From: Ian Molton > To: linux-kernel@vger.kernel.org > Subject: Re: Hardwired drivers are going away? > > On a sunny Mon, 14 Jan 2002 11:44:59 -0800 (PST) David Lang gathered a > sheaf of electrons and etched in their motions the following immortal > words: > > > doesn't matter, they are likly to be found on dedicated servers where > > the flexibility of modules is not needed and the slight performance > > advantage is desired. > > Exactly WHAT performance advantage? once the module is loaded, its loaded. > most modules use the same code to handle modular and non-modular builds > anyhow (look at the ide drivers, for example) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:19:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:19:04 -0500 Received: from waste.org ([209.173.204.2]:3736 "EHLO waste.org") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 17:19:02 -0500 Date: Mon, 14 Jan 2002 16:18:41 -0600 (CST) From: Oliver Xymoron To: "Eric S. Raymond" cc: Alexander Viro , Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114151748.B19776@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Alexander Viro : > > But it still leaves you with tristate - instead of yes/module/no it's > > yes/yes, but don't put it on initramfs/no. However, dependencies become > > simpler - all you need is "I want this, that and that on initramfs" and > > the rest can be found by depmod (i.e. configurator doesn't have to deal > > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > > (== can't be M)"). > > Actually I think we may no longer be in tristate-land. Instead, some > devices have the property "This belongs in initramfs if it's configured > at all" -- specifically, drivers for potential boot devices. Everything > else can dynamic-load after boot time. The knowledge of what's required to boot can and should be moved out of the kernel to distro land. 'make install' should call the distro's install script that sez /boot and /lib are on ext3 on /dev/sd?, ergo I need to include the ext3 and relevant SCSI modules. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:21:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:21:08 -0500 Received: from femail44.sdc1.sfba.home.com ([24.254.60.38]:12728 "EHLO femail44.sdc1.sfba.home.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 17:21:03 -0500 Content-Type: text/plain; charset=US-ASCII From: Rob Landley To: Alexander Viro , "Eric S. Raymond" Subject: Re: Hardwired drivers are going away? Date: Mon, 14 Jan 2002 09:19:01 -0500 X-Mailer: KMail [version 1.3.1] Cc: Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20020114222101.ZPUW15906.femail44.sdc1.sfba.home.com@there> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Monday 14 January 2002 02:09 pm, Alexander Viro wrote: > But it still leaves you with tristate - instead of yes/module/no it's > yes/yes, but don't put it on initramfs/no. However, dependencies become > simpler - all you need is "I want this, that and that on initramfs" and > the rest can be found by depmod (i.e. configurator doesn't have to deal > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > (== can't be M)"). This is something I've wondered about and would like to ask for clarification on: the relationship between the initramfs image and the kernel, build process-wise. How much of the build process for the initramfs will be integrated with the kernel build? Since the kernel won't boot without a matching initramfs, I take it that some kind of initramfs will be a kernel build target now? There's been a lot of talk about having the source for a mini-libc (uclibc, dietlibc, some combo) in the kernel tree, and other people saying we should just grab the binary for build purposes. The most obvious model I can think of for klibc staying seperate from the kernel is the user-space pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel. The klibc source/binary debate still seems to be ongoing, but apart from that, will the build process for initramfs be part of the kernel build or not? Rob. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:23:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:22:59 -0500 Received: from fly.HiWAAY.net ([208.147.154.56]:24590 "EHLO mail.hiwaay.net") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 17:22:33 -0500 Date: Mon, 14 Jan 2002 16:22:30 -0600 From: Chris Adams To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020114222230.GA16490@HiWAAY.net> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Organization: HiWAAY Internet Services Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article , David Lang wrote: >I can see a couple reasons for building a kernel without useing modules. > >1. security, if you don't need any modules you can disable modules entirly >and then it's impossible to add a module without patching the kernel first >(the module load system calls aren't there) There is no security gain from disabling module loading. If someone has the level of access needed to load modules, they also have access to /dev/mem. Run-time patching of the kernel is something that can be done (and probably is done by some rootkits). For bonus points, patch in the system call(s) required by insmod and voila: module loading now works (instead of having to patch all your rootkit code into the running kernel, patch in insmod and let the kernel load the code for you). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:37:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:37:30 -0500 Received: from 12-224-37-81.client.attbi.com ([12.224.37.81]:12813 "HELO kroah.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 17:36:20 -0500 Date: Mon, 14 Jan 2002 14:33:03 -0800 From: Greg KH To: Rob Landley Cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020114223302.GC22267@kroah.com> In-Reply-To: <20020114222101.ZPUW15906.femail44.sdc1.sfba.home.com@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020114222101.ZPUW15906.femail44.sdc1.sfba.home.com@there> User-Agent: Mutt/1.3.25i X-Operating-System: Linux 2.2.20 (i586) Reply-By: Mon, 17 Dec 2001 20:00:03 -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2002 at 09:19:01AM -0500, Rob Landley wrote: > > The klibc source/binary debate still seems to be ongoing, but apart from > that, will the build process for initramfs be part of the kernel build or not? I would vote for yes. I would like this, if for no other reason than the number of kernel builds most kernel developers do :) I was going to wait until kbuild 2.5 went into the tree before looking at what would be needed to add this to the build process. thanks, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 17:59:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 17:59:25 -0500 Received: from femail35.sdc1.sfba.home.com ([24.254.60.25]:30117 "EHLO femail35.sdc1.sfba.home.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 17:59:18 -0500 Content-Type: text/plain; charset=US-ASCII From: Rob Landley To: esr@thyrsus.com, Alexander Viro Subject: Re: Hardwired drivers are going away? Date: Mon, 14 Jan 2002 09:57:16 -0500 X-Mailer: KMail [version 1.3.1] Cc: Alan Cox , "Mr. James W. Laferriere" , Giacomo Catenazzi , Linux Kernel List In-Reply-To: <20020114131050.E14747@thyrsus.com> <20020114151748.B19776@thyrsus.com> In-Reply-To: <20020114151748.B19776@thyrsus.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20020114225917.YZIK8351.femail35.sdc1.sfba.home.com@there> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Monday 14 January 2002 03:17 pm, Eric S. Raymond wrote: > Alexander Viro : > > But it still leaves you with tristate - instead of yes/module/no it's > > yes/yes, but don't put it on initramfs/no. However, dependencies become > > simpler - all you need is "I want this, that and that on initramfs" and > > the rest can be found by depmod (i.e. configurator doesn't have to deal > > with "FOO goes on initramfs (== old Y), so BAR and BAZ must go there > > (== can't be M)"). > > Actually I think we may no longer be in tristate-land. Instead, some > devices have the property "This belongs in initramfs if it's configured > at all" -- specifically, drivers for potential boot devices. Everything > else can dynamic-load after boot time. No. Just about every block device there is is a POTENTIAL root device. Boot and root devices are seperate things (just as boot and root partitions are seperate things.) Your kernel can decompress from an enternet boot prom if you're clever enough about. You could theoretically have your root device on a USB storage device. Booting from CD-ROM is fairly common, yet not something you normally want your installed kernel to have compiled in. I've even seen kernels that load via tftp, including an initial ram disk, and either never have local storage of any kind or use it purely as swap space. (Why? Really really really easy system administration of multiple terminals in libraries and kiosks and such. It breaks, you drop in a new one (don't even have to image it). No local hard drive liminates the #1 cause of system failure. And there's no way an end-user can screw up its configuration in a way a reboot won't fix.) What's interesting is what devices the root partition IS going to live on and this has NOTHING to do with the device itself. It can be any device any normal partition lives on. You can have IDE and SCSI in the same system. You can have hard drives, CD-ROM drives, and floppies. The fact you can boot off of an IDE cd-rom doesn't mean you will, or that's how you want to configure your kernel. When manually configuring, you select this. And if the autoprober isn't smart enough to figure out what your root device is, it needs to be fixed. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 18:13:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 18:13:05 -0500 Received: from sydney1.au.ibm.com ([202.135.142.193]:31757 "EHLO haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 18:12:49 -0500 Date: Tue, 15 Jan 2002 10:12:56 +1100 From: Rusty Russell To: Alexander Viro Cc: esr@thyrsus.com, alan@lxorguk.ukuu.org.uk, babydr@baby-dragons.com, cate@debian.org, linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-Id: <20020115101256.33f1bafa.rusty@rustcorp.com.au> In-Reply-To: In-Reply-To: <20020114131050.E14747@thyrsus.com> X-Mailer: Sylpheed version 0.6.6 (GTK+ 1.2.10; powerpc-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002 14:09:16 -0500 (EST) Alexander Viro wrote: > Two technical obstacles: > a) on some architecures modular code is slower (IIRC, the problem is > with medium-range calls being faster than far ones and usable only in the > kernel proper). We probaly want to leave a gap after the .text and remap > .text of module in there - if I understand the problem that should be > enough, but that's really a question to folks dealing with these ports (PPC64 > and Itanic?) Sparc64 has a special allocator. PPC32 is not so lucky, and if the module doesn't end up under 32MB we use trampolines (PLT in the ppc parlance). PPC64 has similar issues. > b) current differences between options parsing in case of built-in > and modular drivers. I have a patch for this, of course, but it's tied to my replacement module loader: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/param.patch.bz2 Cheers! Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 18:13:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 18:13:14 -0500 Received: from quark.didntduck.org ([216.43.55.190]:39178 "EHLO quark.didntduck.org") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 18:13:04 -0500 Message-ID: <3C4365EB.5AA2DEA3@didntduck.org> Date: Mon, 14 Jan 2002 18:12:43 -0500 From: Brian Gerst X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Lang CC: Ian Molton , linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org David Lang wrote: > > the impact is in all calls to the module, if they are far calls instead of > near calls each and every call is (a hair) slower. > > so the code can be the same and still be slower to get to. > > you can argue that it's not enough slower to matter, but even Alan admits > there is some impact. > > David Lang Let's get the terminology right here (for x86 at least): Far jump: Changes to a new code segment, absolute address Near jump: Same code segment, 4-byte relative offset Short jump: Same code segment, 1-byte signed offset The kernel never uses far jumps except for some BIOS calls and during booting. The difference betwen near and short jumps is very minute. Short jumps are limited to +/- 128 bytes, so are really only applicable for small loops. All function calls between object files must be near jumps, as the assembler does not not know the distance of an unresolved symbol and must assume the largest possible offset. -- Brian Gerst From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 18:19:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 18:18:10 -0500 Received: from warden.digitalinsight.com ([208.29.163.2]:36004 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 18:17:26 -0500 From: David Lang To: Brian Gerst Cc: Ian Molton , linux-kernel@vger.kernel.org Date: Mon, 14 Jan 2002 15:17:07 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: <3C4365EB.5AA2DEA3@didntduck.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org my apologies for the terminology errors, I was trying to go from memory from the thread here late last year. David Lang On Mon, 14 Jan 2002, Brian Gerst wrote: > Date: Mon, 14 Jan 2002 18:12:43 -0500 > From: Brian Gerst > To: David Lang > Cc: Ian Molton , linux-kernel@vger.kernel.org > Subject: Re: Hardwired drivers are going away? > > David Lang wrote: > > > > the impact is in all calls to the module, if they are far calls instead of > > near calls each and every call is (a hair) slower. > > > > so the code can be the same and still be slower to get to. > > > > you can argue that it's not enough slower to matter, but even Alan admits > > there is some impact. > > > > David Lang > > Let's get the terminology right here (for x86 at least): > Far jump: Changes to a new code segment, absolute address > Near jump: Same code segment, 4-byte relative offset > Short jump: Same code segment, 1-byte signed offset > > The kernel never uses far jumps except for some BIOS calls and during > booting. The difference betwen near and short jumps is very minute. > Short jumps are limited to +/- 128 bytes, so are really only applicable > for small loops. All function calls between object files must be near > jumps, as the assembler does not not know the distance of an unresolved > symbol and must assume the largest possible offset. > > -- > > Brian Gerst > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 18:20:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 18:19:59 -0500 Received: from pcow029o.blueyonder.co.uk ([195.188.53.123]:62219 "EHLO blueyonder.co.uk") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 18:19:10 -0500 Date: Mon, 14 Jan 2002 23:22:47 +0000 From: Ian Molton To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-Id: <20020114232247.195bf441.spyro@armlinux.org> In-Reply-To: In-Reply-To: <20020114205124.2f05fc56.spyro@armlinux.org> Reply-To: spyro@armlinux.org Organization: The dragon roost X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On a sunny Mon, 14 Jan 2002 14:11:48 -0800 (PST) David Lang gathered a sheaf of electrons and etched in their motions the following immortal words: > the impact is in all calls to the module, if they are far calls instead > of near calls each and every call is (a hair) slower. > > so the code can be the same and still be slower to get to. > > you can argue that it's not enough slower to matter, but even Alan admits > there is some impact. Ok, #1 please dont send me courtesy copies without indicating so. #2 Not all architectures have a problem with 'far' or 'near' calls, and frankly, I'm glad the kernels design isnt being crippled just to serve the fundamentally CRAP x86 architecture, for once. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 18:34:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 18:33:54 -0500 Received: from nat-pool-meridian.redhat.com ([12.107.208.200]:31128 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 18:33:50 -0500 Date: Mon, 14 Jan 2002 18:33:46 -0500 From: Pete Zaitcev Message-Id: <200201142333.g0ENXks24669@devserv.devel.redhat.com> To: david.lang@digitalinsight.com Cc: Subject: Re: Hardwired drivers are going away? In-Reply-To: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 3. simplicity in building kernels for other machines. with a monolithic > kernel you have one file to move (and a bootloader to run) with modules > you have to move quite a few more files. It is easy to automate. Simply build RPMs and install them. Die-hard RPM haters may use some ad-hoc tools as well, see: http://people.redhat.com/zaitcev/linux/linux-collect -- Pete From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 19:40:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 19:40:41 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:9489 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 19:40:29 -0500 To: linux-kernel@vger.kernel.org From: "H. Peter Anvin" Subject: Re: Hardwired drivers are going away? Date: 14 Jan 2002 16:40:12 -0800 Organization: Transmeta Corporation, Santa Clara CA Message-ID: In-Reply-To: <20020114205124.2f05fc56.spyro@armlinux.org> <20020114232247.195bf441.spyro@armlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2002 H. Peter Anvin - All Rights Reserved Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Followup to: <20020114232247.195bf441.spyro@armlinux.org> By author: Ian Molton In newsgroup: linux.dev.kernel > > #2 Not all architectures have a problem with 'far' or 'near' calls, and > frankly, I'm glad the kernels design isnt being crippled just to serve the > fundamentally CRAP x86 architecture, for once. > Especially since the x86 *ISN'T* one of the architectures with this particular problem. 'far' and 'near' as used in this thread don't refer to the x86 segmentation crud. -hpa -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 21:59:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 21:59:00 -0500 Received: from science.horizon.com ([192.35.100.1]:49974 "HELO science.horizon.com") by vger.kernel.org with SMTP id ; Mon, 14 Jan 2002 21:58:45 -0500 Date: 15 Jan 2002 02:58:40 -0000 Message-ID: <20020115025840.11509.qmail@science.horizon.com> From: peter@horizon.com To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I don't mind how people do it, but there are currently two significant penalties associated with modules on x86. I think other architectures have analogues. 1) The main kernel is contiguous in physical memory and is mapped with large (4 MB) pages. This reduces pressure on the TLB. Modules are loaded in vmalloc memory, which uses small pages, and therefore competes for TLB space. This is a performance penalty, especially as most current machines have undersized TLBs already. (A 64-entry TLB with 4K pages maps 256K at a time. On-chip L2 caches are this large or larger. Thus, as a crude approximation, every L2 miss also causes a TLB miss.) Also, vmalloc space is limited, and contributes to the "why isn't the kernel seeing all of my 1 GB?" question. 2) Space for module code is allocated in page units. Thus, each module wastes an average of 2K. If I'm going to have dozens of modules loaded, small machines are going to notice. On a related subject, I'd like a kernel image to consist of a series of concatenated "chunks". The first one is the kernel proper, and then come various modules and initrd image(s). (There may be an "EOF" chunk, or just the absence of a magic number.) All the boot loader has to do is copy the image into contiguous memory and jump to it. The start of the image (ideally, it'd be PIC) then relocates itself to wherever it wants and starts assembling the pieces. Whether this is done by a sort of linker before the kernel boots, or if the chunks are all ramdisk components and form a userland that the kernel boots to which assemble the rest of the kernel is not particularly important. I just want the unnecessary bits to get thrown away once we've booted. (Kernel bloat should NOT be designed in.) That would make assembling a custom boot image simple enough for a fancy boot loader (or fancy tftp server) to do. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 05:46:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 05:46:03 -0500 Received: from waldorf.cs.uni-dortmund.de ([129.217.4.42]:31144 "EHLO waldorf.cs.uni-dortmund.de") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 05:45:47 -0500 Message-Id: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de> To: David Lang cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: Message from David Lang of "Mon, 14 Jan 2002 10:57:19 PST." Date: Tue, 15 Jan 2002 11:45:39 +0100 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > On Mon, 14 Jan 2002, Alan Cox wrote: > > > 1. security, if you don't need any modules you can disable modules > > > entirly and then it's impossible to add a module without patching > > > the kernel first (the module load system calls aren't there) > > Urban legend. > If this is the case then why do I get systemcall undefined error messages > when I make a mistake and attempt to load a module on a kernel without > modules enabled? AFAIU the security improvement of no-modules are way overrated. [...] > > > 3. simplicity in building kernels for other machines. with a monolithic > > > kernel you have one file to move (and a bootloader to run) with modules > > > you have to move quite a few more files. > > tar or nfs mount; make modules_install. > not on my firewalls thank you. You keep compilers and stuff on your firewalls then?! I get them over via ssh or by floppy/CD. Same idea. -- Horst von Brand http://counter.li.org # 22616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 05:57:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 05:57:14 -0500 Received: from i030-063.nv.iinet.net.au ([203.59.30.63]:62962 "HELO aeonline.net") by vger.kernel.org with SMTP id ; Tue, 15 Jan 2002 05:56:58 -0500 From: crispin@iinet.net.au Date: Tue, 15 Jan 2002 19:13:05 +0800 To: Horst von Brand , linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020115191305.P1928@earth> In-Reply-To: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de>; from brand@jupiter.cs.uni-dortmund.de on Tue, Jan 15, 2002 at 11:45:39AM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2002 at 11:45:39AM +0100, Horst von Brand wrote: > > On Mon, 14 Jan 2002, Alan Cox wrote: > > > > > 1. security, if you don't need any modules you can disable modules > > > > entirly and then it's impossible to add a module without patching > > > > the kernel first (the module load system calls aren't there) > > > > Urban legend. > > > If this is the case then why do I get systemcall undefined error messages > > when I make a mistake and attempt to load a module on a kernel without > > modules enabled? > > AFAIU the security improvement of no-modules are way overrated. insmod knark.o Crispin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 06:35:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 06:35:28 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:12548 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Tue, 15 Jan 2002 06:35:15 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Rob Landley Cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Mon, 14 Jan 2002 09:19:01 CDT." <20020114222101.ZPUW15906.femail44.sdc1.sfba.home.com@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jan 2002 22:35:03 +1100 Message-ID: <5641.1011094503@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 14 Jan 2002 09:19:01 -0500, Rob Landley wrote: >How much of the build process for the initramfs will be integrated with the >kernel build? Since the kernel won't boot without a matching initramfs, I >take it that some kind of initramfs will be a kernel build target now? > >There's been a lot of talk about having the source for a mini-libc (uclibc, >dietlibc, some combo) in the kernel tree, and other people saying we should >just grab the binary for build purposes. The most obvious model I can think >of for klibc staying seperate from the kernel is the user-space >pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel. > >The klibc source/binary debate still seems to be ongoing, but apart from >that, will the build process for initramfs be part of the kernel build or not? I am in two minds about this (but I am at one with my duality). Part of me says that users will want to tweak the initramfs process and they may want to use different versions of klibc, so klibc and building initramfs should be outside the kernel build. Another part says that users have to build initramfs before doing the install so initramfs and klibc should be part of kbuild. It will probably end up with klibc as part of the kernel tarball supported by kbuild. Generating initramfs will be done by a script, kbuild will supply a sample but users can copy and change the sample to suit their own requirements. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 07:16:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 07:16:11 -0500 Received: from ns.suse.de ([213.95.15.193]:56840 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Tue, 15 Jan 2002 07:16:06 -0500 To: peter@horizon.com Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020115025840.11509.qmail@science.horizon.com.suse.lists.linux.kernel> From: Andi Kleen Date: 15 Jan 2002 13:16:04 +0100 In-Reply-To: peter@horizon.com's message of "15 Jan 2002 04:04:19 +0100" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.6 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org peter@horizon.com writes: > 1) The main kernel is contiguous in physical memory and is mapped with > large (4 MB) pages. This reduces pressure on the TLB. Modules are > loaded in vmalloc memory, which uses small pages, and therefore > competes for TLB space. This is a performance penalty, especially > as most current machines have undersized TLBs already. (A 64-entry > TLB with 4K pages maps 256K at a time. On-chip L2 caches are this > large or larger. Thus, as a crude approximation, every L2 miss also > causes a TLB miss.) -aa tries to load modules into the linear mapping when possible. That usually works when you load the modules early when the memory isn't that fragmented yet. I agree on that trying to put everything into modules isn't a good idea, especially because of your second point. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 07:34:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 07:33:45 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:42255 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 07:32:45 -0500 Subject: Re: Hardwired drivers are going away? To: peter@horizon.com Date: Tue, 15 Jan 2002 12:44:38 +0000 (GMT) Cc: linux-kernel@vger.kernel.org In-Reply-To: <20020115025840.11509.qmail@science.horizon.com> from "peter@horizon.com" at Jan 15, 2002 02:58:40 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 1) The main kernel is contiguous in physical memory and is mapped with > large (4 MB) pages. This reduces pressure on the TLB. Modules are > 2) Space for module code is allocated in page units. Thus, each module > wastes an average of 2K. If I'm going to have dozens of modules > loaded, small machines are going to notice. If at boot time we keep a big chunk of ram free at the kernel end and just load modules one after each other into that space until we get into real paging that problem goes away From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 07:41:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 07:41:01 -0500 Received: from pizda.ninka.net ([216.101.162.242]:15522 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 07:40:49 -0500 Date: Tue, 15 Jan 2002 04:39:11 -0800 (PST) Message-Id: <20020115.043911.21332087.davem@redhat.com> To: alan@lxorguk.ukuu.org.uk Cc: peter@horizon.com, linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? From: "David S. Miller" In-Reply-To: In-Reply-To: <20020115025840.11509.qmail@science.horizon.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org From: Alan Cox Date: Tue, 15 Jan 2002 12:44:38 +0000 (GMT) If at boot time we keep a big chunk of ram free at the kernel end and just load modules one after each other into that space until we get into real paging that problem goes away And we do have module_map/module_unmap interfaces already so it's easy to toy with this. I've always been meaning to do a "alloc 4MB page at boot, lock into TLB, carve module pages out of that, vmalloc when that runs out" on sparc64. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 09:25:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 09:25:33 -0500 Received: from warden.digitalinsight.com ([208.29.163.2]:25047 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Tue, 15 Jan 2002 09:25:20 -0500 Date: Tue, 15 Jan 2002 06:25:07 -0800 (PST) From: David Lang To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org one other thing re: simplicity. bootloaders I know that many of you who are advocating this new approach despise lilo, but for many people it does the job just fine. with the new approach when switching between kernels you now not only need to switch the kernel images, but also the initrd (or equivalent) images. also don't forget that the current way of storing modules can have problems when some kernel comile options change (SMP for example, but IIRC there are others) if you make modules mandatory you will have to fix this first. David Lang > > > > > 3. simplicity in building kernels for other machines. with a monolithic > > > > kernel you have one file to move (and a bootloader to run) with modules > > > > you have to move quite a few more files. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 10:35:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 10:35:20 -0500 Received: from waste.org ([209.173.204.2]:65230 "EHLO waste.org") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 10:35:02 -0500 Date: Tue, 15 Jan 2002 09:34:37 -0600 (CST) From: Oliver Xymoron To: Keith Owens cc: Rob Landley , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <5641.1011094503@ocs3.intra.ocs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Jan 2002, Keith Owens wrote: > On Mon, 14 Jan 2002 09:19:01 -0500, > Rob Landley wrote: > >How much of the build process for the initramfs will be integrated with the > >kernel build? Since the kernel won't boot without a matching initramfs, I > >take it that some kind of initramfs will be a kernel build target now? > > > >There's been a lot of talk about having the source for a mini-libc (uclibc, > >dietlibc, some combo) in the kernel tree, and other people saying we should > >just grab the binary for build purposes. The most obvious model I can think > >of for klibc staying seperate from the kernel is the user-space > >pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel. > > > >The klibc source/binary debate still seems to be ongoing, but apart from > >that, will the build process for initramfs be part of the kernel build or not? > > I am in two minds about this (but I am at one with my duality). Part > of me says that users will want to tweak the initramfs process and they > may want to use different versions of klibc, so klibc and building > initramfs should be outside the kernel build. Another part says that > users have to build initramfs before doing the install so initramfs and > klibc should be part of kbuild. > > It will probably end up with klibc as part of the kernel tarball > supported by kbuild. Generating initramfs will be done by a script, > kbuild will supply a sample but users can copy and change the sample to > suit their own requirements. Better yet, we should do away with all install targets beyond assembling the bootable images and provide sample install scripts in /scripts. Most of it is already at odds with the distro's install and the remainder becomes a maintenance issue with initramfs. Distro folks are going to be working on initramfs-libc for their boot disks anyway and will undoubted want to tweak such stuff greatly. Let's include Viro's minimal-userspace-boot.c in scripts along with a build-minimal-initramfs.sh and leave it at that. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 12:24:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 12:24:28 -0500 Received: from vitelus.com ([64.81.243.207]:56846 "EHLO vitelus.com") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 12:24:15 -0500 Date: Tue, 15 Jan 2002 09:24:13 -0800 From: Aaron Lehmann To: David Lang Cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020115172413.GD7030@vitelus.com> In-Reply-To: <20020114131050.E14747@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2002 at 10:50:20AM -0800, David Lang wrote: > I can see a couple reasons for building a kernel without useing modules. I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain bad. It will require an initrd (initramfs, or whatever), and force kernel installation to be more difficult. The performance overhead sounds like a major downside, epsecially when currently people know what hardware they have and build things into the kernel accordingly. Between this and CML2, my mental image of 2.5+ is starting to look very grim. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 12:27:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 12:27:47 -0500 Received: from vitelus.com ([64.81.243.207]:58126 "EHLO vitelus.com") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 12:27:41 -0500 Date: Tue, 15 Jan 2002 09:27:29 -0800 From: Aaron Lehmann To: Alan Cox Cc: "Mr. James W. Laferriere" , Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020115172729.GE7030@vitelus.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote: > Not generally found in your grandmothers PC What kind of an argument is this?!? Linux developers used to care about portability to and performance on non-x86 platforms. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 12:47:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 12:47:20 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:32231 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 12:47:10 -0500 Date: Tue, 15 Jan 2002 12:47:09 -0500 (EST) From: Alexander Viro To: Aaron Lehmann cc: Alan Cox , "Mr. James W. Laferriere" , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020115172729.GE7030@vitelus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Jan 2002, Aaron Lehmann wrote: > On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote: > > Not generally found in your grandmothers PC > > What kind of an argument is this?!? Linux developers used to care > about portability to and performance on non-x86 platforms. Guys, could you lay off whatever the fuck you are smoking? And I mean everybody involved. * autoconfig is part of ESR's wet dream. Ignore him and he'll go away. * Aunt Tillie and her magical mistery whorehouse <<--->> * performance problems with modules are real, need to be solved and can be solved. * disabling module loading doesn't buy any security. * it's easy to make irrevertible disabling modules _after_ boot. * initramfs is independent from modules * it is _not_ initrd or an analog * it doesn't involve a shitload of extra files * it removes tons of crap from kernel * it allows to simplify build process and get rid of quite a few sources of bugs, _if_ performance problems with modules are solved Now could we fscking drop these threads? Or at least take care to separate myths from reality before posting more crap. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 13:18:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 13:17:58 -0500 Received: from warden.digitalinsight.com ([208.29.163.2]:62453 "HELO warden.diginsite.com") by vger.kernel.org with SMTP id ; Tue, 15 Jan 2002 13:17:39 -0500 From: David Lang To: Aaron Lehmann Cc: Linux Kernel List Date: Tue, 15 Jan 2002 10:17:29 -0800 (PST) Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020115172413.GD7030@vitelus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org CML2 is a tradeoff in the kernel config process. it (currently) trades time for correctness. It has no effect after you have built the kernel. I like this becouse there have been several times where I have had to go on a scavanger hunt to figure out what option I need to turn on before I can turn on another option (something that CML2 will fix) as for the kbuild 2.5 performance 'penalty', is it really slower then always doign make dep; make clean; make bzImage? Yes I know I don't always have to do that, but I don't understand the rules as to when I do and when I don't (they sound simple at first but there keep being exceptions raised). having the new kernel build process always get this right is valuble. also the time penalties associated with these two options is something that can (and will) be dealt with over time as they get optimized and rewritten to be faster. these are VERY different from the modules thing which is permanently introducing additional penalties into the system that can affect it for as long as it's running. David Lang On Tue, 15 Jan 2002, Aaron Lehmann wrote: > On Mon, Jan 14, 2002 at 10:50:20AM -0800, David Lang wrote: > > I can see a couple reasons for building a kernel without useing modules. > > I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain > bad. It will require an initrd (initramfs, or whatever), and force > kernel installation to be more difficult. The performance overhead > sounds like a major downside, epsecially when currently people know > what hardware they have and build things into the kernel accordingly. > > Between this and CML2, my mental image of 2.5+ is starting to look > very grim. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 14:25:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 14:25:48 -0500 Received: from vitelus.com ([64.81.243.207]:59407 "EHLO vitelus.com") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 14:25:37 -0500 Date: Tue, 15 Jan 2002 11:25:36 -0800 From: Aaron Lehmann To: David Lang Cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020115192535.GB10174@vitelus.com> In-Reply-To: <20020115172413.GD7030@vitelus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2002 at 10:17:29AM -0800, David Lang wrote: > CML2 is a tradeoff in the kernel config process. it (currently) trades > time for correctness. It has no effect after you have built the kernel. My gripe is more that I find it ugly. I'm very used to the menuconfig appearance, and I do not appreciate the interface change. And (we've been through this before) I am *NOT* going to install yet another language runtime just to configure a kernel. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 14:37:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 14:37:00 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:25348 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 14:36:40 -0500 Subject: Re: Hardwired drivers are going away? To: aaronl@vitelus.com (Aaron Lehmann) Date: Tue, 15 Jan 2002 19:48:17 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), babydr@baby-dragons.com (Mr. James W. Laferriere), linux-kernel@vger.kernel.org (Linux Kernel List) In-Reply-To: <20020115172729.GE7030@vitelus.com> from "Aaron Lehmann" at Jan 15, 2002 09:27:29 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > On Mon, Jan 14, 2002 at 07:17:46PM +0000, Alan Cox wrote: > > Not generally found in your grandmothers PC > > What kind of an argument is this?!? Linux developers used to care > about portability to and performance on non-x86 platforms. Read the entire thread (I know thats like asking you to read war and peace) but if you've not read it in context you will misunderstand arguments (as you do above). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 16:31:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 16:31:11 -0500 Received: from khms.westfalen.de ([62.153.201.243]:16873 "EHLO khms.westfalen.de") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 16:31:07 -0500 Date: 15 Jan 2002 21:44:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: linux-kernel@vger.kernel.org Message-ID: <8Gu-Kwrmw-B@khms.westfalen.de> In-Reply-To: <20020115172413.GD7030@vitelus.com> Subject: Re: Hardwired drivers are going away? X-Mailer: CrossPoint v3.12d.kh8 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? In-Reply-To: <20020114131050.E14747@thyrsus.com> <20020115172413.GD7030@vitelus.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org aaronl@vitelus.com (Aaron Lehmann) wrote on 15.01.02 in <20020115172413.GD7030@vitelus.com>: > I agree with all of yours. IMHO, the proposed scheme for 2.5 is plain > bad. It will require an initrd (initramfs, or whatever), and force > kernel installation to be more difficult. The performance overhead > sounds like a major downside, epsecially when currently people know > what hardware they have and build things into the kernel accordingly. Installation more difficult? Significant performance overhead? What *are* you smoking? MfG Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 22:41:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 22:41:43 -0500 Received: from femail12.sdc1.sfba.home.com ([24.0.95.108]:10942 "EHLO femail12.sdc1.sfba.home.com") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 22:41:30 -0500 Content-Type: text/plain; charset=US-ASCII From: Rob Landley To: "David S. Miller" , alan@lxorguk.ukuu.org.uk Subject: Re: Hardwired drivers are going away? Date: Tue, 15 Jan 2002 13:39:48 -0500 X-Mailer: KMail [version 1.3.1] Cc: peter@horizon.com, linux-kernel@vger.kernel.org In-Reply-To: <20020115025840.11509.qmail@science.horizon.com> <20020115.043911.21332087.davem@redhat.com> In-Reply-To: <20020115.043911.21332087.davem@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20020116034129.CRCX26021.femail12.sdc1.sfba.home.com@there> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 15 January 2002 07:39 am, David S. Miller wrote: > From: Alan Cox > Date: Tue, 15 Jan 2002 12:44:38 +0000 (GMT) > > If at boot time we keep a big chunk of ram free at the kernel end and > just load modules one after each other into that space until we get into > real paging that problem goes away > > And we do have module_map/module_unmap interfaces already so it's > easy to toy with this. > > I've always been meaning to do a "alloc 4MB page at boot, lock into > TLB, carve module pages out of that, vmalloc when that runs out" on > sparc64. How would this handle modules being unloaded? Are you going to try to pack the space, try to re-use the holes (allowing fragmentation), handle unloading the last module only (high water mark), or just ignore it and basically not allow modules to ever be unloaded? Just curious... Rob From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 16 Jan 2002 04:10:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 16 Jan 2002 04:10:06 -0500 Received: from waldorf.cs.uni-dortmund.de ([129.217.4.42]:43662 "EHLO waldorf.cs.uni-dortmund.de") by vger.kernel.org with ESMTP id ; Wed, 16 Jan 2002 04:09:48 -0500 Message-Id: <200201151920.g0FJK09j002000@tigger.cs.uni-dortmund.de> To: "Eric S. Raymond" , Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: Message from "Eric S. Raymond" of "Mon, 14 Jan 2002 15:17:48 EST." <20020114151748.B19776@thyrsus.com> Date: Tue, 15 Jan 2002 20:20:00 +0100 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" said: [...] > Actually I think we may no longer be in tristate-land. Instead, some > devices have the property "This belongs in initramfs if it's configured > at all" -- specifically, drivers for potential boot devices. Everything > else can dynamic-load after boot time. Then all SCSI drivers end up in the initramfs for the install kernel for a distro? There might be _many_ devices configured that don't need to reside on the initramfs. OTOH, the initramfs will get built and populated by separate tools (just like initrd is done today), so the alternatives would boil down to M/N. _If_ the grand scheme of getting rid of builtins flies. I for one wouldn't hold my breath. -- Horst von Brand http://counter.li.org # 22616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 16 Jan 2002 04:17:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 16 Jan 2002 04:17:04 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:25728 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Wed, 16 Jan 2002 04:16:18 -0500 Date: Wed, 16 Jan 2002 04:00:31 -0500 From: "Eric S. Raymond" To: Horst von Brand Cc: Linux Kernel List Subject: Re: Hardwired drivers are going away? Message-ID: <20020116040031.A3445@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Horst von Brand , Linux Kernel List In-Reply-To: <200201151920.g0FJK09j002000@tigger.cs.uni-dortmund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200201151920.g0FJK09j002000@tigger.cs.uni-dortmund.de>; from brand@jupiter.cs.uni-dortmund.de on Tue, Jan 15, 2002 at 08:20:00PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Horst von Brand : > > Actually I think we may no longer be in tristate-land. Instead, some > > devices have the property "This belongs in initramfs if it's configured > > at all" -- specifically, drivers for potential boot devices. Everything > > else can dynamic-load after boot time. > > Then all SCSI drivers end up in the initramfs for the install kernel for > a distro? There might be _many_ devices configured that don't need to > reside on the initramfs. No worries. I have working code for a better approach now. It turns out not to be that hard to discover the root device, controller, and bus. -- Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 Jan 2002 07:41:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 Jan 2002 07:41:15 -0500 Received: from mail.cert.uni-stuttgart.de ([129.69.16.17]:11447 "HELO Mail.CERT.Uni-Stuttgart.DE") by vger.kernel.org with SMTP id ; Fri, 18 Jan 2002 07:41:04 -0500 To: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: From: Florian Weimer Date: Fri, 18 Jan 2002 13:39:01 +0100 In-Reply-To: ("Mr. James W. Laferriere"'s message of "Mon, 14 Jan 2002 14:00:01 -0500 (EST)") Message-ID: <87sn93zvdm.fsf@CERT.Uni-Stuttgart.DE> User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Mr. James W. Laferriere" writes: > Hello Alan , > > On Mon, 14 Jan 2002, Alan Cox wrote: >> > 1. security, if you don't need any modules you can disable modules entirly >> > and then it's impossible to add a module without patching the kernel first >> > (the module load system calls aren't there) >> >> Urban legend. > I do not agree . Got proof ? Yes that is a valid question . http://www.phrack.org/phrack/58/p58-0x07 Globally preloading a shared library in user space is almost as effective, BTW, unless your critical binaries are linked statically (which is unusual on most systems nowadays). -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 Jan 2002 17:21:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 Jan 2002 17:20:51 -0500 Received: from ns1.baby-dragons.com ([199.33.245.254]:22923 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Fri, 18 Jan 2002 17:20:37 -0500 Date: Fri, 18 Jan 2002 17:20:02 -0500 (EST) From: "Mr. James W. Laferriere" To: Florian Weimer cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: <87sn93zvdm.fsf@CERT.Uni-Stuttgart.DE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello Florian , On Fri, 18 Jan 2002, Florian Weimer wrote: > "Mr. James W. Laferriere" writes: > > Hello Alan , > > On Mon, 14 Jan 2002, Alan Cox wrote: > >> > 1. security, if you don't need any modules you can disable modules entirly > >> > and then it's impossible to add a module without patching the kernel first > >> > (the module load system calls aren't there) > >> Urban legend. > > I do not agree . Got proof ? Yes that is a valid question . > http://www.phrack.org/phrack/58/p58-0x07 Thank you for the pointer . Fine you do not need to allow modules in order for a hacker to insert their code . It is still another thing to allow modules & not put & use signatures on them . AFAIK Linux doesn't have a method to load encrypted & signed modules at this time . Please , someone prove me wrong . I -personally- like statically compiled kernels . The method being pushed forth at present doesn't allow that , Unless I am completely mistaken about what Alan & the rest have been discussing . Again PLEASE someone prove me wrong about this also . > Globally preloading a shared library in user space is almost as > effective, BTW, unless your critical binaries are linked statically > (which is unusual on most systems nowadays). I can beleive that 8-} . Statically or written to readonly media or the drive hard set to readonly ;-) . I have followed most of Alan's suggestions security concerns over the years & a few that I thought of along the way . Which later I found had been being done alot longer than I would have thought . Tia , JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 18 Jan 2002 18:23:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 18 Jan 2002 18:23:10 -0500 Received: from mail.ocs.com.au ([203.34.97.2]:9995 "HELO mail.ocs.com.au") by vger.kernel.org with SMTP id ; Fri, 18 Jan 2002 18:22:53 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Mr. James W. Laferriere" Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Fri, 18 Jan 2002 17:20:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jan 2002 10:22:43 +1100 Message-ID: <14160.1011396163@ocs3.intra.ocs.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Jan 2002 17:20:02 -0500 (EST), "Mr. James W. Laferriere" wrote: > Linux doesn't have a method to load encrypted & signed modules at > this time . And never will. Who loads the module - root. Who maintains the list of signatures - root. Who controls the code that verifies the signature - root. Your task Jim, should you choose to accept it, is to make the kernel distinguish between a good use of root and a malicious use by some who has broken in and got root privileges. When you can do that, then we can add signed modules. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 19:44:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 19:43:52 -0500 Received: from mail3.home.nl ([213.51.129.227]:3052 "EHLO mail3.home.nl") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 19:43:40 -0500 From: Frank van de Pol Date: Mon, 21 Jan 2002 00:20:41 +0100 To: Keith Owens Cc: "Mr. James W. Laferriere" , linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020121002041.B1958@idefix.fvdpol.home.nl> In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.23i X-Operating-System: Linux 2.4.13-ac4 i686 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote: > On Fri, 18 Jan 2002 17:20:02 -0500 (EST), > "Mr. James W. Laferriere" wrote: > > Linux doesn't have a method to load encrypted & signed modules at > > this time . > > And never will. Who loads the module - root. Who maintains the list > of signatures - root. Who controls the code that verifies the > signature - root. > > Your task Jim, should you choose to accept it, is to make the kernel > distinguish between a good use of root and a malicious use by some who > has broken in and got root privileges. When you can do that, then we > can add signed modules. > If you want to secure your box, why don't you simply put a lock on it and throw away the key? Really, what might help the paranoid admins in this case is a setting in the kernel which basically disables the ability to load or unload modules. Of course once set this setting can not been turned with rebooting the box. Frank. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol@home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 19:55:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 19:55:31 -0500 Received: from pl100.nas921.ichikawa.nttpc.ne.jp ([210.165.234.100]:14881 "EHLO mbr.sphere.ne.jp") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 19:55:21 -0500 Date: Mon, 21 Jan 2002 09:54:58 +0900 From: Bruce Harada To: Frank van de Pol Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-Id: <20020121095458.2bd9c7ed.bruce@ask.ne.jp> In-Reply-To: <20020121002041.B1958@idefix.fvdpol.home.nl> In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> <20020121002041.B1958@idefix.fvdpol.home.nl> X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.6; i686-pc-linux-gnu) X-Face: $qrUU,Lz=B[A}i%m2Rg^Ik;~V@]$Ay)$S`wUf3:^aZ1UdLf,_;1y7_xbEh=Yv*wB0=Fv]a1hj14_qQsl[f1KX]q4IdhwmSIeP6>Ap@[e$c$G;;ObLI7?YXsq*)M'3Jp wrote: > If you want to secure your box, why don't you simply put a lock on it and > throw away the key? Really, what might help the paranoid admins in this case > is a setting in the kernel which basically disables the ability to load or > unload modules. Of course once set this setting can not been turned with > rebooting the box. ...and how would you guarantee that this setting remains set, in the face of some nasty little cracker screwing around with /dev/kmem? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 20:05:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 20:04:52 -0500 Received: from red.csi.cam.ac.uk ([131.111.8.70]:56196 "EHLO red.csi.cam.ac.uk") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 20:04:42 -0500 Message-Id: <5.1.0.14.2.20020121010328.02672020@pop.cus.cam.ac.uk> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 21 Jan 2002 01:06:41 +0000 To: Frank van de Pol From: Anton Altaparmakov Subject: Re: Hardwired drivers are going away? Cc: Keith Owens , "Mr. James W. Laferriere" , linux-kernel@vger.kernel.org In-Reply-To: <20020121002041.B1958@idefix.fvdpol.home.nl> In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> <14160.1011396163@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At 23:20 20/01/02, Frank van de Pol wrote: >On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote: > > On Fri, 18 Jan 2002 17:20:02 -0500 (EST), > > "Mr. James W. Laferriere" wrote: > > > Linux doesn't have a method to load encrypted & signed modules at > > > this time . > > > > And never will. Who loads the module - root. Who maintains the list > > of signatures - root. Who controls the code that verifies the > > signature - root. > > > > Your task Jim, should you choose to accept it, is to make the kernel > > distinguish between a good use of root and a malicious use by some who > > has broken in and got root privileges. When you can do that, then we > > can add signed modules. > >If you want to secure your box, why don't you simply put a lock on it and >throw away the key? Really, what might help the paranoid admins in this case >is a setting in the kernel which basically disables the ability to load or >unload modules. Of course once set this setting can not been turned with >rebooting the box. Er that sounds like just disabling modules in the kernel altogether (kernel compile option exists for this since the beginning of time)... I do that on all servers I control. Not only for security reasons but also because I suspect it produces smaller and probably faster kernels (I haven't tested this in any way, just a guess). Best regards, Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 20:08:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 20:08:22 -0500 Received: from ns1.baby-dragons.com ([199.33.245.254]:18830 "EHLO filesrv1.baby-dragons.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 20:08:12 -0500 Date: Sun, 20 Jan 2002 20:07:12 -0500 (EST) From: "Mr. James W. Laferriere" To: Anton Altaparmakov cc: Frank van de Pol , Keith Owens , Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: <5.1.0.14.2.20020121010328.02672020@pop.cus.cam.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello Anton , On Mon, 21 Jan 2002, Anton Altaparmakov wrote: > At 23:20 20/01/02, Frank van de Pol wrote: > >On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote: > > > On Fri, 18 Jan 2002 17:20:02 -0500 (EST), > > > "Mr. James W. Laferriere" wrote: > > > > Linux doesn't have a method to load encrypted & signed modules at > > > > this time . > > > And never will. Who loads the module - root. Who maintains the list > > > of signatures - root. Who controls the code that verifies the > > > signature - root. > > > Your task Jim, should you choose to accept it, is to make the kernel > > > distinguish between a good use of root and a malicious use by some who > > > has broken in and got root privileges. When you can do that, then we > > > can add signed modules. > >If you want to secure your box, why don't you simply put a lock on it and > >throw away the key? Really, what might help the paranoid admins in this case > >is a setting in the kernel which basically disables the ability to load or > >unload modules. Of course once set this setting can not been turned with > >rebooting the box. > Er that sounds like just disabling modules in the kernel altogether (kernel > compile option exists for this since the beginning of time)... I do that on > all servers I control. Not only for security reasons but also because I > suspect it produces smaller and probably faster kernels (I haven't tested > this in any way, just a guess). This is just what the Heads are trying to do away with . There will only be module enabled kernels . JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 20:29:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 20:29:04 -0500 Received: from red.csi.cam.ac.uk ([131.111.8.70]:15238 "EHLO red.csi.cam.ac.uk") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 20:28:53 -0500 Message-Id: <5.1.0.14.2.20020121012849.02675c90@pop.cus.cam.ac.uk> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 21 Jan 2002 01:31:20 +0000 To: "Mr. James W. Laferriere" From: Anton Altaparmakov Subject: Re: Hardwired drivers are going away? Cc: Frank van de Pol , Keith Owens , Linux Kernel Maillist In-Reply-To: In-Reply-To: <5.1.0.14.2.20020121010328.02672020@pop.cus.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At 01:07 21/01/02, Mr. James W. Laferriere wrote: >On Mon, 21 Jan 2002, Anton Altaparmakov wrote: > > At 23:20 20/01/02, Frank van de Pol wrote: > > >On Sat, Jan 19, 2002 at 10:22:43AM +1100, Keith Owens wrote: > > > > On Fri, 18 Jan 2002 17:20:02 -0500 (EST), > > > > "Mr. James W. Laferriere" wrote: > > > > > Linux doesn't have a method to load encrypted & signed modules at > > > > > this time . > > > > And never will. Who loads the module - root. Who maintains the list > > > > of signatures - root. Who controls the code that verifies the > > > > signature - root. > > > > Your task Jim, should you choose to accept it, is to make the kernel > > > > distinguish between a good use of root and a malicious use by some who > > > > has broken in and got root privileges. When you can do that, then we > > > > can add signed modules. > > >If you want to secure your box, why don't you simply put a lock on it and > > >throw away the key? Really, what might help the paranoid admins in > this case > > >is a setting in the kernel which basically disables the ability to load or > > >unload modules. Of course once set this setting can not been turned with > > >rebooting the box. > > > Er that sounds like just disabling modules in the kernel altogether (kernel > > compile option exists for this since the beginning of time)... I do that on > > all servers I control. Not only for security reasons but also because I > > suspect it produces smaller and probably faster kernels (I haven't tested > > this in any way, just a guess). > This is just what the Heads are trying to do away with . There > will only be module enabled kernels . JimL Ah! Serves me right for jumping into a thread without reading the previous posts... I better shut up as I have no idea why this is being done. From my unknowledgeable point of view it seems daft but there probably are good reasons... I suppose even non-modular kernels can be modified by the root user to be exploited, it's just a little bit harder... Best regards, Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 20:37:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 20:36:54 -0500 Received: from vasquez.zip.com.au ([203.12.97.41]:7696 "EHLO vasquez.zip.com.au") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 20:36:43 -0500 Message-ID: <3C4B6F24.C2750F51@zip.com.au> Date: Sun, 20 Jan 2002 17:30:12 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Mr. James W. Laferriere" CC: Anton Altaparmakov , Frank van de Pol , Keith Owens , Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: <5.1.0.14.2.20020121010328.02672020@pop.cus.cam.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Mr. James W. Laferriere" wrote: > > This is just what the Heads are trying to do away with . There > will only be module enabled kernels . JimL I suspect none of these "Heads" spend much time in protracted email debug sessions. Because the *first* thing you do is ask the tester to compile the relevant driver into the kernel. The problems which the removal of this option will cause include: 1: Inability to look up symbols in the kernel elf image. 2: Breaks the kernel profiler 3: breaks kgdb 4: breaks ksymoops. How often have we seen nonsensical backtraces here because modules were involved? Possibly we can include a table of module base addresses in the Oops output and teach ksymoops about it. This proposal is, frankly, brain-damaged. It will significantly impeded kernel developers in remote problem diagnosis and it will weaken the kernel development toolchain. There's a lot of work to be done to overcome this damage, and given the difficulty of getting debug tools into the mainstream kernel, the damage may well be permanent. - From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 20:54:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 20:53:51 -0500 Received: from zok.SGI.COM ([204.94.215.101]:56709 "EHLO zok.sgi.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 20:53:40 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Andrew Morton Cc: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 17:30:12 -0800." <3C4B6F24.C2750F51@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2002 12:53:28 +1100 Message-ID: <32505.1011578008@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 Jan 2002 17:30:12 -0800, Andrew Morton wrote: >I suspect none of these "Heads" spend much time in protracted >email debug sessions. Because the *first* thing you do is >ask the tester to compile the relevant driver into the >kernel. > >The problems which the removal of this option will cause include: > >1: Inability to look up symbols in the kernel elf image. >2: Breaks the kernel profiler >3: breaks kgdb >4: breaks ksymoops. > >How often have we seen nonsensical backtraces here because >modules were involved? Possibly we can include a table >of module base addresses in the Oops output and teach ksymoops >about it. You see nonsensical backtraces because people persist in using the oops decode option of klogd which is broken when faced with modules. Turn off klogd oops (klogd -x) and you get a raw backtrace which ksymoops can handle. Guess why these entries are in /proc/ksyms? c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs] c48a0000 __insmod_3c589_cs_O/lib/modules/2.4.17-xfs/kernel/drivers/net/pcmcia/3c589_cs.o_M3C332CFF_V132113 [3c589_cs] c48a22a0 __insmod_3c589_cs_S.data_L96 [3c589_cs] c48a1820 __insmod_3c589_cs_S.rodata_L1152 [3c589_cs] c48a0060 __insmod_3c589_cs_S.text_L6064 [3c589_cs] ksymoops uses the __insmod entries to work out exactly where each module is, it gives an accurate backtrace with modules. man insmod for details. Kernel debuggers like kgdb and kdb use kallsyms which has full support for modules. kgdb can also use the __insmod entries in /proc/ksyms to tell gdb where each module was loaded. ksymoops has a save map option (-s) which writes out the combined system map, including the kernel and all symbols from all modules. Sure, a dynamic system requires a little more work, but it has all been done. Just kill the broken klogd code so it stops corrupting log data. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 21:10:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 21:10:26 -0500 Received: from vasquez.zip.com.au ([203.12.97.41]:31500 "EHLO vasquez.zip.com.au") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 21:10:18 -0500 Message-ID: <3C4B7710.6C518006@zip.com.au> Date: Sun, 20 Jan 2002 18:04:00 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 17:30:12 -0800." <3C4B6F24.C2750F51@zip.com.au> <32505.1011578008@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keith Owens wrote: > > On Sun, 20 Jan 2002 17:30:12 -0800, > Andrew Morton wrote: > >I suspect none of these "Heads" spend much time in protracted > >email debug sessions. Because the *first* thing you do is > >ask the tester to compile the relevant driver into the > >kernel. > > > >The problems which the removal of this option will cause include: > > > >1: Inability to look up symbols in the kernel elf image. > >2: Breaks the kernel profiler > >3: breaks kgdb > >4: breaks ksymoops. > > > >How often have we seen nonsensical backtraces here because > >modules were involved? Possibly we can include a table > >of module base addresses in the Oops output and teach ksymoops > >about it. > > You see nonsensical backtraces because people persist in using the oops > decode option of klogd which is broken when faced with modules. Turn > off klogd oops (klogd -x) and you get a raw backtrace which ksymoops > can handle. ksymoops doesn't know what modules were loaded at the time of the crash, and it doesn't know where they were loaded. The `klogd -x' problem has been with us for *years* and distributors still persist in turning it on. > Guess why these entries are in /proc/ksyms? > > c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs] > c48a0000 __insmod_3c589_cs_O/lib/modules/2.4.17-xfs/kernel/drivers/net/pcmcia/3c589_cs.o_M3C332CFF_V132113 [3c589_cs] > c48a22a0 __insmod_3c589_cs_S.data_L96 [3c589_cs] > c48a1820 __insmod_3c589_cs_S.rodata_L1152 [3c589_cs] > c48a0060 __insmod_3c589_cs_S.text_L6064 [3c589_cs] > > ksymoops uses the __insmod entries to work out exactly where each > module is, it gives an accurate backtrace with modules. man insmod for > details. It assumes too much. Arjan has a kksymoops thingy which does the symbol resolution at crash-time. This seems much more reliable to me. It also handles the common case where the running vmlinux/System.map/etc no longer exist. > Kernel debuggers like kgdb and kdb use kallsyms which has full support > for modules. kgdb can also use the __insmod entries in /proc/ksyms to > tell gdb where each module was loaded. > > ksymoops has a save map option (-s) which writes out the combined > system map, including the kernel and all symbols from all modules. > > Sure, a dynamic system requires a little more work, but it has all been > done. Just kill the broken klogd code so it stops corrupting log data. Keith, I have spent a *lot* of time working weird kernel bugs with people via email. Usually, things peter out simply because the other party lacks the expertise or time to keep on doing things. So the bug doesn't get fixed. I would prefer that all this become easier, simpler and more reliable. We need a damn good reason for deprecating statically linked kernels and certainly none has been presented yet. - From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 21:11:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 21:11:37 -0500 Received: from serenity.mcc.ac.uk ([130.88.200.93]:18180 "EHLO serenity.mcc.ac.uk") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 21:11:23 -0500 Date: Mon, 21 Jan 2002 02:13:55 +0000 From: John Levon To: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? Message-ID: <20020121021355.GA60801@compsoc.man.ac.uk> In-Reply-To: <3C4B6F24.C2750F51@zip.com.au> <32505.1011578008@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32505.1011578008@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.25i X-Url: http://www.movementarian.org/ X-Record: Bendik Singers - Afrotid X-Toppers: N/A Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote: > >How often have we seen nonsensical backtraces here because > >modules were involved? Possibly we can include a table > >of module base addresses in the Oops output and teach ksymoops > >about it. > > You see nonsensical backtraces because people persist in using the oops > decode option of klogd which is broken when faced with modules. Turn > off klogd oops (klogd -x) and you get a raw backtrace which ksymoops > can handle. Guess why these entries are in /proc/ksyms? > > c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs] and quite often the user has unloaded / loaded modules in the meantime and the oops is useless. It would be nice if klogd's oops detection just passed everything to ksymoops untouched, and stored everything somewhere using -m I don't see any reason why the internal profiler can't have an extended EIP range to catch module samples either. Perhaps I'm missing something. Perhaps no one cares enough ... regards john -- "I hope you will find the courage to keep on living despite the existence of this feature." - Richard Stallman From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 21:25:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 21:25:41 -0500 Received: from zok.SGI.COM ([204.94.215.101]:31623 "EHLO zok.sgi.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 21:25:30 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Andrew Morton Cc: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 18:04:00 -0800." <3C4B7710.6C518006@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2002 13:25:18 +1100 Message-ID: <324.1011579918@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 Jan 2002 18:04:00 -0800, Andrew Morton wrote: >ksymoops doesn't know what modules were loaded at the time >of the crash, and it doesn't know where they were loaded. /var/log/ksymoops. man insmod and look for ksymoops assistance. >The `klogd -x' problem has been with us for *years* and >distributors still persist in turning it on. Tell me about it :(. >It assumes too much. Arjan has a kksymoops thingy which does the symbol >resolution at crash-time. It can only get symbols that are in /proc/ksyms, i.e. the exported symbols. Proper crash analysis needs the full symbol table. >It also >handles the common case where the running vmlinux/System.map/etc no longer >exist. So does ksymoops, with reduced detail because it only has exported symbols. >I would prefer that all this become easier, simpler and more reliable. >We need a damn good reason for deprecating statically linked kernels >and certainly none has been presented yet. That is a different problem. Saying that modular kernels cause problems for debugging is not a good enough reason to deprecate modular kernels, all the problems have been solved. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 21:31:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 21:31:21 -0500 Received: from rj.sgi.com ([204.94.215.100]:30358 "EHLO rj.sgi.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 21:31:11 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: John Levon Cc: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Mon, 21 Jan 2002 02:13:55 -0000." <20020121021355.GA60801@compsoc.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2002 13:31:00 +1100 Message-ID: <386.1011580260@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 Jan 2002 02:13:55 +0000, John Levon wrote: >On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote: >> Guess why these entries are in /proc/ksyms? >> >> c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs] > >and quite often the user has unloaded / loaded modules in the meantime >and the oops is useless. /var/log/ksymoops. I added the code and documented it nicely, man insmod or ksymoops. It's not my fault if nobody reads the docs! >It would be nice if klogd's oops detection just passed everything to ksymoops >untouched, and stored everything somewhere using -m It would be better if klogd got out of the way completely. Everything is stored, just created /var/log/ksymoops. >I don't see any reason why the internal profiler can't have an extended EIP >range to catch module samples either. Perhaps I'm missing something. Perhaps >no one cares enough ... IMNSHO the profiler should use kallsyms. Then it gets every symbol from the kernel and from all modules, instead of only being able to report on exported symbols. int kallsyms_address_to_symbol( unsigned long address, /* Address to lookup */ const char **mod_name, /* Set to module name */ unsigned long *mod_start, /* Set to start address of module */ unsigned long *mod_end, /* Set to end address of module */ const char **sec_name, /* Set to section name */ unsigned long *sec_start, /* Set to start address of section */ unsigned long *sec_end, /* Set to end address of section */ const char **sym_name, /* Set to full symbol name */ unsigned long *sym_start, /* Set to start address of symbol */ unsigned long *sym_end /* Set to end address of symbol */ ) We have the technology. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 22:03:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 22:03:11 -0500 Received: from vasquez.zip.com.au ([203.12.97.41]:6928 "EHLO vasquez.zip.com.au") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 22:02:52 -0500 Message-ID: <3C4B8362.8B249698@zip.com.au> Date: Sun, 20 Jan 2002 18:56:34 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 18:04:00 -0800." <3C4B7710.6C518006@zip.com.au> <324.1011579918@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keith Owens wrote: > > On Sun, 20 Jan 2002 18:04:00 -0800, > Andrew Morton wrote: > >ksymoops doesn't know what modules were loaded at the time > >of the crash, and it doesn't know where they were loaded. > > /var/log/ksymoops. man insmod and look for ksymoops assistance. Oh I have, extensively, when trying to get kgdb to play with modules. I did what any sensible person would do: gave up and went for a static link. I'm not aware of anyone getting kgdb working fully with modules. > >The `klogd -x' problem has been with us for *years* and > >distributors still persist in turning it on. > > Tell me about it :(. > > >It assumes too much. Arjan has a kksymoops thingy which does the symbol > >resolution at crash-time. > > It can only get symbols that are in /proc/ksyms, i.e. the exported > symbols. Proper crash analysis needs the full symbol table. Proper crash analysis needs to know the load address of each module at the time of the crash. We should print them out at Oops time. > >It also > >handles the common case where the running vmlinux/System.map/etc no longer > >exist. > > So does ksymoops, with reduced detail because it only has exported > symbols. > > >I would prefer that all this become easier, simpler and more reliable. > >We need a damn good reason for deprecating statically linked kernels > >and certainly none has been presented yet. > > That is a different problem. Saying that modular kernels cause > problems for debugging is not a good enough reason to deprecate modular > kernels, all the problems have been solved. They are patently *not* solved, because we continue to get a stream of partially and competely useless oops reports. It is my empirical observation that this problem is worse when modules are involved. It is my personal experience that modular code is harder to debug. It is also my personal experience that the refusal of sbp2.o to work correctly when statically linked was a complete pain in the ass when trying to diagnose its deadlock and module refcount problems. It was only when I worked out that I could link it statically and then get it to play via rescan-scsi-bus.sh that I was able to make reasonably-paced progress in finding the bugs. We don't want this to happen to every damn driver in the kernel. - From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 22:43:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 22:43:32 -0500 Received: from rj.sgi.com ([204.94.215.100]:20380 "EHLO rj.sgi.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 22:43:12 -0500 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Andrew Morton Cc: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 18:56:34 -0800." <3C4B8362.8B249698@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jan 2002 14:43:00 +1100 Message-ID: <1032.1011584580@kao2.melbourne.sgi.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 Jan 2002 18:56:34 -0800, Andrew Morton wrote: >I'm not aware of anyone getting kgdb working fully with modules. kgdb has a script that tells gdb where each module is loaded. AFAIK it uses add-symbol-file FILENAME -sSECTION ADDRESS, the __insmod entries contain enough data to tell gdb what is going on. >Proper crash analysis needs to know the load address of each module >at the time of the crash. We should print them out at Oops time. You need 13 bits of data per module. Where each of text, rodata, data and bss sections were loaded, you cannot assume they are contiguous. The length of those four sections. Where the module is on disk, you cannot assume the object name is the same as the module name, insmod -o. The timestamp and kernel version of the module when it was loaded, to detect updates after the event. All of that is encoded in the __insmod entries in /proc/ksyms, 5 lines per module. >> That is a different problem. Saying that modular kernels cause >> problems for debugging is not a good enough reason to deprecate modular >> kernels, all the problems have been solved. > >They are patently *not* solved, because we continue to get a >stream of partially and competely useless oops reports. Rule 1. Users do not read documentation. Rule 2. You can't do anything about rule 1. If you want complete bug reports, write a script that forces the user to submit all the required data. Why do I feel the "Linux should have a bug reporting system" thread starting again? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 22:45:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 22:44:52 -0500 Received: from hq.fsmlabs.com ([209.155.42.197]:17926 "EHLO hq.fsmlabs.com") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 22:44:41 -0500 Date: Sun, 20 Jan 2002 20:44:13 -0700 From: yodaiken@fsmlabs.com To: Keith Owens Cc: Andrew Morton , Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? Message-ID: <20020120204413.B6096@hq.fsmlabs.com> In-Reply-To: <3C4B7710.6C518006@zip.com.au> <324.1011579918@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <324.1011579918@kao2.melbourne.sgi.com>; from kaos@ocs.com.au on Mon, Jan 21, 2002 at 01:25:18PM +1100 Organization: FSM Labs Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2002 at 01:25:18PM +1100, Keith Owens wrote: > >I would prefer that all this become easier, simpler and more reliable. > >We need a damn good reason for deprecating statically linked kernels > >and certainly none has been presented yet. > > That is a different problem. Saying that modular kernels cause > problems for debugging is not a good enough reason to deprecate modular > kernels, all the problems have been solved. Interesting definition of "solved". From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 22:50:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 22:50:04 -0500 Received: from taifun.devconsult.de ([212.15.193.29]:62724 "EHLO taifun.devconsult.de") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 22:49:57 -0500 Date: Mon, 21 Jan 2002 04:49:52 +0100 From: Andreas Ferber To: Bruce Harada Cc: Frank van de Pol , linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020121044952.A21348@devcon.net> Mail-Followup-To: Bruce Harada , Frank van de Pol , linux-kernel@vger.kernel.org In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> <20020121002041.B1958@idefix.fvdpol.home.nl> <20020121095458.2bd9c7ed.bruce@ask.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020121095458.2bd9c7ed.bruce@ask.ne.jp>; from bruce@ask.ne.jp on Mon, Jan 21, 2002 at 09:54:58AM +0900 Organization: dev/consulting GmbH X-NCC-RegID: de.devcon Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2002 at 09:54:58AM +0900, Bruce Harada wrote: > > ...and how would you guarantee that this setting remains set, in the face of > some nasty little cracker screwing around with /dev/kmem? If the attacker gained the ability to play with /dev/kmem, he can already load modules into the kernel, regardless if the kernel is actually compiled with module support or not. You can find various papers describing how to do it via google, and AFAIK some rootkits are already using those techniques, so it's even "scriptkiddy-ready". Face it, there is absolutely /no/ security gain in disabling module support. Andreas -- Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG --------------------------------------------------------- +49 521 1365800 - af@devcon.net - www.devcon.net From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 23:30:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 23:30:48 -0500 Received: from vasquez.zip.com.au ([203.12.97.41]:63248 "EHLO vasquez.zip.com.au") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 23:30:32 -0500 Message-ID: <3C4B97EA.F49C7C95@zip.com.au> Date: Sun, 20 Jan 2002 20:24:10 -0800 From: Andrew Morton X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18pre1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Owens CC: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Your message of "Sun, 20 Jan 2002 18:56:34 -0800." <3C4B8362.8B249698@zip.com.au> <1032.1011584580@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keith Owens wrote: > > On Sun, 20 Jan 2002 18:56:34 -0800, > Andrew Morton wrote: > >I'm not aware of anyone getting kgdb working fully with modules. > > kgdb has a script that tells gdb where each module is loaded. AFAIK it > uses add-symbol-file FILENAME -sSECTION ADDRESS, the __insmod entries > contain enough data to tell gdb what is going on. > > >Proper crash analysis needs to know the load address of each module > >at the time of the crash. We should print them out at Oops time. > > You need 13 bits of data per module. Where each of text, rodata, data > and bss sections were loaded, you cannot assume they are contiguous. > The length of those four sections. Where the module is on disk, you > cannot assume the object name is the same as the module name, insmod > -o. The timestamp and kernel version of the module when it was loaded, > to detect updates after the event. All of that is encoded in the > __insmod entries in /proc/ksyms, 5 lines per module. That sounds OK. Just print it first. If it hits the logs then great. If it just scrolls off the screen then no loss. > >> That is a different problem. Saying that modular kernels cause > >> problems for debugging is not a good enough reason to deprecate modular > >> kernels, all the problems have been solved. > > > >They are patently *not* solved, because we continue to get a > >stream of partially and competely useless oops reports. > > Rule 1. Users do not read documentation. > Rule 2. You can't do anything about rule 1. Often the users know nothing about elf internals, kernel tools and build processes and all of that. They just want to get their box back up and reliable, and they consider that any work they do in problem disgnosis is a favour for the developers (and I have no problem with that attitude). Often, we only get one shot at it. > If you want complete bug reports, write a script that forces the user > to submit all the required data. It's in our interest to make it as easy as possible for the reporter. Cut-and-paste is easy, so we should err on the side of overkill when choosing which data to dump out. > Why do I feel the "Linux should have > a bug reporting system" thread starting again? Yeah, let's not do that. (But I'd be on the "no" side :-)) - From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Jan 2002 23:45:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Jan 2002 23:45:40 -0500 Received: from pl100.nas921.ichikawa.nttpc.ne.jp ([210.165.234.100]:24616 "EHLO mbr.sphere.ne.jp") by vger.kernel.org with ESMTP id ; Sun, 20 Jan 2002 23:45:26 -0500 Date: Mon, 21 Jan 2002 13:45:16 +0900 From: Bruce Harada To: Andreas Ferber Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-Id: <20020121134516.503c40cd.bruce@ask.ne.jp> In-Reply-To: <20020121044952.A21348@devcon.net> In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> <20020121002041.B1958@idefix.fvdpol.home.nl> <20020121095458.2bd9c7ed.bruce@ask.ne.jp> <20020121044952.A21348@devcon.net> X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.6; i686-pc-linux-gnu) X-Face: $qrUU,Lz=B[A}i%m2Rg^Ik;~V@]$Ay)$S`wUf3:^aZ1UdLf,_;1y7_xbEh=Yv*wB0=Fv]a1hj14_qQsl[f1KX]q4IdhwmSIeP6>Ap@[e$c$G;;ObLI7?YXsq*)M'3Jp wrote: > On Mon, Jan 21, 2002 at 09:54:58AM +0900, Bruce Harada wrote: > > > > ...and how would you guarantee that this setting remains set, in the face > > of some nasty little cracker screwing around with /dev/kmem? > > If the attacker gained the ability to play with /dev/kmem, he can > already load modules into the kernel, regardless if the kernel is > actually compiled with module support or not. You can find various > papers describing how to do it via google, and AFAIK some rootkits are > already using those techniques, so it's even "scriptkiddy-ready". Er... that was exactly what I meant - perhaps you meant to reply to the parent post? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Jan 2002 00:12:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Jan 2002 00:12:23 -0500 Received: from taifun.devconsult.de ([212.15.193.29]:27654 "EHLO taifun.devconsult.de") by vger.kernel.org with ESMTP id ; Mon, 21 Jan 2002 00:12:09 -0500 Date: Mon, 21 Jan 2002 06:12:06 +0100 From: Andreas Ferber To: Bruce Harada Cc: linux-kernel@vger.kernel.org Subject: Re: Hardwired drivers are going away? Message-ID: <20020121061206.A11330@devcon.net> Mail-Followup-To: Bruce Harada , linux-kernel@vger.kernel.org In-Reply-To: <14160.1011396163@ocs3.intra.ocs.com.au> <20020121002041.B1958@idefix.fvdpol.home.nl> <20020121095458.2bd9c7ed.bruce@ask.ne.jp> <20020121044952.A21348@devcon.net> <20020121134516.503c40cd.bruce@ask.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020121134516.503c40cd.bruce@ask.ne.jp>; from bruce@ask.ne.jp on Mon, Jan 21, 2002 at 01:45:16PM +0900 Organization: dev/consulting GmbH X-NCC-RegID: de.devcon Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2002 at 01:45:16PM +0900, Bruce Harada wrote: > > Er... that was exactly what I meant - perhaps you meant to reply to the parent > post? Hmm, I understood your post as if you consider a simple flag disabling module loading a step-back regarding security. I stand corrected. Andreas -- Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG --------------------------------------------------------- +49 521 1365800 - af@devcon.net - www.devcon.net From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Jan 2002 04:34:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Jan 2002 04:34:27 -0500 Received: from waldorf.cs.uni-dortmund.de ([129.217.4.42]:40644 "EHLO waldorf.cs.uni-dortmund.de") by vger.kernel.org with ESMTP id ; Mon, 21 Jan 2002 04:34:16 -0500 Message-Id: <200201210934.g0L9Y7qV001830@tigger.cs.uni-dortmund.de> To: Andrew Morton cc: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? In-Reply-To: Message from Andrew Morton of "Sun, 20 Jan 2002 17:30:12 PST." <3C4B6F24.C2750F51@zip.com.au> Date: Mon, 21 Jan 2002 10:34:07 +0100 From: Horst von Brand Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton said: > "Mr. James W. Laferriere" wrote: > > This is just what the Heads are trying to do away with . There > > will only be module enabled kernels . JimL > I suspect none of these "Heads" spend much time in protracted > email debug sessions. Because the *first* thing you do is > ask the tester to compile the relevant driver into the > kernel. > > The problems which the removal of this option will cause include: > > 1: Inability to look up symbols in the kernel elf image. ksymoops(8) is able to find them... > 2: Breaks the kernel profiler Which one? > 3: breaks kgdb Officially not wanted by the heads, so irrelevant > 4: breaks ksymoops. How so? -- Horst von Brand http://counter.li.org # 22616 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Jan 2002 09:26:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Jan 2002 09:26:46 -0500 Received: from probity.mcc.ac.uk ([130.88.200.94]:57092 "EHLO probity.mcc.ac.uk") by vger.kernel.org with ESMTP id ; Mon, 21 Jan 2002 09:26:39 -0500 Date: Mon, 21 Jan 2002 14:29:05 +0000 From: John Levon To: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? Message-ID: <20020121142903.GA73605@compsoc.man.ac.uk> In-Reply-To: <3C4B6F24.C2750F51@zip.com.au> <200201210934.g0L9Y7qV001830@tigger.cs.uni-dortmund.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201210934.g0L9Y7qV001830@tigger.cs.uni-dortmund.de> User-Agent: Mutt/1.3.25i X-Url: http://www.movementarian.org/ X-Record: Bendik Singers - Afrotid X-Toppers: N/A X-Scanner: exiscan *16SfOx-000OxC-00*HCwu9uYDQnk* (Manchester Computing, University of Manchester) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2002 at 10:34:07AM +0100, Horst von Brand wrote: > > 2: Breaks the kernel profiler > > Which one? readprofile(3) - the histogram only extends across the .text of the monolithic kernel image regards john -- "I hope you will find the courage to keep on living despite the existence of this feature." - Richard Stallman From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Jan 2002 17:42:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Jan 2002 17:42:47 -0500 Received: from khms.westfalen.de ([62.153.201.243]:35524 "EHLO khms.westfalen.de") by vger.kernel.org with ESMTP id ; Mon, 21 Jan 2002 17:42:33 -0500 Date: 21 Jan 2002 22:57:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: linux-kernel@vger.kernel.org Message-ID: <8HHVjc4Xw-B@khms.westfalen.de> In-Reply-To: <20020120204413.B6096@hq.fsmlabs.com> Subject: Re: Hardwired drivers are going away? X-Mailer: CrossPoint v3.12d.kh8 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? In-Reply-To: <324.1011579918@kao2.melbourne.sgi.com> <3C4B7710.6C518006@zip.com.au> <324.1011579918@kao2.melbourne.sgi.com> <20020120204413.B6096@hq.fsmlabs.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org yodaiken@fsmlabs.com wrote on 20.01.02 in <20020120204413.B6096@hq.fsmlabs.com>: > On Mon, Jan 21, 2002 at 01:25:18PM +1100, Keith Owens wrote: > > >I would prefer that all this become easier, simpler and more reliable. > > >We need a damn good reason for deprecating statically linked kernels > > >and certainly none has been presented yet. > > > > That is a different problem. Saying that modular kernels cause > > problems for debugging is not a good enough reason to deprecate modular > > kernels, all the problems have been solved. > > > Interesting definition of "solved". Make that "all problems except the one of how to get everybody to use the correct solution", and it is the standard definition of "solved". I.e., everything's solved except the marketing. MfG Kai From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 21 Jan 2002 20:14:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 21 Jan 2002 20:14:20 -0500 Received: from c207-202-243-179.sea1.cablespeed.com ([207.202.243.179]:58706 "EHLO darklands.zimres.net") by vger.kernel.org with ESMTP id ; Mon, 21 Jan 2002 20:14:10 -0500 Date: Mon, 21 Jan 2002 15:52:46 -0800 From: Thomas Zimmerman To: Linux Kernel Maillist Subject: Re: Hardwired drivers are going away? Message-ID: <20020121235246.GA2974@zimres.net> Reply-To: Thomas Mail-Followup-To: Linux Kernel Maillist In-Reply-To: <20020121021355.GA60801@compsoc.man.ac.uk> <386.1011580260@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <386.1011580260@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.25i X-Operating-System: Linux lightlands 2.4.18-pre3 X-Operating-Status: 14:58:05 up 3:08, 2 users, load average: 0.44, 0.47, 0.24 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 21-Jan 01:31, Keith Owens wrote: > On Mon, 21 Jan 2002 02:13:55 +0000,=20 > John Levon wrote: > >On Mon, Jan 21, 2002 at 12:53:28PM +1100, Keith Owens wrote: > >> Guess why these entries are in /proc/ksyms? > >>=20 > >> c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs] > > > >and quite often the user has unloaded / loaded modules in the meantime > >and the oops is useless. >=20 > /var/log/ksymoops. I added the code and documented it nicely, man > insmod or ksymoops. It's not my fault if nobody reads the docs! >=20 > >It would be nice if klogd's oops detection just passed everything to ksy= moops > >untouched, and stored everything somewhere using -m >=20 > It would be better if klogd got out of the way completely. Everything > is stored, just created /var/log/ksymoops. Isn't part of the problem with klogd mangling is that is sort of works? Change the format so that klogd doesn't touch it and that gets _wrong_ Oops reports out of the way. [you do great work, now make someone else do some too!]=20 Just my $0.02, from a thankful user. Thomas --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TKnNUHPW3p9PurIRAhDuAJ0c5mhE+dSFqfS3zn/e5LLVMqAZ8gCfcgpR MX0XhNzKvYjjwByZeBogZqg= =CFWN -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 8 Feb 2002 19:19:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 8 Feb 2002 19:19:20 -0500 Received: from blackhole.compendium-tech.com ([64.156.208.74]:19090 "EHLO sol.compendium-tech.com") by vger.kernel.org with ESMTP id ; Fri, 8 Feb 2002 19:19:10 -0500 Date: Fri, 8 Feb 2002 16:19:08 -0800 (PST) From: "Dr. Kelsey Hudson" X-X-Sender: kernel@sol.compendium-tech.com To: Linux Kernel List Subject: Re: Hardwired drivers are going away? In-Reply-To: <20020114131050.E14747@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org This bothers me. I prefer building a monolithic kernel with only a few drivers compiled as modules (e.g. those drivers which are under active development and are upgraded often). I believe firmly that certain drivers should be part of the monolithic kernel.... either way, i'm not about to debate it. i'd just like to know exactly why this is being done, and to lodge an objection against it. On Mon, 14 Jan 2002, Eric S. Raymond wrote: > Alan Cox : > > For 2.5 if things go to plan there will be no such thing as a "compiled in" > > driver. They simply are not needed with initramfs holding what were once the > > "compiled in" modules. > > This is something of a bombshell. Not necessarily a bad one, but... > > Alan, do you have *any* *freakin'* *idea* how much more complicated > the CML2 deduction engine had to be because the basic logical entity > was a tristate rather than a bool? If this plan goes through, I'm > going to be able to drop out at least 20% of the code, with most of > that 20% being in the nasty complicated bits where the maintainability > improvement will be greatest. And I can get rid of the nasty "vitality" > flag, which probably the worst wart on the language. > > Yowza...so how soon is this supposed to happen? > -- Kelsey Hudson khudson@ctica.com Software Engineer Compendium Technologies, Inc (619) 725-0771 ---------------------------------------------------------------------------