DragonFly kernel List (threaded) for 2003-07
Re: Guidelines for tasks?
:> Kip Macy wrote:
:>> I was wondering if you had thought about creating a more fine-grained
:>> set of tasks for working towards your design goals so that individuals
:>> can contribute smaller pieces. Or does it make more sense right now to
:>> restrict work to those who really understand what you have in mind?
:> I agree with Kip in this sense: a "task-tree", some library of existing
:> open tasks that indicates how they are linked with other tasks (that are
:> also in some state of pending/open/complete stage), would enable people
:> to contribute in smaller chunks by taking on tasks, completing them and
:> then dipping in again in some other area. The ability to see how all
:> the tasks relate to one another at any time may encourage those of us
:> who really want to be a part of this exciting project to get involved
:> but who are time-limited in terms of how much they can take on at one
:> time or another. Perhaps some visual/diagramatic representation (on the
:> dragonfly site, perhaps) of such a tree (consisting of data drawn from a
:> development database populated by individuals as they work on separate
:> tasks) would work? Just a thought :) Anyone think of lightweight
:> examples of such a thing rather than having to build one from scratch?
:I'm glad that I'm not completely out in left field on this one. I'm
:CC'ing Matt this time in case he missed the message by accident.
Well, I agree with the concept. I'm not sure about a visual
representation but we could create nested dependancies on a web page
It's good to talk about this now because, as I have said, within a week
or two a significant number of in-kernel codepaths are going to become
available for external development.
I am really only pre-committing myself to certain large scale one-man
projects. DEV messaging infrastructure, VFS messaging infrastructure,
VFS name cache rewrite, initial SYSCALL message wrapping, and a few
others that are basically one-man jobs which touch dozens or hundreds
of files and get the subsystem to the point where additional work can
be done in smaller chunks.
e.g. when I do VFS all our filesystems will suddenly be a lot slower
because they won't be reentrant any more, which means work could begin
on making the most important filesystem(s) (ah.. probably just UFS)
When I do the initial SYSCALL work then we immediately open up several
additional projects, such as userland threads support, initial
kernelland (rfork) thread hacks, and ultimately asynchronization of
those system calls which can non-trivially block (mainly I/O calls).
As I write down these things I am slowly going to build up a simplistic
work tree in the Status section. Some better way of organizing it
might be in order.