Linux 2.4 future

Linux 2.4 future

[Ralf Baechle]

For those of you who don't follow linux-kernel below Marcelo's posting
about the future of 2.4.  I think we should follow that for MIPS also,
so whatever new feature you still may have pending for 2.4, send it
soon - or for 2.6.

I also remind everybody that a 2.6.0 release is expect already before the
end of the year and the MIPS kernel is not exactly in the shape we'd
like it to be - time to switch to 2.6 for active development!

  Ralf

----- Forwarded message from Marcelo Tosatti <marcelo.tosatti@cyclades.com> -----

From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Date: Mon, 1 Dec 2003 12:25:23 -0200 (BRST)
To: linux-kernel@vger.kernel.org
Subject: Linux 2.4 future 
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi, 

The intention of this email is to clarify my position on 2.4.x future.

2.6 is becoming more stable each day, and we will hopefully see a 2.6.0
release during this month or January.

Having that mentioned, I pretend to:

- Fix pending problems which might required more intrusive modifications
during 2.4.24. New drivers will be accept during this period (for example,
Cyclades PC300 driver, input userlevel driver support, or other sane
driver which might come up).

- From 2.4.25 on, fix only critical/security problems.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

----- End forwarded message -----

  Ralf

Linux 2.4 future

[Marcelo Tosatti]

Hi, 

The intention of this email is to clarify my position on 2.4.x future.

2.6 is becoming more stable each day, and we will hopefully see a 2.6.0
release during this month or January.

Having that mentioned, I pretend to:

- Fix pending problems which might required more intrusive modifications
during 2.4.24. New drivers will be accept during this period (for example,
Cyclades PC300 driver, input userlevel driver support, or other sane
driver which might come up).

- From 2.4.25 on, fix only critical/security problems.

Re: Linux 2.4 future

[Ian Kent]

On Mon, 1 Dec 2003, Marcelo Tosatti wrote:

> 
> Hi, 
> 
> The intention of this email is to clarify my position on 2.4.x future.
> 
> 2.6 is becoming more stable each day, and we will hopefully see a 2.6.0
> release during this month or January.
> 
> Having that mentioned, I pretend to:
> 
> - Fix pending problems which might required more intrusive modifications
> during 2.4.24. New drivers will be accept during this period (for example,
> Cyclades PC300 driver, input userlevel driver support, or other sane
> driver which might come up).

Would you be willing to consider autofs4 patches that I would like 
included in 2.4?

Sounds like it's the last chance I'll get.

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[Christoph Hellwig]

On Mon, Dec 01, 2003 at 11:04:21PM +0800, Ian Kent wrote:
> Would you be willing to consider autofs4 patches that I would like 
> included in 2.4?

What autofs4 patches?  bugfixes, features?  if they aren't in
2.6 yet I don't think it makes sense trying to get them into
2.4 anymore at all.

Re: Linux 2.4 future

[Peter C. Norton]

On Mon, Dec 01, 2003 at 03:33:16PM +0000, Christoph Hellwig wrote:
> On Mon, Dec 01, 2003 at 11:04:21PM +0800, Ian Kent wrote:
> > Would you be willing to consider autofs4 patches that I would like 
> > included in 2.4?
> 
> What autofs4 patches?  bugfixes, features?  if they aren't in
> 2.6 yet I don't think it makes sense trying to get them into
> 2.4 anymore at all.

Ian has lots of bugfixes and and feature patches (like direct mounts)
going to the autofs mailing list.  Autofs4 has always had stability
issues in 2.4.x, and its been lacking in features.  This makes myself
and others run a bastard combination of amd, autofs and editing
/etc/fstab to get "automounter" features even close to the solaris
automounter.  If these can go into 2.4, which will be "stable" and in
use in lots of places for the next couple of years it could help by
encouraging the distros to get behind autofs4 (hint hint, redhat,
hint).

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Re: Linux 2.4 future

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
`
> encouraging the distros to get behind autofs4 (hint hint, redhat,
> hint).

I suspect you'll have a really hard time finding ANY distro that still
wants to actively develop new products on a 2.4 codebase.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.4 future

[Ian Kent]

On Tue, 2 Dec 2003, Arjan van de Ven wrote:

> On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
> `
> > encouraging the distros to get behind autofs4 (hint hint, redhat,
> > hint).
>
> I suspect you'll have a really hard time finding ANY distro that still
> wants to actively develop new products on a 2.4 codebase.
>

Do you feel that 2.6 will be stable enough, soon enough for us to not see
another RedHat 2.4.x?

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[Peter C. Norton]

On Tue, Dec 02, 2003 at 09:11:50AM +0800, Ian Kent wrote:
> Do you feel that 2.6 will be stable enough, soon enough for us to not see
> another RedHat 2.4.x?

IMO its too late for that.  AS3.0 has already come out, and with it a
probable 2 year life cycle at large installations where the kernel
will not move to 2.6 for stability reasons (by which I mean the
stability of the environment, not necessarily that of the kernel).

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Re: Linux 2.4 future

[Peter C. Norton]

On Tue, Dec 02, 2003 at 12:54:54AM +0100, Arjan van de Ven wrote:
> On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
> `
> > encouraging the distros to get behind autofs4 (hint hint, redhat,
> > hint).
> 
> I suspect you'll have a really hard time finding ANY distro that still
> wants to actively develop new products on a 2.4 codebase.

Perhaps, but some rather large customers of AS2.1, would like it if
redhat could deliver the large outstanding automounting features for
their (mainly sun) environments.  Since these environments resist
change, upgrading a kernel to include a newer autofs4 is more likely
than upgrading the whole system.

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Re: Linux 2.4 future

[Arjan van de Ven]

On Tue, Dec 02, 2003 at 12:10:40PM -0800, Peter C. Norton wrote:
> On Tue, Dec 02, 2003 at 12:54:54AM +0100, Arjan van de Ven wrote:
> > On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
> > `
> > > encouraging the distros to get behind autofs4 (hint hint, redhat,
> > > hint).
> > 
> > I suspect you'll have a really hard time finding ANY distro that still
> > wants to actively develop new products on a 2.4 codebase.
> 
> Perhaps, but some rather large customers of AS2.1, would like it if
> redhat could deliver the large outstanding automounting features for
> their (mainly sun) environments.  Since these environments resist
> change, upgrading a kernel to include a newer autofs4 is more likely
> than upgrading the whole system.

and putting a feature into 2.4.23 is going to help/change that... how ?

Re: Linux 2.4 future

[Peter C. Norton]

On Tue, Dec 02, 2003 at 09:18:00PM +0100, Arjan van de Ven wrote:
> On Tue, Dec 02, 2003 at 12:10:40PM -0800, Peter C. Norton wrote:
> > On Tue, Dec 02, 2003 at 12:54:54AM +0100, Arjan van de Ven wrote:
> > > On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
> > > `
> > > > encouraging the distros to get behind autofs4 (hint hint, redhat,
> > > > hint).
> > > 
> > > I suspect you'll have a really hard time finding ANY distro that still
> > > wants to actively develop new products on a 2.4 codebase.
> > 
> > Perhaps, but some rather large customers of AS2.1, would like it if
> > redhat could deliver the large outstanding automounting features for
> > their (mainly sun) environments.  Since these environments resist
> > change, upgrading a kernel to include a newer autofs4 is more likely
> > than upgrading the whole system.
> 
> and putting a feature into 2.4.23 is going to help/change that... how ?

The autofs4 kernel code is already in the mainline kernel and in
redhat's AS kernels.  However:

1) In the mainline its not complete (no direct mounts) 
2) In redhats AS kernels its not supported or complete.  A newer version 
   seems to only make sense.

Putting an upgrade to autofs4 in the mainline kernel once its proven
would give users the option of having a much more feature-complete and
un-broken automounter to use.  If its not hurting anything else then
why leave broken code in the kernel?  

Please correct me if I'm making too big a leap, because I have a
thought.  It seems that new hardware gets this sort of treatment - new
drivers for a NIC, scsi, or FC card will be included in a stable
series because with out it some subsystem of a computer "doesn't
work" completely.  What makes this case different?

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

Re: Linux 2.4 future

[Ian Kent]

We seem to be getting a little of track here.

Sorry, this is probably not the right place for this discussion but I feel
strongly enough about it to pursue it anyway.

Being one of the people that have to face the dificulties that Peter has,
I think that a solution satisfactory to all needs to be worked out.

There seems to be two seperate problems here:

1) Whether to merge a huge unknown quality patch into the 2.4 stable
kernel.

The majority of people seem to feel it is not efficient use of Marcelos'
time and recommend a merge into 2.6.

That's fine with me if that's Marcelos' decision.


2) The supportability of using autofs v4 in RedHats' commercial product.

This issue can't be fixed by simply adding this patch to the kernel.

There is a userspace daemon which is also not included in the RedHat
product. RedHat have no reason to trust my code for their commercial
customers and their commercial customers need the sort of changes I am
trying to make.

So the real question is "what can I do to enable this to be used, without
customer penalty, in RedHats' commercial product".

I have a kernel module kit that allows the module to be used without
wiping out the original (and back out the change if needed). I think I can
turn this into an RPM if that would help.

I'm about to make 4.1.0 a release. It's not perfect but it is certainly an
improvement on previous autofs v4 versions. A src RPM will be produced as
well.

Anyone have any suggestions on how to solve this problem?


On Tue, 2 Dec 2003, Peter C. Norton wrote:

> On Tue, Dec 02, 2003 at 09:18:00PM +0100, Arjan van de Ven wrote:
> > On Tue, Dec 02, 2003 at 12:10:40PM -0800, Peter C. Norton wrote:
> > > On Tue, Dec 02, 2003 at 12:54:54AM +0100, Arjan van de Ven wrote:
> > > > On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
> > > > `
> > > > > encouraging the distros to get behind autofs4 (hint hint, redhat,
> > > > > hint).
> > > >
> > > > I suspect you'll have a really hard time finding ANY distro that still
> > > > wants to actively develop new products on a 2.4 codebase.
> > >
> > > Perhaps, but some rather large customers of AS2.1, would like it if
> > > redhat could deliver the large outstanding automounting features for
> > > their (mainly sun) environments.  Since these environments resist
> > > change, upgrading a kernel to include a newer autofs4 is more likely
> > > than upgrading the whole system.
> >
> > and putting a feature into 2.4.23 is going to help/change that... how ?
>
> The autofs4 kernel code is already in the mainline kernel and in
> redhat's AS kernels.  However:
>
> 1) In the mainline its not complete (no direct mounts)
> 2) In redhats AS kernels its not supported or complete.  A newer version
>    seems to only make sense.
>
> Putting an upgrade to autofs4 in the mainline kernel once its proven
> would give users the option of having a much more feature-complete and
> un-broken automounter to use.  If its not hurting anything else then
> why leave broken code in the kernel?
>
> Please correct me if I'm making too big a leap, because I have a
> thought.  It seems that new hardware gets this sort of treatment - new
> drivers for a NIC, scsi, or FC card will be included in a stable
> series because with out it some subsystem of a computer "doesn't
> work" completely.  What makes this case different?
>
> -Peter
>
>

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[Matthias Andree]

