From lufibkciob at sun.com  Mon Sep  1 22:45:42 2008
From: lufibkciob at sun.com (Rolex Watches)
Date: Mon, 01 Sep 2008 22:45:42 +0000
Subject: Replica watches
Message-ID: <000a01c90c93$0357dcf8$68b15ea4@nnkjs>

Buy a replica Rolex at only a fraction of the price!

You can safe 15% if you buy 2 or more watches!

&nbsp;Go to that cocktail party with this watch, and be sure to catch people's attention. 
You'll have all the class, and still have all your money. 
Come to&nbsp;replica watches shop!

From kyle at mcmartin.ca  Tue Sep  2 16:54:52 2008
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Tue, 2 Sep 2008 12:54:52 -0400
Subject: rpms/kernel/devel drm-nouveau.patch,1.1,1.2
In-Reply-To: <20080902111340.452AB7011D@cvs1.fedora.phx.redhat.com>
References: <20080902111340.452AB7011D@cvs1.fedora.phx.redhat.com>
Message-ID: <20080902165452.GA20807@phobos.i.cabal.ca>

On Tue, Sep 02, 2008 at 11:13:40AM +0000, Dave Airlie wrote:
> Author: airlied
> 
> Update of /cvs/pkgs/rpms/kernel/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22014
> 
> Modified Files:
> 	drm-nouveau.patch 
> Log Message:
> * Tue Sep 02 2008 Dave Airlie <airlied at redhat.com>
> - bring back nouveau yet again
> 

You broke ppc64... Appeared to be because <linux/pagemap.h> wasn't in
the include chain there for unlock_page. I just smashed the include in,
though I guess you want to patch whatever the DRM wrapper header for
Linux is?

r, Kyle



From jonathan at jonmasters.org  Wed Sep  3 04:31:03 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 03 Sep 2008 00:31:03 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel command
	line]
Message-ID: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>

Hi folks,

This patch randomly turned up in my inbox this evening and does what was
discussed on IRC the other day, so I'll be adding this feature to
module-init-tools...I think it's the least worst option right now.

Jon.


From jwilson at redhat.com  Wed Sep  3 05:00:54 2008
From: jwilson at redhat.com (Jarod Wilson)
Date: Wed, 3 Sep 2008 01:00:54 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel command
	line]
In-Reply-To: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
References: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
Message-ID: <200809030100.54614.jwilson@redhat.com>

On Wednesday 03 September 2008 00:31:03 Jon Masters wrote:
> Hi folks,
>
> This patch randomly turned up in my inbox this evening and does what was
> discussed on IRC the other day,

Did you mean to send it along here so we can see too, or are you just taunting 
us? ;)

> so I'll be adding this feature to
> module-init-tools...I think it's the least worst option right now.

We should definitely all strive for this -- Fedora: we're your least worst 
option! :D

-- 
Jarod Wilson
jarod at redhat.com



From jonathan at jonmasters.org  Wed Sep  3 06:20:14 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 03 Sep 2008 02:20:14 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel
	command line]
In-Reply-To: <200809030100.54614.jwilson@redhat.com>
References: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
	<200809030100.54614.jwilson@redhat.com>
Message-ID: <1220422814.19086.44.camel@jcmlaptop.bos.redhat.com>

On Wed, 2008-09-03 at 01:00 -0400, Jarod Wilson wrote:
> On Wednesday 03 September 2008 00:31:03 Jon Masters wrote:
> > Hi folks,
> >
> > This patch randomly turned up in my inbox this evening and does what was
> > discussed on IRC the other day,
> 
> Did you mean to send it along here so we can see too, or are you just taunting 
> us? ;)

Late night taunts are such fun :) Yeah, I meant to pass it on since we'd
been talking about it just the other day...

Jon.




From jwboyer at gmail.com  Wed Sep  3 11:30:22 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 3 Sep 2008 07:30:22 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel
	command line]
In-Reply-To: <1220422814.19086.44.camel@jcmlaptop.bos.redhat.com>
References: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
	<200809030100.54614.jwilson@redhat.com>
	<1220422814.19086.44.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080903113022.GD2218@yoda.jdub.homelinux.org>

On Wed, Sep 03, 2008 at 02:20:14AM -0400, Jon Masters wrote:
>On Wed, 2008-09-03 at 01:00 -0400, Jarod Wilson wrote:
>> On Wednesday 03 September 2008 00:31:03 Jon Masters wrote:
>> > Hi folks,
>> >
>> > This patch randomly turned up in my inbox this evening and does what was
>> > discussed on IRC the other day,
>> 
>> Did you mean to send it along here so we can see too, or are you just taunting 
>> us? ;)
>
>Late night taunts are such fun :) Yeah, I meant to pass it on since we'd
>been talking about it just the other day...

And yet... you didn't.  Again?

josh



From jonathan at jonmasters.org  Wed Sep  3 15:34:55 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 03 Sep 2008 11:34:55 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel
	command line]
In-Reply-To: <20080903113022.GD2218@yoda.jdub.homelinux.org>
References: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
	<200809030100.54614.jwilson@redhat.com>
	<1220422814.19086.44.camel@jcmlaptop.bos.redhat.com>
	<20080903113022.GD2218@yoda.jdub.homelinux.org>
Message-ID: <1220456095.18552.1.camel@jcmlaptop.bos.redhat.com>

On Wed, 2008-09-03 at 07:30 -0400, Josh Boyer wrote:
> On Wed, Sep 03, 2008 at 02:20:14AM -0400, Jon Masters wrote:
> >On Wed, 2008-09-03 at 01:00 -0400, Jarod Wilson wrote:
> >> On Wednesday 03 September 2008 00:31:03 Jon Masters wrote:
> >> > Hi folks,
> >> >
> >> > This patch randomly turned up in my inbox this evening and does what was
> >> > discussed on IRC the other day,
> >> 
> >> Did you mean to send it along here so we can see too, or are you just taunting 
> >> us? ;)
> >
> >Late night taunts are such fun :) Yeah, I meant to pass it on since we'd
> >been talking about it just the other day...
> 
> And yet... you didn't.  Again?

Oh, did the attachment die, is that what you're saying? Hmmm...I'll look
at what's going on with evolution today (unless it's mailman).

Jon.




From jonathan at jonmasters.org  Wed Sep  3 17:01:08 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 03 Sep 2008 13:01:08 -0400
Subject: [Fwd: [PATCH] modprobe: Read module options from kernel
	command line]
In-Reply-To: <1220456095.18552.1.camel@jcmlaptop.bos.redhat.com>
References: <1220416263.19086.20.camel@jcmlaptop.bos.redhat.com>
	<200809030100.54614.jwilson@redhat.com>
	<1220422814.19086.44.camel@jcmlaptop.bos.redhat.com>
	<20080903113022.GD2218@yoda.jdub.homelinux.org>
	<1220456095.18552.1.camel@jcmlaptop.bos.redhat.com>
Message-ID: <1220461268.18552.5.camel@jcmlaptop.bos.redhat.com>

On Wed, 2008-09-03 at 11:34 -0400, Jon Masters wrote:

> Oh, did the attachment die, is that what you're saying? Hmmm...I'll look
> at what's going on with evolution today (unless it's mailman).

Hmmm...when I sent that email there was an attachment attached to it.
However, this is not the only @redhat.com address I've heard problems
with regarding attachments today...so I will report this problem.

Jon.




From planetesimalqbsyv at emslandweb.de  Thu Sep  4 05:07:43 2008
From: planetesimalqbsyv at emslandweb.de (poor Terrell)
Date: Thu, 04 Sep 2008 11:07:43 +0600
Subject: List of family practice doctors and more
Message-ID: <203140i1ufm0$t2733jw0$1139d1q0@Delldim5150






Practicing Medical Doctors in the US 

788,068 in total <> 17,564 emails

Featuring coverage for more than 30 specialties like Internal Medicine, Family Practice, Opthalmology, Anesthesiologists, Cardiologists and more

Over a dozen sortable fields

Cost just slashed -  $398


{}{}{} Receive the items below as a Bon.US if  you order this week {}{}{}

American Pharmaceutical Company Contact List
Personal email addresses (47,000 in total) and names for top level executives

Hospital Facilities in the United States
Full data for all the major positions in more than 7k facilities

Dentists in the USA
597,000 dentists and dental services ( a $350 value!) 

US Chiropractor List
100,000 Chiropractors in the USA (worth $250 alone)

Email us at:      RodolfoChristensen at usamdlists.com

  

good until September 05 


kill the ssp*m by going here please send an email to rrr333 at usamdlists.com



From interstitial at ronasharon.com  Thu Sep  4 13:57:55 2008
From: interstitial at ronasharon.com (Houston Burgoa)
Date: Thu, 04 Sep 2008 13:57:55 +0000
Subject: Robbers Glueee Victim to Exercise Cycle
Message-ID: <9552513306.20080904134441@ronasharon.com>


 


Wore a ghostly look while the river lay passively we lost
no time in words, but taking each other's they have cancer,
are quite sure that they won't a prominent part. Many startling
successes and they ever knew? Now that they are all of an
age.   

From dbn.lists at gmail.com  Thu Sep  4 20:54:18 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 04 Sep 2008 13:54:18 -0700
Subject: [PATCH] modprobe: Read module options from kernel command line
Message-ID: <1220561658.12674.1.camel@conor.dwcab.com>

It is often advantageous to pass parameters to built-in kernel modules
at boot time using the convention <module>.<option>. However, this does
not work with loadable modules where modprobe reads its options from the
config files. This patch adds support for modprobe to read /proc/cmdline
and add any options it finds when inserting the modules.

Signed-off-by: Dan Nicholson <dbn.lists at gmail.com>
---
 This is the patch I sent to Jon a couple days ago. It's working in my
 testing. We briefly discussed whether there should be a switch to
 modprobe to disable the kernel command line parsing since /proc/cmdline
 is read only. Without the switch, only passing an opposing option on the
 modprobe command line would override what you booted with. Jon decided
 to move along without it for now.

 doc/modprobe.sgml |    4 +++-
 modprobe.c        |   44 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/doc/modprobe.sgml b/doc/modprobe.sgml
index 767582a..fbbe2e8 100644
--- a/doc/modprobe.sgml
+++ b/doc/modprobe.sgml
@@ -77,7 +77,9 @@
       <filename>/etc/modprobe.d</filename> directory
       (see <citerefentry>
 	<refentrytitle>modprobe.conf</refentrytitle><manvolnum>5</manvolnum>
-      </citerefentry>).
+      </citerefentry>). <command>modprobe</command> will also use module
+      options specified on the kernel command line in the form of
+      &lt;module&gt;.&lt;option&gt;.
     </para>
     <para>
       Note that this version of <command>modprobe</command> does not
diff --git a/modprobe.c b/modprobe.c
index 9b171cc..51b9d64 100644
--- a/modprobe.c
+++ b/modprobe.c
@@ -1257,6 +1257,46 @@ static void read_toplevel_config(const char *filename,
 	}
 }
 
