* [PATCH] Miscellaneous UML bug fixes
From: Jeff Dike @ 2002-12-17 23:23 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/fixes-2.5
This update fixes a number of small bugs:
strtoul calls are checked such that an empty string doesn't look like
zero
fixed some ubd driver error checking
a host helper is searched for if it's not in its usual location
fixed a check for an irq being disabled
Jeff
arch/um/drivers/fd.c | 2 +-
arch/um/drivers/mcast_kern.c | 4 ++--
arch/um/drivers/port_user.c | 2 +-
arch/um/drivers/ubd_kern.c | 9 ++++++---
arch/um/drivers/xterm.c | 3 +++
arch/um/kernel/exitcode.c | 2 +-
arch/um/kernel/helper.c | 5 ++++-
arch/um/kernel/irq_user.c | 3 ++-
arch/um/kernel/tty_log.c | 2 +-
arch/um/os-Linux/file.c | 3 ++-
include/asm-um/system-generic.h | 1 +
11 files changed, 24 insertions(+), 12 deletions(-)
ChangeSet@1.797.78.1, 2002-11-18 21:53:20-05:00, jdike@uml.karaya.com
Merged a number of bug fixes from the 2.4 pool.
^ permalink raw reply
* [PATCH] UML network updates
From: Jeff Dike @ 2002-12-17 23:24 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/net-2.5
This updates the UML networking support:
adds help text to the UML network config options
adds the slirp back end
updates and cleans up the slip back end
improves the driver's error handling
cleans up device initialization
Jeff
arch/um/Kconfig_net | 147 +++++++++++++++++++++++++++++++
arch/um/drivers/Makefile | 24 +----
arch/um/drivers/net_kern.c | 111 +++++++++++++----------
arch/um/drivers/slip.h | 10 +-
arch/um/drivers/slip_kern.c | 9 -
arch/um/drivers/slip_proto.h | 93 +++++++++++++++++++
arch/um/drivers/slip_user.c | 104 +++++-----------------
arch/um/drivers/slirp.h | 51 ++++++++++
arch/um/drivers/slirp_kern.c | 132 ++++++++++++++++++++++++++++
arch/um/drivers/slirp_user.c | 202 +++++++++++++++++++++++++++++++++++++++++++
arch/um/include/net_kern.h | 5 +
arch/um/include/net_user.h | 5 +
12 files changed, 742 insertions(+), 151 deletions(-)
ChangeSet@1.982, 2002-12-17 00:56:55-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/net-2.5
ChangeSet@1.797.50.2, 2002-11-17 13:37:34-05:00, jdike@uml.karaya.com
Copied in the new files for the slirp transport and slip cleanup.
ChangeSet@1.797.50.1, 2002-11-17 13:26:59-05:00, jdike@uml.karaya.com
Merged the network fixes from the 2.4 pool.
ChangeSet@1.797.44.4, 2002-11-17 13:00:11-05:00, jdike@uml.karaya.com
Moved the net changes to arch/um/drivers/Makefile into updates to a
void a merge conflict.
^ permalink raw reply
* [PATCH] Update UML to 2.5.52
From: Jeff Dike @ 2002-12-17 23:23 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/updates-2.5
This patch brings UML up to date with 2.5.52:
build cleanups
an updated defconfig
bug fixes in the console and serial line drivers
the block driver again supports partitions
more symbols exported
SMP fixes
interrupt handling fixes
hook in the new system calls
sys_restart_syscall support
Jeff
arch/um/Kconfig | 1 +
arch/um/drivers/line.c | 1 +
arch/um/kernel/process_kern.c | 2 +-
arch/um/kernel/signal_kern.c | 8 ++++++++
arch/um/kernel/sys_call_table.c | 19 ++++++++++---------
arch/um/kernel/syscall_kern.c | 12 ++++++++----
arch/um/kernel/sysrq.c | 8 ++++----
arch/um/sys-i386/Makefile | 36 +++++++++++++++++-------------------
arch/um/uml.lds.S | 12 +++++++++++-
include/asm-um/pgtable.h | 6 +++---
include/asm-um/thread_info.h | 10 ++++------
include/asm-um/uaccess.h | 2 +-
12 files changed, 69 insertions(+), 48 deletions(-)
ChangeSet@1.985, 2002-12-17 02:28:31-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/updates-2.5
into uml.karaya.com:/home/jdike/linux/2.5/updates-2.5
ChangeSet@1.984, 2002-12-17 02:22:54-05:00, jdike@uml.karaya.com
Updated to 2.5.52. A couple of changes relating to system call
restarting.
ChangeSet@1.981.1.1, 2002-12-17 01:34:58-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/updates-2.5
ChangeSet@1.983, 2002-12-17 00:44:15-05:00, jdike@uml.karaya.com
Applied updates from 2.5.51 and 2.5.52.
ChangeSet@1.982, 2002-12-16 15:16:49-05:00, jdike@uml.karaya.com
Merge uml.karaya.com:/home/jdike/linux/2.5/linus-2.5
into uml.karaya.com:/home/jdike/linux/2.5/updates-2.5
ChangeSet@1.797.173.3, 2002-12-06 21:29:24-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/updates-2.5
into uml.karaya.com:/home/jdike/linux/2.5/updates-2.5
ChangeSet@1.797.173.2, 2002-12-06 21:23:55-05:00, jdike@uml.karaya.com
Updated to 2.5.50.
ChangeSet@1.797.193.1, 2002-12-06 19:15:18-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/updates-2.5
ChangeSet@1.797.173.1, 2002-11-30 14:18:23-05:00, jdike@uml.karaya.com
Merge uml.karaya.com:/home/jdike/linux/2.5/linus-2.5
into uml.karaya.com:/home/jdike/linux/2.5/updates-2.5
ChangeSet@1.797.132.2, 2002-11-23 19:25:48-05:00, jdike@uml.karaya.com
Updated to 2.5.49, which involved fixing the calls to do_fork.
ChangeSet@1.797.71.4, 2002-11-21 23:21:41-05:00, jdike@uml.karaya.com
Removed the checksum.S symlink from arch/um/sys-i386/Makefile.
ChangeSet@1.797.71.3, 2002-11-21 14:05:13-05:00, jdike@uml.karaya.com
Changed the config to pull in zlib.
ChangeSet@1.797.71.2, 2002-11-18 20:03:13-05:00, jdike@uml.karaya.com
A few more fixes to get 2.4.48 to boot.
ChangeSet@1.797.71.1, 2002-11-18 15:57:00-05:00, jdike@uml.karaya.com
Updated to 2.5.48
^ permalink raw reply
* [PATCH] UML device configuration reporting
From: Jeff Dike @ 2002-12-17 23:24 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/mconfig-2.5
This update allows the UML device drivers to report their configurations
to the host.
Jeff
arch/um/drivers/chan_kern.c | 66 ++++++++++++++++++++++++++++-
arch/um/drivers/fd.c | 6 ++
arch/um/drivers/line.c | 91 +++++++++++++++++++++++++++++++++++-----
arch/um/drivers/mconsole_kern.c | 62 +++++++++++++++++++++++++--
arch/um/drivers/null.c | 5 +-
arch/um/drivers/port_user.c | 9 +++
arch/um/drivers/pty.c | 17 ++++++-
arch/um/drivers/ssl.c | 32 +++++++++++++-
arch/um/drivers/stdio_console.c | 30 ++++++++++++-
arch/um/drivers/tty.c | 8 ++-
arch/um/drivers/ubd_kern.c | 39 +++++++++++++++++
arch/um/drivers/xterm.c | 4 +
arch/um/include/chan_kern.h | 3 +
arch/um/include/chan_user.h | 3 -
arch/um/include/line.h | 11 +++-
arch/um/include/mconsole_kern.h | 16 ++++++-
16 files changed, 371 insertions(+), 31 deletions(-)
ChangeSet@1.797.71.1, 2002-11-18 15:57:40-05:00, jdike@uml.karaya.com
Merged the get_config changes from 2.4.
^ permalink raw reply
* [PATCH] Allow UML kernel to run in a separate host address space
From: Jeff Dike @ 2002-12-17 23:24 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/skas-2.5
This allows the UML kernel to run in a different address space from its
processes. The benefits include better security and much improved performance.
This is a large patch, but
it's all under arch/um and include/asm-um
a lot of it is code movement
This is described fairly completely in
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=fa.ia69pmv.e4qnq1%40ifi.uio.no
Jeff
arch/um/Kconfig | 8
arch/um/Makefile | 77 ++--
arch/um/Makefile-i386 | 4
arch/um/drivers/chan_kern.c | 66 +++
arch/um/drivers/chan_user.c | 33 -
arch/um/drivers/fd.c | 6
arch/um/drivers/line.c | 108 +++++-
arch/um/drivers/mconsole_kern.c | 62 +++
arch/um/drivers/null.c | 5
arch/um/drivers/port_kern.c | 13
arch/um/drivers/port_user.c | 9
arch/um/drivers/pty.c | 19 -
arch/um/drivers/ssl.c | 36 +-
arch/um/drivers/stdio_console.c | 32 +
arch/um/drivers/tty.c | 8
arch/um/drivers/ubd_kern.c | 39 ++
arch/um/drivers/xterm.c | 4
arch/um/include/chan_kern.h | 3
arch/um/include/chan_user.h | 4
arch/um/include/choose-mode.h | 35 ++
arch/um/include/debug.h | 26 -
arch/um/include/frame.h | 18 -
arch/um/include/kern.h | 2
arch/um/include/kern_util.h | 28 -
arch/um/include/line.h | 11
arch/um/include/mconsole_kern.h | 16
arch/um/include/mem.h | 1
arch/um/include/mem_user.h | 12
arch/um/include/mode.h | 30 +
arch/um/include/mode_kern.h | 30 +
arch/um/include/os.h | 8
arch/um/include/sigcontext.h | 2
arch/um/include/syscall_user.h | 13
arch/um/include/sysdep-i386/checksum.h | 217 ++++++++++++
arch/um/include/sysdep-i386/frame_kern.h | 9
arch/um/include/sysdep-i386/ptrace.h | 109 ++++--
arch/um/include/sysdep-i386/sigcontext.h | 33 +
arch/um/include/time_user.h | 2
arch/um/include/um_mmu.h | 40 ++
arch/um/include/um_uaccess.h | 73 ++++
arch/um/include/user_util.h | 26 -
arch/um/kernel/Makefile | 58 +--
arch/um/kernel/checksum.c | 42 ++
arch/um/kernel/exec_kern.c | 64 ---
arch/um/kernel/exec_user.c | 49 --
arch/um/kernel/frame.c | 204 ++++++-----
arch/um/kernel/frame_kern.c | 85 +++-
arch/um/kernel/helper.c | 5
arch/um/kernel/init_task.c | 2
arch/um/kernel/ksyms.c | 17
arch/um/kernel/mem.c | 71 +---
arch/um/kernel/mem_user.c | 44 --
arch/um/kernel/process.c | 136 +++++--
arch/um/kernel/process_kern.c | 477 +--------------------------
arch/um/kernel/ptrace.c | 61 +++
arch/um/kernel/reboot.c | 25 -
arch/um/kernel/sigio_user.c | 13
arch/um/kernel/signal_kern.c | 19 -
arch/um/kernel/signal_user.c | 9
arch/um/kernel/skas/Makefile | 24 +
arch/um/kernel/skas/exec_kern.c | 41 ++
arch/um/kernel/skas/exec_user.c | 61 +++
arch/um/kernel/skas/include/mmu.h | 27 +
arch/um/kernel/skas/include/mode.h | 34 +
arch/um/kernel/skas/include/mode_kern.h | 52 +++
arch/um/kernel/skas/include/proc_mm.h | 55 +++
arch/um/kernel/skas/include/ptrace-skas.h | 57 +++
arch/um/kernel/skas/include/skas.h | 49 ++
arch/um/kernel/skas/include/skas_ptrace.h | 36 ++
arch/um/kernel/skas/include/uaccess.h | 236 +++++++++++++
arch/um/kernel/skas/mem.c | 35 ++
arch/um/kernel/skas/mem_user.c | 95 +++++
arch/um/kernel/skas/mmu.c | 46 ++
arch/um/kernel/skas/process.c | 386 ++++++++++++++++++++++
arch/um/kernel/skas/process_kern.c | 195 +++++++++++
arch/um/kernel/skas/sys-i386/Makefile | 14
arch/um/kernel/skas/sys-i386/sigcontext.c | 114 ++++++
arch/um/kernel/skas/syscall_kern.c | 42 ++
arch/um/kernel/skas/syscall_user.c | 47 ++
arch/um/kernel/skas/time.c | 30 +
arch/um/kernel/skas/tlb.c | 156 +++++++++
arch/um/kernel/skas/trap_user.c | 66 +++
arch/um/kernel/skas/util/Makefile | 10
arch/um/kernel/skas/util/mk_ptregs.c | 50 ++
arch/um/kernel/smp.c | 12
arch/um/kernel/sys_call_table.c | 15
arch/um/kernel/syscall_kern.c | 126 -------
arch/um/kernel/syscall_user.c | 79 ----
arch/um/kernel/sysrq.c | 8
arch/um/kernel/time.c | 22 -
arch/um/kernel/time_kern.c | 3
arch/um/kernel/tlb.c | 225 +------------
arch/um/kernel/trap_kern.c | 361 +++------------------
arch/um/kernel/trap_user.c | 492 +---------------------------
arch/um/kernel/tt/Makefile | 20 +
arch/um/kernel/tt/exec_kern.c | 84 ++++
arch/um/kernel/tt/exec_user.c | 49 ++
arch/um/kernel/tt/gdb.c | 278 ++++++++++++++++
arch/um/kernel/tt/gdb_kern.c | 40 ++
arch/um/kernel/tt/include/debug.h | 29 +
arch/um/kernel/tt/include/mmu.h | 23 +
arch/um/kernel/tt/include/mode.h | 35 ++
arch/um/kernel/tt/include/mode_kern.h | 53 +++
arch/um/kernel/tt/include/ptrace-tt.h | 26 +
arch/um/kernel/tt/include/tt.h | 45 ++
arch/um/kernel/tt/include/uaccess.h | 119 ++++++
arch/um/kernel/tt/ksyms.c | 28 +
arch/um/kernel/tt/mem.c | 77 ++++
arch/um/kernel/tt/process_kern.c | 513 ++++++++++++++++++++++++++++++
arch/um/kernel/tt/ptproxy/Makefile | 13
arch/um/kernel/tt/ptproxy/proxy.c | 370 +++++++++++++++++++++
arch/um/kernel/tt/ptproxy/ptproxy.h | 61 +++
arch/um/kernel/tt/ptproxy/ptrace.c | 239 +++++++++++++
arch/um/kernel/tt/ptproxy/sysdep.c | 71 ++++
arch/um/kernel/tt/ptproxy/sysdep.h | 25 +
arch/um/kernel/tt/ptproxy/wait.c | 86 +++++
arch/um/kernel/tt/ptproxy/wait.h | 15
arch/um/kernel/tt/sys-i386/Makefile | 14
arch/um/kernel/tt/sys-i386/sigcontext.c | 59 +++
arch/um/kernel/tt/syscall_kern.c | 140 ++++++++
arch/um/kernel/tt/syscall_user.c | 90 +++++
arch/um/kernel/tt/time.c | 28 +
arch/um/kernel/tt/tlb.c | 226 +++++++++++++
arch/um/kernel/tt/tracer.c | 466 +++++++++++++++++++++++++++
arch/um/kernel/tt/trap_user.c | 58 +++
arch/um/kernel/tt/uaccess_user.c | 126 +++++++
arch/um/kernel/uaccess_user.c | 126 -------
arch/um/kernel/um_arch.c | 119 +++---
arch/um/kernel/umid.c | 6
arch/um/main.c | 64 ---
arch/um/os-Linux/Makefile | 6
arch/um/os-Linux/drivers/Makefile | 3
arch/um/os-Linux/process.c | 42 ++
arch/um/os-Linux/tty.c | 2
arch/um/ptproxy/Makefile | 10
arch/um/ptproxy/proxy.c | 370 ---------------------
arch/um/ptproxy/ptproxy.h | 61 ---
arch/um/ptproxy/ptrace.c | 238 -------------
arch/um/ptproxy/sysdep.c | 71 ----
arch/um/ptproxy/sysdep.h | 25 -
arch/um/ptproxy/wait.c | 86 -----
arch/um/ptproxy/wait.h | 15
arch/um/sys-i386/Makefile | 36 --
arch/um/sys-i386/checksum.S | 460 ++++++++++++++++++++++++++
arch/um/sys-i386/ksyms.c | 3
arch/um/sys-i386/ldt.c | 69 +++-
arch/um/sys-i386/ptrace.c | 57 ++-
arch/um/sys-i386/ptrace_user.c | 2
arch/um/sys-i386/sigcontext.c | 39 --
arch/um/sys-i386/util/mk_thread_kern.c | 16
arch/um/sys-i386/util/mk_thread_user.c | 32 +
arch/um/uml.lds.S | 1
arch/um/util/Makefile | 11
arch/um/util/mk_constants_kern.c | 24 +
arch/um/util/mk_constants_user.c | 28 +
include/asm-um/a.out.h | 8
include/asm-um/checksum.h | 2
include/asm-um/mmu.h | 18 -
include/asm-um/mmu_context.h | 51 ++
include/asm-um/page.h | 2
include/asm-um/processor-generic.h | 39 +-
include/asm-um/ptrace-generic.h | 2
include/asm-um/uaccess.h | 100 -----
163 files changed, 8121 insertions(+), 3588 deletions(-)
ChangeSet@1.984, 2002-12-17 02:55:00-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.981.1.1, 2002-12-17 02:34:29-05:00, jdike@jdike.wstearns.org
Merge
ChangeSet@1.983, 2002-12-17 02:21:56-05:00, jdike@uml.karaya.com
Removed includes of Rules.mk.
ChangeSet@1.982, 2002-12-17 01:06:44-05:00, jdike@uml.karaya.com
Merged the 2.5.52 Makefile changes.
ChangeSet@1.797.195.3, 2002-12-06 21:30:55-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.195.2, 2002-12-06 21:25:54-05:00, jdike@uml.karaya.com
Added a couple of includes as part of the 2.5.50 update.
ChangeSet@1.797.196.1, 2002-12-06 19:04:22-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/skas-2.5
ChangeSet@1.797.195.1, 2002-12-06 18:14:59-05:00, jdike@uml.karaya.com
Merge uml.karaya.com:/home/jdike/linux/2.5/linus-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.134.7, 2002-11-25 22:07:47-05:00, jdike@uml.karaya.com
Fixed a stupid compile bug.
ChangeSet@1.797.134.6, 2002-11-25 21:03:24-05:00, jdike@uml.karaya.com
Small fixes to sync up the 2.4 and 2.5 pools.
Also fixed a stupid signal handling bug.
ChangeSet@1.797.134.5, 2002-11-25 13:41:02-05:00, jdike@uml.karaya.com
A whole lot of small changes to sync up the 2.4 and 2.5 pools
somewhat. Mostly whitespace changes, plus some code movement.
Also added checksum.S to the repository, which I had somehow
missed before.
ChangeSet@1.797.134.3, 2002-11-23 21:37:53-05:00, jdike@uml.karaya.com
Merge
ChangeSet@1.797.134.2, 2002-11-23 19:25:48-05:00, jdike@uml.karaya.com
Updated to 2.5.49, which involved fixing the calls to do_fork.
ChangeSet@1.797.72.14, 2002-11-23 16:49:59-05:00, jdike@uml.karaya.com
Finished the skas merge by eliminating a syntax error, fixing the
new compilation warnings, and fixing a call to handle_page_fault.
ChangeSet@1.797.72.13, 2002-11-22 21:47:15-05:00, jdike@uml.karaya.com
Merged the rest of the skas changes.
ChangeSet@1.797.72.12, 2002-11-22 21:22:57-05:00, jdike@uml.karaya.com
Fixed various build problems with the tlb.c merge.
ChangeSet@1.797.72.11, 2002-11-22 20:39:33-05:00, jdike@uml.karaya.com
Merged the tlb.c changes from the skas patch.
ChangeSet@1.797.72.10, 2002-11-22 14:27:24-05:00, jdike@uml.karaya.com
Minor build fixes to the last batch of skas merges.
ChangeSet@1.797.72.9, 2002-11-22 12:53:13-05:00, jdike@uml.karaya.com
Merged a number of small skas changes.
ChangeSet@1.797.72.8, 2002-11-21 23:22:43-05:00, jdike@uml.karaya.com
Some small build fixes to the IP checksum merge.
ChangeSet@1.797.71.4, 2002-11-21 23:21:41-05:00, jdike@uml.karaya.com
Removed the checksum.S symlink from arch/um/sys-i386/Makefile.
ChangeSet@1.797.72.7, 2002-11-21 22:30:24-05:00, jdike@uml.karaya.com
Merged the IP checksum changes from the skas code.
ChangeSet@1.797.72.6, 2002-11-21 22:26:06-05:00, jdike@uml.karaya.com
Some minor build and compilation fixes to the copy_sc merge.
ChangeSet@1.797.72.5, 2002-11-21 22:00:31-05:00, jdike@uml.karaya.com
Applied the sigcontext changes in the skas code.
ChangeSet@1.797.72.4, 2002-11-21 21:38:56-05:00, jdike@uml.karaya.com
A number of small fixes for the uaccess merge.
ChangeSet@1.797.72.3, 2002-11-21 18:54:16-05:00, jdike@uml.karaya.com
Added the uaccess changes from the skas merge.
ChangeSet@1.797.72.2, 2002-11-21 17:16:25-05:00, jdike@uml.karaya.com
Resolved the conflict between the skas and get_config changes in
line.h.
ChangeSet@1.797.80.17, 2002-11-21 14:59:43-05:00, jdike@uml.karaya.com
Added skas/mem_user.c and tt/gdb.c
ChangeSet@1.797.80.16, 2002-11-21 14:48:11-05:00, jdike@uml.karaya.com
Added a bunch of C files under arch/um/kernel/skas and
arch/um/kernel/tt.
ChangeSet@1.797.80.15, 2002-11-21 14:31:45-05:00, jdike@uml.karaya.com
Added a batch of files under arch/um/kernel/skas.
ChangeSet@1.797.80.14, 2002-11-21 14:09:26-05:00, jdike@uml.karaya.com
Added arch/um/include/mode_kern.h
ChangeSet@1.797.71.3, 2002-11-21 14:05:13-05:00, jdike@uml.karaya.com
Changed the config to pull in zlib.
ChangeSet@1.797.80.13, 2002-11-21 13:23:40-05:00, jdike@uml.karaya.com
Added the mode mmu.h and mode.h headers.
ChangeSet@1.797.80.12, 2002-11-21 13:15:09-05:00, jdike@uml.karaya.com
Added mode.h, mk_constants_kern.c, mk_constants_user.c, and um_mmu.h
ChangeSet@1.797.80.11, 2002-11-21 12:58:41-05:00, jdike@uml.karaya.com
Added ptrace-skas.h and ptrace-tt.h.
ChangeSet@1.797.80.10, 2002-11-21 12:52:36-05:00, jdike@uml.karaya.com
Added arch/um/kernel/skas/util/*, which I missed somehow.
ChangeSet@1.797.80.9, 2002-11-20 23:04:22-05:00, jdike@uml.karaya.com
Merged most of the rest of the skas changes.
ChangeSet@1.797.80.8, 2002-11-19 14:54:08-05:00, jdike@uml.karaya.com
Declared mode_tt in user_util.h.
ChangeSet@1.797.80.7, 2002-11-19 14:53:18-05:00, jdike@uml.karaya.com
Merged the skas exec reorg.
ChangeSet@1.797.80.6, 2002-11-19 13:47:41-05:00, jdike@uml.karaya.com
Fixed a couple of buglets in the signal frame merge.
ChangeSet@1.797.80.5, 2002-11-19 00:54:26-05:00, jdike@uml.karaya.com
Merged the signal frame cleanups and fixes from 2.4.
ChangeSet@1.797.80.4, 2002-11-19 00:47:18-05:00, jdike@uml.karaya.com
Fixes to the last merge.
ChangeSet@1.797.80.3, 2002-11-19 00:13:26-05:00, jdike@uml.karaya.com
Merged the os_kill_process and the driver from_user changes from
the 2.4 pool.
Also merged some other cleanups.
ChangeSet@1.797.80.2, 2002-11-18 23:28:32-05:00, jdike@uml.karaya.com
Fixed the Makefiles so that the ptproxy move from arch/um/ptproxy
to arch/um/kernel/tt/ptproxy works.
ChangeSet@1.797.80.1, 2002-11-18 22:47:18-05:00, jdike@uml.karaya.com
Moved the ptproxy code from arch/um/ptproxy to
arch/um/kernel/tt/ptproxy.
ChangeSet@1.797.71.2, 2002-11-18 20:03:13-05:00, jdike@uml.karaya.com
A few more fixes to get 2.4.48 to boot.
ChangeSet@1.797.72.1, 2002-11-18 15:57:40-05:00, jdike@uml.karaya.com
Merged the get_config changes from 2.4.
ChangeSet@1.797.71.1, 2002-11-18 15:57:00-05:00, jdike@uml.karaya.com
Updated to 2.5.48
^ permalink raw reply
* [PATCH] UML documentation updates
From: Jeff Dike @ 2002-12-17 23:23 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/doc-2.5
This updates the UML documentation:
adds help text back to the UML config
deletes the old config.in files
puts the UML HOWTO in Documentation/uml
Jeff
Documentation/uml/UserModeLinux-HOWTO.txt | 4686 ++++++++++++++++++++++++++++++
arch/um/Kconfig | 85
arch/um/Kconfig_block | 34
arch/um/Kconfig_char | 76
arch/um/config_block.in | 16
arch/um/config_char.in | 37
arch/um/config_net.in | 46
arch/um/config_scsi.in | 30
8 files changed, 4878 insertions(+), 132 deletions(-)
ChangeSet@1.797.69.2, 2002-11-18 14:22:01-05:00, jdike@uml.karaya.com
Added the UML HOWTO in Documentation/uml.
ChangeSet@1.797.53.1, 2002-11-17 15:36:15-05:00, jdike@uml.karaya.com
Merged the help text from the 2.4 Configure.help.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Andre Hedrick @ 2002-12-17 23:18 UTC (permalink / raw)
To: Dave Jones; +Cc: Linus Torvalds, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <20021217124009.GB10589@suse.de>
Okay I will go back to my storage cave, call when you need something.
Got some meat tenderizer for the shoe leather to make choking it down
easier?
Cheers,
On Tue, 17 Dec 2002, Dave Jones wrote:
> On Tue, Dec 17, 2002 at 01:45:52AM -0800, Andre Hedrick wrote:
>
> > Are you serious about moving of the banging we currently do on 0x80?
> > If so, I have a P4 development board with leds to monitor all the lower io
> > ports and can decode for you.
>
> INT 0x80 != IO port 0x80
>
> 8-)
>
> Dave
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Driver for Margi video card?
From: fleming @ 2002-12-17 23:16 UTC (permalink / raw)
To: linux-kernel
I have a Margi Diaply-to-Go video card. I am looking for a driver for
Linux; I'm running RedHat's 2.4.18 kernel, but this is negotiable.
My searches so far have shown that there's an (unrelated) DVD/MPEG
type card. My search found no other matches, either on LKML archives,
comp.os.linux.hardware, or google. I suspect this means there is in
fact no driver currently available, but I thought I would check here
before I consider writing my own.
Please respond to fleming@austin.ibm.com.
Thanks,
Matt
--
fleming@austin.ibm.com
^ permalink raw reply
* Re: Brute force printk routines for looking at netfilter structures
From: Patrick Schaaf @ 2002-12-17 23:07 UTC (permalink / raw)
To: Patrick Schaaf; +Cc: Ranjeet Shetye, netfilter-devel
In-Reply-To: <20021217203737.GA25448@oknodo.bof.de>
> > signed int nf_debug_indent = 0;
>
> Why signed? Anyway, this will fall on its face on SMP systems.
> Cure: use atomic_t.
Ahem. Given the application, a per-cpu nf_debug_indent would be
the proper cure, together with preventing preemption whenever
nf_debug_indent is above 0. You can then also printk the CPU
number along with the rest :-)
best regards
Patrick
^ permalink raw reply
* Re: 2.5.52 compile error
From: Randy.Dunlap @ 2002-12-17 23:03 UTC (permalink / raw)
To: eric lin; +Cc: James Simmons, linux-kernel
In-Reply-To: <3E001D07.5010006@centurytel.net>
| > Yes!!! I have a patch for fixing this issue.
| >
| > You can import this changeset into BK by piping this whole message to:
| > '| bk receive [path to repository]' or apply the patch as usual.
| >
| > ===================================================================
| >
| >
| > ChangeSet@1.868, 2002-12-10 12:07:45-08:00, jsimmons@kozmo.(none)
| > The VT tty layer depends on the input api now. Fixed this dependency.
| >
| >
| > Kconfig | 1 +
| > 1 files changed, 1 insertion(+)
| >
| >
| > diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig
| > --- a/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
| > +++ b/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
| > @@ -6,6 +6,7 @@
| >
| > config VT
| > bool "Virtual terminal"
| > + depends on INPUT=y
| > ---help---
| > If you say Y here, you will get support for terminal devices with
| > display and keyboard devices. These are called "virtual" because you
| >
| > ===================================================================
| >
| >
| > This BitKeeper patch contains the following changesets:
| I copied this piece as patch1.tar.gz
This piece is just the above piece in gz format.
You don't need this latter piece, just the above part.
| --------------------------------------------------------------
| > +
| > ## Wrapped with gzip_uu ##
| >
| >
| > begin 664 bkpatch6044
| > M'XL(`+!+]CT``]54VVH;,1!]MKYB("\MQ;NZ[,T+6]RFEX24UKA.7TH?A';L
| > MW=@KF97L9,-^?&6[N1!,H*5]J"X(9H;#F3D'G<"EQ38?7-FZ:8RVY`3.C'7Y
| > M8&EN&Q.\T$;C2Q^<&N.#X<:VH6U5N*KUYF98Z_7&$9^=2*<JV&)K\P$+Q'W$
| > M=6O,!]/W'R\_O9D24A1P6DF]P*_HH"B(,^U6KDH[EJY:&1VX5FK;H).!,DU_
| > M7]IS2KG?,4L%C9.>)31*>\5*QF3$L*0\RI*(W+4P?DS]"0KCC+)1%,6C7B24
| > M"?(.6)`E&5`>,G\H,)[3-(_B(<UR2N$H*+QB,*3D+?S=!DZ)@EF%\&T&SG6P
| > MDAVV4.(:=6G!:'`^MQ\YR'4-VEP'\*&^P=(G:ONK$+7J`B`7(.(TC<CD8>!D
| > M^)N+$"HI>0VW]7J-J_%!\B;)EH%I%]_O6O_1EVV]4SY4E6S#"V7TO%X<ADT%
| > MI9'@/.LYIUG6BU0D*.99R>>E$!R/3_<90`_IWY1Y]40<97M'':O>F>O?T2:E
| > MW.+56)D2/?DE=COD8+-\!I)Q?^/$JR[8B!]L)YZ:CHW^>]/M5?D"P_9Z?[R)
| > L)D<%^@,SGF?`R.`1L_//D\M9T3W\/ZI"M;2;IE!2\7B$2'X"W[RZ@MX$````
| > `
| > end
| >
| -------------------------------------------------------------------
| then in my /linux-2.5.52/
|
| fsshl@www:~/linux-2.5.52$ gzip -cd patch1.tar.gz | patch -p1
| patch: **** Only garbage was found in the patch input.
Yep.
| Please help
--
~Randy
^ permalink raw reply
* Re: PATCH
From: Greg Lindahl @ 2002-12-17 22:59 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <1040165474.16482.22.camel@zeus.mvista.com>
On Tue, Dec 17, 2002 at 02:51:14PM -0800, Pete Popov wrote:
> One of the problems with these graphics cards is that they are end of
> life before you finish writing the driver. I still have a few RageXL
> cards in the office, but you can't even buy them in the store anymore.
Yeah, that's why emulation might turn out to be easier in the long run.
This emulator:
http://www.scitechsoft.com/products/developer/x86_emulator.html
claims to be the one in XFree86 these days. Another emulation project
is bochs. It doesn't really matter if the performance isn't great
since the BIOS doesn't run for very long. But I think I'll have to dig
around a bit to figure out how well this works in practice.
-- greg
^ permalink raw reply
* Question: mvista kernel ... how do i enable SCC1 for enet
From: James Don @ 2002-12-17 23:00 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
Hi,
I have my kernel running with SMC1 UART support and would now like to add
SCC1 support.
FYI: My platform is based on a FADS board ... but some of my SCC pins have
moved.
1.) What kernel modules do I need to enable to get ENET on SCC1? I have
added basic network support ... but see no SCC1 under CPM settings ... is it
there by default ...
2.) Do I have to change anything in the kernel to accommodate my new SCC
pins?
As always thanks for the assistance!
Jim
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Andrew Morton @ 2002-12-17 22:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Justin T. Gibbs, linux-scsi
In-Reply-To: <20021217223341.A26529@infradead.org>
Christoph Hellwig wrote:
>
> On Tue, Dec 17, 2002 at 05:24:59PM -0500, Doug Ledford wrote:
> > Well, that or I need Jens to clean up the block layer allocation code so
> > that it only allocates one request at block queue init time and from then
> > on does lazy request allocations once the device needs them, similar to
> > what I did with the scsi command blocks.
>
> What do you think about forward-porting akpm's blk_grow_request_list()
> changes in 2.4? I could do that easily and it should help to get this
> sorted out properly.
>
wakes up.
I think (hope) the plan there is to do away with the preallocated
per-queue request lists altogether. Just allocate the requests
direct from slab at __make_request().
The request slab would have to be backed by a (small) mempool of
course. get_request_wait() should disappear, and management of
the amount of memory which is under IO is moved up to the VM layer.
This means that we have basically no upper bound on the amount of
memory which can be placed under I/O. Which used to give the VM
a heart-attack, but it should be OK for writes now. If not I'll
fix it up. There could be issues with reads and direct-IO.
The rbtree elevator becomes compulsory with such potentially-large
queues, but that's working fine.
^ permalink raw reply
* Re: mac address change on an eth alias
From: Ray Olszewski @ 2002-12-17 22:53 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <02121722061606.00388@unix.pa3gcu>
At 10:06 PM 12/17/02 +0000, pa3gcu wrote:
>On Tuesday 17 December 2002 21:55, Petre Bandac wrote:
>[...]
> > so I didn't get what I wanted - the mac of the alias being different than
> > the interface's; should I presume "no can do" ?
>
>I myself have never used aliasing, i do however need to spoof my MAC
>sometimes on my laptop to be able to use it on other locations for my work.
>However thats beside the point, as far as i can see if you set a different
>IP# then the need for another MAC is (AFAIK) not nessasary.
>If ARP's are a problem then setting static arps may be an answer, once more i
>have no experiance with alising, possably Ray may have some advise for you.
Afraid not; I've never actually used aliasing (except in trivial test setups).
Perhaps the best next step would be for you to explain why you need the
interfaces to respond as though they were on different physical devices
(that is, NICs with distinct MAC addresses). With that information, then
maybe someone here could suggest a workaround. But as far as I know, NICs
only support a single MAC address at any moment, not multiple ones.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [ANNOUNCE] Intel PRO/100 software developer manual released
From: Jeff Garzik @ 2002-12-17 22:59 UTC (permalink / raw)
To: Feldman, Scott; +Cc: linux-kernel, netdev, LOSTeam
In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758F6C@orsmsx113.jf.intel.com>
Feldman, Scott wrote:
> Available at https://sourceforge.net/projects/e1000.
>
> The full title is:
>
> Intel 8255x 10/100 Mbps Ethernet Controller Family
> Open Source Software Developer Manual
> Revision 1.0
>
> The manual is intended to support the maintenance of the e100 driver (or the
> best driver for the PRO/100 networking hardware ;-). The manual covers the
> 82557, 82558, 82559, 82550, and 82551 Ethernet controllers.
>
> I would like to thank Jeff Garzik for encouraging this publication, and for
> having the patience to deal with the Intel machine.
I'm surprised that this David (me) actually got through to the Goliath :)
Let me publicly thank Intel NIC team [and related persons] for some
great work. You guys have really been responsive both to technical
issues and also political/community-related issues like this one of
opening docs.
This is a situation where I really think that opening docs will lead to
a better overall user experience with Intel hardware on Linux, and
hopefully serves as a model for other vendors to follow.
Thanks and kudos, Intel!
Jeff
^ permalink raw reply
* Re: 2.5.52 compile error
From: eric lin @ 2002-12-18 7:00 UTC (permalink / raw)
To: James Simmons; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212172152350.24589-100000@phoenix.infradead.org>
James Simmons wrote:
>>All of these options are modules in my config file, *must* they be built
>>into the kernel in order to compile?
>
>
> Yes!!! I have a patch for fixing this issue.
>
> You can import this changeset into BK by piping this whole message to:
> '| bk receive [path to repository]' or apply the patch as usual.
>
> ===================================================================
>
>
> ChangeSet@1.868, 2002-12-10 12:07:45-08:00, jsimmons@kozmo.(none)
> The VT tty layer depends on the input api now. Fixed this dependency.
>
>
> Kconfig | 1 +
> 1 files changed, 1 insertion(+)
>
>
> diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig
> --- a/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
> +++ b/drivers/char/Kconfig Tue Dec 10 12:16:48 2002
> @@ -6,6 +6,7 @@
>
> config VT
> bool "Virtual terminal"
> + depends on INPUT=y
> ---help---
> If you say Y here, you will get support for terminal devices with
> display and keyboard devices. These are called "virtual" because you
>
> ===================================================================
>
>
> This BitKeeper patch contains the following changesets:
I copied this piece as patch1.tar.gz
--------------------------------------------------------------
> +
> ## Wrapped with gzip_uu ##
>
>
> begin 664 bkpatch6044
> M'XL(`+!+]CT``]54VVH;,1!]MKYB("\MQ;NZ[,T+6]RFEX24UKA.7TH?A';L
> MW=@KF97L9,-^?&6[N1!,H*5]J"X(9H;#F3D'G<"EQ38?7-FZ:8RVY`3.C'7Y
> M8&EN&Q.\T$;C2Q^<&N.#X<:VH6U5N*KUYF98Z_7&$9^=2*<JV&)K\P$+Q'W$
> M=6O,!]/W'R\_O9D24A1P6DF]P*_HH"B(,^U6KDH[EJY:&1VX5FK;H).!,DU_
> M7]IS2KG?,4L%C9.>)31*>\5*QF3$L*0\RI*(W+4P?DS]"0KCC+)1%,6C7B24
> M"?(.6)`E&5`>,G\H,)[3-(_B(<UR2N$H*+QB,*3D+?S=!DZ)@EF%\&T&SG6P
> MDAVV4.(:=6G!:'`^MQ\YR'4-VEP'\*&^P=(G:ONK$+7J`B`7(.(TC<CD8>!D
> M^)N+$"HI>0VW]7J-J_%!\B;)EH%I%]_O6O_1EVV]4SY4E6S#"V7TO%X<ADT%
> MI9'@/.LYIUG6BU0D*.99R>>E$!R/3_<90`_IWY1Y]40<97M'':O>F>O?T2:E
> MW.+56)D2/?DE=COD8+-\!I)Q?^/$JR[8B!]L)YZ:CHW^>]/M5?D"P_9Z?[R)
> L)D<%^@,SGF?`R.`1L_//D\M9T3W\/ZI"M;2;IE!2\7B$2'X"W[RZ@MX$````
> `
> end
>
-------------------------------------------------------------------
then in my /linux-2.5.52/
fsshl@www:~/linux-2.5.52$ gzip -cd patch1.tar.gz | patch -p1
patch: **** Only garbage was found in the patch input.
Please help
>
> -
> 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/
>
>
--
Sincere Eric
www.linuxspice.com
linux pc for sale
^ permalink raw reply
* RE: [PATCH] kNFSd - 2 of 7 - Revlaidate inodes after filehandle and name lookup in nfsd
From: Neil Brown @ 2002-12-17 22:50 UTC (permalink / raw)
To: Irina Slutsky; +Cc: nfs, 'Brian Dixon'
In-Reply-To: <000201c2a5d9$adcec250$6902a8c0@Iralaptop>
On Tuesday December 17, ira@ibrix.com wrote:
> Thanks for this patch. Problem, this patch is addressing is very
> important for me. This is the behaviors I am missing and is trying to
> work around. When do you think this patch can be incorporated in the
> official kernel release?
Hopefully in 2.4.21, whenever that comes out.
>
> Small note: there is an inline routine
> do_reavlidate(struct denty *) in the kernel
> that could be used instead. It has all the "if"s checking inside.
So there is... but it is in lots of .c files and no .h's.
I guess I could copy it but I don't know that it is worth it.
>
> I also have a question on the same topic:
>
> Is there any particular reason for not allowing a fs to create file
> handle for exported entry? I know the code is easier this way, but it
> would be very useful.
It isn't so much that it is not "allowed", but rather that it is not
"required". knfsd can find the file without any help from the
filesystem, so it doesn't even both to ask.
How would it be useful to you if it did?
NeilBrown
-------------------------------------------------------
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/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: PATCH
From: Pete Popov @ 2002-12-17 22:51 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg Lindahl, linux-mips
In-Reply-To: <1040167450.20804.30.camel@irongate.swansea.linux.org.uk>
On Tue, 2002-12-17 at 15:24, Alan Cox wrote:
> On Tue, 2002-12-17 at 22:40, Pete Popov wrote:
> > It would be if there was a generic way to go about adding support for
> > graphics cards that require bios support. In this case we were working
> > with the manufacturer and had all the docs, but still couldn't figure
> > out certain pieces needed in initializing the card. Ultimately the "no
> > bios init" patch you see is a pci bus analyzer capture, filtered through
> > a perl script, dumped into a new file, and integrated as part of the
> > driver. Even if you could do that with all cards, I'm not sure it's
> > legally allowed. We had the vendor's blessings in this case.
>
> XFree86 has an emulator library for this.
Thanks; I didn't know that.
One of the problems with these graphics cards is that they are end of
life before you finish writing the driver. I still have a few RageXL
cards in the office, but you can't even buy them in the store anymore.
Pete
^ permalink raw reply
* Re: detecting layout in RAID
From: Neil Brown @ 2002-12-17 22:55 UTC (permalink / raw)
To: Anu; +Cc: linux-kernel
In-Reply-To: <Pine.GSO.4.44.0212121507430.3980-100000@sun.cesr.ncsu.edu>
On Thursday December 12, avaidya@unity.ncsu.edu wrote:
> hello,
> I am trying to detect layouts of the RAID configuration (I have a
> software RAID set up. ) Mine is currently left symmetric and the way I am
> trying to detect layout is to reaad consecutive blocks and look for
> whether there is a big dp when it has to move all the way across..
What exactly do you mean by "move all the way across"?
The only things that move are the drive which spins and the heads
which move back and forth.
I suspect that the way to detect differences in layout is to do lots
of random reads of different block sizes and look for different
throughput.
NeilBrown
^ permalink raw reply
* Re: 2.5.52 compile error
From: Bob Miller @ 2002-12-17 22:54 UTC (permalink / raw)
To: eric lin; +Cc: linux-kernel
In-Reply-To: <3E001825.7080709@centurytel.net>
On Tue, Dec 17, 2002 at 11:39:33PM -0700, eric lin wrote:
> Bob Miller wrote:
> >On Tue, Dec 17, 2002 at 03:57:01PM -0500, rtilley wrote:
> >
> >>Using RH's default *i686.config to build a vanilla 2.5.52 kernel. It
> >>keeps returning this error on 2 totally different x86 PCs:
> >>
> >>
Stuff deleted.
> >>
> >>
> >>Where is the fix for this?
> >>
> >
> >At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
> >off the main page.
> I did not know what is that mean (off the man page)?
> >
> Is that at menuconfig
> or
> should modify any source code?
>
Yes it is at off the first page of "make menuconfig".
--
Bob Miller Email: rem@osdl.org
Open Source Development Lab Phone: 503.626.2455 Ext. 17
^ permalink raw reply
* Re: PATCH
From: Alan Cox @ 2002-12-17 23:24 UTC (permalink / raw)
To: Pete Popov; +Cc: Greg Lindahl, linux-mips
In-Reply-To: <1040164850.16501.18.camel@zeus.mvista.com>
On Tue, 2002-12-17 at 22:40, Pete Popov wrote:
> It would be if there was a generic way to go about adding support for
> graphics cards that require bios support. In this case we were working
> with the manufacturer and had all the docs, but still couldn't figure
> out certain pieces needed in initializing the card. Ultimately the "no
> bios init" patch you see is a pci bus analyzer capture, filtered through
> a perl script, dumped into a new file, and integrated as part of the
> driver. Even if you could do that with all cards, I'm not sure it's
> legally allowed. We had the vendor's blessings in this case.
XFree86 has an emulator library for this.
^ permalink raw reply
* Re: MSN helper module
From: Filip Sneppe (Cronos) @ 2002-12-17 22:38 UTC (permalink / raw)
To: Carlos Fernandez Sanz; +Cc: netfilter-devel, Michael Richardson
In-Reply-To: <001701c2a615$cc774dd0$152ea8c0@maincomp>
hi Carlos,
On Tue, 2002-12-17 at 22:46, Carlos Fernandez Sanz wrote:
> Thanks for the links. I have done some research already. I don't think it's
> going to be a weekend project but possibly not a lot more :-) Anyway I don't
> really have an option. It's starting to escalate...
Good to hear that we may have an additional netfilter module soon !
> BTW, when you started to work on this, did you take a look at the FTP
> module? I think it solves most of the problems (including security), since
> the connection method is identical to an active (PORT initiated) FTP data
> connection.
I think I heard Rusty explain how he dealt with this during some netfilter
talk, I think. IIRC, with ftp there are "end-of-line" markers before
or after the PORT/PASV commands that allow the module to distinguish
them from weird filenames in the control channel. That's the only
protection mechanism I heard of for the ftp conntrackers.
With MSN, it's a little trickier:
A normal messaging command looks like this:
MSG 3 A 157
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-MMS-IM-Format: FN=Microsoft%20Sans%20Serif; EF=I; CO=000000; CS=0;
PF=22
Hello! How are you?
where the "157" is a length indicator (including header). Now the 157
bytes minus header that follow this can be anything: end-of-line
characters, and stuff that looks like "MSG 4 A 140<cr>".
What the module shouldn't do, is get confused by this "user-supplied"
content and start interpreting it. Otherwise, if a user supplied:
MSG 4 N 238
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; charset=UTF-8
Invitation-Command: ACCEPT
Invitation-Cookie: 33267
IP-Address: 10.44.102.65
Port: 6891
AuthCookie: 93301
Launch-Application: FALSE
Request-Data: IP-Address:
as the content of a MSG message, it would create a security problem.
So I guess you need to do something like this:
- Parse the first data packet, assuming that you're not parsing
a packet from a "messaging" session, because that could already
contain spoofed data.
- If you encounter a "MSG 4 N xxx" message in the MSN header, check
the rest of the header for the "Content-Type: text/x-msmsgsinvite"
string. If that's present, it's an MSN file transfer request.
go from there to add the expectation.
- If you encounter a "MSG 4 N xxx" message without the
"Content-Type: text/x-msmsgsinvite" stuff in the MSN header,
you should ignore the xxx bytes of that MSN packet (and possibly
the following packets if xxx >> MTU) and not parse it at all:
it's just user supplied data.
- I think you'll need to keep track of that MSG length field
inside some ip_ct_msn_master to keep track of it accross
various packets. I don't know if your module has to deal with
out of order packets, ...
- Possibly you could do even stricter checking by watching the
Invitation cookies etc.
Does this sound correct ?
Regards,
Filip
^ permalink raw reply
* Re: PATCH
From: Pete Popov @ 2002-12-17 22:40 UTC (permalink / raw)
To: Greg Lindahl; +Cc: linux-mips
In-Reply-To: <20021217142913.A1921@wumpus.internal.keyresearch.com>
On Tue, 2002-12-17 at 14:29, Greg Lindahl wrote:
> On Fri, Dec 13, 2002 at 08:52:47PM -0800, Pete Popov wrote:
>
> > This patch was sent to the RageXL maintainer but I don't think he was
> > interested in it. Others might find it useful on embedded systems. It
> > initializes the RageXL card when there is no system bios to initialize
> > it from the video bios. Tested on the Pb1500; makes a really good
> > workstation.
>
> Pete,
>
> Is there a website with info about graphics cards on non-x86
> architectures?
Not that I know of personally.
> Most cards require their own BIOS to be run at boot
> time. This issue ought to be of interest to lots of other communities
> than MIPS.
It would be if there was a generic way to go about adding support for
graphics cards that require bios support. In this case we were working
with the manufacturer and had all the docs, but still couldn't figure
out certain pieces needed in initializing the card. Ultimately the "no
bios init" patch you see is a pci bus analyzer capture, filtered through
a perl script, dumped into a new file, and integrated as part of the
driver. Even if you could do that with all cards, I'm not sure it's
legally allowed. We had the vendor's blessings in this case.
Pete
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Christoph Hellwig @ 2002-12-17 22:33 UTC (permalink / raw)
To: Justin T. Gibbs, linux-scsi
In-Reply-To: <20021217222459.GD28100@redhat.com>
On Tue, Dec 17, 2002 at 05:24:59PM -0500, Doug Ledford wrote:
> Well, that or I need Jens to clean up the block layer allocation code so
> that it only allocates one request at block queue init time and from then
> on does lazy request allocations once the device needs them, similar to
> what I did with the scsi command blocks.
What do you think about forward-porting akpm's blk_grow_request_list()
changes in 2.4? I could do that easily and it should help to get this
sorted out properly.
^ permalink raw reply
* [PATCH] (v3) move LOG_BUF_SIZE to header/config
From: Randy.Dunlap @ 2002-12-17 22:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3DFF5E67.C0BA874C@digeo.com>
Changes from yesterday:
a. use a shift value (suggested by HCH); probably still not as quite
as free and open as he suggested, but I had user-friendliness
problems with that.
b. allow a wider range of values (HCH and James Cloos):
smaller added, larger can be added as needed.
c. put common config into kernel/Kconfig and include that in each
arch/*/Kconfig
More comments?
--
~Randy
patch_name: logbuf-config-2552.patch
patch_version: 2002.12.17
author: Randy Dunlap <rddunlap@osdl.org>
description: change LOG_BUF_SIZE to a config option (LOG_BUF_SHIFT)
product: linux
product_versions: 2.5.52
changelog: (a) move to a common kernel/Kconfig;
(b) use a SHIFT value (enforces power of 2, gives more choices)
URL:
requires: kconfig in 2.5.52
conflicts:
diffstat:
arch/alpha/Kconfig | 2 +
arch/arm/Kconfig | 2 +
arch/cris/Kconfig | 2 +
arch/ia64/Kconfig | 3 ++
arch/m68k/Kconfig | 2 +
arch/m68knommu/Kconfig | 2 +
arch/mips/Kconfig | 2 +
arch/mips64/Kconfig | 2 +
arch/parisc/Kconfig | 2 +
arch/ppc/Kconfig | 2 +
arch/ppc64/Kconfig | 2 +
arch/s390/Kconfig | 2 +
arch/s390x/Kconfig | 2 +
arch/sh/Kconfig | 2 +
arch/sparc/Kconfig | 2 +
arch/sparc64/Kconfig | 2 +
arch/um/Kconfig | 2 +
arch/v850/Kconfig | 2 +
arch/x86_64/Kconfig | 2 +
kernel/Kconfig | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
kernel/printk.c | 11 ---------
21 files changed, 95 insertions(+), 10 deletions(-)
--- ./arch/m68k/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/m68k/Kconfig Tue Dec 17 14:08:33 2002
@@ -2346,3 +2346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc/Kconfig%LOGBUF Sun Dec 15 18:07:42 2002
+++ ./arch/sparc/Kconfig Tue Dec 17 14:11:06 2002
@@ -1422,3 +1422,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc64/Kconfig%LOGBUF Sun Dec 15 18:08:16 2002
+++ ./arch/sparc64/Kconfig Tue Dec 17 14:11:13 2002
@@ -1710,3 +1710,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ppc/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/ppc/Kconfig Tue Dec 17 14:10:18 2002
@@ -1872,3 +1872,5 @@
source "crypto/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/m68knommu/Kconfig%LOGBUF Sun Dec 15 18:08:13 2002
+++ ./arch/m68knommu/Kconfig Tue Dec 17 14:08:52 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/alpha/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/alpha/Kconfig Tue Dec 17 14:07:34 2002
@@ -1030,3 +1030,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/cris/Kconfig%LOGBUF Sun Dec 15 18:08:19 2002
+++ ./arch/cris/Kconfig Tue Dec 17 14:08:06 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/mips/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/mips/Kconfig Tue Dec 17 14:08:59 2002
@@ -1284,3 +1284,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/x86_64/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/x86_64/Kconfig Tue Dec 17 14:11:54 2002
@@ -700,3 +700,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ppc64/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/ppc64/Kconfig Tue Dec 17 14:10:25 2002
@@ -559,3 +559,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/um/Kconfig%LOGBUF Sun Dec 15 18:07:57 2002
+++ ./arch/um/Kconfig Tue Dec 17 14:11:35 2002
@@ -171,3 +171,5 @@
endmenu
+source "kernel/Kconfig"
+
--- ./arch/arm/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/arm/Kconfig Tue Dec 17 14:07:56 2002
@@ -1228,3 +1228,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/parisc/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/parisc/Kconfig Tue Dec 17 14:10:11 2002
@@ -423,3 +423,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ia64/Kconfig%LOGBUF Sun Dec 15 18:08:21 2002
+++ ./arch/ia64/Kconfig Tue Dec 17 14:08:24 2002
@@ -891,3 +891,6 @@
source "security/Kconfig"
source "crypto/Kconfig"
+
+source "kernel/Kconfig"
+
--- ./arch/mips64/Kconfig%LOGBUF Sun Dec 15 18:07:52 2002
+++ ./arch/mips64/Kconfig Tue Dec 17 14:09:07 2002
@@ -727,3 +727,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390x/Kconfig%LOGBUF Sun Dec 15 18:07:59 2002
+++ ./arch/s390x/Kconfig Tue Dec 17 14:10:41 2002
@@ -346,3 +346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/v850/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/v850/Kconfig Tue Dec 17 14:11:46 2002
@@ -452,4 +452,6 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
#############################################################################
--- ./arch/sh/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/sh/Kconfig Tue Dec 17 14:10:52 2002
@@ -1276,3 +1276,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390/Kconfig%LOGBUF Sun Dec 15 18:07:54 2002
+++ ./arch/s390/Kconfig Tue Dec 17 14:10:33 2002
@@ -337,3 +337,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./kernel/Kconfig%LOGBUF Tue Dec 17 14:00:31 2002
+++ ./kernel/Kconfig Tue Dec 17 14:16:36 2002
@@ -0,0 +1,55 @@
+# This general setup config file is read _after_ all other config files.
+# It is for generic kernel options that cannot be handled elsewhere,
+# including some generic options that are processor-dependent.
+# This is also _not_ for device driver options.
+# They should be handled in their driver subsystem areas.
+
+menu "Common kernel setup (more)"
+
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_SHIFT_17 if ARCH_S390
+ default LOG_BUF_SHIFT_16 if X86_NUMAQ || IA64
+ default LOG_BUF_SHIFT_15 if SMP
+ default LOG_BUF_SHIFT_14
+ help
+ Select kernel log buffer size from this list (power of 2).
+ Defaults: 17 (=> 128 KB for S/390)
+ 16 (=> 64 KB for x86 NUMAQ or IA-64)
+ 15 (=> 32 KB for SMP)
+ 14 (=> 16 KB for uniprocessor)
+
+config LOG_BUF_SHIFT_17
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_SHIFT_16
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_SHIFT_15
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_SHIFT_14
+ bool "16 KB"
+
+config LOG_BUF_SHIFT_13
+ bool "8 KB"
+
+config LOG_BUF_SHIFT_12
+ bool "4 KB"
+
+endchoice
+
+config LOG_BUF_SHIFT
+ int
+ default 17 if LOG_BUF_SHIFT_17=y
+ default 16 if LOG_BUF_SHIFT_16=y
+ default 15 if LOG_BUF_SHIFT_15=y
+ default 14 if LOG_BUF_SHIFT_14=y
+ default 13 if LOG_BUF_SHIFT_13=y
+ default 12 if LOG_BUF_SHIFT_12=y
+
+endmenu
+
--- ./kernel/printk.c%LOGBUF Sun Dec 15 18:08:24 2002
+++ ./kernel/printk.c Tue Dec 17 14:01:50 2002
@@ -30,16 +30,7 @@
#include <asm/uaccess.h>
-#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
-#define LOG_BUF_LEN (65536)
-#elif defined(CONFIG_ARCH_S390)
-#define LOG_BUF_LEN (131072)
-#elif defined(CONFIG_SMP)
-#define LOG_BUF_LEN (32768)
-#else
-#define LOG_BUF_LEN (16384) /* This must be a power of two */
-#endif
-
+#define LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
#ifndef arch_consoles_callable
^ 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.