On Wed, 03 Dec 2003, Ian Kent wrote:

> Sorry, this is probably not the right place for this discussion but I feel
> strongly enough about it to pursue it anyway.
...
> 2) The supportability of using autofs v4 in RedHats' commercial product.
> 
> This issue can't be fixed by simply adding this patch to the kernel.
> 
> There is a userspace daemon which is also not included in the RedHat
> product. RedHat have no reason to trust my code for their commercial
> customers and their commercial customers need the sort of changes I am
> trying to make.
> 
> So the real question is "what can I do to enable this to be used, without
> customer penalty, in RedHats' commercial product".
> 
> I have a kernel module kit that allows the module to be used without
> wiping out the original (and back out the change if needed). I think I can
> turn this into an RPM if that would help.
> 
> I'm about to make 4.1.0 a release. It's not perfect but it is certainly an
> improvement on previous autofs v4 versions. A src RPM will be produced as
> well.
> 
> Anyone have any suggestions on how to solve this problem?

If people are chary about replacing autofs4 in its current shape with
some of the problems it has (like, if the process gets killed with busy
autofs4-mounted file systems), it's difficult to get the system back in
a working shape without rebooting.

Distros seeems to be using autofs3 all over the map, but I've found the
"use program" so very useful because it allows for the /etc/auto.net
stuff which is a great help in administration. To my surprise, I figured
that the FreeBSD amd(8) stuff (that I dropped a while ago because it was
inconvenient to administer and incompatible with Solaris) is capable of
doing these /net mounts as well, so I might just use a Makefile and go
amd again if Linux' autofs4 can't be made to fly.

It's fragile currently, and if there are changes that make the beast
solid, I'm all for it, and the whole discussion can be killed right here
because it's a "bugfix" in that case. After all, autofs4 is a
pre-something stuff and going "gold" is certainly a fix.

If there are optional features, well, they might have to be split out to
a separate patch or #ifdef'd out - but I direly hope that autofs4 will
improve.

Re: Linux 2.4 future

[Ian Kent]

On Wed, 3 Dec 2003, Matthias Andree wrote:

> If people are chary about replacing autofs4 in its current shape with
> some of the problems it has (like, if the process gets killed with busy
> autofs4-mounted file systems), it's difficult to get the system back in
> a working shape without rebooting.

Yes. That is sometimes the case. I have improved things somewhat though.

> 
> Distros seeems to be using autofs3 all over the map, but I've found the
> "use program" so very useful because it allows for the /etc/auto.net
> stuff which is a great help in administration. To my surprise, I figured
> that the FreeBSD amd(8) stuff (that I dropped a while ago because it was
> inconvenient to administer and incompatible with Solaris) is capable of
> doing these /net mounts as well, so I might just use a Makefile and go
> amd again if Linux' autofs4 can't be made to fly.

Yes. autofs v3 is quite a solid product but doesn't understand direct 
mounts. amd is a good product as well. In the end I decided to start work 
on autofs v4 because of the syntax differences to our Sun environment as 
well and the fact that it wasn't being maintained.

> 
> It's fragile currently, and if there are changes that make the beast
> solid, I'm all for it, and the whole discussion can be killed right here
> because it's a "bugfix" in that case. After all, autofs4 is a
> pre-something stuff and going "gold" is certainly a fix.

And that would be 4.1.0-beta3 you are talking about right?
Perhaps you could tell me about your problems and I'll put them on my 
growing todo list for 4.1.1.

> 
> If there are optional features, well, they might have to be split out to
> a separate patch or #ifdef'd out - but I direly hope that autofs4 will
> improve.

The kernel module is only needed to provide support for browsable 
directories (I coined it 'ghost'ing directories in autofs v4). The 
difficulty is many people don't like, and should not have 
to, patch the kernel to get the full functionality of the daemon.

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[Matthias Andree]

On Wed, 03 Dec 2003, Ian Kent wrote:

> > It's fragile currently, and if there are changes that make the beast
> > solid, I'm all for it, and the whole discussion can be killed right here
> > because it's a "bugfix" in that case. After all, autofs4 is a
> > pre-something stuff and going "gold" is certainly a fix.
> 
> And that would be 4.1.0-beta3 you are talking about right?
> Perhaps you could tell me about your problems and I'll put them on my 
> growing todo list for 4.1.1.

I'd need to find and evaluate your 4.1.0-beta works first. Oops, I've
got it, I should look into
http://www.de.kernel.org/pub/linux/daemons/autofs/v4/ :-)

Being used to a different directory layout, I looked into the testing
directories and didn't notice there was an actual 4.0.0 version. Wee.

> > If there are optional features, well, they might have to be split out to
> > a separate patch or #ifdef'd out - but I direly hope that autofs4 will
> > improve.
> 
> The kernel module is only needed to provide support for browsable 
> directories (I coined it 'ghost'ing directories in autofs v4). The 
> difficulty is many people don't like, and should not have 
> to, patch the kernel to get the full functionality of the daemon.

User-space issues should not be discussed on linux-kernel in the first
place. If the user-space daemon just disables those features it doesn't
find kernel support for, no-one has any ground to base a complaint on.

For my purposes, I don't *really* need browsable top-level directories
(for /net or /host style mounts), I'm used to giving the name explicitly
to trigger the mount, and if that works RELIABLY (i. e. picking up old
mounts after coming back after a daemon dcrash), that's most I need on
short notice :-)

I cannot make a qualified statement yet as the most current version I've
in production is 4.0.0pre10, and that's pretty aged. I'll review the
4.0.0 and 4.1.0-beta3 versions later and see if they rid me of some
"stale NFS file handle" that keep haunting my LAN.

Either way, your work is much welcome and appreciated. Before even
looking at the results, thank you for the effort put into this software.

I'll come back to you later with my findings - might be "week-end"
though.

Best regards,
Matthias

Re: Linux 2.4 future

[Ian Kent]

On Wed, 3 Dec 2003, Matthias Andree wrote:

> On Wed, 03 Dec 2003, Ian Kent wrote:
>
> > > It's fragile currently, and if there are changes that make the beast
> > > solid, I'm all for it, and the whole discussion can be killed right here
> > > because it's a "bugfix" in that case. After all, autofs4 is a
> > > pre-something stuff and going "gold" is certainly a fix.
> >
> > And that would be 4.1.0-beta3 you are talking about right?
> > Perhaps you could tell me about your problems and I'll put them on my
> > growing todo list for 4.1.1.
>
> I'd need to find and evaluate your 4.1.0-beta works first. Oops, I've
> got it, I should look into
> http://www.de.kernel.org/pub/linux/daemons/autofs/v4/ :-)
>
> Being used to a different directory layout, I looked into the testing
> directories and didn't notice there was an actual 4.0.0 version. Wee.

The 4.0.0 release has only a few bug fixes and is not greatly different
from 4.0.0pre10.

Please use 4.1.0-beta3 unless it's 4.1.0 by the time you get it.

And we should end this off topic thread now I guess.

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[Bryan Whitehead]

