Student for GSoC 2008 - procfs

[Madhusudan C.S]

Hi all,
 Sorry all of you. I am extremely sorry for being so late in sending
this mail. I am a prosepective GSoC 2008 student. I am very much interested
in the idea of implementing procfs on HURD. This idea was proposed to me on
our LUG (BMSLUG) mailing list a year
back[1].
Back then I had very less knowledge of HURD and any UNIX system or their
variants in general as a programmer though I was using GNU/Linux just like
an end user from 3 years then. So I did not take up the task then. Now I am
much used to GNU/Linux and have learnt general API programming on UNIX
systems. Though I have not contributed any code to the Linux Kernel
directly, I have a little understanding of how the code is structured and
how it works.

   So as soon as I saw the idea on the proposed projects list on 24th I was
very much inspired and motivated to take this project for this Summer. I
immediately thought of working on this. And I thought I could post to the
mailing list once I have a fair understanding of the proc filesystem. Hence
the delay in posting. I did go through few guides and tutorials on procfs on
GNU/Linux system. Main guides include
[2]and
[3] . I am also going through the
procfs Documentation in the Linux 2.6 Kernel source located at
kernel-source/Documentation/filesystems/proc.txt[4].
Please give me some time to go through it fully since it is a pretty huge
documentation and it takes some time to digest it. I hope you guys
understand how difficult it is to understand things for beginners like me in
the beginning.

  I have a working Installation of the GNU system[Debian GNU/HURD K-16], I
checked out the CVS code of procfs in the hurdextras repo. I also read the
Documentation thats there in the CVS, the
READMEfile[5].
I am also going through the code. I hope you people understand that
going through the entire code and understanding in less than 5 days is quite
difficult for beginners. Kindly co-operate. I will defintely go through the
code. Though I have understood what translators are I am not aquainted with
translator programming. I am also learning that part still. Since the
requirement says this project would require "learning translator
programming", I am learning it from HURD Hacking Guide.

   Since Google has given us the whole of April and May to build a strong
relationship with the community, I will utilize this time to become well
versed in translator programming, general HURD programming and Hacking and
also with the current implementation of procfs in HURD. I will also utilize
this time to draw a neat plan of what needs to be done(though we would have
comeup with a rough plan while submitting the application itself, at this
stage I would like to refine things and make the plan rocksolid). So as soon
as SoC begins on May 28th I can start right away with coding.

   So I request you all to guide me through this process and help me come up
with a proposal. I think its bit difficult to port all the features in
GNU/Linux procfs to HURD in 3 months by a single person, though its not
impossible(I also think its not necessary to port each and every feature
thats available in GNU/Linux). So by having a discussion here we can
finalize on what are the most important requirements that we need to focus
at the very moment and draw a schedule for this summer so that the goals can
be reached.

   I think most important of all the features that are to be made available
are proc//* features which are very important to implement process
related functionalities. So we need to focus on it at the moment.
Those features include
/proc//cpu
/proc//cwd
correcting the problems in /proc//environ
/proc//mem
completing /proc//stat
/proc/cmdline
/proc/swaps

We can also think of /proc//attr/* features if they are feasible and if
you people suggest to go ahead.

What are your suggestions? Please Help me.

(This is only a rough idea of what can be done. I will draw the plan after
discussion here is complete. I am open for all your inputs. I will be
available in #hurd at the time which is convinient to you all. Please inform
me so I can make myself available at that time. Please help me.)


[1] 
http://groups.yahoo.com/group/bmslug/message/361
Please see this if you have access to this post. The mailing list is not
moderated.
[2] 
http://www.aoc.nrao.edu/~tjuerges/ALMA/Kernel/procfs-guide/index.html
[3] 
http://www.nirendra.net/cms/procfs/user
[4]
http://users.sosdg.org/~qiyong/lxr/source/Documentation/filesystems/proc.txt

Re: Student for GSoC 2008 - procfs

[Madhusudan C.S]

Hey,
   I am sorry I forgot to make a mention of this. As its mentioned in
the proposed ideas page I will also considering writing the code in libnetfs
rather than libtrivfs whereever possible.

-- 
Thanks and regards,
Madhusudan.C.S

Re: Student for GSoC 2008 - procfs

[Madhusudan C.S]

Hi all,
  Sorry for few mistakes in the mail, I was quite excited while
writing this mail.

So as soon as I saw the idea on the proposed projects list on 24th I was
> very much inspired and motivated to take this project for this Summer.
>

The date there is March 17th and not 24th. Excuse me.

Since Google has given us the whole of April and May to build a strong
> relationship with the community, I will utilize this time to become well
> versed in translator programming, general HURD programming and Hacking and
> also with the current implementation of procfs in HURD. I will also utilize
> this time to draw a neat plan of what needs to be done(though we would have
> comeup with a rough plan while submitting the application itself, at this
> stage I would like to refine things and make the plan rocksolid). So as soon
> as SoC begins on May 28th I can start right away with coding.
>

Sorry again the date hear must be May 26th. I am really sorry.

-- 
Thanks and regards,
Madhusudan.C.S

Re: Student for GSoC 2008 - procfs

[Madhusudan C.S]

Hi,


> Hi,You aren't late at all -- official application period is starting only
> on monday :-)
>

 First of all thanks a lot in spending your invaluable time to read such
a long mail I have sent. Somehow I dont want to delay submitting application
to the last day. So I though posting after such a long time was late. Before
that I wanted to have a small discussion about this project on the group,
taking inputs from others, what they would like to see as a part of procfs
on Hurd. Since this takes quite some time, I thought it was late. Anyhow
thanks a lot for inducing confidence in me.

Indeed, we don't need all features -- only what's needed for procfs, top and
> similar tools.
>
> /proc//mem is problematic. Do we really need it for procps etc?


 After a bit of googling I found that /proc//mem was considered a
problem due to the vulnarability it poses in allowing other user processes
to change the process map of other process which consequently may crash the
system requiring a reboot. Since this happened in 2.2.x series of Linux
kernel, the feature was totally disabled in 2.4.x series. But there are some
patches submitted by third party
developers[1].I
think those patches will help us in designing the whole solution itself in a
different way when we start designing.

 If this was not the problem you were trying to mention please tell me
what it was.

I don't know enough about the others -- what they do, what they are needed
> for. Could you give a short summary, why you think each one important?
>

 Yeah sure, I will try to tell you what each of those features do, but I
am working on why each of them are needed for. I will be posting on them in
the subsequent mails.

/proc//cpu  -  Contains CPU state information of the process  and
exactly contains
Current and last cpu in which it was executed.
/proc//cwd -   Its a symlink which points to the current working
directory of the process
correcting the problems in /proc//environ
-   This contains values of Environment variables
for that process. But the
 procfs doc in Hurd says it always fails. And
the author says he doesn't
 know why. Have to work on it and fix it.
completing /proc//stat
-This gives the process status in a form not
legible to humans. And the
  need of this is just this. Let me try to give
an example thats given in the
  Nirendra's blog I had linked earlier.
  The 8th attribute in Linux's /proc//stat
is a per process flag which
  gives personal information of process. By
doing a logical AND of per
  process flag and with the following values we
can obtain the information
  thats given next to the values:
  0x0002 Process being created
  0x0004 Exiting
  0x0008 Dead
  0x0040 Process using super user privilage
  0x0200 Process dumping core
  0x0400 Process received some signal
  0x0800 Process allocating memory
  0x1000 Killed for out-of-memory

And so are attributes.


/proc/cmdline   -   Contains the command line arguments passed to Kernel
/proc/swaps -Contains swap space utilization function.

 Also from additional searching and a bit of researching I have found
that it would be nice if I do include these features in the list.

/proc/stat-  Overall statistics about the system, such as the number
of page faults
 since the system was booted.
/proc/version   -   In the current implementation only gives the result of
uname. But it would
 be nice if we provide other details provided by
Linux versions such as gcc
 version used to compile the kernel and the uptime.
/proc/uptime   -   It already seems to be implemented by looking at the
code. If there are any
 problems and additional requirements I would
