Re: Requesting for review of the Draft proposal for - procfs

[olafBuddenhagen]

Hi,

On Sat, Mar 29, 2008 at 08:40:30AM +0530, Madhusudan C.S wrote:

>      I want to bring few points to your notice, though I had
>      understood the need for GNU/Linux compatibility of the procfs
>      that is to be implemented, I always felt that the GNU System
>      should be always ahead of the GNU/Linux or anyother systems,
>      either in terms of design, or performance or in terms of
>      functionality. So I thought it would be nice to come up with a
>      layered design so that new features can be added easily whenever
>      community feels there is a need which keeps "the Hurd" not only
>      on par with GNU/Linux but ahead of it both in terms of desgin and
>      features.

You are perfectly right in principle :-)

There are two points to keep in mind though:

1. We just don't have the manpower -- and won't have any time soon -- to
do better than the established systems in *every* possible regard. So we
need to rationalize: Concentrate on a few points where we can really
shine, and be pragmatic about all the rest -- reusing as much existing
work as possible at minimal effort. I think procfs falls in the second
category :-)

2. Layering is a good thing, but doing it right is hard. In view of the
first point, the priority is on getting a working procfs at minimal
effort.

Actually, splitting procfs into many translators is a very interesting
project; I think it's a good case on which we could explore such
advanced designs. But it's a different project, perhaps for next year's
GSoC, or outside of GSoC alltogether. It's not what the current procfs
task is about.

> "I am sorry I agree that I have over-engineered things, it was all in
> over enthusiasm to contribute to "the Hurd" community.

No harm done :-)

> > Modularity in the Hurd is not achieved by sophisticated layering
> > within one process. Rather, it is achieved by splitting
> > functionality into individual servers (translators).
> >
> > As Frederik already pointed out, one thing that we could do is
> > splitting out the global bits, like /proc/uptime etc. into
> > individual translators -- they are pretty independant, and there is
> > really no good reason to implement them all in one translator. Each
> > of these files could be easily provided by a simple trivfs-based
> > single-node translator.
> >
> > The per-process information, which form the core of procfs, are more
> > tricky. Ideally, we could use a multiplexer, which launches
> > individual translators for each pid and possibly also for each piece
> > of information per pid. However, we have very little experience with
> > doing such things efficiently. This is definitely outside the scope
> > of this project.
> 
> 
> Since I am not 100% sure of using multiplexers and since I was not
> able to go through Documentation to this stuff due to the time
> constraints at the moment, I will not comment on this now. Since you
> have already said that its outside the scope I hope I can leave this
> for now.

Of course :-)

I didn't expect you to comment on the multiplexer design; I only
mentioned it to show in which direction things should go ideally. But as
I said, this is not part of your project; so you don't need to worry
about it now :-)

> Your plan looks pretty sound all in all; but I have some doubts about
> > the middle phases (3-5): You want to work layer by layer. This is
> > problematic, because if the project turns out harder than expected,
> > and you can't complete it all, we are left with no visible
> > improvement at all...
> 
> 
> I am sorry but I still want to mention that there is no room to think
> whether I would complete the project or not. GSoC or no GSoC or after
> GSoC I assure that I will continue my commitments with "the Hurd"
> community. We will always have some visible improvements. I have
> mentioned in the proposal why "the Hurd" is so close to my heart and
> why I contribute to the GNU system, also why I chose Hurd of all the
> other organizations for GSoC.

Well, I'm glad to see so much commitment :-) But part of the GSoC deal
is that we have to assess the success of the project both at mid-term
and at the end. This is hardly possible if you are stuck in some
internal layer without visible progress...

I hope you understand that this is not meant as any slight on you, but
simply a necessary precaution.

Personally, I think that incremental development is generally better --
having continuous feedback both in terms of visible functionality and
internal design always helps. (Trust me, in the past I slipped on the
error of implementing something layer by layer myself...)

But in the case of GSoC, it's not really a matter of personal taste;
it's pretty much unavoidable.

> I think it makes much more sense to implement/fix the individual bits
> of
> > information one by one. (In fact, you could try to implement one of
> > the easiest bits even now during the application phase, to convince
> > us of your programming skills :-) )
> 
> 
> I am working on this. I will try to do atleast one implementation
> during this application phase. Since monthly tests are going on in the
> college I have not been able to invest much time on this part, i.e
> starting the implementation since I am hardly getting to prepare the
> proposals. I will try my level best to show you some code atleast
> before the proposal process ends by April 11th or 14th, is that OK?

Yes of course, it's perfectly fine as long as you show something before
April 11th :-) (Two days or so in advance would be nice though...)

Also, don't wait until you have finished it. Give us feedback on your
progress, and ask whenever you encounter problems -- that's how GSoC is
supposed to work! :-)

BTW, there is a problem: We have another very promising application for
the procfs task. If we want to take both of you, one would have to
switch to a different task. Would you be willing to work on something
else as well? I know it's unfortunate, as you have already put so much
work into this one... But you surely could reuse most of what you
learned in the process :-) Please contact us on IRC if you are unsure
which alternate task to pick.

I will ask the officials whether it's allowable to change the task after
the end of the application process. If not, it would be good if you can
submit in a second application, for another task. I'm perfectly aware
that this second application couldn't be nearly as complete as this one;
but that's OK -- we will take that into account :-)

I will let you know whether it is indeed necessary to hand in a second
application as soon as I know more.

Oh, and I really think that you should submit your draft application(s)
to the official form ASAP. You can update them with your revised
versions afterwards; but it would help us to have it already listed
among the other applications...

-antrik-