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