consider it again
It would also be nice if we can provide
/proc/sys/* features like
/proc/sys/kernel/* - which reflects general kernel behaviors.
/proc/sys/net/*  - which contains all the network related information on the
system.

One more important feature that would be desirable is
/proc//fd -  which contain the symlinks to all the files the process
has opened

I would like to have the suggestions of all you people in working out
what features are needed and what are really not necessary for Hurd. I
request all of you to give your invaluable suggestions so that it will help
me to come up with a good proposal.

I will only b

Requesting for review of the Draft proposal for - procfs

[Madhusudan C.S]

Hi Olaf and all,
I am a prospective GSoC 2008 student. Few you here might be knowing
about me through my previous mails. After some work on procfs
pseudo-filesystem in general which included going through the GNU/Linux's
procfs documentation, going through the existing procfs code in hurdextras
repo and Documentation in it, going through many other websites and
tutorials, and more importantly considreing the suggestions olaf gave me, I
have come up with a rough initial draft of the proposal I want to submit for
GSoC 2008, with Hurd as my mentoring organization. The project is to
implement procfs's functionalities on Hurd.

  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

Also the odt, pdf and plain text versions are available for download at:
http://madhusudancs.byethost13.com/sites/default/files/madhusudancs-hurd-rev00.odt
http://madhusudancs.byethost13.com/sites/default/files/madhusudancs-hurd-rev00.pdf
http://madhusudancs.byethost13.com/sites/default/files/madhusudancs-hurd-rev00.txt

Since this is the initial version of the proposal, I have rougly
collected the ideas and consolidated them into this document. Please review
it and suggest any kind of mistakes including spelling and grammatical
errors. I have mailed this proposal to my friends and teachers for doing
reviews for me.
I alsorequest you people to help me in doing a technical review as well
as non-technical review since you are the people who know Hurd the best.
Suggest any kind of changes I have to do. I am requesting the whole
community(each and everyone here) to give your invaluable suggestions and
inputs on how I can improve this document and the whole project in general.

 I am planning to make as many revisions as possible(atleast 10) to this
proposal. But I do understand that any number of reviews and revisions will
not be sufficient though I am running out of time and have to submit it as
soon as possible. I am planning to submit it through Google Application
Applet on Thursday hoping that all the reviews and revisions will be over by
then.

Also one important note is that, I have referred to my blog in the
proposal for many things. However I have not been able to update it till
now. I assure you that I will update my blog before on or before Friday.

   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.


  Thanks a lot in showing interest towards my emails, proposals and all the
suggestions and inputs you have given. I would be happy if I get a chance to
work with you as a GSoC participant this summer. I will be looking forward
for your mails

   I will be looking forward for all your comments and suggestions
-- 
Thanks and regards,
Madhusudan.C.S

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

[Madhusudan C.S]

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//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//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
> `' 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

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

[Madhusudan C.S]

Hi Olaf, Fredrick and all,
  Thanks a lot for all the suggestions and comments. I am sorry for
all the misconceptions. I am reworking on the entire proposal so that meets
the requirements of "the Hurd" community.

 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.

   But understanding that Free Software is not all about what I want but its
all about what the community wants, I have considerd all the suggestions
from you people and am reworking on the proposal so that my design falls in
line with "the Hurd"'s needs at the moment, i.e a working totally GNU/Linux
compatible monolithic design.

> 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).
>
> I'm not sure such a middle layer is really necessary. Don't
> over-engineer. Start by implementing the actual functionality, and only
> if you indeed encounter a lot of code duplication, think about improving
> the infrastructure... Think KISS and YAGNI :-)


I really understood what I had done after seeing your comment with the above
"KISS and YAGNI" phrase. I am sorry I agree that I have over-engineered
things, it was all in over enthusiasm to contribute to "the Hurd" community.


>
> > One can now think of procfs problem comparable to networks problem in
> > which monolithic designs were replaced by layered designs through OSI
> > reference model and more practical TCP/IP architecture resulting in a
> > robust design of networks. Similarly by layering the design of procfs
> > which includes 3 layers 1.Intra-procfs PI 2.The core functionalities
> > of procfs 3.procfs API We are making procfs system highly robust,
> > reliable. So if new functionalities are to be added, its just a matter
> > of using the IpPI. Also if some functions are to be changed its only a
> > matter of changing the implementation of the function without
> > affecting the other two layers and this applies to those two layers
> > too.
> >
> > The above discussed benefit is more in compliance with the highly
> > modular approach of Microkernels and I feel this falls in line with
> > the Hurd philosophy.
>
> I understand your goal of achieving modularity; but that's not the right
> way of doing it. 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.

>
>
> While it might be interesting to look into such possibilities, should
> you be able to finish the main functionality before time, I suggest to
> completely leave it out of the plan, and stick to the existing
> "monolithic" design for now... Getting a functional and compatible
> procfs is presently much more important than experimenting with more
> elegant design choices :-)


Yeah understood, working on the proposal.

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 wan

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

[Madhusudan C.S]

Hi Olaf, Carl and all,
  I have submitted a totally reworked proposal through Google Web
App. This proposal reflects all the suggestions you have made previously. I
written my proposal so that it falls in line with the Hurd's requirements at
the moment as you people have told me. The same proposal is pasted below for
the review of the entire community. I request to all of you to go through
the proposal and give your suggestions on it which will help me to improve
it further.

Also thanks a lot for spending your invaluable time in reviewing my
proposal and also for the suggestions and comments you have given.

The proposal is given below.

GNU Hurd : GNU/Linux compatible procfs pseudo-filesystem

Abstract

Greetings!

   I wish to provide a sophisticated procfs pseudo-filesystem to
"the Hurd". An implementation of /proc pseudo-filesystem already
exists in hurdextras repository. After skimming through the code
it is clear that it needs a lot of rework and tuning. Experiences
from GNU/Linux have proven procfs to be a very useful facility in
implementing many of the process management tools. So the goal of
this project is to rework on the existing procfs on "the Hurd" so
that its not only reliable and robust but also more importantly
it is fully compatible with the GNU/Linux procfs. The project thus
aims at making the GNU/Linux process management tools  like ps,
top, vmstat, sysctl, w, kill, skill, nice, snice, pgrep, free,
tload, uptime, fuser, killall, pidof, pstree, etc., to run out of
the box.

Project Details

   To begin with, I would be migrating existing procfs code which
uses libtrivfs, to use libnetfs throughout procfs. The necessity
is that libtrivfs is a library which is best suitable for
filesystems providing a single directory or file. Since procfs is
now implemented as a virtual filesystem with a large number of
files and directories, it needs a more reliable and robust library.
"libnetfs" caters to this need as it provides functions for both
Network file systems and large virtual file systems.

   The next stage is the heart of the project. In this stage all
the files and directories that are expected of a GNU/Linux
compatible /proc pseudo-filesystem(Linux procfs doc.[Ref1])
are implemented using the libnetfs library. The functionalities
that form the immediate requirements for running procps, psmisc
and related tools(ps. tools henceforth) are implemented during
this stage of the project. The functionalities that will be
implemented are listed below.

   1.  /proc//cpu
   2.  /proc//cwd
   3.  /proc//root
   4.  /proc//exe
   5.  Correcting the problems of /proc//environ
   6.  Making existing /proc//stat fully Linux compatible,
   this is the core file which provides most of the information
   necessary for ps
   7.  Making existing /proc//maps Linux compatible
   8.  /proc//statm
   9.  Making existing /proc/version Linux compatible
   10. Finding and correcting problems in /proc/uptime, so that
   this too is Linux compatible
   11. /proc/sys/net/*
   12. /proc/meminfo

   Other features will be added to this list after studying their
feasibilities and necessities. Details of each of these files and
directories and their necessities will be provided in detail in my
blog[Ref2].

   With these features of procfs ready, the next stage of the project
is to test these implementations with the Linux versions of ps. tools
so as to ensure that the prime goal of the project is accomplished.
Bugs that arise during testing are fixed so as to ensure that all
ps. tools work out of the box on the Hurd.

Benefits to Hurd

Rewriting procfs to use libnetfs instead of the liptrivfs makes it
easier to implement large virtual filesystems. All the ps. tools
written for Linux will be capable of running on the Hurd out of the
box. Since these tools use only the features of procfs, it reduces
of a lot of efforts which would be otherwise required to port these
tools to use the Hurd's libps library which is not a good idea at
the moment.

   Also GNU/Linux's ps. tools are continuously evolving to provide
increasing number of functionalities and improvements. Thus
providing a compatible procfs makes much more sense than to use the
libps method since, when the new features are added to these tools
we need not again port the improvements but simply make them to run
out of the box, since it is more likely that procfs remains the same.
If procfs itself changes, even then it wont take too much of an
effort in making this change reflect in our procfs.

   Benefit to the user((and developers) community is that they can
now use Linux's ps. tools without waiting for it to be ported all
over to the Hurd which means faster availability of these tools
on Hurd to users.

Deliverables

   1. /proc filesystem that uses libnetfs. Using this library makes it
  easier for implementing a large set of functionalities and hence
  makes the implementation robust.
   2. The core GNU/Linux compatible /proc fi

Re: Student for GSoC 2008 - procfs

[Madhusudan C.S]

Hi Carl, Olaf and all,

>
>
> I didn't mean to say that /proc/*/mem is problematic per se. I rather
> meant that it's problematic to implement a Linux-compatible version in
> the Hurd procfs translator.
>
> The issue is that it's not possible to obtain all of the information
> listed by the Linux variant. For one, in Linux, the file corresponding
> the each mmap region is listed. In the Hurd, we have no central entity
> keeping track of mmapped files. The kernel only knows about memory
> objects. For each object, there is some process (called pager) backing
> it -- usually some filesystem server. Mapping the memory object to a
> file is entirely the individual pager's responsibility -- to obtain the
> file name associated with a memory object, we would need a new interface
> that allows asking the pager about it, or the actual process that
> requested the mapping.
>
> But that's not all. Linux procfs not only gives the path of the mapped
> file, but also the inode and the major/minor device number of the
> partition it is on. However, the Hurd doesn't have device numbers.
> Rather, devices are described by the translators handling them. In case
> of kernel-implemented devices, there is the Mach device name as
> identifier, which is quite like major/minor device numbers, except that
> it's an alphanumeric string rather than a pair of integers -- we can't
> represent that in a compatible manner.
>
> Filesystems can also live on devices not implemented by the kernel, and
> thus having no device name at all. In some cases, the filesystem
> location of the device translator could be used instead; but that's
> again incompatible, and doesn't always exist either. Similary, some
> filesystems on the Hurd are purely virtual (stuff like ftpfs for
> example), and thus have no inodes.
>
> The only way to unambiguously name any open file in the Hurd is to
> provide the actual port. While it would be technically possible to do
> that in a /proc filesystem I think, it would work totally different than
> the /proc/*/mem on Linux...
>
> The bottom line is that it's not possible to create a fully compatible
> /proc/*/mem. But do we really need to? AFAIK this interface is used
> mostly by debugging tools -- but debugging is very system-specific
> anyways, and the tools need to be adopted to use whatever native
> debugging interface the respective system provides; trying to be
> compatible seems useless here.
>
> Thus it's very important to find out whether /proc/*/mem is really
> needed for ps, top and related tools; whether we need to implement it at
> all, and if so, which parts...


