Hi,
For ARM, I require pgd_alloc to take a struct mm_struct argument (so the
pgd_alloc prototype becomes "pgd_t *pgd_alloc(struct mm_struct *)".
Why? Because ARM must always have the first virtual page allocated and
present - its used for the hardware vectors, and in order to allocate
the page table for this page, I need a mm_struct (see the pte_alloc
prototype and associated code in mm/memory.c).
There are various options here:
1. Either I can fix up all architectures, and send a patch to this list, or
2. You can fix it up, send me a patch, and I'll collate them and send the
whole to Linus.
3. I can send a patch to Alan, and you can send your individual patches again
to Alan, and Alan can send the whole patch to Linus.
Its up to you how this is done.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King writes:
> There are various options here:
>
> 1. Either I can fix up all architectures, and send a patch to this list, or
Fixup all the architectures and send this and the ARM bits to Linus.
I really would wish folks would not choose Alan as the first place
to send the patch. I'm not directly accusing anyone of it, but it
does appear that often AC is used as a "back door" to get a change
in. While this scheme most of the time, often it unnecessarily
overworks Alan which I think is unfair.
Sending it to Linus first also eliminates 2 levels of indirection
each time Linus wants something done differently in the change.
person --> alan --> linus --> needs change
alan BCC's person, person codes new version
person --> alan --> linus --> etc. etc.
Sure Alan could fix it up himself, but...
My main point is that for changes like this, sending stuff to Alan
first is often an ineffective mechanism. If someone were to reply to
this "Linus is hard to push changes too, or takes too long" my reply
is "if this is really the problem, should the burdon should be
entirely placed on Alan's shoulders?"
The AC patches are huge, but they have substantially decreased in size
during the recent 2.4.4-preX series. And sure, Alan makes conscious
decisions to apply patches and eventually work to push them to Linus,
but honestly people should consider ways to help decrease his load.
Later,
David S. Miller
[email protected]
On Sun, 22 Apr 2001, David S. Miller wrote:
<snip>
> My main point is that for changes like this, sending stuff to Alan
> first is often an ineffective mechanism. If someone were to reply to
> this "Linus is hard to push changes too, or takes too long" my reply
> is "if this is really the problem, should the burdon should be
> entirely placed on Alan's shoulders?"
Perhaps Alan could speak to this.
Alan, could you delegate any of this work? Is it feasible to
have you redirect some portion of the patch analysis and acceptance
load to another person, other than Linus? Obviously, if the rate
of patch flow increases significantly, others will need to get
involved more closely with the patch acceptance process.
Miles
On Sun, 22 Apr 2001, David S. Miller wrote:
>
> Russell King writes:
> > There are various options here:
> >
> > 1. Either I can fix up all architectures, and send a patch to this list, or
>
> Fixup all the architectures and send this and the ARM bits to Linus.
>
> I really would wish folks would not choose Alan as the first place
> to send the patch. I'm not directly accusing anyone of it, but it
> does appear that often AC is used as a "back door" to get a change
> in. While this scheme most of the time, often it unnecessarily
> overworks Alan which I think is unfair.
Hi David,
While I agree that this state of affairs must be taxing Alan,
it was my understanding that this situation was _intended_.
It's been explicitly stated, IIRC, that only really important
bug fixes for very well-defined problems should be going
to Linus. This was announced around the time of the 2.4 launch.
The reasoning being that Linus wanted to be assured that we
would not have a backslide in kernel stability after the 2.4
launch, like happened after the 2.2 launch. My understanding
is that Alan is acting as gatekeeper for the experimental
and lower priority patches until after the 2.5 kernel opens
up. Of course, then the 2.4 maintainer (who will likely
be Alan?) will be receiving 2.4 patches, while Linus begins
receiving all things 2.5 (experimental or not). My guess
(perhaps grossly incorrect) is that the flow rate of patches
after the 2.5 tree opens will be pretty evenly split between
2.5 and 2.4.
Again, IIRC, Linus wanted to stay really focused on the 2.4
kernel stability. Having Alan shielding him from the huge
quantity of patches has probably helped him be effective in
making sure patches in the 2.4.x-pre series are good stuff.
Have I got this right?
Cheers,
Miles
> I really would wish folks would not choose Alan as the first place
> to send the patch. I'm not directly accusing anyone of it, but it
I asked him about it on irc and why it was needed, so it sort of makes a lot
of sense he emailed me it 8)
Alan
> Alan, could you delegate any of this work? Is it feasible to
> have you redirect some portion of the patch analysis and acceptance
> load to another person, other than Linus? Obviously, if the rate
To be honest I get very little patch material I didnt want to track. I get
lots of patches that are wrong, misguided, or otherwise flawed. However
I want to see those patches so I can help get them fixed.
On the whole people seem to be fairly good at sending stuff to obvious
maintainers. Sometimes I bounce a few on. Big global changes to vm/vfs I tend
to ignore because those kind of things tend to be stuff Linus cares a lot
about getting right anyway.
Alan
On Sun, Apr 22, 2001 at 09:44:07PM -0700, David S. Miller wrote:
> I really would wish folks would not choose Alan as the first place
> to send the patch. I'm not directly accusing anyone of it, but it
> does appear that often AC is used as a "back door" to get a change
> in. While this scheme most of the time, often it unnecessarily
> overworks Alan which I think is unfair.
The reason I suggested sending this stuff to Alan is because it _needs_
to be reviewed or tested before coming out in Linus tree, and I know
that Linus is trying to get 2.4.4 out.
Last time I checked, ARM can't run a Sparc kernel. ;)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, 23 Apr 2001, Alan Cox wrote:
> > Alan, could you delegate any of this work? Is it feasible to
> > have you redirect some portion of the patch analysis and acceptance
> > load to another person, other than Linus? Obviously, if the rate
>
> To be honest I get very little patch material I didnt want to track. I get
> lots of patches that are wrong, misguided, or otherwise flawed. However
> I want to see those patches so I can help get them fixed.
Obviously, there's huge value to the development community to get your
feedback on these flawed patches, as well. It strengthens the entire
community.
> On the whole people seem to be fairly good at sending stuff to obvious
> maintainers. Sometimes I bounce a few on. Big global changes to vm/vfs I tend
> to ignore because those kind of things tend to be stuff Linus cares a lot
> about getting right anyway.
Yeah. I sort of figured you'd shout if something really wasn't working.
Thanks Alan,
Miles