Hello!
On Tue, Apr 24, 2007 at 03:04:26PM +0200, Richard Braun wrote:
> On Tue, Apr 24, 2007 at 02:50:52PM +0200, Thomas Schwinge wrote:
> > Okay, a new zalloc zone would be overkill, but I've implemented a tiny
> > new kernel object, lumped it all together -- and it even works, it seems!
> >
> >
On Tue, Apr 24, 2007 at 02:50:52PM +0200, Thomas Schwinge wrote:
> Okay, a new zalloc zone would be overkill, but I've implemented a tiny
> new kernel object, lumped it all together -- and it even works, it seems!
>
> But then noticed that I had forgotten to deallocate the kernel object's
> `kallo
Hello!
Continuing my monologue...
On Wed, Apr 11, 2007 at 06:08:07PM +0200, I wrote:
> On Sun, Apr 08, 2007 at 12:16:25PM +0200, I wrote:
> > But where would be the correct place in GNU Mach to store these
> > ``io_port_t from, to'' values?
> >
> > [OSKit-Mach]/oskit/ds_oskit.h
> > #v+
> > stru
Hello!
On Sun, Apr 08, 2007 at 12:16:25PM +0200, I wrote:
> On Mon, Apr 02, 2007 at 01:26:51PM -0700, Roland McGrath wrote:
> > The old device_emulation_ops stuff in i386at is similar,
> > i.e. it provides hooks to implement the device RPCs.
>
> But where would be the correct place in GNU Mach to
On Mon, Apr 02, 2007 at 01:26:51PM -0700, Roland McGrath wrote:
> The old device_emulation_ops stuff in i386at is similar,
> i.e. it provides hooks to implement the device RPCs.
But where would be the correct place in GNU Mach to store these
``io_port_t from, to'' values?
[OSKit-Mach]/oskit/ds_os
The old device_emulation_ops stuff in i386at is similar,
i.e. it provides hooks to implement the device RPCs.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Hello!
Since it's been six and a half years, let me first give some context
here...
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> here is a patch to implement I/O permission control in OSKit-Mach.
>
> What do you get?
>
>
> Two new interfaces:
>
> /* Req
> On Sat, Oct 20, 2001 at 10:42:35PM -0400, Roland McGrath wrote:
> > Indeed. I think the best plan is to scrutinize the pmap locking strategy
> > and do something similar.
>
> I am looking into this, but it looks quite hard. In fact, it requires an
> interrupt to signal the other processors (S
On Sat, Oct 20, 2001 at 10:42:35PM -0400, Roland McGrath wrote:
> Indeed. I think the best plan is to scrutinize the pmap locking strategy
> and do something similar.
I am looking into this, but it looks quite hard. In fact, it requires an
interrupt to signal the other processors (SMP_IPI_VECTO
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann said:
> This is not so cool as Kalles cursor move program, so:
>
> Exercise
>
>
> Reimplement Kalles cursor move test program so that it works on OSKit-Mach
> with the patch.
Attached.
Thanks,
Kevin
--
Kevin Kreamer
FsckIt on
> On Wed, Oct 17, 2001 at 04:43:55AM -0400, Roland McGrath wrote:
> >
> > I don't like `struct x86_tss_ext' as the name. Let's try to leave x86_* to
> > the oskit. Call it `task_tss' or `task_i386_tss' or something. Actually
> > you might as well just open-code it in the i386 `struct machine_t
On Wed, Oct 17, 2001 at 04:43:55AM -0400, Roland McGrath wrote:
>
> I don't like `struct x86_tss_ext' as the name. Let's try to leave x86_* to
> the oskit. Call it `task_tss' or `task_i386_tss' or something. Actually
> you might as well just open-code it in the i386 `struct machine_task'.
The
Indeed. I think the best plan is to scrutinize the pmap locking strategy
and do something similar.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Thu, Oct 18, 2001 at 03:32:05PM -0400, Roland McGrath wrote:
> > Also, what about i386_io_perm_modify vs another cpu switching to another
> > thread in the same task? The bad kinds of interactions I am worried
> > about is not so much the io_perm interface with itself, but with
> > task_termin
> In German you would say that I have tomatoes on my eyes. ;)
You mean egg on your face? :-)
> Mmh. What about i386_io_perm_modify vs. task_terminate on SMP? I don't
> want to scribble in deallocated pages.
Hmm, yes. I think you want to task_lock while diddling it and check
TASK->active (l
On Thu, Oct 18, 2001 at 01:57:33PM +0200, Marcus Brinkmann wrote:
> Mmh. What about i386_io_perm_modify vs. task_terminate on SMP?
Giving the answer myself: A task_terminate terminates all threads before it
deallocates the task.
> Also, what about i386_io_perm_modify vs another cpu switching to
On Thu, Oct 18, 2001 at 01:57:33PM +0200, Marcus Brinkmann wrote:
> I think keeping the bitmap around at the risk that it is not used anymore is
> better than the risk that io_permissions are often switched and you end up
> allocatin and freeing often. For both cases it is true that they probably
On Wed, Oct 17, 2001 at 04:43:55AM -0400, Roland McGrath wrote:
> > There are some details about the implementation which are not ideal, but ok:
> > Once a task gets a bitmap, it is never destroyed, even if no I/O ports are
> > enabled (all bits set). The bitmap is destroyed only with the task.
>
> There are some details about the implementation which are not ideal, but ok:
> Once a task gets a bitmap, it is never destroyed, even if no I/O ports are
> enabled (all bits set). The bitmap is destroyed only with the task.
All bits clear you mean. Anyway, this is not so really bad; tasks tha
If copying it all every time is good enough for Linux, it's good enough for us.
You can change the bitmap offset in the tss with little cost, so you can
always use a smaller bitmap stored at the tail end of the tss segment. For
each task, keep track of the highest port number whose bit is set.
On Tue, Oct 16, 2001 at 11:06:53AM +, Adam Olsen wrote:
> I can't
> think of any reason that we'd want segments larger than the smallest
> value we can manage.
Simplicity. The smallest value we can handle is a bit, and this is the
bitmap we have already. However, instead searching for bits
On Tue, Oct 16, 2001 at 12:09:07PM +0200, Marcus Brinkmann wrote:
> On Tue, Oct 16, 2001 at 05:48:02AM +, Adam Olsen wrote:
> > On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> > > A task requesting some I/O permission will get a full blown 8192 bytes large
> > > bitmap, whi
On Tue, Oct 16, 2001 at 12:09:07PM +0200, Marcus Brinkmann wrote:
> When you task switch, the segment bit maps are OR'ed, and only those segments
> are copied. The actual number of segments (and thus their length) can be
> tuned, 128, 256, 512 and 1024 are convenient values. Anybody has an idea
On Tue, Oct 16, 2001 at 05:48:02AM +, Adam Olsen wrote:
> On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> > A task requesting some I/O permission will get a full blown 8192 bytes large
> > bitmap, which is copied in the processor TSS at every switch to the task.
> > (Linux
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> A task requesting some I/O permission will get a full blown 8192 bytes large
> bitmap, which is copied in the processor TSS at every switch to the task.
> (Linux by default only uses a half bitmap, and provides a full one at
> req
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> /* Request a new port IO_PERM that represents the capability to access
>the I/O ports [FROM; TO] directly. MASTER_PORT is the master device port.
>The function returns KERN_INVALID_ARGUMENT if TARGET_TASK is not a task,
>
26 matches
Mail list logo
