A modest proposal -- We need a patch penguin
Matthew D. Pitts
I agree 100% with this idea. I have several projects in the planning stages
that i want to integrate into 2.5, but I do NOT want them dropped with no
explanation. If i had a computer that I could devote to it, I would be
willing to volenteer to be patch penguin.
Matthew D. Pitts
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Francesco Munda
Rob Landley <lan...@trommello.org> wrote:
> Patch Penguin Proposal.
>
> [...]
You mean some sort of proxy/two-tier development? A "commit/rollback"
transaction model on the kernel itself?
I deeply agree with you, especially in keeping "many eyes" to look at the
same kernel tree, and not chosing one of the many subtrees; as added bonus,
this stuff is buzzword compliant! What we can ask more? :)
Now, Linus' call to accept _your_ patch. Fingers crossed already.
-- FM
John Weber
patches anyway in my new duties as maintainer of www.linuxhq.com.
I am currently writing code to scan the usual places for linux patches
and automatically add them to our databases. This would be really
simplified by having patches sent to us. And, since we already have a
functioning site, we have the hardware/network capacity to serve as
a limitless queue of waiting patches for Linus. I would love nothing
more than to update the site with information as to the status of these
patches.
John Weber
Linus Torvalds
Francesco Munda <sy...@libero.it> wrote:
>
>I deeply agree with you, especially in keeping "many eyes" to look at the
>same kernel tree, and not chosing one of the many subtrees; as added bonus,
>this stuff is buzzword compliant! What we can ask more? :)
Some thinking, for one thing.
One "patch penguin" scales no better than I do. In fact, I will claim
that most of them scale a whole lot worse.
The fact is, we've had "patch penguins" pretty much forever, and they
are called subsystem maintainers. They maintain their own subsystem, ie
people like David Miller (networking), Kai Germaschewski (ISDN), Greg KH
(USB), Ben Collins (firewire), Al Viro (VFS), Andrew Morton (ext3), Ingo
Molnar (scheduler), Jeff Garzik (network drivers) etc etc.
If there are problems with certain patches, it tends to be due to one or
more of:
- the subsystem is badly modularized (quite common, originally. I don't
think many people realize how _far_ Linux has come in the last five
years wrt issues like architectures, driver independence, filesystem
infrastructure etc). And it still happens.
- lack of maintainer interest. Many "maintainers" are less interested
in true merging than in trying to just push whatever code they have,
and only ever grow their patches instead of keeping them in pieces.
This is usually a matter of getting used to it, and the best people
get used to it really quickly (Andrea, for example, used to not do
this well at all, but look at how he does it now! From a merge
standpoint, his patches have gone from "horrible" to "very good")
- personality/communication issues. Yes, they happen. I've tried to
have other people be "filters" for the people I cannot work with, but
I have to say that most of the time when I can't work with somebody,
others have real problems with those people too.
(An example of a very successful situation: David Miller and Alexey
Kuznetsov: Alexey used to have these rather uncontrolled patches that
I couldn't judge or work with but that obviously had a lot of
potential, and David acting as a filter made them a very successful
team.)
In short, if you have areas or patches that you feel have had problems,
ask yourself _why_ those areas have problems.
A word of warning: good maintainers are hard to find. Getting more of
them helps, but at some point it can actually be more useful to help the
_existing_ ones. I've got about ten-twenty people I really trust, and
quite frankly, the way people work is hardcoded in our DNA. Nobody
"really trusts" hundreds of people. The way to make these things scale
out more is to increase the network of trust not by trying to push it on
me, but by making it more of a _network_, not a star-topology around me.
In short: don't try to come up with a "patch penguin". Instead try to
help existing maintainers, or maybe help grow new ones. THAT is the way
to scalability.
Linus
Linus Torvalds
On Mon, 28 Jan 2002, Rob Landley wrote:
>
> > A word of warning: good maintainers are hard to find. Getting more of
> > them helps, but at some point it can actually be more useful to help the
> > _existing_ ones. I've got about ten-twenty people I really trust, and
> > quite frankly, the way people work is hardcoded in our DNA. Nobody
> > "really trusts" hundreds of people. The way to make these things scale
> > out more is to increase the network of trust not by trying to push it on
> > me, but by making it more of a _network_, not a star-topology around me.
>
> (It's not a star topology, it's a tree.)
No, I don't really think an "integration manager" works well.
I think it helps a lot to have people pick up patches that nobody else
wants to maintain, and to gather them up. Andrea does that to some degree.
But it is _much_ better if you have somebody who is a point-man for
specific areas.
The problem with an overall guy is that there can't be too many of them.
The very thing you are _complaining_ about is in fact that there are a
number of over-all guys without clear focus, which only leads to confusion
about who handles what.
Clarity is good.
> Are you saying that Alan Cox's didn't serve a purpose during the 2.2 kernel
> time frame, and that Dave Jones is currently wasting his time?
No, I'm saying that there are not very many peopel who can do it, and who
can get the kind of trust that they are _everywhere_. Let's face it, Alan
grew to be respected because he did lots of different stuff over many
years, and he proved himself more than capable. And I suspect he's _quite_
happy not being in the middle of it right now.. It's a tough job.
It's a lot more likely to find people who can maintain _parts_. And if
there are patches that fall out of those parts, that tends to indicate a
lack of modularity, and perhaps a lack of maintainer for those parts.
And more likely, even if you _do_ find ten people who can do everything,
you don't want them to.
Andrew Pimlott
One,
> This integration and patch tracking work is a fairly boring, thankless task,
> but it's work somebody other than Linus can do, which Linus has to do
> otherwise. (And which Linus is NOT doing a good job at right now.)
... are you _sure_ that Linus does this? My sense is that he mostly
eschews integration grunt-work. If that is so, it's possible that
Linus is already operating near top efficiency, and that his
throughput is as high as he wants it to be! Linus has pointed out
more than once that a big part of his job is to limit change. Maybe
he's happy with the current rate of change in 2.5. (That doesn't
mean everything is optimal--he might wish for higher quality changes
or a different mix of changes, just not more.)
Two, Linus has argued that maintainers are his patch penguins;
whereas you favor a single integration point between the maintainers
and Linus. This has advantages and disadvantages, but on the whole,
I think it is better if Linus works directly with subsystem
maintainers. To the extent that Linux is modular, there is little
need for the extra layer (so it is just overhead). And when there
is a real conflict between subsystems--that's probably just the time
when Linus and the maintainers need to be collaborating directly!
The only "but" is that many people find it hard to work with Linus.
However, Linus made clear in his message that he considers this a
solvable problem (and maybe one you should work on!).
> Finished code
> regularly goes unintegrated for months at a time, being repeatedly resynced
> and re-diffed against new trees until the code's maintainer gets sick of it.
Assuming that your system doesn't dramatically increase Linus's
throughput, code will still have to be re-diffed. I don't agree
that thrusting all the merging onto one person is the right
solution. That person is a _much_ bigger scalability bottleneck
than Linus, because (by your definition of the role) he can't drop
patches! So he will inevitably become overwhelmed, and then we have
a bigger mess.
Frankly, if I were a maintainer, I would want the patch that finally
gets integrated to be one that I produce, not one re-diffed by
someone less familiar with the subsystem. So, I side with Linus's
"tough, that's part of the maintainer's job" stance. (Now, tools to
help resync, and to eliminate the tedium of re-submitting to Linus
periodically, would be welcome.)
> Several of the bug fixes in Alan's tree (which he
> stopped maintaining months ago) still are not present in 2.4.17 or 2.5.
This is plain evidence that a single integration point (and there is
no better than Alan) isn't a panacea.
Three, regarding your complaint about "clean-up" patches being
dropped: maybe this just means there is a maintainer missing from
the pantheon: the clean-up maintainer.
Andrew
Larry McVoy
> And more likely, even if you _do_ find ten people who can do everything,
> you don't want them to.
[and other things, in general saying that he wasn't happy with the approach]
What you didn't do, Linus, is paint a picture which allows development
to scale up. Perhaps you don't want it to do so; looking back on Sun's
development process has taught me that a lot of it was just a way to
slow things down enough that the architects could keep up with the many
hacks going on here there and everywhere. If this was Sun, I'd say that
slowing things down is good.
But cast your mind back to your "Linux is evolution" line of reasoning
and ask yourself if that does not mean that allowing the fastest
forward progress is what you want. It would seem so, but at this point,
Linus, it is hard to predict what you think, so I'll pass on guessing.
What would be nice is if you came out with a clear statement, similar
to Rob's written summary, that said what it is that you would like to
see happen to address the issues that have come up over and over again.
The alternative is that sooner or later someone or some group will come
up with a better answer, there will be an ugly fight, and a lot of time
will get wasted when we could have learned how to grow up nicely.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Linus Torvalds
On Mon, 28 Jan 2002, Larry McVoy wrote:
>
> What you didn't do, Linus, is paint a picture which allows development
> to scale up.
Actually, I thought I did.
Basic premise: development is done by humans.
Now, look at how humans work. I don't know _anybody_ who works with
hundreds of people. You work with 5-10 people, out of a pool of maybe
30-50 people. Agreed?
Now, look at the suggested "patch penguin", and realize that the
suggestion doesn't add any scaling at all: it only adds a simple layer
that has all the same scaling problems.
What I'm saying is
- I'm never going to work with hundreds of people directly, because it is
fundamentally against my nature, by virtue of being human.
- adding a "patch penguin" doesn't help, because _he_ (or she, although I
didn't see any women nominated) is also going to be human. So either
the patch penguin is going to do a bad job (and I won't start trusting
him/her), or the patch penguin is going to have all the same issues
people complain about.
Those are obvious truths. If you don't see them as being obvious truths,
you just haven't been thinking things through.
Did Alan do a good job? Yes. He did a _great_ job. But let's face it: (a)
he got really tired of doing it and (b) it really works only with one or
two Alan's, not with more - because with more you get people complaining
about the -aa tree vs the -dj tree vs the -marcelo tree vs the -linus
tree.
So Alan doesn't scale up either - I doubt you'll find a "better Alan", and
I _seriously_ doubt you'll be able to have multiple Alan's.
Does anybody really doubt this?
Now, if you've read this far, and you agree with these issues, I suspect
you know the solution as well as I do. It's the setup I already mentioned:
a network of maintainers, each of whom knows other maintainers.
And there's overlap. I'm not talking about a hierarchy here: it's not the
"general at the top" kind of tree-like setup. The network driver people
are in the same general vicinity as the people doing network protocols,
and there is obviously a lot of overlap.
Are there problems with maintainership? Yes. The main one being that it's
too damn easy to step on any toes. Which is why you want the modularity,
ie you do NOT want to have files issues that slash across different
maintenance boundaries (unless they have clearly defined interfaces:
that's where the importance of a clear VFS interface design comes in etc)
For an example of this, look at init/main.c in 2.2.x, in 2.4.x, and in
2.5.x. BIG changes. And most of the changes have very little to do with
what that file actually does (relatively little), and _everything_ to do
with the fact that it is the file that "instantiates" almost everything
and thus crosses all boundaries.
And notice how the "initcall" etc setup has changed, and cut a lot of
those dependencies. That's very much by design: look at what a device
driver had to do (and know) to be either a compiled-in driver or a modular
driver a few years ago. And look at a driver today.
In short, I'm saying that the true path to scalability is:
- lack of dependencies on a source level
This implies good interfaces that do NOT have common source files for
different projects. In particular, it implies dynamic add/remove
without the rest of the system having to know at all.
- lack of people (whether patch-penguins or me) who have to follow
everything.
This, in turn, implies two things:
(a) it is not the maintainers who pull things into their trees (because
they aren't always there, and they don't know everything). It is
the developers who _push_ onto maintainers.
(b) if you as a developer cannot find a maintainer who you know, it is
YOUR problem, and you cannot blame some super-penguin in the blue
yonder for not caring about you. You may have to maintain your
patch-set yourself. Or you should find a maintainer who cares about
the work you do, and who helps feed it forward.
I know, I know. It's easier to whine about other people than it is to take
responsibility for your own actions. It's so easy to complain about "Linus
doesn't apply my patches", and so hard to just face the fact that Linus
never _will_ care about all patches, and that if you cannot find anybody
else to care about them either, then maybe they should die or you should
take care and feed them yourself.
I'm a bastard. I'm spending a lot of time applying patches, but it's not
my whole life. Never has been, never will be. I'll always be better at
applying patches from those ten people that I know and I trust than I'll
be at applying patches from people I don't trust.
If you're a developer, and you can't get through to me, ask yourself if
you can get through to somebody else.
And if you can't get through to anybody else either, ask yourself whether
maybe the problem is at _your_ end.
Linus
Stuart Young
>I think it helps a lot to have people pick up patches that nobody else
>wants to maintain, and to gather them up. Andrea does that to some degree.
>But it is _much_ better if you have somebody who is a point-man for
>specific areas.
>
>The problem with an overall guy is that there can't be too many of them.
>The very thing you are _complaining_ about is in fact that there are a
>number of over-all guys without clear focus, which only leads to confusion
>about who handles what.
>
>Clarity is good.
Perhaps what we need is a patch maintenance system? Now I'm not talking
CVS, I'm talking about something that is, in reality, pretty simple.
Something that does the following:
1. People can submit patches, which are given a unique patch ID.
2. Notifications of patches are passed on to (from a selection or
automatic detection):
a. A module maintainer
b. A section maintainer
c. A tree maintainer
d. Linus Torvalds
3. The patches can be reviewed, and immediately:
a. Dropped with a canned reject message
b. Dropped with a custom reject message
c. Dropped but archived for later review
d. Suspended/Skipped for later review
e. Redelegated up/down to a maintainer
f. Accepted, pending testing
4. If someone wants to know why their patch is not being accepted:
a. They can easily look up the current status
b. There is a common reference place
c. If their patch is rejected, they can ask for more detail
Yes it's a tiny patch tracking system. The idea is that if we can make the
thing simple to use, simple to understand, and simple to maintain, people
will actually use it. Submitting patches by mail in freeform, while
reasonably simple, leads to overall complication, and may take longer to
sort through.
It doesn't have to be that involved. A shell script (or perl) could happily
do the submission job (which could all still be done by mail, however in a
more formatted approach). It'd also be simple to do some sort of web
interface if anyone was actually inclined.
Later, maybe, we can have it track possible conflicts (between waiting
patches) and flag them as such so the maintainer is aware of the fact.
If we can automate some simple, key parts of the kernel maintenance, then
this could help immensely, and let everyone get on with the job than the
hassle. Maybe we want to re-invent this wheel, maybe we don't.
PS: Remember this is only a suggestion. I'm not infallible (is anyone?),
all I can do is give the big guy ideas (even bad ones), so he can make
better decisions. *grin*
Stuart Young - s...@amc.com.au
(aka Cefiar) - cef...@optushome.com.au
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
Alexei Podtelezhnikov
May I add just a pure speculation that some significant part of the problem
lays in human nature of the kernel developers? The perfectly logical path of a
patch progression and acceptance, which goes through the subsystem
maintainers, is greatly obscured by the fact that the author's name will
likely never be mentioned in the his-highness-Linus' ChangeLog. So they send
them directly or post to lkml, just hoping. So Linus is flooded with patches.
So the maintainers are fishing for the related bits in the lkml.
So I suggest dropping the names from the holy ChangeLog at all, rather than
mostly just mentioning well established authorities. Yes, this is likely
to kill probably the only reward existing in this community. There are
other ways. It would be cool if maintainers had released their trees before
the holy resync. With rewarding ChangeLogs, this will attract the mighty
community towards them. That's exactly how Alan won the love of the community.
www.kernel.org should have WHO-TO with the maintainers contacts. Gee, I
wonder who decides on the personality of the particular maintainer. The
unmaintained parts - well, Linus, unless you find who maintains it, it's
your responsibility, it's not nice to ignore patches for several months.
If you are not interested, tough but even a person who you dislike will
suffice the community. People just want to know who to bother.
A.
PS. you guessed, I have no chance to be in the ChangeLog since I only
watch debates here.
Nix N. Nix
Kinda like bugzilla, but for patches ? Am I off the deep end here ?
Just a thought.
Greg KH
>
> I'm not proposing replacing the current subsystem maintainers. But are the
> current subsystem maintainers happy?
I'll speak up here as a subsystem maintainer and say that I'm happy with
the current situation. I integrate a wide variety of USB driver patches
from lots of different people (and usually in lots of different formats
against different kernel trees) and feed them to Linus/Marcelo/Alan in
small chunks that can be easily applied against their latest kernel
version.
Sure, sometimes my patches get dropped, but you forgot to mention the
most important thing a kernel programmer needs to have, persistence :)
thanks,
greg k-h
George Bonser
You delegate responsibility to those you trust and accept their
judgment. You also must try to ensure that the thing is built so
that decisions made by Bill can't step on Bob's work. Delegation
is one thing ... but it is the architecture that makes sure that
delegation is possible. I am not a kernel hacker but don't feel
that I have to be in this case to comment. What Linus is saying
has nothing at all to do with Linux but is more along the lines
of how to get work done in any kind of project that is larger than
any single person.
While all kinds of software might get written for project management
and revision control, projects boil down to how the thing is built,
the style of the person in charge, and the people around that person.
Finding people that are willing to take responsibility for portions
of the code base and develop a relationship of trust over time while
being able to work with the individuals submitting patches for their
bug fixes/ideas is a big task. If you could gather all of
those people together, I will bet you they will be a successful team
in just about ANYTHING they choose to work on. I think what Linus is
striving toward is what any good manager wants and when such a team
comes together, watch out, things are gonna happen fast.
Don't think of it as a star or a tree, think of it as a star of trees.
> -----Original Message-----
> From: linux-ker...@vger.kernel.org
> [mailto:linux-ker...@vger.kernel.org]On Behalf Of
> Daniel Phillips
> Sent: Monday, January 28, 2002 11:39 PM
> To: Rob Landley; linux-...@vger.kernel.org
> Subject: Re: A modest proposal -- We need a patch penguin
>
>
> Apropos of nothing in particular:
>
> > (It's not a star topology, it's a tree.)
>
> There is no difference between a star and a tree, except
> how you draw the
> picture.
>
> --
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe
> Linux-kernel" in
Matthias Andree
> The holder of the patch penguin would feed Linus good patches, by Linus's
> standards. Not just tested ones, but small bite-sized patches, one per email
> as plain text includes, with an explanation of what each patch does at the
> top of the mail. (Just the way Linus likes them. :) Current pending patches
> from the patch penguin tree could even be kept at a public place (like
> kernel.org) so Linus could pull rather than push, and grab them when he has
> time. The patch penguin tree would make sure that when Linus is ready for a
> patch, the patch is ready for Linus.
Looks like a manual re-implementation of a bug/request/patch tracker
like sourceforge's, bugzilla or whatever, with some additions. A patch
is added to the system, it gets a version tag, and you just pull it, and
mark it closed if applied to Linus' tree. If Linus releases a new tree,
the patch is marked stale until the maintainer uploads an updated patch
or just reopens it to mark "still applies unchanged to new version". (No
CVS involved, BTW.)
> One reason Linus doesn't like CVS is he won't let other people check code
> into his tree. (This is not a capricious decision on Linus's part: no
> architect can function if he doesn't know what's in the system. Code review
> of EVERYTHING is a vital part of Linus's job.) With a patch penguin tree,
That's one of the arguments Peter Miller uses to endorse his "Aegis"
system: separate the integration part. FreeBSD also seem to follow a
similar idea: there are maintainers and committers. Maintainers usually
do not commit, but file PRs tagged as "maintainer-update".
(Note: I've never used aegis myself, it seems as though it had some
implications with development spread to various locations, someone
comment on that.)
Also, I'm not sure how good Bitkeeper fits here, or whether subversion
will help in this way (one might consider feeding suggestions to the
subversion team, http://subversion.tigris.org/, if they do atomic
commits, one might consider holding them off until blessed by an
integrator).
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Jim McDonald
> On Mon, 28 Jan 2002, Rob Landley wrote:
[...]
> Also, I'm not sure how good Bitkeeper fits here, or whether subversion
> will help in this way (one might consider feeding suggestions to the
> subversion team, http://subversion.tigris.org/, if they do atomic
> commits, one might consider holding them off until blessed by an
> integrator).
I'm not sure that a CVS-type solution is going to fix the problem here.
From what I can see, the problems that people are bringing up are as
follows:
- some patches sent to the list get dropped without comment
- people are worried about Linus' scalability in handling patches
- patches time-out quite quickly with the speed of development of
the kernel, which results in patches not getting applied because
by the time they get looked they have gone stale
- people seem to often be unsure about where to send patches
for unmaintained code, and with no direct maintainer it seems
that these patches automatically fall outside of Linus'
trusted kernel people and stand a very small chance of getting
implemented
I must admit that I agree with Linus' position in most places, but the
result of that is two-fold: a lot of people are left in the dark as to
the state of their patches (ditched, pending, bad style, etc), and a lot
of patch work is duplicated as different people fix the same problem
every couple of months because the fixes are never applied.
We have two solutions - fix the way that all of this works, or try to
patch around the resultant problems. It looks like number 1 is not
going to happen, so why not do something with 2? There has been a lot
of talk about putting together a system that re-sends patches every
month or so to lkml, let's write something that does this. We could get
a number of advantages from this:
- identification of patches (cleanup, performance improvement, bug
fix, new functionality, ...)
- automatic identification of responsible maintainer (direct from
patch) to email on submission of patch
- ability to automatically re-diff patch against latest kernel
versions and get submitter to re-apply if required
- simple rejection of patches with minimal effort from maintainers
- easy way for wannabe-patchers to see what patches are already
pending so they can concentrate on other areas and not duplicate
effort
Note that this isn't that far from SourceForge, but probably too far to
make it worthwhile trying to set it up as an SF project. If we do this
I figure that at worst it allows for auto-resending of patches that have
slipped through the cracks, and at best it will give people a far more
suitable mechanism for patch submission and tracking than just email.
Comments? I'm willing to write it if someone is willing to host it.
> Matthias Andree
Cheers,
Jim.
--
Jim McDonald - J...@mcdee.net
Rik van Riel
> I would be happy to serve as patch penguin, as I plan on collecting all
> patches anyway in my new duties as maintainer of www.linuxhq.com.
> we have the hardware/network capacity to serve as a limitless queue of
> waiting patches for Linus.
Please don't just accumulate stuff.
It would be useful to know which of the patches still
applies against the most recent 2.2, 2.4 or 2.5 kernel,
so each patch gets some status fields:
1) applies against 2.2
2) applies against 2.4
3) applies against 2.5
4) was applied to 2.2
5) was applied to 2.4
6) was applied to 2.5
7) bitrotted patch, no longer applies and wasn't
applied ... moved to 'old' queue
kind regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
Martin Dalecki
>Some thinking, for one thing.
>
>One "patch penguin" scales no better than I do. In fact, I will claim
>that most of them scale a whole lot worse.
>
Bla bla bla... Just tell how frequenty do I have to tell the world, that
the read_ahead array is a write
only variable inside the kernel and therefore not used at
all?????!!!!!!!!!!
Ingo Molnar
On Mon, 28 Jan 2002, Rob Landley wrote:
> (You keep complaining people never send you patches. People are
> suggesting automated patch remailers to spam your mailbox even harder.
> There has GOT to be a better way...)
None of the examples you cited so far are convincing to me, and i'd like
to explain why. I've created and submitted thousands of patches to the
Linux kernel over the past 4 years (my patch archive doesnt go back more
than 4 years):
# ls patches | wc -l
2818
a fair percentage of those went to Linus as well, and while having seen
some of them rejected does hurt mentally, i couldnt list one reject from
Linus that i wouldnt reject *today*. But i sure remember being frustrated
about rejects when they happened. In any case, i have some experience in
submitting patches and i'm maintaining a few subsystems, so here's my take
on the 'patch penguin' issue:
If a patch gets ignored 33 times in a row then perhaps the person doing
the patch should first think really hard about the following 4 issues:
- cleanliness
- concept
- timing
- testing
a violation of any of these items can cause patch to be dropped *without
notice*. Face it, it's not Linus' task to teach people how to code or how
to write correct patches. Sure, he still does teach people most of the
time, but you cannot *expect* him to be able to do it 100% of the time.
1) cleanliness
code cleanliness is a well-know issue, see Documentation/CodingStyle. If
a patch has such problems then maintainers are very likely to help - Linus
probably wont and shouldnt. I'm truly shocked sometimes, how many active
and experienced kernel developers do not follow these guidelines. While
the Linux coding style might be arbitrary in places, all coding styles are
arbitrary in some areas, and only one thing is important above all:
consistency between kernel subsystems. If i go from one kernel subsystem
to another then i'd like to have the same 'look and feel' of source code -
i think this is a natural desire we all share. If anyone doesnt see the
importance of this issue then i'd say he hasnt seen, hacked and maintained
enough kernel code yet. I'd say the absolute positive example here is Al
Viro. I think most people just do not realize the huge amount of
background cleanup work Al did in the past 2 years. And guess what? I bet
Linus would be willing to apply Al's next patch blindfolded.
impact: a patch penguin might help here - but he probably wont scale as
well as the current set of experienced kernel hackers scale, many of whom
are happy to review patches for code cleanliness (and other) issues.
2) concept
many of the patches which were rejected for a long time are *difficult*
issues. And one thing many patch submitters miss: even if the concept of
the patch is correct, you first have to start by cleaning up *old* code,
see issue 1). Your patch is not worth a dime if you leave in old cruft, or
if the combination of old cruft and your new code is confusing. Also, make
sure the patch is discussed and developed openly, not on some obscure
list. linux-...@vger.kernel.org will do most of the time. I do not want
to name specific patches that violate this point (doing that in public
just offends people needlessly - and i could just as well list some of my
older patches), but i could list 5 popular patches immediately.
impact: a patch penguin just wont solve this concept issue, because, by
definition, he doesnt deal with design issues. And most of the big patch
rejections happen due to exactly these concept issues.
3) timing
kernel source code just cannot go through arbitrary transitions. Eg. right
now the scheduler is being cleaned up (so far it was more than 50
sub-patches and they are still coming) - and work is going on to maximize
the quality of the preemption patch, but until the base scheduler has
stabilized there is just no point in applying the preemption patch - no
matter how good the preemption patch is. Robert understands this very
much. Many other people do not.
impact: a patch penguin just wont solve this issue, because a patch
penguin cannot let his tree transition arbitrarily either. Only separately
maintained and tested patches/trees can handle this issue.
4) testing
there are code areas and methods which need more rigorous testing and
third-party feedback - no matter how good the patch. Most notably, if a
patch exports some new user-space visible interface, then this item
applies. An example is the aio patch, which had all 3 items right but was
rejected due to this item. [things are improving very well on the aio
front so i think this will change in the near future.]
impact: a patch penguin just wont solve this issue, because his job, by
definition, is not to keep patches around indefinitely, but to filter them
to Linus. Only separately maintained patches/trees help here. More people
are willing to maintain separate trees is good (-dj, -ac, -aa, etc.), one
tree can do a nontrivial transition at a time, and by having more of them
we can eg. get one of them testing aio, the other one testing some other
big change. A single patch penguin will be able to do only one nontrivial
transition - and it's not his task to do nontrivial transitions to begin
with.
Many people who dont actually maintain any Linux code are quoting Rik's
complains as an example. I'll now have to go on record disagreeing with
Rik humbly, i believe he has done a number of patch-management mistakes
during his earlier VM development, and i strongly believe the reason why
Linus ignored some of his patches were due to these issues. Rik's flames
against Linus are understandable but are just that: flames. Fortunately
Rik has learned meanwhile (we all do) and his rmap patches are IMHO
top-notch. Joining the Andrea improvements and Rik's tree could provide a
truly fantastic VM. [i'm not going to say anything about the IDE patches
situation because while i believe Rik understands public criticism, i
failed to have an impact on Andre before :-) ]
also, many people just start off with a single big patch. That just doesnt
work and you'll likely violate one of the 4 items without even noticing
it. Start small, because for small patches people will have the few
minutes needed to teach you. The bigger a patch, the harder it is to
review it, and the less likely it happens. Also, if a few or your patches
have gone into the Linux tree that does not mean you are senior kernel
hacker and can start off writing the one big, multi-megabyte super-feature
you dreamt about for years. Start small and increase the complexity of
your patches slowly - and perhaps later on you'll notice that that
super-feature isnt all that super anymore. People also underestimate the
kind of complexity explosion that occurs if a large patch is created.
Instead of 1-2 places, you can create 100-200 problems.
face it, most of the patches rejected by Linus are not due to overload. He
doesnt guarantee to say why he rejects patches - *and he must not*. Just
knowing that your patch got rejected and thinking it all over again often
helps finding problems that Linus missed first time around. If you submit
to Linus then you better know exactly what you do.
if you are uncertain about why a patch got rejected, then shake off your
frustration and ask *others*. Many kernel developers, including myself,
are happy to help reviewing patches. But people do have egos, and it
happens very rarely that people ask it on public lists why their patches
got rejected, because people do not like talking about failures. And the
human nature makes it much easier to attack than to talk about failures.
Which fact alone pretty much shows that most of the time the problem is
with the patch submitter, not with Linus.
it's so much easier to blame Linus, or maintainers. It's so much easier to
fire off an email flaming Linus and getting off the steam than to actually
accept the possibility of mistake and *fix* the patch. I'll go on record
saying that good patches are not ignored, even these days when the number
of active kernel hackers has multipled. People might have to go through
several layers first, and finding some kernel hacker who is not as loaded
as Linus to review your patch might be necessery as well (especially if
the patch is complex), but if you go through the right layers then you can
be sure that nothing worthwile gets rejected arbitrarily.
Ingo
Martin Dalecki
>On Mon, 28 Jan 2002, Larry McVoy wrote:
>
>>What you didn't do, Linus, is paint a picture which allows development
>>to scale up.
>>
>
>Actually, I thought I did.
>
>Basic premise: development is done by humans.
>
>Now, look at how humans work. I don't know _anybody_ who works with
>hundreds of people. You work with 5-10 people, out of a pool of maybe
>30-50 people. Agreed?
>
Not at all. Please have a look at the ARMY. (A tightly hierarchical
system...)
Dave Jones
> probably diminish as new development shifts over to 2.5. Right now, the
> patch constipation we've been seeing is, in my opinion, directing development
> to occur against 2.4 that should at the very least be eyeing 2.5. (Alan is
> probably NOT interested in integrating patches that Marcelo has no intention
> of eventually integrating into 2.5. So he's not taking the new development
> integration pressure off, that's DJ's job.)
>
> I think DJ could definitely use a clearer mandate.
* Initially, -dj was "pick up fixes from 2.4".
* Then when Linus broke various other parts of 2.5, I took fixes
for various bits. (Some of those went back his way, others didn't,
others are still in the process)
(I'm a believer in the 'eat your own dogfood' thing, and run my
tree on several testboxes -- being able to compile/boot/test
this tree became more important at the cost of the tree growing
a little further away from -linus)
* Some developers also wanting to develop against 2.5 found the
quickest way to get a compilable, workable 2.5 tree was to
grab my snapshot, and work against my tree until Linus gets his
together. And hence, the input layer & fb layer changes.
This was one I had to think about a bit before deciding if
I was going to start accepting such patches.
In theory, as we're now in 2.5, there should be no need for this,
but whilst Linus is busy focusing on the block layer, scheduler
or other flavour of the week, James, Vojtech etc can at least
get some extra testers before their code hits -linus.
By the time that the new input/fb stuff is ready for Linus' tree
hopefully a lot of the more obvious problems will be shaken out,
and Linus can have a set of patches for a "new xxx layer" that
works for at least everyone who's been testing it in -dj.
Where to go from here? More of the same. It's a fulltime job
keeping up with Marcelo & Linus, and reviewing, merging, and
chasing down the right people. One thing I'm not entirely
enthusiastic about doing, is making policy decisions.
I've had questions from people asking me if I'll merge xxx's
implementation of ACLs for example. Without knowing which way
Linus is going to turn on such an issue, I'm naturally hesitant.
Another thing of note is that the merge process with Linus
isn't as straightforward as running splitdiff, and pushing the
chunks to Linus. Some bits require a timing (although this is
sometimes hard to get right) so I can push him filesystem
changes when Al isn't turning the VFS upside down for eg.
Other bits I won't push because maintainers have mailed me
asking me not to. And other bits, because the maintainers
can do a better job of splitting,pushing and describing than
I can (typical example: the fbdev/input stuff)
> Dave didn't seem to have any major objections but raised a lot technical
> points to the effect of "I'm already doing this bit". Both of them gave me
> permission to post most of our conversation to the list, but seem unwilling
> to do it themselves. :)
Time, Headcold, time, blah, excuses 8)
But to reiterate, yes. Most of what you described is exactly whats
taking place, although a lot of it happens behind the scenes, not
on Linux-kernel, not on irc, but me being a pita chasing maintainers
"Hey xxx sent me a patch, aren't you working on this? You two should
talk..". It's like being a switchboard operator at times, plugging
in the right cables, connecting the right people.
> As for attracting Linus's attention, there's a penguin and egg problem here:
> without an integration lieutenant Linus is largely too swamped to reliably be
> aware of this kind of thread on the list
Linus' concern that people don't scale is perhaps not unfounded.
Since I started doing this, the number of hours involved has increased
on a day by day basis. If there comes a time where >I'm< not scaling
and start dropping patches, then maybe an extra tier is needed. *shrug*
For now at least, things seem to be working out quite well on the whole.
I'm not aware of any particularly important fix/cleanup that has been
dropped on the floor since I started scooping them up.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Padraig Brady
> On Mon, 28 Jan 2002 09:10:56 -0500
> Rob Landley <lan...@trommello.org> wrote:
>
>
>>Patch Penguin Proposal.
>>
>>[...]
>>
>
> You mean some sort of proxy/two-tier development? A "commit/rollback"
> transaction model on the kernel itself?
Dave Jones described the current model very succinctly in:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100966905916285&w=2
He also mentioned a big problem. People not honouring/realising
there position in the tree, (trying to get in the ChangeLog?).
True, the only way to scale it is add another level at the current
bottleneck, but this must be more than 1 person or it won't help,
as it'll just move the bottelneck back a little.
Personally I think automated tools (like bitkeeper) would help
more than another level in the hierarchy.
Currently the way I see it [should be] currently is:
random hackers
| | | | | | |
| maintainers
| | | |
combiners
| |
Linus
I.E. Linus just gets input from the combiners which
test logic from the maintainers in combination. Also
random hackers should input to the combiners and not Linus
if there isn't an appropriate maintainer for their code.
Padraig.
Ingo Molnar
On Tue, 29 Jan 2002, Martin Dalecki wrote:
> >One "patch penguin" scales no better than I do. In fact, I will claim
> >that most of them scale a whole lot worse.
> Bla bla bla... Just tell how frequenty do I have to tell the world,
> that the read_ahead array is a write only variable inside the kernel
> and therefore not used at all?????!!!!!!!!!!
tell Jens. He goes about fixing it all, not just the most visible pieces
that showed how much the Linux block IO code sucked. And guess what? His
patches are being accepted, and the Linux 2.5 block IO code is evolving
rapidly. Sometimes keeping broken code around as an incentive to fix it
*for real* is better than trying to massage the broken code somewhat.
a patch penguin doesnt solve this particular problem, by definition he
just wont fix the block IO code.
any other 'examples'?
Ingo
Alan Cox
> more than once that a big part of his job is to limit change. Maybe
> he's happy with the current rate of change in 2.5. (That doesn't
> mean everything is optimal--he might wish for higher quality changes
> or a different mix of changes, just not more.)
Progress happens at its own rate. Linus can no more control rate of change
than you can put a waterfall into low gear. There is a difference between
refusing stuff where the quality is low and losing stuff which is clear
fixes
> Two, Linus has argued that maintainers are his patch penguins;
> whereas you favor a single integration point between the maintainers
> and Linus. This has advantages and disadvantages, but on the whole,
> I think it is better if Linus works directly with subsystem
Perl I think very much shows otherwise. Right now we have a maze of partially
integrated trees which overlap, clash when the people send stuff to Linus and
worse.
When you have one or two integrators you have a single tree pretty much everyone
builds new stuff from and which people maintain small diffs relative to. At
the end of the day that ends up like the older -ac tree, and with the same
conditions - notably that anything in it might be going to see /dev/null not
Linus if its shown to be flawed or not done well.
Alan
Ingo Molnar
On Tue, 29 Jan 2002, Daniel Phillips wrote:
> [...] Consider my patch to fix group descriptor corruption in Ext2,
> submitted half a dozen times to Linus and other maintainers over the
> course of two years, which was clearly explained, passed scrutiny on
> ext2-devel and lkml, fixed a real problem that really bit people and
> which I'd been running myself over the entire period. Which one of
> cleanliness, concept, timing or testing did I violate?
>
> If the answer is 'none of the above', then what is wrong with this
> picture?
am i correct that you are referring to this patch?:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0011.3/0861.html
was this the first iteration of your patch? Your mail is a little more
than 1 year old. You rated the patch as: 'The fix below is kind of
gross.'. Clearly, this does not help getting patches applied.
the ext2 bh-handling code had cleanliness issues before. I had ext2
patches rejected by Linus because they kept the method of passing around
double-pointers, and i have to agree that the code was far from clean. Al
did lots of cleanups in this area, and i think he fixed this issue as
well, didnt he? So where is the problem exactly, does 2.4 still have this
bug?
in terms of 2.2 and 2.0, you should contact the respective maintainers.
Ingo
Alan Cox
> *for real* is better than trying to massage the broken code somewhat.
>
> a patch penguin doesnt solve this particular problem, by definition he
> just wont fix the block IO code.
Ingo, you should have a look at my mailbox and the people sick of trying to
get Linus to take 3 liners to fix NODEV type stuff and being ignored so that
2.5.* still doesn't even compile or boot for many people.
Dave in doing the patch hoovering at least ensures these are picked up. You
think if this carries on anyone will be running Linus tree in 9 months ?
Ingo Molnar
On Tue, 29 Jan 2002, Martin Dalecki wrote:
> >Now, look at how humans work. I don't know _anybody_ who works with
> >hundreds of people. You work with 5-10 people, out of a pool of maybe
> >30-50 people. Agreed?
> >
> Not at all. Please have a look at the ARMY. (A tightly hierarchical
> system...)
a general wont work with hundreds of people *directly*.
and i doubt 'giving orders' qualifies as 'works with'. 'Works with' is the
close circle around the general whom he talks to about current issues and
whose advice he listens to.
Ingo
Alan Cox
> the patch should first think really hard about the following 4 issues:
Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4 liners.
The big stuff is not the problem most times. That stuff does get ripped to
shreds and picked over as is needed. (Except device drivers, Linus alas has
absolutely no taste in device drivers 8))
People collecting up patches _does_ help big time for all the small fixes.
Especially ones disciplined enough to keep the originals they applied so
they can feed stuff on with that tag. If I sent Linus on a patch that said
"You've missed this fix by Andrew Morton" then Linus knew it was probably
right for example.
> it. Start small, because for small patches people will have the few
Start small and your obvious one line diff, or 3 line typo fix will be
ignored for a decade. There were critical fixes that Linus dropped
repeatedly between 2.4.2 and 2.4.16 or so which ended up being holes in every
non-ac based distro.
Alan
Christoph Hellwig
In article <3C568C52...@evision-ventures.com> you wrote:
>>One "patch penguin" scales no better than I do. In fact, I will claim
>>that most of them scale a whole lot worse.
>>
> Bla bla bla... Just tell how frequenty do I have to tell the world, that
> the read_ahead array is a write
> only variable inside the kernel and therefore not used at
> all?????!!!!!!!!!!
It IS used. (hint: take a look at fs/hfs/file.c).
I still don't think maintainig this array is worth just for hfs
readahead, so the below patch disables it and gets rid of read_ahead.
Jens, could you check the patch and include it in your next batch of
block-layer changes for Linus?
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/acorn/block/mfmhd.c linux/drivers/acorn/block/mfmhd.c
--- ../master/linux-2.5.3-pre6/drivers/acorn/block/mfmhd.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/acorn/block/mfmhd.c Tue Jan 29 14:07:41 2002
@@ -1442,7 +1442,6 @@
hdc63463_irqpollmask = irqmask;
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB?) read ahread */
add_gendisk(&mfm_gendisk);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/DAC960.c linux/drivers/block/DAC960.c
--- ../master/linux-2.5.3-pre6/drivers/block/DAC960.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/DAC960.c Tue Jan 29 13:57:06 2002
@@ -1964,10 +1964,6 @@
Controller->GenericDiskInfo.sizes = Controller->PartitionSizes;
blksize_size[MajorNumber] = Controller->BlockSizes;
/*
- Initialize Read Ahead to 128 sectors.
- */
- read_ahead[MajorNumber] = 128;
- /*
Complete initialization of the Generic Disk Information structure.
*/
Controller->GenericDiskInfo.major = MajorNumber;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/acsi.c linux/drivers/block/acsi.c
--- ../master/linux-2.5.3-pre6/drivers/block/acsi.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/acsi.c Tue Jan 29 13:57:19 2002
@@ -1785,7 +1785,6 @@
STramMask = ATARIHW_PRESENT(EXTD_DMA) ? 0x00000000 : 0xff000000;
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &acsi_lock);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read-ahead */
add_gendisk(&acsi_gendisk);
#ifdef CONFIG_ATARI_SLM
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/blkpg.c linux/drivers/block/blkpg.c
--- ../master/linux-2.5.3-pre6/drivers/block/blkpg.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/blkpg.c Tue Jan 29 13:58:51 2002
@@ -227,18 +227,6 @@
intval = (is_read_only(dev) != 0);
return put_user(intval, (int *)(arg));
- case BLKRASET:
- if(!capable(CAP_SYS_ADMIN))
- return -EACCES;
- if(arg > 0xff)
- return -EINVAL;
- read_ahead[major(dev)] = arg;
- return 0;
- case BLKRAGET:
- if (!arg)
- return -EINVAL;
- return put_user(read_ahead[major(dev)], (long *) arg);
-
case BLKFRASET:
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -319,6 +307,9 @@
set_blocksize(dev, intval);
return 0;
+ case BLKRASET:
+ case BLKRAGET:
+ /* this information is no more used by the kernel */
default:
return -EINVAL;
}
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/cciss.c linux/drivers/block/cciss.c
--- ../master/linux-2.5.3-pre6/drivers/block/cciss.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/block/cciss.c Tue Jan 29 13:59:03 2002
@@ -2542,7 +2542,6 @@
/* fill in the other Kernel structs */
blksize_size[MAJOR_NR+i] = hba[i]->blocksizes;
- read_ahead[MAJOR_NR+i] = READ_AHEAD;
/* Fill in the gendisk data */
hba[i]->gendisk.major = MAJOR_NR + i;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/cpqarray.c linux/drivers/block/cpqarray.c
--- ../master/linux-2.5.3-pre6/drivers/block/cpqarray.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/cpqarray.c Tue Jan 29 13:59:14 2002
@@ -481,7 +481,6 @@
blk_queue_max_phys_segments(q, SG_MAX);
blksize_size[MAJOR_NR+i] = ida_blocksizes + (i*256);
- read_ahead[MAJOR_NR+i] = READ_AHEAD;
ida_gendisk[i].major = MAJOR_NR + i;
ida_gendisk[i].major_name = "ida";
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
--- ../master/linux-2.5.3-pre6/drivers/block/ll_rw_blk.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/block/ll_rw_blk.c Tue Jan 29 13:59:28 2002
@@ -54,10 +54,6 @@
*/
DECLARE_TASK_QUEUE(tq_disk);
-/* This specifies how many sectors to read ahead on the disk. */
-
-int read_ahead[MAX_BLKDEV];
-
/* blk_dev_struct is:
* request_queue
* *queue
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/paride/pcd.c linux/drivers/block/paride/pcd.c
--- ../master/linux-2.5.3-pre6/drivers/block/paride/pcd.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/paride/pcd.c Tue Jan 29 14:00:33 2002
@@ -358,7 +358,6 @@
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &pcd_lock);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
for (i=0;i<PCD_UNITS;i++) pcd_blocksizes[i] = 1024;
blksize_size[MAJOR_NR] = pcd_blocksizes;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/paride/pd.c linux/drivers/block/paride/pd.c
--- ../master/linux-2.5.3-pre6/drivers/block/paride/pd.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/paride/pd.c Tue Jan 29 14:00:41 2002
@@ -397,7 +397,6 @@
q = BLK_DEFAULT_QUEUE(MAJOR_NR);
blk_init_queue(q, DEVICE_REQUEST, &pd_lock);
blk_queue_max_sectors(q, cluster);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
pd_gendisk.major = major;
pd_gendisk.major_name = name;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/paride/pf.c linux/drivers/block/paride/pf.c
--- ../master/linux-2.5.3-pre6/drivers/block/paride/pf.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/block/paride/pf.c Tue Jan 29 14:00:23 2002
@@ -363,7 +363,6 @@
blk_init_queue(q, DEVICE_REQUEST, &pf_spin_lock);
blk_queue_max_phys_segments(q, cluster);
blk_queue_max_hw_segments(q, cluster);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
for (i=0;i<PF_UNITS;i++) pf_blocksizes[i] = 1024;
blksize_size[MAJOR_NR] = pf_blocksizes;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/ps2esdi.c linux/drivers/block/ps2esdi.c
--- ../master/linux-2.5.3-pre6/drivers/block/ps2esdi.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/block/ps2esdi.c Tue Jan 29 14:00:11 2002
@@ -177,8 +177,6 @@
}
/* set up some global information - indicating device specific info */
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &ps2esdi_lock);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
-
/* some minor housekeeping - setup the global gendisk structure */
add_gendisk(&ps2esdi_gendisk);
ps2esdi_geninit();
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/block/xd.c linux/drivers/block/xd.c
--- ../master/linux-2.5.3-pre6/drivers/block/xd.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/block/xd.c Tue Jan 29 13:59:39 2002
@@ -171,7 +171,6 @@
}
devfs_handle = devfs_mk_dir (NULL, xd_gendisk.major_name, NULL);
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &xd_lock);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read ahead */
add_gendisk(&xd_gendisk);
xd_geninit();
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/aztcd.c linux/drivers/cdrom/aztcd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/aztcd.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/cdrom/aztcd.c Tue Jan 29 14:05:15 2002
@@ -1927,7 +1927,6 @@
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &aztSpin);
blksize_size[MAJOR_NR] = aztcd_blocksizes;
- read_ahead[MAJOR_NR] = 4;
register_disk(NULL, mk_kdev(MAJOR_NR, 0), 1, &azt_fops, 0);
if ((azt_port == 0x1f0) || (azt_port == 0x170))
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/cdu31a.c linux/drivers/cdrom/cdu31a.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/cdu31a.c Tue Jan 15 10:59:05 2002
+++ linux/drivers/cdrom/cdu31a.c Tue Jan 29 14:05:21 2002
@@ -3442,7 +3442,6 @@
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR),
DEVICE_REQUEST,
&cdu31a_lock);
- read_ahead[MAJOR_NR] = CDU31A_READAHEAD;
cdu31a_block_size = 1024; /* 1kB default block size */
/* use 'mount -o block=2048' */
blksize_size[MAJOR_NR] = &cdu31a_block_size;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/cm206.c linux/drivers/cdrom/cm206.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/cm206.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/cm206.c Tue Jan 29 14:05:43 2002
@@ -1503,7 +1503,6 @@
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST,
&cm206_lock);
blksize_size[MAJOR_NR] = cm206_blocksizes;
- read_ahead[MAJOR_NR] = 16; /* reads ahead what? */
init_bh(CM206_BH, cm206_bh);
memset(cd, 0, sizeof(*cd)); /* give'm some reasonable value */
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/gscd.c linux/drivers/cdrom/gscd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/gscd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/gscd.c Tue Jan 29 14:05:50 2002
@@ -1022,7 +1022,6 @@
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &gscd_lock);
blksize_size[MAJOR_NR] = gscd_blocksizes;
- read_ahead[MAJOR_NR] = 4;
disk_state = 0;
gscdPresent = 1;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/mcd.c linux/drivers/cdrom/mcd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/mcd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/mcd.c Tue Jan 29 14:05:56 2002
@@ -1075,7 +1075,6 @@
blksize_size[MAJOR_NR] = mcd_blocksizes;
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST,
&mcd_spinlock);
- read_ahead[MAJOR_NR] = 4;
/* check for card */
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/mcdx.c linux/drivers/cdrom/mcdx.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/mcdx.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/mcdx.c Tue Jan 29 14:06:01 2002
@@ -1184,7 +1184,6 @@
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST,
&mcdx_lock);
- read_ahead[MAJOR_NR] = READ_AHEAD;
blksize_size[MAJOR_NR] = mcdx_blocksizes;
xtrace(INIT, "init() subscribe irq and i/o\n");
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/optcd.c linux/drivers/cdrom/optcd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/optcd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/optcd.c Tue Jan 29 14:06:06 2002
@@ -2062,7 +2062,6 @@
blksize_size[MAJOR_NR] = &blksize;
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST,
&optcd_lock);
- read_ahead[MAJOR_NR] = 4;
request_region(optcd_port, 4, "optcd");
register_disk(NULL, mk_kdev(MAJOR_NR,0), 1, &opt_fops, 0);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/sbpcd.c linux/drivers/cdrom/sbpcd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/sbpcd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/sbpcd.c Tue Jan 29 14:07:22 2002
@@ -4532,11 +4532,7 @@
} /* end of CDROMREADAUDIO */
case BLKRASET:
- if(!capable(CAP_SYS_ADMIN)) RETURN_UP(-EACCES);
- if(kdev_none(cdi->dev)) RETURN_UP(-EINVAL);
- if(arg > 0xff) RETURN_UP(-EINVAL);
- read_ahead[major(cdi->dev)] = arg;
- RETURN_UP(0);
+ return -EINVAL;
default:
msg(DBG_IOC,"ioctl: unknown function request %04X\n", cmd);
RETURN_UP(-EINVAL);
@@ -5870,7 +5866,6 @@
(BLK_DEFAULT_QUEUE(MAJOR_NR))->front_merge_fn = dont_bh_merge_fn;
(BLK_DEFAULT_QUEUE(MAJOR_NR))->merge_requests_fn = dont_merge_requests_fn;
#endif
- read_ahead[MAJOR_NR] = buffers * (CD_FRAMESIZE / 512);
request_region(CDo_command,4,major_name);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/sjcd.c linux/drivers/cdrom/sjcd.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/sjcd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/sjcd.c Tue Jan 29 14:06:10 2002
@@ -1695,7 +1695,6 @@
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST,&sjcd_lock);
- read_ahead[MAJOR_NR] = 4;
register_disk(NULL, mk_kdev(MAJOR_NR, 0), 1, &sjcd_fops, 0);
if (check_region(sjcd_base, 4)) {
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/cdrom/sonycd535.c linux/drivers/cdrom/sonycd535.c
--- ../master/linux-2.5.3-pre6/drivers/cdrom/sonycd535.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/cdrom/sonycd535.c Tue Jan 29 14:06:16 2002
@@ -1598,7 +1598,6 @@
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &sonycd535_lock);
blksize_size[MAJOR_NR] = &sonycd535_block_size;
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read-ahead */
sony_toc = (struct s535_sony_toc *)
kmalloc(sizeof *sony_toc, GFP_KERNEL);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/ide/hd.c linux/drivers/ide/hd.c
--- ../master/linux-2.5.3-pre6/drivers/ide/hd.c Tue Jan 15 10:59:06 2002
+++ linux/drivers/ide/hd.c Tue Jan 29 14:04:07 2002
@@ -837,7 +837,6 @@
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST, &hd_lock);
blk_queue_max_sectors(BLK_DEFAULT_QUEUE(MAJOR_NR), 255);
- read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read-ahead */
add_gendisk(&hd_gendisk);
init_timer(&device_timer);
device_timer.function = hd_times_out;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/ide/ide-cd.c linux/drivers/ide/ide-cd.c
--- ../master/linux-2.5.3-pre6/drivers/ide/ide-cd.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/ide/ide-cd.c Tue Jan 29 14:04:51 2002
@@ -2662,7 +2662,6 @@
int major = HWIF(drive)->major;
int minor = drive->select.b.unit << PARTN_BITS;
- ide_add_setting(drive, "breada_readahead", SETTING_RW, BLKRAGET, BLKRASET, TYPE_INT, 0, 255, 1, 2, &read_ahead[major], NULL);
ide_add_setting(drive, "file_readahead", SETTING_RW, BLKFRAGET, BLKFRASET, TYPE_INTA, 0, INT_MAX, 1, 1024, &max_readahead[major][minor], NULL);
ide_add_setting(drive, "dsc_overlap", SETTING_RW, -1, -1, TYPE_BYTE, 0, 1, 1, 1, &drive->dsc_overlap, NULL);
}
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
--- ../master/linux-2.5.3-pre6/drivers/ide/ide-disk.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/ide/ide-disk.c Tue Jan 29 14:04:45 2002
@@ -931,7 +931,6 @@
ide_add_setting(drive, "bswap", SETTING_READ, -1, -1, TYPE_BYTE, 0, 1, 1, 1, &drive->bswap, NULL);
ide_add_setting(drive, "multcount", id ? SETTING_RW : SETTING_READ, HDIO_GET_MULTCOUNT, HDIO_SET_MULTCOUNT, TYPE_BYTE, 0, id ? id->max_multsect : 0, 1, 1, &drive->mult_count, set_multcount);
ide_add_setting(drive, "nowerr", SETTING_RW, HDIO_GET_NOWERR, HDIO_SET_NOWERR, TYPE_BYTE, 0, 1, 1, 1, &drive->nowerr, set_nowerr);
- ide_add_setting(drive, "breada_readahead", SETTING_RW, BLKRAGET, BLKRASET, TYPE_INT, 0, 255, 1, 1, &read_ahead[major], NULL);
ide_add_setting(drive, "file_readahead", SETTING_RW, BLKFRAGET, BLKFRASET, TYPE_INTA, 0, 4096, PAGE_SIZE, 1024, &max_readahead[major][minor], NULL);
ide_add_setting(drive, "lun", SETTING_RW, -1, -1, TYPE_INT, 0, 7, 1, 1, &drive->lun, NULL);
ide_add_setting(drive, "wcache", SETTING_RW, HDIO_GET_WCACHE, HDIO_SET_WCACHE, TYPE_BYTE, 0, 1, 1, 1, &drive->wcache, write_cache);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/ide/ide-floppy.c linux/drivers/ide/ide-floppy.c
--- ../master/linux-2.5.3-pre6/drivers/ide/ide-floppy.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/ide/ide-floppy.c Tue Jan 29 14:04:40 2002
@@ -1968,7 +1968,6 @@
ide_add_setting(drive, "bios_cyl", SETTING_RW, -1, -1, TYPE_INT, 0, 1023, 1, 1, &drive->bios_cyl, NULL);
ide_add_setting(drive, "bios_head", SETTING_RW, -1, -1, TYPE_BYTE, 0, 255, 1, 1, &drive->bios_head, NULL);
ide_add_setting(drive, "bios_sect", SETTING_RW, -1, -1, TYPE_BYTE, 0, 63, 1, 1, &drive->bios_sect, NULL);
- ide_add_setting(drive, "breada_readahead", SETTING_RW, BLKRAGET, BLKRASET, TYPE_INT, 0, 255, 1, 2, &read_ahead[major], NULL);
ide_add_setting(drive, "file_readahead", SETTING_RW, BLKFRAGET, BLKFRASET, TYPE_INTA, 0, INT_MAX, 1, 1024, &max_readahead[major][minor], NULL);
}
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/ide/ide-probe.c linux/drivers/ide/ide-probe.c
--- ../master/linux-2.5.3-pre6/drivers/ide/ide-probe.c Tue Jan 29 11:24:20 2002
+++ linux/drivers/ide/ide-probe.c Tue Jan 29 14:04:22 2002
@@ -937,7 +937,6 @@
init_gendisk(hwif);
blk_dev[hwif->major].data = hwif;
blk_dev[hwif->major].queue = ide_get_queue;
- read_ahead[hwif->major] = 8; /* (4kB) */
hwif->present = 1; /* success */
return hwif->present;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/md/md.c linux/drivers/md/md.c
--- ../master/linux-2.5.3-pre6/drivers/md/md.c Tue Jan 29 11:24:21 2002
+++ linux/drivers/md/md.c Tue Jan 29 13:56:35 2002
@@ -1737,7 +1737,6 @@
register_disk(&md_gendisk, mk_kdev(MAJOR_NR,mdidx(mddev)),
1, &md_fops, md_size[mdidx(mddev)]<<1);
- read_ahead[MD_MAJOR] = 1024;
return (0);
}
@@ -3177,11 +3176,7 @@
sz += sprintf(page+sz, "\n");
- sz += sprintf(page+sz, "read_ahead ");
- if (read_ahead[MD_MAJOR] == INT_MAX)
- sz += sprintf(page+sz, "not set\n");
- else
- sz += sprintf(page+sz, "%d sectors\n", read_ahead[MD_MAJOR]);
+ sz += sprintf(page+sz, "read_ahead not set\n");
ITERATE_MDDEV(mddev,tmp) {
sz += sprintf(page + sz, "md%d : %sactive", mdidx(mddev),
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/s390/block/xpram.c linux/drivers/s390/block/xpram.c
--- ../master/linux-2.5.3-pre6/drivers/s390/block/xpram.c Tue Jan 15 10:59:08 2002
+++ linux/drivers/s390/block/xpram.c Tue Jan 29 14:02:25 2002
@@ -163,12 +163,11 @@
static int major = XPRAM_MAJOR;
static int devs = XPRAM_DEVS;
-static int rahead = XPRAM_RAHEAD;
static int sizes[XPRAM_MAX_DEVS] = { 0, };
static int blksize = XPRAM_BLKSIZE;
static int hardsect = XPRAM_HARDSECT;
-int xpram_devs, xpram_rahead;
+int xpram_devs;
int xpram_blksize, xpram_hardsect;
int xpram_mem_avail = 0;
unsigned long xpram_sizes[XPRAM_MAX_DEVS];
@@ -660,21 +659,7 @@
return 0;
case BLKRAGET: /* return the readahead value, 0x1263 */
- if (!arg) return -EINVAL;
- err = 0; /* verify_area_20(VERIFY_WRITE, (long *) arg, sizeof(long));
- * if (err) return err;
- */
- put_user(read_ahead[MAJOR(inode->i_rdev)], (long *)arg);
-
- return 0;
-
case BLKRASET: /* set the readahead value, 0x1262 */
- if (!capable(CAP_SYS_ADMIN)) return -EACCES;
- if (arg > 0xff) return -EINVAL; /* limit it */
- read_ahead[MAJOR(inode->i_rdev)] = arg;
- atomic_eieio();
- return 0;
-
case BLKRRPART: /* re-read partition table: can't do it, 0x1259 */
return -EINVAL;
@@ -685,7 +670,6 @@
* BLKROGET
*/
#endif /* V22 */
-
case HDIO_GETGEO:
/*
* get geometry: we have to fake one... trim the size to a
@@ -940,7 +924,6 @@
* snoozing with a debugger.
*/
- xpram_rahead = rahead;
xpram_blksize = blksize;
xpram_hardsect = hardsect;
@@ -1029,7 +1012,7 @@
PRINT_INFO(" %d kB expanded memory found.\n",xpram_mem_avail );
/*
- * Assign the other needed values: request, rahead, size, blksize,
+ * Assign the other needed values: request, size, blksize,
* hardsect. All the minor devices feature the same value.
* Note that `xpram' defines all of them to allow testing non-default
* values. A real device could well avoid setting values in global
@@ -1042,7 +1025,6 @@
q = BLK_DEFAULT_QUEUE (major);
blk_init_queue (q, xpram_request);
#endif /* V22/V24 */
- read_ahead[major] = xpram_rahead;
/* we want to have XPRAM_UNUSED blocks security buffer between devices */
mem_usable=xpram_mem_avail-(XPRAM_UNUSED*(xpram_devs-1));
@@ -1181,7 +1163,6 @@
kfree(xpram_hardsects);
hardsect_size[major] = NULL;
fail_malloc:
- read_ahead[major] = 0;
#if (XPRAM_VERSION == 22)
blk_dev[major].request_fn = NULL;
#endif /* V22 */
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/s390/char/tapeblock.c linux/drivers/s390/char/tapeblock.c
--- ../master/linux-2.5.3-pre6/drivers/s390/char/tapeblock.c Sat Dec 22 20:06:57 2001
+++ linux/drivers/s390/char/tapeblock.c Tue Jan 29 14:02:34 2002
@@ -101,7 +101,6 @@
}
if (tapeblock_major == 0) tapeblock_major = result; /* accept dynamic major number*/
INIT_BLK_DEV(tapeblock_major,tape_request_fn,tapeblock_getqueue,NULL);
- read_ahead[tapeblock_major]=TAPEBLOCK_READAHEAD;
PRINT_WARN(KERN_ERR " tape gets major %d for block device\n", result);
blk_size[tapeblock_major] = (int*) kmalloc (256*sizeof(int),GFP_ATOMIC);
memset(blk_size[tapeblock_major],0,256*sizeof(int));
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/scsi/sd.c linux/drivers/scsi/sd.c
--- ../master/linux-2.5.3-pre6/drivers/scsi/sd.c Tue Jan 15 10:59:09 2002
+++ linux/drivers/scsi/sd.c Tue Jan 29 14:03:01 2002
@@ -1179,7 +1179,7 @@
add_gendisk(&(sd_gendisks[i]));
}
- for (i = 0; i < sd_template.dev_max; ++i)
+ for (i = 0; i < sd_template.dev_max; ++i) {
if (!rscsi_disks[i].capacity && rscsi_disks[i].device) {
sd_init_onedisk(i);
if (!rscsi_disks[i].has_part_table) {
@@ -1190,17 +1190,6 @@
rscsi_disks[i].has_part_table = 1;
}
}
- /* If our host adapter is capable of scatter-gather, then we increase
- * the read-ahead to 60 blocks (120 sectors). If not, we use
- * a two block (4 sector) read ahead. We can only respect this with the
- * granularity of every 16 disks (one device major).
- */
- for (i = 0; i < N_USED_SD_MAJORS; i++) {
- read_ahead[SD_MAJOR(i)] =
- (rscsi_disks[i * SCSI_DISKS_PER_MAJOR].device
- && rscsi_disks[i * SCSI_DISKS_PER_MAJOR].device->host->sg_tablesize)
- ? 120 /* 120 sector read-ahead */
- : 4; /* 4 sector read-ahead */
}
return;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- ../master/linux-2.5.3-pre6/drivers/scsi/sr.c Tue Jan 29 11:24:22 2002
+++ linux/drivers/scsi/sr.c Tue Jan 29 14:03:53 2002
@@ -785,16 +785,6 @@
&sr_bdops, NULL);
register_cdrom(&scsi_CDs[i].cdi);
}
-
-
- /* If our host adapter is capable of scatter-gather, then we increase
- * the read-ahead to 16 blocks (32 sectors). If not, we use
- * a two block (4 sector) read ahead. */
- if (scsi_CDs[0].device && scsi_CDs[0].device->host->sg_tablesize)
- read_ahead[MAJOR_NR] = 32; /* 32 sector read-ahead. Always removable. */
- else
- read_ahead[MAJOR_NR] = 4; /* 4 sector read-ahead */
-
}
static void sr_detach(Scsi_Device * SDp)
@@ -846,7 +836,6 @@
kfree(sr_blocksizes);
sr_blocksizes = NULL;
}
- read_ahead[MAJOR_NR] = 0;
blk_clear(MAJOR_NR);
sr_template.dev_max = 0;
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/fs/hfs/file.c linux/fs/hfs/file.c
--- ../master/linux-2.5.3-pre6/fs/hfs/file.c Tue Jan 15 10:59:13 2002
+++ linux/fs/hfs/file.c Tue Jan 29 14:09:18 2002
@@ -309,6 +309,7 @@
blocks = (count+offset+HFS_SECTOR_SIZE-1) >> HFS_SECTOR_SIZE_BITS;
bhb = bhe = buflist;
+#if 0 /* for readahead we have the pagecache.. --hch */
if (reada) {
if (blocks < read_ahead[major(dev)] / (HFS_SECTOR_SIZE>>9)) {
blocks = read_ahead[major(dev)] / (HFS_SECTOR_SIZE>>9);
@@ -317,6 +318,7 @@
blocks = size - block;
}
}
+#endif
/* We do this in a two stage process. We first try and
request as many blocks as we can, then we wait for the
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/include/linux/blkdev.h linux/include/linux/blkdev.h
--- ../master/linux-2.5.3-pre6/include/linux/blkdev.h Tue Jan 29 11:24:24 2002
+++ linux/include/linux/blkdev.h Tue Jan 29 13:54:49 2002
@@ -341,7 +341,6 @@
#endif
blksize_size[major] = NULL;
max_readahead[major] = NULL;
- read_ahead[major] = 0;
}
extern inline int get_hardsect_size(kdev_t dev)
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/include/linux/fs.h linux/include/linux/fs.h
--- ../master/linux-2.5.3-pre6/include/linux/fs.h Tue Jan 29 11:24:24 2002
+++ linux/include/linux/fs.h Tue Jan 29 13:54:36 2002
@@ -1484,7 +1484,6 @@
extern ssize_t char_read(struct file *, char *, size_t, loff_t *);
extern ssize_t block_read(struct file *, char *, size_t, loff_t *);
-extern int read_ahead[];
extern ssize_t char_write(struct file *, const char *, size_t, loff_t *);
extern ssize_t block_write(struct file *, const char *, size_t, loff_t *);
diff -uNr -Xdontdiff ../master/linux-2.5.3-pre6/kernel/ksyms.c linux/kernel/ksyms.c
--- ../master/linux-2.5.3-pre6/kernel/ksyms.c Tue Jan 29 11:24:24 2002
+++ linux/kernel/ksyms.c Tue Jan 29 13:54:15 2002
@@ -509,7 +509,6 @@
EXPORT_SYMBOL(clear_inode);
EXPORT_SYMBOL(___strtok);
EXPORT_SYMBOL(init_special_inode);
-EXPORT_SYMBOL(read_ahead);
EXPORT_SYMBOL(__get_hash_table);
EXPORT_SYMBOL(new_inode);
EXPORT_SYMBOL(insert_inode_hash);
Ingo Molnar
On Tue, 29 Jan 2002, Alan Cox wrote:
> Ingo, you should have a look at my mailbox and the people sick of
> trying to get Linus to take 3 liners to fix NODEV type stuff and being
> ignored so that 2.5.* still doesn't even compile or boot for many
> people.
for code areas where there is not active maintainer or the maintainer has
ignored patches? Eg. the majority of the kdev transition patches went in
smoothly.
but i'm not claiming that everything is rosy (i would post patches if
everything was rosy in Linux-land), but i disagree with the majority of
serious examples i've seen cited.
> Dave in doing the patch hoovering at least ensures these are picked
> up. You think if this carries on anyone will be running Linus tree in
> 9 months ?
Dave and you doing patch hoovering is indeed very good. One reason is that
it multithreads the introduction of more risky stuff (by splitting up the
testing effort), and builds up confidence in more complex patches. This is
especially important in the stable cycle - eg. it happened not once that
had eg. some APIC cleanup that was too risky to be added to the stable
branch, and which went into your branch and lived a few iterations (got a
few bugreports) and then went to Linus.
Obviously you wont apply all the complex patches at once - i remember that
occasionally you delayed certain patches of mine because something else
was happening in your tree at that monent. You are simply doing
*different* transitions, but you are constrained by the same basic limits
as Linus' tree is.
Another reason is that you do much more housekeeping in areas that are not
actively maintained. But wouldnt it be better if there were active
maintainers in those areas as well so you could spend more time on eg.
doing the kernel-stack coloring changes?
but i truly believe that for the hard issues there is no solution, and
that most of the patch rejects are due to hard issues.
Ingo
Eric W. Biederman
> Now, if you've read this far, and you agree with these issues, I suspect
> you know the solution as well as I do. It's the setup I already mentioned:
> a network of maintainers, each of whom knows other maintainers.
>
> And there's overlap. I'm not talking about a hierarchy here: it's not the
> "general at the top" kind of tree-like setup. The network driver people
> are in the same general vicinity as the people doing network protocols,
> and there is obviously a lot of overlap.
So the kernel maintainership becomes a network of maintainers. Then
we only have to understand the routing protocols. Currently the
routing tables appear to have Linus as the default route. As there
are currently kernel subsystems that do not have a real maintainer, it
may reasonable to have a misc maintainer. Who looks after the
orphaned code, rejects/ignores patches for code that does have
active maintainers, and looks for people to be maintainers of the
orphaned code.
The key is having enough human to human protocol that there is someone
besides Linus you can send your code to. Or at least when there isn't
people are looking for someone.
Free Software obtains a lot of it's value by many people scratching an
itch and fixing a little bug, or adding a little feature, sending the
code off and then they go off to something else. We need to have the
maintainer routing protocol clear enough, and the maintainer coverage
good enough so we can accumulate most of the bug fixes from the fly by
night hackers.
So does anyone have any good ideas about how to build up routing
tables? And almost more importantly how to make certain we have good
maintainer coverage over the entire kernel?
Eric
Alan Cox
> ignored patches? Eg. the majority of the kdev transition patches went in
> smoothly.
No you merely aren't watching. Most of the maintainers btw are ignoring 2.5
if you do some asking. And a measurable number of the listed maintainer
addresses just bounce.
> Another reason is that you do much more housekeeping in areas that are not
> actively maintained. But wouldnt it be better if there were active
> maintainers in those areas as well so you could spend more time on eg.
> doing the kernel-stack coloring changes?
There never will be maintainers proper for large amounts of stuff, and the
longer Linus deletes and ignores everything from someone new the less people
will bother sending to him. Just look at the size of the diff set between all
the vendor kernels and Linus 2.4.x trees before the giant -ac merge.
Think gcc, think egcs. History is merely beginning to repeat itself
Alan
Alan Cox
> readahead, so the below patch disables it and gets rid of read_ahead.
>
> Jens, could you check the patch and include it in your next batch of
> block-layer changes for Linus?
What would be significantly more useful would be to make it actually work.
Lots of drivers benefit from control over readahead sizes - both the
stunningly slow low end stuff and the high end raid cards that often want
to get hit by very large I/O requests (eg 128K for the ami megaraid)
Alan
Ingo Molnar
On Tue, 29 Jan 2002, Alan Cox wrote:
> The big stuff is not the problem most times. [...]
oh, i agree, but still the big stuff is that gets quoted in most emails
that try to invent the next big patch submission method ...
> People collecting up patches _does_ help big time for all the small
> fixes.
yes. This started with you and multiple people do it currently.
> Especially ones disciplined enough to keep the originals they applied
> so they can feed stuff on with that tag. If I sent Linus on a patch
> that said "You've missed this fix by Andrew Morton" then Linus knew it
> was probably right for example.
yes. This is what maintainers do. You, when collecting patches for the -ac
tree, are in essence a trusted jolly joker maintainer, very disciplined to
filter the trivial stuff from the nontrivial stuff.
> Start small and your obvious one line diff, or 3 line typo fix will be
> ignored for a decade. There were critical fixes that Linus dropped
> repeatedly between 2.4.2 and 2.4.16 or so which ended up being holes
> in every non-ac based distro.
(while i still do not claim that things are perfect, i'd like to see
specific examples nevertheless.)
Ingo
Momchil Velikov
Eric> So does anyone have any good ideas about how to build up routing
Eric> tables?
Umm, broadcasting to lkml ?:)
Dave Jones
>
> No you merely aren't watching. Most of the maintainers btw are ignoring 2.5
> if you do some asking. And a measurable number of the listed maintainer
> addresses just bounce.
I believe a while back someone was going to send a ping to all
the listed addresses in MAINTAINERS. Doing this again may not
be a bad idea.
> There never will be maintainers proper for large amounts of stuff, and the
> longer Linus deletes and ignores everything from someone new the less people
> will bother sending to him. Just look at the size of the diff set between all
> the vendor kernels and Linus 2.4.x trees before the giant -ac merge.
Now that we have an open development branch again, perhaps its
time for a lot of the things that have been proven stable in vendor
kernels for a long time to get a looksee in mainline.
Some things I feel will likely still be vendor-kernel only for some time.
And some of them, rightly so.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Ingo Molnar
On Tue, 29 Jan 2002, Alan Cox wrote:
> [...] And a measurable number of the listed maintainer addresses just
> bounce.
out of the 300+ email addresses in the MAINTAINERS file, 15 addresses
bounced physically. (whether they bounce logically is another question.)
Ingo
Jeff Garzik
> I'm not proposing replacing the current subsystem maintainers. But are the
> current subsystem maintainers happy?
I think the system works, if you understand the system ;-)
Finding a maintainer for a piece of code is sometimes a jumble, but if
people want their patches in the kernel they need to be proactive about
it.
I'm -glad- Linus does not usually apply drop-n-run patches.
Jeff
Dave Jones
> > [...] And a measurable number of the listed maintainer addresses just
> > bounce.
>
> out of the 300+ email addresses in the MAINTAINERS file, 15 addresses
> bounced physically. (whether they bounce logically is another question.)
Care to remove the bogus ones from MAINTAINERS and send it to Linus/Me?
(Keep the entries, but remove the address. (Or better perhaps to mark
it 'out of order' in case of mailserver failure on $maintainers side.)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Skip Ford
Hash: SHA1
Linus Torvalds wrote:
[snip]
> A word of warning: good maintainers are hard to find. Getting more of
> them helps, but at some point it can actually be more useful to help the
> _existing_ ones. I've got about ten-twenty people I really trust, and
Then why not give the subsystem maintainers patch permissions on your tree.
Sort of like committers. The problem people have is that you're dropping
patches from those ten-twenty people you trust.
Each subsystem maintainer should handle patches to that subsystem, and
you should remove your own patch permissions for only those subsystems.
You could get involved with only changes in direction that affect more
than one subsystem.
> quite frankly, the way people work is hardcoded in our DNA. Nobody
> "really trusts" hundreds of people. The way to make these things scale
> out more is to increase the network of trust not by trying to push it on
> me, but by making it more of a _network_, not a star-topology around me.
>
> In short: don't try to come up with a "patch penguin". Instead try to
> help existing maintainers, or maybe help grow new ones. THAT is the way
> to scalability.
- --
Skip ID: 0x7EDDDB0A
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAjxWsfkACgkQBMKxVH7d2wpAfQCfRMoMirEH2/KRYMowNkZyMCBi
CEYAoM4akKt8Ifl20cvkA5UG8Kb4p9Tb
=q5bM
-----END PGP SIGNATURE-----
Ingo Molnar
On Tue, 29 Jan 2002, Dave Jones wrote:
> > out of the 300+ email addresses in the MAINTAINERS file, 15 addresses
> > bounced physically. (whether they bounce logically is another question.)
>
> Care to remove the bogus ones from MAINTAINERS
yeah, was in the process of doing that. Patch against 2.5.3-pre6 attached.
Altogether 13 addresses are affected. I have only removed the
hard-bouncing email addresses, names and list names remain (of course).
Ingo
--- linux/MAINTAINERS.orig Tue Jan 29 15:11:04 2002
+++ linux/MAINTAINERS Tue Jan 29 15:16:31 2002
@@ -154,8 +154,6 @@
AD1816 SOUND DRIVER
P: Thorsten Knabe
-M: Thorsten Knabe <t...@rbg.informatik.tu-darmstadt.de>
-M: Thorsten Knabe <te...@hrzpub.tu-darmstadt.de>
W: http://www.student.informatik.tu-darmstadt.de/~tek/projects/linux.html
W: http://www.tu-darmstadt.de/~tek01/projects/linux.html
S: Maintained
@@ -216,7 +214,6 @@
ARPD SUPPORT
P: Jonathan Layes
-M: la...@loran.com
L: linu...@vger.kernel.org
S: Maintained
@@ -235,7 +232,6 @@
BERKSHIRE PRODUCTS PC WATCHDOG DRIVER
P: Kenji Hollis
-M: ke...@bitgate.com
W: http://ftp.bitgate.com/pcwd/
S: Maintained
@@ -433,13 +429,11 @@
DIGI INTL. EPCA DRIVER
P: Chad Schwartz
M: sup...@dgii.com
-M: ch...@dgii.com
L: digi...@dgii.com
S: Maintained
DIGI RIGHTSWITCH NETWORK DRIVER
P: Rick Richardson
-M: ri...@remotepoint.com
L: linu...@vger.kernel.org
W: http://www.dgii.com/linux/
S: Maintained
@@ -485,7 +479,6 @@
DRM DRIVERS
P: Rik Faith
-M: fa...@valinux.com
L: dri-...@lists.sourceforge.net
S: Supported
@@ -497,7 +490,6 @@
EATA-DMA SCSI DRIVER
P: Michael Neuffer
-M: mi...@i-Connect.Net
L: linux...@i-connect.net, linux...@vger.kernel.org
S: Maintained
@@ -927,7 +919,6 @@
LOGICAL VOLUME MANAGER
P: Heinz Mauelshagen
-M: m...@sistina.de
L: linu...@sistina.com
W: http://www.sistina.com/lvm
S: Maintained
@@ -1134,7 +1125,6 @@
OLYMPIC NETWORK DRIVER
P: Peter De Shrijver
-M: p...@ace.ulyssis.sutdent.kuleuven.ac.be
P: Mike Phillips
M: mi...@linuxtr.net
L: linu...@vger.kernel.org
@@ -1293,7 +1283,6 @@
RISCOM8 DRIVER
P: Dmitry Gorodchanin
-M: pgm...@ibi.com
L: linux-...@vger.kernel.org
S: Maintained
@@ -1660,13 +1649,11 @@
USB SERIAL BELKIN F5U103 DRIVER
P: William Greathouse
M: wgrea...@smva.com
-M: wgrea...@myfavoritei.com
L: linux-u...@lists.sourceforge.net
L: linux-u...@lists.sourceforge.net
S: Maintained
USB SERIAL CYBERJACK PINPAD/E-COM DRIVER
-M: linu...@sii.li
L: linux-u...@lists.sourceforge.net
L: linux-u...@lists.sourceforge.net
S: Supported
@@ -1792,7 +1779,6 @@
ZF MACHZ WATCHDOG
P: Fernando Fuganti
-M: fug...@conectiva.com.br
M: fug...@netbank.com.br
W: http://cvs.conectiva.com.br/drivers/ZFL-watchdog/
S: Maintained
Russell King
> On Tue, Jan 29, 2002 at 05:15:15PM +0100, Ingo Molnar wrote:
> > out of the 300+ email addresses in the MAINTAINERS file, 15 addresses
> > bounced physically. (whether they bounce logically is another question.)
>
> Care to remove the bogus ones from MAINTAINERS and send it to Linus/Me?
> (Keep the entries, but remove the address. (Or better perhaps to mark
> it 'out of order' in case of mailserver failure on $maintainers side.)
If we're going to be doing this periodically, it might be an idea to
put "out of order since dd mmm yyyy" and a "last checked dd mmm yyyy"
at the top of the file.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Ingo Molnar
On Tue, 29 Jan 2002, Alan Cox wrote:
> A correct patch for this one giving a new maintainer was posted to
> Linux kernel already
ok.
> > DRM DRIVERS
> > P: Rik Faith
> > -M: fa...@valinux.com
> > L: dri-...@lists.sourceforge.net
> > S: Supported
>
> Rik moved from VA so I suspect you want to look in the RH internal directory
> for the correct one there 8)
*blush* :-) The correct patch is:
-M: fa...@valinux.com
+M: fa...@redhat.com
Ingo
Ingo Molnar
Patrick Mauritz noticed that this one is actually a typo in the
MAINTAINERS file:
> -M: p...@ace.ulyssis.sutdent.kuleuven.ac.be
so the correct (and existing) email address is:
-M: p...@ace.ulyssis.sutdent.kuleuven.ac.be
+M: p...@ace.ulyssis.student.ac.be
Ingo
Andrew Pimlott
> Andrew wrote:
> > Two, Linus has argued that maintainers are his patch penguins;
> > whereas you favor a single integration point between the maintainers
> > and Linus. This has advantages and disadvantages, but on the whole,
> > I think it is better if Linus works directly with subsystem
>
> Perl I think very much shows otherwise.
I'm really not sure about this example. I assume you mean Perl 5.
Last I checked, Perl didn't really operate the way Rob suggests.
There is a "patch pumpking", but he is more analogous to Linus than
to Alan. In particular, Larry Wall does not review the pumpking's
work at all (he instead sets general direction and makes key design
decisions). If Perl doesn't have the problems observed in Linux, I
think it is because 1) Perl is smaller, 2) Perl 5 is largely in
bug-fix mode, 3) Perl has a culture of accepting patches with less
scrutiny (without meaning this as a slam, I think you can see
evidence of this in the Perl 5 source base).
> When you have one or two integrators you have a single tree pretty
> much everyone builds new stuff from and which people maintain
> small diffs relative to. At the end of the day that ends up like
> the older -ac tree, and with the same conditions - notably that
> anything in it might be going to see /dev/null not Linus if its
> shown to be flawed or not done well.
There is an upper bound to the size of the delta one person can
maintain (well, assuming his goal is to sync those changes with
Linus). Unless Linus's throughput increases dramatically, the
integrator's delta will grow until it reaches that bound. At that
point, the integrator has to drop patches (or give up!). How do you
get around this?
Andrew
Alan Cox
> integrator's delta will grow until it reaches that bound. At that
> point, the integrator has to drop patches (or give up!). How do you
> get around this?
Historically at that point the old maintainer is overthrown 8) Look at
Minix versus Linux, gcc versus egcs etc
Alan Cox
A correct patch for this one giving a new maintainer was posted to Linux
kernel already
> DRM DRIVERS
> P: Rik Faith
> -M: fa...@valinux.com
> L: dri-...@lists.sourceforge.net
> S: Supported
Rik moved from VA so I suspect you want to look in the RH internal directory
for the correct one there 8)
Alan
Eli Carter
>
> On Tue, 29 Jan 2002, Dave Jones wrote:
>
> > > out of the 300+ email addresses in the MAINTAINERS file, 15 addresses
> > > bounced physically. (whether they bounce logically is another question.)
> >
> > Care to remove the bogus ones from MAINTAINERS
>
> yeah, was in the process of doing that. Patch against 2.5.3-pre6 attached.
> Altogether 13 addresses are affected. I have only removed the
> hard-bouncing email addresses, names and list names remain (of course).
>
> Ingo
Humble suggestion: Add a date field for "took over maintainence
on/before: yyyy-mm-dd" and a field for "last verified: yyyy-mm-dd" so we
know when we last checked on the existance/etc. of a maintainer. (And
maybe an "AWAL on/before: yyyy-mm-dd" for those without known working
addresses.)
Thoughts?
Ah, I see Russell King made a similar suggestion...
Eli
--------------------. Real Users find the one combination of bizarre
Eli Carter \ input values that shuts down the system for days.
eli.carter(a)inet.com `-------------------------------------------------
Eli Carter
> Patch Penguin Proposal.
Ok, I mailed Rob privately in support of this; now I'm saying it
publicly: I support this. (And I thought it well written.)
I've submitted small patches for things as I have gotten the chance. I
submitted those to Alan because they were small fixes. He gave feedback
(Thanks Alan!) and I tried to fix things better. He took care of
feeding Linus--something I'm not in a possition to do.
I believe we need a patch-penguin or something similar. Linus wants
subsystem maintainers... maybe make an official bugfix-maintainer?
Whoever it is needs to be officially recognized by Linus and probably
featured on /. or something so people who create those 3-4 line patches
that fix a bug that bit them will know not to mail Linus.
(Returning to the shadows where I belong... ;) )
Dave McCracken
--On Tuesday, January 29, 2002 13:22:05 +0000 Alan Cox
<al...@lxorguk.ukuu.org.uk> wrote:
> Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4
> liners. The big stuff is not the problem most times. That stuff does get
> ripped to shreds and picked over as is needed. (Except device drivers,
> Linus alas has absolutely no taste in device drivers 8))
>
> People collecting up patches _does_ help big time for all the small fixes.
> Especially ones disciplined enough to keep the originals they applied so
> they can feed stuff on with that tag. If I sent Linus on a patch that said
> "You've missed this fix by Andrew Morton" then Linus knew it was probably
> right for example.
I think this is a big part of the problem. What's needed, and what Alan
used to provide, is a maintainer for the miscellaneous parts of the kernel
that aren't covered by the various subsystem maintainers. We need someone
who can accept that one or two line fix, get it tested, and make sure Linus
sees it.
I gather Dave Jones is taking on that role to some extent. If so, perhaps
he should be officially listed in the MAINTAINERS file. Whether it's Dave
or someone else, I think this is a critical need.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dm...@us.ibm.com T/L 678-3059
Dana Lacoste
> posted to Linux
> kernel already
And here it is again, just in case you missed it :
ARPD SUPPORT
P: Jonathan Layes
-M: la...@loran.com
+M: dlac...@loran.com
L: linu...@vger.kernel.org
S: Maintained
+W: http://home.loran.com/~dlacoste/
Stephan von Krawczynski
Martin Dalecki <dal...@evision-ventures.com> wrote:
> Linus Torvalds wrote:
>
> >On Mon, 28 Jan 2002, Larry McVoy wrote:
> >
> >>What you didn't do, Linus, is paint a picture which allows development
> >>to scale up.
> >>
> >
> >Actually, I thought I did.
> >
> >Basic premise: development is done by humans.
> >
> >Now, look at how humans work. I don't know _anybody_ who works with
> >hundreds of people. You work with 5-10 people, out of a pool of maybe
> >30-50 people. Agreed?
> >
> Not at all. Please have a look at the ARMY. (A tightly hierarchical
> system...)
Shoot me: where the heck is the creative/innovative element inside the ARMY?
It just died somewhere down the hierarchy tree...
Ants are a very successful species, too, but they will hardly ever write
software (personal guess).
Regards,
Stephan
Linus Torvalds
On Tue, 29 Jan 2002, Skip Ford wrote:
>
> Linus Torvalds wrote:
> [snip]
> > A word of warning: good maintainers are hard to find. Getting more of
> > them helps, but at some point it can actually be more useful to help the
> > _existing_ ones. I've got about ten-twenty people I really trust, and
>
> Then why not give the subsystem maintainers patch permissions on your tree.
> Sort of like committers. The problem people have is that you're dropping
> patches from those ten-twenty people you trust.
No. Ask them, and they will (I bet) pretty uniformly tell you that I'm
_not_ dropping their patches (although I'm sometimes critical of them,
and will tell them that they do not get applied).
Sure, it happens occasionally that they really do get dropped, just
because I get too much email, but these people know how to re-send every
once in a while, and keep their patches separate.
I think there is some confusion about who I trust. Being listed as
MAINTAINER doesn't mean you are automatically trusted. The MAINTAINERS
list is not meant for me _at_all_ in fact, it's meant more as one of the
places for _others_ to search for a contact with.
Examples of people who I trust: Ingo Molnar, Jeff Garzik, Alan Cox, Al
Viro, David Miller, Greg KH, Andrew Morton etc. They've shown what I call
"good taste" for a long time. But it's not always a long process - some
of you may remember Bill Hawes, for example, who came out of nowhere
rather quickly.
There are other categories: Andrea, for example, is in a category all of
his own under "absolutely stunning, but sometimes somewhat erratic", which
just means that I have to think a lot more about his patches. I love his
experimentation, especially now that he maintains separate patches (and
I'd also love for him to be more active in pushing the non-experimental
parts towards me, hint hint, Andrea)
And there are categories of people who just own a big enough chunk that is
separate enough that I trust them for that area: architecture maintainers
etc tend to be here, as long as they only affect their own architecture.
But you have to realize that there are a _lot_ of people on the
maintainers list that I don't implicitly trust. And being loud and
wellknown on the mailing lists or IRC channels doesn't make them any more
trusted.
Linus
John Alvord
<al...@lxorguk.ukuu.org.uk> wrote:
>> throughput is as high as he wants it to be! Linus has pointed out
>> more than once that a big part of his job is to limit change. Maybe
>> he's happy with the current rate of change in 2.5. (That doesn't
>> mean everything is optimal--he might wish for higher quality changes
>> or a different mix of changes, just not more.)
>
>Progress happens at its own rate. Linus can no more control rate of change
>than you can put a waterfall into low gear. There is a difference between
>refusing stuff where the quality is low and losing stuff which is clear
>fixes
>
>> Two, Linus has argued that maintainers are his patch penguins;
>> whereas you favor a single integration point between the maintainers
>> and Linus. This has advantages and disadvantages, but on the whole,
>> I think it is better if Linus works directly with subsystem
>
>Perl I think very much shows otherwise. Right now we have a maze of partially
>integrated trees which overlap, clash when the people send stuff to Linus and
>worse.
>
>When you have one or two integrators you have a single tree pretty much everyone
>builds new stuff from and which people maintain small diffs relative to. At
>the end of the day that ends up like the older -ac tree, and with the same
>conditions - notably that anything in it might be going to see /dev/null not
>Linus if its shown to be flawed or not done well.
>
Multiple integrator-trees dilute the tester pool, which is a major
limitation on progress.
john alvord
Michael Sterrett -Mr. Bones.-
> "But it's not always a long process - some of you may remember Bill
> Hawes, for example, who came out of nowhere rather quickly.
I remember being very impressed by Bill. What ever happened to him?
Michael Sterrett
-Mr. Bones.-
michael....@coat.com
Andreas Dilger
> @@ -927,7 +919,6 @@
>
> LOGICAL VOLUME MANAGER
> P: Heinz Mauelshagen
> -M: m...@sistina.de
> L: linu...@sistina.com
> W: http://www.sistina.com/lvm
> S: Maintained
m...@sistina.com or mauel...@sistina.com
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Eric S. Raymond
>If a patch gets ignored 33 times in a row then perhaps the person doing
>the patch should first think really hard about the following 4 issues:
>
> - cleanliness
> - concept
> - timing
> - testing
>
>a violation of any of these items can cause patch to be dropped *without
>notice*. Face it, it's not Linus' task to teach people how to code or how
>to write correct patches. Sure, he still does teach people most of the
>time, but you cannot *expect* him to be able to do it 100% of the time.
Since the "33 times in a row" seems to refer to my bad experience with the
Configure.help patches, I think I need to correct a misconception.
The patches in question were *documentation*. No concept issue, no
timing issue, no testing issue (I don't know what a "cleanliness"
issue would be in this context). I know that Michael Elizabeth
Chastain, the listed CML1 maintainer, has had similar frustrating
exoeriences trying to get documentation patches folded in.
We're not talking about obscure internals changes that could break the
kernel, we're talking zero-risk patches submitted by official maintainers.
This is not a situation that ought to require a lot of judgment or
attention on Linus's part.
The fact that Linus *does* have to pass on all such patches, and is
dropping a lot of them them on the floor, is the clearest possible
example of the weaknesses in the present system.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Greg Boyce
at this point, but I have been reading lkml for several months and there
have been a few things I've noticed on this topic.
As people on both sides of this argument have pointed out, one single
person can only do so much. No matter how good you are, you're not going
to catch everything. Due to this, I'd like to suggest a dual
maintainership. A primary maintainer for the bug changes, and a secondary
for any small bits that fall through the crack.
The thing about this method is that it's already been proven to work.
Before Marcelo took over 2.4, Linus was the primary maintainer, and Alan
was making sure that the small bits weren't forgotten (As well as
providing some testing for some major changes before they were quite
ready).
Dave Jones appears to be taking the same roll in the 2.5 series, and Alan
is coming back a bit for 2.4 again.
Why not make it official? The dual tree system seems to work. It
would be quite similiar to Debian's release system. A stable, and a
testing branch. As long as the patches from the secondary maintainer gets
handled in a timely manner, less small changes will fall through the
crack.
Just my 2 cents.
Greg Boyce
Olaf Dietsche
John Weber <we...@nyc.rr.com> writes:
> I am currently writing code to scan the usual places for linux patches
> and automatically add them to our databases. This would be really
> simplified by having patches sent to us. And, since we already have a
How about extracting patches from lkml with procmail?
---cut here-->8---
:0 :
* ^sender: linux-ker...@vger.kernel.org
* ^subject:.*patch
{
:0 Bc:
* ^--- .*/
* ^+++ .*/
linux-kernel-patches
}
---8<--cut here---
This recipe has its limits, but it's a start.
Regards, Olaf.
Patrick Mochel
On Tue, 29 Jan 2002, Stuart Young wrote:
> Perhaps what we need is a patch maintenance system? Now I'm not talking
> CVS, I'm talking about something that is, in reality, pretty simple.
> Something that does the following:
Ah, the old Patch Management Problem. It's like an old friend (or a bad
rash).
AFAIK, something like this was first proposed here:
http://lists.insecure.org/linux-kernel/2000/Sep/2468.html
At that time, we were in the midst of the 2.4.0-test? series. Many things
were unstable and/or volatile. Linus was receiving an ungodly number of
patches, and releasing a new -pre patch about every day.
One of the main problems was that many patches simply didn't apply. What
a patch was diffed against would become obsolete so quickly, that many
patches were rendered useless by the time they were even read. And, there
was the same limitation concerning Linus's ability and desire to reply to
every single email.
The concept is very simple and described well in the email. So, I will not
expound on it here. Unfortunately, the project was dropped internally.
The problem has come up a few times in the last few months. Several people
have expressed interest in having something like it. Some already do.
Several people have said they were working on something like it.
Unfortunately, I think most of those people got distracted with their
other full-time jobs or more intersting work.
I brought the topic up here at OSDL a few months ago for use both
internally and externally. Also, with the notion of integrating our STP
(Scalable Test Platform). We've had several discussions about it, what it
would look like, and how it would work. We've also had the chance to talk
with a few of the other kernel maintainers in the area (face-to-face
meetings really do a long way).
The conclusions were this:
Is it necessary? No.
Could it be useful? Yes.
Would people use it? Probably.
Would everyone use it? No.
Would Linus use it? Probably Not.
Which is all pretty obvious. You can't please everyone.
We're going to develop a system internally and are willing to host a
system for the rest of the world to use. We're not looking to design a
be-all, end-all solution. Basically, just a system that can automate
things like applying patches and compiling.
If a patch succeeds, it then goes to the maintainer to which it was sent.
The maintainer can then accept or reject the patch. Either with
explanation or not. The submitter can then track what patches were
accepted.
Submitted patches can also go to a public mailing list and/or exported via
a public (read: web) interface. Of course, there should be ways to
override the publicity for OOB patches and sensitive items.
Writing the software is really not that difficult. But, we want something
that people like and can use, as well as modular and extensible. So, we're
aiming for simplicity and modularity.
So, the obvious question is 'So, where is it at now?'. Not much further
than the conceptualizing stage. The two people actually writing the
software are a bit over-subscribed ATM, though we do have some pretty
pictures.
I'm currently in the waiting queue for a Sourceforge project. Once that is
live, there will be a mailing list to which the discussion can be moved
and kept alive. Anyone and everyone interested is welcome to submit their
ideas and suggestions. Via the SF project, we will submit our designs and
post our progress on the system.
If you prefer a more private forum, feel free to email me and/or the Man
with the Plan: Nathan Dabney at sm...@osdl.org.
-pat
Alexander Viro
On Tue, 29 Jan 2002, Rob Landley wrote:
> Linux development is a fan club.
*plonk*
Jordan Mendelson
On Monday, January 28, 2002, at 06:10 AM, Rob Landley wrote:
> Okay everybody, this is getting rediculous. Patches FROM MAINTAINERS are
> getting dropped on the floor on a regular basis. This is burning out
> maintainers and is increasing the number of different kernel trees (not
> yet a
> major fork, but a lot of cracks and fragmentation are showing under the
> stress). Linus needs an integration lieutenant, and he needs one NOW.
While I'm not going to debate the fact that maintainence of the kernel
is suboptimal, I would like to point out that the system that has been
put in place is the correct way of doing it if you have someone with the
vision necessary to oversee development. There are many ways to go about
developing software, but many of them were created because of the lack
of a strong leader and fortunately the Linux community has one (many in
fact).
> We need to create the office of "patch penguin", whose job would be to
> make
> Linus's life easier by doing what Alan Cox used to do, and what Dave
> Jones is
> unofficially doing right now. (In fact, I'd like to nominate Dave Jones
> for
> the office, although it's Linus's decision and it would be nice if Dave
> got
> Alan Cox's blessing as well.)
Having one person who looks after patches is just going to create
another bottleneck. The real problem is not Linus not accepting patches,
but the process by which the patches are sent to him and the general
impatience of the developer community.
We all know the kernel is broken up into a set of subsystems and those
subsystems have maintainers. What is lacking however appears to be the
leadership by these maintainers to:
* Delegate ownership of components in their subsystems to others.
* Prioritize small easily code reviewable patches for submission to
Linus with adequate information about the contents of the changes
including who has reviewed it, who wrote it, why it should be included
and it's testing status is.
* Provide feedback to patch creators about the status of their patch
including reasons why it was denied, suggestions for improvement, etc.
Of course, this isn't universally true. There are many instances where,
especially in the case of device drivers, delegation has taken place,
but a formal process of accepting patches that is actually adhered to by
independent developers still appears to be lacking.
> Linus doesn't scale, and his current way of coping is to silently drop
> the
> vast majority of patches submitted to him onto the floor. Most of the
> time
> there is no judgement involved when this code gets dropped. Patches
> that fix
> compile errors get dropped. Code from subsystem maintainers that Linus
> himself designated gets dropped. A build of the tree now spits out
> numerous
> easily fixable warnings, when at one time it was warning-free. Finished
> code
> regularly goes unintegrated for months at a time, being repeatedly
> resynced
> and re-diffed against new trees until the code's maintainer gets sick
> of it.
> This is extremely frustrating to developers, users, and vendors, and is
> burning out the maintainers. It is a huge source of unnecessary work.
> The
> situation needs to be resolved. Fast.
I ague that the vast majority of patches submitted to Linus should be
dropped on the floor. There is no reason why a compilation bug fix for
an IDE chipset driver, PCI subsystem layer or even top-level Makefile
should be sent directly to Linus by an independent developer.
The amount of time necessary to walk through code submitted by those who
you don't know, don't trust and simply don't have an understanding of
proper kernel development makes submitting patches directly to Linus
like calling up the President to contest the suspension of your child
from school. You may have a valid fix for a bug, but the system simply
doesn't work if everyone decides to bypass local authority and go right
to the top.
> The fact that 2.5 has "pre" releases seems suggestive of a change in
> mindset.
> A patch now has to be widely used, tested, and recommended even to get
> into
> 2.5, yet how does the patch get such testing before it's integrated
> into a
> buildable kernel? Chicken and egg problem there, you want more testing
> but
> without integration each testers can test fewer patches at once.
There is no chicken and egg problem. A patch gets wide testing by
submitting it for peer review exactly like what goes on day in and day
out on linux-kernel and various other subsystem mailing lists. The patch
gets integrated into various forks of the tree for one reason or another
and obtains even wider testing and sooner or later, it makes it into the
kernel.
The patch tracking problem does exist. Maintainers loose track of
changes. People integrate changes into their forks and the patch creator
assumes that because someone is using their patch, their work is done.
Worst of all, the people maintaining these forked trees forget where the
patches they applied came from and bug fixes and public comments get
missed.
There has been a lot of discussion about augmenting the kernel
development process with automated tools of one sort of another, but
tools are only as good as the people using them.
* Linus's email is obviously overloaded so the first thing that should
be done is to get him a mailing list where only people he trusts can
post patches they have reviewed. As a matter of policy, every other
patch should simply be ignored by Linus.
* A hierarchical structure should be drawn out that shows who owns what
and the flow of patches. This exists somewhat in the MAINTAINERS file,
but I have a feeling that in some cases, the chain of command or is
mostly unknown as not all maintainers should have direct contact with
Linus. A real benefit would be to place the maintainers email address or
associated mailing list in the top of every file they own (which exists
mostly, but I don't believe it is part of a formal process.)
* A system of documentation for patches should be put in place. Each
patch should have associated information about why it exists, who has
approved it, what priority it is, change lists and of course, who wrote
it. When a comment is made, it needs to be sent back to the author of
the patch otherwise the author is just going to become frustrated and
attempt to escalate the issue himself.
* A system by which maintainers can prioritize the patches they submit
to Linus. Some patches are simply more important than others and
developers are just going to have to deal with the fact that submitting
a patch doesn't mean getting it integrated the next day.
Now this may sound like a lot of bureaucracy, but if the number of
people Linus trusts can be expanded and the hierarchy kept shallow, the
faster patches can be accepted or denied.
A final word. One thing that I have noticed over the years is because of
the frantic pace of development, people tend to get a bit impatient when
submitting patches. This mentality has also infected the average user
who seem to upgrade to the bleeding edge for no apparent reason. What
people need to remember is the 'stable' label given to the 2.4 tree
refers to the type and frequency of changes made to the code base, not
the stability of a running kernel. As developers, we need to be more
patient when submitting patches. The world doesn't end because a patch
doesn't make it into the bleeding edge kernels. If distributions need
the patch, they'll integrate it, but that fact alone doesn't justify the
patch making it into the kernel.
Of course that's just my opinion, I could be wrong.
Jordan
to...@vdpas.hobby.nl
>
>
> @@ -927,7 +919,6 @@
>
> LOGICAL VOLUME MANAGER
> P: Heinz Mauelshagen
> -M: m...@sistina.de
> L: linu...@sistina.com
> W: http://www.sistina.com/lvm
> S: Maintained
I just checked the linux-lvm mailing list.
Heinz seems to be mailing from: mauel...@sistina.com
Regards,
Toon.
--
/"\ | Windows XP:
\ / ASCII RIBBON CAMPAIGN | "Sorry Dave...
X AGAINST HTML MAIL | I'm afraid I can't do that."
/ \
Andi Kleen
> > If a patch gets ignored 33 times in a row then perhaps the person doing
> > the patch should first think really hard about the following 4 issues:
>
> Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4 liners.
> The big stuff is not the problem most times. That stuff does get ripped to
"Most times". For example the EA patches have badly failed so far, just because
Linus ignored all patches to add sys call numbers for a repeatedly discussed
and stable API and nobody else can add syscall numbers on i386.
-Andi
Ville Herva
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0011.3/0861.html
(...)
> does 2.4 still have this bug?
My understanding is that Al did fix it.
> in terms of 2.2 and 2.0, you should contact the respective maintainers.
It has been submitted now. David Weinehall merged it in 2.0.40-rc1 and I
understand that it's in Alan's 2.2.21pre queue as well.
-- v --
Christoph Hellwig
> "Most times". For example the EA patches have badly failed so far, just because
> Linus ignored all patches to add sys call numbers for a repeatedly discussed
> and stable API and nobody else can add syscall numbers on i386.
There still seems to be a lot of discussion vs EAs and ACLs.
Setting the suboptimal XFS APIs in stone doesn't make the discussion
easier.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
James Simmons
> I'm not proposing replacing the current subsystem maintainers. But are the
> current subsystem maintainers happy?
Usually I don't get involved in these discussions but I like to share
my experiences here and I also like for people see it from the point of
view of Linus.
A few years ago I got involved with developement of the framebuffer
layer. Now I work along with Geert on the improvement of this subsystem.
Do I consider myself a maintainer? Its just a title. All I know is I work
with Geert on this stuff. He has been doing that subsystem alot longer
than I have been and I have the up most high respect for him. So I would
never do anything without his okay.
One thing I can tell you is both me and Geert have jobs that don't pay
us to work directly on this (it would be nice HINT!!!!) . We do it out of
our free time. Unfortunely our free time is limited. I know I as well as
Geert receive email from various people on how to write drivers or even
recieve a bunch of patches. I have tried to look at every patch and read
every email. I can tell you it is so hard. Often I don't reply for days or
even weeks at a time. I feel bad sometimes about this but I can't help it.
BTW I don't ever ignore any emails. They might sit there for some time but
eventually I do answer them. Plus I do keep every patch I have been sent.
I even have been sent free hardware to test people's work on. I have
hardware I have been sitting around for several months ago but because I'm
so swamp I just don't get the time to test things on it. Another thing I
have experienced is having my head bite off by driver writers when I
reworked their code or told them this is the way the code should be
written.
As for Linus trusting or not trusting me. I hope he doesn't trust me
because I don't even trust myself sometimes. That is why I like to send
out my stuff on mailing list for people to see it. So people can voice
their options and I do see improvements. I'm thankful for trees like DJ
and alan's because I get to see a large audience test it. I have sent in
patches for the dj that worked for me and for a bunch of other people it
blew up. I see it as a much needed test bed. Only when nearly everyone
that is affected by my work is happy I would consider it worthy to send to
Linus.
I can't even imagine being Linus. First we do see him getting flamed
for wanting things a certain way or reworking someone else code. This can
be good if done right. Second he recieves alot of patches every day. I
don't blame him for not looking at a lot of them. In fact I wouldn't doubt
he has a filter for the people he trust to go int one box and the others
go into another box.
What is the solution for this problem? With my expeirences I have come
up with I found the following to work best. Unfortunely not all have been
applied to fbdev developement but I'm pushing it this way. These are
the goals I'm aiming for.
----------------------- For new device drivers ---------------------------
I. First we have setup a mailing list for this. He driver writers can
post their drivers for code review and testing.
II. Second step is to place it in a area where people know here to go for
the latest thing. For fbdev we have setup a CVS where people can ask
for CVS access and can place their driver their. I like to do it this
way because it is way to hard for me to track every patch. Plus we
have had several people write the same driver independent of each
other.
III. Place it in a beta tree. Announce it to the world.
IV. The maintainer submits it to Linus.
----------------------- API changes --------------------------------------
I. Post a proposal on a mailing list for that subsystem.
II. Everyone comments. Go to 1 until most people are happy.
III. Next a document maintiner steps forward to write real docs. (We
haven't done this). I really think every subsystem needs this.
IV. Start making patches and do above.
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
Andi Kleen
> In article <p73aduw...@oldwotan.suse.de> you wrote:
> > "Most times". For example the EA patches have badly failed so far, just because
> > Linus ignored all patches to add sys call numbers for a repeatedly discussed
> > and stable API and nobody else can add syscall numbers on i386.
>
> There still seems to be a lot of discussion vs EAs and ACLs.
At least the last l-k discussion ended in relative conclusion as far as
I remember (only disagreement was from someone wanting to implement them
in sys_reiser4)
> Setting the suboptimal XFS APIs in stone doesn't make the discussion
> easier.
The presented APIs were not the XFS APIs, but a significantly revised
version, based on a mix of ext2-acl and XFS and some new changes.
See http://acl.bestbits.at/man/extattr.2.html and
http://acl.bestbits.at/man/extattr.5.html
If you think anything is badly "suboptimal" proposal you should have stated
your criticism.
-Andi
Linus Torvalds
Christoph Hellwig <h...@ns.caldera.de> wrote:
>In article <p73aduw...@oldwotan.suse.de> you wrote:
>> "Most times". For example the EA patches have badly failed so far, just because
>> Linus ignored all patches to add sys call numbers for a repeatedly discussed
>> and stable API and nobody else can add syscall numbers on i386.
>
>There still seems to be a lot of discussion vs EAs and ACLs.
>Setting the suboptimal XFS APIs in stone doesn't make the discussion
>easier.
In fact, every time I thought that the extended attributes had reached
some kind of consensus, somebody piped up with some apparently major
complaint.
I think last time it was Al Viro. Admittedly (_very_ much admittedly),
making Al happy is really really hard. His perfectionism makes his
patches very easy to accept, but they make it hard for others to try to
make _him_ accept patches. But since he effectively is the VFS
maintainer whether he wants it to be written down in MAINTAINERS or not,
a comment from him on VFS interfaces makes me jump.
The last discussion over EA's in my mailbox was early-mid December, and
there were worries from Al and Stephen Tweedie. I never heard from the
worried people whether their worries were calmed.
Maybe they did, and maybe they didn't. If somebody doesn't tell me that
they are resolved, and that the people who would actually _use_ and
maintain this interface agrees on it, how can you expect me to ever
apply a patch?
Linus
Andreas Dilger
> Alan Cox <al...@lxorguk.ukuu.org.uk> writes:
> > Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4
> > liners. The big stuff is not the problem most times.
>
> because Linus ignored all patches to add sys call numbers for a repeatedly
> discussed and stable API and nobody else can add syscall numbers on i386.
But at times, keeping things external to the kernel for a good while isn't
a bad thing either. Basically, once code is part of the kernel, the API
is much harder to change than if it was always an optional patch.
For example, the EA patches have matured a lot in the time that they have
been external to the kernel (i.e. the move towards a common API with ext2
and XFS). Even so, the ext2 shared EA on-disk representation leaves a
bit to be desired, because it is only useful in the case of shared ACLs,
and fails if you add any other kind of EA type. See discussions on
ext2-devel for more information.
Similarly, my ext2 online resizing code was (and is) just fine, but when
I implemented the ext3 online resizing code (not yet available) I realized
I needed to change the on-disk format of some structures and this would
be much harder to do if it was part of the official kernel.
Like Ingo was saying, having to look over your code for a while also helps
it mature, and gives you some leeway to change it. That said, there is
also a benefit to adding code to the kernel, as it increases your user
base a LOT, and no code that is external to the kernel can be considered
as mature as that which is included into the kernel, I think. Drivers
may be an exception, because either you need the driver or you don't,
and people have little way of testing a driver if they don't have the hw.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
-
Andrew Morton
>
> Note who the email is addressed to. I have tried many different techniques
> for communicating with this gentleman, including self-deprecation, and they
> all seem to have the same result: no patch applied, long wait, eventually
> some other patch a long time later will obsolete my patch in some way, and
> the whole thing drifts off into forgotten history. Err, almost forgotten,
> because the bad taste remains.
>
> And yes, there was a successor to the patch in which I did the job 'properly'
> by cleaning up some other infrastructure instead of just fixing the bug
> locally. There was also a long lag after I created and submitted that
> version before the bug was actually fixed, and then it was only fixed in 2.4.
>
When all this ext2 fuss was going on, I went into ext3, changed
a few lines, fixed the bug and typed `cvs commit'.
I just thought you might enjoy hearing that.
-
Bill Davidsen
> In short, if you have areas or patches that you feel have had problems,
> ask yourself _why_ those areas have problems.
Easy, because the patch process has bogged down due to bad design and has
failed to scale. And you simply refuse to believe that there is a problem.
> A word of warning: good maintainers are hard to find. Getting more of
> them helps, but at some point it can actually be more useful to help the
> _existing_ ones. I've got about ten-twenty people I really trust, and
> quite frankly, the way people work is hardcoded in our DNA. Nobody
> "really trusts" hundreds of people. The way to make these things scale
> out more is to increase the network of trust not by trying to push it on
> me, but by making it more of a _network_, not a star-topology around me.
The problem is that you don't trust ANYONE. There is no reason why you
should be looking at small obvious patches to bugs (note bugs, not
enhancements). In the last batch of messages I see agreement from Alan Cox
and Eric Raymond that things are backed up. I see reiser filesystem
patches, from the original developer, labeled "third try." Quite bluntly
he is a hell of a lot better qualified to do bug fixes in that area than
you are.
> In short: don't try to come up with a "patch penguin". Instead try to
> help existing maintainers, or maybe help grow new ones. THAT is the way
> to scalability.
I'm sure this will be ignored, but here's what should happen, and will,
just maybe not in the Linus kernel series.
BUGS:
There should be a place to send bugs. Every bug should be acknowleged so
mailbots to keep resending will not be needed. People are setting this up
now, the question is not if it will be done this way, but if it will be
done through or around you.
Each bug should be eyeballed by someone with a clue just to see that the
report states a problem, a way to verify the problem, and doesn't grossly
misstate the intended behaviour. Then someone at the maintainer level
would look at the patch, check it carefully, and reject formally or apply.
Here's the heresy: every bug patch should be promoted to the current
kernel unless it is rejected for reason. This will get fixes in, but more
importantly will force people to look at the damn things...
Reasons to drop a patch:
1 - no bug, this process is for bugs, no news features or improvements.
Offhand I see bugs when you have a crash (oops), a failure to compile, or
filesystem corruption. Someone may want to add drivers totally not
working, but I didn't say it.
2 - no bug, you misunderstand the behaviour, failed to provide a test case
or persuasive argument (you are scanning from 0 to N instead of 0 to N-1
type stuff, you are locking one lock and unlocking another, etc).
3 - no fix, the solution doesn't work.
4 - not readable or understandable.
5 - changes some global part of the kernel and would or could impact other
things.
Note that while "there's a better way" can cause an add to the to-do list,
I do not intend to have the users suffer an actual bug if there is a
viable solution.
To all the people who say that "if you don't like the way Linus does
things write your own kernel," I say that's what is happening with the
-aa, -ac, etc lines. That's why I'm typing this on something called
2.4.17-jl15-ll, because I'm in need of a kernel which runs on a small
machine and doesn't piss me off with lousy response to complex stuff like
echoing what I type.
Someone mentioned the army. Note that hte general doesn't decide where to
dig the foxhole. It's about delegation, and while I doubt Linus read this
far, that's how things scale beyond what one person can do.
Fork is not just a system call, I'd hate to see FreeLinux, NetLinux,
OpenLinux, Linux386, along BSD lines, but while people will wait for
enhancements, I don't find that they are nearly so willing to wait for
fixes. Before we have vendor versions which actually start to differ in
syscall behaviour, let's get a handle on this. It's time for the
maintenence to evolve just as the kernel has, and become something bigger
and better. We need "patch-threads" soon, lest we thrash ourself silly.
--
bill davidsen <davi...@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Andi Kleen
> On Jan 29, 2002 22:56 +0100, Andi Kleen wrote:
> > Alan Cox <al...@lxorguk.ukuu.org.uk> writes:
> > > Lots of the stuff getting missed is tiny little fixes, obvious 3 or 4
> > > liners. The big stuff is not the problem most times.
> >
> > "Most times". For example the EA patches have badly failed so far, just
> > because Linus ignored all patches to add sys call numbers for a repeatedly
> > discussed and stable API and nobody else can add syscall numbers on i386.
>
> But at times, keeping things external to the kernel for a good while isn't
> a bad thing either. Basically, once code is part of the kernel, the API
> is much harder to change than if it was always an optional patch.
>
> For example, the EA patches have matured a lot in the time that they have
> been external to the kernel (i.e. the move towards a common API with ext2
> and XFS). Even so, the ext2 shared EA on-disk representation leaves a
The problem is that there are already 5-6 different incompatible system calls
with either different numbers or different semantics in significant
deployment in the wild. EA/ACLs is an important feature for
samba servers so they are rather popular. While it's IMHO ok to do limited
testing in private the critical threshold where incompatible system call
ABIs are just a big problem for linux has long been surpassed.
One of the success linux/i386 had in the past was to maintain a very stable
kernel ABI, but at least in the EA space this archivement is currently
getting undermined badly.
-Andi
Bill Davidsen
> None of the examples you cited so far are convincing to me, and i'd like
> to explain why. I've created and submitted thousands of patches to the
> Linux kernel over the past 4 years (my patch archive doesnt go back more
> than 4 years):
>
> # ls patches | wc -l
> 2818
>
> a fair percentage of those went to Linus as well, and while having seen
> some of them rejected does hurt mentally, i couldnt list one reject from
> Linus that i wouldnt reject *today*. But i sure remember being frustrated
> about rejects when they happened. In any case, i have some experience in
> submitting patches and i'm maintaining a few subsystems, so here's my take
> on the 'patch penguin' issue:
>
> If a patch gets ignored 33 times in a row then perhaps the person doing
> the patch should first think really hard about the following 4 issues:
1 - why doesn't someone at least ack the damn patch?
2 - why doesn't someone at least ack the damn patch?
3 - why doesn't someone at least ack the damn patch?
4 - why doesn't someone at least ack the damn patch?
There is no better way to avoid getting something good from someone than
to ignore them completely. The fact that things like reisser f/s patches
from the creator don't get in is an example, or don't you think they are
good enough?
--
bill davidsen <davi...@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
Nickolaos Fotopoulos
us to handle all of overflow automatically goes to them. This help keep our
client happy and us in business when a client unexpectidly run an TV ad.
Maybe something could be setup to handle the overflow that Linus recieves on
a regular basis. BTW this is my first post to the list and firstday on the
list so please excuse any ignorance, as i might have just restated what
other have already said.
Nick Fotopoulos
Bill Davidsen
> Ingo, you should have a look at my mailbox and the people sick of trying to
> get Linus to take 3 liners to fix NODEV type stuff and being ignored so that
> 2.5.* still doesn't even compile or boot for many people.
>
> Dave in doing the patch hoovering at least ensures these are picked up. You
> think if this carries on anyone will be running Linus tree in 9 months ?
Linus, I think I hear people you said you trust telling you this... take
the little bits out of band and TRUST people to give you patches which go
in 2.5.x now, not when or if you get to it. Having you approve trivial
stuff is a waste of what you do best, and I think all the versions show
you're not even being effective at that. Don't you HATE looking at
spelling errors, off-by-one logic, corner cases, and stuff like that? Farm
it out and let other people do it, and work on the fun stuff.
--
bill davidsen <davi...@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-
Alan Cox
> they are resolved, and that the people who would actually _use_ and
> maintain this interface agrees on it, how can you expect me to ever
> apply a patch?
Ok now I'm confused. What is the criteria that decides "Im waiting silently
for everyone to guess I need answers from two people whom you must deduce
from telepathy" versus "bugger this lets rip this out and try xyz's approach"
- which you also do at times without everyone being remotely happy on the
subject.
Alan
James Stevenson
> ---cut here-->8---
> :0 :
> * ^sender: linux-ker...@vger.kernel.org
> * ^subject:.*patch
> {
> :0 Bc:
> * ^--- .*/
> * ^+++ .*/
> linux-kernel-patches
> }
> ---8<--cut here---
>
> This recipe has its limits, but it's a start.
well since most patches have a subject line
starting with [PATCH] its not hard to pull them out
with procmail.
Andi Kleen
> In article <200201292208...@ns.caldera.de>,
> Christoph Hellwig <h...@ns.caldera.de> wrote:
> >In article <p73aduw...@oldwotan.suse.de> you wrote:
> >> "Most times". For example the EA patches have badly failed so far, just because
> >> Linus ignored all patches to add sys call numbers for a repeatedly discussed
> >> and stable API and nobody else can add syscall numbers on i386.
> >
> >There still seems to be a lot of discussion vs EAs and ACLs.
> >Setting the suboptimal XFS APIs in stone doesn't make the discussion
> >easier.
>
> In fact, every time I thought that the extended attributes had reached
> some kind of consensus, somebody piped up with some apparently major
> complaint.
>
> I think last time it was Al Viro. Admittedly (_very_ much admittedly),
> making Al happy is really really hard. His perfectionism makes his
> patches very easy to accept, but they make it hard for others to try to
> make _him_ accept patches. But since he effectively is the VFS
> maintainer whether he wants it to be written down in MAINTAINERS or not,
> a comment from him on VFS interfaces makes me jump.
>
> The last discussion over EA's in my mailbox was early-mid December, and
> there were worries from Al and Stephen Tweedie. I never heard from the
> worried people whether their worries were calmed.
Stephen's objection was that the EA specification didn't define a standard
format for ACL EAs too. That's certainly true, but outside the EA spec
actually. First there are good reasons to have ACLs mapped to generic EAs.
There are also already other applications of EAs independent
of ACLs, for example there is an DMAPI implementation for XFS which needs
EAs, or HFS and NTFS need to map arbitary EAs defined by the foreign fs
to some common backupable format, and various extended security projects
need generic "blob" EAs too to store their per file security information.
Mapping the ACLs to EAs has the advantage that you can backup/archive/
network sync all these things with a single API, instead of teaching all
your backup tools about first ACLs and then generic EAs.
About the common ACL spec: there are unfortunately different flavours of
ACLs. All the unix like implementations so far (ext2/3-acl and XFS acl)
use something very near the withdrawn POSIX draft, while NTFS/CIFS/NFSv4
have completely different ACLs, and AFS has another flavour. Trying to map
these into a single ACL syscall seemed to hard and likely doesn't make
sense.
ext2/XFS currently rely on a single user space library that generates
the POSIX ACLs. NTFS/NFSv4/etc. are out of scope because it's not clear
how to merge them. With generic EAs you could have a different user library
that manages NTFS ACLs (and another one for AFS etc.), it seems there will
be no clean way around this.
For the ACL format used by the bestbits libacl there is afaik currently
no draft, just some source code, but the semantics are defined by the
POSIX draft and relatively fixed and also quite common in other Unixes.
Al's objection seemed to be that the patch adding the new VFS functions
passed a struct inode * instead of a struct dentry * in one case.
Fixing that is a trivial search'n'replace. I think it wasn't done at first
because it required changing the VFS to pass a dentry to i_op->permission()
and they didn't want to bloat the patch with search-n-replace in every
filesystem yet. If you would integrate it that could be done of course.
[in short it is a non brainer, has nothing to do with the API but is
just a small implementation detail that can be easily changed]
Does that answer your questions?
Would you look at a patch again?
-Andi
Linus Torvalds
On 30 Jan 2002, Andi Kleen wrote:
> Does that answer your questions?
> Would you look at a patch again?
That answers the specific questions about Al and Stephen.
It does NOT address whether consensus has been reached in general, and
whether people are happy. Is that the case?
Also, obviously nobody actually took over maintainership of the patch,
because equally obviously nobody has been pinging me about it. For some
reason you seem to want _me_ to go out of my way to search for patches
that are over a month old that I don't know whether they are valid or not,
used or not, or even agreed upon or not.
But yes, it's so much easier to blame me.
Linus
Jesse Pollard
>
> Linus Torvalds wrote:
>
> >On Mon, 28 Jan 2002, Larry McVoy wrote:
> >
> >>What you didn't do, Linus, is paint a picture which allows development
> >>to scale up.
> >>
> >
> >Actually, I thought I did.
> >
> >Basic premise: development is done by humans.
> >
> >Now, look at how humans work. I don't know _anybody_ who works with
> >hundreds of people. You work with 5-10 people, out of a pool of maybe
> >30-50 people. Agreed?
> >
> Not at all. Please have a look at the ARMY. (A tightly hierarchical
> system...)
And at each level (outside of training) there are usually one supervisor
for 8-15 people. At the lowest - a corpral. next sargent, ...
Though I can accept the lowest defined as a sargent, with an assistant.
And at the top - president, assisted by vice pres over the cabinet. next
level down, Secretary of Defense over Joint Chiefs...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
Eric S. Raymond
> And we ARE using a patch penguin. You were around, and Dave is
> around. I'm kind of confused at the level of resistence to formally
> recognizing what basically IS current practice, and has been for
> YEARS. (The reason for naming the position is we can't just say
> "alan's tree" anymore. The position went from one person to another
> person, and as such the position seemed to need to be recognized as
> being separate from the individual. I didn't expect to hit a brick
> wall on that. It didn't seem like a revolutionary idea to me...)
Alas. That's because, like most Americans these days, you're
historically illiterate. What we are facing here is a *very* familiar
problem to social and institutional historians.
All movements founded by charismatic leaders like Linus eventually hit
this same wall -- the point at which the charisma of the founder and
the individual ability of the disciples he personally attracts are no
longer adequate to meet the challenges of success, and some way to
institutionalize and distribute the leader's role has to be found.
Movements that fail to make this transition die, generally by
implosion or fragmenting into feuding sub-sects.
If you were familiar with the historical precedents, Rob, you would
understand that your modest proposal re-enacts a common pattern.
A relatively junior member of the movement, one with few political
ties, sees the developing stress fractures in the organization of
the movement and proposes a modest, incremental change to relieve
some of them. Conservatives interpret the attempt to separate
and institutionalize part of the founder's role as an attack on
the authority of the founder. Huge flamewars ensue, with the
original pragmatic sense of the proposal often being lost as it
becomes a political football in the movement's internal status games.
Sometimes the first such attempt at institutionization succeeds. More
often, the movement has to go through a series of escalating crises
(burning up would-be reformers each time) before anyone finally
succeeds in changing the movement's internal culture.
Religions go through this. Secular social movements go through this.
Companies founded by brilliant entrepreneurs go through this (the
B-schools have a whole literature on "entrepreneurial overcontrol" and
its consequences). It's one of the dramas that gets perpetually
re-enacted; it's built in to our wiring. The unhappy truth is that
even *successful* transitions of this kind are invariably painful, and
often leave deep scars on the survivors and on the institution that
arises from the transition.
*Never* expect this sort of transition to be easy, especially when the
positions people are taking are as much about personal identity and
values as they are about "success" in whatever terms the movement
defines it.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Linus Torvalds
On Tue, 29 Jan 2002, Rob Landley wrote:
> > >
> > > Then why not give the subsystem maintainers patch permissions on your
> > > tree. Sort of like committers. The problem people have is that you're
> > > dropping patches from those ten-twenty people you trust.
> >
> > No. Ask them, and they will (I bet) pretty uniformly tell you that I'm
> > _not_ dropping their patches (although I'm sometimes critical of them,
> > and will tell them that they do not get applied).
>
> Andre Hedrick, Eric Raymond, Rik van Riel, Michael Elizabeth Chastain, Axel
> Boldt...
NONE of those are in the ten-twenty people group.
How many people do you think fits in a small group? Hint. It sure isn't
all 300 on the maintainers list.
> Ah. So being listed in the maintainers list doesn't mean someone is actually
> a maintainer it makes sense to forward patches to?
Sure it does.
It just doesn't mean that they should send stuff to _me_.
Did you not understand my point about scalability? I can work with a
limited number of people, and those people can work with _their_ limited
number of people etc etc.
The MAINTAINERS file is _not_ a list of people I work with on a daily
basis. In fact, I don't necessarily even recognize the names of all those
people.
Let's take an example. Let's say that you had a patch for ppp. You'd send
the patch to Paul Mackerras. He, in turn, would send his patches to David
Miller (who knows a hell of a lot better what it's all about than I do).
And he in turn sends them to me.
They are both maintainers. That doesn't mean that I necessarily work with
every maintainer directly.
Or look at USB: I get the USB patches from Greg, and he gets them from
various different people. Johannes Erdfelt is the maintainer for uhci.c,
and he sends them to Greg, not to me.
Why? Because having hundreds of people emailing me _obviously_ doesn't
scale. Never has, never will. It may work over short timeperiods wih lots
of energy, but it obviously isn't a stable setup.
Linus
Alan Cox
> > "good taste" for a long time. But it's not always a long process - some
> > of you may remember Bill Hawes, for example, who came out of nowhere
> > rather quickly.
>
> So listed "maintainers" may need to forward patches to these people, and get
> them to sign off on them, in order to get their patches at least reviewed for
> inclusion into your tree?
Count me out of that job. If you want something in 2.5 don't bug me. I
simply don't care
Alan
Linus Torvalds
On Wed, 30 Jan 2002, Nathan Scott wrote:
>
> Al had several (additional) issues with the original patch, but I
> think we progressively worked through them - Al stopped suggesting
> changes at one point anyway, and the level of abuse died away ;),
> so I guess he became more satisfied with them.
I think you can safely assume that if Al doesn't curse you to hell, he can
be considered happy.
> Not much point apportioning blame - its as much my fault - I
> hadn't heard back from you at all since day 1, so figured you
> were just not interested in this stuff, so I stopped sending.
Basically, you should always consider email to me to be a unreliable
medium, with no explicit congestion control. So think of an email like a
TCP packet, with exponential backoff - except the times are different (in
TCP, the initial timeout is three seconds, and the max timeout is 2
minutes. In "Linus-lossy-network" it makes sense to use different
default and maximum values ;)
Linus
Nathan Scott
On Tue, Jan 29, 2002 at 03:13:14PM -0800, Linus Torvalds wrote:
>
> On 30 Jan 2002, Andi Kleen wrote:
> > Does that answer your questions?
> > Would you look at a patch again?
>
> That answers the specific questions about Al and Stephen.
Al had several (additional) issues with the original patch, but I
think we progressively worked through them - Al stopped suggesting
changes at one point anyway, and the level of abuse died away ;),
so I guess he became more satisfied with them.
> It does NOT address whether consensus has been reached in general, and
> whether people are happy. Is that the case?
I believe so - I know that the ext2/ext3 EA/ACL maintainer
(AndreasG, CCd) is satisfied with the current patches, from
an XFS point of view they satisfy all our needs, and Anton
has chimed in saying this interface will work well for NTFS
EA support (Anton sent me patches and several suggestions as
well, which were included in the patch at the time).
> Also, obviously nobody actually took over maintainership of the patch,
> because equally obviously nobody has been pinging me about it. For some
> reason you seem to want _me_ to go out of my way to search for patches
> that are over a month old that I don't know whether they are valid or not,
> used or not, or even agreed upon or not.
>
> But yes, it's so much easier to blame me.
>
Not much point apportioning blame - its as much my fault - I
hadn't heard back from you at all since day 1, so figured you
were just not interested in this stuff, so I stopped sending.
The two patches which seemed to satisfy the most people are
below - they are unchanged from 2.5.0 but should apply to any
2.5.x tree (they are fairly non-intrusive and the system call
table hasn't changed since last time). A complete userspace
implementation for both EAs and POSIX ACLs exists above these
interfaces.
cheers.
--
Nathan
[Patch #1: reserve syscall numbers]
diff -Naur 2.5.0-pristine/arch/i386/kernel/entry.S 2.5.0-reserved/arch/i386/kernel/entry.S
--- 2.5.0-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.5.0-reserved/arch/i386/kernel/entry.S Tue Dec 4 11:57:32 2001
@@ -622,6 +622,18 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for setxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lsetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fsetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for getxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* 230 reserved for lgetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fgetxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for listxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for llistxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for flistxattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* 235 reserved for removexattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lremovexattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fremovexattr */
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.5.0-pristine/include/asm-i386/unistd.h 2.5.0-reserved/include/asm-i386/unistd.h
--- 2.5.0-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.5.0-reserved/include/asm-i386/unistd.h Tue Dec 4 11:58:21 2001
@@ -230,6 +230,18 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_setxattr 226
+#define __NR_lsetxattr 227
+#define __NR_fsetxattr 228
+#define __NR_getxattr 229
+#define __NR_lgetxattr 230
+#define __NR_fgetxattr 231
+#define __NR_listxattr 232
+#define __NR_llistxattr 233
+#define __NR_flistxattr 234
+#define __NR_removexattr 235
+#define __NR_lremovexattr 236
+#define __NR_fremovexattr 237
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
[Patch #2: VFS implementation]
diff -Naur 2.5.0-pristine/arch/i386/kernel/entry.S 2.5.0-xattr/arch/i386/kernel/entry.S
--- 2.5.0-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.5.0-xattr/arch/i386/kernel/entry.S Thu Dec 6 12:59:47 2001
@@ -622,6 +622,18 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_setxattr)
+ .long SYMBOL_NAME(sys_lsetxattr)
+ .long SYMBOL_NAME(sys_fsetxattr)
+ .long SYMBOL_NAME(sys_getxattr)
+ .long SYMBOL_NAME(sys_lgetxattr) /* 230 */
+ .long SYMBOL_NAME(sys_fgetxattr)
+ .long SYMBOL_NAME(sys_listxattr)
+ .long SYMBOL_NAME(sys_llistxattr)
+ .long SYMBOL_NAME(sys_flistxattr)
+ .long SYMBOL_NAME(sys_removexattr) /* 235 */
+ .long SYMBOL_NAME(sys_lremovexattr)
+ .long SYMBOL_NAME(sys_fremovexattr)
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.5.0-pristine/fs/Makefile 2.5.0-xattr/fs/Makefile
--- 2.5.0-pristine/fs/Makefile Tue Nov 13 04:34:16 2001
+++ 2.5.0-xattr/fs/Makefile Thu Dec 6 12:59:47 2001
@@ -14,7 +14,7 @@
super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o \
fcntl.o ioctl.o readdir.o select.o fifo.o locks.o \
dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o \
- filesystems.o namespace.o seq_file.o
+ filesystems.o namespace.o seq_file.o xattr.o
ifeq ($(CONFIG_QUOTA),y)
obj-y += dquot.o
diff -Naur 2.5.0-pristine/fs/xattr.c 2.5.0-xattr/fs/xattr.c
--- 2.5.0-pristine/fs/xattr.c Thu Jan 1 10:00:00 1970
+++ 2.5.0-xattr/fs/xattr.c Thu Dec 6 12:59:58 2001
@@ -0,0 +1,341 @@
+/*
+ File: fs/xattr.c
+
+ Extended attribute handling.
+
+ Copyright (C) 2001 by Andreas Gruenbacher <a.grue...@computer.org>
+ Copyright (C) 2001 SGI - Silicon Graphics, Inc <linu...@oss.sgi.com>
+ */
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/smp_lock.h>
+#include <linux/file.h>
+#include <linux/xattr.h>
+#include <asm/uaccess.h>
+
+/*
+ * Extended attribute memory allocation wrappers, originally
+ * based on the Intermezzo PRESTO_ALLOC/PRESTO_FREE macros.
+ * The vmalloc use here is very uncommon - extended attributes
+ * are supposed to be small chunks of metadata, and it is quite
+ * unusual to have very many extended attributes, so lists tend
+ * to be quite short as well. The 64K upper limit is derived
+ * from the extended attribute size limit used by XFS.
+ * Intentionally allow zero @size for value/list size requests.
+ */
+static void *
+xattr_alloc(size_t size, size_t limit)
+{
+ void *ptr;
+
+ if (size > limit)
+ return ERR_PTR(-E2BIG);
+
+ if (!size) /* size request, no buffer is needed */
+ return NULL;
+ else if (size <= PAGE_SIZE)
+ ptr = kmalloc((unsigned long) size, GFP_KERNEL);
+ else
+ ptr = vmalloc((unsigned long) size);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+ return ptr;
+}
+
+static void
+xattr_free(void *ptr, size_t size)
+{
+ if (!size) /* size request, no buffer was needed */
+ return;
+ else if (size <= PAGE_SIZE)
+ kfree(ptr);
+ else
+ vfree(ptr);
+}
+
+/*
+ * Extended attribute SET operations
+ */
+static long
+setxattr(struct dentry *d, char *name, void *value, size_t size, int flags)
+{
+ int error;
+ void *kvalue;
+ char kname[XATTR_NAME_MAX + 1];
+
+ if (flags & ~(XATTR_CREATE|XATTR_REPLACE))
+ return -EINVAL;
+
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return -EFAULT;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ kvalue = xattr_alloc(size, XATTR_SIZE_MAX);
+ if (IS_ERR(kvalue))
+ return PTR_ERR(kvalue);
+
+ if (size > 0 && copy_from_user(kvalue, value, size)) {
+ xattr_free(kvalue, size);
+ return -EFAULT;
+ }
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->setxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags);
+ unlock_kernel();
+ }
+
+ xattr_free(kvalue, size);
+ return error;
+}
+
+asmlinkage long
+sys_setxattr(char *path, char *name, void *value, size_t size, int flags)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = setxattr(nd.dentry, name, value, size, flags);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lsetxattr(char *path, char *name, void *value, size_t size, int flags)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = setxattr(nd.dentry, name, value, size, flags);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fsetxattr(int fd, char *name, void *value, size_t size, int flags)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = setxattr(f->f_dentry, name, value, size, flags);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute GET operations
+ */
+static long
+getxattr(struct dentry *d, char *name, void *value, size_t size)
+{
+ int error;
+ void *kvalue;
+ char kname[XATTR_NAME_MAX + 1];
+
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return -EFAULT;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ kvalue = xattr_alloc(size, XATTR_SIZE_MAX);
+ if (IS_ERR(kvalue))
+ return PTR_ERR(kvalue);
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->getxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->getxattr(d, kname, kvalue, size);
+ unlock_kernel();
+ }
+
+ if (kvalue && error > 0)
+ if (copy_to_user(value, kvalue, size))
+ error = -EFAULT;
+ xattr_free(kvalue, size);
+ return error;
+}
+
+asmlinkage long
+sys_getxattr(char *path, char *name, void *value, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = getxattr(nd.dentry, name, value, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lgetxattr(char *path, char *name, void *value, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = getxattr(nd.dentry, name, value, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fgetxattr(int fd, char *name, void *value, size_t size)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = getxattr(f->f_dentry, name, value, size);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute LIST operations
+ */
+static long
+listxattr(struct dentry *d, char *list, size_t size)
+{
+ int error;
+ char *klist;
+
+ klist = (char *)xattr_alloc(size, XATTR_LIST_MAX);
+ if (IS_ERR(klist))
+ return PTR_ERR(klist);
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->listxattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->listxattr(d, klist, size);
+ unlock_kernel();
+ }
+
+ if (klist && error > 0)
+ if (copy_to_user(list, klist, size))
+ error = -EFAULT;
+ xattr_free(klist, size);
+ return error;
+}
+
+asmlinkage long
+sys_listxattr(char *path, char *list, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = listxattr(nd.dentry, list, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_llistxattr(char *path, char *list, size_t size)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = listxattr(nd.dentry, list, size);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_flistxattr(int fd, char *list, size_t size)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = listxattr(f->f_dentry, list, size);
+ fput(f);
+ return error;
+}
+
+/*
+ * Extended attribute REMOVE operations
+ */
+static long
+removexattr(struct dentry *d, char *name)
+{
+ int error;
+ char kname[XATTR_NAME_MAX + 1];
+
+ if (copy_from_user(kname, name, XATTR_NAME_MAX))
+ return -EFAULT;
+ kname[XATTR_NAME_MAX] = '\0';
+
+ error = -EOPNOTSUPP;
+ if (d->d_inode->i_op && d->d_inode->i_op->removexattr) {
+ lock_kernel();
+ error = d->d_inode->i_op->removexattr(d, kname);
+ unlock_kernel();
+ }
+ return error;
+}
+
+asmlinkage long
+sys_removexattr(char *path, char *name)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk(path, &nd);
+ if (error)
+ return error;
+ error = removexattr(nd.dentry, name);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_lremovexattr(char *path, char *name)
+{
+ struct nameidata nd;
+ int error;
+
+ error = user_path_walk_link(path, &nd);
+ if (error)
+ return error;
+ error = removexattr(nd.dentry, name);
+ path_release(&nd);
+ return error;
+}
+
+asmlinkage long
+sys_fremovexattr(int fd, char *name)
+{
+ struct file *f;
+ int error = -EBADF;
+
+ f = fget(fd);
+ if (!f)
+ return error;
+ error = removexattr(f->f_dentry, name);
+ fput(f);
+ return error;
+}
diff -Naur 2.5.0-pristine/include/asm-i386/unistd.h 2.5.0-xattr/include/asm-i386/unistd.h
--- 2.5.0-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.5.0-xattr/include/asm-i386/unistd.h Thu Dec 6 12:59:47 2001
@@ -230,6 +230,18 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_setxattr 226
+#define __NR_lsetxattr 227
+#define __NR_fsetxattr 228
+#define __NR_getxattr 229
+#define __NR_lgetxattr 230
+#define __NR_fgetxattr 231
+#define __NR_listxattr 232
+#define __NR_llistxattr 233
+#define __NR_flistxattr 234
+#define __NR_removexattr 235
+#define __NR_lremovexattr 236
+#define __NR_fremovexattr 237
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
diff -Naur 2.5.0-pristine/include/linux/fs.h 2.5.0-xattr/include/linux/fs.h
--- 2.5.0-pristine/include/linux/fs.h Fri Nov 23 06:46:19 2001
+++ 2.5.0-xattr/include/linux/fs.h Thu Dec 6 12:59:47 2001
@@ -851,6 +851,10 @@
int (*revalidate) (struct dentry *);
int (*setattr) (struct dentry *, struct iattr *);
int (*getattr) (struct dentry *, struct iattr *);
+ int (*setxattr) (struct dentry *, char *, void *, size_t, int);
+ int (*getxattr) (struct dentry *, char *, void *, size_t);
+ int (*listxattr) (struct dentry *, char *, size_t);
+ int (*removexattr) (struct dentry *, char *);
};
/*
diff -Naur 2.5.0-pristine/include/linux/limits.h 2.5.0-xattr/include/linux/limits.h
--- 2.5.0-pristine/include/linux/limits.h Thu Jul 29 03:30:10 1999
+++ 2.5.0-xattr/include/linux/limits.h Thu Dec 6 12:59:47 2001
@@ -13,6 +13,9 @@
#define NAME_MAX 255 /* # chars in a file name */
#define PATH_MAX 4095 /* # chars in a path name */
#define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
+#define XATTR_NAME_MAX 255 /* # chars in an extended attribute name */
+#define XATTR_SIZE_MAX 65536 /* size of an extended attribute value (64k) */
+#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
#define RTSIG_MAX 32
diff -Naur 2.5.0-pristine/include/linux/xattr.h 2.5.0-xattr/include/linux/xattr.h
--- 2.5.0-pristine/include/linux/xattr.h Thu Jan 1 10:00:00 1970
+++ 2.5.0-xattr/include/linux/xattr.h Thu Dec 6 12:59:47 2001
@@ -0,0 +1,15 @@
+/*
+ File: linux/xattr.h
+
+ Extended attributes handling.
+
+ Copyright (C) 2001 by Andreas Gruenbacher <a.grue...@computer.org>
+ Copyright (C) 2001 SGI - Silicon Graphics, Inc <linu...@oss.sgi.com>
+*/
+#ifndef _LINUX_XATTR_H
+#define _LINUX_XATTR_H
+
+#define XATTR_CREATE 0x1 /* set value, fail if attr already exists */
+#define XATTR_REPLACE 0x2 /* set value, fail if attr does not exist */
+
+#endif /* _LINUX_XATTR_H */
Rik van Riel
> > Andre Hedrick, Eric Raymond, Rik van Riel, Michael Elizabeth
> > Chastain, Axel Boldt...
>
> NONE of those are in the ten-twenty people group.
>
> How many people do you think fits in a small group? Hint. It sure
> isn't all 300 on the maintainers list.
That's fine with me, but _who_ do I send VM patches to if
I can't send them to you ?
There is no maintainer for mm/* or kernel/*, it's just you.
I agree it would be nice to have somebody from within the
ten-twenty people group take care of that, but we'll need
to have _somebody_ ...
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
Daniel Jacobowitz
> > Ah. So being listed in the maintainers list doesn't mean someone is actually
> > a maintainer it makes sense to forward patches to?
>
> Sure it does.
>
> It just doesn't mean that they should send stuff to _me_.
>
> Did you not understand my point about scalability? I can work with a
> limited number of people, and those people can work with _their_ limited
> number of people etc etc.
>
> The MAINTAINERS file is _not_ a list of people I work with on a daily
> basis. In fact, I don't necessarily even recognize the names of all those
> people.
I understand that the sort of careful hierarchy that drives this
process is, by nature, an informal thing. But it would still be nice
if _suggestions_ on how it worked were written down somewhere. When
you've got patches that don't have a clear relevant maintainer, it
would be nice to have something more specific than "post to
linux-kernel and pray someone picks it up" to run with!
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Chris Ricker
> They are both maintainers. That doesn't mean that I necessarily work with
> every maintainer directly.
>
> Or look at USB: I get the USB patches from Greg, and he gets them from
> various different people. Johannes Erdfelt is the maintainer for uhci.c,
> and he sends them to Greg, not to me.
>
> Why? Because having hundreds of people emailing me _obviously_ doesn't
> scale. Never has, never will. It may work over short timeperiods wih lots
> of energy, but it obviously isn't a stable setup.
Linus,
That's fine, but there's a major problem with your scheme. What happens
with all the stuff for which no one is listed in MAINTAINERS? For example,
no one owns linux/Documentation. As the person nominally in charge of
linux/Documentation/Changes, there's no one between me and you, period, let
alone anyone between me and you that you trust.... And I realize that you
don't consider documentation very important, but there are other segments of
the Linux source tree for which this breakdown in hierarchy is also true....
later,
chris
Linus Torvalds
On Tue, 29 Jan 2002, Rik van Riel wrote:
>
> That's fine with me, but _who_ do I send VM patches to if
> I can't send them to you ?
The VM stuff right now seems to be Andrea, Dave or you yourself (right now
I just wish you would split up your patches like Andrea does, that way I
can cherry-pick).
> There is no maintainer for mm/* or kernel/*, it's just you.
As to kernel/ there are actually maintainers for some sub-areas, the most
noticeable being Ingo on the scheduler. The rest of kernel/ hasn't ever
been much of a problem, really.
The VM is a big issue, of course. And that one isn't likely to go away
anytime soon as a point of contention. And it's not easy to modularize,
apart from the obvious pieces (ie "filemap.c" vs the rest).
You may not believe me when I say so, but I personally _really_ hope your
rmap patches will work out. I may not have believed in your patches in a
2.4.x kind of timeframe, but for 2.6.x I'm more optimistic. As to how to
actually modularize it better to make points of contention smaller, I
don't know how.
At the same time, while I can understand your personal pain, I don't think
most of the problems have been with the VM (maintenance-wise, that is.
Most of the _technical_ problems really have been with the VM, it's just
the most complex piece).
Linus
Linus Torvalds
On Tue, 29 Jan 2002, Chris Ricker wrote:
>
> That's fine, but there's a major problem with your scheme. What happens
> with all the stuff for which no one is listed in MAINTAINERS?
I have to admit that personally I've always found the MAINTAINERS file
more of an irritation than anything else. The first place _I_ tend to look
personally is actually in the source files themselves (although that may
be a false statistic - the kind of people I tend to have to look up aren't
the main maintainers at all, but more single driver people etc).
It might not be a bad idea to just make that "mention maintainer at the
top of the file" the common case.
Linus
Rik van Riel
> On Tue, 29 Jan 2002, Rik van Riel wrote:
> >
> > That's fine with me, but _who_ do I send VM patches to if
> > I can't send them to you ?
>
> The VM stuff right now seems to be Andrea, Dave or you yourself (right
> now I just wish you would split up your patches like Andrea does, that
> way I can cherry-pick).
I will. It's not split up at the moment because I'd like to
work a bit more on -rmap before submitting it for inclusion
and bitkeeper is a really nice tool to help me carry the patch
from version to version.
If -rmap makes it into the kernel I'll work with small patches
in the same style as Andrea, that's just the easiest way to
work.
I'll also take some of rusty's scripts to automatically check
if a patch (1) has been applied to the latest kernel or
(2) if it still applies cleanly.
Basically I'm looking for a way to minimise the work of
carrying the -rmap VM across kernel versions, so I can spend
my time doing development and cleaning up the code further.
> The VM is a big issue, of course. And that one isn't likely to go away
> anytime soon as a point of contention. And it's not easy to modularize,
> apart from the obvious pieces (ie "filemap.c" vs the rest).
Actually some stuff can be modularised somewhat. Christoph
Hellwig for example has a nice patch which replaces all
knowledge of page->wait with wake_up_page().
This makes the fact of whether we're using per-page waitqueues
or hashed waitqueues completely invisible to the rest of the
kernel.
Similar things are possible for other areas of the code.
> You may not believe me when I say so, but I personally _really_ hope your
> rmap patches will work out. I may not have believed in your patches in a
> 2.4.x kind of timeframe, but for 2.6.x I'm more optimistic. As to how to
> actually modularize it better to make points of contention smaller, I
> don't know how.
One thing William Irwin (and others, myself too) have been
looking at is making the pagemap_lru_lock per-zone.
This would allow us to "split up" memory in zones and have
each CPU start the allocation chain at its own zone.
This works out in practice because the reverse mapping code
allows us to scan and free memory by physical address,
meaning that reclaim_page() becomes a per-CPU local thing
under light memory loads.
Of course the current problem with that code is truncate
and the lock ordering between the pagemap_lru_lock and the
page_cache_lock ... something to look at later.
kind regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
-
Stuart Young
>How about extracting patches from lkml with procmail?
>
>---cut here-->8---
>:0 :
>* ^sender: linux-ker...@vger.kernel.org
>* ^subject:.*patch
>{
> :0 Bc:
> * ^--- .*/
> * ^+++ .*/
> linux-kernel-patches
>}
>---8<--cut here---
>
>This recipe has its limits, but it's a start.
Actually I was sort of thinking that maybe part of the problem with our
current system is the noise-to-signal ratio of lkml itself.
Perhaps it's time we set up a specific lkml-patch mailing list, and leave
lkml for discussions about the problems. Have a script that posts general
details about patches on lkml when there is a post to lkml-patch if you
like, so people know and can go and take a look if they want. If you get
complex, it can vet the patches to see if they apply, before pushing them
to the list. It also goes well with some sort of patch tracking system (who
says we can't use a mailing list as a distribution mechanism), if that gets
the go ahead, while not requiring it.
Another possibility (or could even be combined) is that perhaps we need to
start separating the mailing list at the code tree level.
eg: The "development" tree (lkml-dev which would currently contain 2.5.x)
from the "stable" tree (lkml-stable which would currently contain 2.4.x)
from the "older" trees (lkml-old which would currently contain
2.2.x/2.0.x), at the mailing list level.
That way, people can concentrate on a specific tree (eg: Linus could
concentrate on 2.5.x), without getting inundated with all the other stuff.
This progresses easily when the next "stable" branch hits, so that the
"dev" list can keep talking about what they plan to do while waiting for
the stable to fork into the new development tree, and the previous stable
joins the ranks of the "old" kernels, where it might possibly still get the
occasional fix.
By reducing the noise (and hey, there is a reason people black-list certain
subjects on lkml apart from personal/flame war issues), people can
concentrate on the facts. The less noise (the less traffic?) the more
likely every message will be read, patches will be checked, etc. Especially
when you have other "duties" apart from maintaining kernel code, it's not
always easy keeping up with lkml.
Stuart Young - s...@amc.com.au
(aka Cefiar) - cef...@optushome.com.au
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
Jeff Garzik
> On Tuesday 29 January 2002 06:13 pm, Linus Torvalds wrote:
> > On 30 Jan 2002, Andi Kleen wrote:
> > > Does that answer your questions?
> > > Would you look at a patch again?
> >
> > That answers the specific questions about Al and Stephen.
> >
> > whether people are happy. Is that the case?
>
> you?
So, you think "somebody" is willing to track all kernel issues and patches?
I don't think that's possible for any person or automated system. [it's possible with a
combination of -people- and -automation-, IMHO, though]
> > Also, obviously nobody actually took over maintainership of the patch,
> > because equally obviously nobody has been pinging me about it.
>
> I.E. patches get dropped, even when there's intense interest about them, due
> to sheer frustration burning out the patch's maintainer, and scaring away
> other potential maintainers. (Is this NOT the case? I could be wrong.
> Please point out the flaw in my logic...)
I would point out a flaw if I actually saw any logic...
Are you talking about the EA patch? See Nathan's response and other responses in this
thread.
> > For some
> > reason you seem to want _me_ to go out of my way to search for patches
> > that are over a month old that I don't know whether they are valid or not,
> > used or not, or even agreed upon or not.
>
> I thought I was actually proposing somebody else be formally tasked with the
> job of doing that...
You clearly do not realize the enormity of the task.
> > But yes, it's so much easier to blame me.
>
> Maybe just to suggest that you could use a secretary?
I suggest that you need a Valium.
Jeff
Jeff Garzik
> Perhaps it's time we set up a specific lkml-patch mailing list, and leave
I like the suggestion (most recently, of Daniel? pardon if I
miscredit) of having patches-2.[45]@vger.kernel.org type addresses,
which would archive patches, and have a high noise-to-signal ratio.
Maybe even filter out all non-patches.
The big issue I cannot decide upon is whether standard e-mails should be
To: torvalds@
CC: patches-2.4@
or just
To: patches-2.4@
(I'm guessing Linus would prefer the first, but who knows)
Also, something noone has mentioned is out-of-band patches. Security fixes and other
patches which for various reasons go straight to Linus.
Jeff
Francesco Munda
Padraig Brady <pad...@antefacto.com> wrote:
> Currently the way I see it [should be] currently is:
>
> [cut-n-pasted graph]
>
> I.E. Linus just gets input from the combiners which
> test logic from the maintainers in combination. Also
> random hackers should input to the combiners and not Linus
> if there isn't an appropriate maintainer for their code.
Quite descriptive and useful, thanks.
Let me raise a point. And extend your graph:
random hackers
| | | | | | |
| maintainers -< subsys testers
| | | |
combiners -< tree testers
| |
Linus
Who you call combiners... How many of them should release independent trees
to be thrown at us test-dogs? My point of view is neither the hacker, nor the
maintainer nor the combiner one. Nor Linus, thank god! :) It's the guy who
risks his filesystem integrity with some 2.X.Y-preZ-testW-QQ-KK kernel.
How many crosspatched sources I should look at, to try my luck with?
Have fun,
-- Francesco
Stuart Young
>On Wed, Jan 30, 2002 at 12:00:11PM +1100, Stuart Young wrote:
>
>miscredit) of having patches-2.[45]@vger.kernel.org type addresses,
>which would archive patches, and have a high noise-to-signal ratio.
>Maybe even filter out all non-patches.
>
>The big issue I cannot decide upon is whether standard e-mails should be
> To: torvalds@
> CC: patches-2.4@
>or just
> To: patches-2.4@
>
>(I'm guessing Linus would prefer the first, but who knows)
Perhaps it'd be easier for patches-2.4 to actually send a copy to whoever
is the relevant maintainer of a "section" (which could be worked out from
the path in the patch, as long as it's made relevant to linux/) as well as
the 2.4 maintainer? There is a lot of things that can be done here.
>Also, something noone has mentioned is out-of-band patches. Security
>fixes and other patches which for various reasons go straight to Linus.
Perhaps that is a good use for my lkml-patches idea, which gives those who
have no avenue a place to post patches so they get picked up.
Something that does need to be done is that various directories under the
kernel tree need to have someone "who receives patches" for that part, and
who forwards them onto the kernel maintainer (eg: Linus, Marcello, etc) for
further review/inclusion/rejection. This way, anything that doesn't fall
under a particular maintainer gets sectioned off to someone, so it does get
review, and hopefully a reply.
Stuart Young
>Basically, you should always consider email to me to be a unreliable
>medium, with no explicit congestion control. So think of an email like a
>TCP packet, with exponential backoff - except the times are different (in
>TCP, the initial timeout is three seconds, and the max timeout is 2
>minutes. In "Linus-lossy-network" it makes sense to use different
>default and maximum values ;)
Actually it's more like UDP. *grin* Least with TCP we get an ACK that the
connection is accepted, and some sort of status is kept. Not so sure we
have that with you all the time.
But hey, lots of things run over UDP, just a matter of making sure everyone
realizes it's not a guaranteed medium really, isn't it?
Stuart Young - s...@amc.com.au
(aka Cefiar) - cef...@optushome.com.au
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
-
Miles Lane
>
> On Tue, 29 Jan 2002, Chris Ricker wrote:
> >
> > That's fine, but there's a major problem with your scheme. What happens
> > with all the stuff for which no one is listed in MAINTAINERS?
>
> I have to admit that personally I've always found the MAINTAINERS file
> more of an irritation than anything else. The first place _I_ tend to look
> personally is actually in the source files themselves (although that may
> be a false statistic - the kind of people I tend to have to look up aren't
> the main maintainers at all, but more single driver people etc).
>
> It might not be a bad idea to just make that "mention maintainer at the
> top of the file" the common case.
I do similarly when I am testing Gnome software, but there
I have the CVS sources to look at, including carefully updated
ChangeLog files. I find the ChangeLogs and the output of
"cvs log ChangeLog" to be highly informative and helpful when
attempting to track down the appropriate person to contact.
Is it feasible to set up a read-only anonymous cvs server for
the kernel tree? It seems to me that it would be nice to
good to have ChangeLogs for the kernel directories as well.
Miles