At our site we store all user (~4000 users) data centrally on several NFS servers (running solaris up to now). In order to ease administration we chose the approach to mount each user directory direcly (via automount configured by NIS) on a NFS client where the user wants to access his data. The most important effect of this is, that each users directory is always reachable under the path /home/<user>. This proofed to be very useful (from the administrators point of view) when moving users from one server to another, installing additionl NFS servers etc, because the only path the user knows about and sees when e.g. issuing pwd is /home/<user>. The second advantage is, that there is no need to touch the client system: No need for NFS mounts in /etc/fstab to mount the servers export directory and so there are no unneeded dependencies frpm any client to the NFS servers.

Now think of a setup where no user directory mounts are configured but the whole directory of a NFS server with many users is exported. Of course this makes things easyer for the NFS-system since only one mount is needed but on the client you need to create link trees or something similar so the user still can access his home under /home/<user> and not something like /home/server1/<user>. Moreover even if you create link trees when you issue commands like pwd you see the real path (eg /server1/<user>) instead of the logical (/home/<user>). Such paths are soon written into scripts etc, so that if the user is moved sometime later things will be broken. You simply loose a layer of abstraction if you do not mount the users dir directly. The only other solution I know of would be amd. Amd automatically places a link. But since we come from the sun world, we simply uses suns automounter and there were no problems up to now.

As another not umcommon setup you might think of NAS storage in a larger company. Again you have the choice to mount on a per user basis or you mount the parent directory containing many users. In the latter case again you loose the /home abstraction to some degree.

So I think it would be really good to have at least the option to have more than 256 NFS mounts even if one has to use unsecure ports for this purpose.

the -J4 scheduler patch is available:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.3-pre2-J4.patch
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-J4.patch

there are no open/reported bugs, and no bugs were found since -J2. The scheduler appears to be stabilizing steadily.

-J4 includes two changes to further improve interactiveness:

1. the introduction of 'super-long' timeslices, max timeslice is 500 msecs - it was 180 msecs before. The new default timeslice is 250 msecs, it was 90 msecs before.

   the reason for super-long timeslices is that IMO we now can afford them. The scheduler is pretty good at identifying true interactive tasks these days. So we can increase timeslice length without risking the loss of good interacte latencies. Long timeslices have a number of advantages:

   • nice +19 CPU hogs take up less CPU time than they used to.
   • interactive tasks can gather a bigger 'reserve' timeslice they can use up to do bursts of processing.
   • CPU hogs will get better cache affinity, due to longer timeslices and less context-switching.

   Long timeslices also have a disadvantage:

   • under high load, if an interactive task manages to fall into the CPU-bound hell then it will take longer for it to get the next slice of processing.

   i have measured the pros to beat the cons under the workloads i tried, but YMMV - more testing by more people is needed, comparing -J4's interactive feel (and nice behavior, and kernel compilation performance) against -J2's interactive feel/performance.

2. slight shrinking of the bonus/penalty range a task can get.

   i've shrunk the bonus/penalty range from +-19 priority levels to +-14 priority levels. (from 90% of the full range to 70% of the full range.) The reason why this can be done without hurting interactiveness is that it's no longer a necessity to use the maximum range of priorities - the interactiviness information is stored in p->sleep_avg, which is not sensitive to the range of priority levels.

   The shrinking has two benefits:

   • slightly denser priority arrays, slightly better cache utilization.
   • more isolation of nice levels from each other. Eg. nice -20 tasks now have a 6 priority levels 'buffer zone' which cannot be reached by normal interactive tasks. nice -20 audio daemons should benefit from this. Also, normal CPU hogs are better isolated from nice +19 CPU hogs, with the same 6 priority levels 'buffer zone'.

   (by shrinking the bonus/penalty range, the -3 rule in the TASK_INTERACTIVE definition was shrunk as well, to -2.)

Changelog:

• Erich Focht: optimize max_load, remove prev_max_load.
• Robert Love: simplify unlock_task_rq().
• Robert Love: fix the ->cpu offset value in x86's entry.S, used by the preemption patch.
• me: interactiveness updates.
• me: sched_rr_get_interval() should return the timeslice value based on ->__nice, not based on ->prio.

