Re: [RFC] kern: simple futex for gnumach (version 11)
On Fri, Jan 10, 2014 at 08:28:12AM +0100, Marin Ramesa wrote: > On 01/10/2014 01:59:55 AM, Richard Braun wrote: > >On Thu, Jan 09, 2014 at 09:51:51PM +0100, Marin Ramesa wrote: > >> On 01/09/2014 05:52:21 PM, Richard Braun wrote: > >> >On Thu, Jan 09, 2014 at 05:06:09PM +0100, Marin Ramesa wrote: > >> >> Shouldn't the compare be atomic. Maybe I don't understand what > >> >> atomic really > >> >> means but the GCC manual says this function is. Or is it > >enough to > >> >> hold the lock. > >> > > >> >From the GCC manual : > >> >"These built-in functions perform an atomic compare and swap. > >That is, > >> >if the current value of *ptr is oldval, then write newval into > >*ptr". > >> >So tell us what the point of replacing oldval with itself is. > >> > >> I do a swap so it returns true if they are equal. > > > >I'll say it again because it doesn't look like you got it : when I > >point > >something out to you, consider you're wrong, and make the effort to > >question your assumptions. You may end up being right at times, > >but most > >often not. Now please, read your code again, then answer the > >question I > >asked : "So tell us what the point of replacing oldval with itself > >is". > > OK, sorry. There's no point. I couldn't find just an atomic compare, so > I'm using the compare-and-swap this way. I'll read more in the GCC > manual, > maybe there is another way. Reading correctly aligned integers that are not wider than the processor word size is already atomic. But there still is a problem I mentioned in another review and forgot this time : On Thu, Jan 09, 2014 at 03:45:35PM +0100, Richard Braun wrote: > On Wed, Jan 08, 2014 at 08:43:28PM +0100, Marin Ramesa wrote: > > +routine futex_wait( > > + task: task_t; > > + address : vm_offset_t; > > + value : int; > > + msec: int; > > + private_futex : boolean_t); > > + > > +routine futex_wake( > > + task: task_t; > > + address : vm_offset_t; > > + wake_all: boolean_t); > > Looks good. You'll probably want the requeue operation too some day, but > that can wait. Actually, this isn't good. Rework the futex_wait routine so that it passes *memory* to the kernel, not raw values. Once the kernel can directly access the futex value, a plain memory access should do the job, but since I haven't read the futex paper in depth, I'm not even sure why this is done before queueing a thread on a futex, and what are the exact constraints on the system call. -- Richard Braun
Re: Valgrind porting
Hello again! I searched and asked around for 'teaching Valgrind syscalls', and I found that the syscall wrapper has to be implemented inside coregrind: precisely in coregrind/m_syswrap/syswrap-*.c. So the nature of this project involves implementing all the syscalls in the supposed to be coregrind/m_syswrap/syswrap-hurd.c, I presume? And then making the successful cross-compile to make it work? This is the second step as written in the project idea page, the first being doing the corresponding for kernel traps. (So how would these kernel traps be implemented, is the coregrind, I presume?) Where in the source of hurd/mach shall I find all the syscalls and kernel traps, so that I could make a list of them to study and to work on them? (the directory) I'll dig into the background knowledge for RPCs (syscalls) and kernel traps this week on. Feedbacks, please. Regards, Subhashish On Mon, Jan 6, 2014 at 2:25 PM, Samuel Thibault wrote: > Hello, > > Subhashish Pradhan, le Mon 06 Jan 2014 09:01:26 +0530, a écrit : > > So teaching valgrind the syscall means directing memcache tool to > > intercept the read/write operations of the syscall? > > It does not mean "intercepting", but writing in the valgrind source code > what read/write operations the syscall is supposed to be doing: valgrind > does not intercept anything, it just knows what syscalls are supposed to > read and write. > > > Is this memcache tool the one that handles read/write primitives of > > valgrind? > > Yes. > > Samuel >
About Regular IRC Meetings.
Hello, "Currently, the meetings take place in the *#hurd channel every Thursday at 19:00 UTC* and are open to any interested party." Are these held regularly? How long do they last? Can anyone drop in and discuss their queries related to the project? Regards, Subhashish.
Re: About Regular IRC Meetings.
On Sat, Jan 11, 2014 at 03:26:50AM +0530, Subhashish Pradhan wrote: > Hello, > > "Currently, the meetings take place in the *#hurd channel every Thursday at > 19:00 UTC* and are open to any interested party." > > Are these held regularly? How long do they last? > > Can anyone drop in and discuss their queries related to the project? That was done for the summer of code, and it will probably be done again next time. And yes, in the mean time, just come on the channel and ask your questions. But keep in mind that, in accordance with Hurd and IRC traditions, we may be long to answer, in particular during work/week ends/holidays, so let your client lurk there a few hours/days at least. -- Richard Braun
Re: Fwd: Valgrind porting
Subhashish Pradhan, le Sat 11 Jan 2014 03:14:25 +0530, a écrit : > So the nature of this project involves implementing all the syscalls in the > supposed to be coregrind/m_syswrap/syswrap-hurd.c, I presume? Yes. The good news is that there aren't many of them, just a couple dozen. The less good news is that the mach_msg syscall is quite complex. > And then making the successful cross-compile to make it work? Yes. > This is the second step as written in the project idea page, the first being > doing the corresponding for kernel traps. (So how would these kernel traps > be implemented, is the coregrind, I presume?) Kernel traps are the gnumach name for system calls. > Where in the source of hurd/mach shall I find all the syscalls and kernel > traps, > so that I could make a list of them to study and to work on them? (the > directory) include/mach/syscall_sw.h Samuel
Re: About Regular IRC Meetings.
Thanks! Will do. Regards, Subhashish On Sat, Jan 11, 2014 at 4:19 AM, Richard Braun wrote: > On Sat, Jan 11, 2014 at 03:26:50AM +0530, Subhashish Pradhan wrote: > > Hello, > > > > "Currently, the meetings take place in the *#hurd channel every Thursday > at > > 19:00 UTC* and are open to any interested party." > > > > Are these held regularly? How long do they last? > > > > Can anyone drop in and discuss their queries related to the project? > > That was done for the summer of code, and it will probably be done again > next time. And yes, in the mean time, just come on the channel and ask > your questions. But keep in mind that, in accordance with Hurd and IRC > traditions, we may be long to answer, in particular during work/week > ends/holidays, so let your client lurk there a few hours/days at least. > > -- > Richard Braun >
