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

[Carl Fredrik Hammar]

Hi,

> Hi Carl,
> Thanks a lot in spending your invaluable time in going through my
> proposal.

No problem.  Also, I go by Fredrik not Carl, a misconception that is
easy to make since I don't abbreviate it.  :-)

> [snip]
>
>   I suspect you will need to narrow down your feature list a bit.  Not
>   so much because any item is particularly hard, but they cover a lot of
>   ground.  The information needed to implement them are spread
>   throughout the Hurd, glibc and mach, it might be quite a bother to
>   hunt it all down.
>
> Yeah few people who did a review for me too said that I have over
> committed. I don't think its too much or an over commitment (maybe a a
> bit). Its all done with huge enthusiasm and zeal, maybe I am not feeling
> so because of that. I will be able to tailor my proposal so that I can
> complete everything I have committed if some mentors review it. Whats your
> take on this??

If you really think you can do it, then leave it as is.  If nothing
else your mentor will most likely let you scale down the list if you
later find out that you've bitten more than you can choose.

> Thanks for your concerns anyhow.
>
>   Also, procfs is mainly used to provide compatibility with linux.  So,
>   if /proc/<pid>/mem isn't used in linux it won't be used in the Hurd.
>   (I'm not sure it isn't used, but you made it sound like that in your
>   proposal.)
>
> I am sorry if I sounded so, what I was trying to say was that the write
> functionality to /proc/<pid>/mem has been disabled in Linux kernel due to
> some vulnarebilities as far as what I have read. I have also given the
> link to that in the previous mail. I will make the corresponding changes
> to make it clear in my proposal. Thanks for bringing it to my notice.

Oh, ok then.

> [snip]
>
> Exactly. Thanks a lot for understanding. This is what is my plan at the
> moment. IpPI is nothing but a refinement of libnetfs or more clearly
> procfs specific libnetfs, in your terms libprocfs. This is done for two
> reasons,
>
> 1.  To make the design robust, I dont want the effort who ever puts to go
> waste at any point in time. After procfs implementation is nearly done(I
> dont mean it will be over once for all, I only mean that once procfs has
> the required functionalities that is intended till now. I do understand
> that Free Software Developement is a never ending process of software
> development, improvement and community bonding and interaction and I also
> assure that I will continue my association with Hurd for ever, even after
> GSoC since I simply love GNU and Microkernels), and Hurd has a new library
> which is better than libnetfs for some reasons, one should be in a
> position to only change the Interface which uses these libraries and not
> the whole procfs implementation(very similar to what happened before OSI
> reference model came into picture, now with OSI or more practical TCP/IP
> one needs to change only the layer which must be changed and its interface
> with the layers above and below).
>
> 2.  The reason you said, it should make the users' life easy to add new
> features to procfs.

It seems we are on the same page.  :-)

>   This is not a problem, you can put a url to it in the proposal.  If I
>   recall correctly, there is also a specific field for linking in more
>   information.
>
> Thanks a lot, but I need to submit a proposal to Google which is less than
> 7500 characters. And I want the less than 7500 characters proposal to be
> in complete in its own sense, and mentors need to see the external link
> only for additional details, Am I right in this way? Please suggest me.

I only meant that you're on the right track.  So, yes, you're right!
:-)

Regards,
  Fredrik