Measuring the performace of a parallelized kernel compile with warm caches on a 8 way NUMA-Q box. Highmem support is turned OFF so I'm only using the first 1Gb or so of RAM (it's much faster without HIGHMEM).

prepare:
make -j16 dep; make -j16 bzImage; make mrproper; make -j16 dep;

measured:
time make -j16 bzImage

2.4.18-pre7

330.06user 99.92system 1:00.35elapsed 712%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (411135major+486026minor)pagefaults 0swaps

2.4.18-pre7 with J6 scheduler

307.19user 88.54system 0:57.63elapsed 686%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (399255major+484472minor)pagefaults 0swaps

Seems to give a significant improvement, not only giving a shorter elapsed time, but also lower CPU load.

This is the first release moving the pagetables in highmem. It only compiles on x86 and it is still a bit experimental. I couldn't reproduce problems yet though. the new pte-highmem patch can be downloaded from here:

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/20_pte-highmem-6

Next relevant things to do are the non-x86 archs compilation, and I'd like to sort out the vary-IO for rawio and the hardblocksize-O_DIRECT patch.

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/

No you're wrong. Not writing docs wastes the time of other developers. It sends the message 'my time is more important than yours'. In the case of Linus, that may be true, but it's very definitely not true for any other core developer.

It is the responsibility of each developer to prepare at least minimal - but sufficient - documentation for the work they do. Others who specialize in preparing documentation can then use that material as a starting point for preparing clearer, more extensive documentation. But if core developers shirk their responsibility in this area, we will continue to suffer from a chronic shortage of good, current kernel documentation.

i'd suggest to name the /proc/sys/sched/ values the same way the constants are called. Eg. /proc/sys/sched/CHILD_FORK_PENALTY. This makes it easier to communicate suggested parameter changes.

i have a script that dumps the current sched-parameters state:

[root@mars root]# ./getsched
echo 95 > /proc/sys/kernel/CHILD_FORK_PENALTY
echo 3 > /proc/sys/kernel/EXIT_WEIGHT
echo 3 > /proc/sys/kernel/INTERACTIVE_DELTA
echo 200 > /proc/sys/kernel/MAX_SLEEP_AVG
echo 30 > /proc/sys/kernel/MAX_TIMESLICE
echo 100 > /proc/sys/kernel/PARENT_FORK_PENALTY
echo 70 > /proc/sys/kernel/PRIO_BONUS_RATIO
echo 60 > /proc/sys/kernel/PRIO_CPU_HOG_RATIO
echo 20 > /proc/sys/kernel/PRIO_INTERACTIVE_RATIO
echo 200 > /proc/sys/kernel/STARVATION_LIMIT

the script is very simple:

cd /proc/sys/kernel

for N in *[A-Z]*; do echo "echo "`cat $N`" > /proc/sys/kernel/$N"; done

otherwise our approach is identical. This patch would always stay separate, but could be readily applied by people who want more control over the scheduler for development or whatever other reasons.

I have looked at this header file and I do not understand the asm syntax.

In particular the only x86 div instruction I know only returns a 32 bit div result. Because I don't understand the div64 header I cannot see how a 64 bit result is calculated.

I was afraid somebody would say that.

I need look no further than the shelf at my right hand for a full set of Pentium documentation. I do not consider that an adequate substitute for a document expressing the syntax of all machine instructions of a particular architecture in the GNU syntax.

The only excuse I can think of for not having such a document is "we're all so busy we couldn't write it, please use the Intel documentation". Please don't suggest that we have no need for our own documentmentation, written in a form familiar to us.

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.

One thing intrigued me in this thread - which was not the discussion itself, but the fact that Rik is using bitkeeper.

How many other people are actually using bitkeeper already for the kernel? I know the ppc guys have, for a long time, but who else is? bk, unlike CVS, should at least be _able_ to handle a "network of people" kind of approach.

I am, for the USB and PCI hotplug stuff:

http://linuxusb.bkbits.net/

It makes tracking what patches got applied, and which didn't, and forward porting those that didn't to the next release, a breeze.