Amazing explaination. I understood why /proc//mem cannot be used. By a
bit more googling I got it confirmed that this feature is absolutely needed
for Debugging stuff and not exactly for procps tools, So I have dropped this
from the list.

> /proc//cpu  -  Contains CPU state information of the process
> >  and exactly contains Current and last cpu in which it was
> > executed.
>

In linux 2.4.x compatible mode this is required by top and related tools for
CPU usage information, though this information is provided in
/proc//stat only.

> /proc//cwd -   Its a symlink which points to the current working
> > directory of the process
> > correcting the problems in /proc//environ
> > -   This contains values of Environment
> variables
> > for that process. But the
> >  procfs doc in Hurd says it always fails.
> And
> > the author says he doesn't
> >  know why. Have to work on it and fix it.
>

/proc//environ is definitely needed by ps, a *ps ewww * returns
the environment variables used by that process. Also as of what I have found
now /proc//cwd is used by lsof  to show all the files opened by a
process which includes cwd also, this also requires /proc//fd/* too. I
remember reading somewhere that its required for ps related tools too. I am
not getting that link back now. So I am going through the code of procps and
psmisc to find out. Please give me some time. Most of the features I had
included had reasons and were not included simply without any knowledge on
what they do, except a very few like /proc//mem

>
> > completing /proc//stat
> > -This gives the process status in a form not
> > legible to humans. And the
> >   need of this is just this. Let me try to
> give
> > an example thats given in the
> >   Nirendra's blog I had linked earlier.
> >   The 8th attribute in Linux's
> /proc//stat
> > is a per process flag which
> >   gives personal information of process. By
> > doing a logical AND of per
> >   process flag and with the following values
> we
> > can obtain the information
> >   thats given next to the values:
> >   0x0002 Process bei

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

[Madhusudan C.S]

Hi Carl,


> This is perhaps the root of the misunderstanding, we don't need to be
> ahead of linux when it comes to procfs.  procfs should only provide a
> different interface to features /already/ present in the Hurd, i.e. a
> compatibility layer.  Your desire to propel the Hurd beyond linux is
> misplaced, that should be done outside of procfs.
>
> And just to clarify, there's nothing wrong with your layered design
> per se.  In fact we encourage it, as it will allow others to easily
> add features to procfs, not to get ahead of linux but to catch up when
> we find ourselves missing a feature required by an useful application
> that we would like to port to the Hurd.
>
> It's just better for us if you focus on first just making it work so
> that we can make use of it, and then come up with a nice design.  It
> is also better for you, as you'll get practical experience of how
> stuff works in the Hurd, and thus a better foundation for coming up
> with a good design.
>

Yeah got it clearly. I understood what I had done the moment Olaf mentioned
abt KISS and YAGNI :). I have made all the necessary changes.


> Please understand that we can't really take your word for it.  Of
> course, we all hope you do keep contributing, but we also have to
> consider the worst case scenario.
>
> (I'm not in any way implying that you might be lying.  Shit happens
> and you might not be able to contribute because of illness, accidents,
> or some other factor that is beyond your control.)


Yeah understandable. Thinks like that happen. I only hope for good and such
things wont happen in my case.



-- 
Thanks and regards,
 Madhusudan.C.S

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

[Madhusudan C.S]

Hi Carl,
Thanks a lot in taking time to rgo through my proposal.

I think you've done a really great job of writing this proposal!
> There's not much to comment on really.  :-)


Thanks

> The project thus aims at making the GNU/Linux process management
> > tools like ps, top, vmstat, sysctl, w, kill, skill, nice, snice,
> > pgrep, free, tload, uptime, fuser, killall, pidof, pstree, etc., to
> > run out of the box.
>
> Some of these items might already have a port that is good enough.
> Not sure which ones though, but probably kill.


I will check out.


> > I'm fully available this summer without any other commitments, will
> > tune my day/night rhythm as per my mentor's requirement and assure a
> > dedicated work of 50 hours/week.
>
> Wow, 50 hours a week is a lot.  I didn't put nearly as much time into
> my GSoC project, I think 20 hours a week is typical for a GSoCer.  I
> don't want to discourage you from working hard, but don't overwork
> yourself.  ;-)


I am sorry if I am too arrogant. Please excuse me. One thing I want to
mention is that I am crazy when it comes to Computers and FS. Thanks a lot
for your concern. I dont mean 50 hrs of coding per week. It also includes
time for discussion with the mentor. Community etc etc. Other preparations.
I hope I can set aside 25-30 hrs for coding and documentation and rest of
the time for discussions, reading various books and other resources. (I
usually sit in front of my comp from 8AM to 12 AM in vacation with 6-7 hrs
set aside for routine work, TV and Playing sports. this comes to around 9-10
hrs a day in vacation.) So I felt its managable. I hope I can change this
rythm on the days where circumstances are extreme , say I am not well by
talking to my mentor. And as far as I have understood its all abt finishing
things as per the schedule and not how much time I spend on each day. Am I
right? Please correct me if I am wrong anywhere.


-- 
Thanks regards,
 Madhusudan.C.S

Requesting to help me in selecting the second project

[Madhusudan C.S]

Hi Olaf,
   After a lot of thinking and working on the possibilities you
showed me yesterday I have come up with the the following 3 ideas as the
ideas for my second proposal. They are listed in the order of knowledge I
have about them and my preferences at the moment. (Somehow I am so much
obsessed, fascinated and delighted with the idea of translators at the
moment that my mind is not thinking outside that atleast at the moment.).

1. xmlfs (3 months of programming experience on XML. I handled the entire
XML part of the project(including design, coding and unit testing of XML
part) code named  veeprocess which will go into production in a month or two
written in PHP for a company called Vee Technologies)
2. Namespace-based Translator Selection
3. lexical dot dot resolution

But this doesn't mean that I am restricted to these ideas. As I have said
earlier, this is not all about what I want but what community wants and I
need to respect it. So I am open for any idea which community feels are more
important these at the moment. I will be equally willing and interested to
work on them. Also I have said earlier on IRC that all the ideas in the wiki
look interesting. If you suggest me an idea that I dont have much knowledge
about I will ensure that I will work on it with the same enthu I have on any
other idea of my choice and use community bonding period to get more well
versed in the requirements for that idea.

-- 
Thanks and regards,
Madhusudan.C.S

P.S: Since the deadline for submitting the proposal is fast approaching I
request any of the mentors to reply on this mail as soon as possible.

A small query regarding the schedule

[Madhusudan C.S]

Hi Olaf and all the mentors,
  In the proposal I will be submitting for Improved NFS
implementation, I have divided the entire schedule into 2 major stages with
each stage consisting of several phases. The first stage is to analyze,
design and complete the NFSv2 implementation and then the next stage is to
analyze, design and implement NFSv3. If you are not happy with this kind of
a schedule I will reschedule things once I come back on Monday morning from
the meet I will be attending. I request you to mail mail me all your
suggestions and comments on the schedule and the proposal in general so that
the final proposal will be as good and competitive as possible. Also please
excuse me if the proposal is not formatted or lines are not wrapped
properly. I have done it urgently. I will correct the formatting of the
proposal too when I come back. I request you to comment on this too.

Thanks a lot in spending your invaluable time for reviewing my proposal, and
also for all your suggestions and comments.

-- 
Thanks and regards,
Madhusudan.C.S

Requesting to Review of the proposal - Improved NFS Implementation

[Madhusudan C.S]

Hi Olaf and all,
   My proposal is given below. I request you to review
it and give suggestions on any kind of mistakes so that I can improve my
proposal.

Greetings!

   I wish to provide an improved Network Filesystem support to "the
Hurd". This implementation will be an improvement for the partly
implemented NFS that exists in the Hurd already. Though the exisiting
implementation supports only NFSv2 it has a few problems with it too.
So the aim of this project is to improve the support for NFSv2 by
adding features not present in the current implementation and fixing
the bugs that exist. It also includes adding support for NFSv3. Bug
Fixing includes several things like providing full support for Hurd's
NFS to work with GNU/Linux server in all aspects. All the features
necessary to make the NFSv2 implementation complete will be added.
Implementing NFSv3 support includes adding all the features that are
specified in NFSv3 protocol standard i.e. RFC 1813 like support for
asynchronous writes on the server, performance improvements among
other things.


Project Details

   To begin with, I will work on the existing NFSv2 implementation on
