Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-18 Thread Hubert Mantel
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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-15 Thread Andreas Bombe
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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Andre Hedrick
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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Chip Salzenberg
According to Andre Hedrick: > 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 [...] > > Thanks Chip but the backporting to 2.2 has been terminated. So I've

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Richard B. Johnson
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.

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Ralf Gerbig
* 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 i

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Alan Cox
> > 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 c

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Matthew Kirkwood
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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Andre Hedrick
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 cler

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Alan Cox
> [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)

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread David S. Miller
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]

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

2000-09-13 Thread Chip Salzenberg
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 develo

Re: Linux 2.2.18pre4

2000-09-13 Thread Alexander Viro
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 pat

Re: Linux 2.2.18pre4

2000-09-13 Thread Chip Salzenberg
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. Ser

Re: Linux 2.2.18pre4

2000-09-13 Thread Alan Cox
> > 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

Re: Linux 2.2.18pre4

2000-09-13 Thread Alan Cox
> 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 th

Re: Linux 2.2.18pre4

2000-09-13 Thread Steven N. Hirsch
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

Re: Linux 2.2.18pre4

2000-09-12 Thread Ion Badulescu
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 anythi

Re: Linux 2.2.18pre4

2000-09-12 Thread Ed Tomlinson
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 b

Re: Linux 2.2.18pre4

2000-09-12 Thread Horst von Brand
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

Re: Linux 2.2.18pre4

2000-09-12 Thread Jeff Garzik
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 t

Re: Linux 2.2.18pre4

2000-09-12 Thread Paul Jakma
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

Re: Linux 2.2.18pre4

2000-09-12 Thread Ralf Gerbig
* Chris Wedgwood writes: [CC trimmed] Hi Cris, > Logical or otherwise, people _do_ this. I know plenty of people who > install linux or Redhat from the CD -- they never build their own > kernels, etc. It's not something they would consider; they like the > 'shrink-wrap' stuff (sans security upd

Re: Linux 2.2.18pre4

2000-09-12 Thread Alan Cox
> 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 to

Re: Linux 2.2.18pre4

2000-09-12 Thread Paul Jakma
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

Re: Linux 2.2.18pre4

2000-09-12 Thread Paul Jakma
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 m

Re: Linux 2.2.18pre4

2000-09-12 Thread Horst von Brand
Tom Rini <[EMAIL PROTECTED]> said: > 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

Re: Linux 2.2.18pre4

2000-09-12 Thread Alan Cox
> ..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

Re: Linux 2.2.18pre4

2000-09-12 Thread Tom Rini
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 t

Re: Linux 2.2.18pre4

2000-09-12 Thread Paul Jakma
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 "uns

Re: Linux 2.2.18pre4

2000-09-12 Thread Paul Jakma
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 (li

Re: Linux 2.2.18pre4

2000-09-11 Thread bert hubert
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

Re: Linux 2.2.18pre4

2000-09-11 Thread Martin Diehl
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 (

Re: Linux 2.2.18pre4

2000-09-11 Thread Alan Cox
> 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

Re: Linux 2.2.18pre4

2000-09-11 Thread Jeff Garzik
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

Re: Linux 2.2.18pre4

2000-09-11 Thread Rik van Riel
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 unp

Re: Linux 2.2.18pre4

2000-09-11 Thread Albert D. Cahalan
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

Re: Linux 2.2.18pre4

2000-09-11 Thread Pedro M. Rodrigues
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. Whil

Re: Linux 2.2.18pre4

2000-09-11 Thread 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. mrc -- Mike Castle Life is like a clock: You can work co

Re: Linux 2.2.18pre4

2000-09-11 Thread Alan Cox
> 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 unsubs

Re: Linux 2.2.18pre4

2000-09-11 Thread Admin Mailing Lists
ditto..i patched 2.2.16 with 2.2.17pre20 fine. then patched that with 2.2.18pre4 and got this: can't find file to patch at input line 4697 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -u --new-file --recursive --exclude-from /

Re: Linux 2.2.18pre4

2000-09-11 Thread Alan Cox
> 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 ? > for las

Re: Linux 2.2.18pre4

2000-09-11 Thread Paul Jakma
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 conside

Re: Linux 2.2.18pre4

2000-09-11 Thread Matthew Kirkwood
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 pre

Re: Linux 2.2.18pre4

2000-09-10 Thread Albert D. Cahalan
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 situat

Re: Linux 2.2.18pre4

2000-09-10 Thread Tom Rini
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 tha

Re: Linux 2.2.18pre4

2000-09-10 Thread David S. Miller
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 kn

Re: Linux 2.2.18pre4

2000-09-10 Thread Albert D. Cahalan
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

Re: Linux 2.2.18pre4 make xconfig error

2000-09-10 Thread Art Wagner
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.1

Re: Linux 2.2.18pre4

2000-09-10 Thread Jeff Hittman
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.

Re: Linux 2.2.18pre4 (smbfs config.in patch)

2000-09-10 Thread Urban Widmark
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

Re: Linux 2.2.18pre4

2000-09-10 Thread Alan Cox
> 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 fr

Re: Linux 2.2.18pre4

2000-09-10 Thread Steven N. Hirsch
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.