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: Madhusudan C.S
Subject: Re: Requesting for review of the Draft proposal for - procfs
Date: Thu, 27 Mar 2008 19:50:41 +0530

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

Gave it a quick read-through and it looks pretty good to me.  I'm not
that familiar with procfs though, I've mostly just used it to set some
networking settings and checking my notebooks battery level.  So I
can't comment on which parts are important or easy.

Thanks for the compliments. Ok no problem, I hope atleast one of the potential mentors will comment on which parts are important.

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

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.

This is where things get interesting for me and I would like to hear
more on your plans for this.

As I see it, procfs should not be a single translator.  Rather, there
should be split into distinct parts, e.g. a couple of /very/ simple
translators for `uptime', `version' etc. and one handling all the
`<pid>' directories or possibly several ones merged together using
unionfs.

This way, if a user is missing some functionality from the latest and
greatest linux procfs, all the user would need to do is write a new
translator and use settrans to benefit, instead of hacking a
monolithic procfs implementation.

Thus I think the best design of an IpPI would be to refine libnetfs
into a libprocfs.  To make it very easy if not trivial to write such
translators.

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.

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.

Also the link to procfs is broken, it seems your blog was helpful
enough to escaped that ampersand in there for you.  ;-)

Thanks. I fixed the link.

In addition to all this I request Hurd Developers to review my proposal. I also kindly request potential mentors too to review this proposal. If you want me to be in IRC, please tell me the time. I will try to make myself available at that time.

--
Thanks and regards,
Madhusudan.C.S


reply via email to

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