Arjan van de Ven wrote:
> On Tue, Dec 02, 2003 at 12:10:40PM -0800, Peter C. Norton wrote:
> 
>>On Tue, Dec 02, 2003 at 12:54:54AM +0100, Arjan van de Ven wrote:
>>
>>>On Mon, 2003-12-01 at 22:36, Peter C. Norton wrote:
>>>`
>>>
>>>>encouraging the distros to get behind autofs4 (hint hint, redhat,
>>>>hint).
>>>
>>>I suspect you'll have a really hard time finding ANY distro that still
>>>wants to actively develop new products on a 2.4 codebase.
>>
>>Perhaps, but some rather large customers of AS2.1, would like it if
>>redhat could deliver the large outstanding automounting features for
>>their (mainly sun) environments.  Since these environments resist
>>change, upgrading a kernel to include a newer autofs4 is more likely
>>than upgrading the whole system.
> 
> 
> and putting a feature into 2.4.23 is going to help/change that... how ?

 From a sysadmin with rather large Solaris / Linux install base I'd love 
to see a fully working autofs in 2.4. But I would loath running 2.6 on a 
much needed production system... Hacking around the junk version of 
autofs in 2.4 is a pain.

-- 
Bryan Whitehead
SysAdmin - JPL - Interferometry and Large Optical Systems
Phone: 818 354 2903
driver@jpl.nasa.gov

Re: Linux 2.4 future

[Christoph Hellwig]

On Mon, Dec 01, 2003 at 01:36:51PM -0800, Peter C. Norton wrote:
> Ian has lots of bugfixes and and feature patches (like direct mounts)
> going to the autofs mailing list.  Autofs4 has always had stability
> issues in 2.4.x, and its been lacking in features.  This makes myself
> and others run a bastard combination of amd, autofs and editing
> /etc/fstab to get "automounter" features even close to the solaris
> automounter.  If these can go into 2.4, which will be "stable" and in
> use in lots of places for the next couple of years it could help by
> encouraging the distros to get behind autofs4 (hint hint, redhat,
> hint).

Well, it looks like you're a bit later for 2.4 with that.  Get them
into 2.6 and if they prove good we can backport the bugfix portions.
As for Red Hat:  I'll bet the next Red Hat product will be based on
a 2.6 kernel, as is fedora as their public beta testing community
whizbang version.

Re: Linux 2.4 future

[Ian Kent]

On Mon, 1 Dec 2003, Christoph Hellwig wrote:

> On Mon, Dec 01, 2003 at 11:04:21PM +0800, Ian Kent wrote:
> > Would you be willing to consider autofs4 patches that I would like
> > included in 2.4?
>
> What autofs4 patches?  bugfixes, features?  if they aren't in
> 2.6 yet I don't think it makes sense trying to get them into
> 2.4 anymore at all.
>

Yep.

I have just finished porting them to 2.6 and will be attempting to get
the help of autofs list inhabitants for initail testing in the next few
days. I have one volunteer so far.

Anyone else got time, a 2.6 environment and willing to help?

-- 

   ,-._|\    Ian Kent
  /      \   Perth, Western Australia
  *_.--._/   E-mail: raven@themaw.net
        v    Web: http://themaw.net/

Re: Linux 2.4 future

[snpe]

Is there linux-abi for 2.6 kernel ?

Thanks
Haris Peco

On Monday 01 December 2003 03:33 pm, Christoph Hellwig wrote:
> On Mon, Dec 01, 2003 at 11:04:21PM +0800, Ian Kent wrote:
> > Would you be willing to consider autofs4 patches that I would like
> > included in 2.4?
>
> What autofs4 patches?  bugfixes, features?  if they aren't in
> 2.6 yet I don't think it makes sense trying to get them into
> 2.4 anymore at all.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4 future

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Tue, 2003-12-02 02:23:55 +0000, snpe <snpe@snpe.co.yu>
wrote in message <200312020223.55505.snpe@snpe.co.yu>:
> Is there linux-abi for 2.6 kernel ?

Nobody really cares about ABI (at least, not enough to keep one stable)
while there's a good API. That requires sources, though, but that's a
good thing...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.4 future

[Linus Torvalds]

On Tue, 2 Dec 2003, Jan-Benedict Glaw wrote:
>
> On Tue, 2003-12-02 02:23:55 +0000, snpe <snpe@snpe.co.yu>
> wrote in message <200312020223.55505.snpe@snpe.co.yu>:
> > Is there linux-abi for 2.6 kernel ?
>
> Nobody really cares about ABI (at least, not enough to keep one stable)
> while there's a good API. That requires sources, though, but that's a
> good thing...

People care _deeply_ about the user-visible Linux ABI - I personally think
backwards compatibility is absolutely _the_ most important issue for any
kernel, and breaking user-land ABI's is simply not done.

Sometimes we tweak user-visible stuff (for example, removing truly
obsolete system calls), but even then we're very very careful. Like
printing out warning messages for several _years_ before actually removing
the functionality.

The one exception tends to be "system management" ABI's, ie stuff that
normal programs don't use. So kernel updates do sometimes require new
utilities for doing things like firewall configuration, hardware setup
(ethernet tools, ifconfig etc), or - in the case of 2.6 - module loading
and unloading. Even that is frowned upon, and there has to be a good
reason for it.

At times, we've modified semantics of existing system behaviour subtly:
either to conform to standards, or because of implementation issues. It
doesn't happen often, and if it is found to break existing applications it
is not done at all (and the thing is fixed by adding a new system call
with the proper semantics, and leaving the old one broken).

You are, however, correct when it comes to internal kernel interfaces: we
care not at all about ABI's, and even API's are fluid and are freely
changed if there is a real technical reason for it. But that is only true
for the internal kernel stuff (where source is obviously a requirement
anyway).

		Linus

Re: Linux 2.4 future

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On Tue, 2003-12-02 10:04:24 -0800, Linus Torvalds <torvalds@osdl.org>
wrote in message <Pine.LNX.4.58.0312020956120.1519@home.osdl.org>:
> On Tue, 2 Dec 2003, Jan-Benedict Glaw wrote:
> >
> > On Tue, 2003-12-02 02:23:55 +0000, snpe <snpe@snpe.co.yu>
> > wrote in message <200312020223.55505.snpe@snpe.co.yu>:
> > > Is there linux-abi for 2.6 kernel ?
> >
> > Nobody really cares about ABI (at least, not enough to keep one stable)
> > while there's a good API. That requires sources, though, but that's a
> > good thing...

> You are, however, correct when it comes to internal kernel interfaces: we
> care not at all about ABI's, and even API's are fluid and are freely
> changed if there is a real technical reason for it. But that is only true
> for the internal kernel stuff (where source is obviously a requirement
> anyway).

Whenever The ABI Question (TM) comes up, it seems to be about claiming a
(binary compatible) interface - mostly for modules. But I think it's
widely accepted that there isn't much work done to have these truly (sp?)
binary compatible (eg. UP/SMP spinlocks et al.).

Of course, we want to have a somewhat stable interface for libc (->
userspace), but some struct (fb_info, ...) doesn't need to be binary
compatible - as long as a driver (given to be in source) still works
cleanly with it:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.4 future

[Linus Torvalds]

On Tue, 2 Dec 2003, Jan-Benedict Glaw wrote:
>
> Whenever The ABI Question (TM) comes up, it seems to be about claiming a
> (binary compatible) interface - mostly for modules. But I think it's
> widely accepted that there isn't much work done to have these truly (sp?)
> binary compatible (eg. UP/SMP spinlocks et al.).

Absolutely. It's not going to happen. I am _totally_ uninterested in a
stable ABI for kernel modules, and in fact I'm actively against even
_trying_. I want people to be very much aware of the fact that kernel
internals do change, and that this will continue.

There are no good excuses for binary modules. Some of them may be
technically legal (by virtue of not being derived works) and allowed, but
even when they are legal they are a major pain in the ass, and always
horribly buggy.

I occasionally get a few complaints from vendors over my non-interest in
even _trying_ to help binary modules. Tough. It's a two-way street: if you
don't help me, I don't help you. Binary-only modules do not help Linux,
quite the reverse. As such, we should have no incentives to help make them
any more common than they already are. Adn we do have a lot of
dis-incentives.

			Linus

Re: Linux 2.4 future

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Tue, 2003-12-02 11:09:28 -0800, Linus Torvalds <torvalds@osdl.org>
wrote in message <Pine.LNX.4.58.0312021101440.1519@home.osdl.org>:

> stable ABI for kernel modules, and in fact I'm actively against even
> _trying_. I want people to be very much aware of the fact that kernel
> internals do change, and that this will continue.

<AOL> me too! </AOL> I totally agree.

> There are no good excuses for binary modules. Some of them may be
> technically legal (by virtue of not being derived works) and allowed, but
> even when they are legal they are a major pain in the ass, and always
> horribly buggy.

Thanks a lot for this clarification. Webmaster, please note it down on
www.kernel.org's front index.html!

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.4 future

[Gene Heskett]

On Tuesday 02 December 2003 14:09, Linus Torvalds wrote:
>On Tue, 2 Dec 2003, Jan-Benedict Glaw wrote:
>> Whenever The ABI Question (TM) comes up, it seems to be about
>> claiming a (binary compatible) interface - mostly for modules. But
>> I think it's widely accepted that there isn't much work done to
>> have these truly (sp?) binary compatible (eg. UP/SMP spinlocks et
>> al.).
>
>Absolutely. It's not going to happen. I am _totally_ uninterested in
> a stable ABI for kernel modules, and in fact I'm actively against
> even _trying_. I want people to be very much aware of the fact that
> kernel internals do change, and that this will continue.
>
>There are no good excuses for binary modules. Some of them may be
>technically legal (by virtue of not being derived works) and
> allowed, but even when they are legal they are a major pain in the
> ass, and always horribly buggy.
>
>I occasionally get a few complaints from vendors over my
> non-interest in even _trying_ to help binary modules. Tough. It's a
> two-way street: if you don't help me, I don't help you. Binary-only
> modules do not help Linux, quite the reverse. As such, we should
> have no incentives to help make them any more common than they
> already are. Adn we do have a lot of dis-incentives.
>
>			Linus

Very well said Linus.  And of course I have no problem understanding 
the reasons behind the reasoning.  However, that doesn't help us pour 
schmucks out here in la-la land trying to make the most recent nvidia 
module work with the latest kernel on our now elderly gforce2's.  I'd 
like to have some OpenGL support for instance, but for everything 
else, nv is probably 100x more stable than the nvidia binary.  So we 
run nv.  Maybe someday nvidia will get baptised, but *I'm* not 
counting on it.

Its not your emails (as Linus) to nvidia that will fix that, but a 
concerted effort, emailing them for a resolution from everyone who 
owns one of their products _might_ eventually make a difference.
OTOH, they're going to listen to their IP lawyers & not us. so...

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.4 future

[Jeff Garzik]

On Tue, Dec 02, 2003 at 02:39:52PM -0500, Gene Heskett wrote:
> the reasons behind the reasoning.  However, that doesn't help us pour 
> schmucks out here in la-la land trying to make the most recent nvidia 
> module work with the latest kernel on our now elderly gforce2's.  I'd 
> like to have some OpenGL support for instance, but for everything 
> else, nv is probably 100x more stable than the nvidia binary.  So we 
> run nv.  Maybe someday nvidia will get baptised, but *I'm* not 
> counting on it.
> 
> Its not your emails (as Linus) to nvidia that will fix that, but a 
> concerted effort, emailing them for a resolution from everyone who 
> owns one of their products _might_ eventually make a difference.
> OTOH, they're going to listen to their IP lawyers & not us. so...

Well, the easiest way to convince nVidia is to own someone else's
product, that does support Linux ;-)

Right now -- for the bleeding edge 3D hardware -- hardware makers
are across-the-board closed source AFAIK.  ATI used to be open source,
but their new "microcode JIT" stuff for the latest h/w isn't

Until a volume 3D h/w maker goes open source and gives Linux users a
market to buy into, it's pretty much closed source moving forward :(

	Jeff

Re: Linux 2.4 future

[Stephan von Krawczynski]

On Tue, 2 Dec 2003 14:39:52 -0500
Gene Heskett <gene.heskett@verizon.net> wrote:

> [...]
> Its not your emails (as Linus) to nvidia that will fix that, but a 
> concerted effort, emailing them for a resolution from everyone who 
> owns one of their products _might_ eventually make a difference.

Make the difference yourself: don't buy such products. I stopped some time ago
and I am very happy with _my choice_, not relying on theirs'.

Regards,
Stephan

Re: Linux 2.4 future

[Gene Heskett]

On Tuesday 02 December 2003 15:32, Stephan von Krawczynski wrote:
>On Tue, 2 Dec 2003 14:39:52 -0500
>
>Gene Heskett <gene.heskett@verizon.net> wrote:
>> [...]
>> Its not your emails (as Linus) to nvidia that will fix that, but a
>> concerted effort, emailing them for a resolution from everyone who
>> owns one of their products _might_ eventually make a difference.
>
>Make the difference yourself: don't buy such products. I stopped
> some time ago and I am very happy with _my choice_, not relying on
> theirs'.

So what are you using?  And how does it work, at least for a 
non-gamer?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.4 future

[Linus Torvalds]

On Tue, 2 Dec 2003, Gene Heskett wrote:
>
> So what are you using?  And how does it work, at least for a
> non-gamer?

If you're a nongamer, almost anything will work. Intel's integrated
graphics is pretty well supported even with 3D (and better than most in
2D), and Intel documents their hardware. It helps if you have one of the
newer dual-DDR-400 setups, since the Intel stuff is UMA and will eat
main-memory bandwidth.

The ATI R200-based cards tend to work well with DRI too, and are typically
higher performance than the integrated chipsets (ie you can actually play
most games comfortably).

			Linus

Re: Linux 2.4 future

[Harald Arnesen]

Linus Torvalds <torvalds@osdl.org> writes:

> On Tue, 2 Dec 2003, Gene Heskett wrote:
>>
>> So what are you using?  And how does it work, at least for a
>> non-gamer?
>
> If you're a nongamer, almost anything will work. Intel's integrated
> graphics is pretty well supported even with 3D (and better than most in
> 2D), and Intel documents their hardware. It helps if you have one of the
> newer dual-DDR-400 setups, since the Intel stuff is UMA and will eat
> main-memory bandwidth.
>
> The ATI R200-based cards tend to work well with DRI too, and are typically
> higher performance than the integrated chipsets (ie you can actually play
> most games comfortably).

I second that. I have an ATI Radeon 9200, and I can play Tuxracer,
America's Army (BOO!), and any other 3D-game without any problem.
-- 
Hilsen Harald.

Re: Linux 2.4 future

[Helge Hafting]

Gene Heskett wrote:
> On Tuesday 02 December 2003 15:32, Stephan von Krawczynski wrote:
> 
>>On Tue, 2 Dec 2003 14:39:52 -0500
>>
>>Gene Heskett <gene.heskett@verizon.net> wrote:
>>
>>>[...]
>>>Its not your emails (as Linus) to nvidia that will fix that, but a
>>>concerted effort, emailing them for a resolution from everyone who
>>>owns one of their products _might_ eventually make a difference.
>>
>>Make the difference yourself: don't buy such products. I stopped
>>some time ago and I am very happy with _my choice_, not relying on
>>theirs'.
> 
> 
> So what are you using?  And how does it work, at least for a 
> non-gamer?
> 
I have a matrox G550.  Not known for the best 3D performance,
but it is good enough for tuxracer which is my heaviest 3D app.
It is supposed to be good at 2D.

It should be fine for a non-gamer, one of the things matrox does well
is a nice sharp flicker-free picture.  (A feature that don't require
any os support either!)  The picture is certainly better than the
radeon I use at work, that one has some flickering in high-frequency
images such as the default X background.

Helge Hafting

Re: Linux 2.4 future

[snpe]

Does anyone work on transfer linux-abi to kernel 2.6 ?
regards
On Tuesday 02 December 2003 06:04 pm, Linus Torvalds wrote:
> On Tue, 2 Dec 2003, Jan-Benedict Glaw wrote:
> > On Tue, 2003-12-02 02:23:55 +0000, snpe <snpe@snpe.co.yu>
> >
> > wrote in message <200312020223.55505.snpe@snpe.co.yu>:
> > > Is there linux-abi for 2.6 kernel ?
> >
> > Nobody really cares about ABI (at least, not enough to keep one stable)
> > while there's a good API. That requires sources, though, but that's a
> > good thing...
>
> People care _deeply_ about the user-visible Linux ABI - I personally think
> backwards compatibility is absolutely _the_ most important issue for any
> kernel, and breaking user-land ABI's is simply not done.
>
> Sometimes we tweak user-visible stuff (for example, removing truly
> obsolete system calls), but even then we're very very careful. Like
> printing out warning messages for several _years_ before actually removing
> the functionality.
>
> The one exception tends to be "system management" ABI's, ie stuff that
> normal programs don't use. So kernel updates do sometimes require new
> utilities for doing things like firewall configuration, hardware setup
> (ethernet tools, ifconfig etc), or - in the case of 2.6 - module loading
> and unloading. Even that is frowned upon, and there has to be a good
> reason for it.
>
> At times, we've modified semantics of existing system behaviour subtly:
> either to conform to standards, or because of implementation issues. It
> doesn't happen often, and if it is found to break existing applications it
> is not done at all (and the thing is fixed by adding a new system call
> with the proper semantics, and leaving the old one broken).
>
> You are, however, correct when it comes to internal kernel interfaces: we
> care not at all about ABI's, and even API's are fluid and are freely
> changed if there is a real technical reason for it. But that is only true
> for the internal kernel stuff (where source is obviously a requirement
> anyway).
>
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4 future

[Mike Fedyk]

On Tue, Dec 02, 2003 at 07:59:53PM +0000, snpe wrote:
> Does anyone work on transfer linux-abi to kernel 2.6 ?

What is that supposed to be asking?

Re: Linux 2.4 future

[Arnaldo Carvalho de Melo]

Em Tue, Dec 02, 2003 at 02:30:13PM -0800, Mike Fedyk escreveu:
> On Tue, Dec 02, 2003 at 07:59:53PM +0000, snpe wrote:
> > Does anyone work on transfer linux-abi to kernel 2.6 ?
> 
> What is that supposed to be asking?

I think he is asking for that thing that previously was called iBCS2...

- Arnaldo

Re: Linux 2.4 future

[snpe]

On Tuesday 02 December 2003 10:43 pm, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 02, 2003 at 02:30:13PM -0800, Mike Fedyk escreveu:
> > On Tue, Dec 02, 2003 at 07:59:53PM +0000, snpe wrote:
> > > Does anyone work on transfer linux-abi to kernel 2.6 ?
> >
> > What is that supposed to be asking?
>
> I think he is asking for that thing that previously was called iBCS2...
>
Yes, iBCS2 for  linux kernel 2.[02] and linux-abi for 2.4.What about 2.6 ?

Thanks

Re: Linux 2.4 future

[Christoph Hellwig]

On Wed, Dec 03, 2003 at 02:08:42PM +0000, snpe wrote:
> On Tuesday 02 December 2003 10:43 pm, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 02, 2003 at 02:30:13PM -0800, Mike Fedyk escreveu:
> > > On Tue, Dec 02, 2003 at 07:59:53PM +0000, snpe wrote:
> > > > Does anyone work on transfer linux-abi to kernel 2.6 ?
> > >
> > > What is that supposed to be asking?
> >
> > I think he is asking for that thing that previously was called iBCS2...
> >
> Yes, iBCS2 for  linux kernel 2.[02] and linux-abi for 2.4.What about 2.6 ?

AFAIK nothing.

Re: Linux 2.4 future

[Christoph Hellwig]

On Tue, Dec 02, 2003 at 02:23:55AM +0000, snpe wrote:
> Is there linux-abi for 2.6 kernel ?

AFAIK not.

Re: Linux 2.4 future

[Norberto Bensa]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 192 bytes --]

Marcelo Tosatti wrote:
> during 2.4.24. New drivers will be accept during this period (for example,

If you're going to accept new drivers, accept XFS too (pleeeaaseee :)

Regards,
Norberto



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.4 future

[Matthias Andree]

On Mon, 01 Dec 2003, Norberto Bensa wrote:

Content-Description: signed data
> Marcelo Tosatti wrote:
> > during 2.4.24. New drivers will be accept during this period (for example,
> 
> If you're going to accept new drivers, accept XFS too (pleeeaaseee :)

And device-mapper, so the same user space will work with 2.4.24 and
2.6.X.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: Linux 2.4 future

[Ionut Georgescu]

I can only second that. We've been using XFS here since the days of
2.4.0-testxx and the only problems we've had were sitting between the
chair and the keyboard.

Ionut


On Mon, Dec 01, 2003 at 12:26:01PM -0300, Norberto Bensa wrote:
Content-Description: signed data
> Marcelo Tosatti wrote:
> > during 2.4.24. New drivers will be accept during this period (for example,
> 
> If you're going to accept new drivers, accept XFS too (pleeeaaseee :)
> 
> Regards,
> Norberto
> 
> 



-- 
***************
* Ionut Georgescu
* http://www.physik.tu-cottbus.de/~george/
* Registered Linux User #244479
*
* "In Windows you can do everything Microsoft wants you to do; in Unix you
*                can do anything the computer is able to do."

Re: Linux 2.4 future

[Arnaldo Carvalho de Melo]

Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> I can only second that. We've been using XFS here since the days of
> 2.4.0-testxx and the only problems we've had were sitting between the
> chair and the keyboard.

So if there is no problems at all using it as a patch why add this to a
kernel that is phasing out?

- Arnaldo

Re: Linux 2.4 future

[Ionut Georgescu]

Because new hardware requires newest kernel, and neither I, nor the
majority of the users out there have the knowledge to 'forward' apply
patches.

Even if 2.4 is phasing out, the process has just begun and it will last
a lot until 2.6 will be ready for production systems.

We are not talking about a fancy, experimental feature. We are talking
about a mature, serious project, that has been traveling for 3 years
along the 2.4 kernel and with even more years of testing and research
behind. I find it just pitty for the linux kernel not to include it.

When going to a conference, you don't present the brand new stuff you
have just computed or measured the night before, because you just can't
know if it is correct or not. Instead, you will present older, but
mature work, that you can swear on. The same with the 2.6 kernel.
Everybody is pushing it in front, but no one is using it for production
systems. XFS and 2.4 are, even together, old, mature work, that anybody
would 'present' anywhere.

Regards,
Ionut


On Tue, Dec 02, 2003 at 10:03:15AM -0200, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> > I can only second that. We've been using XFS here since the days of
> > 2.4.0-testxx and the only problems we've had were sitting between the
> > chair and the keyboard.
> 
> So if there is no problems at all using it as a patch why add this to a
> kernel that is phasing out?
> 
> - Arnaldo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
***************
* Ionut Georgescu
* http://www.physik.tu-cottbus.de/~george/
* Registered Linux User #244479
*
* "In Windows you can do everything Microsoft wants you to do; in Unix you
*                can do anything the computer is able to do."

Re: Linux 2.4 future

[Ed Sweetman]

Ionut Georgescu wrote:
> Because new hardware requires newest kernel, and neither I, nor the
> majority of the users out there have the knowledge to 'forward' apply
> patches.
> 
> Even if 2.4 is phasing out, the process has just begun and it will last
> a lot until 2.6 will be ready for production systems.
> 
> We are not talking about a fancy, experimental feature. We are talking
> about a mature, serious project, that has been traveling for 3 years
> along the 2.4 kernel and with even more years of testing and research
> behind. I find it just pitty for the linux kernel not to include it.
> 
> When going to a conference, you don't present the brand new stuff you
> have just computed or measured the night before, because you just can't
> know if it is correct or not. Instead, you will present older, but
> mature work, that you can swear on. The same with the 2.6 kernel.
> Everybody is pushing it in front, but no one is using it for production
> systems. XFS and 2.4 are, even together, old, mature work, that anybody
> would 'present' anywhere.
> 
> Regards,
> Ionut


The point was, the patch is perfectly and easily usable the way it is. 
There stands to be no reason to make it part of the vanilla kernel other 
than a very slight convenience factor for a small minority of users. 
Tosatti thinks that that versus changes to this stable kernel that touch 
common code are unacceptable.  Despite the maturity of the project, it 
just doesn't make sense to include it in the vanilla kernel, it would be 
a disservice to the rest of the users of 2.4.x kernels that do so for 
stability, not only in the not crashing sense, but also in the code-base 
  sense. And the number of users who don't use xfs so greatly outnumber 
the users that do that it's a mute point for Tosatti.
Just suck it up, plug on with the complex command of cat xfs.patch | 
patch -p1 or move up to 2.6.  Anyone using xfs can obviously do either 
already and everyone not can continue not being affected by new code if 
they dont want to.

Re: Linux 2.4 future

[Arnaldo Carvalho de Melo]

Em Tue, Dec 02, 2003 at 08:38:03AM -0500, Ed Sweetman escreveu:
> Ionut Georgescu wrote:
> >Because new hardware requires newest kernel, and neither I, nor the
> >majority of the users out there have the knowledge to 'forward' apply
> >patches.
> >
> >Even if 2.4 is phasing out, the process has just begun and it will last
> >a lot until 2.6 will be ready for production systems.
> >
> >We are not talking about a fancy, experimental feature. We are talking
> >about a mature, serious project, that has been traveling for 3 years
> >along the 2.4 kernel and with even more years of testing and research
> >behind. I find it just pitty for the linux kernel not to include it.
> >
> >When going to a conference, you don't present the brand new stuff you
> >have just computed or measured the night before, because you just can't
> >know if it is correct or not. Instead, you will present older, but
> >mature work, that you can swear on. The same with the 2.6 kernel.
> >Everybody is pushing it in front, but no one is using it for production
> >systems. XFS and 2.4 are, even together, old, mature work, that anybody
> >would 'present' anywhere.
> >
> >Regards,
> >Ionut
> 
> 
> The point was, the patch is perfectly and easily usable the way it is. 
> There stands to be no reason to make it part of the vanilla kernel other 
> than a very slight convenience factor for a small minority of users. 
> Tosatti thinks that that versus changes to this stable kernel that touch 
> common code are unacceptable.  Despite the maturity of the project, it 
> just doesn't make sense to include it in the vanilla kernel, it would be 
> a disservice to the rest of the users of 2.4.x kernels that do so for 
> stability, not only in the not crashing sense, but also in the code-base 
>  sense. And the number of users who don't use xfs so greatly outnumber 
> the users that do that it's a mute point for Tosatti.

<humour>
Thanks for reading my mind and writing it down 8)
</humour>

- Arnaldo

Re: Linux 2.4 future

[Ionut Georgescu]

On Tue, Dec 02, 2003 at 08:38:03AM -0500, Ed Sweetman wrote:
> 
> The point was, the patch is perfectly and easily usable the way it is. 
> There stands to be no reason to make it part of the vanilla kernel other 
> than a very slight convenience factor for a small minority of users. 
> Tosatti thinks that that versus changes to this stable kernel that touch 
> common code are unacceptable.  Despite the maturity of the project, it 
> just doesn't make sense to include it in the vanilla kernel, it would be 
> a disservice to the rest of the users of 2.4.x kernels that do so for 
> stability, not only in the not crashing sense, but also in the code-base 
>  sense. And the number of users who don't use xfs so greatly outnumber 
> the users that do that it's a mute point for Tosatti.
> Just suck it up, plug on with the complex command of cat xfs.patch | 
> patch -p1 or move up to 2.6.  Anyone using xfs can obviously do either 
> already and everyone not can continue not being affected by new code if 
> they dont want to.
> 

I can understand that, but I don't take 2.6 for an answer.  2.4 is not
yet dead and it won't be for a long time, just as 2.2 has gotten to
2.2.25, although 2.4.0 was out when, 3 years ago ?

Ionut


-- 
***************
* Ionut Georgescu
* http://www.physik.tu-cottbus.de/~george/
* Registered Linux User #244479
*
* "In Windows you can do everything Microsoft wants you to do; in Unix you
*                can do anything the computer is able to do."

Re: Linux 2.4 future

[Jeff Garzik]

On Tue, Dec 02, 2003 at 05:01:36PM +0100, Ionut Georgescu wrote:
> I can understand that, but I don't take 2.6 for an answer.  2.4 is not
> yet dead and it won't be for a long time, just as 2.2 has gotten to
> 2.2.25, although 2.4.0 was out when, 3 years ago ?

2.4 has continued life, yes.

But the real question is, should 2.4 continue to be developed?

I agree with Marcelo, increasingly the answer should be "No".  New
features and core changes should be intended for 2.6.  Bug fixes,
security errata, and the like will always be OK for 2.4.  Just like Alan
continues to release new 2.2.x releases, when major bugs are found.

There needs to be a progressive tightening of patch acceptance standards
in 2.4, IMO...  and Marcelo announced he will be doing just that.

	Jeff

Re: Linux 2.4 future

[John Bradford]

Quote from Jeff Garzik <jgarzik@pobox.com>:
> On Tue, Dec 02, 2003 at 05:01:36PM +0100, Ionut Georgescu wrote:
> > I can understand that, but I don't take 2.6 for an answer.  2.4 is not
> > yet dead and it won't be for a long time, just as 2.2 has gotten to
> > 2.2.25, although 2.4.0 was out when, 3 years ago ?
> 
> 2.4 has continued life, yes.
> 
> But the real question is, should 2.4 continue to be developed?
> 
> I agree with Marcelo, increasingly the answer should be "No".  New
> features and core changes should be intended for 2.6.  Bug fixes,
> security errata, and the like will always be OK for 2.4.  Just like Alan
> continues to release new 2.2.x releases, when major bugs are found.

Even doing that becomes increasingly difficult when you have fewer and
fewer systems actually running the code.

Backporting a security fix to 2.0.x, and touching some core code,
could easily result in something breaking and it going unnoticed for
months, especially if it is something that's hard to trigger.

John.

Re: Linux 2.4 future

[Ville Herva]

On Tue, Dec 02, 2003 at 11:08:53AM -0500, you [Jeff Garzik] wrote:
> Bug fixes, security errata, and the like will always be OK for 2.4.  Just
> like Alan continues to release new 2.2.x releases, when major bugs are
> found.

Which btw invites the question: the recent brk() security fix was ported
from 2.5 to 2.4, right? Any idea whether it applies to 2.2 (and 2.0), too?


-- v --

v@iki.fi

Re: Linux 2.4 future

[Chris Wright]

* Ville Herva (vherva@niksula.hut.fi) wrote:
> On Tue, Dec 02, 2003 at 11:08:53AM -0500, you [Jeff Garzik] wrote:
> > Bug fixes, security errata, and the like will always be OK for 2.4.  Just
> > like Alan continues to release new 2.2.x releases, when major bugs are
> > found.
> 
> Which btw invites the question: the recent brk() security fix was ported
> from 2.5 to 2.4, right? Any idea whether it applies to 2.2 (and 2.0), too?

2.2 and 2.0 look ok as they use do_mmap() which has proper checks.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Linux 2.4 future

[Stephan von Krawczynski]

On Tue, 2 Dec 2003 10:03:15 -0200
Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:

> Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> > I can only second that. We've been using XFS here since the days of
> > 2.4.0-testxx and the only problems we've had were sitting between the
> > chair and the keyboard.
> 
> So if there is no problems at all using it as a patch why add this to a
> kernel that is phasing out?

Because it is _not_.

I really wonder how many of you have read this list up to 2.4.11 release ...

Is there some human-memory-loss-virus flooding the area ?

Please stay serious.
Stephan

Re: Linux 2.4 future

[Arnaldo Carvalho de Melo]

Em Tue, Dec 02, 2003 at 09:09:04PM +0100, Stephan von Krawczynski escreveu:
> On Tue, 2 Dec 2003 10:03:15 -0200
> Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:
> 
> > Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> > > I can only second that. We've been using XFS here since the days of
> > > 2.4.0-testxx and the only problems we've had were sitting between the
> > > chair and the keyboard.
> > 
> > So if there is no problems at all using it as a patch why add this to a
> > kernel that is phasing out?
> 
> Because it is _not_.

So what? You disagree, what is the problem of keeping a patch out of the tree
if the tree is getting in deep freeze?
 
> I really wonder how many of you have read this list up to 2.4.11 release ...
> 
> Is there some human-memory-loss-virus flooding the area ?
> 
> Please stay serious.

I'm staying, please stay too.

And I was on this list _way_ before 2.4.11, 2.6 has, IMHO, a different story.

- Arnaldo

Re: Linux 2.4 future

[Stephan von Krawczynski]

On Tue, 2 Dec 2003 18:24:35 -0200
Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:

> And I was on this list _way_ before 2.4.11, 2.6 has, IMHO, a different story.

A story can only be judged _after_ it is history.

Regards,
Stephan

Re: Linux 2.4 future

[Arnaldo Carvalho de Melo]

Em Tue, Dec 02, 2003 at 09:45:04PM +0100, Stephan von Krawczynski escreveu:
> On Tue, 2 Dec 2003 18:24:35 -0200
> Arnaldo Carvalho de Melo <acme@conectiva.com.br> wrote:
> 
> > And I was on this list _way_ before 2.4.11, 2.6 has, IMHO, a different story.
> 
> A story can only be judged _after_ it is history.

What happened up to this point in kernel development hasn't happened? I'm
comparing what happened up to now with what happened at the same point in
the 2.4.0-pre days, talking about the past, so, after it is history, I agree
with you, at least on this :-)

- Arnaldo

Re: Linux 2.4 future

[Tomas Konir]

On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:

> Em Tue, Dec 02, 2003 at 02:38:54PM -0500, Tomas Konir escreveu:
> > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
> > 
> > > Em Tue, Dec 02, 2003 at 02:06:34PM -0500, Tomas Konir escreveu:
> > > > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
> > > > 
> > > > > Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> > > > > > I can only second that. We've been using XFS here since the days of
> > > > > > 2.4.0-testxx and the only problems we've had were sitting between the
> > > > > > chair and the keyboard.
> > > > > 
> > > > > So if there is no problems at all using it as a patch why add this to a
> > > > > kernel that is phasing out?
> > > > 
> > > > Because me and others are wasting our time when merging xfs with other 
> > > > patches such as grsecurity. XFS in kernel can save our time. The question 
> > > > is, that if JFS and other FS's are in kernel, why not XFS ?
> > > 
> > > Why not ReiserFS4? Or DRBD? Or... :-)
> > 
> > ReiserFS4 is stable ? very new information for me.
> 
> Well, some people may well consider :-) But yes, this was my fault, I should
> have just mentioned DRBD and other patches in similar situation, just look
> at any recent 2.4 rpm from any distro.

Distro kernels contains many features, but a lot of bloat :-(
no one pure distro kernel can be used as server kernel.
(only my opinion)

> 
> > > Like I was discussing with Marcelo: if he stated that 2.4 will get in deep
> > > freeze, it means that the external patches for this kernel will not have to
> > > be maintained, or the maintainance will be very very small, and related to
> > > things that are _outside_ the kernel.
> > 
> > 2.2 external patches are not related to other's now.
> 
> 2.2?
> 
> > Why 2.4 patches will be ?
> 
> Havent you mentioned grsecurity?

grsecurity is good example. I have to merge cca 10 rejects, when adding to 
linux-xfs kernel.

> 
> > This discussion is not about unstable testing feature, but about rock 
> > stable filesystem, used by many. Including in kernel can help without 
> 
> It is about adding a new feature, whatever is the opinion of people about
> its stability or not, in a kernel that is being phased out.

agree
but this feature is wanted by many and still rejected without serious 
reasons.

> > stability compromise. I think, that there is no reliable argument to 
> > not include XFS into main kernel.
> 
> But it is included, in 2.6, where it seems to be showing problems, as
> mentioned by Linus some days ago, I for one was using it and stopped, switched
> to ext3 and have had no problems since.

2.6 is still unstable now. I'm using -test10 on my workstation, but it 
takes minimally an half year to use it on server. I can't use ext3 on 
server, because of missing features such as ACL, dump (with acl's), 
built in qouta and for last much different speed on SMP machine.

> 
> But hey, take this discussion to lkml, there more people will be able to
> discuss with us :-)

roger
cc: to linux-kernel

	MOJE

-- 
Konir Tomas
Czech Republic
Brno
ICQ 25849167

Re: Linux 2.4 future

[Mike Fedyk]

On Tue, Dec 02, 2003 at 03:21:54PM -0500, Tomas Konir wrote:
> 2.6 is still unstable now. I'm using -test10 on my workstation, but it 
> takes minimally an half year to use it on server. I can't use ext3 on 
> server, because of missing features such as ACL, dump (with acl's), 
> built in qouta and for last much different speed on SMP machine.

You have all of that for ext3 in 2.6.  The locking has been improved, there
is acl support, and quota has been there for a long time (even in 2.4).  I'm
not sure about the dump, but if dump gets all allocated blocks, then you
should have ACLs dumped too.

Re: Linux 2.4 future

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Tue, 02 Dec 2003 10:53:33 PST, Mike Fedyk said:

> You have all of that for ext3 in 2.6.  The locking has been improved, there
> is acl support, and quota has been there for a long time (even in 2.4).  I'm
> not sure about the dump, but if dump gets all allocated blocks, then you
> should have ACLs dumped too.

At least the 'dump' that comes with Fedora Core 1:

dump 0.4b34 (using libext2fs 1.34 of 25-Jul-2003)

complains:  "ACLs in inode #%ld won't be dumped" (for some value of %ld)
when dumping files that have been tagged by SELinux.

http://dump.sourceforge.net/ disavows the existence of newer than 0.4b34.

It hasn't been a big issue for me, as I can re-run /usr/sbin/setfiles if I
restore. But (a) it's very noisy and liable to hide real errors and (b) any
other not-easily-recreated use of ACLs is a problem...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.4 future

[Jose Luis Domingo Lopez]

On Tuesday, 02 December 2003, at 15:21:54 -0500,
Tomas Konir wrote:

> 2.6 is still unstable now. I'm using -test10 on my workstation, but it 
> takes minimally an half year to use it on server. I can't use ext3 on 
> server, because of missing features such as ACL, dump (with acl's), 
> built in qouta and for last much different speed on SMP machine.
> 
If you can live with filesystem-level backups tar-like, maybe you should
have a look at "star", a tar implementation that is said to be capable
of archiving (and hopefully restoring :-) ACL.

Greetings.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Sid (Linux 2.6.0-test10-mm1)

Re: Linux 2.4 future

[bill davidsen]

In article <Pine.LNX.4.58.0312021508470.21855@moje.vabo.cz>,
Tomas Konir  <moje@vabo.cz> wrote:
| On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
| 
| > Em Tue, Dec 02, 2003 at 02:38:54PM -0500, Tomas Konir escreveu:
| > > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
| > > 
| > > > Em Tue, Dec 02, 2003 at 02:06:34PM -0500, Tomas Konir escreveu:
| > > > > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
| > > > > 
| > > > > > Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
| > > > > > > I can only second that. We've been using XFS here since the days of
| > > > > > > 2.4.0-testxx and the only problems we've had were sitting between the
| > > > > > > chair and the keyboard.
| > > > > > 
| > > > > > So if there is no problems at all using it as a patch why add this to a
| > > > > > kernel that is phasing out?
| > > > > 
| > > > > Because me and others are wasting our time when merging xfs with other 
| > > > > patches such as grsecurity. XFS in kernel can save our time. The question 
| > > > > is, that if JFS and other FS's are in kernel, why not XFS ?
| > > > 
| > > > Why not ReiserFS4? Or DRBD? Or... :-)
| > > 
| > > ReiserFS4 is stable ? very new information for me.

Therein is a fair question. There are a lot more people using XFS than
JFS, or at least if people are using JFS they are not talking about it
much. And XFS has been around and stable for a long time, probably
longer than stable JFS (and some would argue Reiser ;-). I don't think
new FS should be added indefinitely, but since XFS has seniority, a
larger user base than some FS in the kernel, neither of which will ever
be argued again for another FS, it seems possible to add XFS without
setting foot on some hypothetical slippery slope.

As a stability issue, since people are using XFS, it would probably be
better to have it in than as a patch added and possibly modified by each
vendor.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Linux 2.4 future

[jw schultz]

On Wed, Dec 03, 2003 at 06:22:12PM +0000, bill davidsen wrote:
> In article <Pine.LNX.4.58.0312021508470.21855@moje.vabo.cz>,
> Tomas Konir  <moje@vabo.cz> wrote:
> | On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
> | 
> | > Em Tue, Dec 02, 2003 at 02:38:54PM -0500, Tomas Konir escreveu:
> | > > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
> | > > 
> | > > > Em Tue, Dec 02, 2003 at 02:06:34PM -0500, Tomas Konir escreveu:
> | > > > > On Tue, 2 Dec 2003, Arnaldo Carvalho de Melo wrote:
> | > > > > 
> | > > > > > Em Tue, Dec 02, 2003 at 12:54:36PM +0100, Ionut Georgescu escreveu:
> | > > > > > > I can only second that. We've been using XFS here since the days of
> | > > > > > > 2.4.0-testxx and the only problems we've had were sitting between the
> | > > > > > > chair and the keyboard.
> | > > > > > 
> | > > > > > So if there is no problems at all using it as a patch why add this to a
> | > > > > > kernel that is phasing out?
> | > > > > 
> | > > > > Because me and others are wasting our time when merging xfs with other 
> | > > > > patches such as grsecurity. XFS in kernel can save our time. The question 
> | > > > > is, that if JFS and other FS's are in kernel, why not XFS ?
> | > > > 
> | > > > Why not ReiserFS4? Or DRBD? Or... :-)
> | > > 
> | > > ReiserFS4 is stable ? very new information for me.
> 
> Therein is a fair question. There are a lot more people using XFS than
> JFS, or at least if people are using JFS they are not talking about it

Perhaps because we aren't having many problems with it.

> much. And XFS has been around and stable for a long time, probably
> longer than stable JFS (and some would argue Reiser ;-). I don't think
> new FS should be added indefinitely, but since XFS has seniority, a
> larger user base than some FS in the kernel, neither of which will ever
> be argued again for another FS, it seems possible to add XFS without
> setting foot on some hypothetical slippery slope.

Probably more to the point is that not only is XFS used by
many but has been part of distro kernels for some time.

> As a stability issue, since people are using XFS, it would probably be
> better to have it in than as a patch added and possibly modified by each
> vendor.

The fewer patches, particularly feature patches the distros
have to add the less painful it would be to try a different
kernel or change distros.

That said, if XFS is wanted in Linux it should become a
Linux native and not be dependant on IRIX APIs just so SGI
engineers can use an unmodified common codebase.  I agree
wholeheartedly with Marcello on that point.

<OT>
As a datapoint i'm running ext2, reiserfs, JFS and XFS each
for different reasons.

	ext2 -- boot (i'm stodgy) and 2kb blocks for archive CDs

	reiserfs3 -- filesystems not exported nfs (no
	historical version level that i can confirm whether
	i have or not will namesys assert is reliable over
	nfs)

	jfs -- most nfs exported filesystems, decent
	performance and solid but i don't use if for home
	because in SuSE's 2.4.18 (i know it is ancient but
	solid for me) jfs doesn't update mtime of
	directories unless the block allocation changes
	breaking maildir update detection.

	xfs -- home (because of the jfs bug) Earlier tests
	of xfs gave me horrible performance and i haven't
	gotten around to testing since then.  If this is
	fixed without tuning i might drop jfs.  Then again i
	may drop xfs in the next upgrade if i change distros
	and xfs isn't in-kernel.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Linux 2.4 future

[Mike Fedyk]

On Wed, Dec 03, 2003 at 05:24:20PM -0800, jw schultz wrote:
> <OT>
> As a datapoint i'm running ext2, reiserfs, JFS and XFS each
> for different reasons.
> 
> 	ext2 -- boot (i'm stodgy) and 2kb blocks for archive CDs
> 
> 	reiserfs3 -- filesystems not exported nfs (no
> 	historical version level that i can confirm whether
> 	i have or not will namesys assert is reliable over
> 	nfs)
> 

Maybe you should just try it?  I've used reiserfs on an NFS/samba server,
and it didn't give me trouble.

> 	jfs -- most nfs exported filesystems, decent
> 	performance and solid but i don't use if for home
> 	because in SuSE's 2.4.18 (i know it is ancient but
> 	solid for me) jfs doesn't update mtime of
> 	directories unless the block allocation changes
> 	breaking maildir update detection.

This has been fixed in newer versions of JFS though, right?

> 	xfs -- home (because of the jfs bug) Earlier tests
> 	of xfs gave me horrible performance and i haven't
> 	gotten around to testing since then.  If this is
> 	fixed without tuning i might drop jfs.  Then again i
> 	may drop xfs in the next upgrade if i change distros
> 	and xfs isn't in-kernel.

What about ext3?  I tend to prefer ext3 since I know how it works more than
the others, and it puts data integrity ahead of performance, which is the
way things should be (TM).

Re: Linux 2.4 future

[Tim Connors]

Mike Fedyk <mfedyk@matchmail.com> said on Wed, 3 Dec 2003 17:47:43 -0800:
> On Wed, Dec 03, 2003 at 05:24:20PM -0800, jw schultz wrote:
> > 	xfs -- home (because of the jfs bug) Earlier tests
> > 	of xfs gave me horrible performance and i haven't
> > 	gotten around to testing since then.  If this is
> > 	fixed without tuning i might drop jfs.  Then again i
> > 	may drop xfs in the next upgrade if i change distros
> > 	and xfs isn't in-kernel.
> 
> What about ext3?  I tend to prefer ext3 since I know how it works more than
> the others, and it puts data integrity ahead of performance, which is the
> way things should be (TM).

Is it true that JFS still doesn't use a /lost+found?

The justification being that it doesn't want to stuff up the directory
structure anymore than it already supposedly is.

Personally, I think this behaviour is shit, because I would have to
reinstall from backup everytime I get an unclean shutdown (which
defeats the purpose of having journalling at all). (from memory, at
fsck time, it doesn't actually print out that many diagnostics, so I
don't know what adverse things have happened to my filesystem).

I have had plenty of problems with it. One I can think of is under
debian, after your $RANDOM mounts, it doesn't manage to do the
automatic forced fsck, so none of the filesystems get mounted. It
tries to stumble along without having mounted /usr. I have to reboot,
log in single user, and manually fsck. I don't know whther this is a
fsck.jfs or a debian deficiency.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Animals who are not penguins can only wish they were.

Re: Linux 2.4 future

[Willy Tarreau]

Hi !

On Thu, Dec 04, 2003 at 02:45:13PM +1100, Tim Connors wrote:
> > What about ext3?  I tend to prefer ext3 since I know how it works more than
> > the others, and it puts data integrity ahead of performance, which is the
> > way things should be (TM).
> 
> Is it true that JFS still doesn't use a /lost+found?
<...>

> I have had plenty of problems with it. One I can think of is under
> debian, after your $RANDOM mounts, it doesn't manage to do the
> automatic forced fsck, so none of the filesystems get mounted. It
> tries to stumble along without having mounted /usr. I have to reboot,
> log in single user, and manually fsck. I don't know whther this is a
> fsck.jfs or a debian deficiency.

I recently had a very bad experience on my notebook with ext3 and fsck. It
had not checked the disk for 180 days, and started it... I can now estimate
about 60 files I lost in /usr (most of them in /usr/bin), but I regularly
discover new missing ones. Since this notebook has experience lots of
crashes, I think that the FS already was in bad situation, but these files
were still OK for me just before I shut it down. I cannot imagine not
noticing a "make: command not found" after a day of compilation. So I
stuffed some missing files in it again and it's OK now. I really don't
know what happened. Perhaps I fscked during a solar flare :-)

Cheers
Willy

Re: Linux 2.4 future

[jw schultz]

On Wed, Dec 03, 2003 at 05:47:43PM -0800, Mike Fedyk wrote:
> On Wed, Dec 03, 2003 at 05:24:20PM -0800, jw schultz wrote:
> > <OT>
> > As a datapoint i'm running ext2, reiserfs, JFS and XFS each
> > for different reasons.
> > 
> > 	ext2 -- boot (i'm stodgy) and 2kb blocks for archive CDs
> > 
> > 	reiserfs3 -- filesystems not exported nfs (no
> > 	historical version level that i can confirm whether
> > 	i have or not will namesys assert is reliable over
> > 	nfs)
> > 
> 
> Maybe you should just try it?  I've used reiserfs on an NFS/samba server,
> and it didn't give me trouble.

I did once.  Seemed fine for a while then it hit problems
(don't recall specifics) with some files.  Very painful
transitioning active filesystems.  Since then practically
every new version has claimed to have fixed NFS.  I'll wait
until the fix doesn't need to be fixed again for a few revs.

> 
> > 	jfs -- most nfs exported filesystems, decent
> > 	performance and solid but i don't use if for home
> > 	because in SuSE's 2.4.18 (i know it is ancient but
> > 	solid for me) jfs doesn't update mtime of
> > 	directories unless the block allocation changes
> > 	breaking maildir update detection.
> 
> This has been fixed in newer versions of JFS though, right?

Dunno,  I assume so.  It is a pretty obvious bug by the time
i had a server running JFS the kernel i was running was
already old.

If you are running JFS it is easy to test.  Just create a
directory with some files in it and rename or delete one so
the block count of the directory is unchanged and look at
the mtime.

> > 	xfs -- home (because of the jfs bug) Earlier tests
> > 	of xfs gave me horrible performance and i haven't
> > 	gotten around to testing since then.  If this is
> > 	fixed without tuning i might drop jfs.  Then again i
> > 	may drop xfs in the next upgrade if i change distros
> > 	and xfs isn't in-kernel.
> 
> What about ext3?  I tend to prefer ext3 since I know how it works more than
> the others, and it puts data integrity ahead of performance, which is the
> way things should be (TM).

I see too many reports of lost files and ext3 running in a
degraded state unnoticed to trust it.  The features list is
great but there are just too many bugfixes between kernel
versions in production and HEAD.  When i've XFS, reiserfs
and JFS to choose from the need for ext3 just isn't there at
this time.  The added confidence of data journalling on
systems that don't crash just doesn't outweigh doubts caused
by reports of silently lost files. (look further down the
other branch from the message to which this is a reply)

I appreciate the work that has gone into ext3 and have some
hopes that in time it may get past any real or imagined
deficiencies.  I suspect that the biggest value of ext3 at
this time is as a labratory for testing filesystem theory
and new features.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: Linux 2.4 future

[Marcelo Tosatti]

On Mon, 1 Dec 2003, Marcelo Tosatti wrote:

> 
> Hi, 
> 
> The intention of this email is to clarify my position on 2.4.x future.
> 
> 2.6 is becoming more stable each day, and we will hopefully see a 2.6.0
> release during this month or January.
> 
> Having that mentioned, I pretend to:

As several people pointed out, I mean "intend" not pretend.

> - Fix pending problems which might required more intrusive modifications
> during 2.4.24. New drivers will be accept during this period (for example,
> Cyclades PC300 driver, input userlevel driver support, or other sane
> driver which might come up).
> 
> - From 2.4.25 on, fix only critical/security problems.

Re: Linux 2.4 future

[David S. Miller]

On Mon, 1 Dec 2003 12:25:23 -0200 (BRST)
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:

> - From 2.4.25 on, fix only critical/security problems.

I think this is fine, 2.4.x really needs to go into super-
maintainence mode whilst 2.6.x is being brought on stage.

Re: Linux 2.4 future

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]

>>>>> "Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com>:
 Marcelo> The intention of this email is to clarify my position on 2.4.x
 Marcelo> future.

 Marcelo> 2.6 is becoming more stable each day, and we will hopefully
 Marcelo> see a 2.6.0 release during this month or January.

 Marcelo> Having that mentioned, I pretend to:
[...]
 Marcelo> - From 2.4.25 on, fix only critical/security problems.

I find your statements on 2.6.0 being stable enough for users rather
alarming. I'll use this occasion to write about my gripes with Linux
development, with hopes that perhaps this will help some developers
understand people's needs better.

On my notebook, I have spent the last two years going through regular
painful kernel patching and upgrades. I have never had a fully working
system during that time. At various times, various parts failed to work
correctly: ACPI, software suspend, USB, sound. Also, the kernel is
incomplete and I have had to patch each new release or compile
additional drivers for (at least): ACPI, cpufreq, cryptoapi + loop
driver fix (for reasonable IV calculation), orinoco wireless card,
spectrum24 wireless card, ALSA sound modules and software suspend.

I've seen ABI's change from under me (the tun/tap interface being
changed around 2.4.9 AFAIR). I've seen bugs being ignored [1]. I've seen
2.4 kernels being plain unusable on my hardware (a non-working ACPI
implementation means the hardware will overheat).

Overall, the state of affairs has been rather sad. It is improving now,
with ACPI and software suspend becoming mature. Some of the USB bugs
were fixed around 2.4.21/22 (I think). I finally have a reasonably
stable system to work on [2].

I am terrified of the following scenario, which is extremely probable to
happen soon:

  1) 2.4 is being moved into "pure maintenance" mode and people are
     being encouraged to move to 2.6.
  2) While people slowly start using 2.6, Linus starts 2.7 and all
     kernel developers move on to the really cool and fashionable things
     [3].
  3) 2.6 bug reports receive little attention, as it's much cooler to
     work on new features than fix bugs. Bugs are not fashionable.
  4) In the meantime, third-party vendors are confused and do not
     support any kernel properly [4].

IMHO, Linus should try to enforce a *long* 2.6 testing period after the
"real" 2.6 kernel is out. Starting a new series immediately is a recipe
for disaster, as with the 2.4 kernels.

Also, please remember, that for some people the move to 2.6 is not that
easy. My personal checklist of things that have to work (and some still
do not, for various reasons) for me to migrate:

  -- support for my hardware (of course),
  -- stable software suspend,
  -- crypto support that can mount my filesystem,
  -- VMware kernel modules,
  -- ATI drivers [5].

What are my suggestions? Two main points, I guess:

  1) Please don't stop working (and that does include pulling in new
     stuff) on 2.4, as many people still have to use it.

  2) Please don't start developing 2.7 too soon. Go for at least 6
     months of bug-fixing. During that time, patches with new features
     will accumulate anyway, so it isn't lost time. But it will at least
     prevent people from saying "well, I use 2.7.45 and it works for
     me".

I hope this posting will help some of you understand how some users
feel. I think most of those people who run into these kinds of problems
are not very well represented on this list. I know of at least several
people who have tried installing Linux on a laptop and failed
[6]. You'll never hear from those people here.

--J.

== 
[1] Yes, I think a "please retest with 2.5.69" response is equivalent to
    ignoring a bug report.  I was also rather disappointed by people
    saying they don't care about bug reports from people who are not
    willing to resend them regularly. 2.4 does not have a bug-tracking
    system, which means many bug reports get lost or ignored.

[2] On hardware that's two years old.

[3] I really, really couldn't care less for a new scheduler that makes
    my machine 2% faster overall. I will trade performance for
    correctness at any time. I am willing to think about performance
    when my machine works without freeezing or crashing.

[4] Vendors such as VMware, ATI or NVidia.

[5] Please don't tell me to buy an open-source supported 3D card. I've
    seen such answers before and they are ridiculous. There is no such
    card on the market if you want anything like reasonable performance.

[6] Failed for good reasons, not because of stupid errors, but because
    of the limitations of Linux.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Linux 2.4 future

[Jeff Garzik]

On Wed, Dec 03, 2003 at 01:26:56PM -0800, Jan Rychter wrote:
> I find your statements on 2.6.0 being stable enough for users rather
> alarming. I'll use this occasion to write about my gripes with Linux
> development, with hopes that perhaps this will help some developers
> understand people's needs better.

The point is that 2.6.0 has reached the point where major new
development and merging should be occurring there, not in 2.4.

	Jeff

Re: Linux 2.4 future

[Willy Tarreau]

Hi,

On Wed, Dec 03, 2003 at 01:26:56PM -0800, Jan Rychter wrote:
> I am terrified of the following scenario, which is extremely probable to
> happen soon:
> 
>   1) 2.4 is being moved into "pure maintenance" mode and people are
>      being encouraged to move to 2.6.
>   2) While people slowly start using 2.6, Linus starts 2.7 and all
>      kernel developers move on to the really cool and fashionable things
>      [3].
>   3) 2.6 bug reports receive little attention, as it's much cooler to
>      work on new features than fix bugs. Bugs are not fashionable.
>   4) In the meantime, third-party vendors are confused and do not
>      support any kernel properly [4].

This was already already discussed when 2.4 was about to born. But finally
people didn't not jump that fast to 2.5 in part because early releases were
not stable enough for all developpers.

> What are my suggestions? Two main points, I guess:
> 
>   1) Please don't stop working (and that does include pulling in new
>      stuff) on 2.4, as many people still have to use it.
> 
>   2) Please don't start developing 2.7 too soon. Go for at least 6
>      months of bug-fixing. During that time, patches with new features
>      will accumulate anyway, so it isn't lost time. But it will at least
>      prevent people from saying "well, I use 2.7.45 and it works for
>      me".

I think the exact opposite. I too have been hit by recurrent API changes in
2.4. For instance, I remember I once wanted to upgrade to the latest tg3
driver because of a problem in production, but this required me to include
NAPI support in the kernel. Not that pleasant on a stable release.

I think that what incitates people to constantly break APIs and backwards
compatibility is the adding of new features in stable kernels, which is
induced by an overly long release cycle. When developpers have fresh ideas
in their head, they need to implement them right now. If you tell them "wait
6 more months before playing with the dev kernel", what happens ? They test
it on the stable one, and once it works, they propose the patch, people like
you and me find it cool, download it, pressure Marcelo to include it because
we're lazy (don't want to do the job twice), then something breaks.

The other solution: start the new devel kernel even before the stable release
so that developpers can start to play again and not only do the dirty boring
job of running after bug reports. A good developper will always try to fix a
problem in a stable kernel before playing with any other nice feature. But he
needs motivation and not frustration. So I'm totally for a permanent
development tree and regular stable releases with only bug fixes. It's about
what we have with 2.4 at the end of its life. One release every 6 months with
intermediate development releases. But in this case, it's the second digit
and not the third which should be incremented every 6 months.

> [5] Please don't tell me to buy an open-source supported 3D card. I've
>     seen such answers before and they are ridiculous. There is no such
>     card on the market if you want anything like reasonable performance.

Open a paypal account to fund development of these drivers under NDA if you
need... How can you require people you don't even know to find specifications
of closed chips on their own time to write a kernel driver for you ? If it
was that simple, I would ask that someone ports Linux to my under-used G400
so that this graphics card with lots of RAM (32 MB) could embed one more
penguin in my system !

Willy

Re: Linux 2.4 future

[John Jasen]

On Wed, 3 Dec 2003, Jan Rychter wrote:

> >>>>> "Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com>:
>  Marcelo> The intention of this email is to clarify my position on 2.4.x
>  Marcelo> future.
> 
>  Marcelo> 2.6 is becoming more stable each day, and we will hopefully
>  Marcelo> see a 2.6.0 release during this month or January.

I would argue that 2.2 wasn't really usable until somewhere around 2.2.12.

I would also claim that 2.4 wasn't useful until 2.4.10.

If we continue to improve along these lines, can I expect 2.6 to be 
generally usable somewhere around 2.6.8? :)

> On my notebook, I have spent the last two years going through regular
> painful kernel patching and upgrades. 

<snip>

His experiences pretty much mirror my own -- ACPI has been an adventure, 
cpufreq occasionally didn't work, full USB doesn't work without ACPI, I 
need alsa drivers and ACPI in order to have acceptable sound, and I need 
to use GATOS drivers for my display, else 3d just blows chunks.

For the longest time on this beast, kernel upgrades were a day long 
adventure. 

First, to push in acpi, cpufreq, and freeswan. (Oh, look, 2.4.foo is 
out ... but the latest ACPI patch was 2.4.foo-prebar and CPUfreq is 
2.4.foo-pre(bar-2)-3weeks-earlier ... time to patch and resolve 
rejections!)

Then it was off to put in alsa, radoen, freeswan, linux-wlan-ng and so 
forth ...

Some things should be migrated in and updated. drm modules, for example. I 
would also vote for alsa being merged. ACPI was brought up to date in 
2.4.22, I believe, but I haven't checked since then. It should also be 
relativelt current, IMHO.

>   1) Please don't stop working (and that does include pulling in new
>      stuff) on 2.4, as many people still have to use it.
> 
>   2) Please don't start developing 2.7 too soon. Go for at least 6
>      months of bug-fixing. During that time, patches with new features
>      will accumulate anyway, so it isn't lost time. But it will at least
>      prevent people from saying "well, I use 2.7.45 and it works for
>      me".

I have to agree with both of these points. 2.6.0 will probably have 
problems that will take a while to sort out. Putting it on systems to test 
is one thing, putting it into production as its the only blessed solution 
is another ...

-- 
-- John E. Jasen (jjasen@realityfailure.org)
-- User Error #2361: Please insert coffee and try again.

Re: Linux 2.4 future

[Mike Fedyk]

On Fri, Dec 05, 2003 at 10:33:32AM -0500, John Jasen wrote:
> I would also claim that 2.4 wasn't useful until 2.4.10.

Make that 2.4.13, 2.4.10 had a partial merge of the new -aa VM, and it had
many bugs at the time.

Though, many people patched in the fixes instead of going with newer versions.

Re: Linux 2.4 future

[Max Valdez]

[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]

The nices thing is that the evolution from 2.6.0 to 2.6.8 will be very
fast :-), what are the predictions? mine is less than 6 months, we begin
with a nice kernel, not the best, but will finish those 6 months with a
great kernel, really stable, the the release pace will be slower, and we
can start to think on the new shiny unstable 2.7.x kernel :-)

Max
On Fri, 2003-12-05 at 09:33, John Jasen wrote:
> On Wed, 3 Dec 2003, Jan Rychter wrote:
> 
> > >>>>> "Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com>:
> >  Marcelo> The intention of this email is to clarify my position on 2.4.x
> >  Marcelo> future.
> > 
> >  Marcelo> 2.6 is becoming more stable each day, and we will hopefully
> >  Marcelo> see a 2.6.0 release during this month or January.
> 
> I would argue that 2.2 wasn't really usable until somewhere around 2.2.12.
> 
> I would also claim that 2.4 wasn't useful until 2.4.10.
> 
> If we continue to improve along these lines, can I expect 2.6 to be 
> generally usable somewhere around 2.6.8? :)
> 
> > On my notebook, I have spent the last two years going through regular
> > painful kernel patching and upgrades. 
> 
> <snip>
> 
> His experiences pretty much mirror my own -- ACPI has been an adventure, 
> cpufreq occasionally didn't work, full USB doesn't work without ACPI, I 
> need alsa drivers and ACPI in order to have acceptable sound, and I need 
> to use GATOS drivers for my display, else 3d just blows chunks.
> 
> For the longest time on this beast, kernel upgrades were a day long 
> adventure. 
> 
> First, to push in acpi, cpufreq, and freeswan. (Oh, look, 2.4.foo is 
> out ... but the latest ACPI patch was 2.4.foo-prebar and CPUfreq is 
> 2.4.foo-pre(bar-2)-3weeks-earlier ... time to patch and resolve 
> rejections!)
> 
> Then it was off to put in alsa, radoen, freeswan, linux-wlan-ng and so 
> forth ...
> 
> Some things should be migrated in and updated. drm modules, for example. I 
> would also vote for alsa being merged. ACPI was brought up to date in 
> 2.4.22, I believe, but I haven't checked since then. It should also be 
> relativelt current, IMHO.
> 
> >   1) Please don't stop working (and that does include pulling in new
> >      stuff) on 2.4, as many people still have to use it.
> > 
> >   2) Please don't start developing 2.7 too soon. Go for at least 6
> >      months of bug-fixing. During that time, patches with new features
> >      will accumulate anyway, so it isn't lost time. But it will at least
> >      prevent people from saying "well, I use 2.7.45 and it works for
> >      me".
> 
> I have to agree with both of these points. 2.6.0 will probably have 
> problems that will take a while to sort out. Putting it on systems to test 
> is one thing, putting it into production as its the only blessed solution 
> is another ...
-- 
Linux garaged 2.4.22-ac4 #2 SMP Mon Oct 6 14:33:25 UTC 2003 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GS/ d-s:a-28C++ILHA+++P+L++>+++E---W++N*o--K-w++++O-M--V--PS+PEY--PGP++t5XRtv++b++DI--D-G++e++h-r+y**
------END GEEK CODE BLOCK------
gpg-key: http://garaged.homeip.net/gpg-key.txt

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]