Subhashish Pradhan, le Sun 24 Aug 2014 04:31:34 +0530, a écrit :
> Do you think I could mention this project in my CV after I complete
> the port as a part of the work done for the GNU Project?
Sure!
Samuel
Hello,
I've successfully passed the final evaluations for the project. Thanks
for your mentor-ship.
This week I'll take a break to plan the next steps for this project.
For the code submission, the patch set will not include the "teaching
of the link flags".
Do you think I could mention this pro
Subhashish Pradhan, le Sun 17 Aug 2014 20:07:25 +0530, a écrit :
> I moved back to my college hostel this week so it was a bit busy.
> I apologise for the delay.
Sure. The firm deadline is google's, not mine :)
> I think you put my situation into words perfectly. Well, here's the report
> [1].
Hello again!
Any thoughts about the error?
On Sun, Aug 17, 2014 at 8:07 PM, Subhashish Pradhan wrote:
> On Mon, Aug 11, 2014 at 9:54 PM, Samuel Thibault
> wrote:
>> Hello,
>>
>> Any news about your project? We haven't seen you on IRC for a long
>> time, and no news by mail... Remember that th
Um, could you wait a day or two? I'm preparing the report.
Thanks!
On Mon, Aug 11, 2014 at 9:54 PM, Samuel Thibault
wrote:
> Hello,
>
> Any news about your project? We haven't seen you on IRC for a long
> time, and no news by mail... Remember that the soft deadline is today,
> and the hard dea
Hello,
Any news about your project? We haven't seen you on IRC for a long
time, and no news by mail... Remember that the soft deadline is today,
and the hard deadline is on next monday. Also, remember that it is
completely OK to say that the initial goals were not hit, if you explain
why, and I
Subhashish, le Thu 24 Jul 2014 22:08:09 +0530, a écrit :
> I'm getting this weird error, that I can't seem to understand.
>
> The log is here: http://pastebin.com/UrX2bQf0
Well, the probleme is that gcc is not given any .o file, the issue is
probably somewhere in the Makefile.
Samuel
Hello,
I'm getting this weird error, that I can't seem to understand.
The log is here: http://pastebin.com/UrX2bQf0
Subhashish
Subhashish, le Wed 09 Jul 2014 03:14:15 +0530, a écrit :
> Plus I'm getting some weird errors. Can you help me figure out what they
> mean?
>
> There are three errors listed here - http://pastebin.com/cmH8Zf1g
I'd say do not care about m_signals.c, just do not let it built on
GNU/Hurd. I don't th
Subhashish, le Tue 08 Jul 2014 06:35:43 +0530, a écrit :
> In m_signals.c, there is use of a symbol VKI_SA_NOCLDWAIT or SA_NOCLDWAIT.
You mean in the calculate_SKSS_from_SCSS function, right?
I believe you will not need calculate_SKSS_from_SCSS and friends, i.e.
do not let do_sys_sigaction, set_d
Plus I'm getting some weird errors. Can you help me figure out what they
mean?
There are three errors listed here - http://pastebin.com/cmH8Zf1g
20: I mailed about it earlier.
25: This one I don't get.
32: Seems like I need to add a VGO_gnu case and an appropriate
definition for VG_UCONTEXT_
POSIX specifies that setting SA_NOCLDWAIT in sigaction.sa_flags for SIGCHLD
has the same effect on wait* behavior as using SIG_IGN for
sigaction.sa_handler for SIGCHLD. So, by POSIX rules you can just as well
use SIG_IGN if you do not care to actually handle the signal.
However, the Hurd does not
Subhashish, le Wed 09 Jul 2014 03:14:15 +0530, a écrit :
> P.S. - @youpi - I've been to #hurd on IRC these days but it seems you don't
> hang out there, maybe you're busy. I wanted to step up my communication.
I am unfortunately away for the past two weeks. I'll be available next
two weeks.
Samue
On Wednesday 09 July 2014 03:22 AM, Samuel Thibault wrote:
Subhashish, le Wed 09 Jul 2014 03:14:15 +0530, a écrit :
P.S. - @youpi - I've been to #hurd on IRC these days but it seems you don't
hang out there, maybe you're busy. I wanted to step up my communication.
I am unfortunately away for t
Hello,
In m_signals.c, there is use of a symbol VKI_SA_NOCLDWAIT or SA_NOCLDWAIT.
It's not provided in /usr/include and on google I found reports of
pulseaudio builds using this particular constant.
It was commented that the symbol SIG_IGN can be its equivalent. So
should I use that?
Regards,
Hello,
I took some time off to look at my project state and wrote a status
report[1].
Regards,
Subhashish
1 - http://sprkv5.wordpress.com/2014/07/02/gsoc-status-report-1/
Subhashish, le Sat 28 Jun 2014 01:41:12 +0530, a écrit :
> On Wednesday 25 June 2014 04:24 PM, Samuel Thibault wrote:
> >Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
> >>I assume the generated *.h and *.c files will have to be included into the
> >>vki-scnums-gnu.h file and then manipul
On Saturday 28 June 2014 01:41 AM, Subhashish wrote:
On Wednesday 25 June 2014 04:24 PM, Samuel Thibault wrote:
Hello,
Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
The host system traps plus the syscalls( like __NR_rename are to be
encapsulated within an rpc generated via mig - my
On Wednesday 25 June 2014 04:24 PM, Samuel Thibault wrote:
Hello,
Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
The host system traps plus the syscalls( like __NR_rename are to be
encapsulated within an rpc generated via mig - my guess)
are to be listed there.
No. This file should
Subhashish, le Thu 26 Jun 2014 05:34:59 +0530, a écrit :
> https://github.com/sprkv5/valgrind-hurd/blob/main/include/vki/vki-scnums-x86-gnu.h
>
> Is this way proper for the traps to be listed?
Well, we'll see when we actually implement wrappers for them.
But at least I don't think you need to ke
On Wednesday 25 June 2014 04:24 PM, Samuel Thibault wrote:
Hello,
Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
But I couldn't wrap my head around listing the generated mig interfaces for
the traps in vki-scnums-gnu.h.
Err, mig does not have to do with traps. Traps are just the ker
Hello,
Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
> But I couldn't wrap my head around listing the generated mig interfaces for
> the traps in vki-scnums-gnu.h.
Err, mig does not have to do with traps. Traps are just the kernel
interface, mig is not involved there at all. Mig only
On Tuesday 24 June 2014 06:21 PM, Samuel Thibault wrote:
Samuel Thibault, le Wed 18 Jun 2014 00:38:37 +0200, a écrit :
Subhashish, le Mon 16 Jun 2014 15:38:58 +0530, a écrit :
On Sunday 15 June 2014 12:11 AM, Samuel Thibault wrote:
How is it going?
Please feel free to come on the IRC channel
Subhashish, le Wed 04 Jun 2014 05:03:53 +0530, a écrit :
> Second the in the log in line 38 we have "return VG_(do_syscall1)(__NR_dup,
> oldfd);" .
> The linux one just #defines it(__NR_dup) with a number, whereas darwin's
> does it with this VG_DARWIN_SYSCALL_CONSTRUCT_UNIX(41). How do we do it?
Hello,
I'm stuck with this long log of errors and warnings: [5]
Now, I understand a couple of things:
First the VKI_EACCES symbol is to be defined in vki-gnu.h.
Second the in the log in line 38 we have "return
VG_(do_syscall1)(__NR_dup, oldfd);" . Here __NR_dup is undeclared and it
has to be
Subhashish, le Mon 02 Jun 2014 04:31:02 +0530, a écrit :
> In case of
>
> #elif defined(VGO_gnu)
>vg_assert(0);
>
> I'm now changing it to
>
>
> #elif defined(VGO_gnu)
>SysRes res;
>vg_assert(0);
>
> for the 'return res;' at the end of the modified functions are coming
> back to ha
On Thursday 29 May 2014 05:36 AM, Samuel Thibault wrote:
> Subhashish, le Thu 29 May 2014 04:57:55 +0530, a écrit :
>> This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2].
>>
>> Now this vki-gnu.h is supposed to be the gnu/hurd specific kernel
interface
.
.
.
> One thing you need
Subhashish, le Sun 01 Jun 2014 18:26:25 +0530, a écrit :
> I'm sure this using of system headers is not the way, but it can be easily
> swapped out when the redefining-from-scratch implementation is ready. I'm
> going with the darwin one now for that seems quick. I'll work on the other
> implementa
On Saturday 31 May 2014 06:32 AM, Samuel Thibault wrote:
Subhashish, le Sat 31 May 2014 06:23:39 +0530, a écrit :
Now since I've #include-ed "i386-gnu/bits/resource.h", do I need to #define
the RLIMIT_* symbols with VKI_ prefixes?
vki-linux.h doesn't but darwin's does.
vki-linux does, in the
On Saturday 31 May 2014 06:32 AM, Samuel Thibault wrote:
Subhashish, le Sat 31 May 2014 06:23:39 +0530, a écrit :
Now since I've #include-ed "i386-gnu/bits/resource.h", do I need to #define
the RLIMIT_* symbols with VKI_ prefixes?
vki-linux.h doesn't but darwin's does.
vki-linux does, in the
Subhashish, le Sat 31 May 2014 06:23:39 +0530, a écrit :
> Now since I've #include-ed "i386-gnu/bits/resource.h", do I need to #define
> the RLIMIT_* symbols with VKI_ prefixes?
>
> vki-linux.h doesn't but darwin's does.
vki-linux does, in the vki-*-linux.h files.
> Moreover, ours are inside eum
On Saturday 31 May 2014 04:29 AM, Samuel Thibault wrote:
Subhashish, le Sat 31 May 2014 04:24:27 +0530, a écrit :
The symbol VKI_PATH_MAX cannot be defined since symbol PATH_MAX is not
defined[3].
Can we have workarounds - based on realloc, or like xgethostname() as
described.
Yes, but that'll
Subhashish, le Sat 31 May 2014 04:24:27 +0530, a écrit :
> The symbol VKI_PATH_MAX cannot be defined since symbol PATH_MAX is not
> defined[3].
> Can we have workarounds - based on realloc, or like xgethostname() as
> described.
Yes, but that'll be tedious (there are quite a few occurrences) and
u
On Saturday 31 May 2014 04:19 AM, Subhashish wrote:
On Thursday 29 May 2014 05:36 AM, Samuel Thibault wrote:
Subhashish, le Thu 29 May 2014 04:57:55 +0530, a écrit :
This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2].
Now this vki-gnu.h is supposed to be the gnu/hurd specifi
On Thursday 29 May 2014 05:36 AM, Samuel Thibault wrote:
Subhashish, le Thu 29 May 2014 04:57:55 +0530, a écrit :
This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2].
Now this vki-gnu.h is supposed to be the gnu/hurd specific kernel interface
as the linux one ("vki/vki-linux.h"
Subhashish, le Thu 29 May 2014 04:57:55 +0530, a écrit :
> This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2].
>
> Now this vki-gnu.h is supposed to be the gnu/hurd specific kernel interface
> as the linux one ("vki/vki-linux.h") tells.
Ah, so that's the interesting part :)
> Fu
Hello,
I have a query:
This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2].
Now this vki-gnu.h is supposed to be the gnu/hurd specific kernel
interface as the linux one ("vki/vki-linux.h") tells.
Further there are warnings(I may ignore them, might I?) and errors -
which rela
Subhashish, le Sat 24 May 2014 01:33:31 +0530, a écrit :
> I just wanted to ask that in configure.ac, whether I should
> >Set up VGCONF_ARCHS_INCLUDE_.
> >set up VGCONF_OS_IS_
> or leave it to be done when required?
for ARCHS_INCLUDE, it'll be in X86, xX86_GNU, and define a
VGCONF_OS_IS_GNU, indee
Hello,
I got the configure checks to pass;
Here's the log: http://pastebin.com/KCPceTU4
I just wanted to ask that in configure.ac, whether I should
Set up VGCONF_ARCHS_INCLUDE_.
set up VGCONF_OS_IS_
or leave it to be done when required?
Any other recommendations?
Regards,
Subhashish
Hello,
Here's the repository for valgrind-hurd:
https://github.com/sprkv5/valgrind-hurd.git
The branches are:
main - The experimental development branch
master - The default development branch
master-clean - The branch without any changes
Regards,
Subhashish
40 matches
Mail list logo
