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-