the Hurd to make it work in all the aspects. I will work on it to so that
it fully implements all the specifications provided in NFSv2 protocol
standard i.e RFC 1094. I will work on improving the performance of
NFSv2 and fixing bugs that exist on the server side. Since many people
are interested in having the Hurd client communicate with GNU/Linux
server it is more importantly necessary to add all the features to
NFSv2. This includes adding NFS Filesystem model which implements
filesystem organization. This stage also includes completing the
support for the Mount protocol which is employed to mount a filesystem
and create handles to access files on it. Also included are the features
to handle error control and caching mechanism on the client side. All
the NFS server procedures(its nearly a misnomer since server
procedures are actions that a client may take on files residing on a
server) are implemented. Some of them include null, getattr, setattr,
root, lookup, statfs, readdir etc which are not present in the current
implementation but part of the NFS's Remote Procedure Calls(RPC).

   The next stage of this project starts with implementing the core
NFSv3 protocols. The most necessary specifications provided in RFC
1813 needed to for a working NFSv3 will be implemented. This mainly
includes
   1.  Adding support for TCP as a Transport mechanism which was a
major addition for NFSv3 in addition to the existing UDP
   2.  Support for asynchronous writes on the server, to improve write
performance
   3.  Additional file attributes in many replies including fourth set of
permission bits
  4.  Adding READDIRPLUS operation, to get file handles and
   attributes along with file names when scanning a directory
  5.  Adding NFSv3's new server procedures such as mknod, pathconf,
   commit, access
  6.  Improved file locking support with GNU/Linux
  7.  Improving Performance

   Other Hurd specific functions such as adding support for
   1.  Changing a file's author
   2.  Passive translators

are also implemented.

   Other features will be added to this list after studying their
feasibilities and necessities.

   With these features of NFS ready, the next stage of the project is
to test these implementations with the GNU/Linux servers so as to
ensure that the prime goal of the project which is providing NFS
support with GNU/Linux is accomplished because it is the most
necessary feature. Bugs that arise during testing are fixed. Then if
time permits the features needed to run the Hurd's NFS Server are
implemented.

Benefits to the Hurd

   Implementing a feature complete NFS client to Hurd means that a
long time requirement of easily accessing other systems from Hurd is
made easy. It means that users can now use NFS to access the files
that they have stored on GNU/Linux machines on networks. They can
resume their partly finished work on the Hurd, if at all they have
stored it in files in other systems. So file resources can be shared.

   Providing TCP support for Transport is also a huge gain to Hurd since
transfers are now reliable and more secure. This also means that NFS
on the Hurd can also be used over WAN.

   Also this project provides developers with a basic platform to
implement NFSv4 since v4 reuses most of the parts of NFSv2 and v3.

Deliverables

   1.  Completed NFSv2 implementation with support for all the
   features specified in RFC . This also includes implementing all the
   unimplemented RPCs.
   2.  A usable NFSv3 implementation with v3's additional features and
   RPCs.
   3.  NFS implementation that can use TCP as a transport mechanism
and Hurd specific functionalities.

   Non-code deliverables include documentation of the code of the
Hurd's NFS implemented during the course of the proje

Re: Requesting to Review of the proposal - Improved NFS Implementation

[Madhusudan C.S]

Hi Olaf,
   First of all sorry for being very late on the mailing list. I have
been discussing with you about some of these things in the IRC. Anyhow
detailed explaination is here.

> I will work on improving the performance of NFSv2 and fixing bugs that
> > exist on the server side.
>
> How do you intend to improve performance? Are you thinking of anything
> specific that the current implementation doesn't do or does only badly?
> Or is it a more generic intention to look into possible problems?


Its a generic intention. Since the bug related to this also says in the more
generic sense. Have to look at the possibilites. More over RFC too provides
few specifications to improve performance. This includes going through the
specification and implementing the unimplemented parts.

> This includes adding NFS Filesystem model which implements filesystem
> > organization.
>
> What's that?


NFS specification says NFS client specifies its own filesystem model to
represent the filesystem hierarchy i.e directories and files organization.
It is implemented for NFSv2, but this stage includes fixing some parts like
the one you have asked for i.e "rm -r exampledir/" problem(details in other
mail), and providing additional features required for NFSv3.

> This stage also includes completing the support for the Mount protocol
> > which is employed to mount a filesystem and create handles to access
> > files on it.
>
> What is it missing currently? Or is that what you describe below?
> (Pardon my ignorance...)


Needs a thorough look at the currect implementation, code and specifications
to give full details. I am working on it. I will list them as soon as I
finish it. It may be the cause for the above said error too.

> All the NFS server procedures(its nearly a misnomer since server
> > procedures are actions that a client may take on files residing on a
> > server) are implemented.
>
> You mean you intend to implement them?


Yeah.


> > Some of them include null, getattr, setattr, root, lookup, statfs,
>  > readdir etc which are not present in the current implementation but
> > part of the NFS's Remote Procedure Calls(RPC).
>
> Could you give a short summary what these do?


Hey I am sorry. I have put the words wrongly here. Actually I meant looking
at which of these are not implemented and implementing them. Back when I was
writing the proposal I had hardly 1 or 2 days and I was not able to check
for all of those things in the code and write speicfically. So I wrote in
this generic way.
Anyhow here are the details of each of them

Null - Dummy procedure provided for testing purposes.
getattr - Retrieves the attributes of a file on a remote server.
setattr - Sets the attributes of a file on a remote server.
root - This procedure was originally defined to allow a client to find the
root of a remote system
lookup - Returns the file handle of a file for the client to use.
statfs - Provides to the client general information about the remote file
system, including the size of the file system and the amount of free space
remaining.
readdir - Reads the contents of a directory.


>The next stage of this project starts with implementing the core
> >NFSv3 protocols.
> [...]
> >3.  Additional file attributes in many replies including fourth set
> >of permission bits
>
> Is that really related to NFSv3?...


Not exactly to NFSv3. But I have put this in this stage because it requires
an in depth knowledge of NFS file handling mechanisms. So I thought I would
have gained enough experiences while implementing NFSv2 features and this
could be done quickly at this stage.

Anyways, this is only meaningful if both the client *and* the server
> understand the Hurd extensions -- as you said that we don't have a
> usable server anyways, I would leave it out for now...
>

Ok fine.


>
> >   6.  Improved file locking support with GNU/Linux
>
> Does NFSv3 provide improvements in this regard?


No same explaination as above.


> I do experience many locking problems myself, but I'm not sure where
> they come from. It could be deficiencies in the NFS client, but it also
> might be just the general locking problems we have on the Hurd...
>
> Also, I had some locking problems as well when running a GNU/Linux NFS
> client with the GNU/Linux server for testing -- so I wonder whether the
> problem is actually on the server side...


Oh Ok.


> >Other Hurd specific functions such as adding support for 1.
> >Changing a file's author 2.  Passive translators
> >
> > are also implemented.
>
> You mean you want to implement these as well? Well, see above regarding
> fourth permission bit...


I did not get you.


> >With these features of NFS ready, the next stage of the project is
> >to test these implementations with the GNU/Linux servers
>
> You will have to test all the changes you make with GNU/Linux servers
> anyways, as we have no other available... :-)


Ok :)

