Patch submissions

Patch submissions

[Alan Cox]

I'm getting a notable increase in people sending me patches that do major
things and should be 2.5 stuff. Please if you want to rewrite the VM completely,
redesign the scsi layer and the like wait until 2.5. 

Right now I'm only collecting patches that are driver bugfix/updates, arch
specific updates/fixes or bugfixes (not feature adds) for the core kernel code.

Anything else goes in the bitbucket

Re: Patch submissions

[Lars Marowsky-Bree]

On 2001-03-06T16:56:32,
   Alan Cox <alan@lxorguk.ukuu.org.uk> said:

> I'm getting a notable increase in people sending me patches that do major
> things and should be 2.5 stuff. Please if you want to rewrite the VM completely,
> redesign the scsi layer and the like wait until 2.5. 

When will 2.5 be forked?

If anyone wants to redesign the SCSI layer, by all means, DO NOT STOP HIM! ;-)

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

Re: Patch submissions

[Rik van Riel]

On Tue, 6 Mar 2001, Lars Marowsky-Bree wrote:
> On 2001-03-06T16:56:32,
>    Alan Cox <alan@lxorguk.ukuu.org.uk> said:
>
> > I'm getting a notable increase in people sending me patches that do major
> > things and should be 2.5 stuff. Please if you want to rewrite the VM completely,
> > redesign the scsi layer and the like wait until 2.5.
>
> When will 2.5 be forked?
>
> If anyone wants to redesign the SCSI layer, by all means, DO NOT
> STOP HIM! ;-)

If somebody is able to redesign the SCSI layer, I'm *sure*
that person will be able to maintain a separate patch for
some time ...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Patch submissions

[Rik van Riel]

On Tue, 6 Mar 2001, Alan Cox wrote:

> I'm getting a notable increase in people sending me patches that
> do major things and should be 2.5 stuff. Please if you want to
> rewrite the VM completely, redesign the scsi layer and the like
> wait until 2.5.

VM folks can post their patches to linux-mm@kvack.org, where
we can play with things until 2.5 is forked.

I agree with Alan that we should keep all experimental stuff
out of 2.4, probably even out of linux-kernel ...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Patch submissions

[Kurt Garloff]

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

On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote:
> I agree with Alan that we should keep all experimental stuff
> out of 2.4,

Depends on the impact. Experimental stuff in MM, FS, ... things is something
which we don't want. If somebody writes a new driver for a device which was
not supported before, we may want to add it to the kernel to get it tested
and improved.
But, that's probably what you meant.

> probably even out of linux-kernel ...

No. I want to see experimental stuff on l-k. That's what it's meant for.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, FRG                               SCSI, Security

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

Re: Patch submissions

[Rik van Riel]

On Tue, 6 Mar 2001, Kurt Garloff wrote:
> On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote:
> > I agree with Alan that we should keep all experimental stuff
> > out of 2.4,
>
> Depends on the impact. Experimental stuff in MM, FS, ...
	[snip]
> But, that's probably what you meant.

*nod*

> > probably even out of linux-kernel ...
>
> No. I want to see experimental stuff on l-k. That's what it's meant for.

Putting the experimental stuff which isn't on l-k at the
moment would probably triple the volume of this list, if
not more ...

I'm pretty sure most people already find l-k traffic too
heavy to keep up. If you want to read all the experimental
stuff of all the subsystems, why not subscribe to the
mailing lists of those subsystems ?

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Patch submissions

[Jeff Garzik]

Rik van Riel wrote:
> On Tue, 6 Mar 2001, Kurt Garloff wrote:
> > On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote:
> > > probably even out of linux-kernel ...
> >
> > No. I want to see experimental stuff on l-k. That's what it's meant for.
> 
> Putting the experimental stuff which isn't on l-k at the
> moment would probably triple the volume of this list, if
> not more ...
> 
> I'm pretty sure most people already find l-k traffic too
> heavy to keep up. If you want to read all the experimental
> stuff of all the subsystems, why not subscribe to the
> mailing lists of those subsystems ?

Every patch doesn't need to go to lkml, but keeping linux-kernel folks
updated on experimental issues is always IMHO a good idea.  Otherwise,
interested folks who don't have time to find out about and subscribe to
1000 other lists are kept informed.

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

Re: Patch submissions

[Andrew Morton]

Rik van Riel wrote:
> 
> On Tue, 6 Mar 2001, Alan Cox wrote:
> 
> > I'm getting a notable increase in people sending me patches that
> > do major things and should be 2.5 stuff. Please if you want to
> > rewrite the VM completely, redesign the scsi layer and the like
> > wait until 2.5.
> 
> VM folks can post their patches to linux-mm@kvack.org, where
> we can play with things until 2.5 is forked.
> 

With respect, Rik.  You haven't finished the 2.4 VM yet.

It needs better design description.  I've been reading
through it lately, and in some parts it is very, very
hard to go backwards from the implementation to the
designer's intent.

Let's take just one line:

        count = inactive_shortage() + free_shortage();

That expands to, approximately, sometimes:

inactive_shortage():
        freepages.high + inactive_target - nr_free_pages() -
		nr_inactive_clean_pages() - nr_inactive_dirty_pages;

plus free_shortage():

	(freepages.high + inactive_target / 3) -
              (nr_free_pages() + nr_inactive_clean_pages())

IOW:

	2 * freepages.high + 1.33*(min((memory_pressure >> INACTIVE_SHIFT),
                (num_physpages / 4))) - 2 * nr_free_pages() -
        2 * nr_inactive_clean_pages() - nr_inactive_dirty_pages

That's not a thing which just leaps out at me and shouts "ah-ha!"  :)

Across the lifetime of 2.4, other people are going to need to
understand this stuff.  To be able to analyse and even predict how the
VM dynamics will change with varying tuning, varying workload
and varying platform characteristics.

There *is* a fair quantity of good design description in there,
but there are gaps.

Could you please take the time to raise a commentary patch
which describes the underlying design intent?  I'd
strongly recommend *against* some offstream document (it
doesn't get updated) or API documentation (usually lame and useless).
Inline description is much more useful and better maintained.

Thanks

-

Re: Patch submissions

[Rik van Riel]

On Tue, 6 Mar 2001, Andrew Morton wrote:

> With respect, Rik.  You haven't finished the 2.4 VM yet.
> 
> It needs better design description.

> Could you please take the time to raise a commentary patch
> which describes the underlying design intent?

OK, I'll go work on this...

You are right, this is an extremely important thing.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/