Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
On Mon, Feb 14, 2005 at 08:17:25PM -0500, Lee Revell wrote: > from user space to presenting a login prompt that's way too long. My > distro (Debian) runs all the init scripts one at a time, and GDM is the > last thing that gets run. There is just no reason for this. We should > start X and initialize the display and get the login prompt up there > ASAP, and let the system acquire the DHCP lease and start sendmail and > apache and get the date from the NTP server *in the background while I > am logging in*. It's not rocket science. This is debatable. Windows does something like this. It really annoys me that I will get a windows desktop very quickly after logging in but that I can't do anything with it until some mystrey initialization takes place. I would hate to be able to log into my linux machine but not be able to check email for the first 15 seconds. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
On Mon, Feb 14, 2005 at 08:17:25PM -0500, Lee Revell wrote: from user space to presenting a login prompt that's way too long. My distro (Debian) runs all the init scripts one at a time, and GDM is the last thing that gets run. There is just no reason for this. We should start X and initialize the display and get the login prompt up there ASAP, and let the system acquire the DHCP lease and start sendmail and apache and get the date from the NTP server *in the background while I am logging in*. It's not rocket science. This is debatable. Windows does something like this. It really annoys me that I will get a windows desktop very quickly after logging in but that I can't do anything with it until some mystrey initialization takes place. I would hate to be able to log into my linux machine but not be able to check email for the first 15 seconds. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for comments
On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote: > What this would do is keep a "cache" of all the "flows" that are passing > through the system; a flow is defined as the set of packets that have the > same headers - or header fields. For example we could choose "ip source, > ip destination, ip protocol, ip source port [if relevant], ip destination > port [ if relevant ], and maintain a cache of all distinct such > "flows" that pass through the system. The flows would have to be > "expired" from the cache (LRU) and there should be a limit on the size of > the cache. This sounds a lot like what MPLS does. I believe that someone has MPLS patches for the kernel, but I dont know who. You might want to find them and take a look. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for comments
On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote: What this would do is keep a cache of all the flows that are passing through the system; a flow is defined as the set of packets that have the same headers - or header fields. For example we could choose ip source, ip destination, ip protocol, ip source port [if relevant], ip destination port [ if relevant ], and maintain a cache of all distinct such flows that pass through the system. The flows would have to be expired from the cache (LRU) and there should be a limit on the size of the cache. This sounds a lot like what MPLS does. I believe that someone has MPLS patches for the kernel, but I dont know who. You might want to find them and take a look. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: modules and 2.5
On Tue, Jul 03, 2001 at 01:13:45AM -0400, Jeff Garzik wrote: > A couple things that would be nice for 2.5 is > - let MOD_INC_USE_COUNT work even when module is built into kernel, and > - let THIS_MODULE exist and be valid even when module is built into > kernel I have something similar that I have wanted for a long time, and it would accomplish what you want too. I would like for the .o files for modules and compiled in drivers to be identical. It seems like this would be better for testing because it should eleminate module vs non-module bugs. We might even want them to show up in /proc/modules, perhaps with some mechinism to keep the reference count from going to 0. I dont think I would want to unleash it on an end user, but if you omit the part about letting the reference count go to zero, it should even be possible to unload a compiled in driver and replace it with a new module. If you did not load each module into its own section, you would have to leak its text and data memory, but this still might be useful for development. Anyway, just some ideas I have been wanting to share for about 5 years. Thanks for giving me an excuse. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: modules and 2.5
On Tue, Jul 03, 2001 at 01:13:45AM -0400, Jeff Garzik wrote: A couple things that would be nice for 2.5 is - let MOD_INC_USE_COUNT work even when module is built into kernel, and - let THIS_MODULE exist and be valid even when module is built into kernel I have something similar that I have wanted for a long time, and it would accomplish what you want too. I would like for the .o files for modules and compiled in drivers to be identical. It seems like this would be better for testing because it should eleminate module vs non-module bugs. We might even want them to show up in /proc/modules, perhaps with some mechinism to keep the reference count from going to 0. I dont think I would want to unleash it on an end user, but if you omit the part about letting the reference count go to zero, it should even be possible to unload a compiled in driver and replace it with a new module. If you did not load each module into its own section, you would have to leak its text and data memory, but this still might be useful for development. Anyway, just some ideas I have been wanting to share for about 5 years. Thanks for giving me an excuse. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: > > Exactly. However, there are situations when you have only two options: > > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) > > Why can't mozilla be fixed? With the -taso option there is actually less > encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: Exactly. However, there are situations when you have only two options: rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) Why can't mozilla be fixed? With the -taso option there is actually less encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Highmem Bigmem question
Hello All, This is probably an FAQ, but I read the FAQ and its not in there. I have a machine with 2G of memory. I compiled the kernel with the 4G memory option. How much address space should each process be able to address? Does this change if I use the 64G option? I'm after 2.4 information. Right now I am running on a 2.2 kernel and it looks like the user processes are limited to ~1G. Thanks, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Highmem Bigmem question
Hello All, This is probably an FAQ, but I read the FAQ and its not in there. I have a machine with 2G of memory. I compiled the kernel with the 4G memory option. How much address space should each process be able to address? Does this change if I use the 64G option? I'm after 2.4 information. Right now I am running on a 2.2 kernel and it looks like the user processes are limited to ~1G. Thanks, Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Wed, May 09, 2001 at 04:19:53PM -0700, Dan Hollis wrote: > On Thu, 10 May 2001, Daniel Phillips wrote: > > It would be great to see a table of ReiserFS/XFS/Ext2+index performance > > results. Well, to make it really fair it should be Ext3+index so I'd > > better add 'backport the patch to 2.2' or 'bug Stephen and friends to > > hurry up' to my to-do list. > > Is the IBM JFS at a testable state yet, or is it still 'bleedin beta'? It is not stable enough to use in production yet. It is certainly stable enough to test/benchmark. They released a new patch today which is supposed to fix a long standing deadlock, so thats good news. Give it a shot. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs, xfs, ext2, ext3
On Wed, May 09, 2001 at 04:19:53PM -0700, Dan Hollis wrote: On Thu, 10 May 2001, Daniel Phillips wrote: It would be great to see a table of ReiserFS/XFS/Ext2+index performance results. Well, to make it really fair it should be Ext3+index so I'd better add 'backport the patch to 2.2' or 'bug Stephen and friends to hurry up' to my to-do list. Is the IBM JFS at a testable state yet, or is it still 'bleedin beta'? It is not stable enough to use in production yet. It is certainly stable enough to test/benchmark. They released a new patch today which is supposed to fix a long standing deadlock, so thats good news. Give it a shot. Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling kernel
On Wed, May 02, 2001 at 06:00:00PM +0530, [EMAIL PROTECTED] wrote: > suppose I am making some change in sched.c and now I want to build my kernel > that reflects the change.. > Is there any way I can avoid answering all the questions when I do make zImage ? > > In short how should I compile the kernel (in very small time) to see my changes. It sounds like you are running "make config" after you make your changes. If you run "make oldconfig" instead of "make config" it will not ask you questions unless you have added config options to the configure scripts. Its probably not necessary to run either on of these if you have just made minor changes to the code. It does not hurt to do it though, and "make oldconfig" is fast. Hope this helps, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling kernel
On Wed, May 02, 2001 at 06:00:00PM +0530, [EMAIL PROTECTED] wrote: suppose I am making some change in sched.c and now I want to build my kernel that reflects the change.. Is there any way I can avoid answering all the questions when I do make zImage ? In short how should I compile the kernel (in very small time) to see my changes. It sounds like you are running make config after you make your changes. If you run make oldconfig instead of make config it will not ask you questions unless you have added config options to the configure scripts. Its probably not necessary to run either on of these if you have just made minor changes to the code. It does not hurt to do it though, and make oldconfig is fast. Hope this helps, Jim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
