[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requesting for review of the Draft proposal for - procfs
Re: Requesting for review of the Draft proposal for - procfs
Sat, 29 Mar 2008 20:58:40 +0100
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
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
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
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
> > 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...
Re: Requesting for review of the Draft proposal for - procfs, olafBuddenhagen, 2008/03/27
Re: Requesting for review of the Draft proposal for - procfs, Madhusudan C.S, 2008/03/29
Re: Requesting for review of the Draft proposal for - procfs, olafBuddenhagen, 2008/03/30
- Re: Requesting for review of the Draft proposal for - procfs, (continued)