>2.  Analysis and Design I ( May 26th ? June

Help me in tracking a bug in NFS

[Madhusudan C.S]

Hi all,
I have been working on Improving NFS implementation on the Hurd.
Olaf told me that rm -r does not work on some cases and trace the problem.
As I have already discussed with him it is observed that an error occurs
when we use a trailing / with directory name for removing a directory in a
filesystem mounted with NFS, for example
rm -r somedir/
gives an error
rm cannot remove directory 'somedir/': RPC struct is bad

but rm works fine when we use only 'somedir' without trailing /. But its
natural that / is taken when we press tab to complete the directory name.

I am just going through the source files in nfs directory in Hurd source
tree. There are two directories with names nfs and nfsd. Since this has
something to do with client I felt there will some problem with source in
this directory. Can anyone of you please help me tracing out where this
problem might be happening. I request you to give some basic idea behind
this or clues so that I can continue.


-- 
Thanks and regards,
Madhusudan.C.S

Copyright assignments

[Madhusudan C.S]

Hi all,
 In the meet held on 25th April regarding GSoC, Olaf and Samuel
asked us to send the copyright assignments to fsf. We were also given this
link http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00175.html. I
have filled out 3 forms, 1 each for Mach, Hurd and glibc as instructed by
Olaf and Samuel. Can you people see the forms pasted below here and tell me
if its correct. If its correct I will mail it to fsf. Also the form says
mail it to [EMAIL PROTECTED] What does that mean? Should I mail it only to
[EMAIL PROTECTED] or is there some other addresses too for which I need to
mail.

==MACH==

[What is the name of the program or package you're contributing to?]

Mach

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

No


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

No


[For the copyright registration, what country are you a citizen of?]

India


[What year were you born?]

1987


[Please write your email address here.]

[EMAIL PROTECTED]


[Please write your snail address here.]

#92, 2nd Main, 6th Cross, Chamundeshwari Layout,
Vidyaranyapura, Bangalore, Karnataka, India
PIN : 560097



[Which files have you changed so far, and which new files have you written
so far?]

Havenot changed anything till now.


==Hurd==

[What is the name of the program or package you're contributing to?]

Hurd

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

No


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

No


[For the copyright registration, what country are you a citizen of?]

India


[What year were you born?]

1987


[Please write your email address here.]

[EMAIL PROTECTED]


[Please write your snail address here.]

#92, 2nd Main, 6th Cross, Chamundeshwari Layout,
Vidyaranyapura, Bangalore, Karnataka, India
PIN : 560097



[Which files have you changed so far, and which new files have you written
so far?]

Havenot changed anything till now.

==Glibc==

[What is the name of the program or package you're contributing to?]

glibc

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

No


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

No


[For the copyright registration, what country are you a citizen of?]

India


[What year were you born?]

1987


[Please write your email address here.]

[EMAIL PROTECTED]


[Please write your snail address here.]

#92, 2nd Main, 6th Cross, Chamundeshwari Layout,
Vidyaranyapura, Bangalore, Karnataka, India
PIN : 560097



[Which files have you changed so far, and which new files have you written
so far?]

Havenot changed anything till now.


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: Copyright assignments

[Madhusudan C.S]

 Hi

> > [Please write your snail address here.]
> >
> > #92, 2nd Main, 6th Cross, Chamundeshwari Layout,
> > Vidyaranyapura, Bangalore, Karnataka, India
> > PIN : 560097
>
> What is PIN?


Sorry I haven't followed the International Address format. I have changed it
now to look like this.
#92, 2nd Main, 6th Cross, Chamundeshwari Layout,
Vidyaranyapura, Bangalore - 560097
India

Is this fine?

It looks to me like India should be the last line of the address,
> shouldn't it?


Yes, I have changed it. Can you please tell me if other things are correct?

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: Copyright assignments

[Madhusudan C.S]

Hi Samuel,


> > Sorry I haven't followed the International Address format. I have changed
> it
> > now to look like this.
> > #92, 2nd Main, 6th Cross, Chamundeshwari Layout,
> > Vidyaranyapura, Bangalore - 560097
> > India
> >
> > Is this fine?
>
> That should be, yes.


Thanks a lot. I will be mailing it to [EMAIL PROTECTED]



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Help required for porting parted-1.7.1

[Madhusudan C.S]

Hi all,
 I am trying to port parted-1.7.1 to Hurd. As it is logged in
the failed builds report [
http://unstable.buildd.net/buildd/hurd-i386_Failed.html] there is a problem
with variables '_IOT__IOTBASE_format_data_t' and
'_IOT__IOTBASE_dasd_information2_t' in s/390 architecture's code. But at
these lines there is no use of such variables. But there is a call to ioctl
at both the places. Problem here is that there are 3 parameters passed to
ioctl which can be of any type and is optional. In this case they are
pointers to structures. However problem wont occur when there are just two
parameters passed. But this error occurs when there is a third parameter.
Can someone help me please?

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

GSoC: procfs implementation.

[Madhusudan C.S]

Hi,
 The existing procfs code uses libtrivfs. So one of the goal's of my
GSoC project is to rewrite procfs so that uses libnetfs.  During the
proposal submission stage, I had said that I will first port every feature
in the existing code to use libnetfs and then start implementing the new
features. Olaf suggested that its a better idea to write the libnetfs
skeleton first and then port the existing individual features as and when it
is required. But he asked me to make sure which is a better way once. I
request to you all to suggest me which method suits this case.

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: Help required for porting parted-1.7.1

[Madhusudan C.S]

On Fri, May 9, 2008 at 2:39 AM, Samuel Thibault <
[EMAIL PROTECTED]> wrote:

> Hello,
>
> Madhusudan C.S, le Fri 09 May 2008 00:28:16 +0530, a écrit :
> >  I am trying to port parted-1.7.1 to Hurd. As it is logged in
> the
> > failed builds report [
> http://unstable.buildd.net/buildd/hurd-i386_Failed.html]
> > there is a problem with variables '_IOT__IOTBASE_format_data_t' and
> > '_IOT__IOTBASE_dasd_information2_t'
>
> These are supposed to be ioctl #defines, describing the structures of
> struct format_data_t and dasd_information2_t. See for instance in
> /usr/include/bits/termios.h the definition for _IOT_termios:
>
> #define _IOT_termios /* Hurd ioctl type field.  */ \
>  _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)
>
> It says that struct termios holds 4 tcflag_t members, then NCCS cc_t
> members, then 2 speed_t members. In the case of format_data_t, we can
> write
>
> #define _IOT__IOTBASE_format_data_t \
>  _IOT (_IOTS (int), 4, 0, 0, 0, 0)
>
> to express that it just holds 4 int members. In the case of
> dasd_information2_t however, the structure is too complicated and thus
> we can not do that. We are hence screwed by the limited design of the
> ioctl interface, and the only way we have is to just ask for the s390
> patch to _not_ be applied in the hurd-i386 architecture case.
> :/
>

 Aah, I was thinking about this. Best solution atleast at the moment I
thought was not to apply s390 patch. Will remove it and build now. Thanks
for the help.

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: GSoC: procfs implementation.

[Madhusudan C.S]

Hi Olaf,

Well, in the end it is your decision...
>
> Would be nice though if you could explain why you think one way is
> better than the other :-) What possible advantages and disadvantages do
> you see in for each variant?
>
> IMHO there is no specific plus or minus as to why I should select one
method over the other. Both have equal pros and cons. After thinking about
it and reading the code for 2 days, this is what I have thought.

If we take the existing procfs code and then start migrating it to use
netfs, I may fear that it may not be possible everything in the existing
code be ported. Though I am not sure about this, this is what I felt when I
was going through the code. Moreover not every part of the code is well
documented, so I felt it may turn out that it may be difficult to port
everything.

But if we start writing everything from scratch, I felt we may end up
re-inventing the wheel i.e we may do extra amount of work which may involve
implementing the features already implemented. So I would like to ask you
which you feel better.

Given me a choice I would like to take the task first starting with netfs
backbone and porting those features that can be ported along side
implementing the new features paralelly which takes advantages of both the
methods.

I am open for both the ways.

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Help regarding netfs callbacks

[Madhusudan C.S]

Hi all,
I am working on implementing GNU/Linux compatible procfs. I am
using netfs for translator implementing this translator as it was planned. I
have quite a few quiries regarding netfs programming and using its
callbacks. Someone who know about these please help me.

1. Some of the existing translators define two structures one with the
netnode and another generally with the name of the translator, say netnode
and procfs in this case as I have done now. Whats the essential difference
between two structures and what different information are they intended to
contain? (Additionally ftpfs also implements two structures for dir and
dir_entry. Is it necessary to maintain these structures, are there any
special advantages in doing so?)

2. I did not quite get the concept of  netfs_get_dirents callback which
netfs says is used for fetching the directories. What is it expected to do?
What do we have to define and do within this callback? Most of the existing
translators seem to implement the same code(I can say its a copy). Why is it
so? Can I take those things from there? But I dont want to copy paste
something without knowing what is actually happening. Can someone explain
please?


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: Code commit

[Madhusudan C.S]

Hi Olaf,

>
> >
> > Thats the reason I thought I should maintain a Changelog. Also  I want
> > it for my own reference later.
>
> Well, you can always look up the history in git. If you prefer it in a
> text file, there are scripts that extract the commit messages and
> generate a file from them.
>
> Again, maintaining a ChangeLog file manually only makes sense if it
> actually contains something different than the commit messages...
>
> The only good reason I can think of would be maintaining a GNU-style
> changelog in a file, while providing more useful comments in the git
> commit messages. Note that GNU changelogs have a very strict form -- see
> the chapter on changelogs in the "GNU Coding Style" document if you want
> to go down that path...
>
> (Personally, I consider the GNU-style changelogs rather useless in times
> of proper revision control systems, but YMMV...)
>
> Ok thanks a lot. Though I knew how helpful git histories would be, I did
not know about the scripts that help backing up the git history to files.
Ok I will go this way then. Also maintaining a GNU style Changelog is quite
time consuming, and its something like doing every entry twice. I will drop
that then. Thanks again

Also I am hopefully looking forward for a reply to my post on help regarding
netfs.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Updating the progress

[Madhusudan C.S]

Hi Olaf,
   I have done few commits to be code today. I request you to please check
the code. With that done, I feel most part of the netfs backend that is
required to accomplish what we have set as targets (target being creating
empty PID directorries) is mostly done. But it has taken too longer than I
anticipated. Sorry for the miscalculation of the time required two weeks
back. Please suggest if there can be any improvements or point out mistakes
if any. There were few architectural decisions which I took on my own
without your consultation. I am really sorry for that. I was waiting for the
response to my mail on a help regarding netfs call backs, which would have
become the keys to those decisions. But unfortunately I did not get any
response for a long time, and I felt that was no reason to stall the work,
so did it on my own. I am totally open to further discussions and ready to
change the design if you feel that it is required.

   The major decisions were to use two separate structures for directory
handling, viz. procfs_dir and procfs_dir_entry(This was a change from my
previous thought of using the same structure for all types of nodes). Also
another major thing was to use hash tables for maintaining directory
entries. This decision was more or less inspired by the elegant design of
netfs in ftpfs translator. Other translators in hurd-extras, I felt are not
clear in this particular part of maintaining directory entries.

   *I am waiting eagerly for your suggestions and comments*

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: Updating the progress

[Madhusudan C.S]

Hi Olaf,

Well, not being familiar with libnetfs, I unfortunately can't really
> tell whether the code makes sense.
>
> I didn't discover any obvious errors when looking at it -- but then,
> it's not surprising, considering that most of the code seems to be
> template code more or less directly copied from some other translator(s)
> :-)
>
I must again point out that if you copy code, you should mention (below
> the copyright line) that the code is based on ftpfs (or whatever it is
> based on), and include the copyright notice from the orignal file.


Yes, some parts of the code is a template of other netfs translators. But if
seen keenly, nearly almost all the translators I am referring follows the
same template or rather have copied the template from one another. Really
without any documentation on how to actually use netfs, I have no other
choice than doing that, since it is difficult to take the path of my own
which should be different because thats not well tested. To be on safer side
I thought of using the template of ftpfs which is in hurd main source only,
since it is copyrighted to FSF. I hope that will not have any adverse effect
on my code in terms of copyright and license issues.  Also I would like to
tell and I have already said that, struct procfs_dir and procfs_dir_entry
and related initializers was really taken ftpfs and so I would like to
include the ftpfs copyright notice in those files only, though all the code
is not an  exact copy.

Aside from that, you are not following conventions in the commit
> messages (which has very adverse effects on some git tools): You should
> start each commit message with a single line summing up the commit, a
> blank line, and only then a detailed description what you changed.
>
> If you find that you can't sum up the commit in a single line, this most
> probably means that you have several individual changes, which should
> actually go into seperate commits... From what I saw, this is often the
> case.
>
> Also, please check the diffs more closely before comitting: In several
> commits you have changes that aren't mentioned in the commit message,
> and in fact seem totally unrelated to the rest of the commit...


OOPS I am really sorry, I did not know about this convention till now, or
nobody had pointed out to me for this wrong convention in commit messages. I
am really sorry. I will follow the conventions henceforth and please point
out if I break it.

Also before I read this mail I had done some large changes in the code. It
will be an hectic task to revert back and follow these conventions for
atomic commits. So that will be one last commit I will be doing not
following this conventions. It takes simply too much of time to do that now.
Kindly oblige.

BTW I wonder, why are you keeping build logs in git?...
>

Aah I wanted to tell about that myself, when we discuss among our friends
about the progress, I usually used to tell about the silliest programming
errors we make during programming which leads to hours of work to find and
fix it. So many of them asked me to maintain a build log so they can see how
things are going, and also I thought it would be nice for me to go through
such things, because this is the first big free software project I am doing
that too from scratch. I understand your concern that it would make the
repository very big unnecessarily. I wont be transferring that to Hurd CVS
you provide us. Is that ok or should I discontinue that from git?




-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Requesting for help regarding libnetfs

[Madhusudan C.S]

I get the following kind of error, when I settrans my procfs on a directory
and run ls. How to track this kind of errors. Can some one help me please.

*** glibc detected *** procfs: free(): invalid pointer: 0x0122ba44 ***

Also if netfs_get_dirents gets parameters BUFSIZE as 0,  ENTRY as 0 and
NETNRIES as -1, what might be the possible mistake. How to trace it as to
why it happens. Please help me.


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

procfs - Design Issue

[Madhusudan C.S]

Hi all,
  I have a design question regarding implementation of procfs.
Whenever we look into /proc, it is very likely that its contents
change(directory names with PIDs), since processes are created and die. So
everytime it is better to fetch this information whenever a contents are
looked in this directory. But how to manage the old nodes?

1.   Is it better to free all those nodes as soon as they are displayed and
create them whenever they are required?
2.   Or create nodes for each of these PIDs and keep them, when updating the
nodes when client looks at /proc replace only the name and information of
the nodes which no longer exists(corresponding to a process that died), with
new process information and also create new nodes if the number of process
currently running only when it exceeds its previous number?
3.  Whenever client looks into /proc create nodes for directories and give
the required information. When /proc is looked for second time, free all the
previous nodes and create nodes?

 Which among the above is a better approach than the other. Please suggest
me.
-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: GSoC projects

[Madhusudan C.S]

Hi Thomas,

On Sat, Aug 2, 2008 at 2:24 PM, Thomas Schwinge <[EMAIL PROTECTED]> wrote:

> Hello!
>
> The GSoC projects are making good progress, as I read from various IRC
> log lines.  Hence, we'd like to make this work available through the
> standard GNU Savannah Hurd group/repository.  I'm going to make the
> GSoCers members of that group.  Here are some rules:
> 
> >
>

Thanks a lot Thomas.


> So far, we'll grant you commit-after-approval permission, so please
> (continue to) post and discuss everything to bug-hurd that you'd like to
> have committed.  On your own tagged branches, you can do what you feel
> like (commit directly), but please also obey to the above rules.  Better
> to ask first, than trying to do something on your own.  (Remeber that
> whatever you do, it'll be part of the Hurd's permanent RCS history.)
>
> So, let me say this again: Thanks for your interest in the GNU Hurd and
> welcome on board!  :-)
>
>
> Now, I'd now like each of GSoCers post a follow-up to this message, and
> give a short overview of (a) what he's working on and (b) if this is
> rather a stand-alone thing or has to be included into the main Hurd
> repository.  If it's stand-alone I'd rather have it remain so and make up
> a separate module for it (might even use git or else for it instead of
> CVS, whatever people prefer).  If it has to be integrated into the main
> Hurd tree, then we have to make up some rules about how to do this.
>

(a) I am Madhusudan.C.S. I am working on implementing a GNU/Linux compatible
/proc pseudo filesystem. The major goal is to make the /proc available on
Hurd, so that procps and psmisc tools like kill, pgrep, pkill, top, killall
among other things which depend on /proc run out of the box. I have
implemented the important parts of /proc till now and have been able to get
pgrep working fine till now (pkill also seems to work, but some  testing is
needed). I will be working on making more procps tools available.

(b) As both antrik and Samuel suggested procfs should be a part of main Hurd
tree. Can you please tell me the rules?

PS: I'm going to work on the wiki issue today.


Also in the meeting yesterday we decided to setup a backup repository for
Hurd Wiki. I have taken this responsibility. I have also setup a repository
at github.com. I will post the details in a different mail.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: GSoC projects

[Madhusudan C.S]

Hi Thomas,


> I don't know github.com.  But not why simply host (a secondary/backup of)
> the Hurd wiki on the GNU Savannah machine already now?  Then we can --
> later, when the needed infrastructure is in place -- just do a clean
> switch-over (from Barry's flubber to GNU Savannah; for the main wiki
> repository).
>
> I'd prefer if such things would go over some of the Hurd mailing lists,
> before something is said to have been decided in an IRC channel.  Which
> none of the GNU Hurd maintainers is really regularely frequenting.
>

I am sorry for not making this clear. The main reason to setup a backup
repository was to make the GSoC projects going on smooth even when the
main repository at flubber was not accessible(to be very frank, from past
2 weeks or so whenever I have tried I have not been able to access it :(. I
have not been able to make any changes in my wiki page) and  I am sorry
if it was mistook to be some sort of competitor to main Hurd wiki (I felt so

when you said "Which none of the GNU Hurd maintainers is really regularly
frequenting").

 Anyways I have setup the backup repository at github.com. I am sending the
details about how to access them in a separate mail to all GSoC mentors and
participants and also to bug-hurd. But I would like to know if you are doing
this at Savannah sometime soon. If so when will it be up? Can I stop the
work
on github.com and if possible can I take the responsibility of maintaining
the
wiki at savannah (I would like to do this)? If savannah thing cannot be
setup
sometime soon, do you wish to maintain the entire hurd wiki at github.com?

Of course, setting up a mirror of the Hurd wiki repo is nothing
> fundamental :-), but nevertheless: if we have the facilities at GNU
> Savannah, then why resort to an external service provider?  Or can
> github.com do something cool which I don't know of yet?


Few things are cool!. Web Interface at github.com is really cool! And
getting a repository up and to usable state and also giving commit access
to those who want to work on the wiki is is not as stringent as savannah
thingie. Anyways its your wish and decision as a Hurd Admin to take this
in whichever direction you want. I have no intention of misleading things
here. I hope this did not hurt you. If so I am really sorry for that and
will
take care to see to it that this doesn't happen again.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info
Official Email ID: [EMAIL PROTECTED]

Re: GSoC projects

[Madhusudan C.S]

Hi antrik,

Well, I do actually see one problem with hosting it on Savannah: It
> means every wiki committer needs To have a Savannah account, be part of
> the Hurd project, and have commit rights. (Which means commit rights to
> all Hurd stuff, unless Savannah has a way to selectively give commit
> permissions for individual git repositories...)


These things are involved in github.com also, but not as stringent. To
commit
to a repository at github.com one needs an account at github.com. The
procedure
of creating a new account is so simple that it should not take more than a
minute
to get an account ready. And after that what all it needs is to upload SSH
Key
and send me the login name at github.com. But since I will be online most of
the
time, sending a mail to me and getting this done should not take much time.

But maybe that's not really a big issue, considering that with the need
> for copyright assignment, outsiders are not very likely to be interested
> in Git access to the wiki anyways...


That's absolutely true. In fact this is what is keeping some of them away
from
contributing ;-)


> The real reason for setting up a repository on github is that discussing
> things on the mailing list; waiting for some Savannah Hurd admin to set
> things up etc.; is precisely *not* what we wanted here -- we need a
> *quick* and easy solution for the needs of organising GSoC stuff.
> (Especially as you are the only admin who has been active over the past
> two years or so, and even you have been mostly absent over the past
> couple of months.)


I should have said this in my first mail to Thomas. Sorry for not making it
clear. Thank you a lot for telling this.

To make matters worse, when I asked you a couple of days ago what you
> propose to do about the wiki situation, you gave me an answer that,
> quite frankly, sounded like "wait and pray" -- so I decided to take
> initiative and look for another solution. Luckily, with the
> decentralized nature of Git, this in to problem at all. (Except perhaps
> for some additional noise in the history...)


I am both waiting and praying from many days ;-)


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: GSoC projects

[Madhusudan C.S]

Hi Thomas, antrik

On Mon, Aug 4, 2008 at 6:47 AM, <[EMAIL PROTECTED]> wrote:

> Hi,
>
> On Sat, Aug 02, 2008 at 07:12:25PM +0200, Thomas Schwinge wrote:
>
> > I'd say it should clearly reside in an external module, on its own. As
> > it is a stand-alone thing, a separate translator.
>
> The same could be said about all or most of the other translators
> presently in the Hurd source tree...
>
> I don't really have a strong opinion on making the Hurd build (and
> repository) more modular in general, or keeping it as is. But as long as
> it is like now, it's not acceptable to ban some components to different
> modules, while others are part of the Hurd itself. This inevitably would
> mean that those outside the main tree will be second class citizens --
> less maintaining, less visibility, no inclusion in Debian, more
> reluctance by users and develorpos to use them or rely on them...
>
> Really, there is no reason for the new code to be treated as second
> class citizens, just because it happens to come later than some other
> code.
>
> And if you are tempted to argue against this on any kind of theoretic
> grounds, just take a look at the real (and unchanging) situation with
> hurdextras.
>
> The code produced here is too valuable to end up like this.
>

