Hello,
Ludovic Courtès, le Wed 14 Mar 2012 23:13:51 +0100, a écrit :
> This fixes compilation of user code in C99 or GNU99 mode.
Actually we have had a patch with the same kind of goal in Debian for
some time, which just needed some cleanup and commit, which I have done
the other day.
Samuel
Samuel Thibault, le Tue 03 Apr 2012 00:05:39 +0200, a écrit :
> Sergio López, le Tue 03 Apr 2012 00:00:02 +0200, a écrit :
> > 2012/4/2 Samuel Thibault :
> > > Sergio Lopez, le Mon 02 Apr 2012 17:09:08 +0200, a écrit :
> > >> El Mon, 02 Apr 2012 00:23:03 +0300
> > >> Maksym Planeta escribió:
> > >
Hello,
Svante Signell, le Fri 30 Mar 2012 12:55:17 +0200, a écrit :
> Finally gnat builds on GNU/Hurd,
Thanks!
I have uploaded packages on debian-ports, so we can consider that the
bootstrap step is done, thanks again!
We now need to fix the bugs ;)
Samuel
Sergio López, le Tue 03 Apr 2012 00:00:02 +0200, a écrit :
> 2012/4/2 Samuel Thibault :
> > Sergio Lopez, le Mon 02 Apr 2012 17:09:08 +0200, a écrit :
> >> El Mon, 02 Apr 2012 00:23:03 +0300
> >> Maksym Planeta escribió:
> >> > This function allows user advise the kernel about how to handle paging
2012/4/2 Samuel Thibault :
> Sergio Lopez, le Mon 02 Apr 2012 17:09:08 +0200, a écrit :
>> El Mon, 02 Apr 2012 00:23:03 +0300
>> Maksym Planeta escribió:
>> > This function allows user advise the kernel about how to handle paging
>> > input/output in specified memory range. There are several behav
Hi,
bringing this again, a couple of patches in "dirty form" to get further
review.
Attached there is my new attempt as it was previously discussed, i.e.
providing more data in the kernel page of mapped time.
* 01_types.diff:
This adds a new structure in time_value.h, making it named in a simi
Sergio Lopez writes:
> El Mon, 02 Apr 2012 00:23:03 +0300
> Maksym Planeta escribió:
>
>>
>> Hello,
>>
>> I want to work upon implementing of clustered page reading in
>> GNU/Mach, as GSoC project.
>
> I'm happy to know that you will be working on this. After your success
> with the slab alloc
Sergio Lopez, le Mon 02 Apr 2012 17:09:08 +0200, a écrit :
> El Mon, 02 Apr 2012 00:23:03 +0300
> Maksym Planeta escribió:
> > The goal of this project is not only add
> > ability of reading more than one page when page fault occurs, but
> > also implement appropriate interface for user to give hi
natural_t was traditionally the size of registers.
El Mon, 02 Apr 2012 00:23:03 +0300
Maksym Planeta escribió:
>
> Hello,
>
> I want to work upon implementing of clustered page reading in
> GNU/Mach, as GSoC project.
I'm happy to know that you will be working on this. After your success
with the slab allocator, I'm pretty sure you're going to
On Mon, Apr 02, 2012 at 12:23:03AM +0300, Maksym Planeta wrote:
> The project I suppose to work on is not new for GSoC. Two years ago a
> student, whose nick on irc channel is kam, tried to implement readahead,
> but didn't manage to do that for some reason. I looked through patch he
> has sent and
On Mon, Apr 02, 2012 at 03:21:06PM +0200, Samuel Thibault wrote:
> Because there is code in GNU Mach that uses mach_port_t as a pointer,
> see e.g. kdportdeath(), which just casts mach_port_t into ipc_port_t, or
> ipc_kmsg_copyin_header which casts back the just-resolved object into
> mach_port_t.
Richard Braun, le Mon 02 Apr 2012 14:58:55 +0200, a écrit :
> On Mon, Apr 02, 2012 at 02:54:17PM +0200, Samuel Thibault wrote:
> > > I believe we're thinking of two different things here. My current idea
> > > of the solution is to directly convert names (32-bits) to ports or other
> > > IPC object
On Mon, Apr 02, 2012 at 02:54:17PM +0200, Samuel Thibault wrote:
> > I believe we're thinking of two different things here. My current idea
> > of the solution is to directly convert names (32-bits) to ports or other
> > IPC objects (e.g. port sets, 64-bits).
>
> That's what I'm suggesting from th
Richard Braun, le Mon 02 Apr 2012 14:44:45 +0200, a écrit :
> On Mon, Apr 02, 2012 at 02:39:05PM +0200, Samuel Thibault wrote:
> > > I don't see the relation with segmentation and the 4GiB split.
> >
> > I said: "to avoid the trick", i.e. just use 32bit pointers, to just use
> > the same type as i
On Mon, Apr 02, 2012 at 02:39:05PM +0200, Samuel Thibault wrote:
> > I don't see the relation with segmentation and the 4GiB split.
>
> I said: "to avoid the trick", i.e. just use 32bit pointers, to just use
> the same type as in userland as you suggested.
>
> > What is the layout you expect for
Richard Braun, le Mon 02 Apr 2012 14:34:25 +0200, a écrit :
> On Mon, Apr 02, 2012 at 02:18:34PM +0200, Samuel Thibault wrote:
> > But then it needs some trick to convert to pointer everywhere needed.
> > Trying to manage low-4GiB allocation to avoid the trick would make
> > things nasty: remember
On Mon, Apr 02, 2012 at 02:18:34PM +0200, Samuel Thibault wrote:
> But then it needs some trick to convert to pointer everywhere needed.
> Trying to manage low-4GiB allocation to avoid the trick would make
> things nasty: remember that x86_64 does not have segmentation any more,
> only flat address
Richard Braun, le Mon 02 Apr 2012 14:12:27 +0200, a écrit :
> On Mon, Apr 02, 2012 at 01:57:31PM +0200, Samuel Thibault wrote:
> > Richard Braun, le Mon 02 Apr 2012 13:46:08 +0200, a écrit :
> > > How do they convert names from/to pointers ? Regular IPC space lookups ?
> >
> > Well, yes, just like
On Mon, Apr 02, 2012 at 01:57:31PM +0200, Samuel Thibault wrote:
> Richard Braun, le Mon 02 Apr 2012 13:46:08 +0200, a écrit :
> > How do they convert names from/to pointers ? Regular IPC space lookups ?
>
> Well, yes, just like GNU Mach does, in ipc_kmsg_copyin_header etc.
So we'd loose the opti
Richard Braun, le Mon 02 Apr 2012 13:46:08 +0200, a écrit :
> On Mon, Apr 02, 2012 at 12:35:25PM +0200, Samuel Thibault wrote:
> > Richard Braun, le Mon 02 Apr 2012 12:03:34 +0200, a écrit :
> > > Kernel port names are addresses of their target IPC port object.
> >
> > Inside the kernel, yes. In t
On Mon, Apr 02, 2012 at 12:35:25PM +0200, Samuel Thibault wrote:
> Richard Braun, le Mon 02 Apr 2012 12:03:34 +0200, a écrit :
> > Kernel port names are addresses of their target IPC port object.
>
> Inside the kernel, yes. In the userland processes, no. That's the
> difference that xnu makes betw
Richard Braun, le Mon 02 Apr 2012 12:03:34 +0200, a écrit :
> On Sun, Apr 01, 2012 at 05:45:19PM +0200, Samuel Thibault wrote:
> > I don't really see why there should be a "size of a pointer" property
> > anyway: AIUI, vm_offset_t and vm_size_t are there for that. I rather
> > see natural_t and int
On Sun, Apr 01, 2012 at 05:45:19PM +0200, Samuel Thibault wrote:
> I don't really see why there should be a "size of a pointer" property
> anyway: AIUI, vm_offset_t and vm_size_t are there for that. I rather
> see natural_t and integer_t as a "nice integer" type, i.e. something
> that can hold big
24 matches
Mail list logo
