Re: setting cpu speed on crusoe
Linus Torvalds <[EMAIL PROTECTED]> writes: > We're going through our docs and we have internal programs that we'll > release for this so that you'll not just have docs but actually working > code too. It just needs to be cleaned up a bit, and go through the proper > channels (ever wonder why open source gets deveoped faster?). It really > should be "any day now". Working code is better anyway (and in this case, it's first). Go to your favorite kernel.org mirror and check out /pub/linux/utils/cpu/crusoe/longrun-0.9.tar.gz It does everything you could ever want and more, as long as you include the CPUID and MSR devices in your kernel, set up the devices correctly, etc. Dan - 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: setting cpu speed on crusoe
Linus Torvalds [EMAIL PROTECTED] writes: We're going through our docs and we have internal programs that we'll release for this so that you'll not just have docs but actually working code too. It just needs to be cleaned up a bit, and go through the proper channels (ever wonder why open source gets deveoped faster?). It really should be "any day now". Working code is better anyway (and in this case, it's first). Go to your favorite kernel.org mirror and check out /pub/linux/utils/cpu/crusoe/longrun-0.9.tar.gz It does everything you could ever want and more, as long as you include the CPUID and MSR devices in your kernel, set up the devices correctly, etc. Dan - 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/
cramfs filesystem patch for 2.4.0
For symlinks and non-empty regular files, this
+ contains the offset (divided by 4) of the file data in
+ compressed form (starting with an array of block pointers;
+ see README). For non-empty directories it is the offset
+ (divided by 4) of the inode of the first file in that
+ directory. For anything else, offset is zero. */
+ u32 namelen:CRAMFS_NAMELEN_WIDTH, offset:CRAMFS_OFFSET_WIDTH;
+};
+
+struct cramfs_info {
+ u32 crc;
+ u32 edition;
+ u32 blocks;
+ u32 files;
+};
+
+/*
+ * Superblock information at the beginning of the FS.
+ */
+struct cramfs_super {
+ u32 magic; /* 0x28cd3d45 - random number */
+ u32 size; /* length in bytes */
+ u32 flags; /* 0 */
+ u32 future; /* 0 */
+ u8 signature[16]; /* "Compressed ROMFS" */
+ struct cramfs_info fsid;/* unique filesystem info */
+ u8 name[16];/* user-defined name */
+ struct cramfs_inode root; /* Root inode data */
+};
+
+/*
+ * Feature flags
+ *
+ * 0x - 0x00ff: features that work for all past kernels
+ * 0x0100 - 0x: features that don't work for past kernels
+ */
+#define CRAMFS_FLAG_FSID_VERSION_2 0x0001 /* fsid version #2 */
+#define CRAMFS_FLAG_SORTED_DIRS0x0002 /* sorted dirs */
+#define CRAMFS_FLAG_HOLES 0x0100 /* support for holes */
+#define CRAMFS_FLAG_WRONG_SIGNATURE0x0200 /* reserved */
+#define CRAMFS_FLAG_SHIFTED_ROOT_OFFSET0x0400 /* shifted root fs */
+
+/*
+ * Valid values in super.flags. Currently we refuse to mount
+ * if (flags & ~CRAMFS_SUPPORTED_FLAGS). Maybe that should be
+ * changed to test super.future instead.
+ */
+#define CRAMFS_SUPPORTED_FLAGS (0x7ff)
+
+/* Uncompression interfaces to the underlying zlib */
+int cramfs_uncompress_block(void *dst, int dstlen, void *src, int srclen);
+int cramfs_uncompress_init(void);
+int cramfs_uncompress_exit(void);
+
+#endif
diff -urN linux-2.4.0-orig/include/linux/cramfs_fs_sb.h
linux/include/linux/cramfs_fs_sb.h
--- linux-2.4.0-orig/include/linux/cramfs_fs_sb.h Wed Dec 31 16:00:00 1969
+++ linux/include/linux/cramfs_fs_sb.h Sat Jan 13 18:50:47 2001
@@ -0,0 +1,15 @@
+#ifndef _CRAMFS_FS_SB
+#define _CRAMFS_FS_SB
+
+/*
+ * cramfs super-block data in memory
+ */
+struct cramfs_sb_info {
+ unsigned long magic;
+ unsigned long size;
+ unsigned long blocks;
+ unsigned long files;
+ unsigned long flags;
+};
+
+#endif
diff -urN linux-2.4.0-orig/include/linux/fs.h linux/include/linux/fs.h
--- linux-2.4.0-orig/include/linux/fs.h Thu Jan 4 14:50:47 2001
+++ linux/include/linux/fs.hSat Jan 13 19:36:52 2001
@@ -658,6 +658,7 @@
#include
#include
#include
+#include
extern struct list_head super_blocks;
@@ -706,6 +707,7 @@
struct udf_sb_info udf_sb;
struct ncp_sb_info ncpfs_sb;
struct usbdev_sb_info usbdevfs_sb;
+ struct cramfs_sb_info cramfs_sb;
void*generic_sbp;
} u;
/*
diff -urN linux-2.4.0-orig/scripts/cramfs/GNUmakefile linux/scripts/cramfs/GNUmakefile
--- linux-2.4.0-orig/scripts/cramfs/GNUmakefile Tue Jan 11 10:24:58 2000
+++ linux/scripts/cramfs/GNUmakefileSat Jan 13 18:50:47 2001
@@ -1,7 +1,8 @@
-CFLAGS = -Wall -O2
-CPPFLAGS = -I../../fs/cramfs
+CC = gcc
+CFLAGS = -W -Wall -O2 -g
+CPPFLAGS = -I../../include
LDLIBS = -lz
-PROGS = mkcramfs
+PROGS = mkcramfs cramfsck
all: $(PROGS)
diff -urN linux-2.4.0-orig/scripts/cramfs/cramfsck.c linux/scripts/cramfs/cramfsck.c
--- linux-2.4.0-orig/scripts/cramfs/cramfsck.c Wed Dec 31 16:00:00 1969
+++ linux/scripts/cramfs/cramfsck.c Sat Jan 13 20:39:35 2001
@@ -0,0 +1,588 @@
+/*
+ * cramfsck - check a cramfs file system
+ *
+ * Copyright (C) 2000 Transmeta Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * 1999/12/03: Linus Torvalds (cramfs tester and unarchive program)
+ * 2000/06/03: Daniel Quinlan (CRC and length checking program)
+ * 2000/06/04: Danie
cramfs filesystem patch for 2.4.0
ME). For non-empty directories it is the offset
+ (divided by 4) of the inode of the first file in that
+ directory. For anything else, offset is zero. */
+ u32 namelen:CRAMFS_NAMELEN_WIDTH, offset:CRAMFS_OFFSET_WIDTH;
+};
+
+struct cramfs_info {
+ u32 crc;
+ u32 edition;
+ u32 blocks;
+ u32 files;
+};
+
+/*
+ * Superblock information at the beginning of the FS.
+ */
+struct cramfs_super {
+ u32 magic; /* 0x28cd3d45 - random number */
+ u32 size; /* length in bytes */
+ u32 flags; /* 0 */
+ u32 future; /* 0 */
+ u8 signature[16]; /* "Compressed ROMFS" */
+ struct cramfs_info fsid;/* unique filesystem info */
+ u8 name[16];/* user-defined name */
+ struct cramfs_inode root; /* Root inode data */
+};
+
+/*
+ * Feature flags
+ *
+ * 0x - 0x00ff: features that work for all past kernels
+ * 0x0100 - 0x: features that don't work for past kernels
+ */
+#define CRAMFS_FLAG_FSID_VERSION_2 0x0001 /* fsid version #2 */
+#define CRAMFS_FLAG_SORTED_DIRS0x0002 /* sorted dirs */
+#define CRAMFS_FLAG_HOLES 0x0100 /* support for holes */
+#define CRAMFS_FLAG_WRONG_SIGNATURE0x0200 /* reserved */
+#define CRAMFS_FLAG_SHIFTED_ROOT_OFFSET0x0400 /* shifted root fs */
+
+/*
+ * Valid values in super.flags. Currently we refuse to mount
+ * if (flags ~CRAMFS_SUPPORTED_FLAGS). Maybe that should be
+ * changed to test super.future instead.
+ */
+#define CRAMFS_SUPPORTED_FLAGS (0x7ff)
+
+/* Uncompression interfaces to the underlying zlib */
+int cramfs_uncompress_block(void *dst, int dstlen, void *src, int srclen);
+int cramfs_uncompress_init(void);
+int cramfs_uncompress_exit(void);
+
+#endif
diff -urN linux-2.4.0-orig/include/linux/cramfs_fs_sb.h
linux/include/linux/cramfs_fs_sb.h
--- linux-2.4.0-orig/include/linux/cramfs_fs_sb.h Wed Dec 31 16:00:00 1969
+++ linux/include/linux/cramfs_fs_sb.h Sat Jan 13 18:50:47 2001
@@ -0,0 +1,15 @@
+#ifndef _CRAMFS_FS_SB
+#define _CRAMFS_FS_SB
+
+/*
+ * cramfs super-block data in memory
+ */
+struct cramfs_sb_info {
+ unsigned long magic;
+ unsigned long size;
+ unsigned long blocks;
+ unsigned long files;
+ unsigned long flags;
+};
+
+#endif
diff -urN linux-2.4.0-orig/include/linux/fs.h linux/include/linux/fs.h
--- linux-2.4.0-orig/include/linux/fs.h Thu Jan 4 14:50:47 2001
+++ linux/include/linux/fs.hSat Jan 13 19:36:52 2001
@@ -658,6 +658,7 @@
#include linux/udf_fs_sb.h
#include linux/ncp_fs_sb.h
#include linux/usbdev_fs_sb.h
+#include linux/cramfs_fs_sb.h
extern struct list_head super_blocks;
@@ -706,6 +707,7 @@
struct udf_sb_info udf_sb;
struct ncp_sb_info ncpfs_sb;
struct usbdev_sb_info usbdevfs_sb;
+ struct cramfs_sb_info cramfs_sb;
void*generic_sbp;
} u;
/*
diff -urN linux-2.4.0-orig/scripts/cramfs/GNUmakefile linux/scripts/cramfs/GNUmakefile
--- linux-2.4.0-orig/scripts/cramfs/GNUmakefile Tue Jan 11 10:24:58 2000
+++ linux/scripts/cramfs/GNUmakefileSat Jan 13 18:50:47 2001
@@ -1,7 +1,8 @@
-CFLAGS = -Wall -O2
-CPPFLAGS = -I../../fs/cramfs
+CC = gcc
+CFLAGS = -W -Wall -O2 -g
+CPPFLAGS = -I../../include
LDLIBS = -lz
-PROGS = mkcramfs
+PROGS = mkcramfs cramfsck
all: $(PROGS)
diff -urN linux-2.4.0-orig/scripts/cramfs/cramfsck.c linux/scripts/cramfs/cramfsck.c
--- linux-2.4.0-orig/scripts/cramfs/cramfsck.c Wed Dec 31 16:00:00 1969
+++ linux/scripts/cramfs/cramfsck.c Sat Jan 13 20:39:35 2001
@@ -0,0 +1,588 @@
+/*
+ * cramfsck - check a cramfs file system
+ *
+ * Copyright (C) 2000 Transmeta Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * 1999/12/03: Linus Torvalds (cramfs tester and unarchive program)
+ * 2000/06/03: Daniel Quinlan (CRC and length checking program)
+ * 2000/06/04: Daniel Quinlan (merged programs, added options, support
+ *for special files, preserve permissions and
+ *
cramfs filesystem patch
goto out;
+ }
}
+
+ /* get feature flags first */
if (super.flags & ~CRAMFS_SUPPORTED_FLAGS) {
- printk("unsupported filesystem features\n");
+ printk(KERN_ERR "cramfs: unsupported filesystem features\n");
goto out;
}
/* Check that the root inode is in a sane state */
if (!S_ISDIR(super.root.mode)) {
- printk("root is not a directory\n");
+ printk(KERN_ERR "cramfs: root is not a directory\n");
goto out;
}
root_offset = super.root.offset << 2;
+ if (super.flags & CRAMFS_FLAG_FSID_VERSION_2) {
+ sb->CRAMFS_SIZE=super.size;
+ sb->CRAMFS_BLOCKS=super.fsid.blocks;
+ sb->CRAMFS_FILES=super.fsid.files;
+ } else {
+ sb->CRAMFS_SIZE=1<<28;
+ sb->CRAMFS_BLOCKS=0;
+ sb->CRAMFS_FILES=0;
+ }
+ sb->CRAMFS_FLAGS=super.flags;
if (root_offset == 0)
- printk(KERN_INFO "cramfs: note: empty filesystem");
- else if (root_offset != sizeof(struct cramfs_super)) {
- printk("bad root offset %lu\n", root_offset);
+ printk(KERN_INFO "cramfs: empty filesystem");
+ else if (!(super.flags & CRAMFS_FLAG_SHIFTED_ROOT_OFFSET) &&
+((root_offset != sizeof(struct cramfs_super)) &&
+ (root_offset != 512 + sizeof(struct cramfs_super
+ {
+ printk(KERN_ERR "cramfs: bad root offset %lu\n", root_offset);
goto out;
}
/* Set it all up.. */
- sb->s_op= _ops;
+ sb->s_op = _ops;
sb->s_root = d_alloc_root(get_cramfs_inode(sb, ));
retval = sb;
@@ -209,8 +261,10 @@
{
buf->f_type = CRAMFS_MAGIC;
buf->f_bsize = PAGE_CACHE_SIZE;
+ buf->f_blocks = sb->CRAMFS_BLOCKS;
buf->f_bfree = 0;
buf->f_bavail = 0;
+ buf->f_files = sb->CRAMFS_FILES;
buf->f_ffree = 0;
buf->f_namelen = 255;
return 0;
@@ -275,14 +329,20 @@
static struct dentry * cramfs_lookup(struct inode *dir, struct dentry *dentry)
{
unsigned int offset = 0;
+ int sorted = dir->i_sb->CRAMFS_FLAGS & CRAMFS_FLAG_SORTED_DIRS;
while (offset < dir->i_size) {
struct cramfs_inode *de;
char *name;
- int namelen;
+ int namelen, retval;
de = cramfs_read(dir->i_sb, OFFSET(dir) + offset, sizeof(*de)+256);
name = (char *)(de+1);
+
+ /* Try to take advantage of sorted directories */
+ if (sorted && (dentry->d_name.name[0] < name[0]))
+ break;
+
namelen = de->namelen << 2;
offset += sizeof(*de) + namelen;
@@ -299,10 +359,16 @@
}
if (namelen != dentry->d_name.len)
continue;
- if (memcmp(dentry->d_name.name, name, namelen))
+ retval = memcmp(dentry->d_name.name, name, namelen);
+ if (retval > 0)
continue;
- d_add(dentry, get_cramfs_inode(dir->i_sb, de));
- return NULL;
+ if (!retval) {
+ d_add(dentry, get_cramfs_inode(dir->i_sb, de));
+ return NULL;
+ }
+ /* else (retval < 0) */
+ if (sorted)
+ break;
}
d_add(dentry, NULL);
return NULL;
--- linux-2.4.0-test10.orig/scripts/cramfs/GNUmakefile Tue Jan 11 10:24:58 2000
+++ linux-2.4.0-test10/scripts/cramfs/GNUmakefile Wed Dec 6 19:12:12 2000
@@ -1,7 +1,7 @@
-CFLAGS = -Wall -O2
+CFLAGS = -Wall -O2 -g
CPPFLAGS = -I../../fs/cramfs
LDLIBS = -lz
-PROGS = mkcramfs
+PROGS = mkcramfs cramfsck
all: $(PROGS)
--- /dev/null Tue May 5 13:32:27 1998
+++ linux-2.4.0-test10/scripts/cramfs/cramfsck.cWed Dec 6 19:12:12 2000
@@ -0,0 +1,595 @@
+/*
+ * cramfsck - check a cramfs file system
+ *
+ * Copyright (C) 2000 Transmeta Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Publi
cramfs filesystem patch
st */
if (super.flags ~CRAMFS_SUPPORTED_FLAGS) {
- printk("unsupported filesystem features\n");
+ printk(KERN_ERR "cramfs: unsupported filesystem features\n");
goto out;
}
/* Check that the root inode is in a sane state */
if (!S_ISDIR(super.root.mode)) {
- printk("root is not a directory\n");
+ printk(KERN_ERR "cramfs: root is not a directory\n");
goto out;
}
root_offset = super.root.offset 2;
+ if (super.flags CRAMFS_FLAG_FSID_VERSION_2) {
+ sb-CRAMFS_SIZE=super.size;
+ sb-CRAMFS_BLOCKS=super.fsid.blocks;
+ sb-CRAMFS_FILES=super.fsid.files;
+ } else {
+ sb-CRAMFS_SIZE=128;
+ sb-CRAMFS_BLOCKS=0;
+ sb-CRAMFS_FILES=0;
+ }
+ sb-CRAMFS_FLAGS=super.flags;
if (root_offset == 0)
- printk(KERN_INFO "cramfs: note: empty filesystem");
- else if (root_offset != sizeof(struct cramfs_super)) {
- printk("bad root offset %lu\n", root_offset);
+ printk(KERN_INFO "cramfs: empty filesystem");
+ else if (!(super.flags CRAMFS_FLAG_SHIFTED_ROOT_OFFSET)
+((root_offset != sizeof(struct cramfs_super))
+ (root_offset != 512 + sizeof(struct cramfs_super
+ {
+ printk(KERN_ERR "cramfs: bad root offset %lu\n", root_offset);
goto out;
}
/* Set it all up.. */
- sb-s_op= cramfs_ops;
+ sb-s_op = cramfs_ops;
sb-s_root = d_alloc_root(get_cramfs_inode(sb, super.root));
retval = sb;
@@ -209,8 +261,10 @@
{
buf-f_type = CRAMFS_MAGIC;
buf-f_bsize = PAGE_CACHE_SIZE;
+ buf-f_blocks = sb-CRAMFS_BLOCKS;
buf-f_bfree = 0;
buf-f_bavail = 0;
+ buf-f_files = sb-CRAMFS_FILES;
buf-f_ffree = 0;
buf-f_namelen = 255;
return 0;
@@ -275,14 +329,20 @@
static struct dentry * cramfs_lookup(struct inode *dir, struct dentry *dentry)
{
unsigned int offset = 0;
+ int sorted = dir-i_sb-CRAMFS_FLAGS CRAMFS_FLAG_SORTED_DIRS;
while (offset dir-i_size) {
struct cramfs_inode *de;
char *name;
- int namelen;
+ int namelen, retval;
de = cramfs_read(dir-i_sb, OFFSET(dir) + offset, sizeof(*de)+256);
name = (char *)(de+1);
+
+ /* Try to take advantage of sorted directories */
+ if (sorted (dentry-d_name.name[0] name[0]))
+ break;
+
namelen = de-namelen 2;
offset += sizeof(*de) + namelen;
@@ -299,10 +359,16 @@
}
if (namelen != dentry-d_name.len)
continue;
- if (memcmp(dentry-d_name.name, name, namelen))
+ retval = memcmp(dentry-d_name.name, name, namelen);
+ if (retval 0)
continue;
- d_add(dentry, get_cramfs_inode(dir-i_sb, de));
- return NULL;
+ if (!retval) {
+ d_add(dentry, get_cramfs_inode(dir-i_sb, de));
+ return NULL;
+ }
+ /* else (retval 0) */
+ if (sorted)
+ break;
}
d_add(dentry, NULL);
return NULL;
--- linux-2.4.0-test10.orig/scripts/cramfs/GNUmakefile Tue Jan 11 10:24:58 2000
+++ linux-2.4.0-test10/scripts/cramfs/GNUmakefile Wed Dec 6 19:12:12 2000
@@ -1,7 +1,7 @@
-CFLAGS = -Wall -O2
+CFLAGS = -Wall -O2 -g
CPPFLAGS = -I../../fs/cramfs
LDLIBS = -lz
-PROGS = mkcramfs
+PROGS = mkcramfs cramfsck
all: $(PROGS)
--- /dev/null Tue May 5 13:32:27 1998
+++ linux-2.4.0-test10/scripts/cramfs/cramfsck.cWed Dec 6 19:12:12 2000
@@ -0,0 +1,595 @@
+/*
+ * cramfsck - check a cramfs file system
+ *
+ * Copyright (C) 2000 Transmeta Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * 1999/12/03: Linus Torvalds (cramfs tester and unarchive program)
+ * 2000/06/03: Daniel Quinlan (CRC and length
Re: Proposal: Linux Kernel Patch Management System
David S. Miller writes: > Ok, so lets be clear. > > Who is this facility really meant for? Linus (to decrease his > workload), Ted (to assist him in keeping the todo/bug lists uptodate), > or developers (who cares :-)? > > From the description, my take was that this thing is meant to help all > three entities. How exactly does a system to tracking patches and bugs/fixes (not to mention helping Linus and Ted) not help developers? In other words, it is meant to help all three entities. Anyway, I understand your request, but it's not my call. Obviously, it's better if patches successfully apply to the live tree the first time, but aside from that, it doesn't have much effect on the mechanics of the patch management system. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
David S. Miller writes: > [...] I don't want to sift through a log file on some web site > etc. to find out what he's applied. The log file is primarily for Ted (eventually a more automated bug/TODO system). > Very simply, (drumroll please) I want to run diff. :-) I think this is an orthogonal problem. Realtime diffs are good for developers, not as useful for someone trying to track bug reports and see what has been applied, from whom, descriptions, etc. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
Alexander Viro writes: > Sigh... You know, some stuff is security-sensitive. Dunno about > other folks, but in such situations I prefer to send the patches OOB > to relevant maintainers. And they often go through several rewrites > before they go into the tree. Having descriptions of _all_ pending > patches in publicly accessible place may become an interesting > problem. We could add a "security" or "private" flag that would do the right thing. I haven't asked Linus about how he wants security-sensitive stuff handled (OOB or with the kernel-patch system but not public). In terms of rewrites, that's why there is an "obsoletes" tag. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Proposal: Linux Kernel Patch Management System
Here is a proposal to improve the kernel development process. It was co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and myself. We are posting the proposal here for public review and comment. Seb is the guy writing on the software; he's nearly done the initial version. Description of the problem: 1. There is no system that archives and tracks Linux kernel patches. 2. There isn't a good way of marking that a particular patch is believed to address a particular problem on the TODO list. (Patches should be tied to the TODO items.) 3. There is no archival system and no easy way to determine which patches have made it into the kernel. Proposal: 1. Developers submit all Linux kernel patches to [EMAIL PROTECTED] (not in place yet, so don't start sending patches). 2. Each patch will conform to a standardized, but simple, text format, which looks something like this (exact details to be determined): --- To: [EMAIL PROTECTED] Subject: this is a short description of the patch : : --- Required tags: "Version" - the base kernel version. For example, "2.4.0-test8-pre1". The web page will list valid version strings. "Description" - a detailed description of the patch. Optional tags: "Fixes" - followed by one or more bug numbers (tracked by tytso for now). For example, "T0001" might be tytso bug number 0001. "Obsoletes" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Requires" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Cc" - followed by one or more email addresses to be carbon-copied on success. "Flags" - followed by one or more supported flags. For example, "experimental" (that is, don't submit anything to Linus). The tags are basically in RFC 822 format, but are placed in the body of the email. (Additional lines are preceeded by whitespace, tags are followed by a colon, etc.) Linus wants the body of patches to be in text format and not MIME-encoded or uuencoded. 3. A robot will process all patches for correctness (mostly, does it apply?) with the possibility of additional tests later such as compilation tests, regression tests, etc. 4. If the robot likes the patch, it will create a unique identifier (i.e. "KP7562") and prepend a log entry to the body of the patch: --- linux/Documentation/patch-log Tue Aug 29 17:24:37 2000 +++ linux/Documentation/patch-log Tue Aug 29 17:24:44 2000 @@ -1 +1,3 @@ +Applied patch KP7562 (2000/08/30) + Synopsis: () + (Yes, this prepend patch will always successfully apply.) Good patches are sent to the linux-kernel mailing list which is also where additional discussion about these patches can take place. All patches (good and bad) will be logged and there will be a web interface to access the patch database. We had some amount of discussion about whether a separate mailing list would be a good idea, but we ruled the idea out because fragmenting the kernel-related discussion would have negative effects on development. If it becomes a problem, we can always separate it later. If the patch is long, the actual body of the patch won't be included in the email to the discussion mailing list, just a URL to the patch. Also, information about each applied patch can be retrieved from the patch web site (using the identifier). 5. If the robot doesn't like the patch, it will send the patch back to the submitter with a failure report. 6. When and if Linus applies an entire patch, the patch-log will be updated with a record of the changes. If Linus applies a partial patch, then he will remove (or edit) the patch-log section of the patch. Notes: - The web site will document version strings that will work with the server. Patches against unsupported versions will probably not work and should be rejected, sent to somewhere else, etc. - This system can be put into place quickly. - Linus should reject most out-of-band patches if this is to work. Future features? - PGP signing of patches - conversion of uuencoded patches to text format for people with broken mailers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
Alexander Viro writes: Sigh... You know, some stuff is security-sensitive. Dunno about other folks, but in such situations I prefer to send the patches OOB to relevant maintainers. And they often go through several rewrites before they go into the tree. Having descriptions of _all_ pending patches in publicly accessible place may become an interesting problem. We could add a "security" or "private" flag that would do the right thing. I haven't asked Linus about how he wants security-sensitive stuff handled (OOB or with the kernel-patch system but not public). In terms of rewrites, that's why there is an "obsoletes" tag. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
David S. Miller writes: [...] I don't want to sift through a log file on some web site etc. to find out what he's applied. The log file is primarily for Ted (eventually a more automated bug/TODO system). Very simply, (drumroll please) I want to run diff. :-) I think this is an orthogonal problem. Realtime diffs are good for developers, not as useful for someone trying to track bug reports and see what has been applied, from whom, descriptions, etc. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
David S. Miller writes: Ok, so lets be clear. Who is this facility really meant for? Linus (to decrease his workload), Ted (to assist him in keeping the todo/bug lists uptodate), or developers (who cares :-)? From the description, my take was that this thing is meant to help all three entities. How exactly does a system to tracking patches and bugs/fixes (not to mention helping Linus and Ted) not help developers? In other words, it is meant to help all three entities. Anyway, I understand your request, but it's not my call. Obviously, it's better if patches successfully apply to the live tree the first time, but aside from that, it doesn't have much effect on the mechanics of the patch management system. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
