Re: cvs commit: www/en/projects/ideas index.sgml

Quoting Robert Watson <rwatson@xxxxxxxxxxx> (from Fri, 28 Jul 2006 09:52:33 +0100 (BST)):

[moving to hackers@... feel free to redirect if you think there's a more appropriate list]


On Fri, 28 Jul 2006, Joel Dahl wrote:

Modified files:
en/projects/ideas index.sgml
Log:
- Extend the ktrace project with a new task. [1]

[adding some warnings to this project]

Thanks for reviewing and the heads up regarding problems which may arise. Yes, we should add them to the entry.

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.

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.

checkpointing", "Pluggable disk shceduler", "Magic Symlinks", "NFS
Lockd (kernel implementation)", and several others -- the task here
often isn't to port/write the code, the task is to port/write and then
perform a detailed and careful evaluation of the changes to decide
whether they are a good idea, and then consider adopting the code only
if the evaluation suggests it is a good idea and after significant
refinment.

So far we got not much responses from committers/developers. There's a lot of interest in working on some of the entries, but so far we don't get much review for the entries/ideas themself. Any refinement is welcome and appreciated. So if someone has some thoughts about specific entries: please, share them with us.

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.

I think people often grab ideas from the list thinking that if
implemented as described, they will get committed, and this is not the
case. In many of the sorts of "scientific" cases it's likely we'll
look at the results and say, "Oh, that was a bad idea", or maybe
slightly more likely, "Oh, hmm, not so sure about that". The existing

Joel and I already talked briefly about an "we don't do that" or "been there, done that, wasn't a good idea" page because of this.

cautionary language captures that there might be disagreements on the
specifics, but fails to capture that there may be disagreements on the
fundamental ideas themselves. I like the ideas list idea a lot, and

Ok, we should change that. Thanks for providing a big picture view for those of us which don't see the forest while sitting in front it...

don't want to see it removed, but I also don't want people getting the
false impression that this is a "todo" list. Some items are todo items
and obvious short-order commit candidates, others are out-there ideas
that have potential and should be characterized as "high risk" when it
comes to the results actually being used. Maybe what we should be
thinking about is classifying the todo list items into rote items
(things where the chances of adoption of a decent implementation are
high, subject to review) and researchy things (where the chances of
adoption are low, not just because the chances of a good implementation
are low, but because there are lots of open and very difficult
questions involved). This would help prevent misunderstandings, if
nothing else.

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).

So: helping hands are welcome!

Thanks for taking some time to review some parts of the list.

Bye,
Alexander.

--
All great discoveries are made by mistake.
-- Young

http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: cvs commit: www/en/projects/ideas index.sgml
    ... 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'm not able to review the code, 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. ... 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, I think moving it into the kernel would be a disaster. ...
    (freebsd-hackers)
  • Re: Patch for MS Hyper V (virtualization)
    ... >the Hyper-V VM with it so the host also can't shutdown or reboot ... I don't have the commit =permission any more but I can review :-) ... the problem is we need to be able to write to BARs to size them. ...
    (freebsd-hackers)
  • Re: New preview patch for ipfw to pfil_hooks conversion
    ... On Tue, 22 Jun 2004, 13:38+0200, Andre Oppermann wrote: ... Please HEADSUP us before commit or drop me a note, ... review reass/ip options code as I spent a lot of hours parsing it. ... Maxim Konovalov ...
    (freebsd-net)
  • Re: [PATCH] w35und: fix registration with wlan stack
    ... lets see if we can get some more review on this: ... commit 87290671d60a4f0e734f389a266b13d71c275ce4 ... tree c8e312a3ef0b0d250c1e605ce86bff94c0254847 ... parent e6de9be58f118cba6ccfef28830db701b8cc9f46 ...
    (Linux-Kernel)
  • Re: Comments from a new user: what is Distrowatch complaining about?
    ... Richard Hughes Wrote: ... I'll commit some code after some UI ... review. ... it's downloading (e.g. as one sees in URPMI, APT and Smart Package ...
    (Fedora)