Re: [RFC] shutdown machine when li-ion battery goes below 3V
> + res = bq27xxx_battery_voltage(di, ); > + if (res) > + return res; > + > + mV = val.intval / 1000; Reading that code I stumbled over the comment in bq27xxx_battery_voltage saying that it returns millivolts. The code here, the code in bq27xxx_battery_voltage and power_supply.h all indicate that it in fact returns microvolts. Please double-check and fix, as it stands now the code looks inconsistent (but not knowing that device at all I don't feel fit to submit a fix). regards, Olaf
Re: [RFC] shutdown machine when li-ion battery goes below 3V
> + res = bq27xxx_battery_voltage(di, ); > + if (res) > + return res; > + > + mV = val.intval / 1000; Reading that code I stumbled over the comment in bq27xxx_battery_voltage saying that it returns millivolts. The code here, the code in bq27xxx_battery_voltage and power_supply.h all indicate that it in fact returns microvolts. Please double-check and fix, as it stands now the code looks inconsistent (but not knowing that device at all I don't feel fit to submit a fix). regards, Olaf
Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86)
> I am tempted to leave the "flags" argument in place though, along > with the "MEMBARRIER_QUERY" flag. Thoughts ? http://lwn.net/Articles/585415/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86)
I am tempted to leave the flags argument in place though, along with the MEMBARRIER_QUERY flag. Thoughts ? http://lwn.net/Articles/585415/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] tracing: Print nasty banner when trace_printk() is in use
> * > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE** Is it really that bad to warrant this kind of warning? Not knowing about the issue at all, I read from the original description that the wastage is four pages of memory times number of CPU cores, which shouldn't matter much except for small embedded systems. Or does this something much scarier, like considerably slowing down fast paths? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] tracing: Print nasty banner when trace_printk() is in use
* ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE** Is it really that bad to warrant this kind of warning? Not knowing about the issue at all, I read from the original description that the wastage is four pages of memory times number of CPU cores, which shouldn't matter much except for small embedded systems. Or does this something much scarier, like considerably slowing down fast paths? Olaf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODSIGN without RTC?
> Another option would be to make a configure option to just ignore the > date. I'm not sure if I would like to use MODSIGN when I have to fear > that the machine wouldn't start when the RTC fails or got set to a wrong > date. Or just ignore the date unconditionally. After all, when a certificate check fails due to out-of-validity-period, then you can always "fix" that by appropriately setting the clock. So for security, in this application, the date check is outright useless. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODSIGN without RTC?
Another option would be to make a configure option to just ignore the date. I'm not sure if I would like to use MODSIGN when I have to fear that the machine wouldn't start when the RTC fails or got set to a wrong date. Or just ignore the date unconditionally. After all, when a certificate check fails due to out-of-validity-period, then you can always fix that by appropriately setting the clock. So for security, in this application, the date check is outright useless. Olaf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_EXPERT is a booby trap
In article you write: > Interestingly, of the 26 configs that use EXPERT in the default > clause, 15 of them are in drivers/hid (see below). Without looking at the code I assume this is due to copy/paste. Someone perhaps once wrote > ./drivers/hid/Kconfig: default !EXPERT when he really intended > ./drivers/media/common/tuners/Kconfig: default y if !EXPERT Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_EXPERT is a booby trap
In article e1tixga-0008t1...@www.xplot.org you write: Interestingly, of the 26 configs that use EXPERT in the default clause, 15 of them are in drivers/hid (see below). Without looking at the code I assume this is due to copy/paste. Someone perhaps once wrote ./drivers/hid/Kconfig: default !EXPERT when he really intended ./drivers/media/common/tuners/Kconfig: default y if !EXPERT Olaf -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possibly silly Q?
> 200Mb had been filled when it had been umounted from /mnt/bootf8 > repartitioned, mke2fs'd, a journal added and a new label written and then > mounted to /amandatapes. > > Something it seems to me, should have forced the re-init, but didn't. So is Something I stumbled across just a few days ago: fdisk does cause the kernel to re-read the new partitions, but nothing causes udev to create any required new device nodes... Olaf -- 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: Possibly silly Q?
200Mb had been filled when it had been umounted from /mnt/bootf8 repartitioned, mke2fs'd, a journal added and a new label written and then mounted to /amandatapes. Something it seems to me, should have forced the re-init, but didn't. So is Something I stumbled across just a few days ago: fdisk does cause the kernel to re-read the new partitions, but nothing causes udev to create any required new device nodes... Olaf -- 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: [RFC] Documentation about unaligned memory access
> Unaligned memory accesses occur when you try to read N bytes of data starting > from an address that is not evenly divisible by N (i.e. addr % N != 0). Should clarify that you mean "with power-of-two N" - even more strictly this depends on the processor, but I'm pretty sure there is none which supports aligned accesses of N==3... Olaf - 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: [RFC] Documentation about unaligned memory access
Unaligned memory accesses occur when you try to read N bytes of data starting from an address that is not evenly divisible by N (i.e. addr % N != 0). Should clarify that you mean with power-of-two N - even more strictly this depends on the processor, but I'm pretty sure there is none which supports aligned accesses of N==3... Olaf - 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: ipv4 and ipv6 stacks for new link layers?
> In current architecture, you have to patch kernel IPv6 and IPv4 > protocols when you add new link layer that they don't recognize. Which is right, because the IP layer is the place which knows how to map IP addresses to link layer addresses. IP must know its link layer. E.g. it needs a way to decide if the link layer is multicast capable at all. > I think that is worse than allow a new driver to provide a simple > service function which maps IPv4/6 multicast address into link layer > address, when asked. "Link layer address" is not a generic concept at all, even though too much code assumes everything is Ethernet. Olaf - 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: ipv4 and ipv6 stacks for new link layers?
In current architecture, you have to patch kernel IPv6 and IPv4 protocols when you add new link layer that they don't recognize. Which is right, because the IP layer is the place which knows how to map IP addresses to link layer addresses. IP must know its link layer. E.g. it needs a way to decide if the link layer is multicast capable at all. I think that is worse than allow a new driver to provide a simple service function which maps IPv4/6 multicast address into link layer address, when asked. Link layer address is not a generic concept at all, even though too much code assumes everything is Ethernet. Olaf - 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: ipv4 and ipv6 stacks for new link layers?
> This is a pity, because it would be so easy to make the both stacks > totally independent of the actual link layers. It only needs one (or > two) new function pointer in net_device. This function should do the > conversion from IPv4/IPv6 address into corresponding hardware > multicast/broadcast address. You mean, the link layer drivers should know of IP addressing modes? Sounds like a layering violation to me. The mapping from IP to MAC address is (for a good reason) part of the IP specs, not of the Ethernet, Token Ring etc. specs, so the right place to implement it is not the network drivers. Olaf - 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: ipv4 and ipv6 stacks for new link layers?
This is a pity, because it would be so easy to make the both stacks totally independent of the actual link layers. It only needs one (or two) new function pointer in net_device. This function should do the conversion from IPv4/IPv6 address into corresponding hardware multicast/broadcast address. You mean, the link layer drivers should know of IP addressing modes? Sounds like a layering violation to me. The mapping from IP to MAC address is (for a good reason) part of the IP specs, not of the Ethernet, Token Ring etc. specs, so the right place to implement it is not the network drivers. Olaf - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > I've replaced exportfs, mountd and nfsd with a newer version and it > > works now. > > What version were you using? I would really like to know. The system in question was built on a Knoppix release based on Debian Potato, with updates from Woody. Most likely this is the package nfs-kernel-server 1.0-2woody3 based on nfs-utils 1.0, which is the oldest version still to be found on the Debian mirrors. (argh, I should have saved the old binaries and [more important, since the binaries have no version indication] package docs...) Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFiFgxGPw4gdAdiZ0RAvXjAJ0X+BPu8cUg+IHEZRG51KWFKevFTwCfSGCr j+fcUcfnunp1dyCDCrBlUBU= =9Uqx -END PGP SIGNATURE- - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've replaced exportfs, mountd and nfsd with a newer version and it works now. What version were you using? I would really like to know. The system in question was built on a Knoppix release based on Debian Potato, with updates from Woody. Most likely this is the package nfs-kernel-server 1.0-2woody3 based on nfs-utils 1.0, which is the oldest version still to be found on the Debian mirrors. (argh, I should have saved the old binaries and [more important, since the binaries have no version indication] package docs...) Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFiFgxGPw4gdAdiZ0RAvXjAJ0X+BPu8cUg+IHEZRG51KWFKevFTwCfSGCr j+fcUcfnunp1dyCDCrBlUBU= =9Uqx -END PGP SIGNATURE- - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
> Will try your patch tomorrow. ...which does not change anything. (As expected.) Olaf - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
Will try your patch tomorrow. ...which does not change anything. (As expected.) Olaf - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > There is a place where a failed kstrdup could lead to this, but that > is rather unlikely and wouldn't be as reproducible as this seems to > be. > If you boot up and then immediately shutdown does this error trigger, > it does it have to be up for a while? It happens right after booting. I've since disabled the NFS server on that box, and just tried to manually start it, and it gives me this: # /usr/sbin/exportfs -r bigred:/video/rec: Cannot allocate memory That is the first and only export: # cat /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). /video/rec bigred(rw,sync) strace on exportfs shows this:nfsservctl(0x3, 0xbf875824, 0) = - -1 ENOMEM After that, /proc/fs/nfs/export exists and gives the Oops, while /proc/fs/nfsd/export doesn't exist. I don't think however this box is particularly short on memory: MemTotal: 248704 kB MemFree:102780 kB Buffers: 20520 kB Cached: 50692 kB SwapCached: 0 kB Active: 81712 kB Inactive:25160 kB SwapTotal: 0 kB SwapFree:0 kB Dirty:1516 kB Writeback: 0 kB AnonPages: 35672 kB Mapped: 13104 kB Slab: 6960 kB SReclaimable: 3104 kB SUnreclaim: 3856 kB PageTables:692 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:124352 kB Committed_AS: 124528 kB VmallocTotal: 786136 kB VmallocUsed: 7568 kB VmallocChunk: 778508 kB (this is right after booting, DVB drivers loaded and VDR running.) Will try your patch tomorrow. Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdfNoGPw4gdAdiZ0RAjDdAJ4yPltxWuJe21yB9nc2zBooLWJ2TwCaAg1I tNsnDshD1gVpW/FYJ5P9J28= =1zag -END PGP SIGNATURE- - 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: 2.6.19: OOPS in cat /proc/fs/nfs/exports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a place where a failed kstrdup could lead to this, but that is rather unlikely and wouldn't be as reproducible as this seems to be. If you boot up and then immediately shutdown does this error trigger, it does it have to be up for a while? It happens right after booting. I've since disabled the NFS server on that box, and just tried to manually start it, and it gives me this: # /usr/sbin/exportfs -r bigred:/video/rec: Cannot allocate memory That is the first and only export: # cat /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). /video/rec bigred(rw,sync) strace on exportfs shows this:nfsservctl(0x3, 0xbf875824, 0) = - -1 ENOMEM After that, /proc/fs/nfs/export exists and gives the Oops, while /proc/fs/nfsd/export doesn't exist. I don't think however this box is particularly short on memory: MemTotal: 248704 kB MemFree:102780 kB Buffers: 20520 kB Cached: 50692 kB SwapCached: 0 kB Active: 81712 kB Inactive:25160 kB SwapTotal: 0 kB SwapFree:0 kB Dirty:1516 kB Writeback: 0 kB AnonPages: 35672 kB Mapped: 13104 kB Slab: 6960 kB SReclaimable: 3104 kB SUnreclaim: 3856 kB PageTables:692 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:124352 kB Committed_AS: 124528 kB VmallocTotal: 786136 kB VmallocUsed: 7568 kB VmallocChunk: 778508 kB (this is right after booting, DVB drivers loaded and VDR running.) Will try your patch tomorrow. Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdfNoGPw4gdAdiZ0RAjDdAJ4yPltxWuJe21yB9nc2zBooLWJ2TwCaAg1I tNsnDshD1gVpW/FYJ5P9J28= =1zag -END PGP SIGNATURE- - 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/
2.6.19: OOPS in cat /proc/fs/nfs/exports
This is 100% reproducible. It hangs exportfs on shutdown. Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0040 Dec 4 19:50:13 glotze kernel: printing eip: Dec 4 19:50:13 glotze kernel: c017254a Dec 4 19:50:13 glotze kernel: *pde = Dec 4 19:50:13 glotze kernel: Oops: [#1] Dec 4 19:50:13 glotze kernel: PREEMPT Dec 4 19:50:13 glotze kernel: Modules linked in: nfsd exportfs i915 stv0299 budget_ci budget_core dvb_core saa7146 ttpci_eeprom 8250 serial_core nfs lockd sunrpc tuner tvaudio bttv video_buf ir_common compat_ioctl32 i2c_algo_bit btcx_risc tveeprom i2c_core videodev v4l1_compat v4l2_common ipv6 nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ide_cd cdrom e100 mii af_packet Dec 4 19:50:13 glotze kernel: CPU:0 Dec 4 19:50:13 glotze kernel: EIP:0060:[seq_escape+29/201]Not tainted VLI Dec 4 19:50:13 glotze kernel: EFLAGS: 00010286 (2.6.19 #2) Dec 4 19:50:13 glotze kernel: EIP is at seq_escape+0x1d/0xc9 Dec 4 19:50:13 glotze kernel: eax: c761 ebx: c7370e00 ecx: 1000 edx: c761005c Dec 4 19:50:13 glotze kernel: esi: 0040 edi: d0590384 ebp: cd2115f4 esp: c9543ef4 Dec 4 19:50:13 glotze kernel: ds: 007b es: 007b ss: 0068 Dec 4 19:50:13 glotze kernel: Process cat (pid: 1379, ti=c9542000 task=c73ea030 task.ti=c9542000) Dec 4 19:50:13 glotze kernel: Stack: c7370e00 c017219d 0004 c7370e00 0810 cd2115f4 d05878e7 c7370e00 Dec 4 19:50:13 glotze kernel:d059037e d0590343 d059036f fffe fffe 0004 0301 d05969d0 Dec 4 19:50:13 glotze kernel:c7370e00 cd2115c0 0029 c01727c3 0400 0804c848 cb9cb740 c7370e20 Dec 4 19:50:13 glotze kernel: Call Trace: Dec 4 19:50:13 glotze kernel: [seq_printf+46/82] seq_printf+0x2e/0x52 Dec 4 19:50:13 glotze kernel: [pg0+270379239/1069880320] svc_export_show+0x1dd/0x2b1 [nfsd] Dec 4 19:50:13 glotze kernel: [seq_read+461/682] seq_read+0x1cd/0x2aa Dec 4 19:50:13 glotze kernel: [vfs_read+137/325] vfs_read+0x89/0x145 Dec 4 19:50:13 glotze kernel: [seq_read+0/682] seq_read+0x0/0x2aa Dec 4 19:50:13 glotze kernel: [sys_read+65/106] sys_read+0x41/0x6a Dec 4 19:50:13 glotze kernel: [syscall_call+7/11] syscall_call+0x7/0xb Dec 4 19:50:13 glotze kernel: [unix_listen+206/215] unix_listen+0xce/0xd7 Dec 4 19:50:13 glotze kernel: === Dec 4 19:50:13 glotze kernel: Code: fb 37 fe ff 89 f0 83 c4 04 5b 5e 5f 5d c3 55 57 56 53 83 ec 08 89 04 24 89 d6 89 cf 89 c2 8b 00 8b 4a 04 89 c2 8b 1c 24 03 53 0c <0f> b6 1e 84 db 74 7d 01 c8 89 44 24 04 39 d0 76 73 89 f5 eb 44 Dec 4 19:50:13 glotze kernel: EIP: [seq_escape+29/201] seq_escape+0x1d/0xc9 SS:ESP 0068:c9543ef4 Dec 4 19:50:13 glotze kernel: <6>note: cat[1379] exited with preempt_count 1 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19 # Sun Dec 3 22:37:06 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=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=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # 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" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is
2.6.19: OOPS in cat /proc/fs/nfs/exports
This is 100% reproducible. It hangs exportfs on shutdown. Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0040 Dec 4 19:50:13 glotze kernel: printing eip: Dec 4 19:50:13 glotze kernel: c017254a Dec 4 19:50:13 glotze kernel: *pde = Dec 4 19:50:13 glotze kernel: Oops: [#1] Dec 4 19:50:13 glotze kernel: PREEMPT Dec 4 19:50:13 glotze kernel: Modules linked in: nfsd exportfs i915 stv0299 budget_ci budget_core dvb_core saa7146 ttpci_eeprom 8250 serial_core nfs lockd sunrpc tuner tvaudio bttv video_buf ir_common compat_ioctl32 i2c_algo_bit btcx_risc tveeprom i2c_core videodev v4l1_compat v4l2_common ipv6 nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc ide_cd cdrom e100 mii af_packet Dec 4 19:50:13 glotze kernel: CPU:0 Dec 4 19:50:13 glotze kernel: EIP:0060:[seq_escape+29/201]Not tainted VLI Dec 4 19:50:13 glotze kernel: EFLAGS: 00010286 (2.6.19 #2) Dec 4 19:50:13 glotze kernel: EIP is at seq_escape+0x1d/0xc9 Dec 4 19:50:13 glotze kernel: eax: c761 ebx: c7370e00 ecx: 1000 edx: c761005c Dec 4 19:50:13 glotze kernel: esi: 0040 edi: d0590384 ebp: cd2115f4 esp: c9543ef4 Dec 4 19:50:13 glotze kernel: ds: 007b es: 007b ss: 0068 Dec 4 19:50:13 glotze kernel: Process cat (pid: 1379, ti=c9542000 task=c73ea030 task.ti=c9542000) Dec 4 19:50:13 glotze kernel: Stack: c7370e00 c017219d 0004 c7370e00 0810 cd2115f4 d05878e7 c7370e00 Dec 4 19:50:13 glotze kernel:d059037e d0590343 d059036f fffe fffe 0004 0301 d05969d0 Dec 4 19:50:13 glotze kernel:c7370e00 cd2115c0 0029 c01727c3 0400 0804c848 cb9cb740 c7370e20 Dec 4 19:50:13 glotze kernel: Call Trace: Dec 4 19:50:13 glotze kernel: [seq_printf+46/82] seq_printf+0x2e/0x52 Dec 4 19:50:13 glotze kernel: [pg0+270379239/1069880320] svc_export_show+0x1dd/0x2b1 [nfsd] Dec 4 19:50:13 glotze kernel: [seq_read+461/682] seq_read+0x1cd/0x2aa Dec 4 19:50:13 glotze kernel: [vfs_read+137/325] vfs_read+0x89/0x145 Dec 4 19:50:13 glotze kernel: [seq_read+0/682] seq_read+0x0/0x2aa Dec 4 19:50:13 glotze kernel: [sys_read+65/106] sys_read+0x41/0x6a Dec 4 19:50:13 glotze kernel: [syscall_call+7/11] syscall_call+0x7/0xb Dec 4 19:50:13 glotze kernel: [unix_listen+206/215] unix_listen+0xce/0xd7 Dec 4 19:50:13 glotze kernel: === Dec 4 19:50:13 glotze kernel: Code: fb 37 fe ff 89 f0 83 c4 04 5b 5e 5f 5d c3 55 57 56 53 83 ec 08 89 04 24 89 d6 89 cf 89 c2 8b 00 8b 4a 04 89 c2 8b 1c 24 03 53 0c 0f b6 1e 84 db 74 7d 01 c8 89 44 24 04 39 d0 76 73 89 f5 eb 44 Dec 4 19:50:13 glotze kernel: EIP: [seq_escape+29/201] seq_escape+0x1d/0xc9 SS:ESP 0068:c9543ef4 Dec 4 19:50:13 glotze kernel: 6note: cat[1379] exited with preempt_count 1 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19 # Sun Dec 3 22:37:06 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=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=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # 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 # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set #
Re: uninterruptible sleep lockups
In article <[EMAIL PROTECTED]> you write: > The most recent one was yesterday: I had run lsusb in the morning and had no > problems, but at the end of the day I ran it again, and after outputting 3 > lines of data, it hung, stuck in D-state. So now I have this: > > [/home/user]$ ps aux|grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root92 0.0 0.0 00 ?DFeb19 0:00 [khubd] > root 845 0.0 0.0 00 ?DFeb19 0:00 [knodemgrd_0] > root 29016 0.0 0.1 1512 592 ?D00:28 0:00 lsusb I'm getting fairly repeatable deadlocks of this kind involving khubd with a USB storage device. Perhaps there's just a faulty locking issue in khubd. Olaf PS. Linux 2.6.9 - 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: uninterruptible sleep lockups
In article [EMAIL PROTECTED] you write: The most recent one was yesterday: I had run lsusb in the morning and had no problems, but at the end of the day I ran it again, and after outputting 3 lines of data, it hung, stuck in D-state. So now I have this: [/home/user]$ ps aux|grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root92 0.0 0.0 00 ?DFeb19 0:00 [khubd] root 845 0.0 0.0 00 ?DFeb19 0:00 [knodemgrd_0] root 29016 0.0 0.1 1512 592 ?D00:28 0:00 lsusb I'm getting fairly repeatable deadlocks of this kind involving khubd with a USB storage device. Perhaps there's just a faulty locking issue in khubd. Olaf PS. Linux 2.6.9 - 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: Kernel bug with UNIX sockets not detecting other end gone?
> kernel does know that it has been 'disconnected'. One can even justify the > inconcsistent behavior -- the write definitely has no place to go (now), but > the read can't be totally sure that there is no possible way anybody could > ever find the other end and write to it. For a socket created with socketpair()? I'm pretty sure there is no way for any program to find any path to it, and if there is, it's a kernel bug. Such a socket does not have a legitimate name. (And getsockname() reliably returns garbage, which is another bug IMHO.) Olaf - 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: Kernel bug with UNIX sockets not detecting other end gone?
kernel does know that it has been 'disconnected'. One can even justify the inconcsistent behavior -- the write definitely has no place to go (now), but the read can't be totally sure that there is no possible way anybody could ever find the other end and write to it. For a socket created with socketpair()? I'm pretty sure there is no way for any program to find any path to it, and if there is, it's a kernel bug. Such a socket does not have a legitimate name. (And getsockname() reliably returns garbage, which is another bug IMHO.) Olaf - 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: Question about ipip implementation
> Well, I understand that ipip_rcv does some work cleaning sk_buff. > But why after that sk_buff cannot be submitted to ip_rcv, not > netif_rx? Oops, now I see that you're talking about ip_rcv, not netif_rx... I'm doing roughly what you're proposing in CIPE (get IP packet encapsulated in UDP packet via UDP receiver mechanism, strip UDP and optional SOCKS5 headers, submit to processing) but I'm using netif_rx simply because I copied code from the ipip driver ;-) (and because this is the standard way a network driver is supposed to submit input). I'm not exactly sure if it is supposed to be possible to deliver directly into ip_rcv. The code which gets invoked after queuing (net_rx_action() in net/core/dev.c) does something more than just dispatching into the receiver, like handling diversion and bridges, and manipulates fields of the skb itself. Olaf - 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: Question about ipip implementation
Well, I understand that ipip_rcv does some work cleaning sk_buff. But why after that sk_buff cannot be submitted to ip_rcv, not netif_rx? Oops, now I see that you're talking about ip_rcv, not netif_rx... I'm doing roughly what you're proposing in CIPE (get IP packet encapsulated in UDP packet via UDP receiver mechanism, strip UDP and optional SOCKS5 headers, submit to processing) but I'm using netif_rx simply because I copied code from the ipip driver ;-) (and because this is the standard way a network driver is supposed to submit input). I'm not exactly sure if it is supposed to be possible to deliver directly into ip_rcv. The code which gets invoked after queuing (net_rx_action() in net/core/dev.c) does something more than just dispatching into the receiver, like handling diversion and bridges, and manipulates fields of the skb itself. Olaf - 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: Question about ipip implementation
> Yes, I was wrong. But is it possible in similar situation just call > ip_rcv for the sk_buff? What does "just call" mean? The additional setup done by the ipip receiver is the minimum necessary to get the various parameters in the sk_buff in a clean state (things like making sure all header pointers are valid, clearing the private options field etc). These are either done by all network drivers, or are necessary because we use an existing and already handled (as opposed to newly allocated) sk_buff. Olaf - 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: Question about ipip implementation
Yes, I was wrong. But is it possible in similar situation just call ip_rcv for the sk_buff? What does just call mean? The additional setup done by the ipip receiver is the minimum necessary to get the various parameters in the sk_buff in a clean state (things like making sure all header pointers are valid, clearing the private options field etc). These are either done by all network drivers, or are necessary because we use an existing and already handled (as opposed to newly allocated) sk_buff. Olaf - 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: Question about ipip implementation
> I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
> "unwrapping" tunelled IP packet creates "virtual Ethernet header" and submit
Does it? ipip_rcv() does this:
iph = skb->nh.iph;
skb->mac.raw = skb->nh.raw;
i.e. the "MAC header" pointer of the packet is the same as the IP
header, iow. no MAC header available
skb->nh.raw = skb->data;
Although I don't exactly understand this :-) it does not add a header
memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options));
this must be cleared before processing the packet
skb->protocol = __constant_htons(ETH_P_IP);
skb->pkt_type = PACKET_HOST;
mark it as an IP packet
read_lock(_lock);
if ((tunnel = ipip_tunnel_lookup(iph->saddr, iph->daddr)) != NULL) {
tunnel->stat.rx_packets++;
tunnel->stat.rx_bytes += skb->len;
skb->dev = tunnel->dev;
mark the incoming device
dst_release(skb->dst);
skb->dst = NULL;
#ifdef CONFIG_NETFILTER
nf_conntrack_put(skb->nfct);
skb->nfct = NULL;
#ifdef CONFIG_NETFILTER_DEBUG
skb->nf_debug = 0;
#endif
#endif
more clearing of fields / release of resources associated with the packet
ipip_ecn_decapsulate(iph, skb);
handle ECN flags
netif_rx(skb);
The packet as submitted starts with the IP header and the skb pointers
are set up so that the MAC header has zero size.
Olaf
-
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: Question about ipip implementation
I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
unwrapping tunelled IP packet creates virtual Ethernet header and submit
Does it? ipip_rcv() does this:
iph = skb-nh.iph;
skb-mac.raw = skb-nh.raw;
i.e. the MAC header pointer of the packet is the same as the IP
header, iow. no MAC header available
skb-nh.raw = skb-data;
Although I don't exactly understand this :-) it does not add a header
memset((IPCB(skb)-opt), 0, sizeof(struct ip_options));
this must be cleared before processing the packet
skb-protocol = __constant_htons(ETH_P_IP);
skb-pkt_type = PACKET_HOST;
mark it as an IP packet
read_lock(ipip_lock);
if ((tunnel = ipip_tunnel_lookup(iph-saddr, iph-daddr)) != NULL) {
tunnel-stat.rx_packets++;
tunnel-stat.rx_bytes += skb-len;
skb-dev = tunnel-dev;
mark the incoming device
dst_release(skb-dst);
skb-dst = NULL;
#ifdef CONFIG_NETFILTER
nf_conntrack_put(skb-nfct);
skb-nfct = NULL;
#ifdef CONFIG_NETFILTER_DEBUG
skb-nf_debug = 0;
#endif
#endif
more clearing of fields / release of resources associated with the packet
ipip_ecn_decapsulate(iph, skb);
handle ECN flags
netif_rx(skb);
The packet as submitted starts with the IP header and the skb pointers
are set up so that the MAC header has zero size.
Olaf
-
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] SMP race in ext2 - metadata corruption.
> or such. tar/cpio and friends don't deal properly with > a. holes inside of files. > b. hardlinks between files. GNU tar handles both of these. (Not particularly efficiently in the case of sparse files, but that's a minor issue in this case.) See -S flag. Perhaps more importantly, for a _robust_ backup solution which can deal with partially unreadable tapes, you have pretty much no option other than tar for the actual storage. Olaf - 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] SMP race in ext2 - metadata corruption.
or such. tar/cpio and friends don't deal properly with a. holes inside of files. b. hardlinks between files. GNU tar handles both of these. (Not particularly efficiently in the case of sparse files, but that's a minor issue in this case.) See -S flag. Perhaps more importantly, for a _robust_ backup solution which can deal with partially unreadable tapes, you have pretty much no option other than tar for the actual storage. Olaf - 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: Request for comment -- a better attribution system
> * you've ignored the robustness of design behind the UNIX kernel. > These beasts keep going without falling apart even after serious injuries. Do you mean design or operation? In fact UNIX design has a number of serious errors/problems, we just have gotten accustomed to it so much that we don't care any more. Here the robustness is in fact inertia. Robust operation is possible with any halfway cleanly designed system, cf. VMS. Olaf - 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: Request for comment -- a better attribution system
* you've ignored the robustness of design behind the UNIX kernel. These beasts keep going without falling apart even after serious injuries. Do you mean design or operation? In fact UNIX design has a number of serious errors/problems, we just have gotten accustomed to it so much that we don't care any more. Here the robustness is in fact inertia. Robust operation is possible with any halfway cleanly designed system, cf. VMS. Olaf - 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: light weight user level semaphores
> This is guaranteed behaviour of UNIX. You get file handles in order, or
> you don't get them at all.
You get the _next free_ file handle in order. What if your program
assumes they are all contiguous, and it is called by some other
program which forgot about FD_CLOEXEC and has some higher fds still
open? (xdm did this for ten years with its listening socket, just to
name a well-known example. So every program which asssumes contiguous
fd allocations would fail if started from an xdm session.)
If your program makes assumptions on its environment which are not
guaranteed it's broken.
What _is_ guaranteed is that after consecutive allocations of fds like
for (i=0; i fd[j] if (i > j and fd[i]!=-1 and fd[j]!=-1).
What is absolutely nowhere guaranteed is that
fd[i+1] = fd[i]+1.
It is not possible to guarantee this since any fd may be already open
before main() starts.
Of course you can guarantee that the fds are available like this:
for (i=getdtablesize(); i>=0; --i)
close(i);
and not calling library functions which may open fds.
> pid = fork();
> if (!pid) {
> close(0);
> close(1);
> dup(pipe[0]); /* input pipe */
> dup(pipe[1]); /* output pipe */
> execve("child");
> exit(1);
> }
>
> The above is absolutely _standard_ behaviour. It's required to work.
The reason why it works is that (a) the target fds are 0 and 1, and
(b) you close them explicitly. For less trivial uses, there is always
dup2().
> And btw, it's _still_ required to work even if there happens to be a
> "malloc()" in between the close() and the dup() calls.
I wouldn't count on that. It's clearly not required to work if there's
a getpwnam() in between. (I already had my share of problems with
syslog() in exactly this situation.)
Do we need a list of library functions which may open fds, like the
infamous "list of functions which may move or purge memory" on the Mac
(which grew longer with every OS release and Inside Mac supplement
issue)? Do we need to know for each library routine how it is
implemented?
> Trust me. You're arguing for clearly broken behaviour. malloc() and
> friends MUST NOT open file descriptors. It _will_ break programs that
> rely on traditional and documented features.
Traditional and documented is, in my view, the description as of the
open(2) man page:
When the
call is successful, the file descriptor returned will be
the lowest file descriptor not currently open for the proÂ
cess.
which of course is exactly how it is implemented in the kernel.
Olaf
-
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: light weight user level semaphores
This is guaranteed behaviour of UNIX. You get file handles in order, or
you don't get them at all.
You get the _next free_ file handle in order. What if your program
assumes they are all contiguous, and it is called by some other
program which forgot about FD_CLOEXEC and has some higher fds still
open? (xdm did this for ten years with its listening socket, just to
name a well-known example. So every program which asssumes contiguous
fd allocations would fail if started from an xdm session.)
If your program makes assumptions on its environment which are not
guaranteed it's broken.
What _is_ guaranteed is that after consecutive allocations of fds like
for (i=0; in; ++i)
fd[i]=open(...);
the following property holds:
fd[i] fd[j] if (i j and fd[i]!=-1 and fd[j]!=-1).
What is absolutely nowhere guaranteed is that
fd[i+1] = fd[i]+1.
It is not possible to guarantee this since any fd may be already open
before main() starts.
Of course you can guarantee that the fds are available like this:
for (i=getdtablesize(); i=0; --i)
close(i);
and not calling library functions which may open fds.
pid = fork();
if (!pid) {
close(0);
close(1);
dup(pipe[0]); /* input pipe */
dup(pipe[1]); /* output pipe */
execve("child");
exit(1);
}
The above is absolutely _standard_ behaviour. It's required to work.
The reason why it works is that (a) the target fds are 0 and 1, and
(b) you close them explicitly. For less trivial uses, there is always
dup2().
And btw, it's _still_ required to work even if there happens to be a
"malloc()" in between the close() and the dup() calls.
I wouldn't count on that. It's clearly not required to work if there's
a getpwnam() in between. (I already had my share of problems with
syslog() in exactly this situation.)
Do we need a list of library functions which may open fds, like the
infamous "list of functions which may move or purge memory" on the Mac
(which grew longer with every OS release and Inside Mac supplement
issue)? Do we need to know for each library routine how it is
implemented?
Trust me. You're arguing for clearly broken behaviour. malloc() and
friends MUST NOT open file descriptors. It _will_ break programs that
rely on traditional and documented features.
Traditional and documented is, in my view, the description as of the
open(2) man page:
When the
call is successful, the file descriptor returned will be
the lowest file descriptor not currently open for the pro
cess.
which of course is exactly how it is implemented in the kernel.
Olaf
-
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: light weight user level semaphores
> Optimization use in select: If all "interesting" file id's are known
> to be below "n", then only the first "n" bits in a FD_ISSET need to
> be examined. As soon as the bits are scattered, it takes MUCH longer
> to check for activity
That's an optimization, not a correctness issue.
> for (i = 0; i <= MAX_LOG && i < argc; i++) {
> sprintf(str,"/tmp/%s",pnames[i]);
> mkfifo(str,0600); /* assume it exists */
> inlogfd[i] = open(str,O_RDONLY | O_NDELAY);
> FD_SET(inlogfd[i],_files);
> }
This works regardless of what the open() returns. What does not work
is using MAX_LOG (assuming it is constant) later in the following form:
> while (select(MAX_LOG,,NULL,NULL,NULL) >= 0) {
I see no way around computing the maximum of the inlogfd[i] values +1.
(Which can of course be done just after the opens above. Note that the
last opened fd _is_ guaranteed to get the highest number; FD_SET is
one of the library routines where you can be pretty confident they
don't open fds...)
Btw. there are two problems even assuming you do get contiguous fds:
- an off by one error in the case of argc > MAX_LOG, the first
argument of select() is maximum fd _plus one_
- from an optimization POV it is highly advisable to take only the
real maximum anyway.
Olaf
-
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: light weight user level semaphores
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection), programs _will_ break.
Of course, but this is a result from sloppy coding. In general, open()
can just return anything and about the only case where you can even
think of ignoring its result is this:
close(0); close(1); close(2);
open("/dev/null", O_RDWR); dup(0); dup(0);
(which is even not clean for other reasons).
I can't imagine depending on the "fact" that the first fd I open is 3,
the next is 4, etc. And what if the routine in question is not
malloc() but e.g. getpwuid()? Both are just arbitrary library
functions, and one of them clearly does open file descriptors,
depending on their implementation.
What would the reason[1] be for wanting contiguous fd space anyway?
Olaf
[1] apart from not having understood how poll() works of course.
-
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: light weight user level semaphores
Ehh.. I will bet you $10 USD that if libc allocates the next file
descriptor on the first "malloc()" in user space (in order to use the
semaphores for mm protection), programs _will_ break.
Of course, but this is a result from sloppy coding. In general, open()
can just return anything and about the only case where you can even
think of ignoring its result is this:
close(0); close(1); close(2);
open("/dev/null", O_RDWR); dup(0); dup(0);
(which is even not clean for other reasons).
I can't imagine depending on the "fact" that the first fd I open is 3,
the next is 4, etc. And what if the routine in question is not
malloc() but e.g. getpwuid()? Both are just arbitrary library
functions, and one of them clearly does open file descriptors,
depending on their implementation.
What would the reason[1] be for wanting contiguous fd space anyway?
Olaf
[1] apart from not having understood how poll() works of course.
-
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: SCSI tape test results
> Still have to test copying from a SCSI disk on the same bus as the > tape drive. Done (tar c/tar d), no corruption. Olaf - 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: light weight user level semaphores
> problems: just _how_ high woul dyou move it? Would it potentially disturb > an application that opens thousands of files, and knows that they get > consecutive file descriptors? Which is _legal_ and well-defined in UNIX. Only if you close them before. The process may have been started with arbitrary fds open. > say "if you use fast semaphores, they use file descriptors and you should > no longer depend on consecutive fd's". Which you cannot anyway. Already some library routines can open fds although they don't explicitly say so and don't have to in all implementations, like openlog() or all the get*by*() stuff (or even dlopen()), so you are never sure to know which or how many FDs you actually have open. Olaf - 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/
SCSI tape test results
I tested my systems to try to reproduce the recently reported SCSI tape corruptions. I did not find any errors, the tape works OK. Linux version 2.4.3 (olaf@bigred) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Sat Mar 31 11:51:54 CEST 2001 K6-III-400, 96MB NCR53C815 SCSI controller HP C1533A DDS-2 tape drive Tape drive compression turned off These were the tests: 1. Copied (with "cp") and verified (with "cmp") two 650MB CD images from an NFS server. 2. In a directory on an IDE disk: tar cSvf /dev/tape . tar df /dev/tape . 3. On the same disk, ~6.5GB directory: tar cSf - . | tarmill -F1500 -m8M -C6M zip 3 list >/dev/tape tarmill -m8M -C6M unzip http://sites.inka.de/~bigred/sw/>. It reads/writes in blocks the same size as tar, just in case this is relevant.) Still have to test copying from a SCSI disk on the same bus as the tape drive. Olaf - 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/
SCSI tape test results
I tested my systems to try to reproduce the recently reported SCSI tape corruptions. I did not find any errors, the tape works OK. Linux version 2.4.3 (olaf@bigred) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Sat Mar 31 11:51:54 CEST 2001 K6-III-400, 96MB NCR53C815 SCSI controller HP C1533A DDS-2 tape drive Tape drive compression turned off These were the tests: 1. Copied (with "cp") and verified (with "cmp") two 650MB CD images from an NFS server. 2. In a directory on an IDE disk: tar cSvf /dev/tape . tar df /dev/tape . 3. On the same disk, ~6.5GB directory: tar cSf - . | tarmill -F1500 -m8M -C6M zip 3 list /dev/tape tarmill -m8M -C6M unzip /dev/tape | tar df - (tarmill is a tar archive compression/encryption program, available from URL:http://sites.inka.de/~bigred/sw/. It reads/writes in blocks the same size as tar, just in case this is relevant.) Still have to test copying from a SCSI disk on the same bus as the tape drive. Olaf - 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: light weight user level semaphores
problems: just _how_ high woul dyou move it? Would it potentially disturb an application that opens thousands of files, and knows that they get consecutive file descriptors? Which is _legal_ and well-defined in UNIX. Only if you close them before. The process may have been started with arbitrary fds open. say "if you use fast semaphores, they use file descriptors and you should no longer depend on consecutive fd's". Which you cannot anyway. Already some library routines can open fds although they don't explicitly say so and don't have to in all implementations, like openlog() or all the get*by*() stuff (or even dlopen()), so you are never sure to know which or how many FDs you actually have open. Olaf - 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: SCSI tape test results
Still have to test copying from a SCSI disk on the same bus as the tape drive. Done (tar c/tar d), no corruption. Olaf - 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: IP Acounting Idea for 2.5
> Umm, no. Counters can be resetable - you just specify that accounting > programs should not reset them, ever. > > The ability to reset counters is extremely useful if you're a human > looking at the output of iptables -L -v. (I thus far know of no one > who can memorise the counter values for around 40 rules). You'll get bogus accounting results unless you stop/restart the accounting programs every time you manually deal with the counters. This sounds dangerously easy to make mistakes to me. Olaf - 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
> > 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? Of course it does; in an idiosyncratic way (not directly using X resources) but it does use the X resource file syntax. > If it does, it's not in any of the documentation I've ever seen. It's in Ousterhout's Tcl/Tk book as well as in the Perl/Tk intro by Walsh. ;-) Tk calls this "option database" or similar. The only catch is that it needs to be explicitly loaded, see "optionReadfile" (at least that's what it's called in perl/tk). Olaf - 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: IP Acounting Idea for 2.5
> Similarly, if my InPackets are at 102345 at one read, and 2345 the > next read, and I know that my counter is 32 bits, then I know i've > wrapped and can do my own math. No. When you have resettable counters, you don't know if the counter has wrapped or been reset. Either you have received 2345 packets in between, or 2^32-102345. The difference is not negligible. ;-) Unless you have a second counter which is incremented with every wrap (_or_, perhaps better, with every reset) and can _not_ be reset manually. This would be the date in your date/time example. Olaf - 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
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? Of course it does; in an idiosyncratic way (not directly using X resources) but it does use the X resource file syntax. If it does, it's not in any of the documentation I've ever seen. It's in Ousterhout's Tcl/Tk book as well as in the Perl/Tk intro by Walsh. ;-) Tk calls this "option database" or similar. The only catch is that it needs to be explicitly loaded, see "optionReadfile" (at least that's what it's called in perl/tk). Olaf - 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: IP Acounting Idea for 2.5
Similarly, if my InPackets are at 102345 at one read, and 2345 the next read, and I know that my counter is 32 bits, then I know i've wrapped and can do my own math. No. When you have resettable counters, you don't know if the counter has wrapped or been reset. Either you have received 2345 packets in between, or 2^32-102345. The difference is not negligible. ;-) Unless you have a second counter which is incremented with every wrap (_or_, perhaps better, with every reset) and can _not_ be reset manually. This would be the date in your date/time example. Olaf - 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: IP Acounting Idea for 2.5
Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever. The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules). You'll get bogus accounting results unless you stop/restart the accounting programs every time you manually deal with the counters. This sounds dangerously easy to make mistakes to me. Olaf - 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.1, wiuth experimental fast mode
[Warning: historical reference ahead.] > > I'd appreciate it if some of you with slow machines would try running > > with fast mode on and seeing if that addresses the sluggishness. > > I assume that, eventually there will be no slow mode or fast mode > distinction... just a single fast mode. Right? :) Perhaps not, if fast mode won't display on the screen while running, or such things... ;-) Olaf - 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: CML1 cleanup patch
> And the problem is that this hits a fast path in the classical news spool
> layout article create path. The code for this assumes that you have
> articles in the range X to Y, and you just got a new article, so you write
> a file called /var/spool/news/group/name/Y+1. You really do not want to
> cope with the possibility of a directory Y+1 existing in that place.
C News did this, actually: if creat(.../name/Y+1) fails, it tries
creat(.../name/Y+2), etc. (IIRC up to 1000 times). This does not really
hurt a fast path: either you do
sprintf(a, "...", artno);
if (creat(a, ...)<0) {
syslog(...);
return FAILED;
}
or
while (sprintf(a, "...", artno),
creat(a, ...)<0) {
++artno;
if (++count>MAX) {
syslog(...);
return FAILED;
}
}
it's just one compare in the fast path which you need anyway.
(Initializing the counter does not _have_ to happen for each article.)
What would hurt is a stat() here, but that is not necessary. It could
be necessary in expire and/or maintenance tools, but these are not as
time-critical. The all-numerics mess up things like "find the lowest
article number" (makeactive/renumber/however it is called), in these
cases a stat is really necessary.
However I think the point is moot because the traditional spool layout
has been proven by experience to be inadequate for the job, even in
the face of more sophisticated filesystems - modern news systems need
other storage mechanisms to cope with the load anyway.
> And then, it's an ugly user interface: the classical spool layout does
> assume that you look at that scpool with Unix tools (like find and grep),
> not only via NNTP and the server.
INN needs a "storage manager grep", but that's even more off topic
here :-)
Olaf
-
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: SCSI tape corruption problem
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k I have a tool which compresses individual files in a tar archive instead of the whole archive[1]. That one tries hard to write only in standard 10kb blocks to emulate tar's behavior towards the drive. I'll try in a few days (when I'm back from holidays) if I have this error on my scsi tape too (bad) and if the compression program affects it. Olaf [1] http://sites.inka.de/bigred/sw/tarmill-0.22.tar.gz> - 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: SCSI tape corruption problem
tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k I have a tool which compresses individual files in a tar archive instead of the whole archive[1]. That one tries hard to write only in standard 10kb blocks to emulate tar's behavior towards the drive. I'll try in a few days (when I'm back from holidays) if I have this error on my scsi tape too (bad) and if the compression program affects it. Olaf [1] URL:http://sites.inka.de/bigred/sw/tarmill-0.22.tar.gz - 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.1, wiuth experimental fast mode
[Warning: historical reference ahead.] I'd appreciate it if some of you with slow machines would try running with fast mode on and seeing if that addresses the sluggishness. I assume that, eventually there will be no slow mode or fast mode distinction... just a single fast mode. Right? :) Perhaps not, if fast mode won't display on the screen while running, or such things... ;-) Olaf - 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: CML1 cleanup patch
And the problem is that this hits a fast path in the classical news spool
layout article create path. The code for this assumes that you have
articles in the range X to Y, and you just got a new article, so you write
a file called /var/spool/news/group/name/Y+1. You really do not want to
cope with the possibility of a directory Y+1 existing in that place.
C News did this, actually: if creat(.../name/Y+1) fails, it tries
creat(.../name/Y+2), etc. (IIRC up to 1000 times). This does not really
hurt a fast path: either you do
sprintf(a, "...", artno);
if (creat(a, ...)0) {
syslog(...);
return FAILED;
}
or
while (sprintf(a, "...", artno),
creat(a, ...)0) {
++artno;
if (++countMAX) {
syslog(...);
return FAILED;
}
}
it's just one compare in the fast path which you need anyway.
(Initializing the counter does not _have_ to happen for each article.)
What would hurt is a stat() here, but that is not necessary. It could
be necessary in expire and/or maintenance tools, but these are not as
time-critical. The all-numerics mess up things like "find the lowest
article number" (makeactive/renumber/however it is called), in these
cases a stat is really necessary.
However I think the point is moot because the traditional spool layout
has been proven by experience to be inadequate for the job, even in
the face of more sophisticated filesystems - modern news systems need
other storage mechanisms to cope with the load anyway.
And then, it's an ugly user interface: the classical spool layout does
assume that you look at that scpool with Unix tools (like find and grep),
not only via NNTP and the server.
INN needs a "storage manager grep", but that's even more off topic
here :-)
Olaf
-
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: goodbye
> It scares me that peoples' messages would be denied based on what > degree of connection they choose to mail via. I sincerely hope that > the DUL lists only list netblocks that are actively being used for > spam. This would be sort of like the Usenet Death Penalty, instating > bans on providers who refuse to deal with spamming. I think that's a There's another list to do that: the original RBL. The DUL is only and explicitly for the purpose of denying access based on the degree of connection the users can afford. Olaf - 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: goodbye
It scares me that peoples' messages would be denied based on what degree of connection they choose to mail via. I sincerely hope that the DUL lists only list netblocks that are actively being used for spam. This would be sort of like the Usenet Death Penalty, instating bans on providers who refuse to deal with spamming. I think that's a There's another list to do that: the original RBL. The DUL is only and explicitly for the purpose of denying access based on the degree of connection the users can afford. Olaf - 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: /proc/config idea
> a module for 2.4.3 will work for any 2.4.3 kernel that supports modules > at all (except for the SMP vs UP issue) so it's not the same thing as No, no, no. This is absolutely and dangerously wrong. A module depends on the kernel configuration, because it may access internal data structures of the kernel which change with configuration. It also depends on the compiler version and exact options used, because certain structures in the kernel are compiler dependent. Loading a module which doesn't fit the running kernel _exactly_ is the easiest way to get a hard kernel crash. SMP is only a special case of this general problem. CONFIG_MODVERSIONS is designed to take care of this dependency, and it really ought to be non-optional. Olaf - 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: /proc/config idea
a module for 2.4.3 will work for any 2.4.3 kernel that supports modules at all (except for the SMP vs UP issue) so it's not the same thing as No, no, no. This is absolutely and dangerously wrong. A module depends on the kernel configuration, because it may access internal data structures of the kernel which change with configuration. It also depends on the compiler version and exact options used, because certain structures in the kernel are compiler dependent. Loading a module which doesn't fit the running kernel _exactly_ is the easiest way to get a hard kernel crash. SMP is only a special case of this general problem. CONFIG_MODVERSIONS is designed to take care of this dependency, and it really ought to be non-optional. Olaf - 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: bug database braindump from the kernel summit
> 1) The idea of letting a bug "expire" is a good one. One way to do this > is to incorporate some form of user-base moderation into the bug > database. Unlike some of the forum systems, there's no reason why we can't > have tiers of moderators: "maintainers" are the clearinghouse people for > certain portions of the Linux kernel source tree and should have a larger > voice as to whether a bug is important, redundant, or completely off As everyone thinking about this perhaps should know, this moderation system is already used by Bugzilla: A bug report starts out as "unconfirmed", and people who volunteer to triage bugs and are given appropriate permission may elevate them to "new" status or resolve them as invalid. The actual maintainers query the database only for "new" bugs. Experience in the Mozilla development community has shown, however, that this is not as simple as it sounds. There are bug reports which remain unconfirmed for weeks. People submitting reports have that nasty feeling that they are being ignored. Really, I don't think it is a good idea to stamp any bug report as "not to be taken seriously" by default. It puts off people who know better. With automatic expiry of unconfirmed reports that would be absolutely devastating. Hopefully it is clear why. (Any pre-triaging process, even without expiry, must be done quickly and have enough people who do this unrewarding work, or it will introduce delays which make the submissions increasingly worthless.) I think that some sort of expiry is in order, but perhaps better the other way around: any report with no progress in a certain amount of time gets _higher_ priority, so that someone (perhaps a triager) is "forced" to do _something_ about it (and if it's only to close an issue which has long been fixed or is invalid from the start). Bugzilla also does address some of the other issues presented here. (No, I don't think it's perfect :-) Olaf - 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: bug database braindump from the kernel summit
1) The idea of letting a bug "expire" is a good one. One way to do this is to incorporate some form of user-base moderation into the bug database. Unlike some of the forum systems, there's no reason why we can't have tiers of moderators: "maintainers" are the clearinghouse people for certain portions of the Linux kernel source tree and should have a larger voice as to whether a bug is important, redundant, or completely off As everyone thinking about this perhaps should know, this moderation system is already used by Bugzilla: A bug report starts out as "unconfirmed", and people who volunteer to triage bugs and are given appropriate permission may elevate them to "new" status or resolve them as invalid. The actual maintainers query the database only for "new" bugs. Experience in the Mozilla development community has shown, however, that this is not as simple as it sounds. There are bug reports which remain unconfirmed for weeks. People submitting reports have that nasty feeling that they are being ignored. Really, I don't think it is a good idea to stamp any bug report as "not to be taken seriously" by default. It puts off people who know better. With automatic expiry of unconfirmed reports that would be absolutely devastating. Hopefully it is clear why. (Any pre-triaging process, even without expiry, must be done quickly and have enough people who do this unrewarding work, or it will introduce delays which make the submissions increasingly worthless.) I think that some sort of expiry is in order, but perhaps better the other way around: any report with no progress in a certain amount of time gets _higher_ priority, so that someone (perhaps a triager) is "forced" to do _something_ about it (and if it's only to close an issue which has long been fixed or is invalid from the start). Bugzilla also does address some of the other issues presented here. (No, I don't think it's perfect :-) Olaf - 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: query about sending udp packets in kernel mode
> sock_creat(PF_INET, SOCK_DGRAM, IPPROTO_UDP, );
> sin.sin_family = AF_INET;
> sin.sin_port = htons((unsigned short)serv_port);
> sin.sin_addr.s_addr = htonl(INADDR_ANY); /*i am not sure about this*/
Needs the target IP address here.
> msg.msg_name =
> msg.msglen = sizeof(struct sockaddr_in);
> msg.msg_iov = iovec_containg the message;
> msg.msg_iovlen = 1;
> msg.msg_control = NULL;
> msg.msg_controllen=0;
> msg.msg_flags =0;
{ mm_segment_t fs=get_fs();
set_fs(get_ds());
> sock->ops->sendmsg(sock,,count,0);
set_fs(fs); }
"count" needs to be the total length of the message. The 0 is
redundant, sendmsg() takes only three arguments since Linux 2.1 (five
under 2.0).
Olaf
-
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: query about sending udp packets in kernel mode
sock_creat(PF_INET, SOCK_DGRAM, IPPROTO_UDP, sock);
sin.sin_family = AF_INET;
sin.sin_port = htons((unsigned short)serv_port);
sin.sin_addr.s_addr = htonl(INADDR_ANY); /*i am not sure about this*/
Needs the target IP address here.
msg.msg_name = sin;
msg.msglen = sizeof(struct sockaddr_in);
msg.msg_iov = iovec_containg the message;
msg.msg_iovlen = 1;
msg.msg_control = NULL;
msg.msg_controllen=0;
msg.msg_flags =0;
{ mm_segment_t fs=get_fs();
set_fs(get_ds());
sock-ops-sendmsg(sock,msg,count,0);
set_fs(fs); }
"count" needs to be the total length of the message. The 0 is
redundant, sendmsg() takes only three arguments since Linux 2.1 (five
under 2.0).
Olaf
-
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: 2.4.x and SMP fails to compile (`current' undefined)
> Yes, but if SMP for Athlons is not supported, what is the point in > allowing CONFIG_SMP + CONFIG_MK7 (or CONFIG_SMP + CONFIG_MK6)? Such a > kernel will not run on *any* SMP system, since AMD kernels do not work > on Intel. If an AMD user really wants to carry around SMP baggage for > no reason, let him use CONFIG_M586TSC. Authors of drivers or other kernel add-on code often have to test their stuff on a variety of configurations. _Especially_ on an SMP kernel even if all they have is UP. Olaf - 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.x and SMP fails to compile (`current' undefined)
Yes, but if SMP for Athlons is not supported, what is the point in allowing CONFIG_SMP + CONFIG_MK7 (or CONFIG_SMP + CONFIG_MK6)? Such a kernel will not run on *any* SMP system, since AMD kernels do not work on Intel. If an AMD user really wants to carry around SMP baggage for no reason, let him use CONFIG_M586TSC. Authors of drivers or other kernel add-on code often have to test their stuff on a variety of configurations. _Especially_ on an SMP kernel even if all they have is UP. Olaf - 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: hotmail not dealing with ECN
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an > > RST packet as "go away and never ever send traffic to this host again" - > > i.e. trying another TCP connection, this time with ECN disabled, would be > > acceptable. > > Using a different source port number, even. But that has to be done on the application level, which means we need a socket option to not use ECN. It is not acceptable that the kernel changes the port number of a socket which already has one, or any application which uses getsockname() on the connecting socket will horribly break.[1] Olaf [1] and this means any application using libsocks5, so nobody tell me "no sane application does need this". - 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: hotmail not dealing with ECN
I was not suggesting ignoring these. OTOH, there is no reason to treat an RST packet as "go away and never ever send traffic to this host again" - i.e. trying another TCP connection, this time with ECN disabled, would be acceptable. Using a different source port number, even. But that has to be done on the application level, which means we need a socket option to not use ECN. It is not acceptable that the kernel changes the port number of a socket which already has one, or any application which uses getsockname() on the connecting socket will horribly break.[1] Olaf [1] and this means any application using libsocks5, so nobody tell me "no sane application does need this". - 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: The latest instance in the A20 farce
> I also really, really, *REALLY* hate them for killing serial ports. It's > a Bad Idea[TM]. Why, it opens up the market for serial-ports-on-USB devices. HW manufactures can make significantly more money on that than on $7.95 ISA multi I/O cards[1] ;-) Olaf [1] and I still dislike those, because they are only useful with lots and lots of jumpers for which you always can't find the description... but RS232 ports _are_ necessary in the real world, and more often than you like you need more than 2 of them. - 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: The latest instance in the A20 farce
I also really, really, *REALLY* hate them for killing serial ports. It's a Bad Idea[TM]. Why, it opens up the market for serial-ports-on-USB devices. HW manufactures can make significantly more money on that than on $7.95 ISA multi I/O cards[1] ;-) Olaf [1] and I still dislike those, because they are only useful with lots and lots of jumpers for which you always can't find the description... but RS232 ports _are_ necessary in the real world, and more often than you like you need more than 2 of them. - 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: TCP/IP kernel modification
> i.e after the kernel calls ip_route_output() and > ip_route_output_slow() and fails to find a match, i > need the kernel to somehow "hook-up" with a > process/daemon(routing protocol) and access a user > route cache there. You may try this: http://sites.inka.de/~bigred/sw/rrouted.txt> Olaf - 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: TCP/IP kernel modification
i.e after the kernel calls ip_route_output() and ip_route_output_slow() and fails to find a match, i need the kernel to somehow "hook-up" with a process/daemon(routing protocol) and access a user route cache there. You may try this: URL:http://sites.inka.de/~bigred/sw/rrouted.txt Olaf - 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: test13-pre3 woes
In article <[EMAIL PROTECTED]> you write: > [J Sloan] > > The module now compiles and gets installed - > > Unfortunately, attempting to load it does not go well: > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range >... > Those symbols are rather generic and rather important. Sounds like a > generic module problem. Do other modules load? Does your kernel use > MODVERSIONS? (This module apparently doesn't.) Are you using a recent > version of modutils? The most important question: Did you run "make dep" after doing the patch? Olaf - 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: test13-pre3 woes
In article [EMAIL PROTECTED] you write: [J Sloan] The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range ... Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? The most important question: Did you run "make dep" after doing the patch? Olaf - 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: NetWare Changing IP Port 524
> this problem is that it would give any internet hackers the ability to > discover the network topology (including which servers host NDS master > and replica databases). Not very secure. The concern for Petr is if in If knowing the server makes it vulnerable, the server has other problems still. Treating addresses and topology as secret is STO. Olaf - 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: More modutils: It's probably worse.
> The original exploit had nothing to do with filenames masquerading as > options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out Why is there any reason that a shell should be invoked anywhere in the request_module->modprobe->insmod chain? If implemented correctly, this attack should have the same result as insmod ';chmod o+w .' (and it should not matter if it gets renamed so that the actual command executed is insmod 'netdevice-;chmod o+w .') > The problem is the combination of kernel code passing user space > parameters through unchanged (promoting user input to root) Which means that all parts of the chain which deal with possible user input in elevated privilege mode must do input validation. This means the kernel _and_ modprobe in my book. > plus the > modprobe meta expansion algorithm. and I see no reason why modprobe should do any such thing, apart from configurations dealt with in modules.conf anyway. Olaf - 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: NetWare Changing IP Port 524
this problem is that it would give any internet hackers the ability to discover the network topology (including which servers host NDS master and replica databases). Not very secure. The concern for Petr is if in If knowing the server makes it vulnerable, the server has other problems still. Treating addresses and topology as secret is STO. Olaf - 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: More modutils: It's probably worse.
The original exploit had nothing to do with filenames masquerading as options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out Why is there any reason that a shell should be invoked anywhere in the request_module-modprobe-insmod chain? If implemented correctly, this attack should have the same result as insmod ';chmod o+w .' (and it should not matter if it gets renamed so that the actual command executed is insmod 'netdevice-;chmod o+w .') The problem is the combination of kernel code passing user space parameters through unchanged (promoting user input to root) Which means that all parts of the chain which deal with possible user input in elevated privilege mode must do input validation. This means the kernel _and_ modprobe in my book. plus the modprobe meta expansion algorithm. and I see no reason why modprobe should do any such thing, apart from configurations dealt with in modules.conf anyway. Olaf - 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/
for_each_task() in module?
The definition of for_each_task() in is based on init_task. This symbol is exported in Linux 2.2.15 and 2.4.0-test9, but with a comment which indicates only a special use; it is not exported in 2.2.9. Is there an official opinion about whether for_each_task() is intended to be usable from a module? (Which means the older kernel is simply buggy) or is the right way to build my own version based on "current"? Olaf - 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/
for_each_task() in module?
The definition of for_each_task() in linux/sched.h is based on init_task. This symbol is exported in Linux 2.2.15 and 2.4.0-test9, but with a comment which indicates only a special use; it is not exported in 2.2.9. Is there an official opinion about whether for_each_task() is intended to be usable from a module? (Which means the older kernel is simply buggy) or is the right way to build my own version based on "current"? Olaf - 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: Where is it written?
> Well it's safer if you are lazy about prototyping varargs functions. > But of course by doing that you're treading on thin ice anyway, in > terms of type promotion and portability. So I guess it's much better > to say "varargs functions MUST be prototyped" and use the registers. make -Wmissing-prototypes mandatory :-) Olaf - 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: Where is it written?
Well it's safer if you are lazy about prototyping varargs functions. But of course by doing that you're treading on thin ice anyway, in terms of type promotion and portability. So I guess it's much better to say "varargs functions MUST be prototyped" and use the registers. make -Wmissing-prototypes mandatory :-) Olaf - 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: catch 22 - porting net driver from 2.2 to 2.4
> We figured that since we are in user context (do_ioctl) and use > spin_lock_bh() to protect us from other concurrent threads, it might > interfere with rtnl_lock() so we remove our lock just before calling > register_netdev() and lock again upon return but then the whole process just > stopped and didn't return to the prompt. from within kdb, we could see that Can't you just do this: #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) /* not sure about the 0 */ #define rtnl_LOCK() rtnl_lock() #define rtnl_UNLOCK() rtnl_unlock() #else #define rtnl_LOCK() /* nop */ #define rtnl_UNLOCK() /* nop */ #endif rtnl_LOCK(); register_netdevice(...); rtnl_UNLOCK(); that works for me (yes, from do_ioctl, but without the bh lock - I don't know if that's absolutely needed in your case). Olaf - 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: Module open() problems, Linux 2.4.0
> > I suppose. Look at what you just stated! This means that a reported > > value is now worthless. > > Correct. And it was always worthless. Right. The module "use count" is not a use count, it's a lock count. E.g. a driver may well increase this counter on open and then again when in a particular ioctl routine, if this situation isn't already locked right by the kernel. This can happen when a driver has more than one access point from user space, look at slip_open() in slip.c from 2.2. > It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so, > but it was neither intended nor documented so. Remember the Landmark Test and those silly CPU-speed displays configured to show "Landmark MHz"? :-) Olaf - 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: Module open() problems, Linux 2.4.0
I suppose. Look at what you just stated! This means that a reported value is now worthless. Correct. And it was always worthless. Right. The module "use count" is not a use count, it's a lock count. E.g. a driver may well increase this counter on open and then again when in a particular ioctl routine, if this situation isn't already locked right by the kernel. This can happen when a driver has more than one access point from user space, look at slip_open() in slip.c from 2.2. It's the same de-facto standard as bogo-mips ~= CPU MHz. It was so, but it was neither intended nor documented so. Remember the Landmark Test and those silly CPU-speed displays configured to show "Landmark MHz"? :-) Olaf - 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: catch 22 - porting net driver from 2.2 to 2.4
We figured that since we are in user context (do_ioctl) and use spin_lock_bh() to protect us from other concurrent threads, it might interfere with rtnl_lock() so we remove our lock just before calling register_netdev() and lock again upon return but then the whole process just stopped and didn't return to the prompt. from within kdb, we could see that Can't you just do this: #if LINUX_VERSION_CODE = KERNEL_VERSION(2,3,0) /* not sure about the 0 */ #define rtnl_LOCK() rtnl_lock() #define rtnl_UNLOCK() rtnl_unlock() #else #define rtnl_LOCK() /* nop */ #define rtnl_UNLOCK() /* nop */ #endif rtnl_LOCK(); register_netdevice(...); rtnl_UNLOCK(); that works for me (yes, from do_ioctl, but without the bh lock - I don't know if that's absolutely needed in your case). Olaf - 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: /proc & xml data
> "MemTotal: %8lu kB\n" > to something like > "%8lu kB\n" The latter form offers no significant advantage over the former at all - there is nothing that can be expressed as value which can't also be expressed as name: value or name=value and the latter format is significantly easier to parse. The only situation where XML really would be useful would be some need of grouping, and this is done in /proc using directories. (Which are also much easier to parse using existing standard tools.) Olaf - 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: /proc xml data
"MemTotal: %8lu kB\n" to something like "memtotal%8lu kB/memtotal\n" The latter form offers no significant advantage over the former at all - there is nothing that can be expressed as namevalue/name which can't also be expressed as name: value or name=value and the latter format is significantly easier to parse. The only situation where XML really would be useful would be some need of grouping, and this is done in /proc using directories. (Which are also much easier to parse using existing standard tools.) Olaf - 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: Device Driver
> See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a Speaking of that file, < Portability:Pointers are not always 32bits, people do not all have < floating point and you shouldn't use inline x86 assembler in < your driver without careful thought. Pure x86 drivers is IMHO not exactly right. _Nobody_ has floating point in kernel space. Just because this is a FAQ it could be stressed more :-) Olaf - 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: Device Driver
See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a Speaking of that file, Portability:Pointers are not always 32bits, people do not all have floating point and you shouldn't use inline x86 assembler in your driver without careful thought. Pure x86 drivers is IMHO not exactly right. _Nobody_ has floating point in kernel space. Just because this is a FAQ it could be stressed more :-) Olaf - 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: [PATCH] VM fix for 2.4.0-test9 & OOM handler
> > Still, it would be nice to recover that 4 MB when the system > > doesn't have any memory left. > Yup. The X server could give back the memory for some cases like the > background without too much hackery. Then Linux only needs to implement SIGDANGER, which has been talked about for years... X would be a good candidate to implement a handler for it. Others are Emacs, Mozilla or JVMs - basically everything which has a GC of some sort. It could even be used to implement a configurable user mode OOM killer. Olaf - 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: Linux 2.4-test9 kernel header flaw
> We really need a collection of include files that only
> define the manifest constants and structures used for
> communication with user space. These can then be used both
> by glibc and by the kernel. This yields includes
> and and the former defines a constant API.
> It ideally never changes, only is added to.
Yes, please. And also include feature testing macros. That will make
the life of authors of kernel-dependent but portable software much
easier.
I.e. if you add something like
struct my_foo_ioctl { int stuff; };
also add
#define HAVE_MY_FOO_IOCTL 1
Olaf
(If absolutely necessary and indispensable, a definition may also be
deleted along with its feature macro, but this should not become the
norm.)
-
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: Linux 2.4-test9 kernel header flaw
We really need a collection of include files that only
define the manifest constants and structures used for
communication with user space. These can then be used both
by glibc and by the kernel. This yields includes linux/foo.h
and kernel/foo.h and the former defines a constant API.
It ideally never changes, only is added to.
Yes, please. And also include feature testing macros. That will make
the life of authors of kernel-dependent but portable software much
easier.
I.e. if you add something like
struct my_foo_ioctl { int stuff; };
also add
#define HAVE_MY_FOO_IOCTL 1
Olaf
(If absolutely necessary and indispensable, a definition may also be
deleted along with its feature macro, but this should not become the
norm.)
-
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/
