Re: CVS help needed, top and htop

[olafBuddenhagen]

Hi,

On Thu, Aug 14, 2008 at 01:37:27AM +0530, Madhusudan C.S wrote:

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

This has been discussed at the last IRC meeting:

21:48:35< antrik> BTW, does anyone know how to import a new directory tree into 
CVS properly? or is it necessary to add each new file explicitely?
21:49:17< youpi> antrik: doesn't cvs add the_dir work ?
21:49:43< antrik> youpi: it only adds the dir, but not the files AFAIK
21:49:48< youpi> erf
21:50:17< antrik> there is cvs import, but I don't know if/how it can be used 
to add a new directory while preserving everything else...
21:50:53< youpi> cvs import adds a new module to my knowledge
21:51:20< antrik> so I guess it means adding each file explicitely. shouldn't 
be such a big deal really -- we are not dealing with complicated directory 
trees here...
21:52:42< antrik> so, just cvs add <directory>, cvs add *.[ch] ... (all the 
source files), and finally commit...

BTW, why do you assume that we two are the only people able to answer a
CVS question?...

Also, I usually read the backlog, i.e. everything that was said while I
was in the channel, even if I'm not replying immediately. 

In general, you should not wait for any particular person to be around
(unless of course you have something to discuss that immediately
concerns this person), but rather just ask away; and if you don't get a
reply, simply write a mail, instead of waiting and waiting...

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

I think it's good practice to fix small bugs ASAP in general :-)

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

Hm... Maybe I'm totally off, but doesn't /hurd/magic do something like
that?...

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

Note that the small allocation is the fix for only *one* of the places
whete PATH_MAX occurs. Again from the last IRC meeting:

21:50:35< youpi> madrazr: the PATH_MAX in readproc.c can clearly be replaced by 
a small constant, like 32
21:51:57< youpi> about the PATH_MAX used for readlink
21:52:22< youpi> the proper way is to have a loop that dynamically allocates 
arrays until readlink doesn't return ENAMETOOLONG
21:52:31< youpi> doubling the size each time

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

I don't understand. What is the problem if you just have procfs return
2.6.18?

-antrik-