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

[Carl Fredrik Hammar]

Hi,

I was the student in GSoC last year, just thought I'd share my
acquired wisdom and drop some comments on your proposal.  :-)

> [snip]
>
>   I have come up with this draft proposal so that we can discuss further
> based on the this proposal. I have roughly consolidated my ideas from the
> above mentioned sources. So I request all of you to please go through the
> draft proposal I have come up with.
>
> My proposal is available at:
> http://madhusudancs.byethost13.com/content/gnu-hurd-procfs-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.

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.

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.)

> [from the proposal]
>
> 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).

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.


> [snip]
>
> Another important note is that, this document is the detailed proposal
> I have written. I have put all the ideas in my mind together so as to make
> it clear to you people about what I am thinking. This proposal is nearly
> 13,000 characters and in no way I can submit this through Google Applet
> since it restricts the lenght to 7,500 characters. My final submission
> must be a heavily tailored version of this document. I have thought of
> cutting down the description of each of the core functionalities I have
> written in project details part and also the details of the schedule,
> since I will be making the full version of this document available through
> my blog. I request you people too to suggest me which other parts require
> tailoring.

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.

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

Regards,
  Fredrik