Re: compat work.

[christos%zoulas.com@localhost (Christos Zoulas)]

On Mar 15, 10:57am, paul%whooppee.com@localhost (Paul Goyette) wrote:
-- Subject: Re: compat work.
  
[leaving an ifdef to identify compat only code that can be removed]

| That might be useful.

I agree.

| 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.

That is my goal too. I have completed disentangling the compat swap code
so now you should be able to sync your branch with head (taking the head
changes) and it will all work. This is the way I envision compat things
to hook into the main code with minimal disruption.

| > 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.

Yes, but consider the scenario where you have multiple variables that
are affected by module loading and unloading that are reached while
executing the same function... This is why I want to keep the interface
between the compat code and the kernel with as few touchpoints as possible.

Best,

christos