Re: Distro kernel patches (was Re: Linux 2.2.18pre4)
Hi, On Wed, Sep 13, David S. Miller wrote: > It's an especially amusing situation especially since no vendor has > shipped a distribution without the raid patches applied to their > kernel for almost 2 years now. You have a very interesting definition of "no vendor". > Later, > David S. Miller -o) Hubert Mantel Goodbye, dots... /\\ _\_v - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
Hi, On Wed, Sep 13, David S. Miller wrote: It's an especially amusing situation especially since no vendor has shipped a distribution without the raid patches applied to their kernel for almost 2 years now. You have a very interesting definition of "no vendor". Later, David S. Miller -o) Hubert Mantel Goodbye, dots... /\\ _\_v - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote: > On 13 Sep 2000, Ralf Gerbig wrote: > > > * Chip Salzenberg writes: > > > > Hi Chip, > > > > > According to Ralf Gerbig: > > >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. > > > > > You've just made L-K's understatement of the day. > > > > [...] > > > > so I rest my case vs shrink wrap. > > > > Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I > recompiled the kernel source that they supplied. First, I just did > `make oldconfig` so I could duplicate the existing kernel. Well. > No such luck. There was no way in hell I could duplicate the kernel > that they supplied, with the sources that they supplied. And there > was no secret 'patch' directory either... I'm not sure (don't have a SuSE box right here) but I think they have separate packages for patched and unpatched kernel sources. I also remember their kernel patches are even separately stored somewhere. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote: On 13 Sep 2000, Ralf Gerbig wrote: * Chip Salzenberg writes: Hi Chip, According to Ralf Gerbig: but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. [...] so I rest my case vs shrink wrap. Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I recompiled the kernel source that they supplied. First, I just did `make oldconfig` so I could duplicate the existing kernel. Well. No such luck. There was no way in hell I could duplicate the kernel that they supplied, with the sources that they supplied. And there was no secret 'patch' directory either... I'm not sure (don't have a SuSE box right here) but I think they have separate packages for patched and unpatched kernel sources. I also remember their kernel patches are even separately stored somewhere. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Chip Salzenberg wrote: > According to Andre Hedrick: > So I've noticed. Do you not believe in its technical future, or are > you just conserving what's left of your free time? I would be attending an ice skating party below before I would see this included, and I am short on time. With the addition of a PPC toy the debugging of a second arch is heavy. And if others arrive it will get worse. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On 13 Sep 2000, Ralf Gerbig wrote: > * Chip Salzenberg writes: > > Hi Chip, > > > According to Ralf Gerbig: > >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. > > > You've just made L-K's understatement of the day. > > [...] > > so I rest my case vs shrink wrap. > Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I recompiled the kernel source that they supplied. First, I just did `make oldconfig` so I could duplicate the existing kernel. Well. No such luck. There was no way in hell I could duplicate the kernel that they supplied, with the sources that they supplied. And there was no secret 'patch' directory either... And I thought this was the whole idea of (GPL) [Snipped...] : 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, But what do I know, I haven't bought any lawyers lately ;~) Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
* Chip Salzenberg writes: Hi Chip, > According to Ralf Gerbig: >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. > You've just made L-K's understatement of the day. [...] so I rest my case vs shrink wrap. OTOH one of the first things I do after trying a new distribution is to replace the kernel by the latest and greatest, at least for the box at home and mine at work. I think I know what I am doing, or suffer otherwise. Those who want to upgrade their kernels have a choice between vendor suplied rpms, debs, tar.gz´s or the one and only from [ftp|http]//ftp.**.kernel.org. If they choose the latter, I would presume they are able to patch that one to their liking. OK I confess I usually chicken out and wait for those who_really_ know what they are doing, to supply their patches to the mainstream kernel. What I am trying to say is that I am perfectly happy to wait until the maintainers integrate the code into the mainstream kernel. Ralf -- P: Linus Torvalds patch-2.2.4 -S: Buried alive in diapers +S: Buried alive in reporters - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
> > Solve that and the tool back compatibility problem for the cases in > > question in a way Ingo is happy with and Raid 0.90 can go in. Simple > > as that. > > Apply the RAID 0.90 patch and make Ingo (or someone else) > maintain a patch which backs it out. 2.2 out of the box has to stay back compatible. Period - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Alan Cox wrote: > > [1] I understand the RAID issue with disk format compatibility, which > > makes the current RAID patch unacceptable for official 2.2 usage. > > I just wish somebody would *solve* that issue.[2] > Solve that and the tool back compatibility problem for the cases in > question in a way Ingo is happy with and Raid 0.90 can go in. Simple > as that. Easy. Apply the RAID 0.90 patch and make Ingo (or someone else) maintain a patch which backs it out. That would, I think, keep a vast majority of RAID users happy, while offering compatibility for the few users of the legacy code. Matthew. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Chip Salzenberg wrote: > that reducing it isn't worthwhile. The more de facto standard patches > (*cough* NFS RAID[1] HedrickIDE *ahem*) can get into the 2.2 tree, the > easier it will be for everyone to stay up to date, and the less effort > will be wasted on basically clerical patch maintenance work. Thanks Chip but the backporting to 2.2 has been terminated. I stopped at 2.2.18-3 and would have stopped at 2.2.15-pre7 if someone had not taken the time to do it for me. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
> [1] I understand the RAID issue with disk format compatibility, which > makes the current RAID patch unacceptable for official 2.2 usage. > I just wish somebody would *solve* that issue.[2] > [2] Having complained about a problem, have I just volunteered myself > to solve it? (HHOS) Solve that and the tool back compatibility problem for the cases in question in a way Ingo is happy with and Raid 0.90 can go in. Simple as that. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
Date:Wed, 13 Sep 2000 06:08:04 -0700 From: Chip Salzenberg <[EMAIL PROTECTED]> [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] [2] Having complained about a problem, have I just volunteered myself to solve it? (HHOS) It's an especially amusing situation especially since no vendor has shipped a distribution without the raid patches applied to their kernel for almost 2 years now. I'd say at least 9 out of 10 people using raid, are using the raid patches. In fact you could almost consider it a bug that stock 2.2.x kernels are not on-disk compatible with 9 out of 10 raid installations out there :-) Later, David S. Miller [EMAIL PROTECTED] - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
According to Ralf Gerbig: > but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. VA has always shipped a patched kernel. As of a few weeks ago, I'm VA's new kernel coordinator. We're not quite done with the current internal development cycle for a new kernel; but already we've applied to our kernel tree about a dozen major patches and over fifty minor ones. And that's on top of 2.2.18pre, into which Alan had already merged USB, AGP, and DRM (Thanks, Alan!!!). People who run big systems and big applications need these patches: 2.4 isn't ready for production use, stock 2.2 can't make full use of modern hardware, and the world is moving at Internet time. And VA's patching habits are the rule, not the exception. Andrea makes SuSE's kernel, and anyone who's scanned people/andrea on kernel.org knows how many patches he uses. (I greatly appreciate Andrea's patch archive, BTW. It's a great place to get major patches reconciled with each other.) And Red Hat's kernel, last I looked, had over 150 patches on top of 2.2.14. On the other hand, just because patching is inevitable doesn't mean that reducing it isn't worthwhile. The more de facto standard patches (*cough* NFS RAID[1] HedrickIDE *ahem*) can get into the 2.2 tree, the easier it will be for everyone to stay up to date, and the less effort will be wasted on basically clerical patch maintenance work. [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] [2] Having complained about a problem, have I just volunteered myself to solve it? (HHOS) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Wed, 13 Sep 2000, Chip Salzenberg wrote: > According to Mike Castle: > > On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: > > > So basically the situation is that people prefer to switch the whole > > > OS as opposed to applying a kernel patch? > > > > Or multiple kernel patches. > > NFS. RAID. IDE. > > Bigmem. LVM. LFS. Rawio. Serial. Ext3. Multi-threaded fs, virtual consoles, paging VM, symlinks, SIGHUP... Yes, I would say that some people prefer to switch the whole OS as opposed to applying kernel patches ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
According to Mike Castle: > On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: > > So basically the situation is that people prefer to switch the whole > > OS as opposed to applying a kernel patch? > > Or multiple kernel patches. > NFS. RAID. IDE. Bigmem. LVM. LFS. Rawio. Serial. Ext3. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> > They exist in the same way. You update stuff in controlled careful steps > > and you change troublesome drivers very early in a patch release - eg > > never touching tulip except early on > > So it could be in 2.2.19? Anything interested parties could/should do to > help? Im still hoping to get it into 2.2.18 but I have to get things like the compile issues with AGP sorted first otherwise nobody will ever quite get around to 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: Linux 2.2.18pre4
> Think Alan has made that clear. The way I read things the nfsv2 stuff needs > to be split out, into sets of small independent patches. This lets Alan > audit and control any bad patches easily. The nfsv3 changes should not We've taken that as far as we can already - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Ed Tomlinson wrote: > Horst von Brand wrote: > > > OK, OK, OK. It is by now abundantly clear that NFSv3 is a high-priority > > item for lots of people out there. But just complaining about it not being > > in the kernel just generates ill will. > > Think Alan has made that clear. The way I read things the nfsv2 stuff needs > to be split out, into sets of small independent patches. This lets Alan > audit and control any bad patches easily. The nfsv3 changes should not > effect anything unless they are selected in the kernel build. Trond has made it equally clear that he has no interest in revisiting the entire tortuous process of stabilizing the client. I don't blame him. Those of us who actually rely upon fast, reliable NFS know that it works and works well. I'll wager to say that most (if not all) commercial distributions will include Trond and D. Higgen's patches in the next refresh. I won't try to second-guess Alan in his reticence, but do think it's a shame these won't get into the base kernel. Let me weigh in as being utterly opposed to any interim or piecemeal adoption of either client or server patches. This would be foolish and ten times more likely to break things. Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
They exist in the same way. You update stuff in controlled careful steps and you change troublesome drivers very early in a patch release - eg never touching tulip except early on So it could be in 2.2.19? Anything interested parties could/should do to help? Im still hoping to get it into 2.2.18 but I have to get things like the compile issues with AGP sorted first otherwise nobody will ever quite get around to 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: Linux 2.2.18pre4
Think Alan has made that clear. The way I read things the nfsv2 stuff needs to be split out, into sets of small independent patches. This lets Alan audit and control any bad patches easily. The nfsv3 changes should not We've taken that as far as we can already - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
According to Mike Castle: On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. Bigmem. LVM. LFS. Rawio. Serial. Ext3. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
[1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] [2] Having complained about a problem, have I just volunteered myself to solve it? (HHOS) Solve that and the tool back compatibility problem for the cases in question in a way Ingo is happy with and Raid 0.90 can go in. Simple as that. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Alan Cox wrote: [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] Solve that and the tool back compatibility problem for the cases in question in a way Ingo is happy with and Raid 0.90 can go in. Simple as that. Easy. Apply the RAID 0.90 patch and make Ingo (or someone else) maintain a patch which backs it out. That would, I think, keep a vast majority of RAID users happy, while offering compatibility for the few users of the legacy code. Matthew. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
* Chip Salzenberg writes: Hi Chip, According to Ralf Gerbig: but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. [...] so I rest my case vs shrink wrap. OTOH one of the first things I do after trying a new distribution is to replace the kernel by the latest and greatest, at least for the box at home and mine at work. I think I know what I am doing, or suffer otherwise. Those who want to upgrade their kernels have a choice between vendor suplied rpms, debs, tar.gz´s or the one and only from [ftp|http]//ftp.**.kernel.org. If they choose the latter, I would presume they are able to patch that one to their liking. OK I confess I usually chicken out and wait for those who_really_ know what they are doing, to supply their patches to the mainstream kernel. What I am trying to say is that I am perfectly happy to wait until the maintainers integrate the code into the mainstream kernel. Ralf -- P: Linus Torvalds patch-2.2.4 -S: Buried alive in diapers +S: Buried alive in reporters - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On 13 Sep 2000, Ralf Gerbig wrote: * Chip Salzenberg writes: Hi Chip, According to Ralf Gerbig: but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. [...] so I rest my case vs shrink wrap. Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I recompiled the kernel source that they supplied. First, I just did `make oldconfig` so I could duplicate the existing kernel. Well. No such luck. There was no way in hell I could duplicate the kernel that they supplied, with the sources that they supplied. And there was no secret 'patch' directory either... And I thought this was the whole idea of (GPL) [Snipped...] : 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, But what do I know, I haven't bought any lawyers lately ;~) Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, 13 Sep 2000, Chip Salzenberg wrote: According to Andre Hedrick: So I've noticed. Do you not believe in its technical future, or are you just conserving what's left of your free time? I would be attending an ice skating party below before I would see this included, and I am short on time. With the addition of a PPC toy the debugging of a second arch is heavy. And if others arrive it will get worse. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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: Distro kernel patches (was Re: Linux 2.2.18pre4)
Date:Wed, 13 Sep 2000 06:08:04 -0700 From: Chip Salzenberg [EMAIL PROTECTED] [1] I understand the RAID issue with disk format compatibility, which makes the current RAID patch unacceptable for official 2.2 usage. I just wish somebody would *solve* that issue.[2] [2] Having complained about a problem, have I just volunteered myself to solve it? (HHOS) It's an especially amusing situation especially since no vendor has shipped a distribution without the raid patches applied to their kernel for almost 2 years now. I'd say at least 9 out of 10 people using raid, are using the raid patches. In fact you could almost consider it a bug that stock 2.2.x kernels are not on-disk compatible with 9 out of 10 raid installations out there :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
In article 8pmnfc$6p1$[EMAIL PROTECTED]> you wrote: > Think Alan has made that clear. The way I read things the nfsv2 stuff needs > to be split out, into sets of small independent patches. This lets Alan > audit and control any bad patches easily. The nfsv3 changes should not > effect anything unless they are selected in the kernel build. > > Comments? Are you volunteering to do it? No? I thought so. Personally, I'd rather let Trond spend his precious little spare time on useful things like improving the code and fixing whatever problems are left, then have him waste it on such a useless thing. If this means we have to keep patching each 2.2 release in order to get usable NFS, so be it. And, just to make things clear: Alan has *never* said what you imply. It was Jeff Garzik's suggestion. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Horst von Brand wrote: > OK, OK, OK. It is by now abundantly clear that NFSv3 is a high-priority > item for lots of people out there. But just complaining about it not being > in the kernel just generates ill will. Think Alan has made that clear. The way I read things the nfsv2 stuff needs to be split out, into sets of small independent patches. This lets Alan audit and control any bad patches easily. The nfsv3 changes should not effect anything unless they are selected in the kernel build. Comments? Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan Cox <[EMAIL PROTECTED]> said: > Subject: Re: Linux 2.2.18pre4 > > Return-Path: [EMAIL PROTECTED] > Delivery-Date: Tue Sep 12 20:33:05 2000 > Return-Path: <[EMAIL PROTECTED]> > In-Reply-To: <[EMAIL PROTECTED]> from "Paul > ***Jakma" at Sep 12, 2000 05:12:33 PM > > What are the issues with updating NFS code that do not exist with > > other drivers, filesystems, etc... in 2.2 for which updates are > > accepted? > They exist in the same way. You update stuff in controlled careful steps > and you change troublesome drivers very early in a patch release - eg > never touching tulip except early on So it could be in 2.2.19? Anything interested parties could/should do to help? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Paul Jakma wrote:
> alan seems to {want,prefer} small incremental/'obvious fix' patches.
> but that isn't practically possible anymore. It would mean the NFS
> guys would effectively have to redo the entire development cycle of
> code they have written over the last year.
[...]
> So it is now at the stage where we either:
>
> 1. bite the bullet and sync stock nfs with nfs.sourceforge.net
>
> or
>
> 2. accept that stock 2.2 will never have decent NFS server
>functionality, and wait for 2.4 to get stable.
I don't think anybody has to redo a lot of development in order to
submit Alan small, focused patches. So option #3, break up the big NFS
patch into small ones, still seems like the best option.
All this requires is a hacker, or hackers, who are interested enough in
2.2.x NFS to do something besides complaining :)
Jeff
--
Jeff Garzik | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc. |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Horst von Brand wrote:
> Better asK: What can _we_ do to assure Alan that NFS is up to snuff?
even if it does suck - so what? it can't possibly suck as much as
current stock NFS. :) but the general view is that 2.2 with patches
is quite useable for NFS serving and as client.
> How can we help along?
the NFS patches (which are a backport of stock 2.4, which descended
from the original 2.2 NFS patches) are now too large and too
different from stock 2.2 to realistically be split up into small
little "this fixes this exact problem". The code is now so far ahead
of stock 2.2 that it is an effective rewrite (and with new, but
optional, NFSv3 client and server and NFS client over TCP code added
on).
alan seems to {want,prefer} small incremental/'obvious fix' patches.
but that isn't practically possible anymore. It would mean the NFS
guys would effectively have to redo the entire development cycle of
code they have written over the last year.
In lieu of a technical argument such as small patches, the only other
arguments are those based on the experiences of people who have tried
to get linux to work reliably as an NFS server and even client. I've
tried to cover those in a previous email, see:
Message-ID: <[EMAIL PROTECTED]>
So it is now at the stage where we either:
1. bite the bullet and sync stock nfs with nfs.sourceforge.net
or
2. accept that stock 2.2 will never have decent NFS server
functionality, and wait for 2.4 to get stable.
we await 2.219pre1 with much curiosity. :)
regards,
--
Paul Jakma [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Where you stand depends on where you sit.
-- Rufus Miles, HEW
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> What are the issues with updating NFS code that do not exist with > other drivers, filesystems, etc... in 2.2 for which updates are > accepted? They exist in the same way. You update stuff in controlled careful steps and you change troublesome drivers very early in a patch release - eg never touching tulip except early on - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote:
> > ..so it should be at least as well tested as the USB backport in 2.2.18preX,
> > if not more so? Or so is implied. :)
>
> This is the big clue most people are missing
>
> 2.2.17- USB devices do not work
> 2.2.18- USB=n no kernel change USB devices still do not work
> USB=m USB works for most people
>
> USB cant make things any worse than now because you can compile it out.
>
I see where you are coming from, but the {"stock 2.4","2.2 patch"} NFS
code is well tested, lots of bug fixes for NFSv2 and the 'new' code ->
NFSv3 client/server is a compile yes/no option, just like the USB
backport.
2.2 without patches - NFS has performance/reliability problems
2.2 with patches- NFSv2 provided with lots of bugfixes
NFSv3 is compile time optional
I have not heard of anyone that prefers stock 2.2 NFS over
patched/2.4. Anecdotal evidence[1] suggests:
- stock 2.2 has 'issues' with NFS, serving in particular. Bad enough
that linux users would consider switching to another *nix for NFS
serving.
- 2.2 + NFS patches does not have issues (or very few), and would even
appear to work quite well, definitely for NFSv2 and seemingly for
the optional v3[2]. Certainly you need the patches for
interoperability.
- all the NFS developers are working the 2.4 code and backporting to
2.2. So issues wrt to the current 2.2 NFS codebase will not get
fixed. Issues wrt to the 2.4 backport do get fixed.
So the anecdotal evidence suggests we don't have anything to lose but
a not very good NFS server, and everything to gain.
What are the issues with updating NFS code that do not exist with
other drivers, filesystems, etc... in 2.2 for which updates are
accepted?
what is there to lose?
--paulj
[1]. as gathered from posts to this thread, to the nfs sourceforge
lists and my experience of stock NFS as of over a year ago and the NFS
patches since then.
[2]. linux v3 works flawlessly against IRIX 6.2 + ONC3 updates, both
as client and server, for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote: > They exist in the same way. You update stuff in controlled careful > steps and you change troublesome drivers very early in a patch > release - eg never touching tulip except early on > true. as i said before i'm glad we have such a 'tight' stable kernel maintainer. :) the problem is, NFS updates /never/ make it in - well once, but even then not the complete NFSv2 update. as for tulip, i know what you mean. however, i think in this case you'd be very hard pressed to find anyone for whom the patches are anything but a vast improvement. anyway... i've gone hoarse now. better stop. :) regards, Paul Jakma - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> ..so it should be at least as well tested as the USB backport in 2.2.18preX, > if not more so? Or so is implied. :) This is the big clue most people are missing 2.2.17 - USB devices do not work 2.2.18 - USB=n no kernel change USB devices still do not work USB=m USB works for most people USB cant make things any worse than now because you can compile it out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, Sep 12, 2000 at 03:00:29PM +0100, Paul Jakma wrote: > On Mon, 11 Sep 2000, Alan Cox wrote: > > > Shrug. So you want me to make it worse by shipping unproven code in a way > > I can't test it ? > > > > the code is in 2.4 and has been tested there though. the patches are a > backport of the 2.4 code. ..so it should be at least as well tested as the USB backport in 2.2.18preX, if not more so? Or so is implied. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Alan Cox wrote: > Shrug. So you want me to make it worse by shipping unproven code in a way > I can't test it ? > the code is in 2.4 and has been tested there though. the patches are a backport of the 2.4 code. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Jeff Garzik wrote: > I hear that the new NFS patch is "better and more stable" etc. but no > details. hard to give details as i havn't used unpatched linux 2.2 nfs in a very long time. best evidence from me is anecdotal: linux 2.4 / 2.2 nfs patches works perfectly for me (linux server, linux/irix clients, V2 and V3), and Trond et al are very responsive if there's problem. (eg silly delete handling bit me a couple of weeks ago, and Trond redid it and had a patch for me within a week or so of diagnosing the problem.). What I remember from using unpatched linux nfs is that it was /awful/ compared to the other unixen i used, most notably in the stability dept. As i remember it a standard linux NFS server never had much of an uptime because of NFS. also dreadful performance to non-linux clients. > It seems to me that if you want an NFS problem fixed in 2.2.x, > address that a single problem with a reproducible test and a small, > focused kernel patch sent to Alan. > there is a patch (well a couple -> server side and client side). The problem is it is never integrated, so now after more than a year of development in NFS the difference between linux nfs and /current/ NFS is bound to be huge. > Whatever Alan's reasons for not including "the 2.2.x NFS patch", I > serious doubt among those reasons is "keep NFS dreadful and unstable." > ;-) unless alan is being paid off by the commercial *nix vendors looking to sell NFS server - no of course not. :) > Maybe it breaks backwards compatibility... not with current nfs-utils. And even if it did: show me anyone who uses standard NFS for anything half-serious that isn't using the patches. (either they're patching themselves or their vendor has included the patch). > so then, someone should pick up the ball and break up the NFS > patch into acceptable, useful, tested chunks. Avoid the stuff > that breaks backwards compatibility, backward compat with what? we're now in the situation that the biggest problem is that so vendors are using different revisions of the nfs problems. none that i know of ship stock linux nfs. even worse: we also have the situation that sometimes people submit small patches against stock linux NFS to fix small problems that are either fixed in the nfs patch or simply were never present in the nfs patches. > but submit the other fixes to > Alan, describing in detail each problem fixed by each patch. > that'd be worth discussing on the nfs list... good idea. > Jeff --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, Sep 11, 2000 at 05:08:22PM +0100, Alan Cox wrote: > > The very fact that a large and important patch by > > (as far as I can see) the NFS _maintainers_ is not > > being accepted by the stable kernel maintainer does > > not fill one with hope about the quality of the patch. > > The current patch actually looks pretty good. Its a timing issue now An important lesson for me was 'the timing is never right'. Bite the bullet, and things will be all right. Fear-of-merging is a well known programmer phenomenon, best solved by: merging. Of course NFS has some influence on bugreports but the crosstalk should be minimal. I just merged a chunk of code in my non-open source project and I now feel that I waited far too long. The same might go for NFS. Regards, bert hubert -- | http://www.rent-a-nerd.nl | - U N I X - | Inspice et cautus eris - D11T'95 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, Sep 11, 2000 at 05:08:22PM +0100, Alan Cox wrote: The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. The current patch actually looks pretty good. Its a timing issue now An important lesson for me was 'the timing is never right'. Bite the bullet, and things will be all right. Fear-of-merging is a well known programmer phenomenon, best solved by: merging. Of course NFS has some influence on bugreports but the crosstalk should be minimal. I just merged a chunk of code in my non-open source project and I now feel that I waited far too long. The same might go for NFS. Regards, bert hubert -- | http://www.rent-a-nerd.nl | - U N I X - | Inspice et cautus eris - D11T'95 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Jeff Garzik wrote: I hear that the new NFS patch is "better and more stable" etc. but no details. hard to give details as i havn't used unpatched linux 2.2 nfs in a very long time. best evidence from me is anecdotal: linux 2.4 / 2.2 nfs patches works perfectly for me (linux server, linux/irix clients, V2 and V3), and Trond et al are very responsive if there's problem. (eg silly delete handling bit me a couple of weeks ago, and Trond redid it and had a patch for me within a week or so of diagnosing the problem.). What I remember from using unpatched linux nfs is that it was /awful/ compared to the other unixen i used, most notably in the stability dept. As i remember it a standard linux NFS server never had much of an uptime because of NFS. also dreadful performance to non-linux clients. It seems to me that if you want an NFS problem fixed in 2.2.x, address that a single problem with a reproducible test and a small, focused kernel patch sent to Alan. there is a patch (well a couple - server side and client side). The problem is it is never integrated, so now after more than a year of development in NFS the difference between linux nfs and /current/ NFS is bound to be huge. Whatever Alan's reasons for not including "the 2.2.x NFS patch", I serious doubt among those reasons is "keep NFS dreadful and unstable." ;-) unless alan is being paid off by the commercial *nix vendors looking to sell NFS server - no of course not. :) Maybe it breaks backwards compatibility... not with current nfs-utils. And even if it did: show me anyone who uses standard NFS for anything half-serious that isn't using the patches. (either they're patching themselves or their vendor has included the patch). so then, someone should pick up the ball and break up the NFS patch into acceptable, useful, tested chunks. Avoid the stuff that breaks backwards compatibility, backward compat with what? we're now in the situation that the biggest problem is that so vendors are using different revisions of the nfs problems. none that i know of ship stock linux nfs. even worse: we also have the situation that sometimes people submit small patches against stock linux NFS to fix small problems that are either fixed in the nfs patch or simply were never present in the nfs patches. but submit the other fixes to Alan, describing in detail each problem fixed by each patch. that'd be worth discussing on the nfs list... good idea. Jeff --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, Sep 12, 2000 at 03:00:29PM +0100, Paul Jakma wrote: On Mon, 11 Sep 2000, Alan Cox wrote: Shrug. So you want me to make it worse by shipping unproven code in a way I can't test it ? the code is in 2.4 and has been tested there though. the patches are a backport of the 2.4 code. ..so it should be at least as well tested as the USB backport in 2.2.18preX, if not more so? Or so is implied. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
..so it should be at least as well tested as the USB backport in 2.2.18preX, if not more so? Or so is implied. :) This is the big clue most people are missing 2.2.17 - USB devices do not work 2.2.18 - USB=n no kernel change USB devices still do not work USB=m USB works for most people USB cant make things any worse than now because you can compile it out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote: They exist in the same way. You update stuff in controlled careful steps and you change troublesome drivers very early in a patch release - eg never touching tulip except early on true. as i said before i'm glad we have such a 'tight' stable kernel maintainer. :) the problem is, NFS updates /never/ make it in - well once, but even then not the complete NFSv2 update. as for tulip, i know what you mean. however, i think in this case you'd be very hard pressed to find anyone for whom the patches are anything but a vast improvement. anyway... i've gone hoarse now. better stop. :) regards, Paul Jakma - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote:
..so it should be at least as well tested as the USB backport in 2.2.18preX,
if not more so? Or so is implied. :)
This is the big clue most people are missing
2.2.17- USB devices do not work
2.2.18- USB=n no kernel change USB devices still do not work
USB=m USB works for most people
USB cant make things any worse than now because you can compile it out.
I see where you are coming from, but the {"stock 2.4","2.2 patch"} NFS
code is well tested, lots of bug fixes for NFSv2 and the 'new' code -
NFSv3 client/server is a compile yes/no option, just like the USB
backport.
2.2 without patches - NFS has performance/reliability problems
2.2 with patches- NFSv2 provided with lots of bugfixes
NFSv3 is compile time optional
I have not heard of anyone that prefers stock 2.2 NFS over
patched/2.4. Anecdotal evidence[1] suggests:
- stock 2.2 has 'issues' with NFS, serving in particular. Bad enough
that linux users would consider switching to another *nix for NFS
serving.
- 2.2 + NFS patches does not have issues (or very few), and would even
appear to work quite well, definitely for NFSv2 and seemingly for
the optional v3[2]. Certainly you need the patches for
interoperability.
- all the NFS developers are working the 2.4 code and backporting to
2.2. So issues wrt to the current 2.2 NFS codebase will not get
fixed. Issues wrt to the 2.4 backport do get fixed.
So the anecdotal evidence suggests we don't have anything to lose but
a not very good NFS server, and everything to gain.
What are the issues with updating NFS code that do not exist with
other drivers, filesystems, etc... in 2.2 for which updates are
accepted?
what is there to lose?
--paulj
[1]. as gathered from posts to this thread, to the nfs sourceforge
lists and my experience of stock NFS as of over a year ago and the NFS
patches since then.
[2]. linux v3 works flawlessly against IRIX 6.2 + ONC3 updates, both
as client and server, for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Horst von Brand wrote:
Better asK: What can _we_ do to assure Alan that NFS is up to snuff?
even if it does suck - so what? it can't possibly suck as much as
current stock NFS. :) but the general view is that 2.2 with patches
is quite useable for NFS serving and as client.
How can we help along?
the NFS patches (which are a backport of stock 2.4, which descended
from the original 2.2 NFS patches) are now too large and too
different from stock 2.2 to realistically be split up into small
little "this fixes this exact problem". The code is now so far ahead
of stock 2.2 that it is an effective rewrite (and with new, but
optional, NFSv3 client and server and NFS client over TCP code added
on).
alan seems to {want,prefer} small incremental/'obvious fix' patches.
but that isn't practically possible anymore. It would mean the NFS
guys would effectively have to redo the entire development cycle of
code they have written over the last year.
In lieu of a technical argument such as small patches, the only other
arguments are those based on the experiences of people who have tried
to get linux to work reliably as an NFS server and even client. I've
tried to cover those in a previous email, see:
Message-ID: [EMAIL PROTECTED]
So it is now at the stage where we either:
1. bite the bullet and sync stock nfs with nfs.sourceforge.net
or
2. accept that stock 2.2 will never have decent NFS server
functionality, and wait for 2.4 to get stable.
we await 2.219pre1 with much curiosity. :)
regards,
--
Paul Jakma [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Where you stand depends on where you sit.
-- Rufus Miles, HEW
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Paul Jakma wrote:
alan seems to {want,prefer} small incremental/'obvious fix' patches.
but that isn't practically possible anymore. It would mean the NFS
guys would effectively have to redo the entire development cycle of
code they have written over the last year.
[...]
So it is now at the stage where we either:
1. bite the bullet and sync stock nfs with nfs.sourceforge.net
or
2. accept that stock 2.2 will never have decent NFS server
functionality, and wait for 2.4 to get stable.
I don't think anybody has to redo a lot of development in order to
submit Alan small, focused patches. So option #3, break up the big NFS
patch into small ones, still seems like the best option.
All this requires is a hacker, or hackers, who are interested enough in
2.2.x NFS to do something besides complaining :)
Jeff
--
Jeff Garzik | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc. |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
In article cs.lists.linux-kernel/8pmnfc$6p1$[EMAIL PROTECTED] you wrote: Think Alan has made that clear. The way I read things the nfsv2 stuff needs to be split out, into sets of small independent patches. This lets Alan audit and control any bad patches easily. The nfsv3 changes should not effect anything unless they are selected in the kernel build. Comments? Are you volunteering to do it? No? I thought so. Personally, I'd rather let Trond spend his precious little spare time on useful things like improving the code and fixing whatever problems are left, then have him waste it on such a useless thing. If this means we have to keep patching each 2.2 release in order to get usable NFS, so be it. And, just to make things clear: Alan has *never* said what you imply. It was Jeff Garzik's suggestion. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Alan Cox wrote:
> 2.2.18pre4
> o Fix some of the dquot races (Jan Kara)
this appears to be basically the same patch as applied to 2.4.0t8 vs. t7
producing an Oops in dquot_transfer(). This issue can (at least) be
triggered by chown'ing a file on an (userquota && !groupquota) filesystem
from an user with unlimited quota to one who is restricted.
I've sent a fix for this to the diskquota-maintainer ([EMAIL PROTECTED])
and l-k yesterday. With a few lines offset the same patch should be
applicable to 2.2.18pre4 - but haven't tested in this context!
Martin
--- linux-2.4.0-test8/fs/dquot.c.orig Mon Sep 11 01:42:56 2000
+++ linux-2.4.0-test8/fs/dquot.cMon Sep 11 02:12:04 2000
@@ -1285,12 +1285,15 @@
blocks = isize_to_blocks(inode->i_size, BLOCK_SIZE_BITS);
else
blocks = (inode->i_blocks >> 1);
- for (cnt = 0; cnt < MAXQUOTAS; cnt++)
+ for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
+ if (transfer_to[cnt] == NODQUOT)
+ continue;
if (check_idq(transfer_to[cnt], 1) == NO_QUOTA ||
check_bdq(transfer_to[cnt], blocks, 0) == NO_QUOTA) {
cnt = MAXQUOTAS;
goto put_all;
}
+ }
if ((error = notify_change(dentry, iattr)))
goto put_all;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> Why not use the NFS patch that almost all Linux > distributions have been shipping with for months? Most of those patches are in I believe. Whats needed next is to jump to the major revision. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Paul Jakma wrote: > > On Sun, 10 Sep 2000, Albert D. Cahalan wrote: > > > escape Linux 2.2.xx NFS. This is kind of serious, you know? > > yep. it is serious. we've been begging for knfsd to be updated to the > most /current/ code for quite a while a now. I searched the archives > and i found a post of mine asking alan to consider an NFS patch sync > for 2.2.something - over a year ago. > > standard linux NFS is dreadful and unstable, and that's just between > linux machines. other unixen as clients? don't even try. I hear that the new NFS patch is "better and more stable" etc. but no details. It seems to me that if you want an NFS problem fixed in 2.2.x, address that a single problem with a reproducible test and a small, focused kernel patch sent to Alan. Whatever Alan's reasons for not including "the 2.2.x NFS patch", I serious doubt among those reasons is "keep NFS dreadful and unstable." ;-) Maybe it breaks backwards compatibility... so then, someone should pick up the ball and break up the NFS patch into acceptable, useful, tested chunks. Avoid the stuff that breaks backwards compatibility, but submit the other fixes to Alan, describing in detail each problem fixed by each patch. Jeff -- Jeff Garzik | Isn't it strange that the same people Building 1024| that laugh at gypsy fortune tellers MandrakeSoft, Inc. | take economists seriously? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Alan Cox wrote: > > Over on the freebsd-questions mailing list you can see desperate > > people trying to convert Linux systems over to that other OS to > > escape Linux 2.2.xx NFS. This is kind of serious, you know? > > Shrug. So you want me to make it worse by shipping unproven code > in a way I can't test it ? Why not use the NFS patch that almost all Linux distributions have been shipping with for months? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan Cox writes: >> Over on the freebsd-questions mailing list you can see desperate >> people trying to convert Linux systems over to that other OS to >> escape Linux 2.2.xx NFS. This is kind of serious, you know? > > Shrug. So you want me to make it worse by shipping unproven code > in a way I can't test it ? Since it can't get much worse, yes. This is like treatment for the terminally ill. One tries all sorts of experimental things because there is little or nothing to lose. With software, you can even back out changes if the patient dies. > And FreeBSD people flow steadily to Linux too. I've never seen it. Going the other way is common. > 2.2 is the stable branch, my job is to keep it stable. > That means I have a permanent queue of neat things I > really want to apply but can't right now. Many would interpret "stable" as "not prone to crashes and other erratic behavior". Those who dislike change can keep 2.2.16 as long as they like. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Not so sure about NFSv3 server, since i haven´t pushed it that much, but as a NFSv2 server and client, and a NFSv3 client, it has proven itself to me. And i have a network comprised of about 40 Solaris, Irix, Aix and Linux machines, running different releases of each operating system. While someone mentioned having considered Freebsd, more recently i have considered Solaris x86, due to the licensing changes. Not much of a performer in general, but it has solid NFSv2 and v3 from stock. Pedro On 11 Sep 00, at 16:56, Alan Cox wrote: > Over on the freebsd-questions mailing list you can see desperate > people trying to convert Linux systems over to that other OS to > escape Linux 2.2.xx NFS. This is kind of serious, you know? Shrug. So you want me to make it worse by shipping unproven code in a way I can't test 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: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> The very fact that a large and important patch by > (as far as I can see) the NFS _maintainers_ is not > being accepted by the stable kernel maintainer does > not fill one with hope about the quality of the patch. The current patch actually looks pretty good. Its a timing issue now - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Albert D. Cahalan wrote: > escape Linux 2.2.xx NFS. This is kind of serious, you know? yep. it is serious. we've been begging for knfsd to be updated to the most /current/ code for quite a while a now. I searched the archives and i found a post of mine asking alan to consider an NFS patch sync for 2.2.something - over a year ago. standard linux NFS is dreadful and unstable, and that's just between linux machines. other unixen as clients? don't even try. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, David S. Miller wrote: >Over on the freebsd-questions mailing list you can see desperate >people trying to convert Linux systems over to that other OS to >escape Linux 2.2.xx NFS. This is kind of serious, you know? > > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Yep, and I have seen it too. (Though not to BSD.) People would rather switch OSes than apply a patch which Alan won't accept. The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Albert D. Cahalan wrote: escape Linux 2.2.xx NFS. This is kind of serious, you know? yep. it is serious. we've been begging for knfsd to be updated to the most /current/ code for quite a while a now. I searched the archives and i found a post of mine asking alan to consider an NFS patch sync for 2.2.something - over a year ago. standard linux NFS is dreadful and unstable, and that's just between linux machines. other unixen as clients? don't even try. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Not so sure about NFSv3 server, since i haven´t pushed it that much, but as a NFSv2 server and client, and a NFSv3 client, it has proven itself to me. And i have a network comprised of about 40 Solaris, Irix, Aix and Linux machines, running different releases of each operating system. While someone mentioned having considered Freebsd, more recently i have considered Solaris x86, due to the licensing changes. Not much of a performer in general, but it has solid NFSv2 and v3 from stock. Pedro On 11 Sep 00, at 16:56, Alan Cox wrote: Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? Shrug. So you want me to make it worse by shipping unproven code in a way I can't test 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: Linux 2.2.18pre4
Alan Cox writes: Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? Shrug. So you want me to make it worse by shipping unproven code in a way I can't test it ? Since it can't get much worse, yes. This is like treatment for the terminally ill. One tries all sorts of experimental things because there is little or nothing to lose. With software, you can even back out changes if the patient dies. And FreeBSD people flow steadily to Linux too. I've never seen it. Going the other way is common. 2.2 is the stable branch, my job is to keep it stable. That means I have a permanent queue of neat things I really want to apply but can't right now. Many would interpret "stable" as "not prone to crashes and other erratic behavior". Those who dislike change can keep 2.2.16 as long as they like. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Alan Cox wrote: Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? Shrug. So you want me to make it worse by shipping unproven code in a way I can't test it ? Why not use the NFS patch that almost all Linux distributions have been shipping with for months? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Alan Cox wrote:
2.2.18pre4
o Fix some of the dquot races (Jan Kara)
this appears to be basically the same patch as applied to 2.4.0t8 vs. t7
producing an Oops in dquot_transfer(). This issue can (at least) be
triggered by chown'ing a file on an (userquota !groupquota) filesystem
from an user with unlimited quota to one who is restricted.
I've sent a fix for this to the diskquota-maintainer ([EMAIL PROTECTED])
and l-k yesterday. With a few lines offset the same patch should be
applicable to 2.2.18pre4 - but haven't tested in this context!
Martin
--- linux-2.4.0-test8/fs/dquot.c.orig Mon Sep 11 01:42:56 2000
+++ linux-2.4.0-test8/fs/dquot.cMon Sep 11 02:12:04 2000
@@ -1285,12 +1285,15 @@
blocks = isize_to_blocks(inode-i_size, BLOCK_SIZE_BITS);
else
blocks = (inode-i_blocks 1);
- for (cnt = 0; cnt MAXQUOTAS; cnt++)
+ for (cnt = 0; cnt MAXQUOTAS; cnt++) {
+ if (transfer_to[cnt] == NODQUOT)
+ continue;
if (check_idq(transfer_to[cnt], 1) == NO_QUOTA ||
check_bdq(transfer_to[cnt], blocks, 0) == NO_QUOTA) {
cnt = MAXQUOTAS;
goto put_all;
}
+ }
if ((error = notify_change(dentry, iattr)))
goto put_all;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. The current patch actually looks pretty good. Its a timing issue now - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, David S. Miller wrote: Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Yep, and I have seen it too. (Though not to BSD.) People would rather switch OSes than apply a patch which Alan won't accept. The very fact that a large and important patch by (as far as I can see) the NFS _maintainers_ is not being accepted by the stable kernel maintainer does not fill one with hope about the quality of the patch. Matthew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
David S. Miller writes: > From: "Albert D. Cahalan" <[EMAIL PROTECTED]> >> Over on the freebsd-questions mailing list you can see desperate >> people trying to convert Linux systems over to that other OS to >> escape Linux 2.2.xx NFS. This is kind of serious, you know? > > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Yes. Reasons why this may be so: 1. Confidence has been lost. The OS is seen as buggy crap. Patches are perceived as being mere bandaids. 2. Existence of the required patches is not well known. Most people don't know to look for patches when something goes wrong. Patches don't get banner ads on Slashdot. 3. If a patch is found, can you trust it? It could be obsolete, buggy, or even a trojan. 4. Not everybody with NFS problems knows what to do with a patch. For the last person I helped, reason #2 was the primary problem. I saw hints of #1 and #3 as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: >From: "Albert D. Cahalan" <[EMAIL PROTECTED]> >Date: Sun, 10 Sep 2000 23:05:29 -0400 (EDT) > >Over on the freebsd-questions mailing list you can see desperate >people trying to convert Linux systems over to that other OS to >escape Linux 2.2.xx NFS. This is kind of serious, you know? > > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Well, it seems a good many people don't know there are patches out there for NFS that make it bearable or don't want to try and compile a kernel. As an aside, anyone know which vendors kernel source either a) has some variant of the NFS patches or b) has a clean enough tree that new ones apply fine? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
From: "Albert D. Cahalan" <[EMAIL PROTECTED]> Date:Sun, 10 Sep 2000 23:05:29 -0400 (EDT) Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan Cox writes: > [somebody] >> Alan, are the NFS client/server patches EVER going to >> make it into the base kernel? Inquiring minds want to know.. > > I still hope so but there is a maximum sane rate of change and > its important to change stuff piece by piece. 2.2.18pre4 isnt > the right place to change NFS Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? I'm doing my part to save these lost souls... anybody else up for last-chance emergency tech support? (scan for subjects like "can freebsd understand ext2?", then help the person solve their Linux problems at nfs.sourceforge.net or wherever) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4 make xconfig error
On "make xconfig" error on /fs/nls/Config.in, line 8 if error due to missing "" on n Art Wagner Alan Cox wrote: > > This cleans up a lot of the small bugs, some ext2 races and other smaller > items partly from 2.2.17 partly from the new code. Hopefully the changes > from now on through to 2.2.18 can be smaller as we shake stuff out of the > drivers and other stuff merged. > - > 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan - What is PRE4 applied against? I'm seeing errors patching up from either 17pre20 or 2.2.17 final. | Begathon, n.: A multi-day event on public Jeff Hittman | television, used to raise money so you won't have [EMAIL PROTECTED] | to watch commercials. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4 (smbfs config.in patch)
A patch for the Config.in problems with smbfs. /Urban diff -ur -X exclude linux-2.2.18-pre4-orig/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.2.18-pre4-orig/Documentation/Configure.help Sun Sep 10 20:07:56 2000 +++ linux/Documentation/Configure.help Sun Sep 10 20:13:11 2000 @@ -7948,6 +7948,13 @@ want), say M here and read Documentation/modules.txt. The module will be called smbfs.o. Most people say N, however. +use nls by default +CONFIG_SMB_NLS_DEFAULT + Enabling this will make smbfs use nls translations by default. You + need to specify the local charset (CONFIG_NLS_DEFAULT) in the nls + settings and you need to give the default nls for the SMB server as + CONFIG_SMB_NLS_REMOTE. + nls support setting CONFIG_SMB_NLS_REMOTE This setting allows you to specify a default value for which diff -ur -X exclude linux-2.2.18-pre4-orig/fs/Config.in linux/fs/Config.in --- linux-2.2.18-pre4-orig/fs/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/Config.in Sun Sep 10 20:14:18 2000 @@ -92,7 +92,10 @@ fi tristate 'SMB filesystem support (to mount WfW shares etc.)' CONFIG_SMB_FS if [ "$CONFIG_SMB_FS" != "n" ]; then - string 'Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "" + bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT + if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then +string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + fi fi fi if [ "$CONFIG_IPX" != "n" -o "$CONFIG_INET" != "n" ]; then diff -ur -X exclude linux-2.2.18-pre4-orig/fs/nls/Config.in linux/fs/nls/Config.in --- linux-2.2.18-pre4-orig/fs/nls/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/nls/Config.in Sun Sep 10 20:16:26 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n diff -ur -X exclude linux-2.2.18-pre4-orig/fs/smbfs/inode.c linux/fs/smbfs/inode.c --- linux-2.2.18-pre4-orig/fs/smbfs/inode.c Sun Sep 10 20:08:26 2000 +++ linux/fs/smbfs/inode.c Sun Sep 10 20:14:55 2000 @@ -32,6 +32,13 @@ #include "smb_debug.h" +/* Always pick a default string */ +#ifdef CONFIG_SMB_NLS_REMOTE +#define SMB_NLS_REMOTE CONFIG_SMB_NLS_REMOTE +#else +#define SMB_NLS_REMOTE "" +#endif + static void smb_read_inode(struct inode *); static void smb_put_inode(struct inode *); static void smb_delete_inode(struct inode *); @@ -383,7 +390,7 @@ memcpy(mnt, raw_data, sizeof(struct smb_mount_data)); strncpy(mnt->codepage.local_name, CONFIG_NLS_DEFAULT, SMB_NLS_MAXNAMELEN); - strncpy(mnt->codepage.remote_name, CONFIG_SMB_NLS_REMOTE, + strncpy(mnt->codepage.remote_name, SMB_NLS_REMOTE, SMB_NLS_MAXNAMELEN); /* FIXME: ** temp ** pass config flags in file mode */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
> Alan, are the NFS client/server patches EVER going to make it > into the base kernel? Inquiring minds want to know.. I still hope so but there is a maximum sane rate of change and its important to change stuff piece by piece. 2.2.18pre4 isnt the right place to change NFS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Alan Cox wrote: > This cleans up a lot of the small bugs, some ext2 races and other smaller > items partly from 2.2.17 partly from the new code. Hopefully the changes > from now on through to 2.2.18 can be smaller as we shake stuff out of the > drivers and other stuff merged. > > 2.2.18pre4 Alan, are the NFS client/server patches EVER going to make it into the base kernel? Inquiring minds want to know.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Alan Cox wrote: This cleans up a lot of the small bugs, some ext2 races and other smaller items partly from 2.2.17 partly from the new code. Hopefully the changes from now on through to 2.2.18 can be smaller as we shake stuff out of the drivers and other stuff merged. 2.2.18pre4 sigh.. Alan, are the NFS client/server patches EVER going to make it into the base kernel? Inquiring minds want to know.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
sigh.. Alan, are the NFS client/server patches EVER going to make it into the base kernel? Inquiring minds want to know.. I still hope so but there is a maximum sane rate of change and its important to change stuff piece by piece. 2.2.18pre4 isnt the right place to change NFS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4 (smbfs config.in patch)
A patch for the Config.in problems with smbfs. /Urban diff -ur -X exclude linux-2.2.18-pre4-orig/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.2.18-pre4-orig/Documentation/Configure.help Sun Sep 10 20:07:56 2000 +++ linux/Documentation/Configure.help Sun Sep 10 20:13:11 2000 @@ -7948,6 +7948,13 @@ want), say M here and read Documentation/modules.txt. The module will be called smbfs.o. Most people say N, however. +use nls by default +CONFIG_SMB_NLS_DEFAULT + Enabling this will make smbfs use nls translations by default. You + need to specify the local charset (CONFIG_NLS_DEFAULT) in the nls + settings and you need to give the default nls for the SMB server as + CONFIG_SMB_NLS_REMOTE. + nls support setting CONFIG_SMB_NLS_REMOTE This setting allows you to specify a default value for which diff -ur -X exclude linux-2.2.18-pre4-orig/fs/Config.in linux/fs/Config.in --- linux-2.2.18-pre4-orig/fs/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/Config.in Sun Sep 10 20:14:18 2000 @@ -92,7 +92,10 @@ fi tristate 'SMB filesystem support (to mount WfW shares etc.)' CONFIG_SMB_FS if [ "$CONFIG_SMB_FS" != "n" ]; then - string 'Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "" + bool ' Use a default NLS' CONFIG_SMB_NLS_DEFAULT + if [ "$CONFIG_SMB_NLS_DEFAULT" = "y" ]; then +string ' Default Remote NLS Option' CONFIG_SMB_NLS_REMOTE "cp437" + fi fi fi if [ "$CONFIG_IPX" != "n" -o "$CONFIG_INET" != "n" ]; then diff -ur -X exclude linux-2.2.18-pre4-orig/fs/nls/Config.in linux/fs/nls/Config.in --- linux-2.2.18-pre4-orig/fs/nls/Config.in Sun Sep 10 20:08:25 2000 +++ linux/fs/nls/Config.in Sun Sep 10 20:16:26 2000 @@ -5,7 +5,7 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != n ]; then + -o "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n diff -ur -X exclude linux-2.2.18-pre4-orig/fs/smbfs/inode.c linux/fs/smbfs/inode.c --- linux-2.2.18-pre4-orig/fs/smbfs/inode.c Sun Sep 10 20:08:26 2000 +++ linux/fs/smbfs/inode.c Sun Sep 10 20:14:55 2000 @@ -32,6 +32,13 @@ #include "smb_debug.h" +/* Always pick a default string */ +#ifdef CONFIG_SMB_NLS_REMOTE +#define SMB_NLS_REMOTE CONFIG_SMB_NLS_REMOTE +#else +#define SMB_NLS_REMOTE "" +#endif + static void smb_read_inode(struct inode *); static void smb_put_inode(struct inode *); static void smb_delete_inode(struct inode *); @@ -383,7 +390,7 @@ memcpy(mnt, raw_data, sizeof(struct smb_mount_data)); strncpy(mnt-codepage.local_name, CONFIG_NLS_DEFAULT, SMB_NLS_MAXNAMELEN); - strncpy(mnt-codepage.remote_name, CONFIG_SMB_NLS_REMOTE, + strncpy(mnt-codepage.remote_name, SMB_NLS_REMOTE, SMB_NLS_MAXNAMELEN); /* FIXME: ** temp ** pass config flags in file mode */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan - What is PRE4 applied against? I'm seeing errors patching up from either 17pre20 or 2.2.17 final. | Begathon, n.: A multi-day event on public Jeff Hittman | television, used to raise money so you won't have [EMAIL PROTECTED] | to watch commercials. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4 make xconfig error
On "make xconfig" error on /fs/nls/Config.in, line 8 if error due to missing "" on n Art Wagner Alan Cox wrote: This cleans up a lot of the small bugs, some ext2 races and other smaller items partly from 2.2.17 partly from the new code. Hopefully the changes from now on through to 2.2.18 can be smaller as we shake stuff out of the drivers and other stuff merged. - 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Alan Cox writes: [somebody] sigh.. Alan, are the NFS client/server patches EVER going to make it into the base kernel? Inquiring minds want to know.. I still hope so but there is a maximum sane rate of change and its important to change stuff piece by piece. 2.2.18pre4 isnt the right place to change NFS Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? I'm doing my part to save these lost souls... anybody else up for last-chance emergency tech support? (scan for subjects like "can freebsd understand ext2?", then help the person solve their Linux problems at nfs.sourceforge.net or wherever) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
From: "Albert D. Cahalan" [EMAIL PROTECTED] Date:Sun, 10 Sep 2000 23:05:29 -0400 (EDT) Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
David S. Miller writes: From: "Albert D. Cahalan" [EMAIL PROTECTED] Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Yes. Reasons why this may be so: 1. Confidence has been lost. The OS is seen as buggy crap. Patches are perceived as being mere bandaids. 2. Existence of the required patches is not well known. Most people don't know to look for patches when something goes wrong. Patches don't get banner ads on Slashdot. 3. If a patch is found, can you trust it? It could be obsolete, buggy, or even a trojan. 4. Not everybody with NFS problems knows what to do with a patch. For the last person I helped, reason #2 was the primary problem. I saw hints of #1 and #3 as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: From: "Albert D. Cahalan" [EMAIL PROTECTED] Date: Sun, 10 Sep 2000 23:05:29 -0400 (EDT) Over on the freebsd-questions mailing list you can see desperate people trying to convert Linux systems over to that other OS to escape Linux 2.2.xx NFS. This is kind of serious, you know? So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Well, it seems a good many people don't know there are patches out there for NFS that make it bearable or don't want to try and compile a kernel. As an aside, anyone know which vendors kernel source either a) has some variant of the NFS patches or b) has a clean enough tree that new ones apply fine? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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/
