bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carl Fredrik Hammar
Subject: Re: Requesting for review of the Draft proposal for - procfs
Date: Sat, 29 Mar 2008 16:08:21 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Hi,

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

This is perhaps the root of the misunderstanding, we don't need to be
ahead of linux when it comes to procfs.  procfs should only provide a
different interface to features /already/ present in the Hurd, i.e. a
compatibility layer.  Your desire to propel the Hurd beyond linux is
misplaced, that should be done outside of procfs.

And just to clarify, there's nothing wrong with your layered design
per se.  In fact we encourage it, as it will allow others to easily
add features to procfs, not to get ahead of linux but to catch up when
we find ourselves missing a feature required by an useful application
that we would like to port to the Hurd.

It's just better for us if you focus on first just making it work so
that we can make use of it, and then come up with a nice design.  It
is also better for you, as you'll get practical experience of how
stuff works in the Hurd, and thus a better foundation for coming up
with a good design.

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

Please understand that we can't really take your word for it.  Of
course, we all hope you do keep contributing, but we also have to
consider the worst case scenario.

(I'm not in any way implying that you might be lying.  Shit happens
and you might not be able to contribute because of illness, accidents,
or some other factor that is beyond your control.)

>   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? I request you people to
> understand the difficulties at the moment. I would be happy if I am given
> some time to work. Kindly oblige.

You would have to show it *before* April 10th for it to have any
effect on your chances for acceptance.  Of course the earlier the
better, to give your mentor a chance to review it properly.

Regards,
  Fredrik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]