My trees are world readable, and people are welcome to send me patches against it, or even bitkeeper changesets, but I have yet to receive one of those yet :)

It's certainly possible and there are changes we could make to make it more useful. Right now, there is no record of a change if it goes and then gets rejected right back out; it's as if you patched and then you did a reverse patch.

The good news is that each change (patch) has an identifier, they look like

awc@bitmover.bitmover.com|ChangeSet|20011230212716|39200

and if we kept a record of those that were rejected, it would be trivial for a developer to track whether his change was in/not seen/rejected.

Bitkeeper also seems to have some problems applying out-of-order changesets or applying them partially.

Changesets sent by 'bk send' are also much harder to read than unidiffs ;)

I think for bitkeeper to be useful for the kernel we really need:

1. 'bk send' format Linus can read easily
2. the ability to send individual changes (for example, the foo_net.c fixes from 1.324 and 1.350) in one nice unidiff
3. the ability for Linus to apply patches that are slightly "out of order" - a direct consequence of (2)

There are two issues, one is out of order and the other is what we call "false dependencies". I think it is the latter that bites you most of the time. The reason you want out of order is because of the false dependencies, at least that is my belief, let me tell you what they are and you tell me.

Suppose that you make 3 changes, a driver change, a vm change, and a networking change. Suppose that you want to send the networking change to Linus. With patch, you just diff 'em and send and hope that patch can put it together on the other end. With BK as it stands today, there is a linear dependency between all three changes and if you want to send the networking change, you also have to send the other 2.

How much of the out order stuff goes away if you could send changes out of order as long as they did not overlap (touch the same files)?

here's the deal on this topic. The out of order thing is a much bigger deal for a large open source project than it is for our commercial customers. It's also hard to do correctly, it would take at least a month. Linus has flirted with using BitKeeper multiple times and then gotten distracted. If we had dropped everything and fixed the issues he needs fixed rather than the issues our commercial customers need fixed, we'd be out of business and you'd have the lovely task of trying to make this work in the BitKeeper source. You can believe me or not, but you'd have very little chance of getting it to work, the BK source base is a lot larger and more complex than the generic part of the Linux kernel.

If enough of the kernel people start using BitKeeper and demanding the out of order stuff, we'll do it. The lead time is about a month, so you have to deal with that. On the other hand, if this turns into yet another kernel "she loves, she loves me not, she loves me, she loves me not" about BK, we're not going to fix the out of order stuff until it is the most important issue for our commercial customers.

Hopefully, you'll take this in the spirit in which it is intended. We want to help out the kernel team, that was the reason for writing BitKeeper. We have to survive, however, and that means paying attention to the commercial needs as well. If/when it looks like Linus & Co are serious about using BK, I'll staff a couple of people to address the out of order stuff and commit to a delivery date. It's clear that it is the biggest "gotcha" about BK & the kernel work flow.

i sent 8 different scheduler update patches 5 days ago:

