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
> 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.
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,
Madhusudan.C.S
