bug-hurd
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]