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

[Robert Watson]

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