On Fri, 28 Jul 2006, Alexander Leidinger wrote:
BTW, a problem that has occurred a number of times in the past is that
people have approached us with implementations of ideas in the idea list
that it has later transpired we aren't actually interested in (sometimes at
all). I think it might not be a bad idea to sprinkle the
My impression is, that we lack some committers which not only have time to
review the submissions, but also have the necessary domain specific
knowledge at the same time.
I suggest marking unreviewed ideas as unreviewed then. My biggest concern is
that we have people who come along, see the idea, implement it, and it's then
dropped on the floor because it turns out we didn't really want it, but it was
on the list. If we don't want it, we shouldn't list it. If we're not sure if
we want it, but think it might be neat, then we should say that's why it's on
the list, so as to avoid misunderstandings.
idea list with some additional cautionary language -- often ideas listed
there are things to explore, not to adopt without very careful
consideration. For example, the "FPU subsystem overhaul", "Process
Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the review
(or I don't remember it), but so far it looks like it would be beneficial to
commit it (AFAIR). I'm not able to review the code (I lack the necessary
domain specific knowledge), but I wanted to give it a try on my system and
then send a mail to arch to get some technical reasons why to not commit
commit it.
Similar for the new TCP checksumming code. Initially there was a problem, it
got fixed, and now nobody takes care of it since everyone seems to think
"it's flawed". At least this is the impression I got.
I have no specific technical opinion on either of these items.
Some of the ideas on this list are distinctly "explore this direction as a
computer scientist, not a code hacker" sorts of problems -- for example,
the "Process checkpointing" task seems to suggest that if you can read the
DFBSD repository and write some C code, you're set. In fact, this is not
remotely the case. Checkpointing is a very difficult problem in computer
science, with little consensus on how it should be done (and indeed whether
it should be done at all) by general purpose operating systems. Not only
that, but we would not adopt the DFBSD implementation as-is, as it solves a
few of the easy problems, and none of the hard ones (i.e., security). The
requirements here aren't just the ability to write code, but an
understanding of distributed systems, our application/execution model, a
strong understanding of the performance and security requirements, and
willingness to not just look at code but the extensive research literature
on this topic.
AFAIR the process checkpointing in DFly has to be enabled (or am I mixing
this up with the magic symlinks?) in the kernel. And the man page contains
some text what is possible and what not, and about security implications.
Yes, they don't use a model which is able to solve all cases, but for some
cases where the programs (those which don't make heavy use of I/O and thus
can open/close I/O channels when they are needed) are written to make use of
this feature, you can make some users happy and the developers can
concentrate at the problem at hand. So it's one of those 80/20 solutions.
While I agree that a 100% solution would be nice, I think an implementation
of this in -current would be nice to have.
It's a neat/fun hack, but I would object strongly to the current
implementation going into the tree. I think 80/20 is a mischaracterization.
We need some reviewers here... while I'm able to come up with a nice
technical description of roughly expressed ideas (as long as I get the
idea), I'm not a TRB and as such aren't aware of every implication. And some
ideas are expressed in a way which make them sound like it's "common
knowledge to people which work in this field" (ATM I refer to the NFS lockd
in kernel implementation idea).
Given that we can't get the user space code to work and don't have an owner
for it (it appears to be abandonware), I think moving it into the kernel would
be a disaster. We've been discussing ripping out the current user space code
entirely on the basis that it is responsible for a huge number of bug reports
and lots of problems.
So: helping hands are welcome!
Thanks for taking some time to review some parts of the list.
I'll try to take a look through the rest of them later today.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