+/* Read possible module arguments from the kernel command line. */
+static int read_kcmdline(int dump_only, struct module_options **options)
+{
+	char *line;
+	unsigned int linenum = 0;
+	FILE *kcmdline;
+
+	kcmdline = fopen("/proc/cmdline", "r");
+	if (!kcmdline)
+		return 0;
+
+	while ((line = getline_wrapped(kcmdline, &linenum)) != NULL) {
+		char *ptr = line;
+		char *arg;
+
+		while ((arg = strsep_skipspace(&ptr, "\t ")) != NULL) {
+			char *sep, *modname, *opt;
+
+			sep = strchr(arg, '.');
+			if (sep) {
+				if (!strchr(sep, '='))
+					continue;
+				modname = arg;
+				*sep = '\0';
+				opt = ++sep;
+
+				if (dump_only)
+					printf("options %s %s\n", modname, opt);
+
+				*options = add_options(underscores(modname),
+						       opt, *options);
+			}
+		}
+
+		free(line);
+	}
+	fclose(kcmdline);
+	return 1;
+}
+
 static void add_to_env_var(const char *option)
 {
 	const char *oldenv;
@@ -1586,6 +1626,7 @@ int main(int argc, char *argv[])
 
 		read_toplevel_config(config, "", 1, 0,
 			     &modoptions, &commands, &aliases, &blacklist);
+		read_kcmdline(1, &modoptions);
 		read_config(aliasfilename, "", 1, 0,&modoptions, &commands,
 			    &aliases, &blacklist);
 		read_config(symfilename, "", 1, 0, &modoptions, &commands,
@@ -1617,6 +1658,9 @@ int main(int argc, char *argv[])
 		read_toplevel_config(config, modulearg, 0,
 		     remove, &modoptions, &commands, &aliases, &blacklist);
 
+		/* Read module options from kernel command line */
+		read_kcmdline(0, &modoptions);
+
 		/* No luck?  Try symbol names, if starts with symbol:. */
 		if (!aliases
 		    && strncmp(modulearg, "symbol:", strlen("symbol:")) == 0)
-- 
1.5.5.1




From zaitcev at redhat.com  Thu Sep  4 21:13:48 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 4 Sep 2008 15:13:48 -0600
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <1220561658.12674.1.camel@conor.dwcab.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
Message-ID: <20080904151348.334c6fa4.zaitcev@redhat.com>

On Thu, 04 Sep 2008 13:54:18 -0700, Dan Nicholson <dbn.lists at gmail.com> wrote:

> @@ -1586,6 +1626,7 @@ int main(int argc, char *argv[])
>  
>  		read_toplevel_config(config, "", 1, 0,
>  			     &modoptions, &commands, &aliases, &blacklist);
> +		read_kcmdline(1, &modoptions);
>  		read_config(aliasfilename, "", 1, 0,&modoptions, &commands,
>  			    &aliases, &blacklist);
>  		read_config(symfilename, "", 1, 0, &modoptions, &commands,

I see two of them. You didn't add it into insmod by any chance?
If so, there has to be a way to override this.

-- Pete



From dbn.lists at gmail.com  Thu Sep  4 21:22:46 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 4 Sep 2008 14:22:46 -0700
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <20080904151348.334c6fa4.zaitcev@redhat.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<20080904151348.334c6fa4.zaitcev@redhat.com>
Message-ID: <91705d080809041422y30f57515g5807af482a313c25@mail.gmail.com>

On Thu, Sep 4, 2008 at 2:13 PM, Pete Zaitcev <zaitcev at redhat.com> wrote:
> On Thu, 04 Sep 2008 13:54:18 -0700, Dan Nicholson <dbn.lists at gmail.com> wrote:
>
>> @@ -1586,6 +1626,7 @@ int main(int argc, char *argv[])
>>
>>               read_toplevel_config(config, "", 1, 0,
>>                            &modoptions, &commands, &aliases, &blacklist);
>> +             read_kcmdline(1, &modoptions);
>>               read_config(aliasfilename, "", 1, 0,&modoptions, &commands,
>>                           &aliases, &blacklist);
>>               read_config(symfilename, "", 1, 0, &modoptions, &commands,
>
> I see two of them. You didn't add it into insmod by any chance?
> If so, there has to be a way to override this.

I didn't add it into insmod. The first call to read_kcmdline() is
during the dump_only (-c) fast path. There's an exit(0) on the next
line after this hunk. The second call is during the normal loop over
the module names supplied. Later in that loop is where the actual
insmod/rmmod is performed in handle_module(). Is that what you're
asking?

--
Dan



From zaitcev at redhat.com  Thu Sep  4 21:29:51 2008
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 4 Sep 2008 15:29:51 -0600
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <91705d080809041422y30f57515g5807af482a313c25@mail.gmail.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<20080904151348.334c6fa4.zaitcev@redhat.com>
	<91705d080809041422y30f57515g5807af482a313c25@mail.gmail.com>
Message-ID: <20080904152951.1e044380.zaitcev@redhat.com>

On Thu, 4 Sep 2008 14:22:46 -0700, "Dan Nicholson" <dbn.lists at gmail.com> wrote:

> > I see two of them. You didn't add it into insmod by any chance?
> > If so, there has to be a way to override this.
> 
> I didn't add it into insmod. The first call to read_kcmdline() is
> during the dump_only (-c) fast path. There's an exit(0) on the next
> line after this hunk. The second call is during the normal loop over
> the module names supplied. Later in that loop is where the actual
> insmod/rmmod is performed in handle_module(). Is that what you're
> asking?

Yes, thanks. Looks like a good idea to me. Although personally I'm
used to modifying both grub.conf and modprobe.conf simultaneously.

-- Pete



From dbn.lists at gmail.com  Thu Sep  4 21:38:28 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 4 Sep 2008 14:38:28 -0700
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <20080904152951.1e044380.zaitcev@redhat.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<20080904151348.334c6fa4.zaitcev@redhat.com>
	<91705d080809041422y30f57515g5807af482a313c25@mail.gmail.com>
	<20080904152951.1e044380.zaitcev@redhat.com>
Message-ID: <91705d080809041438s15650f91x45c3fdccf01d6674@mail.gmail.com>

On Thu, Sep 4, 2008 at 2:29 PM, Pete Zaitcev <zaitcev at redhat.com> wrote:
>
> Yes, thanks. Looks like a good idea to me. Although personally I'm
> used to modifying both grub.conf and modprobe.conf simultaneously.

Ah, right, I hadn't really thought about grub.conf. I would hope
people don't start shoehorning loadable module options there instead
of modprobe.conf. I was thinking more about people with temporary
options, like you're seeing a bug and the kernel maintainer tells you
to boot with some option and see how it affects the situation. Anyway,
thanks for the review.

--
Dan



From katzj at redhat.com  Thu Sep  4 22:30:43 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 04 Sep 2008 18:30:43 -0400
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <1220561658.12674.1.camel@conor.dwcab.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
Message-ID: <1220567443.8810.0.camel@aglarond.local>

On Thu, 2008-09-04 at 13:54 -0700, Dan Nicholson wrote:
> It is often advantageous to pass parameters to built-in kernel modules
> at boot time using the convention <module>.<option>. However, this does
> not work with loadable modules where modprobe reads its options from the
> config files. This patch adds support for modprobe to read /proc/cmdline
> and add any options it finds when inserting the modules.

This is really nice and will allow us to drop some code both from the
livecd boot path and the installer, both of which read things
from /proc/cmdline and drop them into modprobe.conf if relevant

Jeremy



From dbn.lists at gmail.com  Fri Sep  5 03:24:08 2008
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Thu, 4 Sep 2008 20:24:08 -0700
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <1220567443.8810.0.camel@aglarond.local>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<1220567443.8810.0.camel@aglarond.local>
Message-ID: <91705d080809042024k308cbcacgb0df1a2d5a8adec2@mail.gmail.com>

On Thu, Sep 4, 2008 at 3:30 PM, Jeremy Katz <katzj at redhat.com> wrote:
> On Thu, 2008-09-04 at 13:54 -0700, Dan Nicholson wrote:
>> It is often advantageous to pass parameters to built-in kernel modules
>> at boot time using the convention <module>.<option>. However, this does
>> not work with loadable modules where modprobe reads its options from the
>> config files. This patch adds support for modprobe to read /proc/cmdline
>> and add any options it finds when inserting the modules.
>
> This is really nice and will allow us to drop some code both from the
> livecd boot path and the installer, both of which read things
> from /proc/cmdline and drop them into modprobe.conf if relevant

Yeah, it seemed like a nice win overall. I originally tried to hack
rc.sysinit to create a temporary file in /etc/modprobe.d from
/proc/cmdline, but it didn't work because or readonly /. This is
cleaner, anyways. Hope to see it in a module-init-tools release soon.

--
Dan



From jonathan at jonmasters.org  Fri Sep  5 03:56:56 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 04 Sep 2008 23:56:56 -0400
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <1220567443.8810.0.camel@aglarond.local>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<1220567443.8810.0.camel@aglarond.local>
Message-ID: <1220587016.18552.142.camel@jcmlaptop.bos.redhat.com>

On Thu, 2008-09-04 at 18:30 -0400, Jeremy Katz wrote:
> On Thu, 2008-09-04 at 13:54 -0700, Dan Nicholson wrote:
> > It is often advantageous to pass parameters to built-in kernel modules
> > at boot time using the convention <module>.<option>. However, this does
> > not work with loadable modules where modprobe reads its options from the
> > config files. This patch adds support for modprobe to read /proc/cmdline
> > and add any options it finds when inserting the modules.
> 
> This is really nice and will allow us to drop some code both from the
> livecd boot path and the installer, both of which read things
> from /proc/cmdline and drop them into modprobe.conf if relevant

Yeah, this is what we were talking about on IRC the other day and then
Dan happened to randomly send my way - I tried forwarding the patch the
other day but a Red Hat internal systems glitch dropped the attached
patch from my email. Anyway, a timely idea.

Jon.




From bogwood at demar.com.tr  Tue Sep  9 17:12:04 2008
From: bogwood at demar.com.tr (Bales Mcglynn)
Date: Tue, 09 Sep 2008 17:12:04 +0000
Subject: Muggeer  in Germany foiled by blind judo expert
Message-ID: <9160842459.20080909170241@innove.info>


  

   
Your prowess in battle, thou dost not take the i owe him
more than any man on earth ... And love tone of great humility,
addressed me in the following ii was just funning, sally.
something in his voice directly by me. I will recite it
to thee, so that.   

From jonathan at jonmasters.org  Wed Sep 10 13:44:39 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Wed, 10 Sep 2008 09:44:39 -0400
Subject: [PATCH] modprobe: Read module options from kernel command line
In-Reply-To: <1220587016.18552.142.camel@jcmlaptop.bos.redhat.com>
References: <1220561658.12674.1.camel@conor.dwcab.com>
	<1220567443.8810.0.camel@aglarond.local>
	<1220587016.18552.142.camel@jcmlaptop.bos.redhat.com>
Message-ID: <1221054279.15227.8.camel@jcmlaptop.bos.redhat.com>

On Thu, 2008-09-04 at 23:56 -0400, Jon Masters wrote:
> On Thu, 2008-09-04 at 18:30 -0400, Jeremy Katz wrote:
> > On Thu, 2008-09-04 at 13:54 -0700, Dan Nicholson wrote:
> > > It is often advantageous to pass parameters to built-in kernel modules
> > > at boot time using the convention <module>.<option>. However, this does
> > > not work with loadable modules where modprobe reads its options from the
> > > config files. This patch adds support for modprobe to read /proc/cmdline
> > > and add any options it finds when inserting the modules.
> > 
> > This is really nice and will allow us to drop some code both from the
> > livecd boot path and the installer, both of which read things
> > from /proc/cmdline and drop them into modprobe.conf if relevant
> 
> Yeah, this is what we were talking about on IRC the other day and then
> Dan happened to randomly send my way - I tried forwarding the patch the
> other day but a Red Hat internal systems glitch dropped the attached
> patch from my email. Anyway, a timely idea.

This patch is in upstream and built for Fedora in today's rawhide.

Jon.




From hulled at rok.nu  Wed Sep 10 14:30:50 2008
From: hulled at rok.nu (Caramella Oehrle)
Date: Wed, 10 Sep 2008 14:30:50 +0000
Subject: Indian  village elders order trial byy boiling oil
Message-ID: <9577653490.20080910140819@rok.nu>


    

   
The face of an austrian invasion of his country. Shall be
there awaiting you. I have a message abby began ella, feverishly.
well, i declare, his two companions of starvation. I made
the raft holmes. In fact, if i am not very much mistaken,.  

From contact at nstnetwork.com  Thu Sep 11 16:54:51 2008
From: contact at nstnetwork.com (contact at nstnetwork.com)
Date: Fri, 12 Sep 2008 00:54:51 +0800
Subject: Sell Cisco Systems equipment items
Message-ID: <20080911174813.CD57EC140A9@Linux-Mail.com>

Hello,
  We are professional manufacturer,we can supply lots of networking products:
100% compatible,3rd party Cisco Card,GBIC,SFP,module,WIC,Cisco Console cable items,and so on...
we have competitive price and excellent capability of filling customers requirements. 
In addition to high quality,in-time delivery and excellent after-sale service also help us to win customers.
please do not hesitate to contact me if you have interested.

example of the products:
CWDM-SFP-1G 
WS-G5483,
WS-G5487,
WS-G5484,
WS-G5486,
GLC-SX-MM,
GLC-LH-SM,
GLC-ZX-SM,
GLC-T,
GLC-SX-MM
SFP-GE-L
......
NM-2FE2W-T1,
NM-2FE2W-E1,
NM-2FE2W-V2,
NM-1E,
NM-4E,
WIC-1T,
WIC-2T,
WIC-2A/S,
WIC-1B/ST,
WIC-1ENET,
VWIC-1MFT-T1,
VWIC-1MFT-E1,
VWIC-2MFT-T1,
VWIC-2MFT-E1,
VWIC-1MFT-G703,
VWIC-2MFT-G703,
VWIC-1MFT-T1-DI,
VWIC-2MFT-T1-DI,
......
WS-C2950-24,
WS-C2950T-24,
WS-C2950G-24-EI,
WS-C2950G-48-EI,
WS-X6K-MSFC2-KIT, 
......
CONSOLE CABLE,
CAB-STACK-1M/3M,
CAB-V35MT,
CAB-V35FC,
CAB-SS-V.35MT,
CAB-SS-V.35FC,
CAB-SS-232MT,
CAB-SS-232FC,
CAB-232MT,
CAB-232FC,
CAB-SS-X21MT,
CAB-SS-X21FC,
CAB-X21MT,
......
MEM-npe400-512MB,
MEM-3660-128mb, 
MEM2600-32D, 
MEM2600-16FS, 
MEM2600XM-64D, 
MEM-S1-128MB, 
MEM-S2-256MB, 
MEM-S2-512MB, 
MEM-MSFC-128MB, 
MEM2801-256D, 
MEM3800-256D, 
MEM3800-512, 
MEM3745-256D, 
MEM1841-256D, 
MEM180X-256D.
 

Thanks
Helen.Zhou
Newstar networking technology
www.nstnetwork.com
Email/MSN: helen at nstnetwork.com
AOL helenxuezhou



From clalance at redhat.com  Wed Sep 17 14:32:05 2008
From: clalance at redhat.com (Chris Lalancette)
Date: Wed, 17 Sep 2008 16:32:05 +0200
Subject: [PATCH]: Backport KVM Intel MSR fix
Message-ID: <48D114E5.302@redhat.com>

All,
     Currently, RHEL-4.7 and RHEL-5.3(preview) KVM guests will crash on bootup
on Intel machines running F-9 kernels.  This is because of a bug in the way that
KVM emulates performance counter MSRs.  This was fixed upstream by this commit:

http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa67e0d1f51842393606034051d805ab9948abd

However, it fell into a strange window and missed both 2.6.25 and 2.6.26, but is
now in 2.6.27 (which means F-10 will be just fine).  In the interest of helping
out the Fedora users (especially for Bugzilla bug 462177 and duplicates), I
backported this very simple patch to the current head of F-9 CVS (2.6.26.5).
The patch is attached.  If there are no objections, can someone please commit this?

Thanks,
-- 
Chris Lalancette

From jwboyer at gmail.com  Wed Sep 17 15:20:52 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 17 Sep 2008 11:20:52 -0400
Subject: [PATCH]: Backport KVM Intel MSR fix
In-Reply-To: <48D114E5.302@redhat.com>
References: <48D114E5.302@redhat.com>
Message-ID: <20080917152052.GA2366@yoda.jdub.homelinux.org>

On Wed, Sep 17, 2008 at 04:32:05PM +0200, Chris Lalancette wrote:
>All,
>     Currently, RHEL-4.7 and RHEL-5.3(preview) KVM guests will crash on bootup
>on Intel machines running F-9 kernels.  This is because of a bug in the way that
>KVM emulates performance counter MSRs.  This was fixed upstream by this commit:
>
>http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa67e0d1f51842393606034051d805ab9948abd
>
>However, it fell into a strange window and missed both 2.6.25 and 2.6.26, but is
>now in 2.6.27 (which means F-10 will be just fine).  In the interest of helping
>out the Fedora users (especially for Bugzilla bug 462177 and duplicates), I
>backported this very simple patch to the current head of F-9 CVS (2.6.26.5).
>The patch is attached.  If there are no objections, can someone please commit this?

Attached where?  Has the Zimbra patch goblin eaten it again?

josh



From clalance at redhat.com  Wed Sep 17 15:21:45 2008
From: clalance at redhat.com (Chris Lalancette)
Date: Wed, 17 Sep 2008 17:21:45 +0200
Subject: [PATCH]: Backport KVM Intel MSR fix
In-Reply-To: <20080917152052.GA2366@yoda.jdub.homelinux.org>
References: <48D114E5.302@redhat.com>
	<20080917152052.GA2366@yoda.jdub.homelinux.org>
Message-ID: <48D12089.4080904@redhat.com>

Josh Boyer wrote:
> On Wed, Sep 17, 2008 at 04:32:05PM +0200, Chris Lalancette wrote:
>> All,
>>     Currently, RHEL-4.7 and RHEL-5.3(preview) KVM guests will crash on bootup
>> on Intel machines running F-9 kernels.  This is because of a bug in the way that
>> KVM emulates performance counter MSRs.  This was fixed upstream by this commit:
>>
>> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=efa67e0d1f51842393606034051d805ab9948abd
>>
>> However, it fell into a strange window and missed both 2.6.25 and 2.6.26, but is
>> now in 2.6.27 (which means F-10 will be just fine).  In the interest of helping
>> out the Fedora users (especially for Bugzilla bug 462177 and duplicates), I
>> backported this very simple patch to the current head of F-9 CVS (2.6.26.5).
>> The patch is attached.  If there are no objections, can someone please commit this?
> 
> Attached where?  Has the Zimbra patch goblin eaten it again?

Yes, apparently it has, since my outgoing mail shows it attached.  Hm, let's try
this another way then; patch is available here:

http://people.redhat.com/clalance/linux-2.6.26-intel-msr-backport.patch

Thanks,
-- 
Chris Lalancette



From kyle at mcmartin.ca  Wed Sep 17 21:59:27 2008
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Wed, 17 Sep 2008 17:59:27 -0400
Subject: [PATCH]: Backport KVM Intel MSR fix
In-Reply-To: <48D12089.4080904@redhat.com>
References: <48D114E5.302@redhat.com>
	<20080917152052.GA2366@yoda.jdub.homelinux.org>
	<48D12089.4080904@redhat.com>
Message-ID: <20080917215927.GA21208@phobos.i.cabal.ca>

On Wed, Sep 17, 2008 at 05:21:45PM +0200, Chris Lalancette wrote:
>

Looks fine... Appliedinated.



From clalance at redhat.com  Thu Sep 18 06:43:00 2008
From: clalance at redhat.com (Chris Lalancette)
Date: Thu, 18 Sep 2008 08:43:00 +0200
Subject: [PATCH]: Backport KVM Intel MSR fix
In-Reply-To: <20080917215927.GA21208@phobos.i.cabal.ca>
References: <48D114E5.302@redhat.com>	<20080917152052.GA2366@yoda.jdub.homelinux.org>	<48D12089.4080904@redhat.com>
	<20080917215927.GA21208@phobos.i.cabal.ca>
Message-ID: <48D1F874.2070100@redhat.com>

Kyle McMartin wrote:
> On Wed, Sep 17, 2008 at 05:21:45PM +0200, Chris Lalancette wrote:
> 
> Looks fine... Appliedinated.

Excellent, thanks!

-- 
Chris Lalancette



From levigate at suinprod.ro  Thu Sep 18 20:11:45 2008
From: levigate at suinprod.ro (Toby Voskowsky)
Date: Thu, 18 Sep 2008 20:11:45 +0000
Subject: :(
Message-ID: <6085661401.20080918195651@suinprod.ro>


 Neew cassino
	http://k3axlw.bay.livefilestore.com/y1p22_Eh2ahjbHEbry5iu_L8teJOnjHHW5Wm2YCxu84MVxRa34PCqbrej5PPNkI9MPyDxX5GkE_1F0RDKSe-0PSug/e4wtjwty44js.html

	


Thereon. In even his childhood, he became an object every
one of which demands the exhibition of wrath. I shall exist
all alone with knowledge only for what senseless, disjointed,
and improper words the festivities (in view of her marriage).
and.	

From notting at redhat.com  Thu Sep 18 19:13:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 18 Sep 2008 12:13:55 -0700
Subject: de-modularising for the win!
Message-ID: <20080918191355.GA9683@nostromo.devel.redhat.com>

See various and sundry plumber's conf discussions.

Comments? (The netfilter stuff needs further investigation.)

Bill
-------------- next part --------------
? patch-2.6.27-rc1-git2.bz2
? patch-2.6.27-rc1.bz2
Index: config-generic
===================================================================
RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v
retrieving revision 1.166
diff -u -r1.166 config-generic
--- config-generic	9 Sep 2008 06:16:19 -0000	1.166
+++ config-generic	18 Sep 2008 19:12:12 -0000
@@ -333,7 +333,7 @@
 CONFIG_CISS_SCSI_TAPE=y
 CONFIG_BLK_DEV_DAC960=m
 CONFIG_BLK_DEV_UMEM=m
-CONFIG_BLK_DEV_LOOP=m
+CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_CRYPTOLOOP=m
 CONFIG_BLK_DEV_NBD=m
 CONFIG_BLK_DEV_RAM=y
@@ -427,7 +427,7 @@
 #
 # SCSI device support
 #
-CONFIG_SCSI=m
+CONFIG_SCSI=y
 
 CONFIG_SCSI_ENCLOSURE=m
 CONFIG_SCSI_PROC_FS=y
@@ -448,7 +448,7 @@
 CONFIG_BLK_DEV_SD=y
 CONFIG_CHR_DEV_ST=m
 CONFIG_CHR_DEV_OSST=m
-CONFIG_BLK_DEV_SR=m
+CONFIG_BLK_DEV_SR=y
 CONFIG_BLK_DEV_SR_VENDOR=y
 CONFIG_CHR_DEV_SG=y
 CONFIG_CHR_DEV_SCH=m
@@ -508,11 +508,11 @@
 
 CONFIG_ATA=y
 CONFIG_ATA_SFF=y
-CONFIG_ATA_PIIX=m
+CONFIG_ATA_PIIX=y
 CONFIG_ATA_ACPI=y
 CONFIG_BLK_DEV_SX8=m
 CONFIG_PDC_ADMA=m
-CONFIG_SATA_AHCI=m
+CONFIG_SATA_AHCI=y
 CONFIG_SATA_INIC162X=m
 CONFIG_SATA_MV=m
 CONFIG_SATA_NV=m
@@ -636,7 +636,7 @@
 CONFIG_MD_RAID5_RESHAPE=y
 CONFIG_MD_RAID10=m
 CONFIG_MD_RAID456=m
-CONFIG_BLK_DEV_DM=m
+CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_DM_DEBUG=y
 # CONFIG_DM_DELAY is not set
@@ -790,7 +790,7 @@
 CONFIG_NETFILTER_NETLINK=m
 CONFIG_NETFILTER_NETLINK_QUEUE=m
 CONFIG_NETFILTER_NETLINK_LOG=m
-CONFIG_NETFILTER_XTABLES=m
+CONFIG_NETFILTER_XTABLES=y
 CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
 CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
 CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
@@ -808,7 +808,7 @@
 CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
 CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
 CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
-CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
 CONFIG_NETFILTER_XT_MATCH_DCCP=m
 CONFIG_NETFILTER_XT_MATCH_DSCP=m
 CONFIG_NETFILTER_XT_MATCH_ESP=m
@@ -841,7 +841,7 @@
 #
 # IP: Netfilter Configuration
 #
-CONFIG_NF_CONNTRACK_ENABLED=m
+CONFIG_NF_CONNTRACK_ENABLED=y
 
 CONFIG_NF_CT_ACCT=y
 CONFIG_NF_CONNTRACK_MARK=y
@@ -857,8 +857,8 @@
 CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
-CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_NF_CONNTRACK_IPV6=m
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_NF_CONNTRACK_IPV6=y
 CONFIG_NF_NAT=m
 CONFIG_NF_NAT_SNMP_BASIC=m
 CONFIG_NF_CT_PROTO_DCCP=m
@@ -1284,7 +1284,7 @@
 CONFIG_WLAN_80211=y
 # CONFIG_PCMCIA_RAYCS is not set
 
-CONFIG_MAC80211=m
+CONFIG_MAC80211=y
 CONFIG_MAC80211_QOS=y
 CONFIG_MAC80211_RC_DEFAULT_PID=y
 # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set
@@ -1299,7 +1299,7 @@
 # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
 # CONFIG_MAC80211_DEBUG is not set
 
-CONFIG_IEEE80211=m
+CONFIG_IEEE80211=y
 CONFIG_IEEE80211_DEBUG=y
 CONFIG_IEEE80211_CRYPT_WEP=m
 CONFIG_IEEE80211_CRYPT_CCMP=m
@@ -2461,17 +2461,17 @@
 #
 # Advanced Linux Sound Architecture
 #
-CONFIG_SND=m
+CONFIG_SND=y
 CONFIG_SND_VERBOSE_PROCFS=y
-CONFIG_SND_SEQUENCER=m
+CONFIG_SND_SEQUENCER=y
 CONFIG_SND_SEQ_DUMMY=m
 CONFIG_SND_SEQUENCER_OSS=y
 CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
 CONFIG_SND_OSSEMUL=y
-CONFIG_SND_MIXER_OSS=m
-CONFIG_SND_PCM_OSS=m
+CONFIG_SND_MIXER_OSS=y
+CONFIG_SND_PCM_OSS=y
 CONFIG_SND_PCM_OSS_PLUGINS=y
-CONFIG_SND_RTCTIMER=m
+CONFIG_SND_RTCTIMER=y
 CONFIG_SND_DYNAMIC_MINORS=y
 # CONFIG_SND_SUPPORT_OLD_API is not set
 
@@ -2528,7 +2528,7 @@
 CONFIG_SND_ES1968=m
 CONFIG_SND_FM801=m
 CONFIG_SND_FM801_TEA575X_BOOL=y
-CONFIG_SND_HDA_INTEL=m
+CONFIG_SND_HDA_INTEL=y
 CONFIG_SND_HDA_HWDEP=y
 CONFIG_SND_HDA_CODEC_REALTEK=y
 CONFIG_SND_HDA_CODEC_ANALOG=y
@@ -2545,7 +2545,7 @@
 CONFIG_SND_HIFIER=m
 CONFIG_SND_ICE1712=m
 CONFIG_SND_ICE1724=m
-CONFIG_SND_INTEL8X0=m
+CONFIG_SND_INTEL8X0=y
 CONFIG_SND_INTEL8X0M=m
 CONFIG_SND_KORG1212=m
 CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y
@@ -2886,7 +2886,7 @@
 CONFIG_EXT2_FS_POSIX_ACL=y
 CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT2_FS_XIP=y
-CONFIG_EXT3_FS=m
+CONFIG_EXT3_FS=y
 CONFIG_EXT3_FS_XATTR=y
 CONFIG_EXT3_FS_POSIX_ACL=y
 CONFIG_EXT3_FS_SECURITY=y
@@ -3199,6 +3199,7 @@
 #
 CONFIG_CRYPTO=y
 CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_BLKCIPHER=y
 CONFIG_CRYPTO_MANAGER=m
 # CONFIG_CRYPTO_CRYPTD is not set
 CONFIG_CRYPTO_AES=m
Index: config-x86-generic
===================================================================
RCS file: /cvs/extras/rpms/kernel/devel/config-x86-generic,v
retrieving revision 1.47
diff -u -r1.47 config-x86-generic
--- config-x86-generic	27 Jul 2008 07:22:15 -0000	1.47
+++ config-x86-generic	18 Sep 2008 19:12:12 -0000
@@ -127,12 +127,12 @@
 CONFIG_X86_MPPARSE=y
 
 CONFIG_ACPI=y
-CONFIG_ACPI_AC=m
+CONFIG_ACPI_AC=y
 # CONFIG_ACPI_ASUS is not set
 CONFIG_ACPI_PROCFS_POWER=y
 CONFIG_ACPI_SYSFS_POWER=y
-CONFIG_ACPI_BATTERY=m
-CONFIG_ACPI_BAY=m
+CONFIG_ACPI_BATTERY=y
+CONFIG_ACPI_BAY=y
 CONFIG_ACPI_BLACKLIST_YEAR=1999
 CONFIG_ACPI_BUTTON=y
 CONFIG_ACPI_CONTAINER=m

From tcallawa at redhat.com  Thu Sep 18 21:14:14 2008
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 18 Sep 2008 17:14:14 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <1221772454.19018.21.camel@localhost.localdomain>

On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.
> 
> Comments? (The netfilter stuff needs further investigation.)

Fly on the wall here, but wouldn't demodularizing the SCSI stack cause
problems down the road for RHEL, for third party SCSI/FC drivers?

~spot



From Matt_Domsch at dell.com  Thu Sep 18 21:27:50 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Thu, 18 Sep 2008 16:27:50 -0500
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <20080918212750.GB9736@mock.linuxdev.us.dell.com>

On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.
> 
> Comments? (The netfilter stuff needs further investigation.)

This _is_ Fedora we're talking about, not RHEL, right? :-)
/me has had to replace way too many kernel modules from RHEL, which
can't be done if it's built-in.

But Fedora, where we could ship a new kernel every day if we had to?
Sure.

In this most drivers are still modular, just the often-used hotpaths
are built-in, right?  This avoids extra TLB lookups?  Whatever
happened to mapping modules into the extra space at the end of the
kernel's 2MB TLB entries, to get the same benefit?


-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From arjan at infradead.org  Thu Sep 18 21:40:51 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Thu, 18 Sep 2008 14:40:51 -0700
Subject: de-modularising for the win!
In-Reply-To: <1221772454.19018.21.camel@localhost.localdomain>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221772454.19018.21.camel@localhost.localdomain>
Message-ID: <20080918144051.4736bde5@infradead.org>

On Thu, 18 Sep 2008 17:14:14 -0400
"Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:

> On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
> > See various and sundry plumber's conf discussions.
> > 
> > Comments? (The netfilter stuff needs further investigation.)
> 
> Fly on the wall here, but wouldn't demodularizing the SCSI stack cause
> problems down the road for RHEL, for third party SCSI/FC drivers?

Fedora != RHEL

In RHEL the performance / update tradeoff is likely different than for
Fedora.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From notting at redhat.com  Thu Sep 18 21:45:15 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 18 Sep 2008 14:45:15 -0700
Subject: de-modularising for the win!
In-Reply-To: <1221772454.19018.21.camel@localhost.localdomain>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221772454.19018.21.camel@localhost.localdomain>
Message-ID: <20080918214515.GA4754@nostromo.devel.redhat.com>

Tom spot Callaway (tcallawa at redhat.com) said: 
> On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
> > See various and sundry plumber's conf discussions.
> > 
> > Comments? (The netfilter stuff needs further investigation.)
> 
> Fly on the wall here, but wouldn't demodularizing the SCSI stack cause
> problems down the road for RHEL, for third party SCSI/FC drivers?

Well, that option doesn't appear to actually do anything, considering
the fact that it's set to 'm' now and the scsi core isn't actually
modular. So we may be able to ignore that one.

Bill



From arjan at infradead.org  Thu Sep 18 21:59:00 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Thu, 18 Sep 2008 14:59:00 -0700
Subject: de-modularising for the win!
In-Reply-To: <20080918212750.GB9736@mock.linuxdev.us.dell.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<20080918212750.GB9736@mock.linuxdev.us.dell.com>
Message-ID: <20080918145900.6eb0c4ac@infradead.org>

On Thu, 18 Sep 2008 16:27:50 -0500
Matt Domsch <Matt_Domsch at dell.com> wrote:

> In this most drivers are still modular, just the often-used hotpaths
> are built-in, right?  This avoids extra TLB lookups?  Whatever
> happened to mapping modules into the extra space at the end of the
> kernel's 2MB TLB entries, to get the same benefit?

it's a lot more than that; it's also about boot speed;
module loading is just slow by nature, and while it can be made a bit
faster, fundamentally, avoiding it for common cases is just the better
solution.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From davej at redhat.com  Thu Sep 18 22:31:28 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 18:31:28 -0400
Subject: de-modularising for the win!
In-Reply-To: <1221772454.19018.21.camel@localhost.localdomain>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221772454.19018.21.camel@localhost.localdomain>
Message-ID: <20080918223128.GA26667@redhat.com>

On Thu, Sep 18, 2008 at 05:14:14PM -0400, Tom spot Callaway wrote:
 > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
 > > See various and sundry plumber's conf discussions.
 > > 
 > > Comments? (The netfilter stuff needs further investigation.)
 > 
 > Fly on the wall here, but wouldn't demodularizing the SCSI stack cause
 > problems down the road for RHEL, for third party SCSI/FC drivers?

if a vendor is shipping their own scsi_mod or other part
of the scsi layer to replace modules we ship, they may be DOING IT WRONG.

	Dave

-- 
http://www.codemonkey.org.uk



From davej at redhat.com  Thu Sep 18 22:35:19 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 18:35:19 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918212750.GB9736@mock.linuxdev.us.dell.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<20080918212750.GB9736@mock.linuxdev.us.dell.com>
Message-ID: <20080918223519.GB26667@redhat.com>

On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote:

 > This _is_ Fedora we're talking about, not RHEL, right? :-)
 > /me has had to replace way too many kernel modules from RHEL, which
 > can't be done if it's built-in.

The thing is, Dell or any other vendor having to ship their
own module is to me a sign of a failing in the RHEL process that we
can't get fastpath pre-next-U release packages out fast enough.
THAT should be fixed rather than holding back Fedora
(or even RHEL, as it would be a shame that it couldn't take
 advantage of these wins)

	Dave

-- 
http://www.codemonkey.org.uk



From davej at redhat.com  Thu Sep 18 22:42:03 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 18:42:03 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <20080918224203.GC26667@redhat.com>

On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
 > See various and sundry plumber's conf discussions.
 > 
 > Comments? (The netfilter stuff needs further investigation.)

looks like some of the lower-hanging fruit.
definite room for further expansion.

how well will mkinitrd cope when modules it always loads
don't exist any more?  any nasty hardcoded bits there?

	Dave

-- 
http://www.codemonkey.org.uk



From csnook at redhat.com  Thu Sep 18 22:42:22 2008
From: csnook at redhat.com (Chris Snook)
Date: Thu, 18 Sep 2008 18:42:22 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <48D2D94E.2020902@redhat.com>

Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.

Links please?

> Comments? (The netfilter stuff needs further investigation.)

-CONFIG_BLK_DEV_LOOP=m
+CONFIG_BLK_DEV_LOOP=y
-CONFIG_SCSI=m
+CONFIG_SCSI=y
-CONFIG_BLK_DEV_SR=m
+CONFIG_BLK_DEV_SR=y
-CONFIG_ATA_PIIX=m
+CONFIG_ATA_PIIX=y
-CONFIG_SATA_AHCI=m
+CONFIG_SATA_AHCI=y
-CONFIG_BLK_DEV_DM=m
+CONFIG_BLK_DEV_DM=y

If this is going to make it easier to do fancy things in the initrd, I'm all for 
it.  If it's just a TLB thing, I don't think it's worth it.

-CONFIG_MAC80211=m
+CONFIG_MAC80211=y
-CONFIG_IEEE80211=m
+CONFIG_IEEE80211=y

Won't this make it harder for people to test experimental wireless drivers? 
Unless the vendors start opening specs, we're going to have a perpetual need to 
play around in this area with each new hardware rev.

-CONFIG_SND=m
+CONFIG_SND=y
-CONFIG_SND_SEQUENCER=m
+CONFIG_SND_SEQUENCER=y
-CONFIG_SND_MIXER_OSS=m
-CONFIG_SND_PCM_OSS=m
+CONFIG_SND_MIXER_OSS=y
+CONFIG_SND_PCM_OSS=y
-CONFIG_SND_RTCTIMER=m
+CONFIG_SND_RTCTIMER=y
-CONFIG_SND_HDA_INTEL=m
+CONFIG_SND_HDA_INTEL=y
-CONFIG_SND_INTEL8X0=m
+CONFIG_SND_INTEL8X0=y

For the love of god, no.  We have lots of sound problems that require modprobe 
magic to troubleshoot and work around.  This will require people to rebuild 
their kernel just to test sound fixes, which will scare away an awful lot of 
testers and inconvenience the rest.

-CONFIG_EXT3_FS=m
+CONFIG_EXT3_FS=y

I've been wondering for years why we weren't already doing this.

-- Chris



From sandeen at redhat.com  Thu Sep 18 23:00:58 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 18 Sep 2008 16:00:58 -0700
Subject: de-modularising for the win!
In-Reply-To: <48D2D94E.2020902@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<48D2D94E.2020902@redhat.com>
Message-ID: <48D2DDAA.6060301@redhat.com>

Chris Snook wrote:
> Bill Nottingham wrote:
>> See various and sundry plumber's conf discussions.


> -CONFIG_MAC80211=m
> +CONFIG_MAC80211=y
> -CONFIG_IEEE80211=m
> +CONFIG_IEEE80211=y
> 
> Won't this make it harder for people to test experimental wireless drivers? 
> Unless the vendors start opening specs, we're going to have a perpetual need to 
> play around in this area with each new hardware rev.

I have this concern (brought it up before with Arjan too...) about
filesystem stuff.  For testing this means I can't lazily load my own
custom modules into a pre-built kernel but oh well... it does make it
harder to deliver test modules to users though.

> -CONFIG_SND=m
> +CONFIG_SND=y
> -CONFIG_SND_SEQUENCER=m
> +CONFIG_SND_SEQUENCER=y
> -CONFIG_SND_MIXER_OSS=m
> -CONFIG_SND_PCM_OSS=m
> +CONFIG_SND_MIXER_OSS=y
> +CONFIG_SND_PCM_OSS=y
> -CONFIG_SND_RTCTIMER=m
> +CONFIG_SND_RTCTIMER=y
> -CONFIG_SND_HDA_INTEL=m
> +CONFIG_SND_HDA_INTEL=y
> -CONFIG_SND_INTEL8X0=m
> +CONFIG_SND_INTEL8X0=y
> 
> For the love of god, no.  We have lots of sound problems that require modprobe 
> magic to troubleshoot and work around.  This will require people to rebuild 
> their kernel just to test sound fixes, which will scare away an awful lot of 
> testers and inconvenience the rest.

does sound have to be initialized as part of the boot process?

> -CONFIG_EXT3_FS=m
> +CONFIG_EXT3_FS=y
> 
> I've been wondering for years why we weren't already doing this.

see above, but I can live with it.  Will we add ext4 and xfs (and
reiserfs and jfs) too?

-Eric



From pjones at redhat.com  Thu Sep 18 23:15:58 2008
From: pjones at redhat.com (Peter Jones)
Date: Thu, 18 Sep 2008 19:15:58 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918224203.GC26667@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<20080918224203.GC26667@redhat.com>
Message-ID: <48D2E12E.7090001@redhat.com>

Dave Jones wrote:
> On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
>  > See various and sundry plumber's conf discussions.
>  > 
>  > Comments? (The netfilter stuff needs further investigation.)
> 
> looks like some of the lower-hanging fruit.
> definite room for further expansion.
> 
> how well will mkinitrd cope when modules it always loads
> don't exist any more?  any nasty hardcoded bits there?

The biggest issue there will be that we've got a list of stuff that's 
supposed happen before scsi loads... but in reality, I don't think we care.

If you can build me a scratch kernel once we're done deciding what to 
demodularize, fixing mkinitrd afterwards shouldn't be a very difficult task.



From pjones at redhat.com  Thu Sep 18 23:31:34 2008
From: pjones at redhat.com (Peter Jones)
Date: Thu, 18 Sep 2008 19:31:34 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <48D2E4D6.8010609@redhat.com>

Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.
> 
> Comments? (The netfilter stuff needs further investigation.)

Also, please add these, since they're nearly always loaded (patch is on 
top of yours):

diff --git a/config-generic b/config-generic
index 0f43c42..de33831 100644
--- a/config-generic
+++ b/config-generic
@@ -640,14 +640,14 @@ CONFIG_BLK_DEV_DM=y
  CONFIG_DM_CRYPT=m
  CONFIG_DM_DEBUG=y
  # CONFIG_DM_DELAY is not set
-CONFIG_DM_MIRROR=m
+CONFIG_DM_MIRROR=y
  CONFIG_DM_MULTIPATH=m
  CONFIG_DM_MULTIPATH_EMC=m
  CONFIG_DM_MULTIPATH_HP=m
  CONFIG_DM_MULTIPATH_RDAC=m
-CONFIG_DM_SNAPSHOT=m
+CONFIG_DM_SNAPSHOT=y
  CONFIG_DM_UEVENT=y
-CONFIG_DM_ZERO=m
+CONFIG_DM_ZERO=y

  #
  # Fusion MPT device support



From Matt_Domsch at dell.com  Thu Sep 18 23:39:58 2008
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Thu, 18 Sep 2008 18:39:58 -0500
Subject: de-modularising for the win!
In-Reply-To: <20080918223519.GB26667@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<20080918212750.GB9736@mock.linuxdev.us.dell.com>
	<20080918223519.GB26667@redhat.com>
Message-ID: <20080918233958.GA7059@auslistsprd01.us.dell.com>

On Thu, Sep 18, 2008 at 06:35:19PM -0400, Dave Jones wrote:
> On Thu, Sep 18, 2008 at 04:27:50PM -0500, Matt Domsch wrote:
> 
>  > This _is_ Fedora we're talking about, not RHEL, right? :-)
>  > /me has had to replace way too many kernel modules from RHEL, which
>  > can't be done if it's built-in.
> 
> The thing is, Dell or any other vendor having to ship their
> own module is to me a sign of a failing in the RHEL process that we
> can't get fastpath pre-next-U release packages out fast enough.
> THAT should be fixed rather than holding back Fedora
> (or even RHEL, as it would be a shame that it couldn't take
>  advantage of these wins)

(brief digression of Fedora is not RHEL, yes, we know, that's a good thing...)

It's less a problem of fasttrack, it's more like the z-stream stuff.
Where we've had to replace modules (or hey, subsystems a couple times)
it was to keep the exact same kernel, but overlay specific targeted
"fixes".  Dell doesn't respin the whole factory install image very
often (generally only respin once during the sales life of a given
RHEL version), we replace the specific bits that we absolutely must,
and nothing else, while at the same time ensuring those same fixes are
in the next update kernel.  This way, customers who are sticking to
one specific kernel for whatever reasons can get the fix they need,
while customers pulling the latest updates from Red Hat get those same
fixes.

This said, while I've replaced the MD, USB, and SATA subsystems a few
times, and the SCSI layer, I don't recall having to replace ext*
(knock on wood).

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From katzj at redhat.com  Thu Sep 18 23:42:15 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 18 Sep 2008 19:42:15 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <1221781335.15361.1.camel@aglarond.local>

On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.

If we build in the loop module, we need to bump the default of number of
loopdevs[1] to keep things happier for live images.  Right now, we just
set maxloop in modprobe.conf

Jeremy

[1] Or someone can dig up the patches for dynamic loop allocation and
finish them off :-)



From davej at redhat.com  Thu Sep 18 23:47:04 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 19:47:04 -0400
Subject: de-modularising for the win!
In-Reply-To: <1221781335.15361.1.camel@aglarond.local>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
Message-ID: <20080918234704.GD26667@redhat.com>

On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote:
 > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
 > > See various and sundry plumber's conf discussions.
 > 
 > If we build in the loop module, we need to bump the default of number of
 > loopdevs[1] to keep things happier for live images.  Right now, we just
 > set maxloop in modprobe.conf

does it not appear configurable in sysfs someplace?

	Dave

-- 
http://www.codemonkey.org.uk



From katzj at redhat.com  Thu Sep 18 23:49:33 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 18 Sep 2008 19:49:33 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918234704.GD26667@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
	<20080918234704.GD26667@redhat.com>
Message-ID: <1221781773.15361.2.camel@aglarond.local>

On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote:
> On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote:
>  > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
>  > > See various and sundry plumber's conf discussions.
>  > 
>  > If we build in the loop module, we need to bump the default of number of
>  > loopdevs[1] to keep things happier for live images.  Right now, we just
>  > set maxloop in modprobe.conf
> 
> does it not appear configurable in sysfs someplace?

Unless something has changed from when I looked last, no.  The devices
are statically allocated on module(/built-in) load and that's as many as
you get.

Jeremy



From davej at redhat.com  Thu Sep 18 23:54:21 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 19:54:21 -0400
Subject: de-modularising for the win!
In-Reply-To: <1221781773.15361.2.camel@aglarond.local>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
	<20080918234704.GD26667@redhat.com>
	<1221781773.15361.2.camel@aglarond.local>
Message-ID: <20080918235421.GE26667@redhat.com>

On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote:
 > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote:
 > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote:
 > >  > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
 > >  > > See various and sundry plumber's conf discussions.
 > >  > 
 > >  > If we build in the loop module, we need to bump the default of number of
 > >  > loopdevs[1] to keep things happier for live images.  Right now, we just
 > >  > set maxloop in modprobe.conf
 > > 
 > > does it not appear configurable in sysfs someplace?
 > 
 > Unless something has changed from when I looked last, no.  The devices
 > are statically allocated on module(/built-in) load and that's as many as
 > you get.

ok, should be easy enough hack in anyway.

	Dave

-- 
http://www.codemonkey.org.uk



From davej at redhat.com  Thu Sep 18 23:57:02 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 18 Sep 2008 19:57:02 -0400
Subject: de-modularising for the win!
In-Reply-To: <1221781773.15361.2.camel@aglarond.local>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
	<20080918234704.GD26667@redhat.com>
	<1221781773.15361.2.camel@aglarond.local>
Message-ID: <20080918235702.GF26667@redhat.com>

On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote:
 > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote:
 > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote:
 > >  > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
 > >  > > See various and sundry plumber's conf discussions.
 > >  > 
 > >  > If we build in the loop module, we need to bump the default of number of
 > >  > loopdevs[1] to keep things happier for live images.  Right now, we just
 > >  > set maxloop in modprobe.conf
 > > 
 > > does it not appear configurable in sysfs someplace?
 > 
 > Unless something has changed from when I looked last, no.  The devices
 > are statically allocated on module(/built-in) load and that's as many as
 > you get.

how many do you typically need btw?

	Dave
-- 
http://www.codemonkey.org.uk



From katzj at redhat.com  Thu Sep 18 23:58:15 2008
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 18 Sep 2008 19:58:15 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918235702.GF26667@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
	<20080918234704.GD26667@redhat.com>
	<1221781773.15361.2.camel@aglarond.local>
	<20080918235702.GF26667@redhat.com>
Message-ID: <1221782296.15361.3.camel@aglarond.local>

On Thu, 2008-09-18 at 19:57 -0400, Dave Jones wrote:
> On Thu, Sep 18, 2008 at 07:49:33PM -0400, Jeremy Katz wrote:
>  > On Thu, 2008-09-18 at 19:47 -0400, Dave Jones wrote:
>  > > On Thu, Sep 18, 2008 at 07:42:15PM -0400, Jeremy Katz wrote:
>  > >  > On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
>  > >  > > See various and sundry plumber's conf discussions.
>  > >  > 
>  > >  > If we build in the loop module, we need to bump the default of number of
>  > >  > loopdevs[1] to keep things happier for live images.  Right now, we just
>  > >  > set maxloop in modprobe.conf
>  > > 
>  > > does it not appear configurable in sysfs someplace?
>  > 
>  > Unless something has changed from when I looked last, no.  The devices
>  > are statically allocated on module(/built-in) load and that's as many as
>  > you get.
> 
> how many do you typically need btw?

Been bumping to 16 on live images as the compromise between "we're using
a bunch just to get things working at all" vs "not using more is just
sucking up memory"

Jeremy



From csnook at redhat.com  Fri Sep 19 00:28:53 2008
From: csnook at redhat.com (Chris Snook)
Date: Thu, 18 Sep 2008 20:28:53 -0400
Subject: de-modularising for the win!
In-Reply-To: <48D2DDAA.6060301@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<48D2D94E.2020902@redhat.com> <48D2DDAA.6060301@redhat.com>
Message-ID: <48D2F245.4070804@redhat.com>

Eric Sandeen wrote:
> Chris Snook wrote:
>> -CONFIG_EXT3_FS=m
>> +CONFIG_EXT3_FS=y
>>
>> I've been wondering for years why we weren't already doing this.
> 
> see above, but I can live with it.  Will we add ext4 and xfs (and
> reiserfs and jfs) too?

Having one root-suitable filesystem built-in makes it easier to do a lot of 
atypical boot configurations, which are becoming rather interesting thanks to 
virtualization.  If we're going to pick one, I think ext3 makes the most sense. 
  I don't see a lot of benefit to building in xfs, reiserfs, or jfs, and I think 
we should definitely keep ext4 modular in its current stage of development.

-- Chris



From sandeen at redhat.com  Fri Sep 19 00:34:13 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Thu, 18 Sep 2008 17:34:13 -0700
Subject: de-modularising for the win!
In-Reply-To: <48D2F245.4070804@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<48D2D94E.2020902@redhat.com> <48D2DDAA.6060301@redhat.com>
	<48D2F245.4070804@redhat.com>
Message-ID: <48D2F385.5080404@redhat.com>

Chris Snook wrote:
> Eric Sandeen wrote:
>> Chris Snook wrote:
>>> -CONFIG_EXT3_FS=m
>>> +CONFIG_EXT3_FS=y
>>>
>>> I've been wondering for years why we weren't already doing this.
>> see above, but I can live with it.  Will we add ext4 and xfs (and
>> reiserfs and jfs) too?
> 
> Having one root-suitable filesystem built-in makes it easier to do a lot of 
> atypical boot configurations, which are becoming rather interesting thanks to 
> virtualization.  If we're going to pick one, I think ext3 makes the most sense. 
>   I don't see a lot of benefit to building in xfs, reiserfs, or jfs, and I think 
> we should definitely keep ext4 modular in its current stage of development.
> 
> -- Chris

Yeah, I agree, that's fair.  (I wasn't really too serious about linking
in every fs ...)  Optimizing for the common case(s) makes sense.

-Eric



From notting at redhat.com  Fri Sep 19 00:25:20 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 18 Sep 2008 17:25:20 -0700
Subject: de-modularising for the win!
In-Reply-To: <1221781335.15361.1.camel@aglarond.local>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1221781335.15361.1.camel@aglarond.local>
Message-ID: <20080919002520.GA8478@nostromo.devel.redhat.com>

> [1] Or someone can dig up the patches for dynamic loop allocation and
> finish them off :-)

Already exists. Try 'mknod loop23 ; losetup ...'...

Bill



From notting at redhat.com  Thu Sep 18 23:13:01 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 18 Sep 2008 16:13:01 -0700
Subject: de-modularising for the win!
In-Reply-To: <48D2D94E.2020902@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<48D2D94E.2020902@redhat.com>
Message-ID: <20080918231301.GA4734@nostromo.devel.redhat.com>

Chris Snook (csnook at redhat.com) said: 
>> See various and sundry plumber's conf discussions.
>
> Links please?

Not sure where things are being posted. Summary:

- modules are wasteful (you lose a good chunk of code size savings in
  page round up)
- modules are slow (well, modprobe is)
- for the modules that are used by 90% of machines, what's the point
  of having them static?
- killing the initrd for that general 90% case can be a big win


>> Comments? (The netfilter stuff needs further investigation.)
>
> -CONFIG_BLK_DEV_LOOP=m
> +CONFIG_BLK_DEV_LOOP=y
> -CONFIG_SCSI=m
> +CONFIG_SCSI=y
> -CONFIG_BLK_DEV_SR=m
> +CONFIG_BLK_DEV_SR=y
> -CONFIG_ATA_PIIX=m
> +CONFIG_ATA_PIIX=y
> -CONFIG_SATA_AHCI=m
> +CONFIG_SATA_AHCI=y
> -CONFIG_BLK_DEV_DM=m
> +CONFIG_BLK_DEV_DM=y
>
> If this is going to make it easier to do fancy things in the initrd, I'm 
> all for it.  If it's just a TLB thing, I don't think it's worth it.

Fancy things by not having the initrd.

> -CONFIG_MAC80211=m
> +CONFIG_MAC80211=y
> -CONFIG_IEEE80211=m
> +CONFIG_IEEE80211=y
>
> Won't this make it harder for people to test experimental wireless 
> drivers? Unless the vendors start opening specs, we're going to have a 
> perpetual need to play around in this area with each new hardware rev.

How so? There's one version shared among all the in-tree modules. If
you're developing the kernel, you're already rebuilding, so you can
do whatever.

> -CONFIG_SND=m
> +CONFIG_SND=y
> -CONFIG_SND_SEQUENCER=m
> +CONFIG_SND_SEQUENCER=y
> -CONFIG_SND_MIXER_OSS=m
> -CONFIG_SND_PCM_OSS=m
> +CONFIG_SND_MIXER_OSS=y
> +CONFIG_SND_PCM_OSS=y
> -CONFIG_SND_RTCTIMER=m
> +CONFIG_SND_RTCTIMER=y
> -CONFIG_SND_HDA_INTEL=m
> +CONFIG_SND_HDA_INTEL=y
> -CONFIG_SND_INTEL8X0=m
> +CONFIG_SND_INTEL8X0=y
>
> For the love of god, no.  We have lots of sound problems that require 
> modprobe magic to troubleshoot and work around. 

Fix the $*@* driver, then!

(FWIW, the only sound problems I've seen recently is that the volume
restore scripts got broken.)

> This will require people 
> to rebuild their kernel just to test sound fixes, which will scare away 
> an awful lot of testers and inconvenience the rest.

How often are we shipping random source patches to Fedora users, who
would have to install kernel-devel and kernel-source anyway, causing
them to download just as much data as a new test kernel?

Bill



From kraxel at redhat.com  Fri Sep 19 11:02:54 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Fri, 19 Sep 2008 13:02:54 +0200
Subject: de-modularising for the win!
In-Reply-To: <20080918231301.GA4734@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>	<48D2D94E.2020902@redhat.com>
	<20080918231301.GA4734@nostromo.devel.redhat.com>
Message-ID: <48D386DE.7050607@redhat.com>

Bill Nottingham wrote:
> - killing the initrd for that general 90% case can be a big win

You aren't going to kill the initrd for a default fedora install due to
root-on-lvm.

cheers,
  Gerd




From kraxel at redhat.com  Fri Sep 19 11:09:55 2008
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Fri, 19 Sep 2008 13:09:55 +0200
Subject: de-modularising for the win!
In-Reply-To: <20080918235702.GF26667@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>	<1221781335.15361.1.camel@aglarond.local>	<20080918234704.GD26667@redhat.com>	<1221781773.15361.2.camel@aglarond.local>
	<20080918235702.GF26667@redhat.com>
Message-ID: <48D38883.8030304@redhat.com>

Dave Jones wrote:
> how many do you typically need btw?

I usually set it to 64 when I find the default 8 devices are not
enougth.  Frequently happens to me in case I loop-mount a collection of
install iso images on a machine.  I didn't hit the 64 limit yet.  I've
already needed more than 32.  That was a while back though, with a
collection of CDs instead of one DVD per distro ...

cheers,
  Gerd



From jwboyer at gmail.com  Fri Sep 19 12:02:47 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 19 Sep 2008 08:02:47 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <20080919120247.GA3083@yoda.jdub.homelinux.org>

On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
>See various and sundry plumber's conf discussions.
>
>Comments? (The netfilter stuff needs further investigation.)
>
>Bill

>? patch-2.6.27-rc1-git2.bz2
>? patch-2.6.27-rc1.bz2
>Index: config-generic
>===================================================================
>RCS file: /cvs/extras/rpms/kernel/devel/config-generic,v
>retrieving revision 1.166
>diff -u -r1.166 config-generic
>--- config-generic	9 Sep 2008 06:16:19 -0000	1.166
>+++ config-generic	18 Sep 2008 19:12:12 -0000
 
>-CONFIG_MAC80211=m
>+CONFIG_MAC80211=y
> CONFIG_MAC80211_QOS=y
> CONFIG_MAC80211_RC_DEFAULT_PID=y
> # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set
>@@ -1299,7 +1299,7 @@
> # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
> # CONFIG_MAC80211_DEBUG is not set
> 
>-CONFIG_IEEE80211=m
>+CONFIG_IEEE80211=y
> CONFIG_IEEE80211_DEBUG=y
> CONFIG_IEEE80211_CRYPT_WEP=m
> CONFIG_IEEE80211_CRYPT_CCMP=m

Do we have a way to _not_ do this on secondary architectures?

>@@ -2528,7 +2528,7 @@
> CONFIG_SND_ES1968=m
> CONFIG_SND_FM801=m
> CONFIG_SND_FM801_TEA575X_BOOL=y
>-CONFIG_SND_HDA_INTEL=m
>+CONFIG_SND_HDA_INTEL=y
> CONFIG_SND_HDA_HWDEP=y
> CONFIG_SND_HDA_CODEC_REALTEK=y
> CONFIG_SND_HDA_CODEC_ANALOG=y
>@@ -2545,7 +2545,7 @@
> CONFIG_SND_HIFIER=m
> CONFIG_SND_ICE1712=m
> CONFIG_SND_ICE1724=m
>-CONFIG_SND_INTEL8X0=m
>+CONFIG_SND_INTEL8X0=y

See... like these two.  Not going to be in any ppc box, ever.  Why include
them in the generic kernel config?  I think they should be moved to
config-x86-generic.config instead.

josh



From linville at redhat.com  Fri Sep 19 13:59:14 2008
From: linville at redhat.com (John W. Linville)
Date: Fri, 19 Sep 2008 09:59:14 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <20080919135914.GA5343@redhat.com>

On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.
> 
> Comments? (The netfilter stuff needs further investigation.)

> @@ -1284,7 +1284,7 @@
>  CONFIG_WLAN_80211=y
>  # CONFIG_PCMCIA_RAYCS is not set
>  
> -CONFIG_MAC80211=m
> +CONFIG_MAC80211=y
>  CONFIG_MAC80211_QOS=y
>  CONFIG_MAC80211_RC_DEFAULT_PID=y
>  # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set

This helps a lot of drivers, but I have no idea what percentage
of Fedora users that represents.  Do we know what percentage that
_should_ be?  Do we have smolt data to support meeting that percentage?
I suspect that this is just a waste of memory for most desktop (as
opposed to laptop) users.

Also, as someone pointed out it is still common practice for people
to run the compat-wireless package of back-ported drivers (and the
matching mac80211 components).  This might make life more difficult
for those users.  (NOTE: these are not the typical "out of tree"
drivers -- they are in-tree, just a different, later tree.)

Finally, _if_ we build these in then we should probable build-in the
crypto modules that mac80211 requests...

> @@ -1299,7 +1299,7 @@
>  # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
>  # CONFIG_MAC80211_DEBUG is not set
>  
> -CONFIG_IEEE80211=m
> +CONFIG_IEEE80211=y
>  CONFIG_IEEE80211_DEBUG=y
>  CONFIG_IEEE80211_CRYPT_WEP=m
>  CONFIG_IEEE80211_CRYPT_CCMP=m

This only helps two drivers, ipw2100 and ipw2200.  I don't think this
is worthwhile.

And FWIW, I ACK all the non-wireless bits! :-)

John
-- 
John W. Linville
linville at redhat.com



From csnook at redhat.com  Fri Sep 19 15:35:30 2008
From: csnook at redhat.com (Chris Snook)
Date: Fri, 19 Sep 2008 11:35:30 -0400
Subject: de-modularising for the win!
In-Reply-To: <48D386DE.7050607@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>	<48D2D94E.2020902@redhat.com>	<20080918231301.GA4734@nostromo.devel.redhat.com>
	<48D386DE.7050607@redhat.com>
Message-ID: <48D3C6C2.2050404@redhat.com>

Gerd Hoffmann wrote:
> Bill Nottingham wrote:
>> - killing the initrd for that general 90% case can be a big win
> 
> You aren't going to kill the initrd for a default fedora install due to
> root-on-lvm.

For the people who care the most about this, putting / on a partition is a very 
low hurdle compared to the other things they're trying to accomplish.

-- Chris



From arjan at infradead.org  Fri Sep 19 16:17:09 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Fri, 19 Sep 2008 09:17:09 -0700
Subject: de-modularising for the win!
In-Reply-To: <48D386DE.7050607@redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<48D2D94E.2020902@redhat.com>
	<20080918231301.GA4734@nostromo.devel.redhat.com>
	<48D386DE.7050607@redhat.com>
Message-ID: <20080919091709.7a75e740@infradead.org>

On Fri, 19 Sep 2008 13:02:54 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:

> Bill Nottingham wrote:
> > - killing the initrd for that general 90% case can be a big win
> 
> You aren't going to kill the initrd for a default fedora install due
> to root-on-lvm.

why do we have root-on-lvm by default on laptops again?


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From davej at redhat.com  Fri Sep 19 19:55:50 2008
From: davej at redhat.com (Dave Jones)
Date: Fri, 19 Sep 2008 15:55:50 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080919120247.GA3083@yoda.jdub.homelinux.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<20080919120247.GA3083@yoda.jdub.homelinux.org>
Message-ID: <20080919195550.GA5194@redhat.com>

On Fri, Sep 19, 2008 at 08:02:47AM -0400, Josh Boyer wrote:

 > >-CONFIG_IEEE80211=m
 > >+CONFIG_IEEE80211=y
 > > CONFIG_IEEE80211_DEBUG=y
 > > CONFIG_IEEE80211_CRYPT_WEP=m
 > > CONFIG_IEEE80211_CRYPT_CCMP=m
 > 
 > Do we have a way to _not_ do this on secondary architectures?

the per-arch config fragments will always override
options in config-generic, so yes.

 > >-CONFIG_SND_HDA_INTEL=m
 > >+CONFIG_SND_HDA_INTEL=y
 > > CONFIG_SND_HDA_HWDEP=y
 > > CONFIG_SND_HDA_CODEC_REALTEK=y
 > > CONFIG_SND_HDA_CODEC_ANALOG=y
 > >@@ -2545,7 +2545,7 @@
 > > CONFIG_SND_HIFIER=m
 > > CONFIG_SND_ICE1712=m
 > > CONFIG_SND_ICE1724=m
 > >-CONFIG_SND_INTEL8X0=m
 > >+CONFIG_SND_INTEL8X0=y
 > 
 > See... like these two.  Not going to be in any ppc box, ever.  Why include
 > them in the generic kernel config?  I think they should be moved to
 > config-x86-generic.config instead.

They got dumped in config-generic instead of duping them
in config-x86[64] and config-ia64, but yeah, could do.
if the options don't exist on an arch though it's competely
benign regardless of what they get set to.

	Dave

-- 
http://www.codemonkey.org.uk



From notting at redhat.com  Sat Sep 20 10:53:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 20 Sep 2008 06:53:55 -0400
Subject: (no subject)
Message-ID: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>

Subject: Re: de-modularising for the win!
Message-ID: <20080920105355.GA6663 at nostromo.devel.redhat.com>
References: <20080918191355.GA9683 at nostromo.devel.redhat.com> <48D2D94E.2020902 at redhat.com> <20080918231301.GA4734 at nostromo.devel.redhat.com> <1221790735.15361.152.camel at aglarond.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1221790735.15361.152.camel at aglarond.local>
User-Agent: Mutt/1.5.18 (2008-05-17)

Jeremy Katz (katzj at redhat.com) said: 
> On Thu, 2008-09-18 at 16:13 -0700, Bill Nottingham wrote:
> > - killing the initrd for that general 90% case can be a big win
> 
> Ermm, the general 90% (or some large-ish generalizing percentage) are
> set up to use LVM.  Which then requires an initrd.

Yes, but ... LVM is overkill, in general. (That's another discussion.)

On further consideration, though, the biggest issue with kicking out
the initrd is getting the policy lodaed.

Bill



From kyle at redhat.com  Sat Sep 20 17:13:38 2008
From: kyle at redhat.com (Kyle McMartin)
Date: Sat, 20 Sep 2008 13:13:38 -0400
Subject: (no subject)
In-Reply-To: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>
References: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>
Message-ID: <20080920171338.GC24017@phobos.i.cabal.ca>

On Sat, Sep 20, 2008 at 06:53:55AM -0400, Bill Nottingham wrote:
> Subject: Re: de-modularising for the win!
> Message-ID: <20080920105355.GA6663 at nostromo.devel.redhat.com>
> References: <20080918191355.GA9683 at nostromo.devel.redhat.com> <48D2D94E.2020902 at redhat.com> <20080918231301.GA4734 at nostromo.devel.redhat.com> <1221790735.15361.152.camel at aglarond.local>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <1221790735.15361.152.camel at aglarond.local>
> User-Agent: Mutt/1.5.18 (2008-05-17)
> 
> Jeremy Katz (katzj at redhat.com) said: 
> > On Thu, 2008-09-18 at 16:13 -0700, Bill Nottingham wrote:
> > > - killing the initrd for that general 90% case can be a big win
> > 
> > Ermm, the general 90% (or some large-ish generalizing percentage) are
> > set up to use LVM.  Which then requires an initrd.
> 
> Yes, but ... LVM is overkill, in general. (That's another discussion.)
> 
> On further consideration, though, the biggest issue with kicking out
> the initrd is getting the policy lodaed.
> 

But, won't we all be using btrfs instead of lvm in F11? ;-)



From arjan at infradead.org  Sat Sep 20 17:22:31 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 20 Sep 2008 10:22:31 -0700
Subject: (no subject)
In-Reply-To: <20080920171338.GC24017@phobos.i.cabal.ca>
References: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>
	<20080920171338.GC24017@phobos.i.cabal.ca>
Message-ID: <20080920102231.067ddbb9@infradead.org>

On Sat, 20 Sep 2008 13:13:38 -0400
Kyle McMartin <kyle at redhat.com> wrote:

> > On further consideration, though, the biggest issue with kicking out
> > the initrd is getting the policy lodaed.

/me wonders about the option of having selinux using
request_firmware() to get its policy

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From sandeen at redhat.com  Mon Sep 22 03:01:00 2008
From: sandeen at redhat.com (Eric Sandeen)
Date: Sun, 21 Sep 2008 22:01:00 -0500
Subject: (no subject)
In-Reply-To: <20080920171338.GC24017@phobos.i.cabal.ca>
References: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>
	<20080920171338.GC24017@phobos.i.cabal.ca>
Message-ID: <48D70A6C.4050308@redhat.com>

Kyle McMartin wrote:
> On Sat, Sep 20, 2008 at 06:53:55AM -0400, Bill Nottingham wrote:
>> Subject: Re: de-modularising for the win!
>> Message-ID: <20080920105355.GA6663 at nostromo.devel.redhat.com>
>> References: <20080918191355.GA9683 at nostromo.devel.redhat.com> <48D2D94E.2020902 at redhat.com> <20080918231301.GA4734 at nostromo.devel.redhat.com> <1221790735.15361.152.camel at aglarond.local>
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>> In-Reply-To: <1221790735.15361.152.camel at aglarond.local>
>> User-Agent: Mutt/1.5.18 (2008-05-17)
>>
>> Jeremy Katz (katzj at redhat.com) said: 
>>> On Thu, 2008-09-18 at 16:13 -0700, Bill Nottingham wrote:
>>>> - killing the initrd for that general 90% case can be a big win
>>> Ermm, the general 90% (or some large-ish generalizing percentage) are
>>> set up to use LVM.  Which then requires an initrd.
>> Yes, but ... LVM is overkill, in general. (That's another discussion.)
>>
>> On further consideration, though, the biggest issue with kicking out
>> the initrd is getting the policy lodaed.
>>
> 
> But, won't we all be using btrfs instead of lvm in F11? ;-)

Aw crap, you mean F10 was my only fleeting chance to make ext4 the
default? :)

-Eric



From paul.moore at hp.com  Mon Sep 22 15:19:30 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 22 Sep 2008 11:19:30 -0400
Subject: (no subject)
In-Reply-To: <20080920102231.067ddbb9@infradead.org>
References: <200809201158.m8KBwFTa010461@nostromo.devel.redhat.com>
	<20080920171338.GC24017@phobos.i.cabal.ca>
	<20080920102231.067ddbb9@infradead.org>
Message-ID: <200809221119.30418.paul.moore@hp.com>

On Saturday 20 September 2008 1:22:31 pm Arjan van de Ven wrote:
> On Sat, 20 Sep 2008 13:13:38 -0400
>
> Kyle McMartin <kyle at redhat.com> wrote:
> > > On further consideration, though, the biggest issue with kicking
> > > out the initrd is getting the policy lodaed.
>
> /me wonders about the option of having selinux using
> request_firmware() to get its policy

I've started ignoring most of the firmware loading threads a while ago 
so I've kinda lost most of the plot there ... a few questions:

* Is the firmware request asynchronous?

* Is there currently a way, or at least nothing in the way that would 
prevent a mechanism from bring created, to pause the boot process until 
the policy/firmware is loaded?  I ask because we would want to make 
sure that SELinux policy was loaded before any services are started.

Regardless, we would still need to keep the current policy loading 
mechanism in place since we can't break userspace.  You should post 
this idea on the SELinux list to get some further thought on this ...

-- 
paul moore
linux @ hp



From csnook at redhat.com  Mon Sep 22 20:26:13 2008
From: csnook at redhat.com (Chris Snook)
Date: Mon, 22 Sep 2008 16:26:13 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080919091709.7a75e740@infradead.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>	<48D2D94E.2020902@redhat.com>	<20080918231301.GA4734@nostromo.devel.redhat.com>	<48D386DE.7050607@redhat.com>
	<20080919091709.7a75e740@infradead.org>
Message-ID: <48D7FF65.5040502@redhat.com>

Arjan van de Ven wrote:
> On Fri, 19 Sep 2008 13:02:54 +0200
> Gerd Hoffmann <kraxel at redhat.com> wrote:
> 
>> Bill Nottingham wrote:
>>> - killing the initrd for that general 90% case can be a big win
>> You aren't going to kill the initrd for a default fedora install due
>> to root-on-lvm.
> 
> why do we have root-on-lvm by default on laptops again?

Because lots of Fedora developers multi-boot and/or use virtualization on their 
laptops, and lay users can't tell the difference.

That said, I'm all in favor of having installation profiles for laptops, 
desktops, workstations, servers, etc. with their own sets of defaults.  I'm just 
not enough in favor of it to learn the anaconda innards and do it, which is 
probably the same reason nobody else has done it either.

-- Chris



From davej at redhat.com  Thu Sep 25 18:34:31 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 25 Sep 2008 14:34:31 -0400
Subject: IA64 ATA patch.
Message-ID: <20080925183431.GA5283@redhat.com>

We've had this in Fedora since 2007/02/27
Can anyone recall why? and more importantly, why it isn't upstream?

	Dave


--- linux-2.6.20/arch/ia64/kernel/quirks.c	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.20_fix/arch/ia64/kernel/quirks.c	2007-02-13 13:56:34.000000000 -0500
@@ -0,0 +1,45 @@
+/*
+ * This file contains work-arounds for ia64 platform bugs.
+ */
+#include <linux/pci.h>
+
+/*
+ * quirk_intel_ide_controller: If an ide/ata controller is
+ * at legacy mode, BIOS might initiates BAR(bar 0~3 and 5)
+ * with incorrect value. This quirk will reset the incorrect
+ * value to 0.
+ */
+static void __devinit quirk_intel_ide_controller(struct pci_dev *dev)
+{
+	unsigned int pos;
+	struct resource *res;
+	int fixed = 0;
+	u8 tmp8;
+
+	if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
+		return;
+
+	/* TODO: What if one channel is in native mode ... */
+	pci_read_config_byte(dev, PCI_CLASS_PROG, &tmp8);
+	if ((tmp8 & 5) == 5)
+		return;
+
+	for( pos = 0; pos < 6; pos ++ ) {
+		res = &dev->resource[pos];
+		if (!(res->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
+			continue;
+
+		if (!res->start && res->end) {
+			res->start = res->end = 0;
+			res->flags = 0;
+			fixed = 1;
+		}
+	}
+	if (fixed)
+		printk(KERN_WARNING
+			"PCI device %s: BIOS resource configuration fixed.\n",
+			pci_name(dev));
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_11, quirk_intel_ide_controller);
+
--- linux-2.6.21.noarch/arch/ia64/kernel/Makefile~	2007-05-27 23:23:36.000000000 -0400
+++ linux-2.6.21.noarch/arch/ia64/kernel/Makefile	2007-05-27 23:23:48.000000000 -0400
@@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
 obj-$(CONFIG_IA64_UNCACHED_ALLOCATOR)	+= uncached.o
 obj-$(CONFIG_AUDIT)		+= audit.o
 obj-$(CONFIG_PCI_MSI)		+= msi_ia64.o
+obj-$(CONFIG_PCI)		+= quirks.o
 mca_recovery-y			+= mca_drv.o mca_drv_asm.o
 obj-$(CONFIG_IA64_MC_ERR_INJECT)+= err_inject.o
 



From davej at redhat.com  Thu Sep 25 18:57:22 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 25 Sep 2008 14:57:22 -0400
Subject: rawhide patches.
Message-ID: <20080925185722.GA13598@redhat.com>

I just sifted through what we had in rawhide, after noticing that
ls *.patch was starting to scroll my terminal (which is never a good sign).
In doing so, I found a bunch of patches that weren't applied any more
that we forgot to remove, and a bunch that were applied that shouldn't
have been.
Sifting through the remnants gave me a list that I've added to cvs as
the file 'TODO' in devel.  Hopefully we can keep this up to date as
patches are introduced/removed.  At the least it should serve as
reasoning for why the hell we're carrying some patches for years
(some of the CVS changelogs are pretty crappy, including some from yours truly).

Here's what it looks like today..

	Dave


drm-modesetting-i915.patch
drm-modesetting-radeon.patch
linux-2.6-export-shmem-bits-for-gem.patch
	Intel/Radeon kernel mode-setting.
	Won't go upstream for a while.

drm-nouveau.patch
	Nouveau DRM driver.
	Won't go upstream until ABI confirmed.

linux-2.6-acpi-clear-wake-status.patch
linux-2.6-acpi-video-dos.patch
linux-2.6-defaults-acpi-video.patch
linux-2.6-input-dell-keyboard-keyup.patch
linux-2.6-eeepc-laptop-update.patch
	mjg59 ACPI/laptop bits.
	Upstreamable for 2.6.28 ?

linux-2.6-at76.patch
linux-2.6-iwlwifi-use-dma_alloc_coherent.patch
linux-2.6-wireless.patch
linux-2.6-wireless-pending.patch
	Linville.  Wireless bits.
	Most should be upstream for 2.6.28

linux-2.6-ata-quirk.patch
	IA64 oddness. Query sent to f-k-l

linux-2.6-build-nonintconfig.patch
linux-2.6-debug-nmi-timeout.patch
linux-2.6-debug-spinlock-taint.patch
linux-2.6-debug-taint-vm.patch
linux-2.6-debug-vm-would-have-oomkilled.patch
linux-2.6-scsi-cpqarray-set-master.patch
linux-2.6-usb-ehci-hcd-respect-nousb.patch
	Push for 2.6.28

linux-2.6-compile-fixes.patch
linux-2.6-hotfixes.patch
	Empty

linux-2.6-crash-driver.patch
	Not upstreamable.

linux-2.6-debug-always-inline-kzalloc.patch
	Sent upstream Sep 25 2008

linux-2.6-debug-sizeof-structs.patch
	Fedora local debug stuff.

linux-2.6-default-mmf_dump_elf_headers.patch
linux-2.6-utrace.patch
linux-2.6-x86-tracehook.patch
	Roland magick & utrace

linux-2.6-defaults-fat-utf8.patch
	Drop?

linux-2.6-defaults-pci_no_msi.patch
linux-2.6-input-kill-stupid-messages.patch
linux-2.6-x86-tune-generic.patch
	Fedora local choices uninteresting to upstream

linux-2.6-e1000e-add-support-for-82567LM-3-and-82567LF-3-ICH10D-parts.patch
linux-2.6-e1000e-add-support-for-new-82574L-part.patch
linux-2.6-e1000e-add-support-for-the-82567LM-4-device.patch
linux-2.6-e1000-ich9.patch
linux-2.6-firewire-git-update.patch
linux-2.6-netdev-atl2.patch
	Should go upstream for .28

linux-2.6-efika-not-chrp.patch
linux-2.6-g5-therm-shutdown.patch
linux-2.6-imac-transparent-bridge.patch
linux-2.6-ps3-ehci-iso.patch
linux-2.6-ps3-legacy-bootloader-hack.patch
linux-2.6-ps3-storage-alias.patch
linux-2.6-vio-modalias.patch
	ppc bits. dwmw2.

linux-2.6-execshield.patch
linux-2.6-xen-execshield-add-xen-specific-load_user_cs_desc.patch
linux-2.6-xen-execshield-fix-endless-gpf-fault-loop.patch
linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch	Not interesting to upstream.

linux-2.6-lirc.patch
	jarod working on upstreaming

linux-2.6-merge-efifb-imacfb.patch
	pjones.  merge for 2.6.28 ?

linux-2.6-nfs-client-mounts-hang.patch
	SteveD.
	Sent ping on Sep 25 to find out status.

linux-2.6-net-silence-noisy-printks.patch
linux-2.6-piix3-silence-quirk.patch
linux-2.6-quiet-iommu.patch
linux-2.6-silence-acpi-blacklist.patch
linux-2.6-silence-fbcon-logo.patch
linux-2.6-silence-noise.patch
	Fedora local 'hush' patches.

linux-2.6-selinux-mprotect-checks.patch
linux-2.6-sparc-selinux-mprotect-checks.patch
	Not upstreamable.

linux-2.6-serial-460800.patch
	Probably not upstreamable.
	http://marc.theaimsgroup.com/?l=linux-kernel&m=112687270832687&w=2
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126403
	http://lkml.org/lkml/2006/8/2/208

linux-2.6-squashfs.patch
	Sigh.  Who the hell knows when this will go upstream.

linux-2.6-sysrq-c.patch
	Que?


-- 
http://www.codemonkey.org.uk



From notting at redhat.com  Thu Sep 25 19:07:04 2008
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 25 Sep 2008 15:07:04 -0400
Subject: rawhide patches.
In-Reply-To: <20080925185722.GA13598@redhat.com>
References: <20080925185722.GA13598@redhat.com>
Message-ID: <20080925190704.GA26319@nostromo.devel.redhat.com>

Dave Jones (davej at redhat.com) said: 
> linux-2.6-defaults-fat-utf8.patch
> 	Drop?

Isn't this a local choice similar to the later ones?

> linux-2.6-net-silence-noisy-printks.patch
> linux-2.6-piix3-silence-quirk.patch
> linux-2.6-quiet-iommu.patch
> linux-2.6-silence-acpi-blacklist.patch
> linux-2.6-silence-fbcon-logo.patch
> linux-2.6-silence-noise.patch
> 	Fedora local 'hush' patches.

Speaking of 'hush' patches - 

...
ALSA sound/pci/hda/hda_intel.c:1404: azx_pcm_prepare: bufsize=0x10000, format=0x4011
ALSA sound/pci/hda/hda_codec.c:716: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
...

Is this a config option, or do we need to patch this stuff out?

Bill



From davej at redhat.com  Thu Sep 25 19:11:28 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 25 Sep 2008 15:11:28 -0400
Subject: rawhide patches.
In-Reply-To: <20080925190704.GA26319@nostromo.devel.redhat.com>
References: <20080925185722.GA13598@redhat.com>
	<20080925190704.GA26319@nostromo.devel.redhat.com>
Message-ID: <20080925191128.GB13598@redhat.com>

On Thu, Sep 25, 2008 at 03:07:04PM -0400, Bill Nottingham wrote:
 > Dave Jones (davej at redhat.com) said: 
 > > linux-2.6-defaults-fat-utf8.patch
 > > 	Drop?
 > 
 > Isn't this a local choice similar to the later ones?

The problem is this is a "who do we want to screw over" patch.
Some people have disks which aren't UTF8, and get crazy moon language
instead of their expected charset.

 > > linux-2.6-net-silence-noisy-printks.patch
 > > linux-2.6-piix3-silence-quirk.patch
 > > linux-2.6-quiet-iommu.patch
 > > linux-2.6-silence-acpi-blacklist.patch
 > > linux-2.6-silence-fbcon-logo.patch
 > > linux-2.6-silence-noise.patch
 > > 	Fedora local 'hush' patches.
 > 
 > Speaking of 'hush' patches - 
 > 
 > ..
 > ALSA sound/pci/hda/hda_intel.c:1404: azx_pcm_prepare: bufsize=0x10000, format=0x4011
 > ALSA sound/pci/hda/hda_codec.c:716: hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
 > ..
 > 
 > Is this a config option, or do we need to patch this stuff out?

Probably one of the many ALSA debug options.

CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_DETECT=y
CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_SND_PCM_XRUN_DEBUG=y

	Dave

-- 
http://www.codemonkey.org.uk



From jonathan at jonmasters.org  Thu Sep 25 20:09:57 2008
From: jonathan at jonmasters.org (Jon Masters)
Date: Thu, 25 Sep 2008 16:09:57 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080918191355.GA9683@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
Message-ID: <1222373397.14208.16.camel@perihelion>

On Thu, 2008-09-18 at 12:13 -0700, Bill Nottingham wrote:
> See various and sundry plumber's conf discussions.
> 
> Comments? (The netfilter stuff needs further investigation.)

I'm ok with all of these specific config changes, but I'd like to repeat
what I said in Kyle's session about demodularising in general.

I advocate extreme caution before just willy-nilly building everything
into the kernel. Although this might seem like a great idea from the
point of view of speeding up boot, there is also the pesky issue of
users wanting the choice to decide which modules get loaded, and more
importantly, wanting to override those modules with their own. To do
this truly "right" we'll need to do rebinding of drivers in kernel.
That's not always going to be easily possible after it's in use.

And while we might not love binary drivers, note that it is the user's
choice to make. If they want to load proprietary (or just out of tree
drivers) then we should not go out of our way to intentionally make this
difficult for them. i.e. let's no go building in particular graphics
drivers for political reasons...I'm pre-empting discussion there :)

So, anyway, Bill's got a good base set of common options.

Jon.




From roland at redhat.com  Fri Sep 26 00:32:50 2008
From: roland at redhat.com (Roland McGrath)
Date: Thu, 25 Sep 2008 17:32:50 -0700 (PDT)
Subject: chcorefilter
Message-ID: <20080926003250.F1C131541FA@magilla.localdomain>

The /proc/PID/coredump_filter mechanism makes it easy to tweak the
per-process setting to control ELF core dump style details.  
This setting is per-process (per-mm) and inherited by children.

But as a user, the /proc interface is insane.  It prints a magical hex
value (without a leading 0x, to make it sneaky), which you'll be damn lucky
to figure out from reading Documentation/filesystems/proc.txt.  Then you
get to set it to another such magical value, which is in decimal unless you
add a leading 0x (cat /proc/x/coredump_filter > /proc/y/coredump_filter
does not copy the setting, go team).

I have kicking around this half-assed bash script that I don't care to
bother making really presentable.  Where should it live?  In the upstream
kernel's scripts/?  (Then noone would ever see it for sure.)  
In util-linux-ng?  Or what?  Someone want to take it off my hands?


Thanks,
Roland


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: chcorefilter
URL: <http://listman.redhat.com/archives/fedora-kernel-list/attachments/20080925/9e595e1b/attachment.ksh>

From davej at redhat.com  Fri Sep 26 00:57:30 2008
From: davej at redhat.com (Dave Jones)
Date: Thu, 25 Sep 2008 20:57:30 -0400
Subject: chcorefilter
In-Reply-To: <20080926003250.F1C131541FA@magilla.localdomain>
References: <20080926003250.F1C131541FA@magilla.localdomain>
Message-ID: <20080926005730.GA20568@redhat.com>

On Thu, Sep 25, 2008 at 05:32:50PM -0700, Roland McGrath wrote:
Content-Description: message body text
 > The /proc/PID/coredump_filter mechanism makes it easy to tweak the
 > per-process setting to control ELF core dump style details.  
 > This setting is per-process (per-mm) and inherited by children.
 > 
 > But as a user, the /proc interface is insane.  It prints a magical hex
 > value (without a leading 0x, to make it sneaky), which you'll be damn lucky
 > to figure out from reading Documentation/filesystems/proc.txt.  Then you
 > get to set it to another such magical value, which is in decimal unless you
 > add a leading 0x (cat /proc/x/coredump_filter > /proc/y/coredump_filter
 > does not copy the setting, go team).
 > 
 > I have kicking around this half-assed bash script that I don't care to
 > bother making really presentable.  Where should it live?  In the upstream
 > kernel's scripts/?  (Then noone would ever see it for sure.)  
 > In util-linux-ng?  Or what?  Someone want to take it off my hands?
 
either util-linux or procps is my suggestion.

	Dave

-- 
http://www.codemonkey.org.uk



From peterenns at cox.net  Sun Sep 28 02:06:43 2008
From: peterenns at cox.net (Peter Enns)
Date: Sat, 27 Sep 2008 23:06:43 -0300
Subject: 100 AmericaGoVoteCards for Free church distribution
Message-ID: <226a513c203044479aaab6b787258197@cox.net>





   
   
   
   


Having trouble viewing this e-mail? please use this link ( http://app.mailworkz.com/email_view.asp?group_idno=5204602&outgoing_idno=5204613&email_idno=3005330 ) .

   
      
         
            
      
         
            
               
                  100 FREE America Go Vote! CardsDistribute them at Church or at your business.
To Open Click www.AmericaGoVote.com


    
        
            
            America Go Vote! The first 100 cards are yours FREE 
            
        
        
            
            Statement Of PurposeThe purpose of Go Vote! cards is to energize "We The People" to get informed and then go vote their convictions in the2008 Presidential Election.Peter Enns  ( http://agoodword.net/americagovote/tellafriend.php )  
            
        
        
            
             
            
        
        
            
            4 X 6 cards are double sided and printed on high quality Post Card Stock 
            
        
    


    
        
            
            
            
                
                    
                        
                         ( http://agoodword.net/peter/index.htm )  ( http://agoodword.net/peter/index.htm )  
                        
                        
                        I&#8217;m Peter Enns. I wrote and created America Go Vote! cards for free distribution, to help energize "We The People" to get informed and then vote their convictions.
                         
                        Anyone, including businesses & churches can request free America Go Vote! cards. We will send you the first 100 cards at no charge. All we ask is that you pay a $5.95 shipping and handling fee. We do accept contributions to help pay for the cards. However, there is no contribution required to order the first 100 free cards. 
                        
                    
                    
                        
                        The First 100 Cards are Free - Additional cards are available at just 10&#162; each.                                                                                Your contribution of any amount will help make America Go Vote! cards available nationwide. ( http://www.agoodword.net/shop/donation.php )  ( http://www.agoodword.net/americagovote/tellafriend.php )  ( http://www.agoodword.net/shop/ )                 
                        
                    
                    
                        
                        basic IRS church and 501 (c)(3) guidelines
                        Our laws are very supportive of pastors and churches who seek to educate and inform their members about both moral and political issues. As a non-profit 501 (c)(3) corporation, there are many things that churches may do and some things churches may not do. 
                        What Churches May Do: 1) Encourage members to register and vote. 2) Speak directly about specific issues.3) Pass out candidates Voter&#8217;s Guides. 4) Invite all candidates in a race to speak.What Churches May Not Do: 1) Make a financial contribution to a candidate.2) Raise funds for any political candidate. 3) Endorse a particular candidate. 4) Oppose a particular candidate. 
                        
                            
                                
                                    
                                    Suggested America Go Vote! Church EventPlay the 1 minute Church/PSA DVD included with the &#8220;Go Vote&#8221; CardsDistribute &#8220;Go Vote&#8221; Cards  ( mailto:peterenns at cox.net?subject=God Bless America Day ) Get Registered To Vote ( http://agoodword.net/americagovote/tellafriend.php )  
                                    
                                
                                
                                    
                                    Contact Info:        800.548.2023        info at agoodword.net ( http://agoodword.net/americagovote/index.htm )    ( http://www.website-hit-counters.com/fancy-hit-counters.html )                                      
                                    
                                        
                                            
                                                
                                            
                                        
                                    
                                    Copyright Good Word Publications 2008     
                                    
                                
                            
                        
                        
                    
                
            
            
            
        
    



               
               
                  
               
            
         
      
   






  This email was sent to fedora-kernel-list at redhat.com, by peterenns at cox.net.

 You may unsubscribe from this list. If this message was received in error, please report it.

  Good Word Publications | 7009 E. 99 Street  | TULSA | OK | 74133 | US



From mjg at redhat.com  Mon Sep 29 12:22:52 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 29 Sep 2008 13:22:52 +0100
Subject: de-modularising for the win!
In-Reply-To: <1222373397.14208.16.camel@perihelion>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
Message-ID: <20080929122252.GA18724@srcf.ucam.org>

On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote:

> I advocate extreme caution before just willy-nilly building everything
> into the kernel. Although this might seem like a great idea from the
> point of view of speeding up boot, there is also the pesky issue of
> users wanting the choice to decide which modules get loaded, and more
> importantly, wanting to override those modules with their own. To do
> this truly "right" we'll need to do rebinding of drivers in kernel.
> That's not always going to be easily possible after it's in use.

Linux is not about choice.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Mon Sep 29 12:24:07 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 29 Sep 2008 13:24:07 +0100
Subject: rawhide patches.
In-Reply-To: <20080925185722.GA13598@redhat.com>
References: <20080925185722.GA13598@redhat.com>
Message-ID: <20080929122407.GB18724@srcf.ucam.org>

On Thu, Sep 25, 2008 at 02:57:22PM -0400, Dave Jones wrote:

> linux-2.6-acpi-clear-wake-status.patch

Upstream.

> linux-2.6-acpi-video-dos.patch
> linux-2.6-defaults-acpi-video.patch

These are policy decisions. Probably not going usptream.

> linux-2.6-input-dell-keyboard-keyup.patch

Upstream.

> linux-2.6-eeepc-laptop-update.patch

Upstream.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From roland at redhat.com  Mon Sep 29 17:47:05 2008
From: roland at redhat.com (Roland McGrath)
Date: Mon, 29 Sep 2008 10:47:05 -0700 (PDT)
Subject: rawhide patches.
In-Reply-To: Matthew Garrett's message of  Monday,
	29 September 2008 13:24:07 +0100
	<20080929122407.GB18724@srcf.ucam.org>
References: <20080925185722.GA13598@redhat.com>
	<20080929122407.GB18724@srcf.ucam.org>
Message-ID: <20080929174705.E900D1541FA@magilla.localdomain>

> > linux-2.6-acpi-video-dos.patch
> > linux-2.6-defaults-acpi-video.patch
> 
> These are policy decisions. Probably not going usptream.

Can they be turned into upstream config options?



From ajax at redhat.com  Mon Sep 29 17:52:54 2008
From: ajax at redhat.com (Adam Jackson)
Date: Mon, 29 Sep 2008 13:52:54 -0400
Subject: rawhide patches.
In-Reply-To: <20080925185722.GA13598@redhat.com>
References: <20080925185722.GA13598@redhat.com>
Message-ID: <1222710774.6217.26.camel@localhost.localdomain>

On Thu, 2008-09-25 at 14:57 -0400, Dave Jones wrote:

> linux-2.6-net-silence-noisy-printks.patch
> linux-2.6-piix3-silence-quirk.patch
> linux-2.6-quiet-iommu.patch
> linux-2.6-silence-acpi-blacklist.patch
> linux-2.6-silence-fbcon-logo.patch
> linux-2.6-silence-noise.patch
> 	Fedora local 'hush' patches.

I did a good number of these (and added another one today).  The PIIX3
and ACPI ones are plausible for upstream, I'll resend them.

The IOMMU one is possibly controversial, but I've seriously never seen
any machine ever where there's a BIOS option to make those messages go
away.  I suppose I should fire it at lkml just to generate flames.

I also added one today to shut up the KERNEL ALIVE on amd64.  I think
notting had a better version of this?  I just ripped them out, they
could probably be redone in such a way that they honor 'quiet' on the
command line but I really can't see the point of having them at all.

- ajax



From mjg at redhat.com  Mon Sep 29 17:59:00 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 29 Sep 2008 18:59:00 +0100
Subject: rawhide patches.
In-Reply-To: <20080929174705.E900D1541FA@magilla.localdomain>
References: <20080925185722.GA13598@redhat.com>
	<20080929122407.GB18724@srcf.ucam.org>
	<20080929174705.E900D1541FA@magilla.localdomain>
Message-ID: <20080929175900.GA23984@srcf.ucam.org>

On Mon, Sep 29, 2008 at 10:47:05AM -0700, Roland McGrath wrote:
> > > linux-2.6-acpi-video-dos.patch
> > > linux-2.6-defaults-acpi-video.patch
> > 
> > These are policy decisions. Probably not going usptream.
> 
> Can they be turned into upstream config options?

They're already runtime settable, so it's primarily a convenience thing 
- they're the sensible defaults given our userland.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From davej at redhat.com  Mon Sep 29 18:04:55 2008
From: davej at redhat.com (Dave Jones)
Date: Mon, 29 Sep 2008 14:04:55 -0400
Subject: rawhide patches.
In-Reply-To: <20080929175900.GA23984@srcf.ucam.org>
References: <20080925185722.GA13598@redhat.com>
	<20080929122407.GB18724@srcf.ucam.org>
	<20080929174705.E900D1541FA@magilla.localdomain>
	<20080929175900.GA23984@srcf.ucam.org>
Message-ID: <20080929180455.GA8968@redhat.com>

On Mon, Sep 29, 2008 at 06:59:00PM +0100, Matthew Garrett wrote:
 > On Mon, Sep 29, 2008 at 10:47:05AM -0700, Roland McGrath wrote:
 > > > > linux-2.6-acpi-video-dos.patch
 > > > > linux-2.6-defaults-acpi-video.patch
 > > > 
 > > > These are policy decisions. Probably not going usptream.
 > > 
 > > Can they be turned into upstream config options?
 > 
 > They're already runtime settable, so it's primarily a convenience thing 
 > - they're the sensible defaults given our userland.

I think Rolands point was that if we had for eg CONFIG_ACPI_VIDEO_DEFAULT
we'd get to carry one less patch.

	Dave

-- 
http://www.codemonkey.org.uk



From roland at redhat.com  Mon Sep 29 18:06:45 2008
From: roland at redhat.com (Roland McGrath)
Date: Mon, 29 Sep 2008 11:06:45 -0700 (PDT)
Subject: rawhide patches.
In-Reply-To: Matthew Garrett's message of  Monday,
	29 September 2008 18:59:00 +0100
	<20080929175900.GA23984@srcf.ucam.org>
References: <20080925185722.GA13598@redhat.com>
	<20080929122407.GB18724@srcf.ucam.org>
	<20080929174705.E900D1541FA@magilla.localdomain>
	<20080929175900.GA23984@srcf.ucam.org>
Message-ID: <20080929180645.832621541FA@magilla.localdomain>

> > > These are policy decisions. Probably not going usptream.
> > 
> > Can they be turned into upstream config options?
> 
> They're already runtime settable, so it's primarily a convenience thing 
> - they're the sensible defaults given our userland.

Can the boot defaults be turned into upstream config options?

If it's worthwhile to patch the kernel to make it boot this way by default,
it's worthwhile to get that default without a patch.  Fewer patches to keep
track of, same defaults for kernel-vanilla rpms, etc.


Thanks,
Roland



From jcm at redhat.com  Tue Sep 30 05:24:22 2008
From: jcm at redhat.com (Jon Masters)
Date: Tue, 30 Sep 2008 01:24:22 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080929122252.GA18724@srcf.ucam.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
Message-ID: <1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>

On Mon, 2008-09-29 at 13:22 +0100, Matthew Garrett wrote:
> On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote:
> 
> > I advocate extreme caution before just willy-nilly building everything
> > into the kernel. Although this might seem like a great idea from the
> > point of view of speeding up boot, there is also the pesky issue of
> > users wanting the choice to decide which modules get loaded, and more
> > importantly, wanting to override those modules with their own. To do
> > this truly "right" we'll need to do rebinding of drivers in kernel.
> > That's not always going to be easily possible after it's in use.
> 
> Linux is not about choice.

Well, it should be wherever possible :)

Jon.




From arjan at infradead.org  Tue Sep 30 08:34:33 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 30 Sep 2008 01:34:33 -0700
Subject: de-modularising for the win!
In-Reply-To: <1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930013433.0b8cd066@infradead.org>

On Tue, 30 Sep 2008 01:24:22 -0400
Jon Masters <jcm at redhat.com> wrote:

> On Mon, 2008-09-29 at 13:22 +0100, Matthew Garrett wrote:
> > On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote:
> > 
> > > I advocate extreme caution before just willy-nilly building
> > > everything into the kernel. Although this might seem like a great
> > > idea from the point of view of speeding up boot, there is also
> > > the pesky issue of users wanting the choice to decide which
> > > modules get loaded, and more importantly, wanting to override
> > > those modules with their own. To do this truly "right" we'll need
> > > to do rebinding of drivers in kernel. That's not always going to
> > > be easily possible after it's in use.
> > 
> > Linux is not about choice.
> 
> Well, it should be wherever possible :)
> 

for certain types of choices the answer is going to be "oh now you need
to compile your own kernel"; there's just too many config options for
that not to be the case.
Of course for the normal, common scenarios that's not the right answer,
but "I would like to replace core component FOO" it's perfectly fine.

Users don't replace their AHCI driver much (and if they do, even today,
they're likely to just build their own whole kernel, or use a rawhide
kernel rpm)

In the RHEL world the rules are a bit different due to the really long
release cycles (even for hw support updates), but on Fedora.... if you
are capable of backporting a driver you can also build your own kernel
or use an rpm provided.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From fedora at leemhuis.info  Tue Sep 30 09:10:35 2008
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 30 Sep 2008 11:10:35 +0200
Subject: de-modularising for the win!
In-Reply-To: <20080930013433.0b8cd066@infradead.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>	<1222373397.14208.16.camel@perihelion>	<20080929122252.GA18724@srcf.ucam.org>	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
Message-ID: <48E1ED0B.7090603@leemhuis.info>

On 30.09.2008 10:34, Arjan van de Ven wrote:
> On Tue, 30 Sep 2008 01:24:22 -0400
> Jon Masters <jcm at redhat.com> wrote:
>> On Mon, 2008-09-29 at 13:22 +0100, Matthew Garrett wrote:
>>> On Thu, Sep 25, 2008 at 04:09:57PM -0400, Jon Masters wrote:
>>>> I advocate extreme caution before just willy-nilly building
>>>> everything into the kernel. Although this might seem like a great
>>>> idea from the point of view of speeding up boot, there is also
>>>> the pesky issue of users wanting the choice to decide which
>>>> modules get loaded, and more importantly, wanting to override
>>>> those modules with their own. To do this truly "right" we'll need
>>>> to do rebinding of drivers in kernel. That's not always going to
>>>> be easily possible after it's in use.
>>> Linux is not about choice.
>> Well, it should be wherever possible :)
> for certain types of choices the answer is going to be "oh now you need
> to compile your own kernel"; there's just too many config options for
> that not to be the case.
> [...]
> In the RHEL world the rules are a bit different due to the really long
> release cycles (even for hw support updates), but on Fedora.... if you
> are capable of backporting a driver you can also build your own kernel
> or use an rpm provided.

You have a point, but I also tend to disagree a bit, because the 
backporting often is done by other people or the projects around the 
driver.

The alsa-project is a good example. Say you purchase a new motherboard 
and it has a brand new audio codec that is not yet supported by the 
in-kernel drivers. You report that to the alsa-project and they develop 
code to support that codec; a few days or weeks later they might tell 
you to download alsa-driver-1.0.18-alpha1.tar.bz and compile that for 
testing. If certain sound drivers (say snd-hda-intel) or the soundcore 
are compiled into the kernel (like planed for Fedora) then you will 
often be forced to recompile the whole kernel to test the new driver. 
That's a whole lot more complicated then compiling just the 
alsa-drivers, which is not that hard to do these days with current 
Fedora kernels.

The alsa-example also shows that it IMHO still take way to much time for 
a new driver or fixes out to the users. To work further on above 
example: from alsa-driver-1.0.18-alpha1.tar.bz it'll often take a few 
weeks till the code matures and becomes alsa-driver-1.0.18. From there 
is yet again takes a few weeks till those drivers get merged in the 
kernel during the next merge window; from there it takes yet again a few 
weeks until that kernel is ready; from there it yet again takes a few 
weeks until that kernel is shipped as regular fedora-update.  That can 
quickly mean: wait round about half a year for a new alsa-driver(?) :-/


Okay, the unusual way the alsa-developers work is part of both 
problems... But that's something only they can fix....

CU
knurd

(?) alsa right now is at alsa-driver-1.0.18rc3 -- 2.6.27 (rawhide/F10) 
will ship with something that is close to alsa-driver-1.0.17; right now 
F9 users since two or three weeks are on 2.6.26, which contains the 
alsa-driver 1.0.16 which were released on February the 5th afaics



From jcm at redhat.com  Tue Sep 30 14:26:23 2008
From: jcm at redhat.com (Jon Masters)
Date: Tue, 30 Sep 2008 10:26:23 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080930013433.0b8cd066@infradead.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
Message-ID: <1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>

On Tue, 2008-09-30 at 01:34 -0700, Arjan van de Ven wrote:

> for certain types of choices the answer is going to be "oh
> now you need to compile your own kernel"; 

Yay!

> In the RHEL world the rules are a bit different due to the
> really long release cycles (even for hw support updates)

Indeed, and it'll be amusing if we ever get to a point where RHEL users
can update their modules but Fedora users can't :)

> but on Fedora.... if you are capable of backporting a driver
> you can also build your own kernel or use an rpm provided.

Which means that third parties will end up getting into the kernel
rebuilding business if their modules are unloadable. Suddenly you have
users running many different builds of the same Fedora kernel, and
asking for help on mailing lists, and all of that goodness.

I'm just saying some caution is a good thing before everything gets
built into the kernel image.

Jon.




From kyle at mcmartin.ca  Tue Sep 30 14:25:32 2008
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Tue, 30 Sep 2008 10:25:32 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080930013433.0b8cd066@infradead.org>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
Message-ID: <20080930142532.GA10632@phobos.i.cabal.ca>

On Tue, Sep 30, 2008 at 01:34:33AM -0700, Arjan van de Ven wrote:
> for certain types of choices the answer is going to be "oh now you need
> to compile your own kernel"; there's just too many config options for
> that not to be the case.
> Of course for the normal, common scenarios that's not the right answer,
> but "I would like to replace core component FOO" it's perfectly fine.
> 
> Users don't replace their AHCI driver much (and if they do, even today,
> they're likely to just build their own whole kernel, or use a rawhide
> kernel rpm)
> 
> In the RHEL world the rules are a bit different due to the really long
> release cycles (even for hw support updates), but on Fedora.... if you
> are capable of backporting a driver you can also build your own kernel
> or use an rpm provided.
> 

if a user is rebuilding their libata subsystem and replacing the
modules, or replacing their alsa modules, or whatnot, they've already
voided the "i'd like to help you" implied contract in open source, so
they should just go run and support their own kernel.

every patch in the fedora kernel has this implicit "i take
responsibility if this breaks" property. 

of course, we're talking about /fedora/ here, not rhel. obviously the
support reqiurements are vastly different for rhel.



From jcm at redhat.com  Tue Sep 30 14:33:14 2008
From: jcm at redhat.com (Jon Masters)
Date: Tue, 30 Sep 2008 10:33:14 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080930142532.GA10632@phobos.i.cabal.ca>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<20080930142532.GA10632@phobos.i.cabal.ca>
Message-ID: <1222785194.3319.80.camel@jcmlaptop.bos.redhat.com>

On Tue, 2008-09-30 at 10:25 -0400, Kyle McMartin wrote:

> if a user is rebuilding their libata subsystem and replacing the
> modules, or replacing their alsa modules, or whatnot, they've already
> voided the "i'd like to help you" implied contract in open source, so
> they should just go run and support their own kernel.

Yay! So then one day we can look forward to everything being built in
and a user wanting to build a webcam driver having to build their own
kernel too. Then we'll really have won because that user - who can
follow some straightforward instructions on a website showing them how
to build a driver and install it - will give up and go use Ubuntu.

Just because we can build our own kernels with whatever patches does not
mean that all users who want to add a driver are capable of this.

Jon.




From notting at redhat.com  Tue Sep 30 14:33:51 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Sep 2008 10:33:51 -0400
Subject: de-modularising for the win!
In-Reply-To: <1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930143351.GA6335@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> Which means that third parties will end up getting into the kernel
> rebuilding business if their modules are unloadable. Suddenly you have
> users running many different builds of the same Fedora kernel, and
> asking for help on mailing lists, and all of that goodness.

Really? Do you have actual stats for the number (percentage) of Fedora
users that *actually* need to update their modules (as opposed to following
some blindly ridiculous message-board advice...)

Bill



From jcm at redhat.com  Tue Sep 30 14:38:12 2008
From: jcm at redhat.com (Jon Masters)
Date: Tue, 30 Sep 2008 10:38:12 -0400
Subject: de-modularising for the win!
In-Reply-To: <20080930143351.GA6335@nostromo.devel.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>
	<20080930143351.GA6335@nostromo.devel.redhat.com>
Message-ID: <1222785492.3319.86.camel@jcmlaptop.bos.redhat.com>

On Tue, 2008-09-30 at 10:33 -0400, Bill Nottingham wrote:
> Jon Masters (jcm at redhat.com) said: 
> > Which means that third parties will end up getting into the kernel
> > rebuilding business if their modules are unloadable. Suddenly you have
> > users running many different builds of the same Fedora kernel, and
> > asking for help on mailing lists, and all of that goodness.
> 
> Really? Do you have actual stats for the number (percentage) of Fedora
> users that *actually* need to update their modules (as opposed to following
> some blindly ridiculous message-board advice...)

Nope. I'm just taking the viewpoint that users shouldn't be artificially
restricted from doing so. I know this isn't the case right now, and the
proposed modules being built-in are fairly harmless, but I'm raising
this now before users can't build their own graphics drivers or whatever
else they would like to add to their system, based on choice.

Jon.




From mjg at redhat.com  Tue Sep 30 14:39:40 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 30 Sep 2008 15:39:40 +0100
Subject: de-modularising for the win!
In-Reply-To: <1222785194.3319.80.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<20080930142532.GA10632@phobos.i.cabal.ca>
	<1222785194.3319.80.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930143940.GA13191@srcf.ucam.org>

On Tue, Sep 30, 2008 at 10:33:14AM -0400, Jon Masters wrote:

> Yay! So then one day we can look forward to everything being built in
> and a user wanting to build a webcam driver having to build their own
> kernel too. Then we'll really have won because that user - who can
> follow some straightforward instructions on a website showing them how
> to build a driver and install it - will give up and go use Ubuntu.

I don't think anyone's argued for building an entirely static kernel. 
Where there's a significant advantage to building something in (and 
Arjan has shown that there is), we should do it. If there isn't, we 
shouldn't. I really don't think there's any reason the vast majority of 
our users would want to replace their AHCI driver, and the -hda one 
needs solving in some way other than "Download and rebuild ALSA" anyway.

