* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Kai Germaschewski @ 2002-12-14 23:11 UTC (permalink / raw)
To: Matthew Bell; +Cc: linux-parport, linux-kernel
In-Reply-To: <20021214201220.31330.qmail@operamail.com>
On Sun, 15 Dec 2002, Matthew Bell wrote:
> This is valid for at least 2.4.20 and earlier; it works for me, and I
> can't see any exceptional reason why it shouldn't work when ISAPNP is a
> module.
> --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> @@ -370,7 +370,7 @@
> { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> };
>
> -#ifdef CONFIG_ISAPNP
> +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
[...]
It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
you'll get link errors. The real fix for this is to do
+#ifdef __ISAPNP__
which will get all cases right.
--Kai
^ permalink raw reply
* Re: Creating degraded more arrays with mdadm?
From: Derek Vadala @ 2002-12-14 22:48 UTC (permalink / raw)
To: Ross Vandegrift; +Cc: linux-raid
In-Reply-To: <20021214222719.GA22527@willow.seitz.com>
On Sat, 14 Dec 2002, Ross Vandegrift wrote:
> I'm trying to convert to using mdadm for everything, but I
> couldn't really figure out how to do this. I thought I figured it out
> with
>
> # mdadm --create /dev/md0 --level=1 --raid-disks=1 /dev/hde2
> ... copy data
> # mdadm --add /dev/md0 /dev/hdg2
>
Use the missing keyword in place of the device name:
# mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/hde2 missing
That should leave you with a 2-disk mirror with only /dev/hde2 as a
member.
--
Derek Vadala, derek@cynicism.com, http://www.cynicism.com/~derek
^ permalink raw reply
* Re: 2.4.20-ac1 KT400 AGP support
From: Nicolas Mailhot @ 2002-12-14 22:55 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
>Dave Jones wrote :
>On Fri, Dec 13, 2002 at 07:57:59PM -0600, Courtney Grimland wrote:
> > You should be able to set AGP to 4x or 2x in the BIOS.
> Aparently some KT400 BIOS's got clever, and took away the option.
> They switch to AGP 3.0 if an AGP 3.0 card is present, and drop
> back to 2.0 if a 2.0 card is present.
Well they didn't get as far as removing the option but secreted it
in a bios setup screen that can only be accessed via a magic key
sequence (which can be found after some serious googling).
Real nice for a normal user when it works (and so far I didn't heard
from anyone their agp recognition was broken). In fact I spend quite
a long time searching why my system just-worked when people started
reporting KT400 problems.
I'd be really surprised if my board (GA-7VAX) did this and the
GA-7VAXP didn't.
Regards,
--
Nicolas Mailhot
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* freemaps
From: Frederic Rossi (LMC) @ 2002-12-14 22:47 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar; +Cc: linux-mm
[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]
Hi,
This patch is intended to provide better support for allocations done with
mmap. As mentioned by Ingo Molnar, keeping the last hole doesn't save us
from scanning vmas because of size constraint.
The following patch implements a simple scheme. The goal is to quickly
return virtual addresses but without scanning the address space at all. It
also works for fixed mappings by reserving areas of virtual addresses.
A global (per mm) cache is maintained from which we can peek ranges of
addresses. There is no link towards vmas. When addresses are cached out they
are simply forgotten. It is then up to the vma users to explicitly cache
out/back areas.
Two of the main functions used for allocations are:
vma_cache_detach(len) returns the first available range of this length
starting from the first block in the cache. The overhead is still very low
since only the cache is scanned (using a first-fit scheme).
vma_cache_area(addr, len) is used to reserve an area from addr to addr+len.
This gives also the possibility to reserve in advance a bunch of virtual
addresses without explicitly mapping them.
Caches are also accessible from /proc/<pid>/freemaps showing free areas
along with their length. Applications willing to map to fixed addresses can
check what is available before doing a mmap().
I guess it could probably give more control on the fragmentation of the
virtual address space too. I successfully ran this patch in a desktop
environment. I also did some simple testing to see how get_unmapped_area()
reacts. Running the kernel 2.5.50 I get
100000 mmaps, mmap=2545 msec munmap=59 msec
100000 mmaps, mmap=2545 msec munmap=58 msec
100000 mmaps, mmap=2544 msec munmap=60 msec
100000 mmaps, mmap=2547 msec munmap=60 msec
and with freemaps I get
100000 mmaps, mmap=79 msec munmap=60 msec
100000 mmaps, mmap=79 msec munmap=60 msec
100000 mmaps, mmap=80 msec munmap=60 msec
100000 mmaps, mmap=79 msec munmap=60 msec
Since there is quite an amazing difference I really would like to have your
comments on this.
I joined a patch against 2.5.50.
Regards,
Frederic
[-- Attachment #2: freemaps-2.5.50-p4.patch --]
[-- Type: application/octet-stream, Size: 24750 bytes --]
diff --exclude=RCS -BbNur linux-2.5.50/fs/binfmt_aout.c linux-2.5.50~/fs/binfmt_aout.c
--- linux-2.5.50/fs/binfmt_aout.c Wed Nov 27 17:35:51 2002
+++ linux-2.5.50~/fs/binfmt_aout.c Thu Dec 12 14:51:05 2002
@@ -24,6 +24,7 @@
#include <linux/binfmts.h>
#include <linux/personality.h>
#include <linux/init.h>
+#include <linux/vma_cache.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -307,7 +308,8 @@
(current->mm->start_data = N_DATADDR(ex));
current->mm->brk = ex.a_bss +
(current->mm->start_brk = N_BSSADDR(ex));
- current->mm->free_area_cache = TASK_UNMAPPED_BASE;
+
+ vma_cache_init (current->mm);
current->mm->rss = 0;
current->mm->mmap = NULL;
diff --exclude=RCS -BbNur linux-2.5.50/fs/binfmt_elf.c linux-2.5.50~/fs/binfmt_elf.c
--- linux-2.5.50/fs/binfmt_elf.c Wed Nov 27 17:35:59 2002
+++ linux-2.5.50~/fs/binfmt_elf.c Thu Dec 12 14:51:05 2002
@@ -35,6 +35,7 @@
#include <linux/compiler.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
+#include <linux/vma_cache.h>
#include <asm/uaccess.h>
#include <asm/param.h>
@@ -617,7 +618,9 @@
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
current->mm->rss = 0;
- current->mm->free_area_cache = TASK_UNMAPPED_BASE;
+
+ vma_cache_init (current->mm);
+
retval = setup_arg_pages(bprm);
if (retval < 0) {
send_sig(SIGKILL, current, 0);
diff --exclude=RCS -BbNur linux-2.5.50/fs/proc/array.c linux-2.5.50~/fs/proc/array.c
--- linux-2.5.50/fs/proc/array.c Wed Nov 27 17:36:05 2002
+++ linux-2.5.50~/fs/proc/array.c Thu Dec 12 14:51:05 2002
@@ -73,6 +73,7 @@
#include <linux/highmem.h>
#include <linux/file.h>
#include <linux/times.h>
+#include <linux/vma_cache.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
@@ -513,6 +514,99 @@
return len;
}
+ssize_t proc_pid_read_vmc (struct task_struct *task, struct file * file, char * buf, size_t count, loff_t *ppos)
+{
+ struct mm_struct *mm;
+ struct vm_area_struct * map;
+ char *tmp, *kbuf;
+ long retval;
+ int off, lineno, loff;
+ struct list_head *h;
+
+ /* reject calls with out of range parameters immediately */
+ retval = 0;
+ if (*ppos > LONG_MAX)
+ goto out;
+ if (count == 0)
+ goto out;
+ off = (long)*ppos;
+ /*
+ * We might sleep getting the page, so get it first.
+ */
+ retval = -ENOMEM;
+ kbuf = (char*)__get_free_page(GFP_KERNEL);
+ if (!kbuf)
+ goto out;
+
+ tmp = (char*)__get_free_page(GFP_KERNEL);
+ if (!tmp)
+ goto out_free1;
+
+ task_lock(task);
+ mm = task->mm;
+ if (mm)
+ atomic_inc(&mm->mm_users);
+ task_unlock(task);
+ retval = 0;
+ if (!mm)
+ goto out_free2;
+
+ down_read(&mm->mmap_sem);
+ map = mm->mmap;
+ lineno = 0;
+ loff = 0;
+ if (count > PAGE_SIZE)
+ count = PAGE_SIZE;
+
+ list_for_each (h, &mm->vma_cache_head) {
+ struct vma_cache_struct *vmc = list_entry (h, struct vma_cache_struct, head);
+
+ int len;
+ if (off > PAGE_SIZE) {
+ off -= PAGE_SIZE;
+ goto next;
+ }
+
+ len = sprintf (tmp, "%lx-%lx %lu\n", vmc->vm_start, vmc->vm_end, vmc->vm_end-vmc->vm_start);
+ len -= off;
+ if (len > 0) {
+ if (retval+len > count) {
+ /* only partial line transfer possible */
+ len = count - retval;
+ /* save the offset where the next read
+ * must start */
+ loff = len+off;
+ }
+ memcpy(kbuf+retval, tmp+off, len);
+ retval += len;
+ }
+ off = 0;
+next:
+ if (!loff)
+ lineno++;
+ if (retval >= count)
+ break;
+ if (loff) BUG();
+ map = map->vm_next;
+ }
+
+ up_read(&mm->mmap_sem);
+ mmput(mm);
+
+ if (retval > count) BUG();
+ if (copy_to_user(buf, kbuf, retval))
+ retval = -EFAULT;
+ else
+ *ppos = (lineno << PAGE_SHIFT) + loff;
+
+out_free2:
+ free_page((unsigned long)tmp);
+out_free1:
+ free_page((unsigned long)kbuf);
+out:
+ return retval;
+}
+
ssize_t proc_pid_read_maps (struct task_struct *task, struct file * file, char * buf,
size_t count, loff_t *ppos)
{
diff --exclude=RCS -BbNur linux-2.5.50/fs/proc/base.c linux-2.5.50~/fs/proc/base.c
--- linux-2.5.50/fs/proc/base.c Wed Nov 27 17:36:06 2002
+++ linux-2.5.50~/fs/proc/base.c Thu Dec 12 14:51:05 2002
@@ -54,6 +54,7 @@
PROC_PID_CMDLINE,
PROC_PID_STAT,
PROC_PID_STATM,
+ PROC_PID_VMC,
PROC_PID_MAPS,
PROC_PID_MOUNTS,
PROC_PID_WCHAN,
@@ -75,6 +76,7 @@
E(PROC_PID_CMDLINE, "cmdline", S_IFREG|S_IRUGO),
E(PROC_PID_STAT, "stat", S_IFREG|S_IRUGO),
E(PROC_PID_STATM, "statm", S_IFREG|S_IRUGO),
+ E(PROC_PID_VMC, "freemaps", S_IFREG|S_IRUGO),
E(PROC_PID_MAPS, "maps", S_IFREG|S_IRUGO),
E(PROC_PID_MEM, "mem", S_IFREG|S_IRUSR|S_IWUSR),
E(PROC_PID_CWD, "cwd", S_IFLNK|S_IRWXUGO),
@@ -99,6 +101,7 @@
}
ssize_t proc_pid_read_maps(struct task_struct*,struct file*,char*,size_t,loff_t*);
+ssize_t proc_pid_read_vmc(struct task_struct*,struct file*,char*,size_t,loff_t*);
int proc_pid_stat(struct task_struct*,char*);
int proc_pid_status(struct task_struct*,char*);
int proc_pid_statm(struct task_struct*,char*);
@@ -336,6 +339,21 @@
.read = pid_maps_read,
};
+static ssize_t pid_vmc_read(struct file * file, char * buf,
+ size_t count, loff_t *ppos)
+{
+ struct inode * inode = file->f_dentry->d_inode;
+ struct task_struct *task = proc_task(inode);
+ ssize_t res;
+
+ res = proc_pid_read_vmc (task, file, buf, count, ppos);
+ return res;
+}
+
+static struct file_operations proc_vmc_operations = {
+ read: pid_vmc_read,
+};
+
extern struct seq_operations mounts_op;
static int mounts_open(struct inode *inode, struct file *file)
{
@@ -1023,6 +1041,9 @@
inode->i_fop = &proc_info_file_operations;
ei->op.proc_read = proc_pid_statm;
break;
+ case PROC_PID_VMC:
+ inode->i_fop = &proc_vmc_operations;
+ break;
case PROC_PID_MAPS:
inode->i_fop = &proc_maps_operations;
break;
diff --exclude=RCS -BbNur linux-2.5.50/include/linux/init_task.h linux-2.5.50~/include/linux/init_task.h
--- linux-2.5.50/include/linux/init_task.h Wed Nov 27 17:35:49 2002
+++ linux-2.5.50~/include/linux/init_task.h Thu Dec 12 14:51:05 2002
@@ -41,6 +41,7 @@
.page_table_lock = SPIN_LOCK_UNLOCKED, \
.mmlist = LIST_HEAD_INIT(name.mmlist), \
.default_kioctx = INIT_KIOCTX(name.default_kioctx, name), \
+ .vma_cache_head = LIST_HEAD_INIT(name.vma_cache_head), \
}
#define INIT_SIGNALS(sig) { \
diff --exclude=RCS -BbNur linux-2.5.50/include/linux/sched.h linux-2.5.50~/include/linux/sched.h
--- linux-2.5.50/include/linux/sched.h Wed Nov 27 17:35:49 2002
+++ linux-2.5.50~/include/linux/sched.h Thu Dec 12 14:51:05 2002
@@ -172,11 +172,16 @@
#include <linux/aio.h>
+struct vma_cache_struct {
+ struct list_head head;
+ unsigned long vm_start;
+ unsigned long vm_end;
+};
+
struct mm_struct {
struct vm_area_struct * mmap; /* list of VMAs */
struct rb_root mm_rb;
struct vm_area_struct * mmap_cache; /* last find_vma result */
- unsigned long free_area_cache; /* first hole */
pgd_t * pgd;
atomic_t mm_users; /* How many users with user space? */
atomic_t mm_count; /* How many references to "struct mm_struct" (users count as 1) */
@@ -189,6 +194,8 @@
* by mmlist_lock
*/
+ struct list_head vma_cache_head; /* cache for free virtual address areas */
+
unsigned long start_code, end_code, start_data, end_data;
unsigned long start_brk, brk, start_stack;
unsigned long arg_start, arg_end, env_start, env_end;
diff --exclude=RCS -BbNur linux-2.5.50/include/linux/slab.h linux-2.5.50~/include/linux/slab.h
--- linux-2.5.50/include/linux/slab.h Wed Nov 27 17:36:23 2002
+++ linux-2.5.50~/include/linux/slab.h Thu Dec 12 14:51:05 2002
@@ -65,6 +65,7 @@
extern int FASTCALL(kmem_cache_reap(int));
/* System wide caches */
+extern kmem_cache_t *vma_cache_cachep;
extern kmem_cache_t *vm_area_cachep;
extern kmem_cache_t *mm_cachep;
extern kmem_cache_t *names_cachep;
diff --exclude=RCS -BbNur linux-2.5.50/include/linux/vma_cache.h linux-2.5.50~/include/linux/vma_cache.h
--- linux-2.5.50/include/linux/vma_cache.h Wed Dec 31 19:00:00 1969
+++ linux-2.5.50~/include/linux/vma_cache.h Thu Dec 12 14:51:05 2002
@@ -0,0 +1,25 @@
+#ifndef _VMA_CACHE_H_
+#define _VMA_CACHE_H_
+
+#define VMA_CACHE_EMPTY(m,a) (list_empty(&(a)->head))
+
+#define vma_cache_alloc() (kmem_cache_alloc(vma_cache_cachep, GFP_KERNEL))
+#define vma_cache_free(v) \
+do { \
+ if (v) { \
+ list_del_init (&(v)->head); \
+ kmem_cache_free (vma_cache_cachep, v); \
+ } \
+} while (0)
+
+int vma_cache_init (struct mm_struct *);
+struct vma_cache_struct *vma_cache_find (struct mm_struct *, unsigned long, int);
+void vma_cache_shtdn (struct mm_struct *);
+int vma_cache_attach (struct mm_struct *, unsigned long, int);
+int vma_cache_merge (struct mm_struct *, struct vma_cache_struct *, unsigned long, int);
+int vma_cache_clone (struct mm_struct *, struct mm_struct *);
+unsigned long vma_cache_area (struct mm_struct *, unsigned long, int);
+unsigned long vma_cache_detach (struct mm_struct *, int);
+
+#endif /* #ifndef _VMA_CACHE_H_ */
+
diff --exclude=RCS -BbNur linux-2.5.50/kernel/exit.c linux-2.5.50~/kernel/exit.c
--- linux-2.5.50/kernel/exit.c Wed Nov 27 17:36:18 2002
+++ linux-2.5.50~/kernel/exit.c Thu Dec 12 14:51:05 2002
@@ -21,6 +21,7 @@
#include <linux/ptrace.h>
#include <linux/profile.h>
#include <linux/mount.h>
+#include <linux/vma_cache.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff --exclude=RCS -BbNur linux-2.5.50/kernel/fork.c linux-2.5.50~/kernel/fork.c
--- linux-2.5.50/kernel/fork.c Wed Nov 27 17:35:49 2002
+++ linux-2.5.50~/kernel/fork.c Thu Dec 12 14:51:05 2002
@@ -29,6 +29,7 @@
#include <linux/futex.h>
#include <linux/ptrace.h>
#include <linux/mount.h>
+#include <linux/vma_cache.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -215,10 +216,10 @@
down_write(&oldmm->mmap_sem);
flush_cache_mm(current->mm);
+ vma_cache_init (mm);
mm->locked_vm = 0;
mm->mmap = NULL;
mm->mmap_cache = NULL;
- mm->free_area_cache = TASK_UNMAPPED_BASE;
mm->map_count = 0;
mm->rss = 0;
mm->cpu_vm_mask = 0;
@@ -246,6 +247,7 @@
goto fail_nomem;
charge += len;
}
+ vma_cache_area (mm, mpnt->vm_start, mpnt->vm_end-mpnt->vm_start);
tmp = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
if (!tmp)
goto fail_nomem;
@@ -334,7 +336,7 @@
mm->page_table_lock = SPIN_LOCK_UNLOCKED;
mm->ioctx_list_lock = RW_LOCK_UNLOCKED;
mm->default_kioctx = (struct kioctx)INIT_KIOCTX(mm->default_kioctx, *mm);
- mm->free_area_cache = TASK_UNMAPPED_BASE;
+ vma_cache_init (mm);
if (likely(!mm_alloc_pgd(mm)))
return mm;
@@ -381,6 +383,7 @@
mmlist_nr--;
spin_unlock(&mmlist_lock);
exit_mmap(mm);
+ vma_cache_shtdn(mm);
mmdrop(mm);
}
}
@@ -1054,6 +1057,9 @@
/* SLAB cache for mm_struct structures (tsk->mm) */
kmem_cache_t *mm_cachep;
+/* SLAB cache for vma_cache structures */
+kmem_cache_t *vma_cache_cachep;
+
void __init proc_caches_init(void)
{
sigact_cachep = kmem_cache_create("signal_act",
@@ -1085,4 +1091,11 @@
SLAB_HWCACHE_ALIGN, NULL, NULL);
if(!mm_cachep)
panic("vma_init: Cannot alloc mm_struct SLAB cache");
+
+ vma_cache_cachep = kmem_cache_create("vma_cache_struct",
+ sizeof(struct vma_cache_struct), 0,
+ SLAB_HWCACHE_ALIGN, NULL, NULL);
+ if(!vm_area_cachep)
+ panic("vma_init: Cannot alloc vma_cache_struct SLAB cache");
+
}
diff --exclude=RCS -BbNur linux-2.5.50/mm/Makefile linux-2.5.50~/mm/Makefile
--- linux-2.5.50/mm/Makefile Wed Nov 27 17:36:14 2002
+++ linux-2.5.50~/mm/Makefile Thu Dec 12 14:51:05 2002
@@ -8,7 +8,7 @@
vmalloc.o slab.o bootmem.o swap.o vmscan.o page_alloc.o \
oom_kill.o shmem.o highmem.o mempool.o msync.o mincore.o \
readahead.o pdflush.o page-writeback.o rmap.o madvise.o \
- vcache.o truncate.o
+ vcache.o truncate.o vma_cache.o
obj-$(CONFIG_SWAP) += page_io.o swap_state.o swapfile.o
diff --exclude=RCS -BbNur linux-2.5.50/mm/mmap.c linux-2.5.50~/mm/mmap.c
--- linux-2.5.50/mm/mmap.c Wed Nov 27 17:36:06 2002
+++ linux-2.5.50~/mm/mmap.c Thu Dec 12 14:51:05 2002
@@ -18,6 +18,7 @@
#include <linux/security.h>
#include <linux/hugetlb.h>
#include <linux/profile.h>
+#include <linux/vma_cache.h>
#include <asm/uaccess.h>
#include <asm/pgalloc.h>
@@ -514,6 +515,7 @@
if (vma && vma->vm_start < addr + len) {
if (do_munmap(mm, addr, len))
return -ENOMEM;
+ vma_cache_area (mm, addr, len);
goto munmap_back;
}
@@ -647,7 +649,6 @@
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- int found_hole = 0;
if (len > TASK_SIZE)
return -ENOMEM;
@@ -657,25 +658,9 @@
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
(!vma || addr + len <= vma->vm_start))
- return addr;
- }
- addr = mm->free_area_cache;
-
- for (vma = find_vma(mm, addr); ; vma = vma->vm_next) {
- /* At this point: (!vma || addr < vma->vm_end). */
- if (TASK_SIZE - len < addr)
- return -ENOMEM;
- /*
- * Record the first available hole.
- */
- if (!found_hole && (!vma || addr < vma->vm_start)) {
- mm->free_area_cache = addr;
- found_hole = 1;
- }
- if (!vma || addr + len <= vma->vm_start)
- return addr;
- addr = vma->vm_end;
+ return vma_cache_area (current->mm, addr, len);
}
+ return vma_cache_detach (current->mm, len);
}
#else
extern unsigned long arch_get_unmapped_area(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
@@ -688,7 +673,7 @@
return -ENOMEM;
if (addr & ~PAGE_MASK)
return -EINVAL;
- return addr;
+ return vma_cache_area (current->mm, addr, len);
}
if (file && file->f_op && file->f_op->get_unmapped_area)
@@ -962,13 +947,8 @@
area->vm_mm->total_vm -= len >> PAGE_SHIFT;
if (area->vm_flags & VM_LOCKED)
area->vm_mm->locked_vm -= len >> PAGE_SHIFT;
- /*
- * Is this a new hole at the lowest possible address?
- */
- if (area->vm_start >= TASK_UNMAPPED_BASE &&
- area->vm_start < area->vm_mm->free_area_cache)
- area->vm_mm->free_area_cache = area->vm_start;
+ vma_cache_attach (mm, area->vm_start, area->vm_end-area->vm_start);
remove_shared_vm_struct(area);
if (area->vm_ops && area->vm_ops->close)
@@ -1336,7 +1316,6 @@
kmem_cache_free(vm_area_cachep, mpnt);
mpnt = next;
}
-
}
/* Insert vm structure into process list sorted by address
diff --exclude=RCS -BbNur linux-2.5.50/mm/vma_cache.c linux-2.5.50~/mm/vma_cache.c
--- linux-2.5.50/mm/vma_cache.c Wed Dec 31 19:00:00 1969
+++ linux-2.5.50~/mm/vma_cache.c Fri Dec 13 08:52:52 2002
@@ -0,0 +1,364 @@
+/*
+ * linux/mm/vma_cache.c
+ *
+ * These routines are used for the allocation of virtual memory areas. Each MM context is
+ * assigned a cache which contains virtual address ranges a process can allocate to map into
+ * its own address space. These routines assume the caller holds the global mm->mmap_sem.
+ * Dec 2002, frederic.rossi@ericsson.ca
+ *
+ */
+
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/errno.h>
+#include <linux/vma_cache.h>
+
+#define next_area(v) (list_entry ((v)->head.next, struct vma_cache_struct, head))
+#define prev_area(v) (list_entry ((v)->head.prev, struct vma_cache_struct, head))
+
+/* not mapped addresses */
+#define unmapped_addr(v,a) ((a)>=(v)->vm_start && (a)<=(v)->vm_end)
+#define unmapped_area(v,a,l) ((a)>=(v)->vm_start && (a)+(l)<=(v)->vm_end)
+#define unmapped_left(v,a,l) ((a)+(l)<(v)->vm_start)
+#define unmapped_right(v,al) ((a)>(v)->vm_end)
+
+/* partially mapped addresses */
+#define pmapped_left(v,a,l) ((a)+(l)==(v)->vm_start)
+#define pmapped_right(v,a,l) ((a)==(v)->vm_end)
+
+static __inline__ int vma_cache_isvalid (struct mm_struct *mm, unsigned long addr, int len)
+{
+ return (addr >= TASK_UNMAPPED_BASE && addr+len <= TASK_SIZE)? 1 : 0;
+}
+
+static __inline__ int vma_cache_chainout (struct mm_struct *mm, struct vma_cache_struct *vmc)
+{
+ if (!vmc)
+ return -EINVAL;
+
+ list_del_init (&vmc->head);
+ vma_cache_free (vmc);
+ return 0;
+}
+
+static __inline__ struct vma_cache_struct *vma_cache_append (struct mm_struct *mm, struct vma_cache_struct *vmc, unsigned long addr, int len)
+{
+ struct vma_cache_struct *new;
+
+ new = vma_cache_alloc ();
+ if (!new)
+ return NULL;
+
+ INIT_LIST_HEAD (&new->head);
+ new->vm_start = addr;
+ new->vm_end = addr+len;
+ list_add (&new->head, &vmc->head);
+
+ return new;
+}
+
+static __inline__ struct vma_cache_struct *vma_cache_insert (struct mm_struct *mm, struct vma_cache_struct *vmc, unsigned long addr, int len)
+{
+ struct vma_cache_struct *new;
+
+ new = vma_cache_alloc ();
+ if (!new)
+ return NULL;
+
+ INIT_LIST_HEAD (&new->head);
+ new->vm_start = addr;
+ new->vm_end = addr+len;
+ list_add_tail (&new->head, &vmc->head);
+
+ return new;
+}
+
+void vma_cache_shtdn (struct mm_struct *mm)
+{
+ struct vma_cache_struct *nptr, *vmc, *head;
+
+ head = list_entry (&mm->vma_cache_head, struct vma_cache_struct, head);
+ vmc = head;
+ nptr = NULL;
+
+ while (nptr != head) {
+ nptr = next_area (vmc);
+ if (vma_cache_attach (mm, vmc->vm_start, vmc->vm_end-vmc->vm_start) == 0)
+ vma_cache_free (vmc);
+ vmc = nptr;
+ }
+}
+
+int vma_cache_clone (struct mm_struct *mm_dst, struct mm_struct *mm_src)
+{
+ struct list_head *tmp, *prev;
+ struct vma_cache_struct *new;
+
+ if (!list_empty (&mm_dst->vma_cache_head)) {
+ /* Remove previous mapping */
+ again:
+ list_for_each (tmp, &mm_dst->vma_cache_head) {
+ struct vma_cache_struct *vmc = list_entry (tmp, struct vma_cache_struct, head);
+ vma_cache_free (vmc);
+ goto again;
+ }
+ INIT_LIST_HEAD (&mm_dst->vma_cache_head);
+ }
+
+ prev = &mm_dst->vma_cache_head;
+ list_for_each (tmp, &mm_src->vma_cache_head) {
+ struct vma_cache_struct *vmc = list_entry (tmp, struct vma_cache_struct, head);
+
+ new = vma_cache_alloc ();
+ if (!new)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD (&new->head);
+ new->vm_start = vmc->vm_start;
+ new->vm_end = vmc->vm_end;
+ list_add (&new->head, prev);
+ prev = &new->head;
+ }
+
+ return 0;
+}
+
+int vma_cache_init (struct mm_struct *mm)
+{
+ struct vma_cache_struct *vmc;
+
+ INIT_LIST_HEAD (&mm->vma_cache_head);
+
+ vmc = vma_cache_alloc ();
+ if (!vmc)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD (&vmc->head);
+ vmc->vm_start = TASK_UNMAPPED_BASE;
+ vmc->vm_end = TASK_SIZE;
+ list_add (&vmc->head, &mm->vma_cache_head);
+
+ return 0;
+}
+
+struct vma_cache_struct *vma_cache_find (struct mm_struct *mm, unsigned long addr, int len)
+{
+ struct list_head *tmp;
+
+ if (!len)
+ return NULL;
+
+ list_for_each (tmp, &mm->vma_cache_head) {
+ struct vma_cache_struct *vmc = list_entry (tmp, struct vma_cache_struct, head);
+ if (unmapped_area (vmc, addr, len))
+ return vmc;
+ }
+
+ return NULL;
+}
+
+/*
+ * Give an address, find the left cache element and merge if mergeable.
+ */
+static struct vma_cache_struct *vma_cache_merge_left (struct mm_struct *mm, struct vma_cache_struct *vmc, unsigned long addr, int len)
+{
+ struct vma_cache_struct *vmc_left = NULL;
+
+ if (!vmc) {
+ vmc = vma_cache_find (mm, addr, len);
+ if (!vmc) goto out;
+ }
+
+ vmc_left = prev_area (vmc);
+
+ if (!vmc_left)
+ goto out;
+
+ if (vmc_left == vmc)
+ goto out;
+
+ /* merge */
+ if (vmc->vm_start <= vmc_left->vm_end && vmc->vm_start >= vmc_left->vm_start){
+ vmc_left->vm_end = vmc->vm_end;
+ vma_cache_chainout (mm, vmc);
+ }
+
+out:
+ return vmc_left;
+}
+
+/*
+ * Give an address, find the right cache element and merge if mergeable.
+ */
+static struct vma_cache_struct *vma_cache_merge_right (struct mm_struct *mm, struct vma_cache_struct *vmc, unsigned long addr, int len)
+{
+ struct vma_cache_struct *vmc_right = NULL;
+
+ if (!vmc) {
+ vmc = vma_cache_find (mm, addr, len);
+ if (!vmc) goto out;
+ }
+
+ vmc_right = next_area (vmc);
+
+ if (!vmc_right)
+ goto out;
+
+ if (vmc_right == vmc)
+ goto out;
+
+ /* merge */
+ if (vmc->vm_end >= vmc_right->vm_start && vmc->vm_end <= vmc_right->vm_end) {
+ vmc_right->vm_start = vmc->vm_start;
+ vma_cache_chainout (mm, vmc);
+ }
+out:
+ return vmc_right;
+}
+
+int vma_cache_merge (struct mm_struct *mm, struct vma_cache_struct *vmc, unsigned long addr, int len)
+{
+ int err=0;
+
+ if (!vmc || vma_cache_find (mm, addr, len) == vmc) {
+ err = (int )vma_cache_merge_left (mm, vmc, addr, len);
+ err |= (int )vma_cache_merge_right (mm, vmc, addr, len);
+ }
+
+ return (err)? -EINVAL : 0;
+}
+
+/*
+ * Insert or increase an existing area. Returns 0 if successfull.
+ */
+int vma_cache_attach (struct mm_struct *mm, unsigned long addr, int len)
+{
+ struct list_head *tmp;
+ struct vma_cache_struct *vmc;
+
+ if (!vma_cache_isvalid (mm, addr, len))
+ return -EINVAL;
+
+ vmc = list_entry (&mm->vma_cache_head, struct vma_cache_struct, head);
+ list_for_each (tmp, &mm->vma_cache_head) {
+ vmc = list_entry (tmp, struct vma_cache_struct, head);
+
+ if (addr > vmc->vm_end)
+ continue;
+
+ if (pmapped_left (vmc, addr, len)) {
+ vmc->vm_start = addr;
+ return vma_cache_merge (mm, vmc, addr, len);
+ }
+
+ if (unmapped_left (vmc, addr, len)) {
+ struct vma_cache_struct *new = vma_cache_insert (mm, vmc, addr, len);
+ if (!new)
+ return -ENOMEM;
+ return vma_cache_merge (mm, new, addr, len);
+ }
+
+ if (pmapped_right (vmc, addr, len)) {
+ vmc->vm_end = addr+len;
+ return vma_cache_merge (mm, vmc, addr, len);
+ }
+
+ if (unmapped_area (vmc, addr, len))
+ return 0;
+
+ if (addr < vmc->vm_start && addr+len > vmc->vm_end) {
+ vmc->vm_start = addr;
+ vmc->vm_end = addr+len;
+ return vma_cache_merge (mm, vmc, addr, len);
+ }
+
+ if (addr == vmc->vm_start && addr+len > vmc->vm_end) {
+ vmc->vm_end = addr+len;
+ return vma_cache_merge (mm, vmc, addr, len);
+ }
+
+ /* shouldn't go here */
+ printk ("vma_cache_area: task '%s' [%d]. Don't know how to attach address range [%lx, %lx] in range [%lx, %lx]\n",
+ current->comm, current->pid, addr, addr+len, vmc->vm_start, vmc->vm_end);
+
+ break;
+ }
+
+ return -EINVAL;
+}
+
+/*
+ * Reserve a range of addresses. An error value is returned only if it's not
+ * possible to reserve this area.
+ */
+unsigned long vma_cache_area (struct mm_struct *mm, unsigned long addr, int len)
+{
+ struct vma_cache_struct *vmc;
+
+ if (!vma_cache_isvalid (mm, addr, len))
+ return addr;
+
+ vmc = vma_cache_find (mm, addr, len);
+ if (!vmc)
+ return addr;
+
+ if (addr == vmc->vm_start && addr+len <= vmc->vm_end) {
+ vmc->vm_start = addr+len;
+ if (vmc->vm_start == vmc->vm_end)
+ vma_cache_chainout (mm, vmc);
+ return addr;
+ }
+
+ if (addr > vmc->vm_start && addr+len == vmc->vm_end) {
+ vmc->vm_end = addr;
+ if (vmc->vm_start == vmc->vm_end)
+ vma_cache_chainout (mm, vmc);
+ return addr;
+ }
+
+ if (addr > vmc->vm_start && addr+len < vmc->vm_end) {
+ unsigned long old_end;
+
+ /* vmc->vm_start -> addr */
+ old_end = vmc->vm_end;
+ vmc->vm_end = addr;
+
+ /* addr+len -> vmc->vm_end */
+ vma_cache_append (mm, vmc, addr+len, old_end-addr-len);
+ return addr;
+ }
+
+ printk ("vma_cache_area: task '%s' [%d]. Don't know how to cache out address range [%lx, %lx] from range [%lx, %lx]\n",
+ current->comm, current->pid, addr, addr+len, vmc->vm_start, vmc->vm_end);
+
+ return -EINVAL;
+}
+
+/*
+ * Find the first available range of addresses. The return value
+ * is to satisfy get_unmapped_area().
+ */
+unsigned long vma_cache_detach (struct mm_struct *mm, int len)
+{
+ struct list_head *tmp;
+ unsigned long addr;
+
+ if (!len)
+ return -EINVAL;
+
+ addr = -ENOMEM;
+
+ list_for_each (tmp, &mm->vma_cache_head) {
+ struct vma_cache_struct *vmc = list_entry (tmp, struct vma_cache_struct, head);
+
+ if (len <= vmc->vm_end - vmc->vm_start) {
+ addr = vmc->vm_start;
+ vmc->vm_start += len;
+ if (vmc->vm_start == vmc->vm_end)
+ vma_cache_chainout (mm, vmc);
+ break;
+ }
+ }
+
+ return addr;
+}
^ permalink raw reply
* Re: Re: kernel: matrox fb - missing files, doesn't compile
From: Petr Vandrovec @ 2002-12-14 22:44 UTC (permalink / raw)
To: Antonino Daplas; +Cc: Ariel, Linux Fbdev development list
In-Reply-To: <1039912121.1008.59.camel@localhost.localdomain>
On Sun, Dec 15, 2002 at 05:30:43AM +0500, Antonino Daplas wrote:
> On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > Current interface just supports only cfb, and only very bad for my needs.
> > And because of matroxfb supports also other modes (such as native text
> > mode, or loading font into accelerator), bye-bye. For now I recommend you
> > either to not upgrade, or use vesafb. Besides that accel_putcs() does not
> > call fb_sync when using font width which is not multiple of 8, and that
> Can you explain why an fb_sync is needed for every character?
It is not needed after every character. But I thought that it will be called
before we return to userspace... And I want to rely on fb_sync
because of hardware setup to change fg_color and bg_color is very costly.
In my tests I'm not able to get accelerated code running faster than
at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
two PCI writes could speed it a bit... It will not get on par, but better than
nothing.
> > with fonts greater than 16*16 pixels (I believe that such fonts are still
> > supported...) it will corrupt memory...
>
> I agree. To be more specific, buffer overruns will occur if (xres *
> fontheight/8 > 8192). The pixmap needs to be dynamically allocated and
> resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> was removed). For those concerned about this problem, you can try this
> patch as a temporary measure until fbcon is fixed. It should not cause
> to much slowdown:
But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
if I remember fork() problems with allocating stack with order=1 correctly,
it is not best idea under the sun. But using physically non-continuous
area is probably even worse idea.
> For anyone concerned, this is a heads up: The data in the pixmap must
> be read completely by the hardware before exiting, otherwise font
> corruption will occur. If you think this will be a problem, the
> function can be easily modified to do multiple buffering instead.
What if I'll decide to paint characters through busmastering? Then
I need font data in buffers allocated by pci_alloc_consistent...
In the past it was not a win to use busmastering, but now, when
upper layers might prepare images much larger than 8x16, it may be
worth of rechecking that...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Reiserfs with Samba vs NetApp Filer (purely performance)
From: Richard Sharpe @ 2002-12-14 22:34 UTC (permalink / raw)
To: Hans Reiser; +Cc: darren, 'Russell Coker', reiserfs-list
In-Reply-To: <3DFBA067.5040601@namesys.com>
On Sun, 15 Dec 2002, Hans Reiser wrote:
> darren wrote:
>
> >Hi all,
> >
> >Thanks for all the very informative bits on this thread.
> >
> >In my usage, I intend to implement this fileserver to complement another
> >server that runs a very intensive small files read/write operation.
> >
> >These files often run into 200,000 or more but are usually in the range
> >of 100kb or less.
> >
> >Hence, space is not a big issue to me, but performance is. (there's no
> >point splitting out the IO from the main server if it runs slower!!).
> >
> >I will be using an spare server to do this job: Dell Xeon 2GHz with 5 x
> >72Gb SCSI hdd (I got on board RAID but have not decided on how to
> >configure yet -help here are welcome too!).
> >
> >My options are: Win2k (NTFS with CIFS), Linux (Reiserfs with Samba) or
> >Netapp 870.
If those are your choices, then I would rank them:
NetApp F870, Linux with ReiserFS and Samba, Win2K
John Terpstra has done some testing with a modified cifs_bm which confirms
that Linux with EXT2/3 or ReiserFS outperforms Win2K on the same hardware.
However, my testing of the NetApp suggests it will outperform the other
two choices.
If you choose to use Samba, you will want to make sure that the sendfile
stuff is implemented. Unfortunately, the directory indexing in Reiser does
not help that much a lot of the time because Samba is forced to do
directory scans because it has to implement case-independent
lookups/searches.
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
^ permalink raw reply
* Re: [linux-lvm] help: can't read name(s) of physical volumes (Debian kernel weirdness also involved)
From: Steven Lembark @ 2002-12-14 22:29 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <Pine.GSO.4.44L-027.0212142036200.10732-100000@unix3.andrew.cmu.edu>
> Here's the situation. I just installed Debian 3.0 testing and I set it up
> so that I was using their lvm10 package (version 1.0.4-6) for /usr, /var
> /home, etc. (NOT /) It works fine off the kernel that Debian uses in its
> install (2.4.18-bf2.4). BUT, if I install a stock Debian kernel with
> apt-get (kernel-image-2.4.18-k7), lvm cannot see my physical volumes at
> boot-time.
Make sure that the stock kernel has LVM installed, then
upgrade to 1.0.6 (via http://www.sistina.com/). Building
a 2.4.10 kernel w/ 1.0.6 (if you want to stick with 1.0)
should give you the best results.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
^ permalink raw reply
* Creating degraded more arrays with mdadm?
From: Ross Vandegrift @ 2002-12-14 22:27 UTC (permalink / raw)
To: linux-raid
Hey everyone,
I started building a new array today to give some failover
capabilities to an aging Maxtor 17G drive and an IBM Deathstar 20G. The
Maxtor had data on it, so I went about my usual routine of creating an
array in with a failed disk.
I'm trying to convert to using mdadm for everything, but I
couldn't really figure out how to do this. I thought I figured it out
with
# mdadm --create /dev/md0 --level=1 --raid-disks=1 /dev/hde2
... copy data
# mdadm --add /dev/md0 /dev/hdg2
But I knew something didn't work as expected when there was no sync
required. I realized only after stopping and restating the array I
created a one disk mirror with one hot spare. Doh!
Given that I have /dev/hde2 with data, and /dev/hdg1 and I want to put
them into an array, how do I use mdadm to make a degraded mode md device
like I used to with raidtools2?
(btw - have I asked this before? I'm having a small case of deja vu,
but google and MARC couldn't corroborate my feeling...)
--
Ross Vandegrift
ross@willow.seitz.com
A Pope has a Water Cannon. It is a Water Cannon.
He fires Holy-Water from it. It is a Holy-Water Cannon.
He Blesses it. It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it. It is a Wholly Holy Holy-Water Cannon.
He has it pierced. It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official. It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive. He shoots them.
^ permalink raw reply
* [U-Boot-Users] PPC 405 _start code - Clarification
From: Jerry Walden @ 2002-12-14 22:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <EGEGIJHKDKJGAJMGIDPNOEHFCCAA.jwalden@digitalatlantic.com>
sorry - I should clarify -
what I expect to see it what I see in /cpu/start.S which looks like:
.text
.long 0x27051956 /* U-Boot Magic Number */
.globl version_string
version_string:
.ascii U_BOOT_VERSION
.ascii " (", __DATE__, " - ", __TIME__, ")"
.ascii CONFIG_IDENT_STRING, "\0"
/*
* Maybe this should be moved somewhere else because the current
* location (0x100) is where the CriticalInput Execption should be.
*/
. = EXC_OFF_SYS_RESET
.globl _start
_start:
#if defined(CONFIG_405GP) || defined(CONFIG_405CR) || defined(CONFIG_405)
*---------------------------------- */
/* Clear and set up some registers. */
/*--------------------------------- */
addi r4,r0,0x0000
mtspr sgr,r4
mtspr dcwr,r4
Instead I see:
fff80100 <_start>:
fff80100: 38 80 00 00 li r4,0
fff80104: 7c 99 eb a6 mtsgr r4
fff80108: 7c 9a eb a6 mtdcwr r4
fff8010c: 7c 94 f3 a6 mtesr r4
fff80110: 7c 9a f3 a6 mttcr r4
fff80114: 7c 81 03 a6 mtxer r4
fff80118: 7c 96 f3 a6 mtevpr r4
fff8011c: 38 80 10 00 li r4,4096
So hence I am confused....
-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Jerry
Walden
Sent: Saturday, December 14, 2002 11:49 AM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] PPC 405 _start code
Greetings:
I just build a version of u-boot for the PPC 405GP.
If I disassemble the code that is generated I see the following:
fff80100 <_start>:
fff80100: 38 80 00 00 li r4,0
fff80104: 7c 99 eb a6 mtsgr r4
fff80108: 7c 9a eb a6 mtdcwr r4
fff8010c: 7c 94 f3 a6 mtesr r4
fff80110: 7c 9a f3 a6 mttcr r4
fff80114: 7c 81 03 a6 mtxer r4
fff80118: 7c 96 f3 a6 mtevpr r4
fff8011c: 38 80 10 00 li r4,4096
So to develop a deeper understanding of how all the pieces fit together
I went to the start.S module under the cpu subdirecory. There I
see the _start vector - however the code I see in start.S does not
correspond to the code that I disassembled.
What am I missing?
Kindest Regards,
Jerry
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Hans Reiser @ 2002-12-14 22:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Oleg Drokin, Linux Kernel Mailing List
In-Reply-To: <3DFB904F.2ADDE2D4@digeo.com>
Andrew Morton wrote:
>
>
>>(and btw you have not even seen reiser4 stack usage ;) )
>>
>>
>
>uh-oh. We need to be very sparing indeed.
>
It is not appropriate to reduce functionality and twist the code so as
to reduce the stack, in my opinion. I suppose we'll get to that
argument later though....
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Gérard Roudier @ 2002-12-14 21:55 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Justin T. Gibbs, James Bottomley, linux-scsi
In-Reply-To: <20021211153935.A23704@infradead.org>
On Wed, 11 Dec 2002, Christoph Hellwig wrote:
[...]
> linux driver interface change between stable series, face it. And a driver
> with tons of ifdefs is utter crap. Interestingly only vendor driver use
> that shitty scheme.
You just miss that new hardware must be supported for both stable and
current kernels and that differences in driver interface use to be large
between adjacent stable and current in Linux. On the other hand driver
interfaces in current kernel seem to be changing as new features come to
mind to developpers. Add to that mess that not all Linux based O/S are
using kernel at same level.
Btw, people who want to learn about how to design and maintain a smart
driver interface that can evolve gracefully without breaking driver
zillions of times should ask Justin how it does this so well with
FreeBSD/CAM, in my opinion.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Not able to compile modutils-2.4.21-7.src.rpm
From: Andrew McGregor @ 2002-12-14 21:34 UTC (permalink / raw)
To: Rusty Russell, Paolo Ciarrocchi; +Cc: adam, linux-kernel
In-Reply-To: <20021214014915.734112C510@lists.samba.org>
Yep, glibc-devel.
Andrew
--On Saturday, December 14, 2002 12:27:34 +1100 Rusty Russell
<rusty@rustcorp.com.au> wrote:
> In message <20021214000944.30118.qmail@linuxmail.org> you write:
>> Hi Rusty and Adam,
>> I send you again this bug report.
>>
>> [root@frodo module-init-tools-0.9.3]# rpm --rebuild
>> /mnt/nt/linux/kernel/modu
> les/modutils-2.4.21-7.src.rpm
>>
>> gcc -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586
>> -ffast-math -
> fno-strength-reduce -o modinfo modinfo.o ../obj/libobj.a ../util/libutil.a
>> gcc -static -O3 -fomit-frame-pointer -pipe -mcpu=pentiumpro -march=i586
>> -ffas
> t-math -fno-strength-reduce -o insmod.static insmod.o rmmod.o modprobe.o
> lsmod. o ksyms.o kallsyms.o ../obj/libobj.a ../util/libutil.a
>> /usr/bin/ld: cannot find -lc
>> collect2: ld returned 1 exit status
>> make[1]: *** [insmod.static] Error 1
>> make[1]: Leaving directory `/usr/src/RPM/BUILD/modutils-2.4.21/insmod'
>> make: *** [all] Error 2
>> error: Bad exit status from /var/tmp/rpm-tmp.76637 (%build)
>
> It looks like you don't have the ability to make static binaries.
> Does this fail for you, too?
>
> echo 'int main(){return 0;}' > /tmp/foo.c && gcc -static -o foo foo.c
>
> Perhaps there is some RH devel package you need to install to allow
> this to work?
>
> YA Debian User,
> Rusty.
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: new Debian packages
From: Russell Coker @ 2002-12-14 21:46 UTC (permalink / raw)
To: Tom, selinux
In-Reply-To: <20021214004206.D22479@lemuria.org>
On Sat, 14 Dec 2002 00:42, Tom wrote:
> On Fri, Dec 13, 2002 at 11:31:08PM +0100, Russell Coker wrote:
> > I have packaged the new kernel patch and the selinux-small code and
> > uploaded them to my web site and to Debian.
> >
> > Please make sure that you install the "selinux" and
> > "selinux-policy-default" packages BEFORE booting a kernel compiled with
> > the latest kernel patch.
>
> I'll be testing this next week. Any new kernels from Brian that I could
> give a shakedown while I'm at it? (I've hosed my test machine again.
> Must remember to be more careful. Will probably write a new chapter
> into my "things not to do with SELinux" paper. :) )
With what Brian is attempting to do with his kernels it might take him a while
to get a new one out. Maybe you would be better off just compiling your own.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: new Debian packages
From: Russell Coker @ 2002-12-14 21:45 UTC (permalink / raw)
To: Brian May; +Cc: selinux
In-Reply-To: <20021214005331.GG13385@snoopy.apana.org.au>
On Sat, 14 Dec 2002 01:53, Brian May wrote:
> On Sat, Dec 14, 2002 at 12:42:07AM +0100, Tom wrote:
> > I'll be testing this next week. Any new kernels from Brian that I could
> > give a shakedown while I'm at it? (I've hosed my test machine again.
> > Must remember to be more careful. Will probably write a new chapter
> > into my "things not to do with SELinux" paper. :) )
>
> The latest patch I have, at the usual place, is for the 2.4.19
> kernel.
>
> It has at least one know security bug fixed in the kernel, plus lots
> of patches I need from time to time (eg. EVMS, ACL, SE-Linux, FreeS/WAN,
> DOV).
That'll keep you busy!
I've given up on EVMS as Linus is not accepting the full EVMS thing and they
have been forced to radically change their plans. As this happened before I
got around to doing anything serious with EVMS I decided to skip it until
it's all settled down.
FreeS/WAN is in a similar situation, it's never going into the main kernel
tree and there's already a replacement for 2.6.
I've been thinking that it may be time to start moving some of my machines to
2.5.x. I think that 2.5.x development has slowed down enough for me to port
the LSM patches between kernels.
I'm just looking at 2.5 now. It appears to have IPSec, it has device-mapper
(not sure if this means LVM2 is in), it has ACLs, and lots of other nice
things such as CryptoAPI.
Maybe next time I run SE play machines I'll run one on a 2.4.x kernel and one
on 2.5.x (Sun gave me a RaQ to use for this sort of thing - thanks Sun).
> I am not sure if there are version of these patches that will work
> with 2.4.20 yet, that is something I need to investigate (DOV at least
> is suppost to have been integrated into the kernel by now).
What is DOV?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [RFC] Hardware support notes for the kernel crypto API (2.5+)
From: Andrew McGregor @ 2002-12-14 21:28 UTC (permalink / raw)
To: James Morris, linux-kernel; +Cc: David S. Miller, cryptoapi-devel
In-Reply-To: <Mutt.LNX.4.44.0212150025190.24712-100000@blackbird.intercode.com.au>
> - What will the Kernel & Userspace APIs look like?
A socket family? Most userspace crypto apps, IMO, will deal with
networking somewhere.
> - Asymmetric crypto?
Yes please! A HiFn 6500 can do a 2048-bit DH exchange in about 30ms,
compared with several seconds for a P3-900. It's similarly fast for
everything else, and utterly astonishing for RSA (under a millisecond for a
signature!).
> Intel
> Crypto documentation for NICs unavailable.
I may have some leverage here. We'll see.
> Broadcom
> No response to emails.
But OpenBSD has drivers, and they say that Broadcom were very good to deal
with. I suggest writing the OpenBSD driver maintainer and asking who to
contact.
Andrew
^ permalink raw reply
* Re: Re: kernel: matrox fb - missing files, doesn't compile
From: Antonino Daplas @ 2002-12-15 0:30 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Ariel, Linux Fbdev development list
In-Reply-To: <A31FF58755A@vcnet.vc.cvut.cz>
On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> Current interface just supports only cfb, and only very bad for my needs.
> And because of matroxfb supports also other modes (such as native text
> mode, or loading font into accelerator), bye-bye. For now I recommend you
> either to not upgrade, or use vesafb. Besides that accel_putcs() does not
> call fb_sync when using font width which is not multiple of 8, and that
Can you explain why an fb_sync is needed for every character?
> with fonts greater than 16*16 pixels (I believe that such fonts are still
> supported...) it will corrupt memory...
I agree. To be more specific, buffer overruns will occur if (xres *
fontheight/8 > 8192). The pixmap needs to be dynamically allocated and
resized somewhere in the fbcon layer (ideally in accel_setup(), but this
was removed). For those concerned about this problem, you can try this
patch as a temporary measure until fbcon is fixed. It should not cause
to much slowdown:
For anyone concerned, this is a heads up: The data in the pixmap must
be read completely by the hardware before exiting, otherwise font
corruption will occur. If you think this will be a problem, the
function can be easily modified to do multiple buffering instead.
Comments?
Tony
diff -Naur linux-2.5.51/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.51/drivers/video/console/fbcon.c 2002-12-14 23:33:50.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2002-12-14 23:35:10.000000000 +0000
@@ -390,7 +390,9 @@
unsigned int cellsize = vc->vc_font.height * width;
struct fb_image image;
u16 c = scr_readw(s);
- static u8 pixmap[8192];
+ static int xres = 0;
+ static int fontheight = 0;
+ static u8 *pixmap = NULL;
image.fg_color = attr_fgcol(p, c);
image.bg_color = attr_bgcol(p, c);
@@ -399,9 +401,24 @@
image.height = vc->vc_font.height;
image.depth = 1;
-/* pixmap = kmalloc((info->var.bits_per_pixel + 7) >> 3 *
- vc->vc_font.height, GFP_KERNEL);
-*/
+ /*
+ * FIXME: This code segment has to be placed
+ * somewhere else to allow freeing of
+ * memory on exit and to reduce unnecessary
+ * processing.
+ */
+ if (xres != info->var.xres ||
+ fontheight != vc->vc_font.height) {
+ xres = info->var.xres;
+ fontheight = vc->vc_font.height;
+
+ if (info->fbops->fb_sync)
+ info->fbops->fb_sync(info);
+ if (pixmap != NULL)
+ kfree(pixmap);
+ pixmap = kmalloc((xres + 7)/8 *
+ fontheight, GFP_KERNEL);
+ }
if (!(vc->vc_font.width & 7) && pixmap != NULL) {
unsigned int pitch = width * count, i, j;
@@ -432,10 +449,6 @@
image.dx += vc->vc_font.width;
}
}
- /*
- if (pixmap);
- kfree(pixmap);
- */
}
void accel_clear_margins(struct vc_data *vc, struct display *p,
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Mirrored and shiftet fonts and logos
From: Antonino Daplas @ 2002-12-15 0:30 UTC (permalink / raw)
To: André Stierenberg; +Cc: Linux Fbdev development list
In-Reply-To: <004501c2a3ab$015a5eb0$ee3c078b@nb1>
On Sun, 2002-12-15 at 00:53, André Stierenberg wrote:
> Now the characters are printed correctly. And in the linux logo, the
> pinguin, something is also wrong. It seems the some pixels are mirrored too
> whereas other pixels are correct.
>
> What could this be and in what way can i fix the problem?
>
The logo is drawn directly to the framebuffer by fbcon_show_logo() in
linux/drivers/video/fbcon.c.
In your case, (is this cfb4?), the code segment is enclosed by this
conditional:
#if defined(CONFIG_FBCON_CFB4)
...
#endif
You can apply the same reversal techniques to correct your problem.
Tony
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Mirrored Display?
From: Antonino Daplas @ 2002-12-15 0:29 UTC (permalink / raw)
To: Michael Kaufmann; +Cc: Linux Fbdev development list
In-Reply-To: <200212131733.42340.kaufmann@sohard.de>
On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> Hello,
>
> i would like to use a mono LCD with a framebuffer driver.
>
> I've modified existing drivers, and after a lot of work i now have a clear
> picture on my display. Unfortunately, the complete picture is mirrored.
> The Bootlogo is top/right instead of top/left and the ascii output starts from
> right to left.
>
> Where is the right place to modify this behaviour?
> I'm also looking for a possibility to rotate the picture.
> Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp.
>
> It would be very nice, if someone can guide me in the right direction.
>
Are you using fbcon-cfb4.c to draw the characters? Is the whole display
mirrored, including individual characters? If you run an fb-based app
(like fbtest for instance), is the display also mirrored?
If it's the whole display, maybe your hardware supports mirroring (some
hardware with video overlay need this to support YUV formats that are
either vertically or horizontally mirrored). Maybe it has something
like that. Otherwise, it will be difficult to correct this without
rewriting practically everything.
Tony
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: MFS: possible bad behaviour of the function exists
From: Bart Oldeman @ 2002-12-14 21:25 UTC (permalink / raw)
To: E_Jeandel; +Cc: linux-msdos
In-Reply-To: <20021214133836.GA1585@ens-lyon.fr>
On Sat, 14 Dec 2002, Emmanuel Jeandel wrote:
> My suggestion will be to comment/delete the line in exists speaking about
> strlowerDOS.
Thank you, that is indeed the correct solution, ie.,
--- mfs.c.old Sat Dec 14 16:23:35 2002
+++ mfs.c Sat Dec 14 16:24:20 2002
@@ -1008,7 +1008,6 @@
while (fullname[len - 1] == '.')
len--;
fullname[len] = '\0';
- strlowerDOS(fullname);
rc = find_file(fullname, st);
return rc;
}
also thanks for finding out about a solution to the Bison problems.
Bart
^ permalink raw reply
* Kernel with acpi hangs on compaq presario 1700
From: Jaap Hogenberg @ 2002-12-14 21:21 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
I'm new to this list so forgive me if this is a FAQ:
I'm tried kernel 2.4.20 with the acpi patches of 12052002 and 12122002
as well as a 2.5.51 with and without patch (12132002) and when I include
acpi support , the kernel will hang when probing the PCI bus.
I have seen references about acpi on compaq laptops indicating that it needed
some tweaking (dumping acpi tables to a file) but as these were
very old postings to linux-kernel mailing list , and the answers there
were quite inconclusive I thought I'd ask here.
Is there some (recent :-) ) documentation on getting acpi working
on this laptop ?
Or is there anything else I should try in my kernel config ?
Regards,
Jaap
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Reiserfs with Samba vs NetApp Filer (purely performance)
From: Hans Reiser @ 2002-12-14 21:19 UTC (permalink / raw)
To: darren; +Cc: 'Russell Coker', reiserfs-list
In-Reply-To: <000001c27328$771e5d80$0101a8c0@bummer>
darren wrote:
>Hi all,
>
>Thanks for all the very informative bits on this thread.
>
>In my usage, I intend to implement this fileserver to complement another
>server that runs a very intensive small files read/write operation.
>
>These files often run into 200,000 or more but are usually in the range
>of 100kb or less.
>
>Hence, space is not a big issue to me, but performance is. (there's no
>point splitting out the IO from the main server if it runs slower!!).
>
>I will be using an spare server to do this job: Dell Xeon 2GHz with 5 x
>72Gb SCSI hdd (I got on board RAID but have not decided on how to
>configure yet -help here are welcome too!).
>
>My options are: Win2k (NTFS with CIFS), Linux (Reiserfs with Samba) or
>Netapp 870.
>
>What do you guys think?
>
>Thanx again
>Darren
>
>
>
>
>
Turn off tails if you want good performance for V3.
^ permalink raw reply
* Re: Re: pci-skeleton duplex check
From: Mr. James W. Laferriere @ 2002-12-14 21:26 UTC (permalink / raw)
To: Russell King
Cc: arun4linux, Michael Richardson, netdev, Linux Kernel Mailing List
In-Reply-To: <20021214161446.B23020@flint.arm.linux.org.uk>
On Sat, 14 Dec 2002, Russell King wrote:
...
> Rubbish.
>
> Think about what you've just said. Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
Put very simply yes . x.odd-number.y IS for DEVELOPEMENT ,
x.even-number.y IS for Stability .
If people can not understand that I feel sorry for them .
JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
^ permalink raw reply
* Re: kernel 2.4 smc1 problems ... advice please ...
From: Wolfgang Denk @ 2002-12-14 21:13 UTC (permalink / raw)
To: James Don; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <DB0585C9F6F9D411BE8F00D0B7896A4CC05F11@SNCMAIL>
In message <DB0585C9F6F9D411BE8F00D0B7896A4CC05F11@SNCMAIL> you wrote:
>
> I am cuurently trying to boot up the linux kernel using ppcboot 1.16 and the
> 2.4 kernel with only smc1 uart support as a start on an MPC860 FADS derived
> board.
Which 2.4 kernel? Please be precise.
> So far I have:
> - ppcboot running great
> - tftpboot graps my kernel puts in RAM
> - bootm starts my kernel ... BUT no serial activity ...
This is a FAQ. See the Q&A section in http://www.denx.de/re/DPLG.html
Either you're passing a wrong bd_info structure, or a wrong clock
frequency (see also the PPCBoot README about the "clocks_in_mhz"
stuff.)
> I am using the vision ICE currently to debug the kernel start up but it has
> a problem stepping through the 'rfi' etc when memory protection is running.
You cannot step through rfi, not with any BDM debugger.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
I paid too much for it, but its worth it.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Mirrored and shiftet fonts and logos
From: James Simmons @ 2002-12-14 21:12 UTC (permalink / raw)
To: André Stierenberg; +Cc: linux-fbdev-devel
In-Reply-To: <004501c2a3ab$015a5eb0$ee3c078b@nb1>
Sounds like a endian issue. =Maybe the frmaebuffer and the processor are
different endianess.
On Sat, 14 Dec 2002, André Stierenberg wrote:
> Hello,
>
> i´m using the framebuffer driver pxafb for my board using the pxa processor
> (Accelent IDP). I have a 4 bit monocrom display. when I run the framebuffer
> I have some problems. The text in the console it in some way shifted. The
> two parts of the font are switched. The first 4 pixels are at dest+2 and the
> last 4 pixels at dest+0. And both parts are mirrored. Now I have done the
> following in fbcon_cfb4.c in function fbcon_cfb4_putcs:
>
> for (rows = fontheight(p), dest = dest0; rows-- ; dest += bytes) {
> fb_writew((nibbletab_cfb4[rv(*cdat) >> 4] & eorx) ^ bgx, dest+2);
> fb_writew((nibbletab_cfb4[rv(*cdat++) & 0xf] & eorx) ^ bgx, dest+0);
> }
>
>
> The function rv will reverse the bit order (bit 1 is bit 8, bit 2 is bit 7..
> etc.).
> And i have swaped the destination offset.
> Now the characters are printed correctly. And in the linux logo, the
> pinguin, something is also wrong. It seems the some pixels are mirrored too
> whereas other pixels are correct.
>
> What could this be and in what way can i fix the problem?
>
> Andre
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [BK] [PATCH] ReiserFS assorted trivia
From: Hans Reiser @ 2002-12-14 21:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: reiserfs fixes for 2.5.51 --]
[-- Type: message/rfc822, Size: 11794 bytes --]
From: Oleg Drokin <green@namesys.com>
To: reiser@namesys.com
Subject: reiserfs fixes for 2.5.51
Date: Fri, 13 Dec 2002 20:04:24 +0300
Message-ID: <20021213200424.A8873@namesys.com>
Hello!
These five changesets contain fixes for reiserfs. They fix issue with
handling of displacing_large_files allocator option, a problem with
remounting from readwrite to readwrite mode if FS holds some deleted,
but not yet closed files, replace lock_kernel() stuff with reiserfs
analogs, some C99 designated initialisers fixes and fixes for annoying
warnings in fs/reiserfs/procfs.c if you compile with reiserfs statistics.
You can pull these from bk://thebsh.namesys.com/bk/reiser3-linux-2.5-fixes
ChangeSet@1.849, 2002-12-07 14:13:55+03:00, green@angband.namesys.com
reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c
ChangeSet@1.848, 2002-12-07 13:20:18+03:00, green@angband.namesys.com
reiserfs: C99 designated initializers, by Art Haas
ChangeSet@1.847, 2002-12-07 13:18:51+03:00, green@angband.namesys.com
reiserfs: lock_kernel is replaced with its reiserfs variant
ChangeSet@1.846, 2002-12-07 13:17:28+03:00, green@angband.namesys.com
reiserfs: Fix a problem with delayed unlinks and remounting RW filesystem RW.
ChangeSet@1.845, 2002-12-07 13:16:27+03:00, green@angband.namesys.com
reiserfs: Take into account file information even when not doing preallocation. Fixes a bug with displacing_large_files option.
Diffstats:
fs/reiserfs/dir.c | 6 +++---
fs/reiserfs/inode.c | 16 ++++++++--------
fs/reiserfs/journal.c | 5 ++---
fs/reiserfs/namei.c | 18 +++++++++---------
fs/reiserfs/procfs.c | 16 ++++++++--------
fs/reiserfs/super.c | 36 ++++++++++++++++++++----------------
include/linux/reiserfs_fs.h | 3 ++-
7 files changed, 52 insertions(+), 48 deletions(-)
Plain text patch:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.844 -> 1.849
# fs/reiserfs/procfs.c 1.14 -> 1.15
# fs/reiserfs/inode.c 1.68 -> 1.70
# fs/reiserfs/super.c 1.54 -> 1.56
# fs/reiserfs/dir.c 1.17 -> 1.18
# fs/reiserfs/namei.c 1.44 -> 1.45
# fs/reiserfs/journal.c 1.59 -> 1.60
# include/linux/reiserfs_fs.h 1.45 -> 1.46
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.845
# reiserfs: Take into account file information even when not doing preallocation. Fixes a bug with displacing_large_files option.
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.846
# reiserfs: Fix a problem with delayed unlinks and remounting RW filesystem RW.
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.847
# reiserfs: lock_kernel is replaced with its reiserfs variant
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.848
# reiserfs: C99 designated initializers, by Art Haas
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.849
# reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/dir.c Sat Dec 7 14:14:58 2002
@@ -18,9 +18,9 @@
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) ;
struct file_operations reiserfs_dir_operations = {
- read: generic_read_dir,
- readdir: reiserfs_readdir,
- fsync: reiserfs_dir_fsync,
+ .read = generic_read_dir,
+ .readdir = reiserfs_readdir,
+ .fsync = reiserfs_dir_fsync,
};
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) {
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/inode.c Sat Dec 7 14:14:58 2002
@@ -490,7 +490,7 @@
return reiserfs_new_unf_blocknrs2(th, inode, allocated_block_nr, path, block);
}
#endif
- return reiserfs_new_unf_blocknrs (th, allocated_block_nr, path, block);
+ return reiserfs_new_unf_blocknrs (th, inode, allocated_block_nr, path, block);
}
int reiserfs_get_block (struct inode * inode, sector_t block,
@@ -2113,11 +2113,11 @@
}
struct address_space_operations reiserfs_address_space_operations = {
- writepage: reiserfs_writepage,
- readpage: reiserfs_readpage,
- releasepage: reiserfs_releasepage,
- sync_page: block_sync_page,
- prepare_write: reiserfs_prepare_write,
- commit_write: reiserfs_commit_write,
- bmap: reiserfs_aop_bmap
+ .writepage = reiserfs_writepage,
+ .readpage = reiserfs_readpage,
+ .releasepage = reiserfs_releasepage,
+ .sync_page = block_sync_page,
+ .prepare_write = reiserfs_prepare_write,
+ .commit_write = reiserfs_commit_write,
+ .bmap = reiserfs_aop_bmap
} ;
diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/journal.c Sat Dec 7 14:14:58 2002
@@ -1812,8 +1812,7 @@
struct reiserfs_journal_commit_task *ct = __ct;
struct reiserfs_journal_list *jl ;
- /* FIXMEL: is this needed? */
- lock_kernel();
+ reiserfs_write_lock(ct->p_s_sb);
jl = SB_JOURNAL_LIST(ct->p_s_sb) + ct->jindex ;
@@ -1824,7 +1823,7 @@
kupdate_one_transaction(ct->p_s_sb, jl) ;
}
reiserfs_kfree(ct->self, sizeof(struct reiserfs_journal_commit_task), ct->p_s_sb) ;
- unlock_kernel();
+ reiserfs_write_unlock(ct->p_s_sb);
}
static void setup_commit_task_arg(struct reiserfs_journal_commit_task *ct,
diff -Nru a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
--- a/fs/reiserfs/namei.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/namei.c Sat Dec 7 14:14:58 2002
@@ -1296,14 +1296,14 @@
*/
struct inode_operations reiserfs_dir_inode_operations = {
//&reiserfs_dir_operations, /* default_file_ops */
- create: reiserfs_create,
- lookup: reiserfs_lookup,
- link: reiserfs_link,
- unlink: reiserfs_unlink,
- symlink: reiserfs_symlink,
- mkdir: reiserfs_mkdir,
- rmdir: reiserfs_rmdir,
- mknod: reiserfs_mknod,
- rename: reiserfs_rename,
+ .create = reiserfs_create,
+ .lookup = reiserfs_lookup,
+ .link = reiserfs_link,
+ .unlink = reiserfs_unlink,
+ .symlink = reiserfs_symlink,
+ .mkdir = reiserfs_mkdir,
+ .rmdir = reiserfs_rmdir,
+ .mknod = reiserfs_mknod,
+ .rename = reiserfs_rename,
};
diff -Nru a/fs/reiserfs/procfs.c b/fs/reiserfs/procfs.c
--- a/fs/reiserfs/procfs.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/procfs.c Sat Dec 7 14:14:58 2002
@@ -78,7 +78,7 @@
struct super_block *sb;
char *format;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
if ( REISERFS_SB(sb)->s_properties & (1 << REISERFS_3_6) ) {
@@ -136,7 +136,7 @@
struct reiserfs_sb_info *r;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -229,7 +229,7 @@
int len = 0;
int level;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -308,7 +308,7 @@
struct reiserfs_sb_info *r;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -352,7 +352,7 @@
int hash_code;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
sb_info = REISERFS_SB(sb);
@@ -409,7 +409,7 @@
int len = 0;
int exact;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
sb_info = REISERFS_SB(sb);
@@ -461,7 +461,7 @@
struct journal_params *jp;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -604,7 +604,7 @@
{
return ( REISERFS_SB(sb)->procdir ) ? create_proc_read_entry
( name, 0, REISERFS_SB(sb)->procdir, func,
- ( void * ) sb->s_bdev->bd_dev) : NULL;
+ ( void * )(int) sb->s_bdev->bd_dev) : NULL;
}
void reiserfs_proc_unregister( struct super_block *sb, const char *name )
diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
--- a/fs/reiserfs/super.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/super.c Sat Dec 7 14:14:58 2002
@@ -474,25 +474,25 @@
struct super_operations reiserfs_sops =
{
- alloc_inode: reiserfs_alloc_inode,
- destroy_inode: reiserfs_destroy_inode,
- write_inode: reiserfs_write_inode,
- dirty_inode: reiserfs_dirty_inode,
- delete_inode: reiserfs_delete_inode,
- put_super: reiserfs_put_super,
- write_super: reiserfs_write_super,
- write_super_lockfs: reiserfs_write_super_lockfs,
- unlockfs: reiserfs_unlockfs,
- statfs: reiserfs_statfs,
- remount_fs: reiserfs_remount,
+ .alloc_inode = reiserfs_alloc_inode,
+ .destroy_inode = reiserfs_destroy_inode,
+ .write_inode = reiserfs_write_inode,
+ .dirty_inode = reiserfs_dirty_inode,
+ .delete_inode = reiserfs_delete_inode,
+ .put_super = reiserfs_put_super,
+ .write_super = reiserfs_write_super,
+ .write_super_lockfs = reiserfs_write_super_lockfs,
+ .unlockfs = reiserfs_unlockfs,
+ .statfs = reiserfs_statfs,
+ .remount_fs = reiserfs_remount,
};
static struct export_operations reiserfs_export_ops = {
- encode_fh: reiserfs_encode_fh,
- decode_fh: reiserfs_decode_fh,
- get_parent: reiserfs_get_parent,
- get_dentry: reiserfs_get_dentry,
+ .encode_fh = reiserfs_encode_fh,
+ .decode_fh = reiserfs_decode_fh,
+ .get_parent = reiserfs_get_parent,
+ .get_dentry = reiserfs_get_dentry,
} ;
/* this struct is used in reiserfs_getopt () for containing the value for those
@@ -716,7 +716,7 @@
}
if (*mount_flags & MS_RDONLY) {
- /* remount rean-only */
+ /* remount read-only */
if (s->s_flags & MS_RDONLY)
/* it is read-only already */
return 0;
@@ -732,6 +732,10 @@
journal_mark_dirty(&th, s, SB_BUFFER_WITH_SB (s));
s->s_dirt = 0;
} else {
+ /* remount read-write */
+ if (!(s->s_flags & MS_RDONLY))
+ return 0; /* We are read-write already */
+
REISERFS_SB(s)->s_mount_state = sb_umount_state(rs) ;
s->s_flags &= ~MS_RDONLY ; /* now it is safe to call journal_begin */
journal_begin(&th, s, 10) ;
diff -Nru a/include/linux/reiserfs_fs.h b/include/linux/reiserfs_fs.h
--- a/include/linux/reiserfs_fs.h Sat Dec 7 14:14:58 2002
+++ b/include/linux/reiserfs_fs.h Sat Dec 7 14:14:58 2002
@@ -2073,13 +2073,14 @@
}
extern inline int reiserfs_new_unf_blocknrs (struct reiserfs_transaction_handle *th,
+ struct inode *inode,
b_blocknr_t *new_blocknrs,
struct path * path, long block)
{
reiserfs_blocknr_hint_t hint = {
.th = th,
.path = path,
- .inode = NULL,
+ .inode = inode,
.block = block,
.formatted_node = 0,
.preallocate = 0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.