I seriously did not know these were the reasons to keep a translator
within or outside the Hurd main source tree. I had thought if it was
a translator and the code is copyrighted to FSF it will go into Hurd
Main Source tree. If someone chooses to hold the Copyright to himself
it will be kept outside main Hurd source probably at hurd extras.
Thanks antrik for helping me out to know why this should actually
go into Hurd main tree. But I have no preferences. It is as Hurd admins
(Thomas and all) wish. I am happy where ever it is as long as the work
is useful in some way. (Hope Google's investment of 5000$ (for free
software) on me doesn't go waste.)


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: GSoC projects

[Madhusudan C.S]

Hi antrik

>
> > and send me the login name at github.com.
>
> I registered as antrik now.


You can commit now :-)



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: ikiwiki fuckup...

[Madhusudan C.S]

Hi Thomas,


> The procfs change was uncommitted, which I can commit as soon as we know
> who's the author, and the other change was a merge conflict which I'll
> resolve as soon as I get access to flubber again.
>
>
>diff --git a/community/procfs.mdwn b/community/procfs.mdwn
>index 472c66c..b12f407 100644
>--- a/community/procfs.mdwn
>+++ b/community/procfs.mdwn
>@@ -210,6 +210,26 @@ Clone URL: [git://
> github.com/madhusudancs/procfs.git](git://github.com/madhusuda
> * cnswap
> > Cumulative nswap for child processes (not maintained).
>
>+* flags
>+> PF_* fields defined in (Not Linux compatible, but nearly says the
> something Linux says)
>+
>+#File - /proc//statm
>+
>+* size
>+> total program size
>+
>+* resident
>+> resident set size
>+
>+* lib
>+> library
>+
>+* dt
>+> dirty pages
>+
>+#Other Per-PID Files
>+
>+#* /proc//cwd
>
> I already know the where the information is exactly available.
>
>@@ -220,15 +240,8 @@ Clone URL: [git://
> github.com/madhusudancs/procfs.git](git://github.com/madhusuda
> * cstime
> > The number of jiffies that this process's waited-for children have
> been scheduled in kernel mode.
>
>-#File - /proc//statm
>-
>-* resident
>-> resident set size
>-
> #Other Per-PID Files
>
>-#* /proc//cwd
>-
> #* /proc//exe
>
> #* /proc//environ
>@@ -266,9 +279,6 @@ Clone URL: [git://
> github.com/madhusudancs/procfs.git](git://github.com/madhusuda
>
> #File - /proc//statm
>
>-* size
>-> total program size
>-
> * text
> > text (code)
>
>@@ -333,19 +343,17 @@ Clone URL: [git://
> github.com/madhusudancs/procfs.git](git://github.com/madhusuda
> * delayacct_blkio_ticks
> > Aggregated block I/O delays, measured in clock ticks (centiseconds).
>
>-* flags
>-> PF_* fields defined in
>-
>
>- Need not be implemented.
>+###Newly added to Roadmap(but these were the original goals of the
> project)
>
>-#File - /proc//statm
>-
>-* lib
>-> library (not required)
>+ procps tools need to be ported so that they run on top of the
> procfs
>
>-* dt
>-> dirty pages (not required)
>+> # pgrep-  Done
>+> # pkill-  Done
>+> # killall  -  Done
>+> # pstree   -  Done
>+> # top  -  In progress
>+> # free -  Needs to be worked on
>
>
> --
>
>
>diff --cc community/scolobb.mdwn
>index 97d269f,c4c4cbd..000
>--- a/community/scolobb.mdwn
>+++ b/community/scolobb.mdwn
>@@@ -34,9 -34,9 +34,17 @@@ The code is at 
>  TODO:
>
>++<<< HEAD:community/scolobb.mdwn
> +* Provide proxy nodes (modify the standard version of
> netfs_S_dir_lookup).
>++===
>+ * Provide shadow nodes (modify the standard version of
> netfs_S_dir_lookup).
>++>>>
> ea856c169cb58f1120e49d2915753ecfa6c6fae4:community/scolobb.mdwn
>
>++<<< HEAD:community/scolobb.mdwn
> +* Create the generic filtering translator.
>++===
>+ * Create the generic filter translator.
>++>>>
> ea856c169cb58f1120e49d2915753ecfa6c6fae4:community/scolobb.mdwn
>
>  * Create the translator '0' (providing the untranslated version of the
>node).
>@@@ -62,9 -62,9 +70,17 @@@
>
>  ###Progress
>
>++<<< HEAD:community/scolobb.mdwn
> +6: Mon Aug 4 - ?
>++===
>+ 6: Sun Aug 3 - ?:
>++>>>
> ea856c169cb58f1120e49d2915753ecfa6c6fae4:community/scolobb.mdwn
>
>++<<< HEAD:community/scolobb.mdwn
> +> Implementing the proxy nodes.
>++===
>+ > Implement the shadow nodes.
>++>>>
> ea856c169cb58f1120e49d2915753ecfa6c6fae4:community/scolobb.mdwn
>
>  5: Thu Jul 24 - Thu Jul 24:
>
>
>
Thanks a lot Thomas for taking this responsibility. Yes this diff belongs to
me, name : Madhusudan.C.S



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

CVS help needed, top and htop

[Madhusudan C.S]

Hi antrik, Samuel and all,
antrik and Samuel I have been trying to meet either of you on
IRC from past couple of days but I am just not able to for some or
the other reason.

First of all, I wanted a small help regarding CVS. Should I now simply
copy the directory of my project i.e procfs into the Hurd Source Tree
of my branch that I have already checked out and just do cvs add procfs
and commit it or should I do a cvs import of my project ?

Also I have a small confusion regarding Changelog. antrik, I happened
to go through the IRC logs between you and Zhengda and got few points.
But these are my specific doubts. Should I have to create the new
Changelog now while committing to the CVS. Or can I just reuse the
original Changelog I had created which you said doesn't make much
sense to maintain a separate Changelog as long as I use git (if you
remember) ?

And can you please suggest me how should the entry in the Changelog
and also the commit log for the very first log be ?

This is what I intend to write it as, is this Ok or do you suggest something
else

2006-07-13 Madhusudan.C.S. <[EMAIL PROTECTED]>

* Initial commit of the procfs translator. The entire history
   of development is available at
   http://github.com/madhusudancs/procfs/tree/master.
   This provides a GNU/Linux compatible /proc filesystem
   which can now support procps tools like pgrep, pkill, kill
   tload, top, free and psmisc tools like killall and pstree.
   It also supports htop to run over it.

Also now regarding the porting of these tools, top and htop mostly
works as I have written in the wiki page. The per-PID shared memory
coloumn and the non per-PID Caches and Buffers fields are the only
fields not working as they work in GNU/Linux now. Any suggestions
on these?

Also what do you intend me to do next? I was just thinking to stop
adding new features for a short time now and concentrate on docu-
mentation and fixing few small bugs I have indentified in the code.
But what do you suggest please?

And I have one very libnetfs specific host, to implement
/proc/self, I need to identify the process i.e the client which accesses
the procfs in someway, say the PID of the client, how to get that?
Can you suggest me some idea?

Finally, regarding patching procps. As I noted down, procps needs
to be patched at 3 places.
1. Is obviously changing PATH_MAX to 32 as Samuel suggested
in the last meeting.
2. In the file proc/version.c, the procps determines the version
of Linux kernel to which the /proc belongs to and as I suppose
it changes the way it reads the fields from /proc files vary.
But on Hurd this version is returned as 0.3.0 which is in no
way valid for procps. As of now I have Hard Coded it to
2.6.18, since the procfs I have written in most compatible
with that version of Linux. So how do you suggest I patch it?
Atleast here we need to differentiate between Hurd's version
   of procps and Linux's version of procps. How do I do it?
3. As per what we do above, the value of Hertz is determined
initially. So if its 2.6.x it uses the elf binaries methods to get
Hertz value from it other wise it calls Old_Hertz () [ An
incredible hack, in antrik's words ;-) ] function which then
may read from /proc/uptime file to determine Hertz.

So how to patch the 2 and the 3rd problems?


-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Help me in testing please

[Madhusudan C.S]

Hi all,
   I request any of you to help me in testing the procfs translator
and procps tools and htop. I have uploaded the binaries of procps and htop
in my blog and have written a small how-to do things. If anyone can help me
it will be of great use to me :-)

http://madhusudancs.info/procfs-testing-how-to-mini

antrik,
I will provide the patches to source packages as soon as
possible. But I have uploaded the binaries, if you want to make sure if the
procps tools which I am claiming to be working to test, you can make use of
the binaries if at all you want.

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

proc server build problem

[Madhusudan C.S]

Hi all,
  I am trying from a long time. But the build of proc server in hurd
is failing when I run make proc. The build error is below. Can someone tell
me what the problem is?

mv -f cancel-cond.d.new cancel-cond.d
set -e; gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I.
-I../../hurd/libthreads -I.. -I../../hurd -I../include -I../../hurd/include
-D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1
-DHAVE_USELOCALE=1 -M -MG ../../hurd/libthreads/stack.c  | sed > stack.d.new
-e 's/stack\.o:/stack.o stack_pic.o stack_p.o stack.d:/' -e 's% [^
]*/gcc-lib/[^ ]*\.h%%g'
mv -f stack.d.new stack.d
set -e; gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I.
-I../../hurd/libthreads -I.. -I../../hurd -I../include -I../../hurd/include
-D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1
-DHAVE_USELOCALE=1 -M -MG ../../hurd/libthreads/cthreads.c  | sed >
cthreads.d.new -e 's/cthreads\.o:/cthreads.o cthreads_pic.o cthreads_p.o
cthreads.d:/' -e 's% [^ ]*/gcc-lib/[^ ]*\.h%%g'
mv -f cthreads.d.new cthreads.d
set -e; gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I.
-I../../hurd/libthreads -I.. -I../../hurd -I../include -I../../hurd/include
-D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1
-DHAVE_USELOCALE=1 -M -MG ../../hurd/libthreads/cthread_data.c  | sed >
cthread_data.d.new -e 's/cthread_data\.o:/cthread_data.o cthread_data_pic.o
cthread_data_p.o cthread_data.d:/' -e 's% [^ ]*/gcc-lib/[^ ]*\.h%%g'
mv -f cthread_data.d.new cthread_data.d
set -e; gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I.
-I../../hurd/libthreads -I.. -I../../hurd -I../include -I../../hurd/include
-D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1
-DHAVE_USELOCALE=1 -M -MG ../../hurd/libthreads/cprocs.c  | sed >
cprocs.d.new -e 's/cprocs\.o:/cprocs.o cprocs_pic.o cprocs_p.o cprocs.d:/'
-e 's% [^ ]*/gcc-lib/[^ ]*\.h%%g'
mv -f cprocs.d.new cprocs.d
set -e; gcc -std=gnu99 -fgnu89-inline -g -O3 -g -O2 -I.
-I../../hurd/libthreads -I.. -I../../hurd -I../include -I../../hurd/include
-D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1
-DHAVE_USELOCALE=1 -M -MG ../../hurd/libthreads/call.c  | sed > call.d.new
-e 's/call\.o:/call.o call_pic.o call_p.o call.d:/' -e 's% [^ ]*/gcc-lib/[^
]*\.h%%g'
mv -f call.d.new call.d
make[1]: Leaving directory `/root/hurdcorrectbuild/libthreads'
make: *** [libthreads] Error 2


Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

RPC implementation - Help me please

[Madhusudan C.S]

Hi all,
 I added 2 routines in $(HURD-SRC)/hurd/process.defs with the names
proc_child_rusage and proc_progeny_usage. And then in
$(HURD-SRC)/proc/info.c, I implemented S_proc_child_rusage and
S_proc_progeny_usage. And then I did make proc from top level directory of
Hurd source tree, i.e $(HURD-SRC) and then did make install from
$(HURD-SRC)/proc directory. Everything went fine, it seems. But when I use
those RPCs in my source code, I am getting error during linking, what am I
missing, do I have to register these routines somewhere else? Can someone
help me please?

-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: RPC implementation - Help me please

[Madhusudan C.S]

On Mon, Aug 25, 2008 at 2:11 AM, Da Zheng <[EMAIL PROTECTED]> wrote:

> Madhusudan C.S wrote:
>
>> Hi all,
>> I added 2 routines in $(HURD-SRC)/hurd/process.defs with the names
>> proc_child_rusage and proc_progeny_usage. And then in
>> $(HURD-SRC)/proc/info.c, I implemented S_proc_child_rusage and
>> S_proc_progeny_usage. And then I did make proc from top level directory of
>> Hurd source tree, i.e $(HURD-SRC) and then did make install from
>> $(HURD-SRC)/proc directory. Everything went fine, it seems. But when I use
>> those RPCs in my source code, I am getting error during linking, what am I
>> missing, do I have to register these routines somewhere else? Can someone
>> help me please?
>>
> Are you sure that you're using the modified proc in your system? for
> example, do you reboot your system?


Yeah I have rebooted my  machine, still no change.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: RPC implementation - Help me please

[Madhusudan C.S]

On Mon, Aug 25, 2008 at 3:54 AM, Samuel Thibault <
[EMAIL PROTECTED]> wrote:

> IIRC you need to recompile glibc too, to have the RPC functions added to
> libhurduser.
>

apt-get source glibc and dpkg-buildpackage -uc -B fails for some weird
compilation errors in bsd files. I forgot to log the errors. Is this a known
bug or is it necessary to give the build logs to find out what it is?
Moreover dpkg-buildpackage again is such a pain. Is there any alternative
for building and installing glibc from source? I tried CVS of glibc but in
vain.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: RPC implementation - Help me please

[Madhusudan C.S]

On Thu, Aug 28, 2008 at 12:29 AM, Michael Banck <[EMAIL PROTECTED]> wrote:

> On Thu, Aug 28, 2008 at 12:23:36AM +0530, Madhusudan C.S wrote:
> > apt-get source glibc and dpkg-buildpackage -uc -B fails for some weird
> > compilation errors in bsd files. I forgot to log the errors. Is this a
> known
> > bug or is it necessary to give the build logs to find out what it is?
>
> Luckily, glibc keeps a build log for you under debian/, the exact name
> of which I do not know by heart.
>
> > Moreover dpkg-buildpackage again is such a pain. Is there any alternative
> > for building and installing glibc from source?
>
> It's unclear what exactly you mean with `pain', so it is difficult to
> suggest alternatives.


Pain in the sense it takes a hell lot of time to build on my machine. It
took around 6-7 hours or so to build for the first time, that too it did not
complete. Also I did not get the logs. I will send in next mail. I think its
same as Zhengda reported on IRC.



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info

Re: RPC implementation - Help me please

[Madhusudan C.S]

On Thu, Aug 28, 2008 at 4:31 AM, Samuel Thibault <
[EMAIL PROTECTED]> wrote:

> Madhusudan C.S, le Thu 28 Aug 2008 00:23:36 +0530, a écrit :
> > On Mon, Aug 25, 2008 at 3:54 AM, Samuel Thibault <
> [EMAIL PROTECTED]>
> > wrote:
> >
> > IIRC you need to recompile glibc too, to have the RPC functions added
> to
> > libhurduser.
> >
> >
> > apt-get source glibc and dpkg-buildpackage -uc -B fails for some weird
> > compilation errors in bsd files. I forgot to log the errors. Is this a
> known
> > bug or is it necessary to give the build logs to find out what it is?
>
> IIRC it's a know error. hurd=20080607-4 will fix it, you can fetch its
> debian/ directory from
> svn://svn.debian.org/svn/pkg-hurd/hurd/trunk/debian


Should I have to change the names of files and directories to -4 or is it
just
a matter of replacing the debian directory? Are there any other changes?

> Moreover dpkg-buildpackage again is such a pain. Is there any
> > alternative for building and installing glibc from source?
>
> Well in any case glibc is very long to compile yes.  Maybe it's possible
> to just ask for the compilation of libhurduser though.
>

How to do it using dpkg-buildpackage? Or should I have to just run
make libhurduser from the top level directory of the glibc source?



-- 
Thanks and regards,
Madhusudan.C.S

Blogs at: www.madhusudancs.info