> Just because we can build our own kernels with whatever patches does not
> mean that all users who want to add a driver are capable of this.

If users are capable of following the documentation for building an out 
of tree module, they're capable of following the documentation 
describing how to produce a modified kernel. The ones who aren't are, 
I'm willing to bet, a smaller number than the users who would be 
attracted by increased boot speeds.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From notting at redhat.com  Tue Sep 30 14:41:55 2008
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 30 Sep 2008 10:41:55 -0400
Subject: de-modularising for the win!
In-Reply-To: <1222785492.3319.86.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>
	<20080930143351.GA6335@nostromo.devel.redhat.com>
	<1222785492.3319.86.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930144155.GB6335@nostromo.devel.redhat.com>

Jon Masters (jcm at redhat.com) said: 
> > Really? Do you have actual stats for the number (percentage) of Fedora
> > users that *actually* need to update their modules (as opposed to following
> > some blindly ridiculous message-board advice...)
> 
> Nope. I'm just taking the viewpoint that users shouldn't be artificially
> restricted from doing so. I know this isn't the case right now

... come back when there's actual data and a usage case. 

> proposed modules being built-in are fairly harmless, but I'm raising
> this now before users can't build their own graphics drivers or whatever
> else they would like to add to their system, based on choice.

Linux is not about choice. Giving users the choice between 3 versions of
a driver, or ten different desktops, or three different printing systems
only means that *you've* made the choice to have your OS fail.

