Further results for kmalloc from linux-tracecalls
It was erroneously asserted by Horst von Brand that 'linux-tracecalls' "can not find where a function could be called through a pointer" On the contrary, almost all the chains are terminated with a callback function, somewhat fewer with an init function, and fewest of all with a syscall. Just for fun here is the first half of the (aggregated) list of all functions terminating chains from our pruned results for kmalloc, marked with the number of chains terminated by each of the 280 functions in this partial list: ( COMMAND was /usr/lib/cgi-bin/lnxtc.pl -file=include/linux/slab.h -func=kmalloc -nohtml=1 \ -prune='drivers/acpi,fs/xfs,kernel/sched.c,kernel/panic.c,mm/oom_kill.c' | perl -00lane 'print $F[0]' | sort | uniq -c | sort -rn | median.pl ) Total chains are 59228 Number of syscalls, callbacks, init functions, etc, terminating chains is 5873 Weighted median is "37 drivers/net/pcmcia/fmvj18x_cs.c::fmvj18x_event" Mean is 10 2156 drivers/scsi/osst.c::osst_ioctl 978 drivers/scsi/osst.c::os_scsi_tape_flush 747 drivers/scsi/osst.c::osst_write 532 fs/jffs2/dir.c::jffs2_rename 455 drivers/scsi/osst.c::osst_read 391 fs/jffs2/dir.c::jffs2_mknod 391 fs/jffs2/dir.c::jffs2_mkdir 391 fs/jffs2/dir.c::jffs2_create 351 fs/hpfs/file.c::hpfs_truncate 330 drivers/usb/media/ov511.c::ov51x_probe 324 fs/hpfs/inode.c::hpfs_notify_change 324 fs/hpfs/file.c::hpfs_file_release 314 drivers/usb/media/ov511.c::ov51x_v4l1_ioctl_internal 286 net/rose/rose_dev.c::rose_rebuild_header 269 fs/jffs2/fs.c::jffs2_setattr 269 fs/jffs2/fs.c::jffs2_dirty_inode 268 fs/jffs2/write.c::jffs2_write_inode_range 268 fs/jffs2/file.c::jffs2_prepare_write 266 fs/jffs2/dir.c::jffs2_symlink 266 fs/jffs2/dir.c::jffs2_rmdir 266 fs/jffs2/dir.c::jffs2_link 243 init/main.c::init 225 fs/hpfs/super.c::hpfs_fill_super 222 net/rose/rose_loopback.c::rose_loopback_timer 220 drivers/usb/media/ov511.c::ov51x_v4l1_open 210 drivers/scsi/qla2xxx/qla_init.c::qla2x00_initialize_adapter 202 fs/hpfs/dir.c::hpfs_lookup 188 fs/hpfs/namei.c::hpfs_mkdir 187 fs/ntfs/super.c::ntfs_fill_super 171 sound/usb/usbaudio.c::usb_audio_probe 171 fs/jffs2/background.c::jffs2_garbage_collect_thread 169 fs/jffs2/fs.c::jffs2_write_super 169 fs/hpfs/namei.c::hpfs_symlink 169 fs/hpfs/namei.c::hpfs_mknod 169 fs/hpfs/namei.c::hpfs_create 169 drivers/net/sk98lin/skge.c::SkGeIoctl 165 net/ipv6/tcp_ipv6.c::tcp_v6_hash 164 fs/jffs2/file.c::jffs2_fsync 161 drivers/net/irda/smsc-ircc2.c::smsc_ircc_init 156 net/ipv6/addrconf.c::addrconf_init 156 fs/cifs/file.c::cifs_readdir 156 drivers/scsi/qla2xxx/qla_init.c::qla2x00_configure_fabric 145 net/bridge/br_ioctl.c::br_ioctl_deviceless_stub 139 drivers/net/sk98lin/skgepnmi.c::DiagActions 138 drivers/scsi/osst.c::os_scsi_tape_open 136 fs/hfsplus/dir.c::hfsplus_rename 135 fs/hfs/dir.c::hfs_rename 134 fs/hfs/extent.c::hfs_get_block 132 security/keys/keyctl.c::sys_keyctl 130 net/ax25/ax25_in.c::ax25_kiss_rcv 129 net/ipv4/udp.c::udp_setsockopt 129 net/ipv4/raw.c::raw_setsockopt 125 net/ipv4/af_inet.c::inet_init 123 drivers/scsi/pcmcia/fdomain_stub.c::fdomain_event 123 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c::ahc_linux_pci_dev_probe 122 drivers/scsi/aic7xxx/aic7770_osm.c::aic7770_eisa_dev_probe 121 net/ipv4/af_inet.c::inet_ioctl 121 fs/nfsd/nfs4proc.c::nfsd4_proc_compound 117 drivers/scsi/pcmcia/qlogic_stub.c::qlogic_event 116 drivers/scsi/aic7xxx/aic79xx_osm_pci.c::ahd_linux_pci_dev_probe 116 drivers/net/pcmcia/smc91c92_cs.c::smc_open 114 net/netrom/nr_loopback.c::nr_loopback_timer 113 sound/usb/usbaudio.c::create_composite_quirk 113 drivers/pcmcia/ds.c::ds_ioctl 111 drivers/net/Space.c::net_olddevs_init 107 drivers/scsi/sata_vsc.c::vsc_sata_init_one 107 drivers/scsi/sata_svw.c::k2_sata_init_one 107 drivers/scsi/sata_promise.c::pdc_ata_init_one 107 drivers/scsi/sata_nv.c::nv_init_one 107 drivers/scsi/ahci.c::ahci_init_one 106 drivers/scsi/sata_via.c::svia_init_one 106 drivers/scsi/sata_uli.c::uli_init_one 106 drivers/scsi/sata_sis.c::sis_init_one 106 drivers/scsi/ata_piix.c::piix_init_one 105 fs/hfsplus/dir.c::hfsplus_link 101 drivers/usb/image/microtek.c::mts_usb_probe 101 drivers/usb/image/hpusbscsi.c::hpusbscsi_usb_probe 101 drivers/scsi/NCR_Q720.c::NCR_Q720_probe 101 drivers/scsi/NCR_D700.c::NCR_D700_probe 100 drivers/scsi/sim710.c::sim710_mca_probe 100 drivers/scsi/sim710.c::sim710_eisa_probe 100 drivers/scsi/BusLogic.c::BusLogic_init 99 drivers/scsi/tmscsim.c::dc390_probe_one 99 drivers/scsi/scsi_debug.c::sdebug_driver_probe 99 drivers/scsi/qlogicfas.c::qlogicfas_init 99 drivers/scsi/dmx3191d.c::dmx3191d_probe_one 98 net/ipv6/ndisc.c::pndisc_redo 98 net/ipv6/icmp.c::icmpv6_rcv
Further results for kmalloc from linux-tracecalls
It was erroneously asserted by Horst von Brand that 'linux-tracecalls' can not find where a function could be called through a pointer On the contrary, almost all the chains are terminated with a callback function, somewhat fewer with an init function, and fewest of all with a syscall. Just for fun here is the first half of the (aggregated) list of all functions terminating chains from our pruned results for kmalloc, marked with the number of chains terminated by each of the 280 functions in this partial list: ( COMMAND was /usr/lib/cgi-bin/lnxtc.pl -file=include/linux/slab.h -func=kmalloc -nohtml=1 \ -prune='drivers/acpi,fs/xfs,kernel/sched.c,kernel/panic.c,mm/oom_kill.c' | perl -00lane 'print $F[0]' | sort | uniq -c | sort -rn | median.pl ) Total chains are 59228 Number of syscalls, callbacks, init functions, etc, terminating chains is 5873 Weighted median is 37 drivers/net/pcmcia/fmvj18x_cs.c::fmvj18x_event Mean is 10 2156 drivers/scsi/osst.c::osst_ioctl 978 drivers/scsi/osst.c::os_scsi_tape_flush 747 drivers/scsi/osst.c::osst_write 532 fs/jffs2/dir.c::jffs2_rename 455 drivers/scsi/osst.c::osst_read 391 fs/jffs2/dir.c::jffs2_mknod 391 fs/jffs2/dir.c::jffs2_mkdir 391 fs/jffs2/dir.c::jffs2_create 351 fs/hpfs/file.c::hpfs_truncate 330 drivers/usb/media/ov511.c::ov51x_probe 324 fs/hpfs/inode.c::hpfs_notify_change 324 fs/hpfs/file.c::hpfs_file_release 314 drivers/usb/media/ov511.c::ov51x_v4l1_ioctl_internal 286 net/rose/rose_dev.c::rose_rebuild_header 269 fs/jffs2/fs.c::jffs2_setattr 269 fs/jffs2/fs.c::jffs2_dirty_inode 268 fs/jffs2/write.c::jffs2_write_inode_range 268 fs/jffs2/file.c::jffs2_prepare_write 266 fs/jffs2/dir.c::jffs2_symlink 266 fs/jffs2/dir.c::jffs2_rmdir 266 fs/jffs2/dir.c::jffs2_link 243 init/main.c::init 225 fs/hpfs/super.c::hpfs_fill_super 222 net/rose/rose_loopback.c::rose_loopback_timer 220 drivers/usb/media/ov511.c::ov51x_v4l1_open 210 drivers/scsi/qla2xxx/qla_init.c::qla2x00_initialize_adapter 202 fs/hpfs/dir.c::hpfs_lookup 188 fs/hpfs/namei.c::hpfs_mkdir 187 fs/ntfs/super.c::ntfs_fill_super 171 sound/usb/usbaudio.c::usb_audio_probe 171 fs/jffs2/background.c::jffs2_garbage_collect_thread 169 fs/jffs2/fs.c::jffs2_write_super 169 fs/hpfs/namei.c::hpfs_symlink 169 fs/hpfs/namei.c::hpfs_mknod 169 fs/hpfs/namei.c::hpfs_create 169 drivers/net/sk98lin/skge.c::SkGeIoctl 165 net/ipv6/tcp_ipv6.c::tcp_v6_hash 164 fs/jffs2/file.c::jffs2_fsync 161 drivers/net/irda/smsc-ircc2.c::smsc_ircc_init 156 net/ipv6/addrconf.c::addrconf_init 156 fs/cifs/file.c::cifs_readdir 156 drivers/scsi/qla2xxx/qla_init.c::qla2x00_configure_fabric 145 net/bridge/br_ioctl.c::br_ioctl_deviceless_stub 139 drivers/net/sk98lin/skgepnmi.c::DiagActions 138 drivers/scsi/osst.c::os_scsi_tape_open 136 fs/hfsplus/dir.c::hfsplus_rename 135 fs/hfs/dir.c::hfs_rename 134 fs/hfs/extent.c::hfs_get_block 132 security/keys/keyctl.c::sys_keyctl 130 net/ax25/ax25_in.c::ax25_kiss_rcv 129 net/ipv4/udp.c::udp_setsockopt 129 net/ipv4/raw.c::raw_setsockopt 125 net/ipv4/af_inet.c::inet_init 123 drivers/scsi/pcmcia/fdomain_stub.c::fdomain_event 123 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c::ahc_linux_pci_dev_probe 122 drivers/scsi/aic7xxx/aic7770_osm.c::aic7770_eisa_dev_probe 121 net/ipv4/af_inet.c::inet_ioctl 121 fs/nfsd/nfs4proc.c::nfsd4_proc_compound 117 drivers/scsi/pcmcia/qlogic_stub.c::qlogic_event 116 drivers/scsi/aic7xxx/aic79xx_osm_pci.c::ahd_linux_pci_dev_probe 116 drivers/net/pcmcia/smc91c92_cs.c::smc_open 114 net/netrom/nr_loopback.c::nr_loopback_timer 113 sound/usb/usbaudio.c::create_composite_quirk 113 drivers/pcmcia/ds.c::ds_ioctl 111 drivers/net/Space.c::net_olddevs_init 107 drivers/scsi/sata_vsc.c::vsc_sata_init_one 107 drivers/scsi/sata_svw.c::k2_sata_init_one 107 drivers/scsi/sata_promise.c::pdc_ata_init_one 107 drivers/scsi/sata_nv.c::nv_init_one 107 drivers/scsi/ahci.c::ahci_init_one 106 drivers/scsi/sata_via.c::svia_init_one 106 drivers/scsi/sata_uli.c::uli_init_one 106 drivers/scsi/sata_sis.c::sis_init_one 106 drivers/scsi/ata_piix.c::piix_init_one 105 fs/hfsplus/dir.c::hfsplus_link 101 drivers/usb/image/microtek.c::mts_usb_probe 101 drivers/usb/image/hpusbscsi.c::hpusbscsi_usb_probe 101 drivers/scsi/NCR_Q720.c::NCR_Q720_probe 101 drivers/scsi/NCR_D700.c::NCR_D700_probe 100 drivers/scsi/sim710.c::sim710_mca_probe 100 drivers/scsi/sim710.c::sim710_eisa_probe 100 drivers/scsi/BusLogic.c::BusLogic_init 99 drivers/scsi/tmscsim.c::dc390_probe_one 99 drivers/scsi/scsi_debug.c::sdebug_driver_probe 99 drivers/scsi/qlogicfas.c::qlogicfas_init 99 drivers/scsi/dmx3191d.c::dmx3191d_probe_one 98 net/ipv6/ndisc.c::pndisc_redo 98 net/ipv6/icmp.c::icmpv6_rcv 96
Linux-tracecalls, a clarification
http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?help
--- Horst von Brand <[EMAIL PROTECTED]> wrote:
> Re: [ANNOUNCE] Linux-tracecalls, a new tool for Kernel development, released
>
> If it can't find out where a function could be called through a pointer
> (very common due to the OOP-in-C style in the kernel) it has no chance.
Dear Doctor von Brand,
I believe the following should clear up your misunderstanding, perhaps due
to my poor original choice of words.
Carl Spalletta
PATCH #2
--- lnxtc-2.6.10.pl-2005-01-21 00:16:33.0 -0500
+++ lnxtc-2.6.10.pl 2005-01-21 00:50:11.0 -0500
@@ -517,10 +517,22 @@
$leaf_node = 0;
$debug and print STDERR "\ncscope line is $full_caller_cscope";
-#Target is a callback
+#TARGET IS A PSEUDO-CALLBACK, AN ARTIFACT OF CSCOPE:
+#
+#The name of an operations structure member, wrongly interpreted by
+#cscope as the name of an actual function - it should be ignored,
+#since it has been confused by cscope with the name of some actual
+#caller. HOWEVER the callbacks are found anyway, under their actual names.
+#and if any function pointed to by a callback is part of a chain to
+#our initial target it _will_ be found, the same as any other caller.
+#
if($full_caller_cscope =~ /\w+\s*->\s*${target_filefunc}\s*\(/)
{
- $debug and print STDERR "callback $target_filefunc ignored.\n";
+ $debug and
+print STDERR "pseudo-callback $target_filefunc ignored.\n";
next;
}
-
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/
Linux-tracecalls, a clarification
http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?help
--- Horst von Brand [EMAIL PROTECTED] wrote:
Re: [ANNOUNCE] Linux-tracecalls, a new tool for Kernel development, released
If it can't find out where a function could be called through a pointer
(very common due to the OOP-in-C style in the kernel) it has no chance.
Dear Doctor von Brand,
I believe the following should clear up your misunderstanding, perhaps due
to my poor original choice of words.
Carl Spalletta
PATCH #2
--- lnxtc-2.6.10.pl-2005-01-21 00:16:33.0 -0500
+++ lnxtc-2.6.10.pl 2005-01-21 00:50:11.0 -0500
@@ -517,10 +517,22 @@
$leaf_node = 0;
$debug and print STDERR \ncscope line is $full_caller_cscope;
-#Target is a callback
+#TARGET IS A PSEUDO-CALLBACK, AN ARTIFACT OF CSCOPE:
+#
+#The name of an operations structure member, wrongly interpreted by
+#cscope as the name of an actual function - it should be ignored,
+#since it has been confused by cscope with the name of some actual
+#caller. HOWEVER the callbacks are found anyway, under their actual names.
+#and if any function pointed to by a callback is part of a chain to
+#our initial target it _will_ be found, the same as any other caller.
+#
if($full_caller_cscope =~ /\w+\s*-\s*${target_filefunc}\s*\(/)
{
- $debug and print STDERR callback $target_filefunc ignored.\n;
+ $debug and
+print STDERR pseudo-callback $target_filefunc ignored.\n;
next;
}
-
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/
Mutation of kernel memory management
http://www.linuxrd.com/~carl/linux-tracecalls/KMALLOC.html#analysis - 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] Linux-tracecalls, a new tool for Kernel development, released
--- Horst von Brand <[EMAIL PROTECTED]> wrote: > If it can't find out where a function could be called through a pointer > (very common due to the OOP-in-C style in the kernel) it has no chance. Dear Horst, No chance of what? You do raise an interesting point. Linux-tracecalls already does "find out where a function could be called through a pointer" internally. Therefore, it would be trivial to add some indication to the the head of the call chain that the subsearch aborted because a callback was detected; and I shall do so in the next release of the tool (which will shortly after kernel.org kernel 2.6.11 is released). The fact that the tool at this stage of development does not do something that it was never designed to do, does not make it worthless. Moreover, I believe the burden of your comments to be ill-considered for the following reasons: The functions you refer to are the callbacks that I have explicitly referred to at http://www.linuxrd.com/~carl/linux-tracecalls : Also, by design, 'linux-tracecalls' will stop tracing when it reaches a syscall, a gcc-builtin function or a callback. I should have further pointed out, were it not so obvious, that if the call chain as produced by the tool begins with function F (ie 'F' is the oldest ancestor of the initial target function) then: 1) You have been saved all the work of doing the tracing manually to that point, not only for that particular chain but for all the chains leading to your initial target function. 2) You can then manually check at function F to see if there is a callback behind it. 3) If you find there is a callback behind F then you can do another query using the actual function represented by the callback as a new initial target. 4) Callbacks - due to the OOP implications you have pointed out - are in most cases ultimately invoked due to syscalls and the core part of the kernel generally (drivers do use OOP of course but it is not the absolute necessity there it is in the case of, for example, the VFS). That being so the paths to the callbacks are generally short ; thus the tool is doing most of the work for you in any case, even in the minority of cases involving a callback. 5) The tool has also done all the macro expansions of function-yielding macros for you, which due to the recursive nature of kernel header files is a major job in itself. At some future date I would like to add the capabilities you suggest - however 'lnxtc.pl' is presently over 800 lines of code and what you are suggesting is at least an order of magnitude harder than what has been accomplished already, so it won't be next week If this tool is really as useless as you suggest then I shall discontinue development. But I strongly disagree. NIH? - 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] Linux-tracecalls, a new tool for Kernel development, released
--- Horst von Brand [EMAIL PROTECTED] wrote: If it can't find out where a function could be called through a pointer (very common due to the OOP-in-C style in the kernel) it has no chance. Dear Horst, No chance of what? You do raise an interesting point. Linux-tracecalls already does find out where a function could be called through a pointer internally. Therefore, it would be trivial to add some indication to the the head of the call chain that the subsearch aborted because a callback was detected; and I shall do so in the next release of the tool (which will shortly after kernel.org kernel 2.6.11 is released). The fact that the tool at this stage of development does not do something that it was never designed to do, does not make it worthless. Moreover, I believe the burden of your comments to be ill-considered for the following reasons: The functions you refer to are the callbacks that I have explicitly referred to at http://www.linuxrd.com/~carl/linux-tracecalls : Also, by design, 'linux-tracecalls' will stop tracing when it reaches a syscall, a gcc-builtin function or a callback. I should have further pointed out, were it not so obvious, that if the call chain as produced by the tool begins with function F (ie 'F' is the oldest ancestor of the initial target function) then: 1) You have been saved all the work of doing the tracing manually to that point, not only for that particular chain but for all the chains leading to your initial target function. 2) You can then manually check at function F to see if there is a callback behind it. 3) If you find there is a callback behind F then you can do another query using the actual function represented by the callback as a new initial target. 4) Callbacks - due to the OOP implications you have pointed out - are in most cases ultimately invoked due to syscalls and the core part of the kernel generally (drivers do use OOP of course but it is not the absolute necessity there it is in the case of, for example, the VFS). That being so the paths to the callbacks are generally short ; thus the tool is doing most of the work for you in any case, even in the minority of cases involving a callback. 5) The tool has also done all the macro expansions of function-yielding macros for you, which due to the recursive nature of kernel header files is a major job in itself. At some future date I would like to add the capabilities you suggest - however 'lnxtc.pl' is presently over 800 lines of code and what you are suggesting is at least an order of magnitude harder than what has been accomplished already, so it won't be next week If this tool is really as useless as you suggest then I shall discontinue development. But I strongly disagree. NIH? - 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/
Mutation of kernel memory management
http://www.linuxrd.com/~carl/linux-tracecalls/KMALLOC.html#analysis - 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-tracecalls, a new tool for Kernel development, released
Only five minutes old, and already a patch ;)
--- lnxtc.pl-old 2005-01-19 12:09:00.0 -0800
+++ lnxtc.pl-new 2005-01-19 12:09:38.0 -0800
@@ -627,6 +627,7 @@
$debug = 0;
}
+$ENV{'PATH'}='/bin:/usr/bin';
#Redirect standard error to logfile (fatals also to browser)
unless($nohtml)
-
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/
[ANNOUNCE] Linux-tracecalls, a new tool for Kernel development, released
>From http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?help "'LINUX-TRACECALLS' finds all call chains leading to a given function in the Linux kernel, to some arbitrary depth. It consists of two parts - a set of specially prepared cscope databases for the kernel source tree, and a perl program, 'lnxtc.pl', to do the call chain discovery based on the information in the cscope DBs." "It works, in part, by expanding function-yielding macros and by mangling function names with the name of the file containing the function's definition, prior to creating the cscope files." "It is believed to be highly accurate.." - 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/
[ANNOUNCE] Linux-tracecalls, a new tool for Kernel development, released
From http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?help 'LINUX-TRACECALLS' finds all call chains leading to a given function in the Linux kernel, to some arbitrary depth. It consists of two parts - a set of specially prepared cscope databases for the kernel source tree, and a perl program, 'lnxtc.pl', to do the call chain discovery based on the information in the cscope DBs. It works, in part, by expanding function-yielding macros and by mangling function names with the name of the file containing the function's definition, prior to creating the cscope files. It is believed to be highly accurate.. - 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-tracecalls, a new tool for Kernel development, released
Only five minutes old, and already a patch ;)
--- lnxtc.pl-old 2005-01-19 12:09:00.0 -0800
+++ lnxtc.pl-new 2005-01-19 12:09:38.0 -0800
@@ -627,6 +627,7 @@
$debug = 0;
}
+$ENV{'PATH'}='/bin:/usr/bin';
#Redirect standard error to logfile (fatals also to browser)
unless($nohtml)
-
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 Kernel Urgently Needed-Open Source Projects
On Monday July 25, 2001 Jasmin Brown wrote: >Aufgaben: >permanente Anpassung wichtiger Systemkomponenten an unsere et cetera Since nobody jumped on the improbably named Yasmin Brown & Jill Simmons for daring to post a classified within these hallowed precincts, I submit herewith my own contribution to interstellar amity - a free translation of the German text from that article: cat << ENDQUOTE die funktionen: ein) Permanent adjustment of important system komponents to our orders. Orders which must be obeyed! In this konnection, program SOURCE projects from Kernel modules mit: zwei) Advancement of our Apache Webservers. drei) Konception and implementation of teufels für our master architecture and elimination of race conditions. fier) Configuration and code modification; for example of GFS, Apache, or Linux kernel. ENDQUOTE I think that was the gist of it. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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 Kernel Urgently Needed-Open Source Projects
On Monday July 25, 2001 Jasmin Brown wrote: Aufgaben: permanente Anpassung wichtiger Systemkomponenten an unsere et cetera Since nobody jumped on the improbably named Yasmin Brown Jill Simmons for daring to post a classified within these hallowed precincts, I submit herewith my own contribution to interstellar amity - a free translation of the German text from that article: cat ENDQUOTE die funktionen: ein) Permanent adjustment of important system komponents to our orders. Orders which must be obeyed! In this konnection, program SOURCE projects from Kernel modules mit: zwei) Advancement of our Apache Webservers. drei) Konception and implementation of teufels für our master architecture and elimination of race conditions. fier) Configuration and code modification; for example of GFS, Apache, or Linux kernel. ENDQUOTE I think that was the gist of it. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - 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/
