Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Merge (was "Collapse") of the pgoyette-compat branch (fwd)



FWIW, it's been pointed out to me that "collapse" of the branch might
be mistakenly taken to indicate that the branch is beyond hope!  :)

Definitely not true - it's just an unfortunate holdover from a former
$DAYJOB.  Of course, the intended meaning was to "merge" the branch
back into mainline.



On Wed, 16 Jan 2019, Paul Goyette wrote:

On Wed, 16 Jan 2019, Kamil Rytarowski wrote:

On 16.01.2019 10:20, Paul Goyette wrote:
Given the dearth of response to the notice posted on current-users I
thought I'd widen the audience a bit, to make sure that all concerned
have a chance to react!

---------- Forwarded message ----------
Date: Mon, 14 Jan 2019 08:21:18 +0800 (PST)
From: Paul Goyette <paul%whooppee.com@localhost>
To: current-users%netbsd.org@localhost
Subject: Collapse of the pgoyette-compat branch

Folks,

Having reached today a significant milestone (conversion of the
rtsock_50 code to use function-pointers for callbacks), I'm ready
to collapse/merge the pgoyette-compat branch into HEAD.  Current
status of the branch, including a list of open items, can be found
at


What are the benefits of the new branch? All compat code usable as
modules?

Well, I haven't reached 100% yet, but much closer than before.

There's much more granularity than before, with a separate compat_xx
module per NetBSD version, rather than a single monolithic compat
module.  Similarly for those architectures that support it, there are
version-specific compat32_xx modules.  As a result, you can load (or
autoload) only as much compat code as you want - it's no longer an
all-or-nothing operation.

A lot of the #ifdef spaghetti that existed has been removed and
replaced with function pointers that get loaded or initialized when
optional code is built into the kernel.  Just as an example, the
vnd(4) driver is optional, but if it is present there are some
compat functions that the mainline driver needs to call (for some
compatability ioctl's).  The compat module simply provides it own
replacement function pointers, overriding the initial values (which
point at no-op functions).

There's also a mechanism for ensuring that a module doesn't get
unloaded while some other code is following one of these function
pointers.  (A very very VERY big thanks goes out to riastradh@ for
the basic design of this, using a combination of localcount(9) and
pserialize(9) for interlocking.)

One of the things that triggered my work here was the problem with
the rtsock code.  Most people know that I use modules whenever I
can, and that includes the compat stuff.  Yet when the rtsock code
was modified, the compat functions could only be reached if they
were built-in.  They could not be part of any compat module.  (Well,
they could be included in the compat module, but there was no
mechanism for the main rtsock code to call non-built-in compat
routines.)

There were also some module infrastructure changes made, mostly a
removal of some limitations.  There's no longer a maximum number of
"required" prerequisite modules, and there's also no limit to the
depth of recursion when loading "required" modules.

Please also look at the file

	[pgoyette-compat]src/sys/doc/TODO.compat-branch

for additional details.


Hopefully all this makes some sort of sense.  I really am not very
good at explaining or justifying things.  (Don't ever pick me as a
member of your debate team - I can almost guarantee you would lose
any competition in which I particpate!)



    [pgoyette-compat]src/doc/TODO.compat-module

The only thing that's holding me back from committing is an inability
to commmit to timely resolution of any fallout that might arise, due
to $PERSONAL_LIFE issues.  But, given that most people actually don't
use modules anyway, any delays in fixing the fallout should likely
have minimal impact.  With luck, we'll actually get this into HEAD in
time for netbsd-9 after all!  (And christos@ has encouraged me to go
ahead and commit sooner rather than later!)

So, I'm planning to commit within the next two weeks (around the 27th
or 28th of January).  Until then, I'll respond to comments/reviews as
best as I can.


+------------------+--------------------------+----------------------------+

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





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

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


Home | Main Index | Thread Index | Old Index