All architecture maintainers: pgd_alloc()
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
Quoted 3 lines · Russell King
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]
Quoted 6 lines · David S. Miller
Quoted 3 lines · Russell King
There are various options here:
1. Either I can fix up all architectures, and send a patch to this list, or
Quoted 7 lines
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
On Sun, 22 Apr 2001, David S. Miller wrote:
<snip>
Quoted 5 lines
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
Quoted 3 lines
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
Quoted 7 lines · Alan Cox
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 2 lines
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
Quoted 5 lines · David S. Miller
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