On 12/29/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 09:43:23PM +0000, seventh guardian wrote:
> On 12/29/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> >On Fri, Dec 29, 2006 at 02:42:16PM +0000, seventh guardian wrote:
> >>
> >> OOPS it's not safe yet. There's a segmentation fault right in the
> >> beggining..... I'll try to find it.
> >
> >For such a dangerous change it would be good if you could split
> >the diffs into a series of self-contained patches that add/change
> >some of the functionality.  It would help to proof read the
> >changes.
>
> You're right.
>
> First, we are not dealing with module numbers, but pointers to a type
> fmodule. So execcontext.c/h needed changing. Here's the patch.

Okay, that patch looks safe.

Is there any chance to make bigger patches that compile when
applied and can actually be used?  This way we could validate the
code step by step.  For example, you could temporarily put the
modnum into the module struct and use "module->modnum instead" of
"modnum" for the moment.

It wouldn't be easy..

The position of a module inside the linked list keeps changing as we
add/remove modules. So the only way for the code to work is dealing
with module pointers instead of indexes.. Keeping an index within each
module would be a nightmare (keeping track of used/ free indexes..),
but could be done..

What I did for now to avoid a mess was to avoid the problem with the
cmd line modules fdsets. I've typecasted the module address to int, so
it should be fairly unique, and it works with the fdset lists.

Apart from that, testing small portions is harder than the whole thing..

Cheers
 Renato

Reply via email to