:(
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. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
de-modularising for the win!
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 - 1.166 +++ config-generic 18 Sep 2008 19:12:12 - @@ -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 - 1.47 +++ config-x86-generic 18 Sep 2008 19:12:12 - @@ -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_
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 18 Sep 2008 17:14:14 -0400 "Tom \"spot\" Callaway" <[EMAIL PROTECTED]> 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 VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Tom spot Callaway ([EMAIL PROTECTED]) 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
On Thu, 18 Sep 2008 16:27:50 -0500 Matt Domsch <[EMAIL PROTECTED]> 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 VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 :-) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
> [1] Or someone can dig up the patches for dynamic loop allocation and > finish them off :-) Already exists. Try 'mknod loop23 ; losetup ...'... Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: de-modularising for the win!
Chris Snook ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] 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 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
