Re: compat work.

[Paul Goyette <paul%whooppee.com@localhost>]

On Wed, 14 Mar 2018, Christos Zoulas wrote:

> On Mar 15, 10:11am, paul%whooppee.com@localhost (Paul Goyette) wrote:
> -- Subject: Re: compat work.
>
> | (Adding tech-kern@ to cc)
> |
> | Such "factoring out" is far beyond my capabilities, especially when we
> | get into areas such as the networking code.  There are just too many
> | parts of the system which I do not adequately understand.
> |
> | I can either maintain the current capabilities, warts and all, or I can
> | abandon the effort.  There is just too much spaghetti code already, and
> | too much "compat_xx" code which is only reachable when built-in.
> |
> | It would have been much more appreciated if you had done your work on
> | the branch, rather than completely invalidating the work I'd already
> | done.
>
> I will fix your branch. And you can ask others (or me) to refactor
> code as you need. It is going to be really difficult to maintain
> and debug the code if we we replace the ifdefs with weak variable
> conditionals when it is already a mess. At least now we can run
> unifdef the kernel code to remove the compat code. In the future
> this will become even more difficult. Perhaps we should leave a
> single ifdef in for that?

That might be useful.

> The goal should be to disentangle the compat code and move it out
> of the main source tree leaving out the minimum number of touchpoints
> (variables and functions) and not compat code segments.

My goal was to ensure that compat code can be reached, whether it was 
built-in to the kernel with compile-time #ifdef COMPAT_xx or it was 
loaded at a later time.  This goal was prompted during the 7.99.x time 
when I discovered that loading the compat module did not get me the 
changes that had been mad to some rtsock code;  the rtsock compatability 
was only available as built-in option.

> There is also the open question of locking as the variables/pointers
> can change while modules load and unload. What's the plan to handle
> that?

While that's a valid question, it's somewhat out of scope of the work 
I'm planning to do.  I have no intention of adding any new "autoload 
points" in any code, so the locking situation should not be affected.



+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+