At the request of reviewers, I have removed the "alias names" stuff,
and I've re-written the description of the .o --> .a change. Here's
the revised request-for-review.
(I was going to just abandon this effort/branch, but the rest of the
changes are IMHO too important to discard.)
After
There has been a recent (very recent, like within the past few hours) proposal
to add the ability to do a chdir() (or fchdir()) to posix_spawn
There are more changes than what are included here, but the rest are mostly
all just boilerplate changes to support this addition.
If anyone has any
As I expected, my attempts to respond to your comments and explain
things have made matters worse rather than better. And I'm pretty
sure that any further attempts to explain will simply confuse
things even more. So I'm not going to pursue this effort further
without some substantial
> >> * Introduction of module "aliases". In addition to its own name, a
> >>module can now provide alias names. This is useful for the
> >>monolithic compat module, which now contains the functionality of
> >>the many version-specific modules. If you load the monolithic module,
> >>
Please note that I'm not really very good at explaining things; never
have been, and likely never will be. :) I'm trying. I hope that
the following helps; more importantly I hope that I don't introduce
any additional confusion. :)
On Fri, 7 Sep 2018, matthew green wrote:
congrats getting
congrats getting this fixed up. i don't like the monolithic module
we have currently ;-)
> * Introduction of module "aliases". In addition to its own name, a
>module can now provide alias names. This is useful for the
>monolithic compat module, which now contains the functionality of
>
Folks,
After several months of work, it's now (nearly) time to merge the
pgoyette-compat branch. (Yeah, I know that many/most of you don't
"allow" modules into your environments in the first place, so none
of this really affects you at all.)
This branch includes the following major changes:
On Fri, Sep 07, 2018 at 01:18:40AM +, m...@netbsd.org wrote:
> is xen suspend resume really handled with zero notifications for the
> running kernel?
> and all this work for a feature that I hear netbsd doesn't even support?
I don't understand your question, sorry. How is the discussion about
