Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote: > b) add a new boot option telling the kernel the name of some file in > initrd or similar from which to load additional options. a file in initrd isn't a good choice; as the initrd is generally a fix image the point is some bootloaders might want to pass quite a bit of state to the kernel at times (i actually have this for a mip32 target where i construct a table and pass a pointer to that in, a tad icky but for lack of options) - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote: > Well, we have initramfs for the really big stuff. The kernel > shouldn't really need that much data, though. except the initrd image is in many cases fairly fixed; right now i have options i pass into initramfs by passing arguments on the command line which initrd them reads, parses and uses that to grab a file from the network it's a tad disconnected to have to do this though - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote: > Maybe not. Another option would simply be to bump it up > significantly (2x isn't really that much.) 4096, maybe. I wonder if we're not at the point where we need something different to what we have now. The concept of a command-line works for passing simple state but for more complex things it's too cumbersome. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote: > I think someone on the SYSLINUX mailing list already sent a patch to > akpm to make 512 the default; making it configurable would be a > better idea. Feel free to send your patch through me. So we really need this to be a configuration option? We have too many of those already. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote: I think someone on the SYSLINUX mailing list already sent a patch to akpm to make 512 the default; making it configurable would be a better idea. Feel free to send your patch through me. So we really need this to be a configuration option? We have too many of those already. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote: Maybe not. Another option would simply be to bump it up significantly (2x isn't really that much.) 4096, maybe. I wonder if we're not at the point where we need something different to what we have now. The concept of a command-line works for passing simple state but for more complex things it's too cumbersome. - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote: Well, we have initramfs for the really big stuff. The kernel shouldn't really need that much data, though. except the initrd image is in many cases fairly fixed; right now i have options i pass into initramfs by passing arguments on the command line which initrd them reads, parses and uses that to grab a file from the network it's a tad disconnected to have to do this though - 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: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote: b) add a new boot option telling the kernel the name of some file in initrd or similar from which to load additional options. a file in initrd isn't a good choice; as the initrd is generally a fix image the point is some bootloaders might want to pass quite a bit of state to the kernel at times (i actually have this for a mip32 target where i construct a table and pass a pointer to that in, a tad icky but for lack of options) - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote: > Why don't you do some research on manners? It was (an obvious) troll. Don't take it so seriously. Besides, deep deep down I really am a terrible person. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote: > I know that experience dosen't come from packing the kernel source, > or the zillion other tar archives on the internet. Are you deliberately trying to be annoying? Let me guess: - your under 25 years of age, probably in high school or not far out of it - you have a stupid oversized wanky computer case with neon lighting and useless analog dials and what not. you might have even overclocked it - you've run windows most of your live - you probably run gentoo now. you like the feeling of having everything optimized for your exact system; the addition 0.25% speed increase more than offsets the fact everything is crappy and crashes all the time - you run reiserfs, you probably can't wait till reiser4 is merged so you can run that - you're very interesting in real-time patches. linux should clearly have all real-time stuff merged. second to your interest in realtime is probably something like selinux - if you drive a car, it has extra spoilers added and you've replaced the steering wheel with something from MOMO - you 'friends' are worried you'll die a virgin Please. How about you do a little research on some things for a bit? The initramfs code is done the way it is for a good reason. cpio is used over tar for another good reason. You are most welcome to disagree and even voice you disagreement, but there comes a point where you really need to produce some better arguments. Patches wouldn't hurt either. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote: I know that experience dosen't come from packing the kernel source, or the zillion other tar archives on the internet. Are you deliberately trying to be annoying? Let me guess: - your under 25 years of age, probably in high school or not far out of it - you have a stupid oversized wanky computer case with neon lighting and useless analog dials and what not. you might have even overclocked it - you've run windows most of your live - you probably run gentoo now. you like the feeling of having everything optimized for your exact system; the addition 0.25% speed increase more than offsets the fact everything is crappy and crashes all the time - you run reiserfs, you probably can't wait till reiser4 is merged so you can run that - you're very interesting in real-time patches. linux should clearly have all real-time stuff merged. second to your interest in realtime is probably something like selinux - if you drive a car, it has extra spoilers added and you've replaced the steering wheel with something from MOMO - you 'friends' are worried you'll die a virgin Please. How about you do a little research on some things for a bit? The initramfs code is done the way it is for a good reason. cpio is used over tar for another good reason. You are most welcome to disagree and even voice you disagreement, but there comes a point where you really need to produce some better arguments. Patches wouldn't hurt either. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote: Why don't you do some research on manners? It was (an obvious) troll. Don't take it so seriously. Besides, deep deep down I really am a terrible person. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote: > The purpose of the patch is to overmount ramfs/rootfs with tmpfs before > the compressed cpio archive is unpacked and /init is run. yes and no there are people who want the overmount even without cpio decompression > But, it's only needed because the current initramfs implementation > doesn't offer tmpfs as an option. tmpfs isn't initialized early enough; i've hacked around this but a cleaner solution is needed > /init could just be a symbolic link to /sbin/init, or it could be > some other executable (shell script etc.), but there would be no > need to pivot or move root. pivot is evil, it probably should be depricated - 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: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: > Overmount_rootfs shouldn't take place until you know for sure the > kernel detects an initramfs. Actually, it was a deliberate decision to *always* overmount after some discussion with people. It's not a clean solution and the overall goals aren't clear here so it was never submitted for inclusion --- an the fact is 99.9% of users simply don't need or care for this. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > I'm curious as to why the kernel has to include the decoder - why > you can't just run a self-extracting executable in an empty > initramfs (with a preset capacity if needs be). You could do tht right now if you wished. We just support decompression in the kernel because it's not overly painful to do so (the code exists and works fairly well for the most part). The code to do so isn't ver large and it's marked __init too (well, it should be). - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: > What if you have a root.cpio.gz that requires 200MB to hold, but you > only have 300MB of memory? then it won't work with nay of the schemes you've suggested > 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). no, actually it won't - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: > Wouldn't it be better to put overmount_rootfs in initramfs.c > and call it only if there's a initramfs? I don't see what or how that helps. Yes we can shuffle some code about but the real problem still exists. That is is that (by design) the early userspace is unpacked as soon as possible before all kernel subsystems are up. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote: Wouldn't it be better to put overmount_rootfs in initramfs.c and call it only if there's a initramfs? I don't see what or how that helps. Yes we can shuffle some code about but the real problem still exists. That is is that (by design) the early userspace is unpacked as soon as possible before all kernel subsystems are up. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: What if you have a root.cpio.gz that requires 200MB to hold, but you only have 300MB of memory? then it won't work with nay of the schemes you've suggested 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). no, actually it won't - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: I'm curious as to why the kernel has to include the decoder - why you can't just run a self-extracting executable in an empty initramfs (with a preset capacity if needs be). You could do tht right now if you wished. We just support decompression in the kernel because it's not overly painful to do so (the code exists and works fairly well for the most part). The code to do so isn't ver large and it's marked __init too (well, it should be). - 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: Initramfs and TMPFS!
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote: Overmount_rootfs shouldn't take place until you know for sure the kernel detects an initramfs. Actually, it was a deliberate decision to *always* overmount after some discussion with people. It's not a clean solution and the overall goals aren't clear here so it was never submitted for inclusion --- an the fact is 99.9% of users simply don't need or care for this. - 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: Initramfs and TMPFS!
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote: The purpose of the patch is to overmount ramfs/rootfs with tmpfs before the compressed cpio archive is unpacked and /init is run. yes and no there are people who want the overmount even without cpio decompression But, it's only needed because the current initramfs implementation doesn't offer tmpfs as an option. tmpfs isn't initialized early enough; i've hacked around this but a cleaner solution is needed /init could just be a symbolic link to /sbin/init, or it could be some other executable (shell script etc.), but there would be no need to pivot or move root. pivot is evil, it probably should be depricated - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote: > I don't know, because tar is probably more widely used and > consequently people are more familiar with how to use it. As I said before, the cpio format is cleaner/easier to parse in the kernel. Everyone has cpio probably so using tar isn't necessary. > But, that is not as important as having the option of using tmpfs > as the initramfs. Well, it's not clean that we really want this either. I have some niche needs for it but I suspect most people will never use such an option. - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: > Right, but it would be nice to have that option if initramfs > using tmpfs becomes part of the kernel. But it's not needed so why add bloat? - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: Right, but it would be nice to have that option if initramfs using tmpfs becomes part of the kernel. But it's not needed so why add bloat? - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote: I don't know, because tar is probably more widely used and consequently people are more familiar with how to use it. As I said before, the cpio format is cleaner/easier to parse in the kernel. Everyone has cpio probably so using tar isn't necessary. But, that is not as important as having the option of using tmpfs as the initramfs. Well, it's not clean that we really want this either. I have some niche needs for it but I suspect most people will never use such an option. - 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: > Also, tar should be an option instead of cpio for the archiver, > because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways - 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: > I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes > It uses 50% of total memory for tmpfs, but it would be nice to have > an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever > You need to add this to init/main.c for it to compile. > #include hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that - 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 2.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote: [...] > +Dell OpenManage requires this driver on the following Dell PowerEdge systems: > +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, > +700, and 750. Other Dell software such as the open source Libsmbios library > +is expected to make use of this driver, and it may include the use of this > +driver on other Dell systems. I'd like to see a URL/pointer somewhere about here in the docs for the location of libsmbios if nobody objects. - 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
> Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an older version of it. It's from some old internal
embedded tree but should be trivial to shoehorn into anything recent.
If people really do like or want this I would like to know and maybe
something more elegant can be worked out.
Index: linux/init/main.c
===
--- linux/init/main.c (revision 51)
+++ linux/init/main.c (working copy)
@@ -689,6 +689,49 @@
#endif
}
+/* If we want the rootfs on initramfs so we mount initramfs over the
+ * rootfs before we unpack it. The little dance we do by creating a
+ * pivot point and moving the root to that is in fact necessary
+ * because lookups of "." don't resolve mountpoints.
+ */
+static inline void __init overmount_rootfs(void)
+{
+#ifdef CONFIG_EARLYUSERSPACE_ON_TMPFS
+ int init_tmpfs(void);
+ int (*initfunc)(void) = init_tmpfs;
+ mm_segment_t oldfs;
+ char pivot[] = "/pivot";
+
+ /* Explicitly go and init the overmount fs early (long-term
+* the need for this will probably go away. */
+
+ if (initfunc())
+ goto err;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+
+ if (sys_mkdir(pivot, 0700) < 0)
+ goto err;
+ if (sys_mount("tmpfs", pivot, "tmpfs", 0, NULL))
+ goto err;
+
+ /* Below here errors are unlikely and icky to deal with. */
+ sys_chdir(pivot);
+ sys_mount(".", "/", NULL, MS_MOVE, NULL);
+ sys_chdir(".");
+ sys_chroot(".");
+ printk(KERN_INFO "Overmounted tmpfs\n");
+ goto out;
+
+ err:
+ printk(KERN_ERR "Overmount error\n");
+
+ out:
+ set_fs(oldfs);
+#endif /* CONFIG_EARLYUSERSPACE_ON_TMPFS */
+}
+
static int init(void * unused)
{
lock_kernel();
@@ -715,6 +758,7 @@
* Do this before initcalls, because some drivers want to access
* firmware files.
*/
+ overmount_rootfs();
populate_rootfs();
do_basic_setup();
Index: linux/fs/Kconfig
===
--- linux/fs/Kconfig(revision 51)
+++ linux/fs/Kconfig(working copy)
@@ -951,6 +951,18 @@
If you are not using a security module that requires using
extended attributes for file security labels, say N.
+config EARLYUSERSPACE_ON_TMPFS
+ bool "Unpack the early userspace onto tmpfs"
+ depends TMPFS
+ default y
+ help
+ Use this to have your early userspace placed (decompressed)
+ onto tmpfs as opposed ramfs. This will allow you to
+ restrict the size of your root-filesystem and it will also
+ be swappable.
+
+ If unsure, say Y.
+
config HUGETLBFS
bool "HugeTLB file system support"
depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN
Index: linux/mm/shmem.c
===
--- linux/mm/shmem.c(revision 51)
+++ linux/mm/shmem.c(working copy)
@@ -2206,7 +2206,7 @@
};
static struct vfsmount *shm_mnt;
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
{
int error;
@@ -2239,7 +2239,12 @@
shm_mnt = ERR_PTR(error);
return error;
}
+/* Don't do this if we are calling it early explicity */
+#ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS
+/* Iff CONFIG_EARLYUSERSPACE_ON_TMPFS is set then we will interpose
+ * ramfs so this will get called explicitly and early */
module_init(init_tmpfs)
+#endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */
/*
* shmem_file_setup - get an unlinked file living in tmpfs
-
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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an older version of it. It's from some old internal
embedded tree but should be trivial to shoehorn into anything recent.
If people really do like or want this I would like to know and maybe
something more elegant can be worked out.
Index: linux/init/main.c
===
--- linux/init/main.c (revision 51)
+++ linux/init/main.c (working copy)
@@ -689,6 +689,49 @@
#endif
}
+/* If we want the rootfs on initramfs so we mount initramfs over the
+ * rootfs before we unpack it. The little dance we do by creating a
+ * pivot point and moving the root to that is in fact necessary
+ * because lookups of . don't resolve mountpoints.
+ */
+static inline void __init overmount_rootfs(void)
+{
+#ifdef CONFIG_EARLYUSERSPACE_ON_TMPFS
+ int init_tmpfs(void);
+ int (*initfunc)(void) = init_tmpfs;
+ mm_segment_t oldfs;
+ char pivot[] = /pivot;
+
+ /* Explicitly go and init the overmount fs early (long-term
+* the need for this will probably go away. */
+
+ if (initfunc())
+ goto err;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+
+ if (sys_mkdir(pivot, 0700) 0)
+ goto err;
+ if (sys_mount(tmpfs, pivot, tmpfs, 0, NULL))
+ goto err;
+
+ /* Below here errors are unlikely and icky to deal with. */
+ sys_chdir(pivot);
+ sys_mount(., /, NULL, MS_MOVE, NULL);
+ sys_chdir(.);
+ sys_chroot(.);
+ printk(KERN_INFO Overmounted tmpfs\n);
+ goto out;
+
+ err:
+ printk(KERN_ERR Overmount error\n);
+
+ out:
+ set_fs(oldfs);
+#endif /* CONFIG_EARLYUSERSPACE_ON_TMPFS */
+}
+
static int init(void * unused)
{
lock_kernel();
@@ -715,6 +758,7 @@
* Do this before initcalls, because some drivers want to access
* firmware files.
*/
+ overmount_rootfs();
populate_rootfs();
do_basic_setup();
Index: linux/fs/Kconfig
===
--- linux/fs/Kconfig(revision 51)
+++ linux/fs/Kconfig(working copy)
@@ -951,6 +951,18 @@
If you are not using a security module that requires using
extended attributes for file security labels, say N.
+config EARLYUSERSPACE_ON_TMPFS
+ bool Unpack the early userspace onto tmpfs
+ depends TMPFS
+ default y
+ help
+ Use this to have your early userspace placed (decompressed)
+ onto tmpfs as opposed ramfs. This will allow you to
+ restrict the size of your root-filesystem and it will also
+ be swappable.
+
+ If unsure, say Y.
+
config HUGETLBFS
bool HugeTLB file system support
depends X86 || IA64 || PPC64 || SPARC64 || SUPERH || X86_64 || BROKEN
Index: linux/mm/shmem.c
===
--- linux/mm/shmem.c(revision 51)
+++ linux/mm/shmem.c(working copy)
@@ -2206,7 +2206,7 @@
};
static struct vfsmount *shm_mnt;
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
{
int error;
@@ -2239,7 +2239,12 @@
shm_mnt = ERR_PTR(error);
return error;
}
+/* Don't do this if we are calling it early explicity */
+#ifndef CONFIG_EARLYUSERSPACE_ON_TMPFS
+/* Iff CONFIG_EARLYUSERSPACE_ON_TMPFS is set then we will interpose
+ * ramfs so this will get called explicitly and early */
module_init(init_tmpfs)
+#endif /* !CONFIG_EARLYUSERSPACE_ON_TMPFS */
/*
* shmem_file_setup - get an unlinked file living in tmpfs
-
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 2.6.13-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote: [...] +Dell OpenManage requires this driver on the following Dell PowerEdge systems: +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, +700, and 750. Other Dell software such as the open source Libsmbios library +is expected to make use of this driver, and it may include the use of this +driver on other Dell systems. I'd like to see a URL/pointer somewhere about here in the docs for the location of libsmbios if nobody objects. - 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: Initramfs and TMPFS!
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote: I tried it with kernel 2.6.13-rc5 and it seems to work. it should yes It uses 50% of total memory for tmpfs, but it would be nice to have an option (tmpfs_size=90% etc.) that you could pass to the kernel. that's just because of the tmpfs default; you can remount to change that if it's not suitable once your up and running in your init-scripts or whatever You need to add this to init/main.c for it to compile. #include asm/uaccess.h hmm... really? i'll rediff it at some point and test it maybe. i really don't like the explicity shm init though, i'd like to think of a cleaner way to do that - 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote: Also, tar should be an option instead of cpio for the archiver, because tar is more widely used. pretty much everyone will have cpio and it's format is much simpler/cleaner to deal with if we want vastly more complex early-userspace semantics i think we need to carefully decide what is needed and how to put as much of that logic into userspace rather than hacking this much more in the kernel for fear of breaking things in subtle ways - 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote: > I was just making a suggestion to whoever it may concern, because I > think it would extend the usefullness of initramfs. I have a path for initramfs to use tmpfs. It's sorta hacky so I never submitted it and solves a niche problem for embedded people. Ultimately we might one day still want to change how we initialize the early userspace (Al suggesting a reasomably nice way to move the decompressor(s) to userspace for example) so I don't feel there is a compelling reason to do more than cleanups in this area right now. - 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: Initramfs and TMPFS!
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote: I was just making a suggestion to whoever it may concern, because I think it would extend the usefullness of initramfs. I have a path for initramfs to use tmpfs. It's sorta hacky so I never submitted it and solves a niche problem for embedded people. Ultimately we might one day still want to change how we initialize the early userspace (Al suggesting a reasomably nice way to move the decompressor(s) to userspace for example) so I don't feel there is a compelling reason to do more than cleanups in this area right now. - 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 for changing of DVD speed via ioctl() call
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
> The parameter value should IMHO be a pointer to a struct {
> unsigned long long maxspeed; // (with 0 being the magic max. value?)
> int facility; /* 0=general speed, 2=general read, 4=read data,
> 6=read audio, 8=read raw ... whatever is supported
> n+1 = s/read/write/ */
> }
Passing pointers inside ioctl's is horrible IMO and if we can avoid it
we should. It's just asking for problems.
-
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 for changing of DVD speed via ioctl() call
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
The parameter value should IMHO be a pointer to a struct {
unsigned long long maxspeed; // (with 0 being the magic max. value?)
int facility; /* 0=general speed, 2=general read, 4=read data,
6=read audio, 8=read raw ... whatever is supported
n+1 = s/read/write/ */
}
Passing pointers inside ioctl's is horrible IMO and if we can avoid it
we should. It's just asking for problems.
-
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: largefile-support-for-accounting.patch added to -mm tree
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote: > Another annoying problem is that once the system reaches this 2GB > limit, then every process which exits will receive a signal, > SIGXFSZ. This signal is generated because an attempt was made to > write beyond the limit for the file descriptor. This signal makes > it look like every process has exited due to a signal, when in fact, > they have not. Eeek. > The solution is to add the O_LARGEFILE flag to the list of flags > used to open the accounting file. The rest of the accounting > support is already largefile safe. That fixes the larger accounting file problem but it doesn't address the fact that signals resulting writes to the accounting file are delivered incorrectly. We could still have issues if the accounting file as over quota for example. Surely all accounting file writes should be insulated from the processes involved? - 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: largefile-support-for-accounting.patch added to -mm tree
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote: Another annoying problem is that once the system reaches this 2GB limit, then every process which exits will receive a signal, SIGXFSZ. This signal is generated because an attempt was made to write beyond the limit for the file descriptor. This signal makes it look like every process has exited due to a signal, when in fact, they have not. Eeek. The solution is to add the O_LARGEFILE flag to the list of flags used to open the accounting file. The rest of the accounting support is already largefile safe. That fixes the larger accounting file problem but it doesn't address the fact that signals resulting writes to the accounting file are delivered incorrectly. We could still have issues if the accounting file as over quota for example. Surely all accounting file writes should be insulated from the processes involved? - 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: sched_yield() makes OpenLDAP slow
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote: > If the 2.6 kernel makes this programming model unreasonably slow, > then quite simply this kernel is not viable as a database platform. Pretty much everyone else manages to make it work. - 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: sched_yield() makes OpenLDAP slow
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote: If the 2.6 kernel makes this programming model unreasonably slow, then quite simply this kernel is not viable as a database platform. Pretty much everyone else manages to make it work. - 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: overflows in /proc/net/dev
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
> in struct net_device_stats all members are defined as unsgined
> long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspace and deal with it as needed.
> Are there any plans to change these coutners to unsigned long long?
It comes up from time to time (see below).
> I saw in ifconfig source code the byte and packet counters are
> already defined as unsigned long long.
ifconfig is userspace.
[...]
> struct net_device_stats
> {
> - unsigned long rx_packets; /* total packets received
> */
> - unsigned long tx_packets; /* total packets transmitted
> */
> - unsigned long rx_bytes; /* total bytes received */
> - unsigned long tx_bytes; /* total bytes transmitted */
> + unsigned long long rx_packets; /* total packets received
> */
> + unsigned long long tx_packets; /* total packets transmitted
> */
> + unsigned long long rx_bytes;/* total bytes received
> */
> + unsigned long long tx_bytes;/* total bytes transmitted
> */
I thought the concensurs here was that because doing reliable atomic
updates of 64-bit values isn't possible on some (most?) 32-bit
architectures so we need additional locking to make this work which is
undesirable? (It might even be a FAQ by now as this comes up fairly
often).
-
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] Watchdog device node name unification
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote: > Looks like people never learn. We had horrible problems with devfs > because it decided to overload existing name fields, but the udev > brigade does the same idiocy again.. It's not too late to fix this. We can add a new field and rename the old one with minimal effort. - 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: NCQ support NVidia NForce4 (CK804) SATAII
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote: > I also agree and am rather disappointed by this news. > Unfortunately, I've already bought an A8N-SLI. If you can send it back citing the driver issues as the reason. Linux sales are probably a tiny blip on the radar for them so I don't expect this to make a big difference immediately but keeping constant pressure of vendors like nvidia about openness is probably the best we can do right now (obviously this means avoiding buying their products as much as possible). - 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] pull XFS support out of Kconfig submenu
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote: > It seems slightly odd to me that XFS support should be in a separate > submenu, when all the other filesystems are not using submenus but > are directly selectable from the Filesystems menu. XFS also has an out-of-tree version. Making it a submenu is probably to make maintenance easier (ie. replace files, not merge). - 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] pull XFS support out of Kconfig submenu
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote: It seems slightly odd to me that XFS support should be in a separate submenu, when all the other filesystems are not using submenus but are directly selectable from the Filesystems menu. XFS also has an out-of-tree version. Making it a submenu is probably to make maintenance easier (ie. replace files, not merge). - 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: NCQ support NVidia NForce4 (CK804) SATAII
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote: I also agree and am rather disappointed by this news. Unfortunately, I've already bought an A8N-SLI. If you can send it back citing the driver issues as the reason. Linux sales are probably a tiny blip on the radar for them so I don't expect this to make a big difference immediately but keeping constant pressure of vendors like nvidia about openness is probably the best we can do right now (obviously this means avoiding buying their products as much as possible). - 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] Watchdog device node name unification
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote: Looks like people never learn. We had horrible problems with devfs because it decided to overload existing name fields, but the udev brigade does the same idiocy again.. It's not too late to fix this. We can add a new field and rename the old one with minimal effort. - 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: overflows in /proc/net/dev
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
in struct net_device_stats all members are defined as unsgined
long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspace and deal with it as needed.
Are there any plans to change these coutners to unsigned long long?
It comes up from time to time (see below).
I saw in ifconfig source code the byte and packet counters are
already defined as unsigned long long.
ifconfig is userspace.
[...]
struct net_device_stats
{
- unsigned long rx_packets; /* total packets received
*/
- unsigned long tx_packets; /* total packets transmitted
*/
- unsigned long rx_bytes; /* total bytes received */
- unsigned long tx_bytes; /* total bytes transmitted */
+ unsigned long long rx_packets; /* total packets received
*/
+ unsigned long long tx_packets; /* total packets transmitted
*/
+ unsigned long long rx_bytes;/* total bytes received
*/
+ unsigned long long tx_bytes;/* total bytes transmitted
*/
I thought the concensurs here was that because doing reliable atomic
updates of 64-bit values isn't possible on some (most?) 32-bit
architectures so we need additional locking to make this work which is
undesirable? (It might even be a FAQ by now as this comes up fairly
often).
-
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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote: > Hmm... did I mention libsmbios? :-) > http://linux.dell.com/libsmbios/main. I'm aware of it --- it seems pretty limited right now and I'm still irked Dell isn't more forthcoming with documentation. > SMI support is not yet implemented inside libsmbios, but I am > working feverishly on it (in-between emails to linux-kernel, of > course.) :-) We have a development mailing list, and I will make the > announcement there when it has been complete. [...] > I cannot (at this point, I'm working on it, though), provide our > internal documentation of our SMI implementation directly. But, I am > authorized to add all of this to libsmbios, and I intend to very > clearly document all of the SMI calls in libsmbios. Given that why not resubmit the kernel driver when the userspace becomes usable for people without them having to use MonsterApp from Dell? > Aside from that, for the most part, the only thing SMI ever does is > pass buffers back and forth. I meant to ask; does this have horrible latency or nasties like lots of laptop SMM stuff? - 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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote: > I'm worried that it might be more of a mess in userspace than it > could be if done properly in the kernel. I would rather if it's gonna be a mess it's, then we put that mess in userspace rather than in the kernel. > Hardware drivers, especially for something as critical as the BIOS, > should probably be done in-kernel. For the most part it's not for the BIOS though AFAICT. It's for some hacky little microcontroller that controls fans and similar things that Dell won't give up details for. > Look at the mess that X has become, it mmaps /dev/mem and pokes at > the PCI busses directly. I just don't want an MSI-driver to become > another /dev/mem. It's for old hardware, I'm not sure it will evolve much other than just for maintenance. It's really hard to say, maybe if Dell gave more details about the userspace we would have a better idea? - 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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote: > Why can't you just implement the system management actions in the > kernel driver? Why put things in the kernel unless it's really needed? I'm not thrillied about the lack of userspace support for this driver but that still doesn't mean we need to shovel wads of crap into the kernel. - 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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote: Why can't you just implement the system management actions in the kernel driver? Why put things in the kernel unless it's really needed? I'm not thrillied about the lack of userspace support for this driver but that still doesn't mean we need to shovel wads of crap into the kernel. - 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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote: I'm worried that it might be more of a mess in userspace than it could be if done properly in the kernel. I would rather if it's gonna be a mess it's, then we put that mess in userspace rather than in the kernel. Hardware drivers, especially for something as critical as the BIOS, should probably be done in-kernel. For the most part it's not for the BIOS though AFAICT. It's for some hacky little microcontroller that controls fans and similar things that Dell won't give up details for. Look at the mess that X has become, it mmaps /dev/mem and pokes at the PCI busses directly. I just don't want an MSI-driver to become another /dev/mem. It's for old hardware, I'm not sure it will evolve much other than just for maintenance. It's really hard to say, maybe if Dell gave more details about the userspace we would have a better idea? - 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][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote: Hmm... did I mention libsmbios? :-) http://linux.dell.com/libsmbios/main. I'm aware of it --- it seems pretty limited right now and I'm still irked Dell isn't more forthcoming with documentation. SMI support is not yet implemented inside libsmbios, but I am working feverishly on it (in-between emails to linux-kernel, of course.) :-) We have a development mailing list, and I will make the announcement there when it has been complete. [...] I cannot (at this point, I'm working on it, though), provide our internal documentation of our SMI implementation directly. But, I am authorized to add all of this to libsmbios, and I intend to very clearly document all of the SMI calls in libsmbios. Given that why not resubmit the kernel driver when the userspace becomes usable for people without them having to use MonsterApp from Dell? Aside from that, for the most part, the only thing SMI ever does is pass buffers back and forth. I meant to ask; does this have horrible latency or nasties like lots of laptop SMM stuff? - 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] Watchdog device node name unification
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote: > It is used for /class/misc/$name/dev Ick. I would almost suggest we change that were it not too late. I think keeping the decription is useful and desirable. - 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] Watchdog device node name unification
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote: It is used for /class/misc/$name/dev Ick. I would almost suggest we change that were it not too late. I think keeping the decription is useful and desirable. - 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: Syncing single filesystem (slow USB writing)
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote: > Mandrake always mounted USB sticks with sync option; it was > effectively noop except for a patch that implemented limited dsync > semantic. fwiw; various people have reported using flash block devices with 'sync' ruins them as there can be many more (and very frequent) updates to the device - 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: Syncing single filesystem (slow USB writing)
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote: Mandrake always mounted USB sticks with sync option; it was effectively noop except for a patch that implemented limited dsync semantic. fwiw; various people have reported using flash block devices with 'sync' ruins them as there can be many more (and very frequent) updates to the device - 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] ramfs: pretend dirent sizes
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote: > In both cases, what used to be a proper offset in one fd can be > complete bogus for another one. Exactly. Knowing the position within a directory is of questionable value and trying to implement any reliable semantics for lseek is futile. - 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] ramfs: pretend dirent sizes
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote: In both cases, what used to be a proper offset in one fd can be complete bogus for another one. Exactly. Knowing the position within a directory is of questionable value and trying to implement any reliable semantics for lseek is futile. - 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] ramfs: pretend dirent sizes
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote: > To my understanding, you can lseek to any "proper" offset inside a > directory. Proper means that the offset marks the beginning of a > new dirent (or end of file) in the interpretation of the filesystem. But you can never tell where these are in general. > Userspace doesn't have any means to figure out, which addresses are > proper and which aren't. Except that getdents(2) moves the fd > offset to a proper address, which likely will remain proper until > the fd is closed. I don't see why or how this can be true in general (it might be, but I don't see how myself). If we are half way through scanning a directory and people start messing with it we could end up somewhere bogus (in which case f_op->readdir I guess is expected to try and do something sane here?) > Reopening the same directory may result in a formerly proper offset > isn't anymore. For that to be the case where is the state kept to ensure your current offset is valid? - 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] ramfs: pretend dirent sizes
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote: To my understanding, you can lseek to any proper offset inside a directory. Proper means that the offset marks the beginning of a new dirent (or end of file) in the interpretation of the filesystem. But you can never tell where these are in general. Userspace doesn't have any means to figure out, which addresses are proper and which aren't. Except that getdents(2) moves the fd offset to a proper address, which likely will remain proper until the fd is closed. I don't see why or how this can be true in general (it might be, but I don't see how myself). If we are half way through scanning a directory and people start messing with it we could end up somewhere bogus (in which case f_op-readdir I guess is expected to try and do something sane here?) Reopening the same directory may result in a formerly proper offset isn't anymore. For that to be the case where is the state kept to ensure your current offset is valid? - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote: > >So you can seek to m*+ to access an offset into > >something at depth m? > > > > Yes. Hos does that work if offset >= m? > I disagree. Where is the information value of i_size if we always > could return 0? Directories clearly can't have zero size, so 0 means 'special'. Anything other than zero *might* be a real value. > IMO it should be at least an upper bound for the "number" of > informations that could actually be read (in terms of a seek offset) > like it is in the case of regular files. Why? And what should that upper bound be? > Better, if it is a strict upper bound so that you can seek to every > value smaller than i_size. For this purpose the i_size of > directories doesn't need to reflect any unit. lseek talks about bytes --- yes, it means for files specifically but I still don't see why we need to define more counter-intuitive semantics for directories when we don't need them. Also, how is lseek + readdir supposed to work in general? - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote: > Since these "arranged" values are also used as the offsets in the > return dirent IMO it is quite clean. So the size you want to reflect is n* i take it? Where in this case n is 20? So you can seek to m*+ to access an offset into something at depth m? > Nope. This value is kind of traditional: tmpfs is using it > (http://marc.theaimsgroup.com/?l=linux-kernel=103208296515378=2). I > think a better value would be 1 (one) since this is also used as the > dirent offset by dcache_readdir(). I really don't know why tmpfs is doing this. > The i_size of a directory isn't covered by the POSIX standard. IMO, > it should be possible to seek in the range of i_size and a following > readdir() on the directory should succeed. With what defined semantics? What if an entry is added in between seek and readdir? > But this isn't possible even not with real file systems like ext2. I'm not sure how expecting a meaningful offset into a directory can have consistent bahvior. > But keeping the i_size bound to zero even if the directory contains > entries does not make sense at all. Why? It seems perfectly reasonable that we can return 0 in such cases. Zero seems to make more sense as 'magical/unknown' than say any other arbitrary value. It's also possible a regular filesystem could return an arbitrary value such as 20 (not that this directly matters except it becomes confusing potentially): [EMAIL PROTECTED]:~$ mkdir foobar [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 2 cw cw 6 Jul 19 11:29 foobar [EMAIL PROTECTED]:~$ mkdir foobar/1234567 [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 3 cw cw 20 Jul 19 11:30 foobar - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote: > I'm using the i_size of directories in my patches. When reading > from a union directory, I'm using the i_size to seek to the right > offset in the union stack. Ick. That'a a bit of a hack. > Therefore I need values of dirent->d_off which are smaller than the > i_size of the directory. Hence the value of 20 I guess --- assuming nothing will stack this high? > Altogether, it doesn't make sense to me to seek to an offset which > is greater than the i_size and let the dirent read succeed. I personally would prefer that to be honest or some other way that doesn't change i_size. - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote: I'm using the i_size of directories in my patches. When reading from a union directory, I'm using the i_size to seek to the right offset in the union stack. Ick. That'a a bit of a hack. Therefore I need values of dirent-d_off which are smaller than the i_size of the directory. Hence the value of 20 I guess --- assuming nothing will stack this high? Altogether, it doesn't make sense to me to seek to an offset which is greater than the i_size and let the dirent read succeed. I personally would prefer that to be honest or some other way that doesn't change i_size. - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote: Since these arranged values are also used as the offsets in the return dirent IMO it is quite clean. So the size you want to reflect is n*stack-depth i take it? Where in this case n is 20? So you can seek to m*stack-depth+offset to access an offset into something at depth m? Nope. This value is kind of traditional: tmpfs is using it (http://marc.theaimsgroup.com/?l=linux-kernelm=103208296515378w=2). I think a better value would be 1 (one) since this is also used as the dirent offset by dcache_readdir(). I really don't know why tmpfs is doing this. The i_size of a directory isn't covered by the POSIX standard. IMO, it should be possible to seek in the range of i_size and a following readdir() on the directory should succeed. With what defined semantics? What if an entry is added in between seek and readdir? But this isn't possible even not with real file systems like ext2. I'm not sure how expecting a meaningful offset into a directory can have consistent bahvior. But keeping the i_size bound to zero even if the directory contains entries does not make sense at all. Why? It seems perfectly reasonable that we can return 0 in such cases. Zero seems to make more sense as 'magical/unknown' than say any other arbitrary value. It's also possible a regular filesystem could return an arbitrary value such as 20 (not that this directly matters except it becomes confusing potentially): [EMAIL PROTECTED]:~$ mkdir foobar [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 2 cw cw 6 Jul 19 11:29 foobar [EMAIL PROTECTED]:~$ mkdir foobar/1234567 [EMAIL PROTECTED]:~$ ls -ld foobar drwxr-xr-x 3 cw cw 20 Jul 19 11:30 foobar - 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] ramfs: pretend dirent sizes
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote: So you can seek to m*stack-depth+offset to access an offset into something at depth m? Yes. Hos does that work if offset = m? I disagree. Where is the information value of i_size if we always could return 0? Directories clearly can't have zero size, so 0 means 'special'. Anything other than zero *might* be a real value. IMO it should be at least an upper bound for the number of informations that could actually be read (in terms of a seek offset) like it is in the case of regular files. Why? And what should that upper bound be? Better, if it is a strict upper bound so that you can seek to every value smaller than i_size. For this purpose the i_size of directories doesn't need to reflect any unit. lseek talks about bytes --- yes, it means for files specifically but I still don't see why we need to define more counter-intuitive semantics for directories when we don't need them. Also, how is lseek + readdir supposed to work in general? - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote: > Because the hardware interfaces on those systems and the Dell > systems management software that access the interfaces are > proprietary, I can't provide specifications for the interfaces or > source code for the software. So you want a driver merged which nobody except Dell can write code for? > The systems that are supported by the dcdbas driver contain the > following Dell proprietary hardware systems management interfaces: > Temperature Voltage Monitor (TVM) and Calling Interface. These > interfaces are supported by older Dell PowerEdge systems. What's so special here that you can't give more details? I personally find it a little unfair to ask to have a driver merged into mainline to facilitate some proprietary userland where you refuse to give protocol level details to create a viable alternative. - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote: Because the hardware interfaces on those systems and the Dell systems management software that access the interfaces are proprietary, I can't provide specifications for the interfaces or source code for the software. So you want a driver merged which nobody except Dell can write code for? The systems that are supported by the dcdbas driver contain the following Dell proprietary hardware systems management interfaces: Temperature Voltage Monitor (TVM) and Calling Interface. These interfaces are supported by older Dell PowerEdge systems. What's so special here that you can't give more details? I personally find it a little unfair to ask to have a driver merged into mainline to facilitate some proprietary userland where you refuse to give protocol level details to create a viable alternative. - 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] ramfs: pretend dirent sizes
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote: > I really think you should update the "simple_xxx()" functions > instead, and thus make this happen for _any_ filesystem that uses > the simple fs helper functions. Why bother at all? I don't see why zero sizes are a problem. We've had them for year without complaints. - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote: > So, the 13-year-old design advice will continue to apply to > 13-year-old systems, but newer systems with C3 and HPET > should be using them. Last I looked HPET isn't everywhere yet (absent from nforce4 mainboards for example, but that might be a linux issue as I was told window can see one). - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote: So, the 13-year-old design advice will continue to apply to 13-year-old systems, but newer systems with C3 and HPET should be using them. Last I looked HPET isn't everywhere yet (absent from nforce4 mainboards for example, but that might be a linux issue as I was told window can see one). - 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] ramfs: pretend dirent sizes
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote: I really think you should update the simple_xxx() functions instead, and thus make this happen for _any_ filesystem that uses the simple fs helper functions. Why bother at all? I don't see why zero sizes are a problem. We've had them for year without complaints. - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote: > AFAIK John simply wants to change jiffies to count in nanoseconds > since bootup and then call it "clock_monotonic". Clocks and counter drift so calling it seconds would be misleading. It would really only be good for approximate timing. I think call it something arbitrary and work towards have a separate mechanism for time of day (which could end up being much more expensive to use but less frrequently needed). > One 64 bit value no splitting into seconds and nanoseconds anymore. Using a 64-bit value is a pain on some (many?) 32-bit CPUs. - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote: AFAIK John simply wants to change jiffies to count in nanoseconds since bootup and then call it clock_monotonic. Clocks and counter drift so calling it prefixseconds would be misleading. It would really only be good for approximate timing. I think call it something arbitrary and work towards have a separate mechanism for time of day (which could end up being much more expensive to use but less frrequently needed). One 64 bit value no splitting into seconds and nanoseconds anymore. Using a 64-bit value is a pain on some (many?) 32-bit CPUs. - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote: > windows xp base rate is 100Hz... but multimedia apps can ask for > almost any rate they want (depends on the hw capabilities). i > recall seeing rates >1200Hz when you launch some of the media player > apps -- sorry i forget the exact number. Windows starts an additional high-speed timer as needed for this? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote: > Does anyone object to setting HZ at boot? I suspect nothing else > will make everyone happy. Does it bloat the code or slow things measurably? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote: > Len Brown, a year ago: "The bottom line number to laptop users is > battery lifetime. Just today somebody complained to me that Windows > gets twice the battery life that Linux does." It seems the motivation for lower HZ is really: (1) ACPI/SMM suckage in laptops (2) NUMA systems with *horrible* remote memory latencies Both can be detected from you .config and we could see HZ as needed there and everyone else could avoid this surely? The above one year old comment where it says "someone complained" makes me wonder if we ever had an original report with hard facts or just some internal/private comment/bug about how things seem. Surely we can test this accurately? > "My expectation is if we want to beat the competition, we'll want > the ability to go *under* 100Hz." What does Windows do here? > Len, any updates on the relationship between HZ and power > consumption? I can measure this[1] for some *old* hardware but as it has unusable behavior for ACPI I'm not sure how useful that is. [1] I was just going to remove batteries and run it from a bench supply in the lab and measure how much current was being drawn. Can anyone suggest something more sensible than that? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote: Len Brown, a year ago: The bottom line number to laptop users is battery lifetime. Just today somebody complained to me that Windows gets twice the battery life that Linux does. It seems the motivation for lower HZ is really: (1) ACPI/SMM suckage in laptops (2) NUMA systems with *horrible* remote memory latencies Both can be detected from you .config and we could see HZ as needed there and everyone else could avoid this surely? The above one year old comment where it says someone complained makes me wonder if we ever had an original report with hard facts or just some internal/private comment/bug about how things seem. Surely we can test this accurately? My expectation is if we want to beat the competition, we'll want the ability to go *under* 100Hz. What does Windows do here? Len, any updates on the relationship between HZ and power consumption? I can measure this[1] for some *old* hardware but as it has unusable behavior for ACPI I'm not sure how useful that is. [1] I was just going to remove batteries and run it from a bench supply in the lab and measure how much current was being drawn. Can anyone suggest something more sensible than that? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote: Does anyone object to setting HZ at boot? I suspect nothing else will make everyone happy. Does it bloat the code or slow things measurably? - 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] i386: Selectable Frequency of the Timer Interrupt
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote: windows xp base rate is 100Hz... but multimedia apps can ask for almost any rate they want (depends on the hw capabilities). i recall seeing rates 1200Hz when you launch some of the media player apps -- sorry i forget the exact number. Windows starts an additional high-speed timer as needed for this? - 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] i386: Selectable Frequency of the Timer Interrupt
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote: > The real answer here is for the tickless patches to cleaned up to > the point where they can be merged, and then we won't waste battery > power entering the timer interrupt in the first place. :-) Whilst conceptually this is a nice idea I've yet to see any viable code that overall has a lower cost. Tickless is a really nice idea for embedded devices and also paravirtualized hardware but I don't think anyone has it working well enough yet do they? - 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] i386: Selectable Frequency of the Timer Interrupt
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote: The real answer here is for the tickless patches to cleaned up to the point where they can be merged, and then we won't waste battery power entering the timer interrupt in the first place. :-) Whilst conceptually this is a nice idea I've yet to see any viable code that overall has a lower cost. Tickless is a really nice idea for embedded devices and also paravirtualized hardware but I don't think anyone has it working well enough yet do they? - 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] compress the stack layout of do_page_fault(), x86
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote: > this patch pushes the creation of a rare signal frame (SIGBUS or > SIGSEGV) into a separate function, thus saving stackspace in the > main do_page_fault() stackframe. The effect is 132 bytes less of > stack used by the typical do_page_fault() invocation - resulting in > a denser cache-layout. does the benefit actually show up anywhere? - 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote: > BTW, Christoph Lameter, if you're seeing this, your mail is bouncing... my bad, i typoed it when i first send the original email - 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote: > it's a config option. Some distros ship 100 already, others 1000, > again others will do 250. Who does anything other than 1000 for a 2.6.x kernel? - 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote: it's a config option. Some distros ship 100 already, others 1000, again others will do 250. Who does anything other than 1000 for a 2.6.x kernel? - 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] i386: Selectable Frequency of the Timer Interrupt
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote: BTW, Christoph Lameter, if you're seeing this, your mail is bouncing... my bad, i typoed it when i first send the original email - 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] compress the stack layout of do_page_fault(), x86
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote: this patch pushes the creation of a rare signal frame (SIGBUS or SIGSEGV) into a separate function, thus saving stackspace in the main do_page_fault() stackframe. The effect is 132 bytes less of stack used by the typical do_page_fault() invocation - resulting in a denser cache-layout. does the benefit actually show up anywhere? - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote: > I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I > can confirm more explicitly if really need be. 48s -> 45.5s elapsed. That's a huge difference (5%) --- what hardware is that on? - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote: > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > ^^ > It's been over two weeks and nobody has complained about anything. Two weeks isn't that long IMO (I only just noticed myself). > Because 1000 is too high. How so? There have been comparatively few complaints about this since we switched quite some time ago. Strictly speaking I agree 1000 might be too high --- but we've had it for so long now, almost all over 2.5.x (I think?) and all of 2.6.x. - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > [PATCH] i386: Selectable Frequency of the Timer Interrupt [...] > +choice > + prompt "Timer frequency" > + default HZ_250 WHAT? The previous value here i386 is 1000 --- so why is the default 250. Changing the *default* time interrupt frequency in a stable series is *really* bad idea if you ask me. Now that this has hit mainline please consider applying: --- kernel/Kconfig.hz~ 2005-06-24 22:16:35.023986593 -0700 +++ kernel/Kconfig.hz 2005-07-08 14:46:35.428917597 -0700 @@ -4,7 +4,7 @@ choice prompt "Timer frequency" - default HZ_250 + default HZ_1000 help Allows the configuration of the timer frequency. It is customary to have the timer interrupt run at 1000 HZ but 100 HZ may be more - 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] i386: Selectable Frequency of the Timer Interrupt
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: [PATCH] i386: Selectable Frequency of the Timer Interrupt [...] +choice + prompt Timer frequency + default HZ_250 WHAT? The previous value here i386 is 1000 --- so why is the default 250. Changing the *default* time interrupt frequency in a stable series is *really* bad idea if you ask me. Now that this has hit mainline please consider applying: --- kernel/Kconfig.hz~ 2005-06-24 22:16:35.023986593 -0700 +++ kernel/Kconfig.hz 2005-07-08 14:46:35.428917597 -0700 @@ -4,7 +4,7 @@ choice prompt Timer frequency - default HZ_250 + default HZ_1000 help Allows the configuration of the timer frequency. It is customary to have the timer interrupt run at 1000 HZ but 100 HZ may be more - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote: On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: ^^ It's been over two weeks and nobody has complained about anything. Two weeks isn't that long IMO (I only just noticed myself). Because 1000 is too high. How so? There have been comparatively few complaints about this since we switched quite some time ago. Strictly speaking I agree 1000 might be too high --- but we've had it for so long now, almost all over 2.5.x (I think?) and all of 2.6.x. - 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] i386: Selectable Frequency of the Timer Interrupt
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote: I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I can confirm more explicitly if really need be. 48s - 45.5s elapsed. That's a huge difference (5%) --- what hardware is that on? - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote: > This patch adds the Dell Systems Management Base driver. You keep posting this driver without explaining/showing how it's used. Could you perhaps give some more details here please? - 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] char: Add Dell Systems Management Base driver
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote: This patch adds the Dell Systems Management Base driver. You keep posting this driver without explaining/showing how it's used. Could you perhaps give some more details here please? - 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/