[patch] [sched] fork-fix 2.5.3-pre5
[patch] [sched] yield-fixes 2.5.3-pre5
[patch] [sched] SCHED_RR fix, 2.5.3-pre5
[patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
[patch] [sched] entry.S offset fix, 2.5.3-pre5.
[patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
[patch] [sched] compiler warning fix, 2.5.3-pre3
[patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3

these patches, while many of them are touching the same file (sched.c) are functionally orthogonal, and can be applied in any order. Linus has applied all of them, but he might have omitted any questionable one and still apply the rest.

how would such changes be expressed via BK, and would it be possible for Linus to reject/accept an arbitrary set of these patches?

There is a way to do this in BK that would work just fine. It pushes some work back onto the developer, but if you are willing to do it, we have no problem doing what you want with BK in its current form and I suspect that the work is very similar to what you are already doing.

In your list above, all of the patches are against 2.5.3-pre5. If you did the work for each patch against the 2.5.3-pre5 baseline, checking it in, saving the BK patch, removing that changeset from the tree, and then going onto the next change, what you'd have is exactly the same set of patches as you have no. Literally. You could type the appropriate command to BK and you should be able to generate a bit for bit identical patch.

In BK's mind, what you have done is to make a very "bushy" set of changes, they are all "side by side". If you think of a graph of changes, you started with

[older changes]
v
[2.5.3-pre4]
v
[2.5.3-pre5]

and then you added one change below that, multiple times. If you were to combine all of those changes in a BK tree, it would look like

[older changes]
v
[2.5.3-pre4]
v
[2.5.3-pre5]
[sched1] [sched2] [sched3] [sched4] [sched5] [sched6] [sched7]

and BK would be happy to allow you to send any subset of the sched changes to Linus and it would work *exactly* how you want it to work. If we could get people to work like this, there are no problems. Just to make it really clear you would do this

for p in patch_list
do bk vi sched.c # that will lock it if isn't

hack, debug, test
bk citool # check it in and make a changeset
bk makepatch -r+ > ~/bk-patches/patch.$p
bk undo -fr+ # get back to the same baseline

Here's what people actually do. They make the first change, then make the second change in the same tree that already has the first change, and so on. BitKeeper faithfully records the linear sequence of changes and enforces that the changes propogate as that linear sequence. You can skip some at the end but you can't skip any in the middle.

In your particular case, we really need out of order changesets to allow the second type of work flow and cherry picking. However, a fairly common case is that the changes are all in unrelated files and *even then* BitKeeper enforces the linearity. That's the problem I think we need to fix first, it's not a complete solution, but it is the 80-90% solution. Until we give you a 100% solution, you have to realize that you are making side by side changes and actually do it that way.

If any of this is not clear to anyone, please speak up and I'll try and draw some pictures and add some explanation.

The thing is, bk should be able to do this on its own.

The rule on check-in should be: if the resultant changeset can be automatically merged with an earlier changeset, it should be _parallel_ to that changeset, not linear.

And note the "automatically merged" part. That still guarantees your database consistency at all levels.

Let us assume that you have a tree that looks like

        a -> b -> c

together with modifications "d". Now, "bk ci" (or, because this is more expensive than a plain "ci", you can call it "bk backmerge" or something, and all sane people will just stop using "ci") should instead of doing a plain

        a -> b -> c -> d

it would see how far back it can go with an automatic merge and add "d" at the _furthest_ point possible. So let's assume that "d" really cannot be merged with "b" but doesn't clash with "c", so what you'd create with "bk backmerge" is the "maximally parallel version:

        a -> b -> c
                \
                 > d

Now, you'll say that this is exponentially expensive to do, and I agree. But CPU-time is cheap, and notice that this "backmerge" would be done not in one centralized location, but in parallel at different developers.

(Yeah, my example may look "cheap", but if you do exclusively backmerging, then after a while your trees will have lots of very wide development, and the m,ore interesting backmerge is when you already have

        a -> b -> c -> f

                -> d

                -> e

and you're adding "g", and it doesn't merge with "c" but not with "d" and "e", so you have to test every path backwards to see where you can push it. In this case you'd end up with

        a -> b  -> c -> f

                     -> g

                -> d

                -> e

kind of tree.)

Just how expensive would that be? I'd be willing to make my machine sweat a bit, if it would just automatically generate the most parallel changesets possible.. And I bet you could do _this_ fairly easily if you didn't care too much about trying to be too efficient.

You're saying your merges are perfect. USE that knowledge, and make it do "bk backmerge".

(Once you do backmerge, the false dependencies no longer exist, AND suddenly "bk" actually gives people information that they didn't have before: the revision history actually tells you the _true_ dependencies in the tree, not some stupid "this is the order in which things were checked in" stuff that doesn't add any value that can't be seen from the changeset directly)

Larry, give me that, and I'll promise to use bk exclusively for two months to shake it out..

actually a label that implies a point in time as well as all the change that came before it. Stated differently, it is a set.

Using your graph:

        a -> b -> c -> f

                -> d

                -> e

and the way that people currently think (and thus speak) of these things, saying that you're using a version 'e' kernel is ambiguous because it may or may not have 'c' or 'd'. This ambiguity also complicates the task of reproducing a tree at some known state later.

You, as the center of the known universe may not need to concern yourself with such trifles, but speaking as one of those fabled commercial customers, the ability to say unambiguously say what's been changed (read: fixed) is really important.

All that said, I like your idea about revision graph compression. My concerns might simply be mitigated by being able to insert "release" points (simply a tag that implies/includes all the preceding changesets).

I disagree.

"g" is really just one thing: it is "the changes".

However, you are obviously correct that any changes are inherently dependent on the context those changes are in. And there are multiple contexts.

One context is simply the "when in time" context, which is interesting, as when you serialize all changesets you see the time-wise development. And this is really the _only_ context that BK (and most other source control tools) really think about.

However, in another sense, the "when in time" context is completely meaningless. Should you care what the _temporal_ relationship between two independent patches is? I say "Absolutely not!". The temporal relationship only hides the _real_ revision information, which is what the patch actually depends on.

And note that my suggestion to have a "bk backmerge" does not remove the temporal relationships. All changesets already have a timestamp (they clearly have to have it, just so that you can see when they happened and say "what did this tree look like one month ago?"). So we already _have_ the temporal information, and encoding that temporal information into the "relationship" information actually ends up costing you quite dearly.

I'd say that most (maybe all) of the complaints about not being able to apply changesets in any random order comes exactly from the fact that developers _know_ that temporal relationships are often not relevant. From a development standpoint, temporal relationships are only relevant if they match the _causal_ relationships, and even then you can often find patches that are _caused_ by previous patches, but that are valid on their own (and can indeed be more important, or even completely obviate the need for the original patch).

So what I'm saying is that from a patch revision standpoint, temporal information is useless. You still have enough information to recreate the tree "at time 'g'" by just doing the equivalent of "bk get -c<date-of-g>".

you don't lose that ability. You still have all the information you used to have, you just have even _more_ information. You have the information on not just when the change was checked in (temporal), you have the information on what files/changes it really _depended_ on.

Now, after those arguments, I'll just finish off with saying that I actually agree with you to some degree - as I already said in private email to Larry, I would definitely also want to have a way of stopping back-merging at some point. In particular, when I'd tag a relase (ie something like Linux-2.5.3, I would potentially also want to set a "backmerge marker tag" which basically tells the backmerge logic that it's not worth it to try to backmerge past that version tag.

That would decrease the chance of confusion considerably, and it would also avoid the exponential complexity problem. Let's face it, exponential algorithms can be really useful, but you do want to have some way of making sure that the bad behaviour never happens in practice. A way of limiting the set of changelogs to be considered for backmerging not only means that humans don't get as confused, the computer also won't have to work insanely to try to go back to Linux version 0.01 if a small patch happened to apply all the way back.

Not so hypothetical, and entirely true. Which is, why I suggest that such "deep merging" wouldn't actually go past tags.

Let's face it, the source control tool cannot know what works and what doesn't. The only thing it can ever know about is "what applies". It can take the approach that everything only applies to the last branch - which is the traditional approach, but which introduces dependencies that simply aren't there, and that _cannot_ be cut. This is what bk does now.

But the other approach is to say "whatever applies, applies, and as long as I don't lose revision information I'll move it backwards". That has other problems (as you point out), but now those problems are manageable, and have solutions.

I'd rather take the problem that can be solved over the problem that cannot.

The fact is, development _often_ is in the situation where somebody does a quick-and-dirty fix, and then only later goes in and digs deeper and does the right fix that makes the original fix completely unnecessary.

The way BK works now, if we call the quick-and-dirty fix "A", and the real fix "B", the developer has a really hard time just sending "B" to me. He'd have to re-clone an earlier BK tree, re-do B in that tree, and then send me the second version.

I'm suggesting that he just send me B, and get rid of his tree. There are no dependencies on A, and I do not want _crap_ in my tree just because A was a temporary state for him.

I can't speak for Linus, but my main problem with BK is similar to what you'd described. Here's what I'm usually doing and what I'd like to be able to do with BK:

Suppose I have 5 deltas - A, B, C, D, E. I want to kill A.

I add a branch that consists of B' (B backported to original) and ABB'^{-1}. It joins the original at AB.

I backport C to B'. Now I've got B', C', ABC(B'C')^{-1}. Again, it joins the original branch.

Repeat for D and E. Now I've got the following picture (apologies for BUAG):

* -B'-> * -C'-> * -D'-> * -E'-> *
|                              /
A                            crap
V                            V
* -B-> * -C-> * -D-> * -E-> *

_Now_ I change the direction of last arrow. Yes, it's more or less reverted A. And now I want to consider the top branch as the main history.

IOW, what I want is ability to play revisionist. And it's not limited to removing patches - if I've found a bug in A, I want to be able to add A-fix and move it all way back to right after A. And merge them. B, C, D and E might have changed from that, but that's what I want. Moreover, I might have some junk left in the end (i.e. ABCDEA-fix == (AA-fix)B'C'D'E'noise) and I'd really like to be able to say that (AA-fix)B'C'D'E' is the main history now and other path (ABCDE A-fix noise^{-1}) is buried.

If you can give a way to do that - I'm happy.

I don't want A (or entire old path) to disappear. What I want is ability to have two paths leading to the same point + ability to mark one of them as "more interesting".

I.e. the result I want is _two_ sets of changesets with the same compositions.

And _that_ is compatible with replication - I simply want the new path in revision graph to be propagated. Along with the "this path is more interesting" being written on the new one.

Can that be done? I want a way to re-split the set of deltas. I'm perfectly happy with old one staying around, as long as we remember that results of old and new are the same object and that new is a prefered way to look at the damn thing.

I suspect that it could be doable with with something as simple as "if you ask to merge two identical nodes, I'll just mark them as such and ask which is more interesting". IIRC, BK doesn't require tree topology on the graph - it can have converging branches.

_If_ that is feasible - the rest can be scripted around it.

Ahh, you want LODs. And they neatly solve the problem you described. And a bunch of others. Think of a LOD as a revision history graph. Imagine being able to create a new, empty (or partially populated) "container". That container is a LOD. You can do set operations from one LOD to the other. They are a lot like branches except that they themselves can branch & merge.

The way that we'd do what you wanted is you'd create a new LOD, stick B, C, D, E into it, and make it the default LOD in your repository.

LODs have some very nice attributes - each change is a set element, the LOD is nothing more than a recorded history of what set elements are in this LOD, and you can cherry pick from one LOD to the other. Out of order, sparsely, whatever.

The only restriction is that you have to have all the changes in your graph. There is no concept of a sparse graph. You can trim off stuff that happens after some point but you can't remove points in the middle, even if they are in the other LOD. Is that OK?

Linus first sounded like he'd accept this as an answer and then later it fell out of favor because even though he could hide a bad changeset in another LOD, he didn't want it in the graph at all. I don't know how to do that.

The other gotcha is that LODs are only partially implemented and are going to stay that way until we achieve concensus on how BK should work for you.

right now I'm trying to see if it makes any difference if I try to use BK for a month or two. I seriously doubt it will really "fix" everything, but neither do I think big re-organizations and patch-lists will. But I'd be stupid if I wasn't willing to try something.

(So far, trying out BK has only meant that I have spent _none_ of my time merging patches and reading email, and most of my time writing helper scripts and emails to Larry to make it possible to use BK in sane ways that suit me. And I'll doubt you'll see any real productivity increase from me for a while ;)

I have been working on this quietly and now my pieces generally work, and I am down to dotting the i's, and crossing the t's. As my start of pushing for inclusion I want to get some feedback (in case I have missed something), and to give some feedback so people understand what I am doing.

First the connections.

• I have a patch I am maintaining (kexec) for booting linux and other OS's from linux. This patch is not x86 specific (it does take architecture specific code). It takes as input an ELF file.
• I am working on a native LinuxBIOS port of Linux, and LinuxBIOS takes as an input a ELF formated kernel.
• I need regularly network boot with etherboot, and an ELF formated kernel can be used natively. bzImage needs help.
• It is a pain not when switching platforms alpha/ia32/xxx to have to completely change your toolchain for booting the linux kernel.
• I have a patch that makes the x86 linux kernel natively ELF bootable.

What a bootable ELF formatted kernel is.

• A list of segments that say load this chunk of file at this physical address.
• An 32bit entry point. (64bit on 64bit platforms).
• Code at that entry point to query from the firmware/BIOS the information the kernel needs.

My next step is to integrate all of my pieces and do some cleanup but I have functioning code for everything.

An x86 ELF bootable kernel: ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.elf_bootable.diff

A patch to boot an arbitrary static ELF executeable. ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.eb-kexec-apic-lb-mtd2.diff

A kernel fix to do proper SMP shutdown so that you can kexec on a SMP kernel ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.eb-apic-lb-mtd2.diff

A kernel patch that implements minimal some LinuxBIOS support. ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.18-pre7.linuxbios.diff

A standalone executable to adapt an existing x86 bzImage to be an ELF bootable kernel. ftp://download.lnxi.com/pub/src/mkelfImage/mkelfImage-1.12.tar.gz

A first draft of a specification that goes into detail about how an ELF image is interpreted, and extensions that can be added so the bootloader name, the bootloader version, and similar interesting but functionally unnecessary information can be passed to the loaded image, and so the bootloader can find out similar kinds of information about the ELF executable it is loading. ftp://download.lnxi.com/pub/src/linuxbios/specifications/draft1_elf_boot_proposal.txt

For what it is worth I have gotten fairly positive feedback from both the Etherboot and the LinuxBIOS communities so far. And etherboot and memtest86 have both been modified already to be ELF bootable. And there is current work that gets a long ways with Plan9.

My kexec work is direct competition to two kernel monte, bootimage, lobos. I have been using it in production for about a year, and I haven't encountered real problems. The biggest issue I have had is with the kernel not properly shutting down devices.

In the short term shutting down devices is trivially handled by umounting filesystems, downing ethernet devices, and calling the reboot notifier chain. Long term I need to call the module_exit routines but they need a little sorting out before I can use them during reboot. In particular calling any module_exit routing that clears pm_power_off is a no-no.

Also while it should work in most cases any loaded ELF image that starts using BIOS/firmware services to drive the hardware is on it's own. Putting all devices back in a state that they match the firmwares cached state is a poorly defined problem. However normal firmware calls that ask if for the memory size or IRQ routing information should work correctly.

More on etherboot can be found at: http://www.etherboot.org

More on LinuxBIOS can be found at: http://www.linuxbios.org

the LVM2 software is ready for beta testing.

This is a complete reimplementation of the existing LVM system, both driver and userland tools.

We encourage you to give it a try and feed back your test results, bug-fixes, enhancement requests etc. through the normal lists linux-lvm@sistina.com and lvm-devel@sistina.com.

The new kernel driver (known as "device-mapper") supports volume management in general and is no longer Linux LVM specific. As such it is a separate package from LVM2 which you will need to download and install before building LVM2.

ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz

The userland tools are available from here:

ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz

This release does not support snapshots or pvmove. These features will go into a subsequent beta release, hopefully within the next fortnight.

This is Beta software which is *not* meant to be running on your production systems. If necessary, keep backups of your data and LVM metadata (/etc/lvmconf/*).

The LVM2 sofware no longer uses a particular driver which is just usable for its own purpose. It rather accesses a different, so-called 'device-mapper' driver, which implements a generic volume management service for the Linux kernel by supporting arbitray mappings of address ranges to underlying block devices. Because this is a generic service rather than an application within the kernel, it is open to be used by multiple LVM implementations (for eg. EVMS could be ported to use it :-)

The device-mapper driver is under the GPL and our Beta1 release dated Wednesday, which included the LVM2 tools as well, supports 2.4 kernels. We are aiming to get it integrated into the stock kernel and are implementing the necessary changes (bio interface) for 2.5 now. We released a device-mapper library (implements a generic API for the device-mapper) which is under the LGPL with it.

The LVM2 tools have a library with routines to for eg. access the device-mapper library, deal with LVM metadata (VGDA), support different metadata formats and offer configuration file support which is under the LGPL as well. The tools themselves (vgcreate, lvcreate, ...) are under the GPL.