Re: reiserfs, xfs, ext2, ext3
On Fri, May 11, 2001 at 05:04:10PM +0100, Alan Cox wrote: > > I think with the growing acceptance of ReiserFS in the Linux > > community, it is tiresome to have to apply a patch again and again > > just to get working NFS. 2.2 NFS horrors all over again. > > The zero copy patches were basically self contained and tested for 6 months. > The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel. > There is a difference. Does NFS server support for one of the included FSes not belong in the kernel? or is it that a better way is possible and this ugly one should not be included? If the latter, has anyone told Hans how to do it 'right' so he can assign someone to the task? - 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: reiserfs, xfs, ext2, ext3
On Fri, May 11, 2001 at 05:04:10PM +0100, Alan Cox wrote: I think with the growing acceptance of ReiserFS in the Linux community, it is tiresome to have to apply a patch again and again just to get working NFS. 2.2 NFS horrors all over again. The zero copy patches were basically self contained and tested for 6 months. The reiserfs NFS hacks are ugly as hell and dont belong in the base kernel. There is a difference. Does NFS server support for one of the included FSes not belong in the kernel? or is it that a better way is possible and this ugly one should not be included? If the latter, has anyone told Hans how to do it 'right' so he can assign someone to the task? - 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: reiserfs, xfs, ext2, ext3
On Thu, May 10, 2001 at 01:44:53PM +0200, Matthias Andree wrote: [snip] > If you're deploying a cache partition such as /var/squid (possibly > having log files in another /var/log partition on another disk drive), > what's the point about not running (e. g.) mke2fs and squid -z on boot, > as well as mounting the system partitions (/usr) read-only (prevents > fsck on next reboot)? mke2fs is faster than reiserfs recovery probably > ;-) A while ago I configured a few squid boxes which ran off of a read-only system. Mke2fs is actually unacceptably slow on large file systems, faster then fsck, but still time consuming. I found that zeroing out the disk, then formating it and saving the non-zero blocks, replaying them on reboot to be an acceptable solution. - 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: reiserfs, xfs, ext2, ext3
On Thu, May 10, 2001 at 01:44:53PM +0200, Matthias Andree wrote: [snip] If you're deploying a cache partition such as /var/squid (possibly having log files in another /var/log partition on another disk drive), what's the point about not running (e. g.) mke2fs and squid -z on boot, as well as mounting the system partitions (/usr) read-only (prevents fsck on next reboot)? mke2fs is faster than reiserfs recovery probably ;-) A while ago I configured a few squid boxes which ran off of a read-only system. Mke2fs is actually unacceptably slow on large file systems, faster then fsck, but still time consuming. I found that zeroing out the disk, then formating it and saving the non-zero blocks, replaying them on reboot to be an acceptable solution. - 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: ECN: Volunteers needed
On Wed, May 09, 2001 at 01:08:31PM -0400, God wrote: > On Wed, 9 May 2001, Gregory Maxwell wrote: > > > 2) They certainly are. Every once in a while they go through a period of > >silently dropping all email coming from hosts that don't have PTRs. > >This would be no worse. > > ACK Which do you mean? : > > -Hosts that don't have valid PTRs (which would be no PTR at all -- Not > deliverable, but not because AOL said so) > > -Hosts that don't have valid PTRs, but DO have at least one valid MX > (Forward and reverse) > > -Same as above, but said hosts MX's forward and/or reverse don't match > > etc etc I ask this simply because I DO know of users who have > complained their E-Mail to/from an AOL customer, didn't get there. I've > always assumed .. well ... AOL user .. no comment :) AFIK, mail which contains Path with host names which don't pass a two-way check (forward, reverse the forward) AOL drops. Not always though, MX records are irrelevantly. - 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: ECN: Volunteers needed
On Wed, May 09, 2001 at 10:10:29AM -0400, Horst von Brand wrote: > Gregory Maxwell <[EMAIL PROTECTED]> said: > > [...] > > > Anyone have any friends at AOL? I wonder what the effect on these > > non-conformant sites would be if AOL's proxy's became ECN enabled? > > And AOL is sure crazy enough to "break compatibility with everybody" just > out of courtesy to someone's friend call. > > Get real, it _won't_ happen unless they are forced to do so. Standard or > not. 1) It's not everybody. 2) They certainly are. Every once in a while they go through a period of silently dropping all email coming from hosts that don't have PTRs. This would be no worse. - 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: ECN: Volunteers needed
On Tue, May 08, 2001 at 10:31:23PM -0400, jamal wrote: > Folks, > > ECN is about to become a Proposed Standard RFC. Thanks to > efforts from the Linux community, a few issues were discovered > in the course of deploying the code. Special kudos go to Alexey > Kuznetsov and David Miller. [snip] Anyone have any friends at AOL? I wonder what the effect on these non-conformant sites would be if AOL's proxy's became ECN enabled? - 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: ECN: Volunteers needed
On Tue, May 08, 2001 at 10:31:23PM -0400, jamal wrote: Folks, ECN is about to become a Proposed Standard RFC. Thanks to efforts from the Linux community, a few issues were discovered in the course of deploying the code. Special kudos go to Alexey Kuznetsov and David Miller. [snip] Anyone have any friends at AOL? I wonder what the effect on these non-conformant sites would be if AOL's proxy's became ECN enabled? - 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: ECN: Volunteers needed
On Wed, May 09, 2001 at 01:08:31PM -0400, God wrote: On Wed, 9 May 2001, Gregory Maxwell wrote: 2) They certainly are. Every once in a while they go through a period of silently dropping all email coming from hosts that don't have PTRs. This would be no worse. ACK Which do you mean? : -Hosts that don't have valid PTRs (which would be no PTR at all -- Not deliverable, but not because AOL said so) -Hosts that don't have valid PTRs, but DO have at least one valid MX (Forward and reverse) -Same as above, but said hosts MX's forward and/or reverse don't match etc etc I ask this simply because I DO know of users who have complained their E-Mail to/from an AOL customer, didn't get there. I've always assumed .. well ... AOL user .. no comment :) AFIK, mail which contains Path with host names which don't pass a two-way check (forward, reverse the forward) AOL drops. Not always though, MX records are irrelevantly. - 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: ECN: Volunteers needed
On Wed, May 09, 2001 at 10:10:29AM -0400, Horst von Brand wrote: Gregory Maxwell [EMAIL PROTECTED] said: [...] Anyone have any friends at AOL? I wonder what the effect on these non-conformant sites would be if AOL's proxy's became ECN enabled? And AOL is sure crazy enough to break compatibility with everybody just out of courtesy to someone's friend call. Get real, it _won't_ happen unless they are forced to do so. Standard or not. 1) It's not everybody. 2) They certainly are. Every once in a while they go through a period of silently dropping all email coming from hosts that don't have PTRs. This would be no worse. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote: > > That means that for fooling closed-source statically-linked binary, > > If they are using glibc then you have the right to the object to link > with the library and the library source under the LGPL. I dont know of any > app using its own C lib Some don't use any libc at all, some just don't use it for the time call that were talking about substituting. Lying about the time is a hack, pure and simple. It will still be possible with magic pages. The fact that it will require more kernel hacking to accomplish it is irrelevant. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote: > On 03 May 2001 09:13:00 +0200, > [EMAIL PROTECTED] (Kai Henningsen) wrote: > >[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in ><[EMAIL PROTECTED]>: > > > >> PS: Hmm, how do you do timewarp for just one userland appliation with > >> this installed? > > > >1. What on earth for? > > Y10K testing :) > > >2. How do you do it today, and why wouldn't that work? > > LD_PRELOAD on a library that overrides gettimeofday(). I can see no > reason why that would not continue to work. What would stop working > are timewarp modules that intercepted the syscall at the kernel level > instead of user space level. It would just have to be done a differnt way.. For those applications you make a differnt magic page and redirect them there. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote: On 03 May 2001 09:13:00 +0200, [EMAIL PROTECTED] (Kai Henningsen) wrote: [EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in [EMAIL PROTECTED]: PS: Hmm, how do you do timewarp for just one userland appliation with this installed? 1. What on earth for? Y10K testing :) 2. How do you do it today, and why wouldn't that work? LD_PRELOAD on a library that overrides gettimeofday(). I can see no reason why that would not continue to work. What would stop working are timewarp modules that intercepted the syscall at the kernel level instead of user space level. It would just have to be done a differnt way.. For those applications you make a differnt magic page and redirect them there. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote: That means that for fooling closed-source statically-linked binary, If they are using glibc then you have the right to the object to link with the library and the library source under the LGPL. I dont know of any app using its own C lib Some don't use any libc at all, some just don't use it for the time call that were talking about substituting. Lying about the time is a hack, pure and simple. It will still be possible with magic pages. The fact that it will require more kernel hacking to accomplish it is irrelevant. - 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: deregister?
On Sun, Apr 29, 2001 at 09:10:49PM -0400, Andres Salomon wrote: [snip] > Not to mention in various comments and documentation. Deregister, > according to www.m-w.com (and many other dictionaries), is not a word. > Is there some sort of historical significance to this being used, in > place of "unregister"? I purpose that we fix this horrible spelling error right away and get it into 2.4.5! :) (up yours binary-only module authors! :) ) - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote: [snip] > The point is: The code in that "magic page" that considers the > tradeoff is KERNEL code, which is designed to care about such > trade-offs for that machine. Glibc never knows this stuff and > shouldn't, because it is already bloated. > > We get the full win here, for our "compile the kernel for THIS > machine to get maximum performance"-strategy. > > People tend to compile the kernel, but not the glibc. > > Just let the benchmarks, Linus and Ulrich decide ;-) The kernel can even customize the page at runtime if it needs to, such as changing algorithims to deal with lock contention. Of course, this page will need to present a stable interface to glibc, and having both the code and a comprehensive jump-table might become tough in a single page... - 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: Sony Memory stick format funnies...
On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote: > Rogier Wolff wrote: > > > > H. Peter Anvin wrote: > > > Followup to: <[EMAIL PROTECTED]> > > > By author:[EMAIL PROTECTED] (Rogier Wolff) > > > In newsgroup: linux.dev.kernel > > > > > > > > # l /mnt/d1 > > > > total 16 > > > > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/ > > > > -r-xr-xr-x 1 root root0 May 23 2000 memstick.ind* > > > > # > > > > > > > > Where the
Re: question regarding cpu selection
On Sun, Apr 29, 2001 at 07:07:51PM -0400, Duncan Gauld wrote: > Hi, > This seems a silly question but - I have an intel celeron 800mhz CPU and thus > it is of the Coppermine breed. But under cpu selection when configuring the > kernel, should I select PIII or PII/Celeron? Just wondering, since Coppermine > is basically a newish PIII with 128K less cache... PIII, the differnce in the options is stuff like SSE that your PIII/Celeron has. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote: > Gregory Maxwell writes: > > On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: > > > Ingo Oeser writes: > > > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: > > > > > The idea is that the one thing one tends to optimize for new cpus > > > > > is the memcpy/memset implementation. What better way to shield > > > > > libc from having to be updated for new cpus but to put it into > > > > > the kernel in this magic page? > > > > > > > > Hehe, you have read this MXT patch on linux-mm, too? ;-) > > > > > > > > There we have 10x faster memmove/memcpy/bzero for 1K blocks > > > > granularity (== alignment is 1K and size is multiple of 1K), that > > > > is done by the memory controller. > > > > > > This sounds different to me. Using the memory controller is (should > > > be!) a privileged operation, thus it requires a system call. This is > > > quite different from code in a magic page, which is excuted entirely > > > in user-space. The point of the magic page is to avoid the syscall > > > overhead. > > > > Too bad this is a performance hack, otherwise we could place the > > privlaged code in the read-only page, allow it to get execute from > > user space, catch the exception, notice the EIP and let it continue > > on. > > No need for anything that complicated. We can merge David's user-space > memcpy code with the memory controller scheme. We need a new syscall > anyway to access the memory controller, so we may as well just make it > a simple interface. Then the user-space code may, on some machines, > contain a test (for alignment) and call to the new syscall. > > The two schemes are independent, and should be treated as such. Just > as the magic page code can call the new syscall, so could libc. Would it make sence to have libc use the magic page for all syscalls? Then on cpus with a fast syscall instruction, the magic page could contain the needed junk in userspace to use it. (i.e. that really should be in libc, but we don't want libc to contain all sorts of CPU specific cruft.. or is there a more general way to accomplish this?) - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: > Ingo Oeser writes: > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: > > > The idea is that the one thing one tends to optimize for new cpus > > > is the memcpy/memset implementation. What better way to shield > > > libc from having to be updated for new cpus but to put it into > > > the kernel in this magic page? > > > > Hehe, you have read this MXT patch on linux-mm, too? ;-) > > > > There we have 10x faster memmove/memcpy/bzero for 1K blocks > > granularity (== alignment is 1K and size is multiple of 1K), that > > is done by the memory controller. > > This sounds different to me. Using the memory controller is (should > be!) a privileged operation, thus it requires a system call. This is > quite different from code in a magic page, which is excuted entirely > in user-space. The point of the magic page is to avoid the syscall > overhead. Too bad this is a performance hack, otherwise we could place the privlaged code in the read-only page, allow it to get execute from user space, catch the exception, notice the EIP and let it continue on. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: Ingo Oeser writes: On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: The idea is that the one thing one tends to optimize for new cpus is the memcpy/memset implementation. What better way to shield libc from having to be updated for new cpus but to put it into the kernel in this magic page? Hehe, you have read this MXT patch on linux-mm, too? ;-) There we have 10x faster memmove/memcpy/bzero for 1K blocks granularity (== alignment is 1K and size is multiple of 1K), that is done by the memory controller. This sounds different to me. Using the memory controller is (should be!) a privileged operation, thus it requires a system call. This is quite different from code in a magic page, which is excuted entirely in user-space. The point of the magic page is to avoid the syscall overhead. Too bad this is a performance hack, otherwise we could place the privlaged code in the read-only page, allow it to get execute from user space, catch the exception, notice the EIP and let it continue on. - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote: Gregory Maxwell writes: On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: Ingo Oeser writes: On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: The idea is that the one thing one tends to optimize for new cpus is the memcpy/memset implementation. What better way to shield libc from having to be updated for new cpus but to put it into the kernel in this magic page? Hehe, you have read this MXT patch on linux-mm, too? ;-) There we have 10x faster memmove/memcpy/bzero for 1K blocks granularity (== alignment is 1K and size is multiple of 1K), that is done by the memory controller. This sounds different to me. Using the memory controller is (should be!) a privileged operation, thus it requires a system call. This is quite different from code in a magic page, which is excuted entirely in user-space. The point of the magic page is to avoid the syscall overhead. Too bad this is a performance hack, otherwise we could place the privlaged code in the read-only page, allow it to get execute from user space, catch the exception, notice the EIP and let it continue on. No need for anything that complicated. We can merge David's user-space memcpy code with the memory controller scheme. We need a new syscall anyway to access the memory controller, so we may as well just make it a simple interface. Then the user-space code may, on some machines, contain a test (for alignment) and call to the new syscall. The two schemes are independent, and should be treated as such. Just as the magic page code can call the new syscall, so could libc. Would it make sence to have libc use the magic page for all syscalls? Then on cpus with a fast syscall instruction, the magic page could contain the needed junk in userspace to use it. (i.e. that really should be in libc, but we don't want libc to contain all sorts of CPU specific cruft.. or is there a more general way to accomplish this?) - 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 regarding cpu selection
On Sun, Apr 29, 2001 at 07:07:51PM -0400, Duncan Gauld wrote: Hi, This seems a silly question but - I have an intel celeron 800mhz CPU and thus it is of the Coppermine breed. But under cpu selection when configuring the kernel, should I select PIII or PII/Celeron? Just wondering, since Coppermine is basically a newish PIII with 128K less cache... PIII, the differnce in the options is stuff like SSE that your PIII/Celeron has. - 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: Sony Memory stick format funnies...
On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote: Rogier Wolff wrote: H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:[EMAIL PROTECTED] (Rogier Wolff) In newsgroup: linux.dev.kernel # l /mnt/d1 total 16 drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root0 May 23 2000 memstick.ind* # Where the *(#$% does that dcim directory come from dcim probably stands for digital camera images. At least Canon digital cameras always put their data in a directory named dcim. Yes. I know. Seems to be standard. The stick is for my Sony camera. However, the question is: how in is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!) I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope? He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :) - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote: [snip] The point is: The code in that magic page that considers the tradeoff is KERNEL code, which is designed to care about such trade-offs for that machine. Glibc never knows this stuff and shouldn't, because it is already bloated. We get the full win here, for our compile the kernel for THIS machine to get maximum performance-strategy. People tend to compile the kernel, but not the glibc. Just let the benchmarks, Linus and Ulrich decide ;-) The kernel can even customize the page at runtime if it needs to, such as changing algorithims to deal with lock contention. Of course, this page will need to present a stable interface to glibc, and having both the code and a comprehensive jump-table might become tough in a single page... - 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: deregister?
On Sun, Apr 29, 2001 at 09:10:49PM -0400, Andres Salomon wrote: [snip] Not to mention in various comments and documentation. Deregister, according to www.m-w.com (and many other dictionaries), is not a word. Is there some sort of historical significance to this being used, in place of unregister? I purpose that we fix this horrible spelling error right away and get it into 2.4.5! :) (up yours binary-only module authors! :) ) - 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: IPv6 routing
On Fri, Apr 20, 2001 at 06:37:05PM +0100, Carlos Parada (EST) wrote: > Hi, > > I'm trying to set up an IPv6 network in Linux kernel 2.4.0-test10. In this > network I'm using just 3 boxs and I would use static routes. > __ _ > | A ||B | | C | > |_| |_||_| > > The problem is that I cannot access from A to C machines and vice-versa. But > the routing problem is a bit strange because, A can access to the two > interfaces of B, even to B interface in the same network as C. Also C can echo -n 1 > /proc/sys/net/ipv6/conf/all/forwarding - 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: bizarre TCP behavior
On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote: > I am having a very strange problem in linux 2.4 kernels. I have not set > any iptables rules at all, and there is no firewall blocking any of my > outgoing traffic. At what seems like random selection, I can not connect > to IP's yet I can get ping replies from them. Most IP's reply just fine, > but certain ones fail to send even an ACK. This problem disappears when I > boot into 2.2. Here is a brief example of what I am talking about: echo -n 0 > /proc/sys/net/ipv4/tcp_ecn Fix it? If so, please tell the sites your are trying to connect to to upgrade their $I#$@#%@(%)@%$ firewall and/or loadbalencer (usually Localdirector or PIX). - 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: bizarre TCP behavior
On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote: I am having a very strange problem in linux 2.4 kernels. I have not set any iptables rules at all, and there is no firewall blocking any of my outgoing traffic. At what seems like random selection, I can not connect to IP's yet I can get ping replies from them. Most IP's reply just fine, but certain ones fail to send even an ACK. This problem disappears when I boot into 2.2. Here is a brief example of what I am talking about: echo -n 0 /proc/sys/net/ipv4/tcp_ecn Fix it? If so, please tell the sites your are trying to connect to to upgrade their $I#$@#%@(%)@%$ firewall and/or loadbalencer (usually Localdirector or PIX). - 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: New directions for kernel development
On Sun, Apr 01, 2001 at 03:05:47PM -0500, Adam wrote: > BZZT, wrong. Headers were forged intentionally to show pine since it is > what Linus uses. > > I had a joke for this year as well, but I didn't hear back from Linus if > that's cool with him to send it to LKML (I suppose I should have asked him > earlier than 24hrs) so I did not send it. > > For those interested, a rought draft is at > > http://www.eax.com/linux2001/linux2001.txt You forgot the obligatory Linus Thorvalds reference. - 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
On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: > I'm really sick of being buried in useless information. The signal > gets lost in the noise. It is easy to discard automatically generated > bug reports, and way too annoying to wade through the crud. > > When network connections hang, the console-tools package version > isn't likely to be of any use. When ramfs leaks memory, nobody needs > the content of /proc/pci. > > Sometimes the bit of crud are HUGE. Imagine the hardware info > for a 64-way SGI or Sun box with plenty of devices attached. Disk space is 'free'. The information should be stored in a database where you can retrieve the information you need at will, while the back-end can statistically analyze the whole of the information looking for anomalies you would never have expected (like that network hang actually being caused by console-tools :) ). - 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
On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote: I'm really sick of being buried in useless information. The signal gets lost in the noise. It is easy to discard automatically generated bug reports, and way too annoying to wade through the crud. When network connections hang, the console-tools package version isn't likely to be of any use. When ramfs leaks memory, nobody needs the content of /proc/pci. Sometimes the bit of crud are HUGE. Imagine the hardware info for a 64-way SGI or Sun box with plenty of devices attached. Disk space is 'free'. The information should be stored in a database where you can retrieve the information you need at will, while the back-end can statistically analyze the whole of the information looking for anomalies you would never have expected (like that network hang actually being caused by console-tools :) ). - 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: New directions for kernel development
On Sun, Apr 01, 2001 at 03:05:47PM -0500, Adam wrote: BZZT, wrong. Headers were forged intentionally to show pine since it is what Linus uses. I had a joke for this year as well, but I didn't hear back from Linus if that's cool with him to send it to LKML (I suppose I should have asked him earlier than 24hrs) so I did not send it. For those interested, a rought draft is at http://www.eax.com/linux2001/linux2001.txt You forgot the obligatory Linus Thorvalds reference. - 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: Revised memory-management stuff (was: OOM killer)
On Sat, Mar 31, 2001 at 10:03:28PM -0800, Jonathan Morton wrote: [snip] > Issue 3: > The OOM killer was frequently killing the "wrong" process. I have > developed an improved badness selector, and devised a possible means of > specifying "don't touch" PIDs at runtime. PID 1 is never selected for > killing. I am debating whether to allow selection of *any* process > labelled "init" and running as root for the chop, since one of the "unusual > but frequently encountered" scenarios is for a second init to be running > during an install or recovery procedure. This might make it's way in as an > optional feature. IO/memory direct hardware access capability holding processes should be at the bottom of the list. - 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: Revised memory-management stuff (was: OOM killer)
On Sat, Mar 31, 2001 at 10:03:28PM -0800, Jonathan Morton wrote: [snip] Issue 3: The OOM killer was frequently killing the "wrong" process. I have developed an improved badness selector, and devised a possible means of specifying "don't touch" PIDs at runtime. PID 1 is never selected for killing. I am debating whether to allow selection of *any* process labelled "init" and running as root for the chop, since one of the "unusual but frequently encountered" scenarios is for a second init to be running during an install or recovery procedure. This might make it's way in as an optional feature. IO/memory direct hardware access capability holding processes should be at the bottom of the list. - 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: Promise RAID controller howto?
On Thu, Mar 29, 2001 at 12:41:11PM +0200, Erik van Asselt wrote: > Hm i have the Promise raid source for 2.2 kernel modules so what do you mean > by opensource signatures > > i have it working for 2.2 kernels but i can't get it to work properly in 2.4 > So if someone want to look at the source !!! > it can be found on www.promise.com The promise controller is not a hardware raid board, it is a regular IDE controller with a bios overlay. Their marketing is deceiving and fraudulent. Their software raid is less flexible then Linuxes, and it's performance is inferior. The only advantages of a promise 'raid' controller is cross-OS compatibility and a simplified booting process. Promises Linux 'drivers' are proprietary and a violation of the GPL. Because their drivers are closed source, you can not debug any kernel with it loaded and you will not be compatible with future upgrades to your kernel without promises good will. Because of these reasons, it would be advantageous for Linux to understand promises boot signature and allow Linuxes built in raid driver to be used on promises 'raid' disk. Allowing for the cross-os compatibility and easy booting but retaining the flexible, high performance and open source of the Linux code. Unfortunately, promise is more concerned with living their lie then providing a high quality product to their customers and refuses to provide the tiny bit of needed information. - 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: Promise RAID controller howto?
On Thu, Mar 29, 2001 at 12:41:11PM +0200, Erik van Asselt wrote: Hm i have the Promise raid source for 2.2 kernel modules so what do you mean by opensource signatures i have it working for 2.2 kernels but i can't get it to work properly in 2.4 So if someone want to look at the source !!! it can be found on www.promise.com The promise controller is not a hardware raid board, it is a regular IDE controller with a bios overlay. Their marketing is deceiving and fraudulent. Their software raid is less flexible then Linuxes, and it's performance is inferior. The only advantages of a promise 'raid' controller is cross-OS compatibility and a simplified booting process. Promises Linux 'drivers' are proprietary and a violation of the GPL. Because their drivers are closed source, you can not debug any kernel with it loaded and you will not be compatible with future upgrades to your kernel without promises good will. Because of these reasons, it would be advantageous for Linux to understand promises boot signature and allow Linuxes built in raid driver to be used on promises 'raid' disk. Allowing for the cross-os compatibility and easy booting but retaining the flexible, high performance and open source of the Linux code. Unfortunately, promise is more concerned with living their lie then providing a high quality product to their customers and refuses to provide the tiny bit of needed information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Mon, Mar 26, 2001 at 10:07:22AM -0500, Richard B. Johnson wrote: [snip] > I have just received notice that my machines will no longer be > provided access to "The Internet". > > "Effective on or before 16:00:00 local time, the only personal > computers that will be allowed Internet access are those administered > by a Microsoft Certified Network Administrator. This means that > no Unix or Linux machines will be provided access beyond the local > area network. If you require Internet access, the company will > provide a PC which runs a secure operating system such as Microsoft > Windows, or Windows/NT. Insecure operating systems like Linux must > be removed from company owned computers before the end of this week." You've demonstrated over and over again that you work for a constantly stupid company. Please find someplace else to work, your issues have become more depressing then amusing. :) It's sad that people like the one who sent out messages like that can stay employed. In the last year there have been several Windows love-bug type worms each causing damaged estimated in the billions. One or two Linux worms that go after a long fixed problem with no published accounts of significant damage and you get that sort of email.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Mon, Mar 26, 2001 at 10:07:22AM -0500, Richard B. Johnson wrote: [snip] I have just received notice that my machines will no longer be provided access to "The Internet". "Effective on or before 16:00:00 local time, the only personal computers that will be allowed Internet access are those administered by a Microsoft Certified Network Administrator. This means that no Unix or Linux machines will be provided access beyond the local area network. If you require Internet access, the company will provide a PC which runs a secure operating system such as Microsoft Windows, or Windows/NT. Insecure operating systems like Linux must be removed from company owned computers before the end of this week." You've demonstrated over and over again that you work for a constantly stupid company. Please find someplace else to work, your issues have become more depressing then amusing. :) It's sad that people like the one who sent out messages like that can stay employed. In the last year there have been several Windows love-bug type worms each causing damaged estimated in the billions. One or two Linux worms that go after a long fixed problem with no published accounts of significant damage and you get that sort of email.. - 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.2 and AMD-760MP I/O APIC
On Thu, Mar 15, 2001 at 05:34:18PM -0800, Johannes Erdfelt wrote: > The I/O APIC code for 2.2 contains a little trick which sets the destination > to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC > on AMD-760MP systems causing a lockup during boot. [snip] I'd love you test your patch! What does it take to become equipt with such a motherboard? - 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: How to optimize routing performance
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote: > Rik van Riel wrote: > > On Thu, 15 Mar 2001, J Sloan wrote: > > > > > There are some scheduler patches that are not part of the > > > main kernel tree at this point (mostly since they have yet to > > > be optimized for the common case) which make quite a big > > > difference under heavy load - you might want to check out: > > > > > > http://lse.sourceforge.net/scheduling/ > > > > Unrelated. Fun, but unrelated to networking... > > under high load, where the sheer numbet of interrupts > per second begins to overwhelm the kernel, might it [snip] > Or are you saying that the bottleneck is somewhere > else completely, or that there wouldn't be a bottleneck > in this case if certain kernel parameters were correctly > set? The scheduler schedules tasks not interrupts. Unless it manages to thrash the cache, the scheduler can not affect routing performance. - 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: How to optimize routing performance
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote: Rik van Riel wrote: On Thu, 15 Mar 2001, J Sloan wrote: There are some scheduler patches that are not part of the main kernel tree at this point (mostly since they have yet to be optimized for the common case) which make quite a big difference under heavy load - you might want to check out: http://lse.sourceforge.net/scheduling/ Unrelated. Fun, but unrelated to networking... under high load, where the sheer numbet of interrupts per second begins to overwhelm the kernel, might it [snip] Or are you saying that the bottleneck is somewhere else completely, or that there wouldn't be a bottleneck in this case if certain kernel parameters were correctly set? The scheduler schedules tasks not interrupts. Unless it manages to thrash the cache, the scheduler can not affect routing performance. - 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.2 and AMD-760MP I/O APIC
On Thu, Mar 15, 2001 at 05:34:18PM -0800, Johannes Erdfelt wrote: The I/O APIC code for 2.2 contains a little trick which sets the destination to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC on AMD-760MP systems causing a lockup during boot. [snip] I'd love you test your patch! What does it take to become equipt with such a motherboard? snicker - 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: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 05:46:39PM -0800, Mike Fedyk wrote: > Gregory Maxwell wrote: > > > > On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: > > > Hello linux-kernel, > > > > > > Is there any way to conduct TCP sessions (IE have a userland process > > > connect out, or accept connections) using non-local IPs? By "non-local" > > > I just mean IPs that aren't assigned to an interface, but do fall into > > > the network range of a running interface (so netmask, gateway, etc are > > > "known"). > > > > > > For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 > > > and assign it IP 10.0.0.1 Then, I want a process to accept TCP > > [snip] > > > > /sbin/ip addr add 10.2.0.0/24 dev eth0 > > > > Tada > How would you deal with the other computer responding to the host "port not > reachable"? I didn't pick-up on the fact that you planned on have other computers listening with those addresses. This won't work without support from your routing device if you actually have hosts on the addresses, just because of ARP. You can make this work, if, you can control and configure the router 1. You can configure your router to direct the needed ports to your Linux box and not the real hosts. (Linux can do this) If you can firewall on the victim boxes, you could block their 'not reachable' reply, but that doesn't solve ARP. You could probably make a trivial change to Linux and run it in promiscuous mode to achieve this. It's more likely the first will be a better option for you. What are you doing anyways? :) - 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: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: > Hello linux-kernel, > > Is there any way to conduct TCP sessions (IE have a userland process > connect out, or accept connections) using non-local IPs? By "non-local" > I just mean IPs that aren't assigned to an interface, but do fall into > the network range of a running interface (so netmask, gateway, etc are > "known"). > > For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 > and assign it IP 10.0.0.1 Then, I want a process to accept TCP [snip] /sbin/ip addr add 10.2.0.0/24 dev eth0 Tada - 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 vs ide performance on fsync's
On Tue, Mar 06, 2001 at 06:14:15PM +0100, David Balazic wrote: [snip] > Hardware Level caching is only good for OSes which have broken > drivers and broken caching (like plain old DOS). > > Linux does a good job in caching and cache control at software > level. Read caching, yes. But for writes, the drive can often do a lot more optimization because of it's synchronous operation with the platter and greater knowledge of internal disk geometry. What would be useful, as Alan said, is a barrier operation. - 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: Process vs. Threads
On Tue, Mar 06, 2001 at 05:28:43PM +0100, Jorge David Ortiz Fuentes wrote: [snip] > "task" that can be run. Using this structure makes easier to identify > which threads belong to the same process and tools such as ps or top > show the TID as a field. > > I understand that changing this in the Linux kernel would mean that: > * some tools will have to be modified. > * the proc filesystem should create a directory using the TID instead > of the PID. > * some features as VM handling, signaling or exec()ing from a thread > would be more difficult to implement. > * compatibility will be broken. > > However, I miss some way to indicate that two processes are, in > fact, threads of the same process. Maybe there is something I'm > missing. Let me elaborate this. [snip] > This information is missleading since there is no way to know that > these 9 threads are sharing memory. If you run 'ps axl' you can see > the hierarchy as if it was a multiprocess program, i.e. no difference > to show you that they are threads. Not even reading > /proc//status you get info about these being threads. [snip] There are no threads in Linux. All tasks are processes. Processes can share any or none of a vast set of resources. When processes share a certain set of resources, they have the same characteristics as threads under other OSes (except the huge performance improvements, Linux processes are already as fast as threads on other OSes). Execution contexts which share resources do not have to share memory. If we implemented top to aggregate such processes (as you suggest), the result would also be potentially misleading. If we were to break compatibility it should be actually fix the situation, not replace once misleading situation with another. Sometimes it is handy to view a collection of execution contexts as a singular object. However, such is also the case with a service implemented as a collection of share-none standard unix processes (like postfix). A better solution would be a more generalized system for service object management. Such a solution could likely be implemented without kernel intervention (though perhaps a general facility to determine what shares what with who might be needed). - 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: Process vs. Threads
On Tue, Mar 06, 2001 at 05:28:43PM +0100, Jorge David Ortiz Fuentes wrote: [snip] "task" that can be run. Using this structure makes easier to identify which threads belong to the same process and tools such as ps or top show the TID as a field. I understand that changing this in the Linux kernel would mean that: * some tools will have to be modified. * the proc filesystem should create a directory using the TID instead of the PID. * some features as VM handling, signaling or exec()ing from a thread would be more difficult to implement. * compatibility will be broken. However, I miss some way to indicate that two processes are, in fact, threads of the same process. Maybe there is something I'm missing. Let me elaborate this. [snip] This information is missleading since there is no way to know that these 9 threads are sharing memory. If you run 'ps axl' you can see the hierarchy as if it was a multiprocess program, i.e. no difference to show you that they are threads. Not even reading /proc/pid/status you get info about these being threads. [snip] There are no threads in Linux. All tasks are processes. Processes can share any or none of a vast set of resources. When processes share a certain set of resources, they have the same characteristics as threads under other OSes (except the huge performance improvements, Linux processes are already as fast as threads on other OSes). Execution contexts which share resources do not have to share memory. If we implemented top to aggregate such processes (as you suggest), the result would also be potentially misleading. If we were to break compatibility it should be actually fix the situation, not replace once misleading situation with another. Sometimes it is handy to view a collection of execution contexts as a singular object. However, such is also the case with a service implemented as a collection of share-none standard unix processes (like postfix). A better solution would be a more generalized system for service object management. Such a solution could likely be implemented without kernel intervention (though perhaps a general facility to determine what shares what with who might be needed). - 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 vs ide performance on fsync's
On Tue, Mar 06, 2001 at 06:14:15PM +0100, David Balazic wrote: [snip] Hardware Level caching is only good for OSes which have broken drivers and broken caching (like plain old DOS). Linux does a good job in caching and cache control at software level. Read caching, yes. But for writes, the drive can often do a lot more optimization because of it's synchronous operation with the platter and greater knowledge of internal disk geometry. What would be useful, as Alan said, is a barrier operation. - 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: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: Hello linux-kernel, Is there any way to conduct TCP sessions (IE have a userland process connect out, or accept connections) using non-local IPs? By "non-local" I just mean IPs that aren't assigned to an interface, but do fall into the network range of a running interface (so netmask, gateway, etc are "known"). For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 and assign it IP 10.0.0.1 Then, I want a process to accept TCP [snip] /sbin/ip addr add 10.2.0.0/24 dev eth0 Tada - 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: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 05:46:39PM -0800, Mike Fedyk wrote: Gregory Maxwell wrote: On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: Hello linux-kernel, Is there any way to conduct TCP sessions (IE have a userland process connect out, or accept connections) using non-local IPs? By "non-local" I just mean IPs that aren't assigned to an interface, but do fall into the network range of a running interface (so netmask, gateway, etc are "known"). For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 and assign it IP 10.0.0.1 Then, I want a process to accept TCP [snip] /sbin/ip addr add 10.2.0.0/24 dev eth0 Tada How would you deal with the other computer responding to the host "port not reachable"? I didn't pick-up on the fact that you planned on have other computers listening with those addresses. This won't work without support from your routing device if you actually have hosts on the addresses, just because of ARP. You can make this work, if, you can control and configure the router 1. You can configure your router to direct the needed ports to your Linux box and not the real hosts. (Linux can do this) If you can firewall on the victim boxes, you could block their 'not reachable' reply, but that doesn't solve ARP. You could probably make a trivial change to Linux and run it in promiscuous mode to achieve this. It's more likely the first will be a better option for you. What are you doing anyways? :) - 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: What is 2.4 Linux networking performance like compared to BSD?
On Fri, Mar 02, 2001 at 09:02:13AM +, Henning P. Schmiedehausen wrote: > [EMAIL PROTECTED] (Hans Reiser) writes: > > If I can't get information about BSD v. Linux 2.4 networking code, > > then reiserfs has to get ported to BSD which will be both nice and a > > pain to do. > > So we would get dual-licensed ReiserFS (BSD and GPL)? > > Are you aware of the legal implications, making your currently > GPL-only code BSD-licensed (status of third party patches for the GPL > code and so on)? There would be no reason to BSD licence ReiserFS.. The intent of the BSD licence is to let anyone who wants to lock it up with more restrictive licences do so, and if the result is more popular.. take over control of the software. So Hans could easily release a GPLed copy of FreeBSD with reiserfs. This type of activity is encouraged by the BSD people. - 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: What is 2.4 Linux networking performance like compared to BSD?
On Fri, Mar 02, 2001 at 09:02:13AM +, Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] (Hans Reiser) writes: If I can't get information about BSD v. Linux 2.4 networking code, then reiserfs has to get ported to BSD which will be both nice and a pain to do. So we would get dual-licensed ReiserFS (BSD and GPL)? Are you aware of the legal implications, making your currently GPL-only code BSD-licensed (status of third party patches for the GPL code and so on)? There would be no reason to BSD licence ReiserFS.. The intent of the BSD licence is to let anyone who wants to lock it up with more restrictive licences do so, and if the result is more popular.. take over control of the software. So Hans could easily release a GPLed copy of FreeBSD with reiserfs. This type of activity is encouraged by the BSD people. - 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: Via UDMA5 3/4/5 is not functional!
On Thu, Feb 22, 2001 at 04:38:48PM +0100, Ricardo Galli wrote: > > Then I tried kernel 2.4.1. I issued exactly the same hdparm command. > > i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not > > functional"! > I had the same problem. > Add > append="ide0=ata66 ide1=ata66 ide0=autotune ide1=autotune hda=autotune > hdb=autotune hdc=autotune" > to lilo.conf. > > BTW, I am having now CRC errors in IDE1 on the VIA, IDE0 it's ok at udma5 > and 30MB/sec. Are you not using a udma cable? :) - 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: Via UDMA5 3/4/5 is not functional!
On Thu, Feb 22, 2001 at 04:38:48PM +0100, Ricardo Galli wrote: Then I tried kernel 2.4.1. I issued exactly the same hdparm command. i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not functional"! I had the same problem. Add append="ide0=ata66 ide1=ata66 ide0=autotune ide1=autotune hda=autotune hdb=autotune hdc=autotune" to lilo.conf. BTW, I am having now CRC errors in IDE1 on the VIA, IDE0 it's ok at udma5 and 30MB/sec. Are you not using a udma cable? :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
On Wed, Feb 21, 2001 at 09:13:30PM -0600, Peter Samuelson wrote: [snip] > If you want stability, run the real Linus 2.4. If you want all the > really minor bug fixes and more of the experimental code, run -ac. If > you want production quality, run your kernel on a test server before > deploying. (As always!) ..and rely on a reputable distributor to help you choose what to run and provide you support to fix it when it breaks. - 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: Very high bandwith packet based interface and performance problems
On Wed, Feb 21, 2001 at 02:00:55PM -0800, Nye Liu wrote: [snip] > This is NOT what I'm seeing at all.. the kernel load appears to be > pegged at 100% (or very close to it), the user space app is getting > enough cpu time to read out about 10-20Mbit, and FURTHERMORE the kernel > appears to be ACKING ALL the traffic, which I don't understand at all > (e.g. the transmitter is simply blasting 300MBit of tcp unrestricted) > > With udp, we can get the full 300MBit throughput, but only if we shape > the load to 300Mbit. If we increase the load past 300 MBit, the received > frames (at the user space udp app) drops to 10-20MBit, again due to > user-space application scheduling problems. Perhaps excess context switches are thrashing the system? - 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 tcp very slow under certain circumstances (Re: netdev issues (3c905B))
On Wed, Feb 21, 2001 at 10:47:24AM +0100, Ookhoi wrote: [snip] > We have exactly the same problem but in our case it depends on the > following three conditions: 1, kernel 2.4 (2.2 is fine), 2, windows ip > header compression turned on, 3, a free internet access provider in > Holland called 'Wish' (which seemes to stand for 'I Wish I had a faster > connection'). > If we remove one of the three conditions, the connection is oke. It is > only tcp which is affected. > A packet on its way from linux server to windows client seems to get > dropped once and retransmitted. This makes the connection _very_ slow. [snip] It's been true for some time now that there are several firewalls, RAS, and NAT devices that break TCP connections in subtile but horrible ways when they encounter SACK, timestamps, have header compression enabled, or other 'exotic' features. Has anyone compiled a list of such bugs so that a test application could be created? - 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 tcp very slow under certain circumstances (Re: netdev issues (3c905B))
On Wed, Feb 21, 2001 at 10:47:24AM +0100, Ookhoi wrote: [snip] We have exactly the same problem but in our case it depends on the following three conditions: 1, kernel 2.4 (2.2 is fine), 2, windows ip header compression turned on, 3, a free internet access provider in Holland called 'Wish' (which seemes to stand for 'I Wish I had a faster connection'). If we remove one of the three conditions, the connection is oke. It is only tcp which is affected. A packet on its way from linux server to windows client seems to get dropped once and retransmitted. This makes the connection _very_ slow. [snip] It's been true for some time now that there are several firewalls, RAS, and NAT devices that break TCP connections in subtile but horrible ways when they encounter SACK, timestamps, have header compression enabled, or other 'exotic' features. Has anyone compiled a list of such bugs so that a test application could be created? - 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: Very high bandwith packet based interface and performance problems
On Wed, Feb 21, 2001 at 02:00:55PM -0800, Nye Liu wrote: [snip] This is NOT what I'm seeing at all.. the kernel load appears to be pegged at 100% (or very close to it), the user space app is getting enough cpu time to read out about 10-20Mbit, and FURTHERMORE the kernel appears to be ACKING ALL the traffic, which I don't understand at all (e.g. the transmitter is simply blasting 300MBit of tcp unrestricted) With udp, we can get the full 300MBit throughput, but only if we shape the load to 300Mbit. If we increase the load past 300 MBit, the received frames (at the user space udp app) drops to 10-20MBit, again due to user-space application scheduling problems. Perhaps excess context switches are thrashing the system? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
On Wed, Feb 21, 2001 at 09:13:30PM -0600, Peter Samuelson wrote: [snip] If you want stability, run the real Linus 2.4. If you want all the really minor bug fixes and more of the experimental code, run -ac. If you want production quality, run your kernel on a test server before deploying. (As always!) ..and rely on a reputable distributor to help you choose what to run and provide you support to fix it when it breaks. - 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/
[OT] Re: Money stifles innovation
On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: > On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: > > On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: > > > The XOR patent and the fraudulent enforcement of it is the purest > > > embodiment of everything that is wrong with the patent system and IP law. > > As a person with a some decades of experience with patents and > > trademarks, and playing among the various sides, I can state > > quite unequivocally that the problem is money. > > Actually the problem is lack of morals and bad people who are really evil > at the core (you wouldnt want them for your neighbor). Actually, it's because we've made it illegal to corporations to behave ethically when it conflicts with short-term shareholder profits. http://www.ratical.com/corporations/ It would be nice if it were so simple as to declare the involved parties as evil. - 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/
[OT] Re: Money stifles innovation
On Sun, Feb 18, 2001 at 05:47:10PM -0800, Dan Hollis wrote: On Sun, 18 Feb 2001 [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2001 at 12:57:14AM -0800, Dan Hollis wrote: The XOR patent and the fraudulent enforcement of it is the purest embodiment of everything that is wrong with the patent system and IP law. As a person with a some decades of experience with patents and trademarks, and playing among the various sides, I can state quite unequivocally that the problem is money. Actually the problem is lack of morals and bad people who are really evil at the core (you wouldnt want them for your neighbor). Actually, it's because we've made it illegal to corporations to behave ethically when it conflicts with short-term shareholder profits. http://www.ratical.com/corporations/ It would be nice if it were so simple as to declare the involved parties as evil. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote: > good commercial drivers dont need fixing. another point. You are arguing > that having source is required to fix crappy code, which i agree with. Too bad we havn't seen much (any?) good closed-source (what you ment to say when you said commercial above) drivers for Linux, including the steaming pile of garbage your company ships. > You "guys" like to have source, and there is nothing wrong with that. But > requiring that all code be distributed as source DOES stifle innovation. > Its as simple as that. Like Microsoft you seem to confuse 'innovation' with 'being able to dictate the terms of how I will extort money from others'. - 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/
[OT]Re: Linux stifles innovation...
On Fri, Feb 16, 2001 at 11:20:54PM -0800, Mike Pontillo wrote: [snip] > Assuming I am a corporate entity and I need to spend a few bucks to fix > a GPL driver, just because I fix it and deploy my fix on my corporation's > internal network machines -- and quite possibly benefit the hell out of > myself and my company -- that does not mean that I have to release my work > for free under the GPL. Of course, the *nice* thing to do would be to > release it under the GPL even if I was only using the fix internally -- but > I am under no obligation to do that, if, say, I just wanted to keep ahead of > my competitors. Maybe I was planning to wait awhile so I could get ahead in > my market. Maybe I'm just an IP freak and I want to keep my code to myself. > Whatever. My understanding is that the only restrictions I have is that I > can't sell or distribute the darned thing. If, say for example I needed to > fix that driver so that it would work on my new WhizBang 2001 Corporate > Server that is about to hit the market, then I would be making money on the > hardware, and as an added bonus my company looks good because it has an > "open" driver for its server. (no matter that it "had" to under the GPL) No, you can sell it as well, but you have to give the buyer the same rights you got (under the GPL), this still has value as you can sell it for any price you want and you can add other value to yours sales (sure, after the first couple sales people will be able to find it for free on the net or included in the kernel, but if they want your support for it, they need pay you). - 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/
[OT]Re: Linux stifles innovation...
On Fri, Feb 16, 2001 at 11:20:54PM -0800, Mike Pontillo wrote: [snip] Assuming I am a corporate entity and I need to spend a few bucks to fix a GPL driver, just because I fix it and deploy my fix on my corporation's internal network machines -- and quite possibly benefit the hell out of myself and my company -- that does not mean that I have to release my work for free under the GPL. Of course, the *nice* thing to do would be to release it under the GPL even if I was only using the fix internally -- but I am under no obligation to do that, if, say, I just wanted to keep ahead of my competitors. Maybe I was planning to wait awhile so I could get ahead in my market. Maybe I'm just an IP freak and I want to keep my code to myself. Whatever. My understanding is that the only restrictions I have is that I can't sell or distribute the darned thing. If, say for example I needed to fix that driver so that it would work on my new WhizBang 2001 Corporate Server that is about to hit the market, then I would be making money on the hardware, and as an added bonus my company looks good because it has an "open" driver for its server. (no matter that it "had" to under the GPL) No, you can sell it as well, but you have to give the buyer the same rights you got (under the GPL), this still has value as you can sell it for any price you want and you can add other value to yours sales (sure, after the first couple sales people will be able to find it for free on the net or included in the kernel, but if they want your support for it, they need pay you). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote: good commercial drivers dont need fixing. another point. You are arguing that having source is required to fix crappy code, which i agree with. Too bad we havn't seen much (any?) good closed-source (what you ment to say when you said commercial above) drivers for Linux, including the steaming pile of garbage your company ships. You "guys" like to have source, and there is nothing wrong with that. But requiring that all code be distributed as source DOES stifle innovation. Its as simple as that. Like Microsoft you seem to confuse 'innovation' with 'being able to dictate the terms of how I will extort money from others'. - 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: How to determine Network Utilization
On Fri, Feb 16, 2001 at 07:24:21PM +0530, Vineet Mehta wrote: > I m a beginner so please dont mind.. > How do we calculate the network utilization of a particular ethernet LAN > segment? > Whata are the issues involved? You start by asking in the right place. Then, considering your mail user agent, you pay lots of money to a vendor who will sell you some flakey app that will tell you what you think you want to know, but insted will have internal problems and really be reporting false information. However, your boss with be satisfied with the false information. :) - 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: How to determine Network Utilization
On Fri, Feb 16, 2001 at 07:24:21PM +0530, Vineet Mehta wrote: I m a beginner so please dont mind.. How do we calculate the network utilization of a particular ethernet LAN segment? Whata are the issues involved? You start by asking in the right place. Then, considering your mail user agent, you pay lots of money to a vendor who will sell you some flakey app that will tell you what you think you want to know, but insted will have internal problems and really be reporting false information. However, your boss with be satisfied with the false information. :) - 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: Reason (was: Re: dropcopyright script)
On Wed, Feb 14, 2001 at 10:00:25AM -0500, Mohammad A. Haque wrote: > How big do you have your icons set that you can actually read stuff in > it? > On Wed, 14 Feb 2001, Mordechai Ovits wrote: > > > In newer file managers, the icon of a C file is a tiny image of the first > > few lines of text. If all files startt with a copyright, it's not much > > good. So running this on a local, personal, tree can be a good thing. It would probably be more useful to make a little picture of a tree of the - 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: Reason (was: Re: dropcopyright script)
On Wed, Feb 14, 2001 at 10:00:25AM -0500, Mohammad A. Haque wrote: How big do you have your icons set that you can actually read stuff in it? On Wed, 14 Feb 2001, Mordechai Ovits wrote: In newer file managers, the icon of a C file is a tiny image of the first few lines of text. If all files startt with a copyright, it's not much good. So running this on a local, personal, tree can be a good thing. It would probably be more useful to make a little picture of a tree of the - 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/
[OT] Re: PCI-SCI Drivers v1.1-7 released
On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote: > More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1 > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput > from the gcc 2.91 compiled version on the identical SAME 2.4.1 > source tree. [snip] Come on Jeff, don't let your annoyance make you a fudder.. The Linux kernel relies on certain undefined behaviors of the compiler to achieve locality of various types. The optimizer in the GCC 3.0 code tree is much smarter and is not laying out code the way GCC 2.x did. So it's very likely that this lossage is caused by poorer cache locality. After GCC 3 is finalized, it's likely that kernel developers will begin moving to it, and rethinking how they express such things as branch probability and code alignment to the compiler. Until then, GCC 3.0 snapshots are NOT the recommended compiler for the linux-kernel and not even RedHat compilers their kernel's with it. User beware. It should also be noted that this compiler almost always produces faster user space code then the older compilers, because almost nothing includes the type of hand-tweaked C that the kernel uses so often on critical paths, most of that software uses assembly in such situations. So.. It's likely that calling your performance issues 'gcc bugs' is about the same as saying that SGI cc is buggy because it can't compile the kernel. At least you managed to avoid calling RedHat names. :) - 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/
[OT] Re: PCI-SCI Drivers v1.1-7 released
On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote: More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1 kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput from the gcc 2.91 compiled version on the identical SAME 2.4.1 source tree. [snip] Come on Jeff, don't let your annoyance make you a fudder.. The Linux kernel relies on certain undefined behaviors of the compiler to achieve locality of various types. The optimizer in the GCC 3.0 code tree is much smarter and is not laying out code the way GCC 2.x did. So it's very likely that this lossage is caused by poorer cache locality. After GCC 3 is finalized, it's likely that kernel developers will begin moving to it, and rethinking how they express such things as branch probability and code alignment to the compiler. Until then, GCC 3.0 snapshots are NOT the recommended compiler for the linux-kernel and not even RedHat compilers their kernel's with it. User beware. It should also be noted that this compiler almost always produces faster user space code then the older compilers, because almost nothing includes the type of hand-tweaked C that the kernel uses so often on critical paths, most of that software uses assembly in such situations. So.. It's likely that calling your performance issues 'gcc bugs' is about the same as saying that SGI cc is buggy because it can't compile the kernel. At least you managed to avoid calling RedHat names. :) - 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: Matrox Marvell G400
On Mon, Feb 05, 2001 at 11:31:57AM -0500, Wakko Warner wrote: > How well is this card supported for it's capture capabilities and dual head? Capture and dual head are almost totally unsupported without using a proprietary, binary only driver chunk which will soundly place your system as 'unsupported' as far as this list is concerned due to the difficulty of debugging a system when sourceless software bangs the hardware. If this situation is not ideals for you, I suggest you address the issue with Matrox. That said, it is a dandy general 2d/3d card. - 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: Matrox Marvell G400
On Mon, Feb 05, 2001 at 11:31:57AM -0500, Wakko Warner wrote: How well is this card supported for it's capture capabilities and dual head? Capture and dual head are almost totally unsupported without using a proprietary, binary only driver chunk which will soundly place your system as 'unsupported' as far as this list is concerned due to the difficulty of debugging a system when sourceless software bangs the hardware. If this situation is not ideals for you, I suggest you address the issue with Matrox. That said, it is a dandy general 2d/3d card. - 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote: [snip] > From the debate raging here is what I gathered is acceptable > > make it blow up fataly and immediatly if it detects Red Hat + gcc >2.96-red_hat_broken(forgot version num) > make it provide a URL to get the patch to remove this safeguard if you really want >this. > > The fatal crash should be VERY carefull to only trigger on a redhat system >with the broken compiler. And to satisfy your agument that people may need to be able >to use it, provide a reverse patch to remove this safeguard in one easy cat file | >patch. No. There are *many* other compilers out there which are much *more* broken then anything RedHat has recently shipped. Unfortunatly, there is no easy way to accuratly test for such bugs (because once they can be boiled down to a simple test they are very rapidly fixed, what's left is voodoo). - 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote: [snip] From the debate raging here is what I gathered is acceptable make it blow up fataly and immediatly if it detects Red Hat + gcc 2.96-red_hat_broken(forgot version num) make it provide a URL to get the patch to remove this safeguard if you really want this. The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch. No. There are *many* other compilers out there which are much *more* broken then anything RedHat has recently shipped. Unfortunatly, there is no easy way to accuratly test for such bugs (because once they can be boiled down to a simple test they are very rapidly fixed, what's left is voodoo). - 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/
NT soon to surpass Linux in specweb99 performance?
Looks like TUX caught MS's attention: http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html Anyone know if their method of achieveing this is as flexible as TUX, or is their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the specweb dyanmic stuff in x86 assembly in their microkernel? :) - 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/
NT soon to surpass Linux in specweb99 performance?
Looks like TUX caught MS's attention: http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html Anyone know if their method of achieveing this is as flexible as TUX, or is their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the specweb dyanmic stuff in x86 assembly in their microkernel? :) - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote: > On Sun, 28 Jan 2001, Rogier Wolff wrote: > > > A sufficiently paranoid firewall should block requests that he doesn't > > fully understand. ECN was in this category, so old firewalls are > > "right" to block these. (Sending an 'RST' is not elegant. So be it.) > > > > However, ECN is now "understood", and operators are now in a position > > to configure their firewall to "do the right thing". This is > > This would have been easier. The firewall operators were not provided with > this option. This is hard-coded. I agree with the rest of your message. They chose their vendor. In the case of Cisco, they aparently chose OK as cisco fixed their product right away. In the case of Raptor they made a bad decision as the vendor still has not fixed the problem... They could have chose Linux where if there had been an issue they could have gotten it fixed without respect to the vendors idea of how important the problem is... - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote: [snip] > > The simplest thing in this chaos is to fix the firewall because it is in > > violation to begin with. > > It is not in violation, and you can't fix it: it's not yours. [snip] > > It's too bad we end up defining protocols using English. We should use > > mathematical equations to remove any ambiguity ;-> > > No, just use English properly. "Must be zero" doesn't actually mean "must > be set to zero when sending, and ignored when receiving/processing", which > is probably what the standard SHOULD have said. I see your problem now... You can't read! The standard don't just say "Must be zero" it also says that it is reserved. Reserved is very explicitly defined elseware... In the language of RFCs (and most of engineering) it means 'you must always set it as specified' when generating, and you must never behave differently because of it. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote: > On Sun, 28 Jan 2001, Ben Ford wrote: > > Do keep in mind, we aren't breaking connectivity, they are. > > Let me guess: you're a lawyer? :-) > > This is a very strange definition: if someone makes a change such that > their machine can no longer communicate with existing systems, I would say > the person making the incompatible change is the one who broke it. No. If one day your city decides to make the rode into and out of your neighorbhood only 1 meter wide, sooner or later someone will expects to drive a car or truck into the area (rather then a motorcycle), the person city is at fault for building a non-standard road. The person who chose to operate a perfectly standard car/truck is not in the wrong. > Maybe my mains sockets should be waterproof: it's still my fault when > pouring water over them causes problems, even if the standards say the > socket should be waterproof! No it's not. If you had a waterproof socket, it would certantly be the makers fault if it wasn't actually waterproof. I suppose you think I should be tried for murder because my sneeze was an element that contributed to a weather pattern which caused a monsoon on the other side of the world and killed people? It's perfectly reasonable for Linux to impliment an IETF standard. It's not reasonable for networks to make expectations/decisions about reserved bits in headers. If you want to break your networks, great, do things like that. But it's your problem to fix it when it becomes an issue. They expended effort to willfully break their networks, they can now expend the effort to fix them. This type of thing is part of the total-cost-of-ownership of a firewall, it isn't Linux's fault if they were too foolish to understand they would have ongoing costs. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote: > James Sutherland wrote: [snip] > > those firewalls should be updated to allow ECN-enabled packets > > through. However, to break connectivity to such sites deliberately just > > because they are not supporting an *experimental* extension to the current > > protocols is rather silly. > > Do keep in mind, we aren't breaking connectivity, they are. Thats the crux of the argument. No one made them run a firewall, they chose one that blocks undefined behavior. The Internet is a dynamic system, they broke the end-to-end model with their firewall, the onus is on them to keep up. - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote: > Thus spake Andrew Morton ([EMAIL PROTECTED]): > > Conclusions: > > > For a NIC which cannot do scatter/gather/checksums, the zerocopy > > patch makes no change in throughput in all case. > > > For a NIC which can do scatter/gather/checksums, sendfile() > > efficiency is improved by 40% and send() efficiency is decreased by > > 10%. The increase and decrease caused by the zerocopy patch will in > > fact be significantly larger than these two figures, because the > > measurements here include a constant base load caused by the device > > driver. > > What is missing here is a good authoritative web ressource that tells > people which NIC to buy. > > I have a tulip NIC because a few years ago that apparently was the NIC > of choice. It has good multicast (which is important to me), but AFAIK > it has neither scatter-gather nor hardware checksumming. > > Is there such a web page already? > If not, I volunteer to create amd maintain one. Additionally, it would be useful to have some boot messages comment on the abilities of cards. I am sick and tired of dealing with people telling me that 'Linux performance sucks' when they keep putting Linux on systems with pci 8139 adaptors. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote: > > There is nothing silly with the decision, davem is simply a modern day > > internet hero. > > No. If it were something essential, perhaps, but it's just a minor > performance tweak to cut packet loss over congested links. It's not > IPv6. It's not PMTU. It's not even very useful right now! No. ECN is essential to the continued stability of the Internet. Without probabilistic queuing (i.e. RED) and ECN the Internet will continue to have retransmit synchronization and once congested stay congested until people get frustrated and give it up for a little bit. It's a real issue, and it's actually important to have it implemented. It's not just a performance hack. - 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: [OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: > ... > > An attack against an Xray system is much more likely to come from inside the > > companies network. > ... > > We are not talking about attacks here, we are talking about undefined > behaviour when (perhaps poorly designed) systems encounter network > packages that use new or experimental features: I have seen MRI scanners > panic when they received SNMP queries and SNMP has been around for ages! The discussion was over centralized firewalls. Putting a firewall right on top of a system is the same as putting it on the system. Putting a firewall on your Internet connection would be insufficient to protect such a system. It's not a question of how long something has been around. You should be able to send line noise into the Ethernet port of any IP host and not have it behave adversly. Anything less and you *WILL* have problems. I would hope that you have enough sense to NOT connect any such broken systems in any way to a public network. Yet, another point against firewalls: Apparently they encourage computer professionals to behave criminally negligent by making it acceptable to implement broken life critical services. Firewalling your hospital's Internet connection to prevent your tomographic equipment from producing bad results due to a port scan rather then correctly repairing the system is computer equivalent of placing the fuel tank on the outside of the frame on a car (Pinto): Since it's protected by it's own wall and the outer body, casual impacts won't make the defect noticeable. Less people would have died in the pinto if the fuel tank was made of sugar-glass and placed prominently on the hood. Not because it's safer that way, but because out of both of the defective configurations the tank-on-the-hood is obviously broken and would get fixed or not used. Firewalls only actually improve security when there is only a single domain of trust behind them. Often we have multiple domains of trust even within a single system. Internet filtering firewalls provide nothing more then a false sense of security, and some opportunistic script kiddie protection. The continued profiteering by security 'experts' and acceptance of magic-boxes by systems administrators ensures that better solutions are not implemented. - 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: [OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: ... An attack against an Xray system is much more likely to come from inside the companies network. ... We are not talking about attacks here, we are talking about undefined behaviour when (perhaps poorly designed) systems encounter network packages that use new or experimental features: I have seen MRI scanners panic when they received SNMP queries and SNMP has been around for ages! The discussion was over centralized firewalls. Putting a firewall right on top of a system is the same as putting it on the system. Putting a firewall on your Internet connection would be insufficient to protect such a system. It's not a question of how long something has been around. You should be able to send line noise into the Ethernet port of any IP host and not have it behave adversly. Anything less and you *WILL* have problems. I would hope that you have enough sense to NOT connect any such broken systems in any way to a public network. Yet, another point against firewalls: Apparently they encourage computer professionals to behave criminally negligent by making it acceptable to implement broken life critical services. Firewalling your hospital's Internet connection to prevent your tomographic equipment from producing bad results due to a port scan rather then correctly repairing the system is computer equivalent of placing the fuel tank on the outside of the frame on a car (Pinto): Since it's protected by it's own wall and the outer body, casual impacts won't make the defect noticeable. Less people would have died in the pinto if the fuel tank was made of sugar-glass and placed prominently on the hood. Not because it's safer that way, but because out of both of the defective configurations the tank-on-the-hood is obviously broken and would get fixed or not used. Firewalls only actually improve security when there is only a single domain of trust behind them. Often we have multiple domains of trust even within a single system. Internet filtering firewalls provide nothing more then a false sense of security, and some opportunistic script kiddie protection. The continued profiteering by security 'experts' and acceptance of magic-boxes by systems administrators ensures that better solutions are not implemented. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote: There is nothing silly with the decision, davem is simply a modern day internet hero. No. If it were something essential, perhaps, but it's just a minor performance tweak to cut packet loss over congested links. It's not IPv6. It's not PMTU. It's not even very useful right now! No. ECN is essential to the continued stability of the Internet. Without probabilistic queuing (i.e. RED) and ECN the Internet will continue to have retransmit synchronization and once congested stay congested until people get frustrated and give it up for a little bit. It's a real issue, and it's actually important to have it implemented. It's not just a performance hack. - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote: Thus spake Andrew Morton ([EMAIL PROTECTED]): Conclusions: For a NIC which cannot do scatter/gather/checksums, the zerocopy patch makes no change in throughput in all case. For a NIC which can do scatter/gather/checksums, sendfile() efficiency is improved by 40% and send() efficiency is decreased by 10%. The increase and decrease caused by the zerocopy patch will in fact be significantly larger than these two figures, because the measurements here include a constant base load caused by the device driver. What is missing here is a good authoritative web ressource that tells people which NIC to buy. I have a tulip NIC because a few years ago that apparently was the NIC of choice. It has good multicast (which is important to me), but AFAIK it has neither scatter-gather nor hardware checksumming. Is there such a web page already? If not, I volunteer to create amd maintain one. Additionally, it would be useful to have some boot messages comment on the abilities of cards. I am sick and tired of dealing with people telling me that 'Linux performance sucks' when they keep putting Linux on systems with pci 8139 adaptors. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote: James Sutherland wrote: [snip] those firewalls should be updated to allow ECN-enabled packets through. However, to break connectivity to such sites deliberately just because they are not supporting an *experimental* extension to the current protocols is rather silly. Do keep in mind, we aren't breaking connectivity, they are. Thats the crux of the argument. No one made them run a firewall, they chose one that blocks undefined behavior. The Internet is a dynamic system, they broke the end-to-end model with their firewall, the onus is on them to keep up. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote: On Sun, 28 Jan 2001, Ben Ford wrote: Do keep in mind, we aren't breaking connectivity, they are. Let me guess: you're a lawyer? :-) This is a very strange definition: if someone makes a change such that their machine can no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. No. If one day your city decides to make the rode into and out of your neighorbhood only 1 meter wide, sooner or later someone will expects to drive a car or truck into the area (rather then a motorcycle), the person city is at fault for building a non-standard road. The person who chose to operate a perfectly standard car/truck is not in the wrong. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! No it's not. If you had a waterproof socket, it would certantly be the makers fault if it wasn't actually waterproof. I suppose you think I should be tried for murder because my sneeze was an element that contributed to a weather pattern which caused a monsoon on the other side of the world and killed people? It's perfectly reasonable for Linux to impliment an IETF standard. It's not reasonable for networks to make expectations/decisions about reserved bits in headers. If you want to break your networks, great, do things like that. But it's your problem to fix it when it becomes an issue. They expended effort to willfully break their networks, they can now expend the effort to fix them. This type of thing is part of the total-cost-of-ownership of a firewall, it isn't Linux's fault if they were too foolish to understand they would have ongoing costs. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote: [snip] The simplest thing in this chaos is to fix the firewall because it is in violation to begin with. It is not in violation, and you can't fix it: it's not yours. [snip] It's too bad we end up defining protocols using English. We should use mathematical equations to remove any ambiguity ;- No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. I see your problem now... You can't read! The standard don't just say "Must be zero" it also says that it is reserved. Reserved is very explicitly defined elseware... In the language of RFCs (and most of engineering) it means 'you must always set it as specified' when generating, and you must never behave differently because of it. - 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: ECN: Clearing the air (fwd)
On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote: On Sun, 28 Jan 2001, Rogier Wolff wrote: A sufficiently paranoid firewall should block requests that he doesn't fully understand. ECN was in this category, so old firewalls are "right" to block these. (Sending an 'RST' is not elegant. So be it.) However, ECN is now "understood", and operators are now in a position to configure their firewall to "do the right thing". This is This would have been easier. The firewall operators were not provided with this option. This is hard-coded. I agree with the rest of your message. They chose their vendor. In the case of Cisco, they aparently chose OK as cisco fixed their product right away. In the case of Raptor they made a bad decision as the vendor still has not fixed the problem... They could have chose Linux where if there had been an issue they could have gotten it fixed without respect to the vendors idea of how important the problem is... - 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/
[OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 02:10:25AM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote: > > It's this kind of ignorance that makes the internet a less secure and stable > > place. > > You have obviously absolutely no idea what you are talking about. Period. Your following comments show exactly who is has no idea of what he is talking about. Period. > > The network should not be a stateful device. If you need stateful > > firewalling the only place it should be implimented is on the end node. If > > management of that is a problem, then make an interface solve that problem > > insted of breaking the damn network. > > So how do you propose to secure devices like MRT's or X-Ray scanners or > life-support in a hospital? Nowadays this equipment is hooked to the > internal network of the hospital and protected by really paranoid > firewalls. Do you really want unneeded software on those devices? Oh yes! This provides you with virtually zero extra security. Now someone in the next room, perhaps the lobby, is free to attack the system... Which probably has very little extra security and trusts the network (after all, it's firewall protected). An attack against an Xray system is much more likely to come from inside the companies network. The only way to have firewall protection against even a simple majority of attacks is to implement a firewall per system. That would be expensive, and wasteful, so it makes a lot more sense to implement a firewall IN every system. Such a thing can be done at zero expense with practically no performance loss and not break the end-to-end model of the Internet. But such a simple solution would totally invalidate the use for most security 'experts' and their products. Firewalling is commodity. Cope. It's much more useful to push it to the end-node where it belongs. But look where security companies make their money The most common business affecting security violations are internal. Yes, many security companies are making most of their money selling expensive and pointless network profalatics. Why? For firewalling to be affordable on every system, it has to be free. Thats not profitable for security companies which is why you never hear it suggested, even though it actually can defend against the most common threats. The very fact that you bring up medical systems and suggest that I purposed leaving them unsecured shows that your only avenue for discussion was hysteria. > Or what about the computer systems in nuclear powerplants? In air defense > systems? Power grids? Water supply? > Oh come on! Just reread some of the newspapers back from Dec 31 1999! Mythology and hysteria. The same things that promotes the propagation of network degrading central firewalls. - 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
On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote: > On Sat, 27 Jan 2001, David Schwartz wrote: > > > > > > Firewalling should be implemented on the hosts, perhaps with centralized > > > policy management. In such a situation, there would be no reason to filter > > > on funny IP options. > > > > That's madness. If you have to implement your firewalling on every host, > > what do you do when someone wants to run a new OS? Forbid it? > > Of course. Then you find out about some new problem you want to block, so > you spend the next week reconfiguring a dozen different OS firewalling > systems. Hrm... I'll stick with a proper firewall, TYVM! It's this kind of ignorance that makes the internet a less secure and stable place. The network should not be a stateful device. If you need stateful firewalling the only place it should be implimented is on the end node. If management of that is a problem, then make an interface solve that problem insted of breaking the damn network. - 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
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote: > > Firewalling should be implemented on the hosts, perhaps with centralized > > policy management. In such a situation, there would be no reason to filter > > on funny IP options. > > That's madness. If you have to implement your firewalling on every host, > what do you do when someone wants to run a new OS? Forbid it? No a standard management interface would be followed by every host. Not unlike configuring your ipaddress with DHCP. - 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
On Sat, Jan 27, 2001 at 08:58:51PM +0100, Jamie Lokier wrote: [snip] > > I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK > > on 'hide nat'ed connections. This causes unreasonable stalls for users on > > SACK enabled clients. Not cool. > > If both SACK and SACK_PERMITTED were zeroed out, the clients would > negotiate non-SACK connections and everythings ok. A performance > disadvantage relative to allowing SACK, but that's true of ECN as well. Some checkpoint firewalls have caused stalls on SACK enabled clients. I don't recall the exact configuration or method of action, but it does happen. I suspect that it didn't kill the SackOK but only the actual SACKs data. Breaking end-to-end is the path to maddness. Trusting practically any network that leaves a room is insane. Firewalling should be implemented on the hosts, perhaps with centralized policy management. In such a situation, there would be no reason to filter on funny IP options. - 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: SBF queueing?
On Sat, Jan 27, 2001 at 07:52:32PM +0100, [EMAIL PROTECTED] wrote: > Hi Gregory! > You might have a look on linux/Documentation/networking/policy-routing.txt > I think this was down by Alexey Kuznetov Thanks for the quick reply. But that's not exactly what I was looking for. I was trying to find out if anyone was working on a peticular queueing algorithim that Linux doesn't currently have. > You might have a look to iproute + tc and HOWTO on advanced networking You mean this "HOWTO on advanced networking"? http://www.ds9a.nl/2.4Routing/ Look at the second authors name on the page. :) > patrick mourlhon - 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
On Sat, Jan 27, 2001 at 07:18:09PM +0100, Frank v Waveren wrote: > On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote: > > Practice being really, really paranoid. Think: You're designing a > > firewall; you've got some reserved bits, currently unused; any future code > > that uses them could behave in completely arbitrary and insecure ways, > > for all you know. Now recall that anything not known to be safe should > > be denied (in a good firewall) -- see Cheswick and Bellovin for why. > > When you take this point of view, it is completely understandable why > > firewalls designed before ECN was introduced might block it. > > Why? Why not just zero them, and get both security and compatibility... Eeek! NO NO NO NO NO NO NO NO! For ECN that would have worked, but that doesn't mean that something couldn't have been implimented there that wouldn't have worked that way.. I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK on 'hide nat'ed connections. This causes unreasonable stalls for users on SACK enabled clients. Not cool. - 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/
SBF queueing?
Has anyone decided to code a SFB (Stochastic Fair Blue) queue implementation for Linux? It's been implemented for FreeBSD/ALTQ (http://www.eecs.umich.edu/~wuchang/blue/). The paper for it shows it performing very well in comparison to RED. It might be useful in a Linux implementation to be able to adjust what fields are hashed (I don't believe the initial implementation does this, though it has been a few months since I read the paper). For instance, on edge networks you hash src,dest,proto,sport,dport to allocate fairly by flow. On larger networks, hashing on each flow will require a fairly big filter to prevent collisions from punishing good flows because of a collision with an unresponsive flow. It might be useful to only hash on src on core networks, and potentially masked src on backbone transit networks (which would have nice social implications as well, produce an unresponsive flow and watch your entire subnet be slowed during networking congestion, thus edge networks would implement technology to detect and police unresponsive flows, something better done towards the edge). - 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/