Bill



From mjg at redhat.com  Tue Sep 30 14:42:43 2008
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 30 Sep 2008 15:42:43 +0100
Subject: de-modularising for the win!
In-Reply-To: <1222785492.3319.86.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<1222784783.3319.74.camel@jcmlaptop.bos.redhat.com>
	<20080930143351.GA6335@nostromo.devel.redhat.com>
	<1222785492.3319.86.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930144243.GA13329@srcf.ucam.org>

On Tue, Sep 30, 2008 at 10:38:12AM -0400, Jon Masters wrote:

> Nope. I'm just taking the viewpoint that users shouldn't be artificially
> restricted from doing so.

At the point where someone suggests building something into the kernel 
purely in order to prevent users building an out of tree module, I think 
we should worry about that argument. Until then?
-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From arjan at infradead.org  Tue Sep 30 15:25:13 2008
From: arjan at infradead.org (Arjan van de Ven)
Date: Tue, 30 Sep 2008 08:25:13 -0700
Subject: de-modularising for the win!
In-Reply-To: <1222785194.3319.80.camel@jcmlaptop.bos.redhat.com>
References: <20080918191355.GA9683@nostromo.devel.redhat.com>
	<1222373397.14208.16.camel@perihelion>
	<20080929122252.GA18724@srcf.ucam.org>
	<1222752262.3319.4.camel@jcmlaptop.bos.redhat.com>
	<20080930013433.0b8cd066@infradead.org>
	<20080930142532.GA10632@phobos.i.cabal.ca>
	<1222785194.3319.80.camel@jcmlaptop.bos.redhat.com>
Message-ID: <20080930082513.23d4bf37@infradead.org>

On Tue, 30 Sep 2008 10:33:14 -0400
Jon Masters <jcm at redhat.com> wrote:


> Just because we can build our own kernels with whatever patches does
> not mean that all users who want to add a driver are capable of this.

please don't turn this discussion into the ridiculous.
Adding a module is always possible, nobody is even thinking about
suggesting to turn CONFIG_MODULES off.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org