[uPATCH] a logitech mouse ID
Adds the ID to recognise my PS/2 TrackMan Marble.
This is purely cosmetic: this is standard 3-button, no wheel or other
such features, so it already _worked_ just fine. This patch suppresses
a warning about the unknown model, and changes the printk from "Mouse"
to "TrackMan".
Signed-Off-By: Peter Samuelson <[EMAIL PROTECTED]>
--- drivers/input/mouse/logips2pp.c
+++ drivers/input/mouse/logips2pp.c
@@ -220,6 +220,7 @@
{ 66, PS2PP_KIND_MX, /*
MX3100 reciver */
PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
PS2PP_EXTRA_BTN | PS2PP_NAV_BTN | PS2PP_HWHEEL
},
+ { 72, PS2PP_KIND_TRACKMAN,0 },/*
T-CH11: TrackMan Marble */
{ 73, 0, PS2PP_SIDE_BTN },
{ 75, PS2PP_KIND_WHEEL, PS2PP_WHEEL },
{ 76, PS2PP_KIND_WHEEL, PS2PP_WHEEL },
signature.asc
Description: Digital signature
[uPATCH] a logitech mouse ID
Adds the ID to recognise my PS/2 TrackMan Marble.
This is purely cosmetic: this is standard 3-button, no wheel or other
such features, so it already _worked_ just fine. This patch suppresses
a warning about the unknown model, and changes the printk from Mouse
to TrackMan.
Signed-Off-By: Peter Samuelson [EMAIL PROTECTED]
--- drivers/input/mouse/logips2pp.c
+++ drivers/input/mouse/logips2pp.c
@@ -220,6 +220,7 @@
{ 66, PS2PP_KIND_MX, /*
MX3100 reciver */
PS2PP_WHEEL | PS2PP_SIDE_BTN | PS2PP_TASK_BTN |
PS2PP_EXTRA_BTN | PS2PP_NAV_BTN | PS2PP_HWHEEL
},
+ { 72, PS2PP_KIND_TRACKMAN,0 },/*
T-CH11: TrackMan Marble */
{ 73, 0, PS2PP_SIDE_BTN },
{ 75, PS2PP_KIND_WHEEL, PS2PP_WHEEL },
{ 76, PS2PP_KIND_WHEEL, PS2PP_WHEEL },
signature.asc
Description: Digital signature
[powerpc] RS/6000 43p-150 no longer boots as of 2.6.18
I know this is a bit late to be reporting this, as it happened before 2.6.18, but my PowerPC CHRP machine (RS/6000 43p-150, 604e CPU) no longer boots. From the console: instantiating rtas at 0x1ffe5000 ... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x008dc000 -> 0x008dcd97 Device tree struct 0x008dd000 -> 0x008e2000 Calling quiesce ... returning from prom_init ...and here it hangs. This happened between 2.6.17-git21 and -git22. .config is attached. I'd be happy to test patches and provide more information. Thanks, Peter # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17-git21 # Sat Feb 3 23:58:54 2007 # # CONFIG_PPC64 is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # CONFIG_CLASSIC32=y # CONFIG_PPC_52xx is not set # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_86xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_8xx is not set # CONFIG_E200 is not set CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-wire" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_ISERIES is not set # CONFIG_EMBEDDED6xx is not set # CONFIG_APUS is not set CONFIG_PPC_CHRP=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_MPIC=y CONFIG_PPC_RTAS=y # CONFIG_RTAS_ERROR_LOGGING is not set CONFIG_RTAS_PROC=y # CONFIG_MMIO_NVRAM is not set CONFIG_PPC_MPC106=y # CONFIG_PPC_970_NAP is not set # CONFIG_CPU_FREQ is not set CONFIG_TAU=y # CONFIG_TAU_INT is not set # CONFIG_TAU_AVERAGE is not set # CONFIG_WANT_EARLY_SERIAL is not set # # Kernel options # # CONFIG_HIGHMEM is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_KEXEC is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_PROC_DEVICETREE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="console=ttyS0,9600 console=tty0 root=/dev/hda1" CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_I8259=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Advanced setup # # CONFIG_ADVANCED_OPTIONS is not set # # Default settings
[powerpc] RS/6000 43p-150 no longer boots as of 2.6.18
I know this is a bit late to be reporting this, as it happened before 2.6.18, but my PowerPC CHRP machine (RS/6000 43p-150, 604e CPU) no longer boots. From the console: instantiating rtas at 0x1ffe5000 ... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x008dc000 - 0x008dcd97 Device tree struct 0x008dd000 - 0x008e2000 Calling quiesce ... returning from prom_init ...and here it hangs. This happened between 2.6.17-git21 and -git22. .config is attached. I'd be happy to test patches and provide more information. Thanks, Peter # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17-git21 # Sat Feb 3 23:58:54 2007 # # CONFIG_PPC64 is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # CONFIG_CLASSIC32=y # CONFIG_PPC_52xx is not set # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_86xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_8xx is not set # CONFIG_E200 is not set CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-wire # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_ISERIES is not set # CONFIG_EMBEDDED6xx is not set # CONFIG_APUS is not set CONFIG_PPC_CHRP=y # CONFIG_PPC_PMAC is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_MPIC=y CONFIG_PPC_RTAS=y # CONFIG_RTAS_ERROR_LOGGING is not set CONFIG_RTAS_PROC=y # CONFIG_MMIO_NVRAM is not set CONFIG_PPC_MPC106=y # CONFIG_PPC_970_NAP is not set # CONFIG_CPU_FREQ is not set CONFIG_TAU=y # CONFIG_TAU_INT is not set # CONFIG_TAU_AVERAGE is not set # CONFIG_WANT_EARLY_SERIAL is not set # # Kernel options # # CONFIG_HIGHMEM is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_KEXEC is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_PROC_DEVICETREE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE=console=ttyS0,9600 console=tty0 root=/dev/hda1 CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_I8259=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Advanced setup # # CONFIG_ADVANCED_OPTIONS is not set # # Default settings for
Re: [uPATCH] cross-compile scripts/lxdialog/ on AIX
[Peter Samuelson] > AIX curses.h defines macros 'clear_screen' and 'color_names' but does > not define 'scroll()'. I should mention that 'make menuconfig' on AIX 4.3 also required 'ln -s libxcurses.a /usr/lib/libncurses.a' but a patch to detect *that* seemed too intrusive to be worthwhile. Also, color escapes are all messed up and I don't know why, but I blame AIX's funky terminfo. Peter signature.asc Description: Digital signature
Re: [uPATCH] cross-compile scripts/lxdialog/ on AIX
[Peter Samuelson] AIX curses.h defines macros 'clear_screen' and 'color_names' but does not define 'scroll()'. I should mention that 'make menuconfig' on AIX 4.3 also required 'ln -s libxcurses.a /usr/lib/libncurses.a' but a patch to detect *that* seemed too intrusive to be worthwhile. Also, color escapes are all messed up and I don't know why, but I blame AIX's funky terminfo. Peter signature.asc Description: Digital signature
[uPATCH] cross-compile scripts/lxdialog/ on AIX
AIX curses.h defines macros 'clear_screen' and 'color_names' but does
not define 'scroll()'.
Signed-Off-By: Peter Samuelson <[EMAIL PROTECTED]>
diff -urN 2.6.11-rc5/scripts/lxdialog/checklist.c.old
2.6.11-rc5/scripts/lxdialog/checklist.c
--- 2.6.11-rc5/scripts/lxdialog/checklist.c.old 2005-02-27 00:49:00.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/checklist.c 2005-02-27 01:01:17.0
-0600
@@ -269,7 +269,7 @@
status[scroll + max_choice - 1],
max_choice - 1, FALSE);
scrollok (list, TRUE);
- scroll (list);
+ wscrl (list, 1);
scrollok (list, FALSE);
}
scroll++;
diff -urN 2.6.11-rc5/scripts/lxdialog/colors.h.old
2.6.11-rc5/scripts/lxdialog/colors.h
--- 2.6.11-rc5/scripts/lxdialog/colors.h.old2004-02-03 21:43:07.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/colors.h2005-02-27 01:45:28.0
-0600
@@ -152,10 +152,4 @@
* Global variables
*/
-typedef struct {
-char name[COLOR_NAME_LEN];
-int value;
-} color_names_st;
-
-extern color_names_st color_names[];
extern int color_table[][3];
diff -urN 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old
2.6.11-rc5/scripts/lxdialog/lxdialog.c
--- 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old 2004-02-03 21:43:57.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/lxdialog.c 2005-02-27 01:31:11.0
-0600
@@ -56,7 +56,7 @@
int
main (int argc, const char * const * argv)
{
-int offset = 0, clear_screen = 0, end_common_opts = 0, retval;
+int offset = 0, opt_clear = 0, end_common_opts = 0, retval;
const char *title = NULL;
#ifdef LOCALE
@@ -89,7 +89,7 @@
offset += 2;
}
} else if (!strcmp (argv[offset + 1], "--clear")) {
- if (clear_screen) { /* Hey, "--clear" can't appear twice! */
+ if (opt_clear) {/* Hey, "--clear" can't appear twice! */
Usage (argv[0]);
exit (-1);
} else if (argc == 2) { /* we only want to clear the screen */
@@ -98,7 +98,7 @@
end_dialog ();
return 0;
} else {
- clear_screen = 1;
+ opt_clear = 1;
offset++;
}
} else /* no more common options */
@@ -127,7 +127,7 @@
init_dialog ();
retval = (*(modePtr->jumper)) (title, argc - offset, argv + offset);
-if (clear_screen) {/* clear screen before exit */
+if (opt_clear) { /* clear screen before exit */
attr_clear (stdscr, LINES, COLS, screen_attr);
refresh ();
}
diff -urN 2.6.11-rc5/scripts/lxdialog/menubox.c.old
2.6.11-rc5/scripts/lxdialog/menubox.c
--- 2.6.11-rc5/scripts/lxdialog/menubox.c.old 2005-02-27 00:23:54.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/menubox.c 2005-02-27 01:32:08.0
-0600
@@ -327,7 +327,7 @@
) {
/* Scroll menu up */
scrollok (menu, TRUE);
-scroll (menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
@@ -357,7 +357,7 @@
for (i=0; (i < max_choice); i++) {
if (scroll+max_choice < item_no) {
scrollok (menu, TRUE);
- scroll(menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
print_item (menu, items[(scroll+max_choice-1)*2+1],
signature.asc
Description: Digital signature
[uPATCH] cross-compile scripts/lxdialog/ on AIX
AIX curses.h defines macros 'clear_screen' and 'color_names' but does
not define 'scroll()'.
Signed-Off-By: Peter Samuelson [EMAIL PROTECTED]
diff -urN 2.6.11-rc5/scripts/lxdialog/checklist.c.old
2.6.11-rc5/scripts/lxdialog/checklist.c
--- 2.6.11-rc5/scripts/lxdialog/checklist.c.old 2005-02-27 00:49:00.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/checklist.c 2005-02-27 01:01:17.0
-0600
@@ -269,7 +269,7 @@
status[scroll + max_choice - 1],
max_choice - 1, FALSE);
scrollok (list, TRUE);
- scroll (list);
+ wscrl (list, 1);
scrollok (list, FALSE);
}
scroll++;
diff -urN 2.6.11-rc5/scripts/lxdialog/colors.h.old
2.6.11-rc5/scripts/lxdialog/colors.h
--- 2.6.11-rc5/scripts/lxdialog/colors.h.old2004-02-03 21:43:07.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/colors.h2005-02-27 01:45:28.0
-0600
@@ -152,10 +152,4 @@
* Global variables
*/
-typedef struct {
-char name[COLOR_NAME_LEN];
-int value;
-} color_names_st;
-
-extern color_names_st color_names[];
extern int color_table[][3];
diff -urN 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old
2.6.11-rc5/scripts/lxdialog/lxdialog.c
--- 2.6.11-rc5/scripts/lxdialog/lxdialog.c.old 2004-02-03 21:43:57.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/lxdialog.c 2005-02-27 01:31:11.0
-0600
@@ -56,7 +56,7 @@
int
main (int argc, const char * const * argv)
{
-int offset = 0, clear_screen = 0, end_common_opts = 0, retval;
+int offset = 0, opt_clear = 0, end_common_opts = 0, retval;
const char *title = NULL;
#ifdef LOCALE
@@ -89,7 +89,7 @@
offset += 2;
}
} else if (!strcmp (argv[offset + 1], --clear)) {
- if (clear_screen) { /* Hey, --clear can't appear twice! */
+ if (opt_clear) {/* Hey, --clear can't appear twice! */
Usage (argv[0]);
exit (-1);
} else if (argc == 2) { /* we only want to clear the screen */
@@ -98,7 +98,7 @@
end_dialog ();
return 0;
} else {
- clear_screen = 1;
+ opt_clear = 1;
offset++;
}
} else /* no more common options */
@@ -127,7 +127,7 @@
init_dialog ();
retval = (*(modePtr-jumper)) (title, argc - offset, argv + offset);
-if (clear_screen) {/* clear screen before exit */
+if (opt_clear) { /* clear screen before exit */
attr_clear (stdscr, LINES, COLS, screen_attr);
refresh ();
}
diff -urN 2.6.11-rc5/scripts/lxdialog/menubox.c.old
2.6.11-rc5/scripts/lxdialog/menubox.c
--- 2.6.11-rc5/scripts/lxdialog/menubox.c.old 2005-02-27 00:23:54.0
-0600
+++ 2.6.11-rc5/scripts/lxdialog/menubox.c 2005-02-27 01:32:08.0
-0600
@@ -327,7 +327,7 @@
) {
/* Scroll menu up */
scrollok (menu, TRUE);
-scroll (menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
@@ -357,7 +357,7 @@
for (i=0; (i max_choice); i++) {
if (scroll+max_choice item_no) {
scrollok (menu, TRUE);
- scroll(menu);
+ wscrl (menu, 1);
scrollok (menu, FALSE);
scroll++;
print_item (menu, items[(scroll+max_choice-1)*2+1],
signature.asc
Description: Digital signature
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
[Kai Germaschewski] > However, I don't think it's hard to verify that my patch works as > well, it's about ten lines added to Rules.make. It's particularly > easy to verify that it doesn't change behavior for objects listed in > $(list-multi) at all. Yes, we can say this, but people are right to be paranoid. Remember that the first version of your patch (several months ago) required a particular version of GNU Make I submitted a cleanup patch for 2.2.18pre that was 100% safe in that it just made use of a script that was already in the tree (scripts/kwhich). But sure enough, it broke for users of older Red Hat installations who were still on bash 1.x. It seems scripts/kwhich hadn't been used that way before, so nobody had noticed that it didn't work with bash 1. That said, I think your current version is in fact bug-free and if it were up to me I would put it in the tree. But I also understand why others are hesitant to trust it. The bugs it fixes are fairly minor, after all. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
[Kai Germaschewski] However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. Yes, we can say this, but people are right to be paranoid. Remember that the first version of your patch (several months ago) required a particular version of GNU Make I submitted a cleanup patch for 2.2.18pre that was 100% safe in that it just made use of a script that was already in the tree (scripts/kwhich). But sure enough, it broke for users of older Red Hat installations who were still on bash 1.x. It seems scripts/kwhich hadn't been used that way before, so nobody had noticed that it didn't work with bash 1. That said, I think your current version is in fact bug-free and if it were up to me I would put it in the tree. But I also understand why others are hesitant to trust it. The bugs it fixes are fairly minor, after all. Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
[esr] > Besides, right now the configurator has a simple invariant. It will > only accept consistent configurations So you are saying that the old 'vi .config; make oldconfig' trick is officially unsupported? That's too bad, it was quite handy. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka I stick my neck out a mile...
[esr] Besides, right now the configurator has a simple invariant. It will only accept consistent configurations So you are saying that the old 'vi .config; make oldconfig' trick is officially unsupported? That's too bad, it was quite handy. Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [upatch] lib/Makefile
[Peter Samuelson] > > Introduced in 2.4.4pre4, I believe. $(export-objs) need not be > > conditional, and the if statement was not really correct either, > > although in this case it probably worked. [Tom Rini] > Er, are you sure changing the test for !"nn" is correct here? I > _think_ at least that is intentional and correct (since you can have > one on but not the other). I understand the intent. The point is that in our current makefiles you are not allowed to assume that a negative value is "n", because it could be "". 2.4.4pre probably works because each 'config.in' file explicitly sets these variables to "y" or "n". However, it would be perfectly legal for a config.in to unset the variable, or for that matter not even mention it. In that case the !"nn" test fails. This is the same reason you cannot use 'ifdef CONFIG_*' in the Makefiles. Lots of people do, but each instance is a bug. They are assuming the opposite: that a variable will be "" rather than "n". (N.B. this issue will go away with Keith's 2.5 Makefiles. And there was much rejoicing.) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[upatch] lib/Makefile
Introduced in 2.4.4pre4, I believe. $(export-objs) need not be conditional, and the if statement was not really correct either, although in this case it probably worked. Peter --- 2.4.4pre6/lib/Makefile~ Mon Apr 23 09:51:17 2001 +++ 2.4.4pre6/lib/Makefile Mon Apr 23 17:11:04 2001 @@ -8,14 +8,12 @@ L_TARGET := lib.a -export-objs := cmdline.o +export-objs := cmdline.o rwsem.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o -ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn) -export-objs += rwsem.o -obj-y += rwsem.o -endif +obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem.o +obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o ifneq ($(CONFIG_HAVE_DEC_LOCK),y) obj-y += dec_and_lock.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[upatch] lib/Makefile
Introduced in 2.4.4pre4, I believe. $(export-objs) need not be conditional, and the if statement was not really correct either, although in this case it probably worked. Peter --- 2.4.4pre6/lib/Makefile~ Mon Apr 23 09:51:17 2001 +++ 2.4.4pre6/lib/Makefile Mon Apr 23 17:11:04 2001 @@ -8,14 +8,12 @@ L_TARGET := lib.a -export-objs := cmdline.o +export-objs := cmdline.o rwsem.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o -ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn) -export-objs += rwsem.o -obj-y += rwsem.o -endif +obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem.o +obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o ifneq ($(CONFIG_HAVE_DEC_LOCK),y) obj-y += dec_and_lock.o - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [upatch] lib/Makefile
[Peter Samuelson] Introduced in 2.4.4pre4, I believe. $(export-objs) need not be conditional, and the if statement was not really correct either, although in this case it probably worked. [Tom Rini] Er, are you sure changing the test for !nn is correct here? I _think_ at least that is intentional and correct (since you can have one on but not the other). I understand the intent. The point is that in our current makefiles you are not allowed to assume that a negative value is n, because it could be . 2.4.4pre probably works because each 'config.in' file explicitly sets these variables to y or n. However, it would be perfectly legal for a config.in to unset the variable, or for that matter not even mention it. In that case the !nn test fails. This is the same reason you cannot use 'ifdef CONFIG_*' in the Makefiles. Lots of people do, but each instance is a bug. They are assuming the opposite: that a variable will be rather than n. (N.B. this issue will go away with Keith's 2.5 Makefiles. And there was much rejoicing.) Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Cross-referencing frenzy
[esr] > > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig >arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart >arch/arm/def-configs/shark [jgarzik] > typo, that should be ...YMFPCI. Actually it's not a typo (although the fix is the same). The old "SB-compatible mode" Yamaha driver was indeed CONFIG_SOUND_YMPCI. That allowed the two to coexist while the native-mode driver matured. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Cross-referencing frenzy
[esr] CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart arch/arm/def-configs/shark [jgarzik] typo, that should be ...YMFPCI. Actually it's not a typo (although the fix is the same). The old "SB-compatible mode" Yamaha driver was indeed CONFIG_SOUND_YMPCI. That allowed the two to coexist while the native-mode driver matured. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.1.3 is available
[John Cowan] > The whole point of CML2 is to make kernel configuration something > that Aunt Tillie (or a reasonable facsimile thereof) can do, and we > are all Aunt Tillies from time to time. That includes differing > standards of readability, Come on, that's absolutely a red herring. There are valid reasons to want to configure your color schemes, but Aunt Tillie is not one of them. Do you seriously believe the novice user will ever futz with a ~/.kernelconfigrc file? I don't. Only the (relatively) advanced user will bother to figure out stuff like that. If you want your aunt to be able to set her own colors, you basically have to provide an 'Edit / Preferences...' drop-down or equivalent, and I think we all know we don't want to go *there* > Without counting, I estimate that 50% of the problem (I won't say > "bug" in this context) reports you have had since 1.0.0 have been > about colors. Which basically means Eric and the others have long since shaken out the serious bugs. -- Except for the famous 20-second parse, which of course accounts for the *other* 50% of recent CML2 traffic. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.1.3 is available
[John Cowan] The whole point of CML2 is to make kernel configuration something that Aunt Tillie (or a reasonable facsimile thereof) can do, and we are all Aunt Tillies from time to time. That includes differing standards of readability, Come on, that's absolutely a red herring. There are valid reasons to want to configure your color schemes, but Aunt Tillie is not one of them. Do you seriously believe the novice user will ever futz with a ~/.kernelconfigrc file? I don't. Only the (relatively) advanced user will bother to figure out stuff like that. If you want your aunt to be able to set her own colors, you basically have to provide an 'Edit / Preferences...' drop-down or equivalent, and I think we all know we don't want to go *there* Without counting, I estimate that 50% of the problem (I won't say "bug" in this context) reports you have had since 1.0.0 have been about colors. Which basically means Eric and the others have long since shaken out the serious bugs. -- Except for the famous 20-second parse, which of course accounts for the *other* 50% of recent CML2 traffic. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.1.3 is available
[esr] > If there were already a library in ths stock Python distribution to > digest .Xdefaults files I might consider this. Perhaps I'll write > one. But I'm not going to bulk up the CML2 code with this marginal > feature. Wait ... I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.1.3 is available
[esr] If there were already a library in ths stock Python distribution to digest .Xdefaults files I might consider this. Perhaps I'll write one. But I'm not going to bulk up the CML2 code with this marginal feature. Wait ... I thought you were just using Python bindings to Tk. Are you telling us the Tk library, which for 8 or 10 years has been pretty much *the* X toolkit/widget set for scripting, does not include an interface to X resources? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
[Jeff Garzik] > > It stays "8139too". Donald Becker's rtl8139.c continues to exist > > outside the kernel. Honestly, Jeff, I don't see how it matters -- because if you are downloading an external driver, you are not going through the config system anyway. But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer gets to choose") so I support your stand. [esr] > Now, wait, Jeff. I'm not attached to Peter's change, but I don't > think we can reasonably be expected to worry about every possible > driver left over from every old version of Linux when managing the > configuration-symbol namespace. That way madness lies. Eric, the issue arose because you are obliquely proposing -- nay, insisting on -- a policy change. CONFIG_8139TOO is a perfectly valid preprocessor token and a perfectly valid GNU Make macro name. It corresponds with a source file '8139too.c' which is also perfectly valid. Did it never occur to you that by insisting on a policy change (and related code changes), with no discussion, consensus or mandate, and which fixes no current bugs ... that a few toes may feel stepped on? The burden of proof is yours. Why should a CML2 design decision (stripping of CONFIG_ in the configuration files) change what seems to be an entirely reasonable policy? Especially since there are multiple ways, which you have rejected, to work around the lexical problem in CML2 itself? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
[esr] > CONFIG_8139TOOCONFIG_RTL8139TOO > CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO > CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER The -TOO suffix was to distinguish between this and the former 8139 driver, as the two coexisted in 2.2 and 2.3. As the old driver has been dropped from 2.4, I propose likewise dropping the -TOO. Oh, BTW -- an alternate approach to making the kernel tree compatible with CML2 would be to make CML2 compatible with the kernel tree. Define a character (say '%') as an optional prefix for a configuration symbol. This character would only be required where the symbol would otherwise by misparsed, as with '[0-9].*'. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
[esr] CONFIG_8139TOOCONFIG_RTL8139TOO CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER The -TOO suffix was to distinguish between this and the former 8139 driver, as the two coexisted in 2.2 and 2.3. As the old driver has been dropped from 2.4, I propose likewise dropping the -TOO. Oh, BTW -- an alternate approach to making the kernel tree compatible with CML2 would be to make CML2 compatible with the kernel tree. Define a character (say '%') as an optional prefix for a configuration symbol. This character would only be required where the symbol would otherwise by misparsed, as with '[0-9].*'. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
[Jeff Garzik] It stays "8139too". Donald Becker's rtl8139.c continues to exist outside the kernel. Honestly, Jeff, I don't see how it matters -- because if you are downloading an external driver, you are not going through the config system anyway. But ... "maintanicus selector est" (my pseudo-Latin for "the maintainer gets to choose") so I support your stand. [esr] Now, wait, Jeff. I'm not attached to Peter's change, but I don't think we can reasonably be expected to worry about every possible driver left over from every old version of Linux when managing the configuration-symbol namespace. That way madness lies. Eric, the issue arose because you are obliquely proposing -- nay, insisting on -- a policy change. CONFIG_8139TOO is a perfectly valid preprocessor token and a perfectly valid GNU Make macro name. It corresponds with a source file '8139too.c' which is also perfectly valid. Did it never occur to you that by insisting on a policy change (and related code changes), with no discussion, consensus or mandate, and which fixes no current bugs ... that a few toes may feel stepped on? The burden of proof is yours. Why should a CML2 design decision (stripping of CONFIG_ in the configuration files) change what seems to be an entirely reasonable policy? Especially since there are multiple ways, which you have rejected, to work around the lexical problem in CML2 itself? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Rename all derived CONFIG variables
[kaos] > In 2.4.2-ac18 there are 130 CONFIG options that are always derived > from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the for namespace CONFIG__* rather than CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, and CONFIG__* seems all-around less intrusive. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Rename all derived CONFIG variables
[kaos] In 2.4.2-ac18 there are 130 CONFIG options that are always derived from other options, the user has no control over them. I've thought about these before ... but never got around to doing anything about them. I agree they should have a separate namespace. However, I would vote the for namespace CONFIG__* rather than CONFIG_*_DERIVED. As Jeff noted, _DERIVED is quite a mouthful to type, and CONFIG__* seems all-around less intrusive. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: yacc dependency of aic7xxx driver
[Jörn Nettingsmeier, quoting Robert Muller] > Just create a shell script called yacc with the following content > --- > #!/bin/sh > bison --yacc $* > --- > i ran into the same problem with a school proiject here yesterday Why does nobody learn shell anymore? (Just curious.) #!/bin/sh exec bison -y "$@" Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: yacc dependency of aic7xxx driver
[Jörn Nettingsmeier, quoting Robert Muller] Just create a shell script called yacc with the following content --- #!/bin/sh bison --yacc $* --- i ran into the same problem with a school proiject here yesterday Why does nobody learn shell anymore? (Just curious.) #!/bin/sh exec bison -y "$@" Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Info on adding system calls
[T.L.Madhu] > I want to add a function defined in my loadeble kernel module as > system call. You can't. At least not without hackery -- anything is possible with a bit of hackery. And there are at least two good reasons for this. First: adding syscalls at runtime is a recipe for chaos in terms of applications knowing what the ABI should be. What if two modules wanted the same unallocated syscall? Should the second one fail, or should it just get a free syscall, and somehow publish its syscall to userspace so apps can use it? The second is philosophical. At the top of the COPYING file in the kernel source, you see that Linus has made an exception to the GPL, to allow anyone to write and distribute non-GPL modules, as long as they do not compile directly into the kernel. However, he doesn't want people to use this as a general GPL circumvention device, so he will not make it convenient to extend the system call interface this way. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS: Cannot open root device
[Jeremy Jackson] > try command 'man mkinitrd' under redhat for hints about initial > ramdisk. I have been puzzled about this for quite some time. Why exactly does everyone always recommend using 'mkinitrd' on Red Hat systems? It seems to me that if you are compiling a kernel for a specific server anyway, it is a much more reliable proposition to just compile in whatever drivers you need to boot. initrd's are inherently clumsy and fragile, to my way of thinking. I've always thought they should only be used to support diverse or unknown hardware, or odd cases like crypto loopback root. Are there other advantages to 'mkinitrd' in the case of a custom kernel for a single machine? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
[Dr. Kelsey Hudson] > umm, last i checked a carriage return wasn't whitespace... space, > horizontal tab, vertical tab, form feed constitute whitespace IIRC... Where and when did you check? Several sources disagree with you. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
[Jeff Coy] > this issue came up frequently with customers uploading scripts in > binary mode trying to run #!/usr/bin/perl^M. The solution for me was > to just do the following: > > cd /usr/bin > sudo ln -s perl^V^M perl So none of your customers tried '#!/usr/bin/perl -w^M'? (Come on, doesn't everyone use -w?) I'm not for treating \r as IFS in the kernel, but the "simple one-time" solution is not perfect.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
[Jeff Coy] this issue came up frequently with customers uploading scripts in binary mode trying to run #!/usr/bin/perl^M. The solution for me was to just do the following: cd /usr/bin sudo ln -s perl^V^M perl So none of your customers tried '#!/usr/bin/perl -w^M'? (Come on, doesn't everyone use -w?) I'm not for treating \r as IFS in the kernel, but the "simple one-time" solution is not perfect.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
[Dr. Kelsey Hudson] umm, last i checked a carriage return wasn't whitespace... space, horizontal tab, vertical tab, form feed constitute whitespace IIRC... Where and when did you check? Several sources disagree with you. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS: Cannot open root device
[Jeremy Jackson] try command 'man mkinitrd' under redhat for hints about initial ramdisk. I have been puzzled about this for quite some time. Why exactly does everyone always recommend using 'mkinitrd' on Red Hat systems? It seems to me that if you are compiling a kernel for a specific server anyway, it is a much more reliable proposition to just compile in whatever drivers you need to boot. initrd's are inherently clumsy and fragile, to my way of thinking. I've always thought they should only be used to support diverse or unknown hardware, or odd cases like crypto loopback root. Are there other advantages to 'mkinitrd' in the case of a custom kernel for a single machine? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Info on adding system calls
[T.L.Madhu] I want to add a function defined in my loadeble kernel module as system call. You can't. At least not without hackery -- anything is possible with a bit of hackery. And there are at least two good reasons for this. First: adding syscalls at runtime is a recipe for chaos in terms of applications knowing what the ABI should be. What if two modules wanted the same unallocated syscall? Should the second one fail, or should it just get a free syscall, and somehow publish its syscall to userspace so apps can use it? The second is philosophical. At the top of the COPYING file in the kernel source, you see that Linus has made an exception to the GPL, to allow anyone to write and distribute non-GPL modules, as long as they do not compile directly into the kernel. However, he doesn't want people to use this as a general GPL circumvention device, so he will not make it convenient to extend the system call interface this way. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for best resource for device driver programmers
[Steven Friedrich] > The questions I have are difficult to research because so little info > exists about 2.4 design philosophy. I guess the ORA "Linux Device Drivers" 2nd edition is due out Real Soon Now. It will cover 2.4. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for best resource for device driver programmers
[Steven Friedrich] The questions I have are difficult to research because so little info exists about 2.4 design philosophy. I guess the ORA "Linux Device Drivers" 2nd edition is due out Real Soon Now. It will cover 2.4. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] Makefile fixes
[Kai Germaschewski] > +list-multi := fore_200e > +fore_200e-objs := fore200e.o $(FORE200E_FW_OBJS) list-multi := fore_200e.o Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] Makefile fixes
[Kai Germaschewski] +list-multi := fore_200e +fore_200e-objs := fore200e.o $(FORE200E_FW_OBJS) list-multi := fore_200e.o Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory allocation
[Ivan Stepnikov] > I tried to call getrlimit(). It shows only 2G available memory and > there is no way to increase it. Right. Architectural limit. There needs to be some room in the address space for kernel stuff, I/O, etc -- in Linux at least, having to play with your page tables every single time you enter a system call or IRQ handler would be considered a Bad Thing. > Could you say me are there any solutions? a) If you have that much memory, maybe you need a 64-bit CPU. b) fork() and do IPC. It's the Unix Way. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory allocation
[Ivan Stepnikov] I tried to call getrlimit(). It shows only 2G available memory and there is no way to increase it. Right. Architectural limit. There needs to be some room in the address space for kernel stuff, I/O, etc -- in Linux at least, having to play with your page tables every single time you enter a system call or IRQ handler would be considered a Bad Thing. Could you say me are there any solutions? a) If you have that much memory, maybe you need a 64-bit CPU. b) fork() and do IPC. It's the Unix Way. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unable to link 2.4.2
[Pierfrancesco Caci] > Hi there, can someone please tell me what's going wrong with my > compilation of 2.4.2 ? Change '-oformat' to '--oformat' 4 places in arch/i386/boot/Makefile. > Binutils 2.10.91.0.2 This version of binutils no longer accepts the old 'ld -oformat' form of '--oformat'. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unable to link 2.4.2
[Pierfrancesco Caci] Hi there, can someone please tell me what's going wrong with my compilation of 2.4.2 ? Change '-oformat' to '--oformat' 4 places in arch/i386/boot/Makefile. Binutils 2.10.91.0.2 This version of binutils no longer accepts the old 'ld -oformat' form of '--oformat'. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt-464c and 2.4.1
[Drew Bertola] > Feb 23 20:48:24 babylon modprobe: modprobe: Can't locate module binfmt-464c > Although I've looked through the documentation, I can't find any > reference to binfmt-464c. binfmt-464c is ELF -- it means your kernel came across an ELF executable and was unable to execute it so it tried to load the ELF binary format module. Since you have ELF compiled into your kernel already, this didn't work. My guess is that you have a corrupt ELF executable on your system, which your ELF loader refuses to load. Every time someone tries to execute it, your kernel will do a 'modprobe -k binfmt-464c'. If you can't find the executable in question and just want to get the message out of your logs, add alias binfmt-464c off to your /etc/modules.conf . Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: loopback block device freezes mount
[Jon Hart] > 1. I am unable to mount loopback block devices using kernel 2.4.2. Apparently fixed in -ac3. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: loopback block device freezes mount
[Jon Hart] 1. I am unable to mount loopback block devices using kernel 2.4.2. Apparently fixed in -ac3. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt-464c and 2.4.1
[Drew Bertola] Feb 23 20:48:24 babylon modprobe: modprobe: Can't locate module binfmt-464c Although I've looked through the documentation, I can't find any reference to binfmt-464c. binfmt-464c is ELF -- it means your kernel came across an ELF executable and was unable to execute it so it tried to load the ELF binary format module. Since you have ELF compiled into your kernel already, this didn't work. My guess is that you have a corrupt ELF executable on your system, which your ELF loader refuses to load. Every time someone tries to execute it, your kernel will do a 'modprobe -k binfmt-464c'. If you can't find the executable in question and just want to get the message out of your logs, add alias binfmt-464c off to your /etc/modules.conf . Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Boot log for Linux PPC64 on POWER3 hardware
[Peter Bergner] > The following is a boot log for a 64 bit port of Linux for IBM's 64 > bit PowerPC processors. This log was made on a pSeries model 270 > which uses a POWER3 microprocessor. Impressive. One question, though -- > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] > starting cpu /cpus/PowerPC,[EMAIL PROTECTED] You have 4 CPUs? > OpenPIC Version 1.2 (8 CPUs and 32 IRQ sources) at e1002000 > OpenPIC timer frequency is 0 MHz ...or is it 8 CPUs? > swamsauger:~ # uname -a > Linux swamsauger 2.4.0-tg11 #188 Thu Feb 22 19:55:45 CST 2001 ppc64 unknown > swamsauger:~ # > swamsauger:~ # cat /proc/cpuinfo > processor : 0 ...or just one CPU? Peter (And when do we get XFree86 support for the GXT-2000P, -3000P etc?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Boot log for Linux PPC64 on POWER3 hardware
[Peter Bergner] The following is a boot log for a 64 bit port of Linux for IBM's 64 bit PowerPC processors. This log was made on a pSeries model 270 which uses a POWER3 microprocessor. Impressive. One question, though -- starting cpu /cpus/PowerPC,[EMAIL PROTECTED] starting cpu /cpus/PowerPC,[EMAIL PROTECTED] starting cpu /cpus/PowerPC,[EMAIL PROTECTED] You have 4 CPUs? OpenPIC Version 1.2 (8 CPUs and 32 IRQ sources) at e1002000 OpenPIC timer frequency is 0 MHz ...or is it 8 CPUs? swamsauger:~ # uname -a Linux swamsauger 2.4.0-tg11 #188 Thu Feb 22 19:55:45 CST 2001 ppc64 unknown swamsauger:~ # swamsauger:~ # cat /proc/cpuinfo processor : 0 ...or just one CPU? Peter (And when do we get XFree86 support for the GXT-2000P, -3000P etc?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
[John Heil] > Which -ac series patch does this match up with or superceed ie should > this be considered superior to -ac19 ? Neither "supercedes" the other -- they are different trees. The -ac series has some patches that Linus may never get because they are experimental, or still buggy. If you want stability, run the real Linus 2.4. If you want all the really minor bug fixes and more of the experimental code, run -ac. If you want production quality, run your kernel on a test server before deploying. (As always!) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com
[Christoph Hellwig] > It would be really good to have something devfs-like just for LVM in > setups that don't use LVM, so we could avoid mounting root read/write ^^^devfs? > for device-creation. For most people, read/write access to /dev is rarely needed -- how often do you create new VGs or LVs? How often do you run MAKEDEV or vgscan? Sometimes you need to change tty inodes but that's what /dev/pts is for. If you do need read-write access to /dev but not /, put it on a separate filesystem. Leave just a skeletal /dev in your root filesystem, enough to bootstrap. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com
[Christoph Hellwig] It would be really good to have something devfs-like just for LVM in setups that don't use LVM, so we could avoid mounting root read/write ^^^devfs? for device-creation. For most people, read/write access to /dev is rarely needed -- how often do you create new VGs or LVs? How often do you run MAKEDEV or vgscan? Sometimes you need to change tty inodes but that's what /dev/pts is for. If you do need read-write access to /dev but not /, put it on a separate filesystem. Leave just a skeletal /dev in your root filesystem, enough to bootstrap. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
[John Heil] Which -ac series patch does this match up with or superceed ie should this be considered superior to -ac19 ? Neither "supercedes" the other -- they are different trees. The -ac series has some patches that Linus may never get because they are experimental, or still buggy. If you want stability, run the real Linus 2.4. If you want all the really minor bug fixes and more of the experimental code, run -ac. If you want production quality, run your kernel on a test server before deploying. (As always!) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Different CFLAGS for arch and non-arch files.
[Peter Bergner] > Hopefully someone can point me in the right direction here. > I need to use different CFLAGS options depending on whether > I'm compiling arch dependent code or arch independent code. Use the per-directory $(EXTRA_CFLAGS), and/or the per-file $(CFLAGS_foo.o). See also $(EXTRA_AFLAGS), $(EXTRA_LDFLAGS) and $(AFLAGS_foo.o). I suppose there ought to be a $(LDFLAGS_foo.o) for completeness, but nobody has needed it yet. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs] > The conclusion: it's cannot be implemented without slowdown. Or: it cannot be implemented 100% safely and correctly without slowdown. If you know the use you wish to put this to, and are willing to risk a permission check somewhere being confused momentarily by a non-atomic update of a 32-bit number (or the non-atomic update between several 32-bit numbers, which I think is less serious because then you are not granting more than the union of the two UIDs) go ahead and patch your kernel. > So ignore my patch. For official kernels, I agree. They need to be as safe and deterministic as possible, especially security-wise, and a semaphore on every permission check would be ridiculous. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[Alan Cox] > There is an assumption in the kernel that only the task changes its > own uid and other related data. Fair enough but could you explain the potential problems? And how is it different from sys_setpriority? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[Peter Samuelson] > > Race -- you need to make sure the task_struct doesn't disappear out > > from under you. > > > > Anyway, why not use the interface 'chown uid /proc/pid'? No new > > syscall, no arch-dependent part, no user-space tool, etc. [Martin Dalecki] > Becouse of exactly the same race condition as above maybe? OK then, what is the right way to make sure a task doesn't disappear? I assumed 'read_lock (_lock)' was enough, from reading other code. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs] > > Race -- you need to make sure the task_struct doesn't disappear out > > from under you. > > Yes, but we need a write_lock, not a read_lock. No, it's a read_lock because it is locking the task *list*, which is not being changed. The only thing being changed is data within a task struct. The lock is merely to prevent the task itself from disappearing. > We need a userspace tool, because we must check if the user, who want > to change the uid, knows the other user's passwd. > Or what if user1 want to change user2's process to user3 uid? That is a mere 'sudo'-type issue -- just a matter of figuring out who has the right to do this to whom and under what circumstances. Root, in any case, can do the job without a special tool. Anyhow, according to Alan bad things can happen if the uid set is changed unexpectedly. I assume he means certain permissions checks could be confused by accessing ->euid more than once and getting different answers. If so, I agree that this is a bad idea Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs] Race -- you need to make sure the task_struct doesn't disappear out from under you. Yes, but we need a write_lock, not a read_lock. No, it's a read_lock because it is locking the task *list*, which is not being changed. The only thing being changed is data within a task struct. The lock is merely to prevent the task itself from disappearing. We need a userspace tool, because we must check if the user, who want to change the uid, knows the other user's passwd. Or what if user1 want to change user2's process to user3 uid? That is a mere 'sudo'-type issue -- just a matter of figuring out who has the right to do this to whom and under what circumstances. Root, in any case, can do the job without a special tool. Anyhow, according to Alan bad things can happen if the uid set is changed unexpectedly. I assume he means certain permissions checks could be confused by accessing -euid more than once and getting different answers. If so, I agree that this is a bad idea Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[Peter Samuelson] Race -- you need to make sure the task_struct doesn't disappear out from under you. Anyway, why not use the interface 'chown uid /proc/pid'? No new syscall, no arch-dependent part, no user-space tool, etc. [Martin Dalecki] Becouse of exactly the same race condition as above maybe? OK then, what is the right way to make sure a task doesn't disappear? I assumed 'read_lock (tasklist_lock)' was enough, from reading other code. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[Alan Cox] There is an assumption in the kernel that only the task changes its own uid and other related data. Fair enough but could you explain the potential problems? And how is it different from sys_setpriority? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs] The conclusion: it's cannot be implemented without slowdown. Or: it cannot be implemented 100% safely and correctly without slowdown. If you know the use you wish to put this to, and are willing to risk a permission check somewhere being confused momentarily by a non-atomic update of a 32-bit number (or the non-atomic update between several 32-bit numbers, which I think is less serious because then you are not granting more than the union of the two UIDs) go ahead and patch your kernel. So ignore my patch. For official kernels, I agree. They need to be as safe and deterministic as possible, especially security-wise, and a semaphore on every permission check would be ridiculous. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Different CFLAGS for arch and non-arch files.
[Peter Bergner] Hopefully someone can point me in the right direction here. I need to use different CFLAGS options depending on whether I'm compiling arch dependent code or arch independent code. Use the per-directory $(EXTRA_CFLAGS), and/or the per-file $(CFLAGS_foo.o). See also $(EXTRA_AFLAGS), $(EXTRA_LDFLAGS) and $(AFLAGS_foo.o). I suppose there ought to be a $(LDFLAGS_foo.o) for completeness, but nobody has needed it yet. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs]
> Here is a new syscall. With this you can change the owner of a running
> procces.
> + if (current->euid)
> + return -EPERM;
Use capable().
> + p = find_task_by_pid(pid);
> + p->fsuid = p->euid = p->suid = p->uid = uid;
Race -- you need to make sure the task_struct doesn't disappear out
from under you.
Anyway, why not use the interface 'chown uid /proc/pid'? No new
syscall, no arch-dependent part, no user-space tool, etc.
The following is untested and almost certainly broken (I'm a lousy
kernel hacker), but should be at least somewhat close
Peter
--- fs/proc/base.c.orig Thu Nov 16 22:11:22 2000
+++ fs/proc/base.c Mon Feb 19 22:51:59 2001
@@ -873,6 +873,27 @@
return ERR_PTR(error);
}
+static int proc_base_chown (struct dentry *dentry, struct iattr *attr)
+{
+ struct task_struct *task;
+
+ if (!capable (CAP_SETUID))
+ return -EPERM;
+
+ if (!(attr->ia_valid & ATTR_UID))
+ return -EINVAL;
+
+ read_lock (_lock);
+ task = dentry->d_inode->u.proc_i.task;
+ if (task)
+ task->fsuid = task->euid = task->suid = task->uid = attr->ia_uid;
+ read_unlock (_lock);
+ if (!task)
+ return -ENOENT;
+
+ return 0;
+}
+
static struct file_operations proc_base_operations = {
read: generic_read_dir,
readdir:proc_base_readdir,
@@ -880,6 +901,7 @@
static struct inode_operations proc_base_inode_operations = {
lookup: proc_base_lookup,
+ setattr:proc_base_chown,
};
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
[Justin Gibbs] > I've verified the driver's functionality on 25 different cards thus > far covering the full range of chips from aic7770->aic7899. That's very good to hear. I know the temptation of only testing on new hardware; that's why I was concerned. > Lots of people here at Adaptec look at me funny when I pull a PC from > the scrap-heap, or pull an old, discontinued card from an unused > marketing display for use in my lab Heh. (: BTW, is there really enough common ground between the whole series of AIC chips to justify a single huge driver? I know they ship three separate NT drivers to cover this range.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
[Justin Gibbs] I've verified the driver's functionality on 25 different cards thus far covering the full range of chips from aic7770-aic7899. That's very good to hear. I know the temptation of only testing on new hardware; that's why I was concerned. Lots of people here at Adaptec look at me funny when I pull a PC from the scrap-heap, or pull an old, discontinued card from an unused marketing display for use in my lab Heh. (: BTW, is there really enough common ground between the whole series of AIC chips to justify a single huge driver? I know they ship three separate NT drivers to cover this range.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
[BERECZ Szabolcs]
Here is a new syscall. With this you can change the owner of a running
procces.
+ if (current-euid)
+ return -EPERM;
Use capable().
+ p = find_task_by_pid(pid);
+ p-fsuid = p-euid = p-suid = p-uid = uid;
Race -- you need to make sure the task_struct doesn't disappear out
from under you.
Anyway, why not use the interface 'chown uid /proc/pid'? No new
syscall, no arch-dependent part, no user-space tool, etc.
The following is untested and almost certainly broken (I'm a lousy
kernel hacker), but should be at least somewhat close
Peter
--- fs/proc/base.c.orig Thu Nov 16 22:11:22 2000
+++ fs/proc/base.c Mon Feb 19 22:51:59 2001
@@ -873,6 +873,27 @@
return ERR_PTR(error);
}
+static int proc_base_chown (struct dentry *dentry, struct iattr *attr)
+{
+ struct task_struct *task;
+
+ if (!capable (CAP_SETUID))
+ return -EPERM;
+
+ if (!(attr-ia_valid ATTR_UID))
+ return -EINVAL;
+
+ read_lock (tasklist_lock);
+ task = dentry-d_inode-u.proc_i.task;
+ if (task)
+ task-fsuid = task-euid = task-suid = task-uid = attr-ia_uid;
+ read_unlock (tasklist_lock);
+ if (!task)
+ return -ENOENT;
+
+ return 0;
+}
+
static struct file_operations proc_base_operations = {
read: generic_read_dir,
readdir:proc_base_readdir,
@@ -880,6 +901,7 @@
static struct inode_operations proc_base_inode_operations = {
lookup: proc_base_lookup,
+ setattr:proc_base_chown,
};
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
[Jacob Luna Lundberg] > Just out of curiosity, why can't the specification be along the lines > of a vendor data file saying ``if you want the printer to do x then > say y'' and ``if the printer says x then it means y''. That ought to > add a lot of functionality right there. Think about it. A spec based on what you say would be quite easy to reverse-compile, no? In which case, obviously the company's IP, such as it is, is not protected. In which case, why not just do an open source driver and be done with it? The concept of architecture-independent device drivers goes back to Open Firmware. But in that case, there is a practical consideration: the drivers couldn't be compiled down to machine language since they had to be accessible as-is at boot time. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
[Dennis] > For example, if there were six different companies that marketed > ethernet drivers for the eepro100, you'd have a choice of which one > to buy..perhaps with different "features" that were of value to > you. Instead, you have crappy GPL code that locks up under load, and > its not worth spending corporate dollars to fix it because you have > to give away your work for free under GPL. And since there is a > "free" driver that most people can use, its not worth building a > better mousetrap either because the market is too small. So, the > handful of users with problems get to "fit it themselves", most of > whom cant of course. You may have a point but device drivers are a piss-poor example. Say Linux does take over the world, and eepro100 continues to lock up under load. Who loses? Intel. People will quit buying their motherboards and PCI cards. So for whom is it worth spending corporate dollars fixing eepro100? Again, Intel. If word were to get out "avoid Intel network cards, the driver is crap", you can bet they will fix it. If this hasn't happened yet, it's because Intel doesn't see enough market in Linux to bother. And if so, so what? There are plenty of motherboards with pcnet32 and 3c9xx chips. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
[Nathan Black] > This really improved the performance of my dual PIII-866 w/512MB Ram > and AIC7899 scsi. [...] > I would suggest, if at all possible, putting this in the 2.4.2 > kernel. Have you any idea the breadth of cards and chips that aic7xxx supports? Sure, Justin's driver does great with your shiny new 7899, but can you verify that it also drives the 8-year-old EISA AHA-2740 I still have sitting around (actually retired to the parts pile, but that's beside the point, I'm sure some still exist in the wild)? How about the VLB card I have in my 486 at home? IMHO there is no way Linus should consider replacing aic7xxx with 6.1 in a stable kernel. Not until it has gotten as much testing on as much obscure hardware as the old driver, which is not going to happen soon. Breaking existing working setups in 2.4.x is not an option. Possible solution: let the two drivers coexist, like ncr53c8xx vs sym53c8xx or tulip vs old_tulip. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
[Manfred Spraul] > > Unless you modify the ABI and pass the array bounds around you won't > > catch such problems, [Eric W. Biederman] > Of course. But this is linux and you have the source. And I did > mention you needed to recompile the libraries your trusted > applications depended on. So by what ABI do you propose to pass array bounds to a called function? It sounds pretty ugly. It also sounds like you will be breaking the extremely useful C postulate that, at the ABI level at least, arrays and pointers are equivalent. I can't see *how* you plan to work around that one. > Yep bounds checking is not an easy fix. Understatement of the year, if you really want to catch all cases. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
[Manfred Spraul] Unless you modify the ABI and pass the array bounds around you won't catch such problems, [Eric W. Biederman] Of course. But this is linux and you have the source. And I did mention you needed to recompile the libraries your trusted applications depended on. So by what ABI do you propose to pass array bounds to a called function? It sounds pretty ugly. It also sounds like you will be breaking the extremely useful C postulate that, at the ABI level at least, arrays and pointers are equivalent. I can't see *how* you plan to work around that one. Yep bounds checking is not an easy fix. Understatement of the year, if you really want to catch all cases. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
[Nathan Black] This really improved the performance of my dual PIII-866 w/512MB Ram and AIC7899 scsi. [...] I would suggest, if at all possible, putting this in the 2.4.2 kernel. Have you any idea the breadth of cards and chips that aic7xxx supports? Sure, Justin's driver does great with your shiny new 7899, but can you verify that it also drives the 8-year-old EISA AHA-2740 I still have sitting around (actually retired to the parts pile, but that's beside the point, I'm sure some still exist in the wild)? How about the VLB card I have in my 486 at home? IMHO there is no way Linus should consider replacing aic7xxx with 6.1 in a stable kernel. Not until it has gotten as much testing on as much obscure hardware as the old driver, which is not going to happen soon. Breaking existing working setups in 2.4.x is not an option. Possible solution: let the two drivers coexist, like ncr53c8xx vs sym53c8xx or tulip vs old_tulip. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
[Dennis] For example, if there were six different companies that marketed ethernet drivers for the eepro100, you'd have a choice of which one to buy..perhaps with different "features" that were of value to you. Instead, you have crappy GPL code that locks up under load, and its not worth spending corporate dollars to fix it because you have to give away your work for free under GPL. And since there is a "free" driver that most people can use, its not worth building a better mousetrap either because the market is too small. So, the handful of users with problems get to "fit it themselves", most of whom cant of course. You may have a point but device drivers are a piss-poor example. Say Linux does take over the world, and eepro100 continues to lock up under load. Who loses? Intel. People will quit buying their motherboards and PCI cards. So for whom is it worth spending corporate dollars fixing eepro100? Again, Intel. If word were to get out "avoid Intel network cards, the driver is crap", you can bet they will fix it. If this hasn't happened yet, it's because Intel doesn't see enough market in Linux to bother. And if so, so what? There are plenty of motherboards with pcnet32 and 3c9xx chips. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
[Jacob Luna Lundberg] Just out of curiosity, why can't the specification be along the lines of a vendor data file saying ``if you want the printer to do x then say y'' and ``if the printer says x then it means y''. That ought to add a lot of functionality right there. Think about it. A spec based on what you say would be quite easy to reverse-compile, no? In which case, obviously the company's IP, such as it is, is not protected. In which case, why not just do an open source driver and be done with it? The concept of architecture-independent device drivers goes back to Open Firmware. But in that case, there is a practical consideration: the drivers couldn't be compiled down to machine language since they had to be accessible as-is at boot time. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lkml subject line
[Kai Henningsen] > > There *is* a good way to do this, and it would be really nice if > > vger could be taught to do it: add a List-Id: header > > (draft-chandhok-listid-04.txt RFC-to-be, implemented in lots of > > mailing list managers already). [Eli Carter] > Have you looked at the headers in an LK email? > > Sender: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > ^^ Should provide that List-Id you want. You missed the point. Certainly there are ways to identify LK mail. Kai is saying that since 'List-Id:' is an IETF proposed standard, Majordomo ought to use it. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lkml subject line
[Kai Henningsen] There *is* a good way to do this, and it would be really nice if vger could be taught to do it: add a List-Id: header (draft-chandhok-listid-04.txt RFC-to-be, implemented in lots of mailing list managers already). [Eli Carter] Have you looked at the headers in an LK email? Sender: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] ^^ Should provide that List-Id you want. You missed the point. Certainly there are ways to identify LK mail. Kai is saying that since 'List-Id:' is an IETF proposed standard, Majordomo ought to use it. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Software Mestizo Manifesto
[ac] > Vast amounts of debian included code contains suggestions about use. I'll not dispute your word because I know you for an objective person. But I don't remember coming across any such examples at least recently. Maybe I just don't remember them because they didn't sound like, well, manifestos. > > Also, Roberto -- it is rather presumptuous to assume that all of > > your (potentially) thousands of contributors from around the world > > happen to agree > Sure, but its an opinion so whats the big deal. Its no different to > RMS view of the world that the GPL discussion and FSF projects push As may be .. there's still a difference between restrictions on use and restrictions on distribution. FSF never even implies anything about how you are "supposed" to use software -- and discussions on distribution largely parallel the GPL in any case, which I have already agreed to. They are in that sense much less invasive, from the POV of contributing developers. (OTOH there is the "sign over your copyrights to the FSF" convention so in that case they are more invasive.) I suppose none of this matters in any case, because the GPL allows me to take your software, strip out the "I'd prefer if you didnt..." comments and redistribute. This is in contrast to the old BSD license, or the Free Documentation License, where it is possible to prevent bits from being clipped. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Software Mestizo Manifesto
[Roberto Diaz] > > I am trying to make a manifesto in order to attach it to all my > > gpl'd developments.. [Rik van Riel] > Quoted from the GPL: > --- > 6. Each time you redistribute the Program (or any work based on the > Program), the recipient automatically receives a license from the > original licensor to copy, distribute or modify the Program subject to [...] > Your "ethical" statement is incompatible with the GPL. Quoted from the GPL: --- 0. [...] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. Roberto's statement is about *use*, not *distribution*, so it is orthogonal to the GPL. It *does*, however, violate the DFSG, at least in spirit (since it is only a suggestion). For what it's worth, the DFSG is my standard for whether a particular project is worth my time to contribute code to. Also, Roberto -- it is rather presumptuous to assume that all of your (potentially) thousands of contributors from around the world happen to agree about that "fraternity of mankind" or whatever that was. Call me a misanthrope, but I'm not sure *I* agree with that one. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Software Mestizo Manifesto
[ac] Vast amounts of debian included code contains suggestions about use. I'll not dispute your word because I know you for an objective person. But I don't remember coming across any such examples at least recently. Maybe I just don't remember them because they didn't sound like, well, manifestos. Also, Roberto -- it is rather presumptuous to assume that all of your (potentially) thousands of contributors from around the world happen to agree Sure, but its an opinion so whats the big deal. Its no different to RMS view of the world that the GPL discussion and FSF projects push As may be .. there's still a difference between restrictions on use and restrictions on distribution. FSF never even implies anything about how you are "supposed" to use software -- and discussions on distribution largely parallel the GPL in any case, which I have already agreed to. They are in that sense much less invasive, from the POV of contributing developers. (OTOH there is the "sign over your copyrights to the FSF" convention so in that case they are more invasive.) I suppose none of this matters in any case, because the GPL allows me to take your software, strip out the "I'd prefer if you didnt..." comments and redistribute. This is in contrast to the old BSD license, or the Free Documentation License, where it is possible to prevent bits from being clipped. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
[Michael D. Crawford]
> I found I could mount three partitions on /mnt
Yes. New feature, appeared in the 2.4.0test series, or shortly before.
> and they'd all show up as mounted at /mnt in the "mount" command, but
> if I unmounted one of them (only tried with the currently visible
> one), then it appeared that there were no filesystems mounted there,
> but I could continue umounting until the other two were gone.
util-linux gets rather confused by this feature. They say newer
versions fix this.
> But I had the 2.10r util-linux sources on my machine and installed
> mount and umount from it, and I find that it gets it right mostly
> when I mount and unmount multiple things, with the exception that if
> /dev/sda5 was mounted before /dev/sda1, then if I give the command
> "umount /dev/sda5", sda1 is the one that gets unmounted rather than
> sda5, so it takes the most recently mounted filesystem rather than
> the one you specify.
I think this is a kernel limitation. 'umount' takes '/dev/sda5' and
turns it into '/mnt/test' and calls umount("/mnt/test"). The kernel
then unmounts whatever is on "top" of /mnt/test.
I don't think there's anything umount can do about this behavior.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/src/linux/scripts/ver_linux prints out incorrect info when "ls" is aliased.
[Ishikawa <[EMAIL PROTECTED]>] > I have no idea why I invoked ver_linux using "." : I must have seen > it somewhere and just followed it somehow. Who knows. Anyway, the following works in 'bash' at least -- don't know about other shells -- but it's quite a hack Peter --- scripts/ver_linux~ Tue Sep 19 22:28:37 2000 +++ scripts/ver_linux Mon Feb 5 10:38:21 2001 @@ -4,6 +4,15 @@ # /bin /sbin /usr/bin /usr/sbin /usr/local/bin, but it may # differ on your system. # +case "$_" in /*/sh|/*/bash|sh|bash) ;; *) + echo '*** Warning: you appear to have used the dreaded' + echo '*** . /path/to/ver_linux' + echo '*** syntax -- I hope you don'\''t have any aliases set' + echo '*** that might affect this script.' + echo '*** Recommended syntax is:' + echo '*** sh /path/to/ver_linux' + ;; +esac PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH echo '-- Versions installed: (if some fields are empty or look' echo '-- unusual then possibly you have very old versions)' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/src/linux/scripts/ver_linux prints out incorrect info when "ls" is aliased.
[Ishikawa] > I just noticed that running > > . /usr/src/linux/script/ver_linux > > prints out strange libc version [...] > I found that if the command "ls" is aliased to "ls -aF" So ... don't use '.' to execute scripts. If there is some documentation somewhere that told you to do this, please notify the author that it is wrong. sh scripts/ver_linux Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/src/linux/scripts/ver_linux prints out incorrect info when ls is aliased.
[Ishikawa] I just noticed that running . /usr/src/linux/script/ver_linux prints out strange libc version [...] I found that if the command "ls" is aliased to "ls -aF" So ... don't use '.' to execute scripts. If there is some documentation somewhere that told you to do this, please notify the author that it is wrong. sh scripts/ver_linux Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/src/linux/scripts/ver_linux prints out incorrect info when ls is aliased.
[Ishikawa [EMAIL PROTECTED]] I have no idea why I invoked ver_linux using "." : I must have seen it somewhere and just followed it somehow. Who knows. Anyway, the following works in 'bash' at least -- don't know about other shells -- but it's quite a hack Peter --- scripts/ver_linux~ Tue Sep 19 22:28:37 2000 +++ scripts/ver_linux Mon Feb 5 10:38:21 2001 @@ -4,6 +4,15 @@ # /bin /sbin /usr/bin /usr/sbin /usr/local/bin, but it may # differ on your system. # +case "$_" in /*/sh|/*/bash|sh|bash) ;; *) + echo '*** Warning: you appear to have used the dreaded' + echo '*** . /path/to/ver_linux' + echo '*** syntax -- I hope you don'\''t have any aliases set' + echo '*** that might affect this script.' + echo '*** Recommended syntax is:' + echo '*** sh /path/to/ver_linux' + ;; +esac PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH echo '-- Versions installed: (if some fields are empty or look' echo '-- unusual then possibly you have very old versions)' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
[Michael D. Crawford]
I found I could mount three partitions on /mnt
Yes. New feature, appeared in the 2.4.0test series, or shortly before.
and they'd all show up as mounted at /mnt in the "mount" command, but
if I unmounted one of them (only tried with the currently visible
one), then it appeared that there were no filesystems mounted there,
but I could continue umounting until the other two were gone.
util-linux gets rather confused by this feature. They say newer
versions fix this.
But I had the 2.10r util-linux sources on my machine and installed
mount and umount from it, and I find that it gets it right mostly
when I mount and unmount multiple things, with the exception that if
/dev/sda5 was mounted before /dev/sda1, then if I give the command
"umount /dev/sda5", sda1 is the one that gets unmounted rather than
sda5, so it takes the most recently mounted filesystem rather than
the one you specify.
I think this is a kernel limitation. 'umount' takes '/dev/sda5' and
turns it into '/mnt/test' and calls umount("/mnt/test"). The kernel
then unmounts whatever is on "top" of /mnt/test.
I don't think there's anything umount can do about this behavior.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: rlim_t and DNS?
[Admin Mailing Lists] > i have no bits directory Really? What version of libc, and on what Linux distro? I thought all versions of glibc2 had /usr/include/bits/. If you are using libc4 or libc5, it is not surprising if the BIND people didn't notice the problem -- they probably didn't try it. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 - can't read root fs (devfs maybe?)
[John Jasen] > E upon careful reading of the devfs/devfsd documentation, > you'll find that it says to put /sbin/devfsd /dev in amongst the > first lines in rc.sysinit. > In looking through rc.sysinit, / is not mounted rw until much later. Who said anything about *re*-mounting '/'? We are talking about having trouble mounting '/' the *first* time, i.e. before rc.sysinit ever gets a chance to run. How did you expect to run /sbin/devfsd when /sbin doesn't exist yet? Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 - can't read root fs (devfs maybe?)
[Michael J. Dikkema] > > I went from 2.4.0 to 2.4.1 and was surprised that either the root > > filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm > > thinking there might have been a change with regards to the devfs > > tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? > > > > I can't even get a shell with init=/bin/bash.. [John Jasen] > Sounds like a lack of devfsd, which handles backwards compatibility > for /dev entries. devfsd does not start up until after the root filesystem is mounted, so that's not it. I don't think you can use the /dev/discs/ link for "root=". It was a long time ago that I ran into this issue -- but as I recall, links with '..' in them do not work before the vfs is fully operational. When I brought it up with Richard he basically said "don't do that then". Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
[me] > > Richard Gooch (devfs author, from Australia) to switch to the American > > spelling of the word, for consistency with the rest of the kernel, and [ac] > Pardon > > include/linux/console_struct.h: unsigned char vc_palette[16*3]; /* >Colour palette for VGA+ */ > include/linux/dio.h:#define DIO_ID2_HRCCATSEYE 0x06 /* highres colour "catseye" */ Ted said it, not me. FWIW I like 'your' spelling of many words (including "colour") better than 'ours' anyway.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
[William Knop]
> How can DevFS know which devices to add to /dev/scsi/... without
> loading the module and scanning the bus first? Or do you manually
> insert the scsi module when you need it?
If you do 'cd /dev/scsi', the kernel looks it up and finds it missing,
which generates a "lookup" event from the kernel to your 'devfsd'
process. (You *do* run devfsd, right?) devfsd then calls 'modprobe
/dev/scsi' (I think that's the default action, you can change it in
/etc/devfsd.conf if you wish). /sbin/modprobe reads /etc/modules.conf
which has an entry like 'alias /dev/scsi sym53c8xx', so when it is
asked to load /dev/scsi it actually loads sym53c8xx. sym53c8xx in turn
triggers the creation of /dev/scsi as it initializes.
So modprobe, having loaded the module, exits. devfsd then replies to
the kernel 'ok, try again, will you please' and the kernel does so, and
this time /dev/scsi/ exists and is accessible.
...And the chdir("/dev/scsi") system call, having waited this whole
time, finally returns successfully. And now you know ... the rest of
the story.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
[Jeremy M. Dolan] > Disk is spelled 'disk' except for Compact Disc and Digital Versatile > Disc. If it wasn't 3:30 in the morning, a patch would be attached. It wouldn't do any good. Many months ago, Ted Ts'o pleaded with Richard Gooch (devfs author, from Australia) to switch to the American spelling of the word, for consistency with the rest of the kernel, and nothing came of it. At this point you may as well consider '/dev/discs' an "interface set in stone". (Come on, do *you* want to explain to thousands of people why their /etc/fstab suddenly broke?) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with Promise IDE controller under 2.4.1
[Rupa Schomaker] > In my case, I have two identical Maxtor drives, but they reported > different geometry. [...] > I'm doing RAID1 and it is really nice to have the same geometry so > that the partition info is the same between the two drives. Makes > life easier. If that's what you needed, you could have used 'dd' to copy the partition table from one drive to the other. Easier than going in and re-cabling just to fool your BIOS. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with Promise IDE controller under 2.4.1
[Rupa Schomaker] In my case, I have two identical Maxtor drives, but they reported different geometry. [...] I'm doing RAID1 and it is really nice to have the same geometry so that the partition info is the same between the two drives. Makes life easier. If that's what you needed, you could have used 'dd' to copy the partition table from one drive to the other. Easier than going in and re-cabling just to fool your BIOS. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
[Jeremy M. Dolan] Disk is spelled 'disk' except for Compact Disc and Digital Versatile Disc. If it wasn't 3:30 in the morning, a patch would be attached. It wouldn't do any good. Many months ago, Ted Ts'o pleaded with Richard Gooch (devfs author, from Australia) to switch to the American spelling of the word, for consistency with the rest of the kernel, and nothing came of it. At this point you may as well consider '/dev/discs' an "interface set in stone". (Come on, do *you* want to explain to thousands of people why their /etc/fstab suddenly broke?) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
[William Knop]
How can DevFS know which devices to add to /dev/scsi/... without
loading the module and scanning the bus first? Or do you manually
insert the scsi module when you need it?
If you do 'cd /dev/scsi', the kernel looks it up and finds it missing,
which generates a "lookup" event from the kernel to your 'devfsd'
process. (You *do* run devfsd, right?) devfsd then calls 'modprobe
/dev/scsi' (I think that's the default action, you can change it in
/etc/devfsd.conf if you wish). /sbin/modprobe reads /etc/modules.conf
which has an entry like 'alias /dev/scsi sym53c8xx', so when it is
asked to load /dev/scsi it actually loads sym53c8xx. sym53c8xx in turn
triggers the creation of /dev/scsi as it initializes.
So modprobe, having loaded the module, exits. devfsd then replies to
the kernel 'ok, try again, will you please' and the kernel does so, and
this time /dev/scsi/ exists and is accessible.
...And the chdir("/dev/scsi") system call, having waited this whole
time, finally returns successfully. And now you know ... the rest of
the story.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
[me] Richard Gooch (devfs author, from Australia) to switch to the American spelling of the word, for consistency with the rest of the kernel, and [ac] Pardon include/linux/console_struct.h: unsigned char vc_palette[16*3]; /* Colour palette for VGA+ */ include/linux/dio.h:#define DIO_ID2_HRCCATSEYE 0x06 /* highres colour "catseye" */ Ted said it, not me. FWIW I like 'your' spelling of many words (including "colour") better than 'ours' anyway.. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
