[Top][All Lists]

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

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

From: Madhusudan C.S
Subject: Re: Requesting for review of the Draft proposal for - procfs
Date: Sat, 29 Mar 2008 08:40:30 +0530

Hi Olaf, Fredrick and all,
          Thanks a lot for all the suggestions and comments. I am sorry for all the misconceptions. I am reworking on the entire proposal so that meets the requirements of "the Hurd" community.

     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.

   But understanding that Free Software is not all about what I want but its all about what the community wants, I have considerd all the suggestions from you people and am reworking on the proposal so that my design falls in line with "the Hurd"'s needs at the moment, i.e a working totally GNU/Linux compatible monolithic design.

> The next stage of the project is to develop a standard set of
> functions(I will call this as Intra-procfs Programming
> Interface(IpPI)) which provides basic functionalities required to
> setup a virtual filesystem, in particular procfs. These are nothing
> but the callback functions that use the services of the libnetfs
> library but provides the interface to implement procfs in particular
> (Advantages in Benefits section).

I'm not sure such a middle layer is really necessary. Don't
over-engineer. Start by implementing the actual functionality, and only
if you indeed encounter a lot of code duplication, think about improving
the infrastructure... Think KISS and YAGNI :-)

I really understood what I had done after seeing your comment with the above "KISS and YAGNI" phrase. I am sorry I agree that I have over-engineered things, it was all in over enthusiasm to contribute to "the Hurd" community.

> One can now think of procfs problem comparable to networks problem in
> which monolithic designs were replaced by layered designs through OSI
> reference model and more practical TCP/IP architecture resulting in a
> robust design of networks. Similarly by layering the design of procfs
> which includes 3 layers 1.Intra-procfs PI 2.The core functionalities
> of procfs 3.procfs API We are making procfs system highly robust,
> reliable. So if new functionalities are to be added, its just a matter
> of using the IpPI. Also if some functions are to be changed its only a
> matter of changing the implementation of the function without
> affecting the other two layers and this applies to those two layers
> too.
> The above discussed benefit is more in compliance with the highly
> modular approach of Microkernels and I feel this falls in line with
> the Hurd philosophy.

I understand your goal of achieving modularity; but that's not the right
way of doing it. 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.

While it might be interesting to look into such possibilities, should
you be able to finish the main functionality before time, I suggest to
completely leave it out of the plan, and stick to the existing
"monolithic" design for now... Getting a functional and compatible
procfs is presently much more important than experimenting with more
elegant design choices :-)

Yeah understood, working on the proposal.

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

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.

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.

Thanks and regards,

reply via email to

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