[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I/O permission control in OSKit-Mach
From: |
Thomas Schwinge |
Subject: |
Re: I/O permission control in OSKit-Mach |
Date: |
Tue, 24 Apr 2007 14:50:52 +0200 |
User-agent: |
Mutt/1.5.11 |
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+
> > struct device {
> > [...]
> > union {
> > struct {
> > oskit_blkio_t *io;
> > oskit_u32_t size; /* block size */
> > #define MAX_PARTS 30
> > diskpart_t *parts;
> > } blk;
> > [...]
> > #if defined(__i386__)
> > struct
> > {
> > io_port_t from, to;
> > } io_perm;
> > #endif
> > } com;
> > };
> > #v-
>
> Is coming up with a new kernel object class and a new zalloc zone the way
> to go for GNU Mach? Something like a combination of a ``struct device''
> and a ``io_port_t from, to''?
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
`kalloc'ed memory, added such a deallocation as well -- and now get a
kernel page fault after having `kfree'ed that memory in a ``no senders''
service routine. If I leave away the `kfree' then everything is fine,
save the memory leak, of course. Hmm.
Is there any Mach savvy person who feels like helping poor tschwinge?
Regards,
Thomas
signature.asc
Description: Digital signature