Re: svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

> On Sat, Jul 7, 2018 at 7:06 PM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> > >
> > > > 08.07.2018 4:38, Warner Losh wrote:
> > > >
> > > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > > > wrote:
> > > > >
> > > > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > > > >
> > > > > > One thing that was tangentially brought up is that the ability
> > > > > > to compile out-of-tree modules requires keeping the
> > kernel-headers
> > > > > > around.  So we may need to identify all the headers that a
> > module
> > > > might
> > > > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > > > would
> > > > > > be needed if, for example, we wanted to install a new Nvidia or
> > > > Virtual
> > > > > > Box module and have it work for older installed kernel
> > versions too
> > > > > > (eg, across ABI breaking changes in -current).
> > > > >
> > > > > We already have all headers in /usr/include, don't we?
> > > > >
> > > > >
> > > > > Not really. We have a subset of the kernel headers that might not
> > match
> > > > the running kernel, nor be enough to build modules.
> > > >
> > > > They should match running kernel definitely as we do not support not
> > > > syncronized kernel/world
> > > > and installworld populates /usr/include.
> > > >
> > >
> > > Nice theory. Lots and lots of people run this way. And it has worked
> > well,
> > > so long as the kernel is newer... so, no, they don't have to match.
> >
> > At some point I had an evolution of "make includes" that would work
> > without the other parts of src being present (ie, only sys) so that
> > you could update /usr/include with the kernel headers if you reved
> > your kernel sources.
> >
> > Not sure how hard this would be to reimplement, but basically skip over
> > missing parts of the src tree with a message (echo) that it could not
> > find that particular set of sources was how it worked.
> 
> 
> I really don't like this idea. It assumes The Kernel and The Includes.
+ match?

> However, that's not quite right. For people running releases, it's near
> enough, but for developers it's not. I have, in the past, installed a
> weekly kernel into /boot/kernel.$DATE and kept a constant userland. I did
> this to catch performance regressions by being able to reboot quickly
> between then. At any given time, we'd not have the right headers with this
> scheme. Certainly not good enough to compile a module against the currently
> booted kernel.

This addition is for the users, not for the developers, developers are
in there own world and far more capable of managing the complex environment
of multiple kernels and includes.  I strongly encourage
rm -rf /usr/include/ && make includes

Users typically only run the latest sys/kernel tree and this only need
to move forward with /usr/include and this works well for that.  
> 
> I've started to like the idea of keeping module sources for 3rd party
> modules /usr/local/ and using that to rebuild the module for a
> specific kernel.

I think we are all on board with that idea.

> If we were to install the kernel includes / opt*.h files
> also into /boot/$KERNEL/include somehow, then 3rd party modules could be
> rebuilt at any time and we'd always have access to the builddir files that
> matter... Something to consider... I think I read that Linux did this to
> help prevent module breakage when new kernels are used...  It may be time
> to ditch /boot/modules entirely in favor of a scheme like this.

First order to me would be to implement "kernelincludes" as a top level
target, that would populate ${DESTDIR}/some/mumble.  This would be a
fairly general use function that could be abused to implement the above.

> 
> > /usr/include is never, ever used to build the kernel (except for things
> > > like aicasm).
> >
> > Is not /usr/include really the kernel/userland interface,
> > not the kernel/kernel interface?
> >
> 
> Yea, and more. It's a bit of hodge-podge, but on the whole, that's not an
> inaccurate characterization. Especially the bit about it not being the
> intra-kernel interface.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Konstantin Belousov]

On Sat, Jul 07, 2018 at 10:46:24PM -0600, Warner Losh wrote:
> On Sat, Jul 7, 2018 at 7:06 PM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> > >
> > > > 08.07.2018 4:38, Warner Losh wrote:
> > > >
> > > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > > > wrote:
> > > > >
> > > > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > > > >
> > > > > > One thing that was tangentially brought up is that the ability
> > > > > > to compile out-of-tree modules requires keeping the
> > kernel-headers
> > > > > > around.  So we may need to identify all the headers that a
> > module
> > > > might
> > > > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > > > would
> > > > > > be needed if, for example, we wanted to install a new Nvidia or
> > > > Virtual
> > > > > > Box module and have it work for older installed kernel
> > versions too
> > > > > > (eg, across ABI breaking changes in -current).
> > > > >
> > > > > We already have all headers in /usr/include, don't we?
> > > > >
> > > > >
> > > > > Not really. We have a subset of the kernel headers that might not
> > match
> > > > the running kernel, nor be enough to build modules.
> > > >
> > > > They should match running kernel definitely as we do not support not
> > > > syncronized kernel/world
> > > > and installworld populates /usr/include.
> > > >
> > >
> > > Nice theory. Lots and lots of people run this way. And it has worked
> > well,
> > > so long as the kernel is newer... so, no, they don't have to match.
> >
> > At some point I had an evolution of "make includes" that would work
> > without the other parts of src being present (ie, only sys) so that
> > you could update /usr/include with the kernel headers if you reved
> > your kernel sources.
> >
> > Not sure how hard this would be to reimplement, but basically skip over
> > missing parts of the src tree with a message (echo) that it could not
> > find that particular set of sources was how it worked.
> 
> 
> I really don't like this idea. It assumes The Kernel and The Includes.
> However, that's not quite right. For people running releases, it's near
> enough, but for developers it's not. I have, in the past, installed a
> weekly kernel into /boot/kernel.$DATE and kept a constant userland. I did
> this to catch performance regressions by being able to reboot quickly
> between then. At any given time, we'd not have the right headers with this
> scheme. Certainly not good enough to compile a module against the currently
> booted kernel.
> 
> I've started to like the idea of keeping module sources for 3rd party
> modules /usr/local/ and using that to rebuild the module for a
> specific kernel. If we were to install the kernel includes / opt*.h files
> also into /boot/$KERNEL/include somehow, then 3rd party modules could be
> rebuilt at any time and we'd always have access to the builddir files that
> matter... Something to consider... I think I read that Linux did this to
> help prevent module breakage when new kernels are used...  It may be time
> to ditch /boot/modules entirely in favor of a scheme like this.
> 
> > /usr/include is never, ever used to build the kernel (except for things
> > > like aicasm).
> >
> > Is not /usr/include really the kernel/userland interface,
> > not the kernel/kernel interface?
> >
> 
> Yea, and more. It's a bit of hodge-podge, but on the whole, that's not an
> inaccurate characterization. Especially the bit about it not being the
> intra-kernel interface.

Building modules against /usr/include/sys mostly worked until recently,
esp. if the proper default options were empirically collected into
module' Makefile (like -DVIMAGE etc).

Now with the ck use, and the fact that ck headers are not installed,
this is impossible.  You need the full kernel sources for module build.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Warner Losh]

On Sat, Jul 7, 2018 at 7:06 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> >
> > > 08.07.2018 4:38, Warner Losh wrote:
> > >
> > > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > > wrote:
> > > >
> > > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > > >
> > > > > One thing that was tangentially brought up is that the ability
> > > > > to compile out-of-tree modules requires keeping the
> kernel-headers
> > > > > around.  So we may need to identify all the headers that a
> module
> > > might
> > > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > > would
> > > > > be needed if, for example, we wanted to install a new Nvidia or
> > > Virtual
> > > > > Box module and have it work for older installed kernel
> versions too
> > > > > (eg, across ABI breaking changes in -current).
> > > >
> > > > We already have all headers in /usr/include, don't we?
> > > >
> > > >
> > > > Not really. We have a subset of the kernel headers that might not
> match
> > > the running kernel, nor be enough to build modules.
> > >
> > > They should match running kernel definitely as we do not support not
> > > syncronized kernel/world
> > > and installworld populates /usr/include.
> > >
> >
> > Nice theory. Lots and lots of people run this way. And it has worked
> well,
> > so long as the kernel is newer... so, no, they don't have to match.
>
> At some point I had an evolution of "make includes" that would work
> without the other parts of src being present (ie, only sys) so that
> you could update /usr/include with the kernel headers if you reved
> your kernel sources.
>
> Not sure how hard this would be to reimplement, but basically skip over
> missing parts of the src tree with a message (echo) that it could not
> find that particular set of sources was how it worked.


I really don't like this idea. It assumes The Kernel and The Includes.
However, that's not quite right. For people running releases, it's near
enough, but for developers it's not. I have, in the past, installed a
weekly kernel into /boot/kernel.$DATE and kept a constant userland. I did
this to catch performance regressions by being able to reboot quickly
between then. At any given time, we'd not have the right headers with this
scheme. Certainly not good enough to compile a module against the currently
booted kernel.

I've started to like the idea of keeping module sources for 3rd party
modules /usr/local/ and using that to rebuild the module for a
specific kernel. If we were to install the kernel includes / opt*.h files
also into /boot/$KERNEL/include somehow, then 3rd party modules could be
rebuilt at any time and we'd always have access to the builddir files that
matter... Something to consider... I think I read that Linux did this to
help prevent module breakage when new kernels are used...  It may be time
to ditch /boot/modules entirely in favor of a scheme like this.

> /usr/include is never, ever used to build the kernel (except for things
> > like aicasm).
>
> Is not /usr/include really the kernel/userland interface,
> not the kernel/kernel interface?
>

Yea, and more. It's a bit of hodge-podge, but on the whole, that's not an
inaccurate characterization. Especially the bit about it not being the
intra-kernel interface.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

> On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:
> 
> > 08.07.2018 4:38, Warner Losh wrote:
> >
> > > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > > wrote:
> > >
> > > 07.07.2018 22:02, Andrew Gallatin wrote:
> > >
> > > > One thing that was tangentially brought up is that the ability
> > > > to compile out-of-tree modules requires keeping the kernel-headers
> > > > around.  So we may need to identify all the headers that a module
> > might
> > > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> > would
> > > > be needed if, for example, we wanted to install a new Nvidia or
> > Virtual
> > > > Box module and have it work for older installed kernel versions too
> > > > (eg, across ABI breaking changes in -current).
> > >
> > > We already have all headers in /usr/include, don't we?
> > >
> > >
> > > Not really. We have a subset of the kernel headers that might not match
> > the running kernel, nor be enough to build modules.
> >
> > They should match running kernel definitely as we do not support not
> > syncronized kernel/world
> > and installworld populates /usr/include.
> >
> 
> Nice theory. Lots and lots of people run this way. And it has worked well,
> so long as the kernel is newer... so, no, they don't have to match.

At some point I had an evolution of "make includes" that would work
without the other parts of src being present (ie, only sys) so that
you could update /usr/include with the kernel headers if you reved
your kernel sources.

Not sure how hard this would be to reimplement, but basically skip over
missing parts of the src tree with a message (echo) that it could not
find that particular set of sources was how it worked.

> And why a subset? Don'we support old-style kernel re-build "config; make
> > depend; make"
> > that does not require full /usr/src tree but /usr/src/sys only?
> >

Your mail agent is still mangling quoting.  Mostly when it line wraps.

> 
> /usr/include is never, ever used to build the kernel (except for things
> like aicasm).

Is not /usr/include really the kernel/userland interface,
not the kernel/kernel interface?

> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

08.07.2018 7:33, Warner Losh wrote:

> > We already have all headers in /usr/include, don't we?
> > Not really. We have a subset of the kernel headers that might not match 
> the running kernel, nor be enough to build modules.
> They should match running kernel definitely as we do not support not 
> syncronized kernel/world
> and installworld populates /usr/include.
> Nice theory. Lots and lots of people run this way. And it has worked well, so 
> long as the kernel is newer... so, no, they don't have to match.

It could work. It can also easily break things with newer kernel too, I can 
remember many cases.
/sbin/ipfw, ps, ifconfig, netstat, top, killall and some important others are 
not guaranteed to run with newer kernel.
I still run FreeBSD 4.11-STABLE inside 11.2-STABLE jail and that's why I know 
this.

> And why a subset? Don'we support old-style kernel re-build "config; make 
> depend; make"
> that does not require full /usr/src tree but /usr/src/sys only?
> /usr/include is never, ever used to build the kernel (except for things like 
> aicasm).

OO. We could still add the whole bunch of needed .h files from /usr/src/sys/ 
there.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Warner Losh]

On Sat, Jul 7, 2018, 5:40 PM Eugene Grosbein  wrote:

> 08.07.2018 4:38, Warner Losh wrote:
>
> > On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > wrote:
> >
> > 07.07.2018 22:02, Andrew Gallatin wrote:
> >
> > > One thing that was tangentially brought up is that the ability
> > > to compile out-of-tree modules requires keeping the kernel-headers
> > > around.  So we may need to identify all the headers that a module
> might
> > > need, and install them in /boot/$KERNEL/sys or some-such.  This
> would
> > > be needed if, for example, we wanted to install a new Nvidia or
> Virtual
> > > Box module and have it work for older installed kernel versions too
> > > (eg, across ABI breaking changes in -current).
> >
> > We already have all headers in /usr/include, don't we?
> >
> >
> > Not really. We have a subset of the kernel headers that might not match
> the running kernel, nor be enough to build modules.
>
> They should match running kernel definitely as we do not support not
> syncronized kernel/world
> and installworld populates /usr/include.
>

Nice theory. Lots and lots of people run this way. And it has worked well,
so long as the kernel is newer... so, no, they don't have to match.


And why a subset? Don'we support old-style kernel re-build "config; make
> depend; make"
> that does not require full /usr/src tree but /usr/src/sys only?
>

/usr/include is never, ever used to build the kernel (except for things
like aicasm).

Warner


>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

08.07.2018 4:38, Warner Losh wrote:

> On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  > wrote:
> 
> 07.07.2018 22:02, Andrew Gallatin wrote:
> 
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around.  So we may need to identify all the headers that a module might
> > need, and install them in /boot/$KERNEL/sys or some-such.  This would
> > be needed if, for example, we wanted to install a new Nvidia or Virtual
> > Box module and have it work for older installed kernel versions too
> > (eg, across ABI breaking changes in -current).
> 
> We already have all headers in /usr/include, don't we?
> 
> 
> Not really. We have a subset of the kernel headers that might not match the 
> running kernel, nor be enough to build modules. 

They should match running kernel definitely as we do not support not 
syncronized kernel/world
and installworld populates /usr/include.

And why a subset? Don'we support old-style kernel re-build "config; make 
depend; make"
that does not require full /usr/src tree but /usr/src/sys only?


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Warner Losh]

On Sat, Jul 7, 2018, 4:14 PM Eugene Grosbein  wrote:

> 07.07.2018 22:02, Andrew Gallatin wrote:
>
> > One thing that was tangentially brought up is that the ability
> > to compile out-of-tree modules requires keeping the kernel-headers
> > around.  So we may need to identify all the headers that a module might
> > need, and install them in /boot/$KERNEL/sys or some-such.  This would
> > be needed if, for example, we wanted to install a new Nvidia or Virtual
> > Box module and have it work for older installed kernel versions too
> > (eg, across ABI breaking changes in -current).
>
> We already have all headers in /usr/include, don't we?
>

Not really. We have a subset of the kernel headers that might not match the
running kernel, nor be enough to build modules.

Warner

>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

07.07.2018 22:02, Andrew Gallatin wrote:

> One thing that was tangentially brought up is that the ability
> to compile out-of-tree modules requires keeping the kernel-headers
> around.  So we may need to identify all the headers that a module might
> need, and install them in /boot/$KERNEL/sys or some-such.  This would
> be needed if, for example, we wanted to install a new Nvidia or Virtual
> Box module and have it work for older installed kernel versions too
> (eg, across ABI breaking changes in -current).

We already have all headers in /usr/include, don't we?

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Andrew Gallatin]

On 07/05/18 19:59, John Baldwin wrote:


You misunderstand.  /usr/local/sys/modules would hold module sources so that
they can be recompiled when building a kernel without having to rebuild the
package or reinstall the package.  Binary modules would continue to be
installed in /boot/modules.



This is very similar to the approach that many Linux distributions take
with DKMS.  The kernel sources for out-of-tree modules are kept around,
and every time a kernel is installed, its new header files are used to
re-compile the out-of-tree module.   Similarly, when you install a
package containing a kernel module, it is re-compiled and installed
for every installed kernel.

One thing that was tangentially brought up is that the ability
to compile out-of-tree modules requires keeping the kernel-headers
around.  So we may need to identify all the headers that a module might
need, and install them in /boot/$KERNEL/sys or some-such.  This would
be needed if, for example, we wanted to install a new Nvidia or Virtual
Box module and have it work for older installed kernel versions too
(eg, across ABI breaking changes in -current).

This would certainly make life easier for people running -current.
This system works quite well on Linux.  For comparison, I used an
Ubuntu based desktop with Nvidia graphics at a previous employers,
and a FreeBSD-current desktop w/Nvidia graphics now. I've been left w/o
graphics  accidentally much more often on FreeBSD than I ever
had been on Ubuntu, even when compiling my own kernels from git..

Drew
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On 7/5/18 5:13 PM, Eugene Grosbein wrote:
> > 06.07.2018 6:59, John Baldwin wrote:
> > 
> >>> I'm not sure I understand the topic quite right, but please do not drop
> >>> MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
> >>> in case of slight changes of its config file not changing ABI and/or
> >>> similar source changes without HUGE modules compilation overhead.
> >>
> >> This would not drop it, but it would mean that you can't necessarily 
> >> kldload
> >> /boot/kernel.GENERIC/foo.ko while running some other kernel.
> > 
> > And what's profit of such restriction? There were several cases
> > when I was forced to extract somemodule.ko from FreeBSD distribution files
> > and upload it to some customized installation such as FreeNAS or NAS4Free
> > or another one running custom kernel and having stripped-down module set 
> > out-of-the-box.
> > For example, ichwd.ko or something like that. And I was just happy I could 
> > do that and
> > that just work. Why should we break it?
> 
> You would still do that by 'cd /sys/modules/foo; make; scp foo.ko somebox:'
> 
> The profit of the restriction is performance.  Making kernel modules
> generic makes them slower by forcing them to indirect certain lightweight
> operations through function calls that the kernel itself performs inline
> (and "tied" modules would inline these same things).

I build custom kernels with the modules compiled in if I want performant
systems.  I remove all the stuff I do not need or want in GENERIC for the
same reason.

Trying to make loaded kernel modules performant by placing near static linked
kernel restrictions on them is not a direction I feel worth heading into as
it breaks just too many other use cases.

> The other benefit is
> that providing a convenient way to recompile modules from ports would 
> alleviate
> KBI breakage for ports such as nvidia-graphics and virtualbox-ose-kmod
> that can break since they use parts of the kernel for which we do not
> guarantee KBI stability.

Isnt that a totally seperate issue to this MODULE_TIED?

> John Baldwin
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

> On 7/5/18 4:17 PM, Eugene Grosbein wrote:
> > 06.07.2018 1:21, John Baldwin wrote:
> > 
> >> Yes, this is a change though I find it the logical outcome of the original 
> >> change
> >> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
> >> intended to use MODULE_TIED in a few places, but I think tagging all those
> >> places will be cumbersome and tedious compared to just doing it in this 
> >> way.  I
> >> think this will also tie into something I proposed earlier in a commit 
> >> reply and
> >> that I also brought up at BSDCan which is that I think that kernel modules 
> >> in
> >> ports should install their sources and build glue to some location we 
> >> choose
> >> (e.g. /usr/local/sys/modules/) and that we should support a variable 
> >> folks
> >> can set in their kernel config file similar to MODULES_OVERRIDE that is a 
> >> list
> >> of local modules to recompile and install into /boot/kernel along with 
> >> other
> >> modules (and that these recompiled modules would be TIED).  The binary 
> >> module
> >> from the package would still be present in /boot/modules, but the tied 
> >> module
> >> in /boot/kernel would be preferred and used instead when it exists (our 
> >> existing
> >> module_path already does this last part).  This would replace the existing
> >> PORTS_MODULES but in a way that is more graceful and works with packages, 
> >> not
> >> just ports IMO.
> > 
> > I'm not sure I understand the topic quite right, but please do not drop
> > MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
> > in case of slight changes of its config file not changing ABI and/or
> > similar source changes without HUGE modules compilation overhead.
> 
> This would not drop it, but it would mean that you can't necessarily kldload
> /boot/kernel.GENERIC/foo.ko while running some other kernel.

Please do not break that!   If any module should continue to load with a
custom kernel it should be the ones built with GENERIC, as long as the
source code/KABI is unchanged why am I not being allowed to load this module?

> > Also, we should not use /usr/local/sys/modules/ as /usr/local
> > can be inaccessible for the loader. Better use /boot/modules/local or 
> > /boot/local
> > as /boot is guaranteed to be accessible.
> 
> You misunderstand.  /usr/local/sys/modules would hold module sources so that
> they can be recompiled when building a kernel without having to rebuild the
> package or reinstall the package.  Binary modules would continue to be
> installed in /boot/modules.

I like this part of it, as we discussed at BSDCan, this would in effect
fix the VirtualBox, kmod-next, and nvidia module issues we currently
face in stable/11.

> John Baldwin
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

06.07.2018 7:20, John Baldwin wrote:

>> And what's profit of such restriction? There were several cases
>> when I was forced to extract somemodule.ko from FreeBSD distribution files
>> and upload it to some customized installation such as FreeNAS or NAS4Free
>> or another one running custom kernel and having stripped-down module set 
>> out-of-the-box.
>> For example, ichwd.ko or something like that. And I was just happy I could 
>> do that and
>> that just work. Why should we break it?
> 
> You would still do that by 'cd /sys/modules/foo; make; scp foo.ko somebox:'

May I suggest that release installation media would provide two copies of 
modules/
directory for one major release, one with tied modules for performance
and another set (not installed by default) with "un-tied" for reference?

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

06.07.2018 7:20, John Baldwin wrote:

>>> This would not drop it, but it would mean that you can't necessarily kldload
>>> /boot/kernel.GENERIC/foo.ko while running some other kernel.
>>
>> And what's profit of such restriction? There were several cases
>> when I was forced to extract somemodule.ko from FreeBSD distribution files
>> and upload it to some customized installation such as FreeNAS or NAS4Free
>> or another one running custom kernel and having stripped-down module set 
>> out-of-the-box.
>> For example, ichwd.ko or something like that. And I was just happy I could 
>> do that and
>> that just work. Why should we break it?
> 
> You would still do that by 'cd /sys/modules/foo; make; scp foo.ko somebox:'

Yes, provided I have a buildbox handy.

> The profit of the restriction is performance.  Making kernel modules
> generic makes them slower by forcing them to indirect certain lightweight
> operations through function calls that the kernel itself performs inline
> (and "tied" modules would inline these same things).  The other benefit is
> that providing a convenient way to recompile modules from ports would 
> alleviate
> KBI breakage for ports such as nvidia-graphics and virtualbox-ose-kmod
> that can break since they use parts of the kernel for which we do not
> guarantee KBI stability.

Thanks, now I got it.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/5/18 5:13 PM, Eugene Grosbein wrote:
> 06.07.2018 6:59, John Baldwin wrote:
> 
>>> I'm not sure I understand the topic quite right, but please do not drop
>>> MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
>>> in case of slight changes of its config file not changing ABI and/or
>>> similar source changes without HUGE modules compilation overhead.
>>
>> This would not drop it, but it would mean that you can't necessarily kldload
>> /boot/kernel.GENERIC/foo.ko while running some other kernel.
> 
> And what's profit of such restriction? There were several cases
> when I was forced to extract somemodule.ko from FreeBSD distribution files
> and upload it to some customized installation such as FreeNAS or NAS4Free
> or another one running custom kernel and having stripped-down module set 
> out-of-the-box.
> For example, ichwd.ko or something like that. And I was just happy I could do 
> that and
> that just work. Why should we break it?

You would still do that by 'cd /sys/modules/foo; make; scp foo.ko somebox:'

The profit of the restriction is performance.  Making kernel modules
generic makes them slower by forcing them to indirect certain lightweight
operations through function calls that the kernel itself performs inline
(and "tied" modules would inline these same things).  The other benefit is
that providing a convenient way to recompile modules from ports would alleviate
KBI breakage for ports such as nvidia-graphics and virtualbox-ose-kmod
that can break since they use parts of the kernel for which we do not
guarantee KBI stability.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

06.07.2018 6:59, John Baldwin wrote:

>> I'm not sure I understand the topic quite right, but please do not drop
>> MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
>> in case of slight changes of its config file not changing ABI and/or
>> similar source changes without HUGE modules compilation overhead.
> 
> This would not drop it, but it would mean that you can't necessarily kldload
> /boot/kernel.GENERIC/foo.ko while running some other kernel.

And what's profit of such restriction? There were several cases
when I was forced to extract somemodule.ko from FreeBSD distribution files
and upload it to some customized installation such as FreeNAS or NAS4Free
or another one running custom kernel and having stripped-down module set 
out-of-the-box.
For example, ichwd.ko or something like that. And I was just happy I could do 
that and
that just work. Why should we break it?

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/5/18 4:17 PM, Eugene Grosbein wrote:
> 06.07.2018 1:21, John Baldwin wrote:
> 
>> Yes, this is a change though I find it the logical outcome of the original 
>> change
>> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
>> intended to use MODULE_TIED in a few places, but I think tagging all those
>> places will be cumbersome and tedious compared to just doing it in this way. 
>>  I
>> think this will also tie into something I proposed earlier in a commit reply 
>> and
>> that I also brought up at BSDCan which is that I think that kernel modules in
>> ports should install their sources and build glue to some location we choose
>> (e.g. /usr/local/sys/modules/) and that we should support a variable 
>> folks
>> can set in their kernel config file similar to MODULES_OVERRIDE that is a 
>> list
>> of local modules to recompile and install into /boot/kernel along with other
>> modules (and that these recompiled modules would be TIED).  The binary module
>> from the package would still be present in /boot/modules, but the tied module
>> in /boot/kernel would be preferred and used instead when it exists (our 
>> existing
>> module_path already does this last part).  This would replace the existing
>> PORTS_MODULES but in a way that is more graceful and works with packages, not
>> just ports IMO.
> 
> I'm not sure I understand the topic quite right, but please do not drop
> MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
> in case of slight changes of its config file not changing ABI and/or
> similar source changes without HUGE modules compilation overhead.

This would not drop it, but it would mean that you can't necessarily kldload
/boot/kernel.GENERIC/foo.ko while running some other kernel.

> Also, we should not use /usr/local/sys/modules/ as /usr/local
> can be inaccessible for the loader. Better use /boot/modules/local or 
> /boot/local
> as /boot is guaranteed to be accessible.

You misunderstand.  /usr/local/sys/modules would hold module sources so that
they can be recompiled when building a kernel without having to rebuild the
package or reinstall the package.  Binary modules would continue to be
installed in /boot/modules.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

06.07.2018 1:21, John Baldwin wrote:

> Yes, this is a change though I find it the logical outcome of the original 
> change
> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
> intended to use MODULE_TIED in a few places, but I think tagging all those
> places will be cumbersome and tedious compared to just doing it in this way.  
> I
> think this will also tie into something I proposed earlier in a commit reply 
> and
> that I also brought up at BSDCan which is that I think that kernel modules in
> ports should install their sources and build glue to some location we choose
> (e.g. /usr/local/sys/modules/) and that we should support a variable 
> folks
> can set in their kernel config file similar to MODULES_OVERRIDE that is a list
> of local modules to recompile and install into /boot/kernel along with other
> modules (and that these recompiled modules would be TIED).  The binary module
> from the package would still be present in /boot/modules, but the tied module
> in /boot/kernel would be preferred and used instead when it exists (our 
> existing
> module_path already does this last part).  This would replace the existing
> PORTS_MODULES but in a way that is more graceful and works with packages, not
> just ports IMO.

I'm not sure I understand the topic quite right, but please do not drop
MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
in case of slight changes of its config file not changing ABI and/or
similar source changes without HUGE modules compilation overhead.

Also, we should not use /usr/local/sys/modules/ as /usr/local
can be inaccessible for the loader. Better use /boot/modules/local or 
/boot/local
as /boot is guaranteed to be accessible.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/5/18 11:39 AM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 11:21:28AM -0700, John Baldwin wrote:
>> On 7/5/18 8:54 AM, Konstantin Belousov wrote:
>>> On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
 On 7/4/18 7:22 AM, Konstantin Belousov wrote:
> On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue Jul  3 23:05:42 2018
>> New Revision: 335916
>> URL: https://svnweb.freebsd.org/changeset/base/335916
>>
>> Log:
>>   Enable MODULE_TIED by default for modules compiled with the kernel
> But why ?

 I think we should enable KLD_TIED to inline critical_* etc. for modules
 built as part of a kernel that are installed alongside the kernel in 
 /boot/.
>>>
 I don't think we need to support modules built with kernel A loaded into 
 kernel B.

>>> This is the crusial point.  I do not object, but this this is a radical
>>> change from the previous mode of modules build.
>>>
>>> I do not want to put words in other person mouth, but I beliee that the
>>> original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
>>> specific modules were to be tied.
>>
>> Yes, this is a change though I find it the logical outcome of the original 
>> change
>> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
>> intended to use MODULE_TIED in a few places, but I think tagging all those
>> places will be cumbersome and tedious compared to just doing it in this way. 
>>  I
>> think this will also tie into something I proposed earlier in a commit reply 
>> and
>> that I also brought up at BSDCan which is that I think that kernel modules in
>> ports should install their sources and build glue to some location we choose
>> (e.g. /usr/local/sys/modules/) and that we should support a variable 
>> folks
>> can set in their kernel config file similar to MODULES_OVERRIDE that is a 
>> list
>> of local modules to recompile and install into /boot/kernel along with other
>> modules (and that these recompiled modules would be TIED).  The binary module
>> from the package would still be present in /boot/modules, but the tied module
>> in /boot/kernel would be preferred and used instead when it exists (our 
>> existing
>> module_path already does this last part).  This would replace the existing
>> PORTS_MODULES but in a way that is more graceful and works with packages, not
>> just ports IMO.
>>
> 
> I probably need to say more explicit why this change made me surprised,
> and the surprise is fueled even more by your proposal.  It basically
> means that we do not need stable KBI, and detecting KBI breakage in such
> setup is practically impossible.  Most consumers would be recompiled,
> except the modules used in very specific scenario:  inter-release updates
> with the modules used from the portmgr-provided packages while packages
> are still built against the older release.
> 
> Again, I do not object against the proposed new world order, I do not
> believe that KBI stability gives positive value comparing with the burden
> and restrictions it puts on the liveness of the stable branches.
> 
> But I do believe that the migration to such new attitude to the kernel
> interfaces would benefit from the discussion.

I am not quite saying to abolish KBI as I don't think we need to ban the
ability to build standalone modules.  I just think that modules built with
a kernel should be tied to that kernel.  In particular as there is a push to
move from GENERIC towards MINIMAL, where more things like drivers are pulled
from modules instead of the base kernel file, there is a need for modules
built with the kernel to be less pessimized.  It is actually that factor more
than others that makes me want to tie modules built with a kernel to the
kernel.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Konstantin Belousov]

On Thu, Jul 05, 2018 at 11:21:28AM -0700, John Baldwin wrote:
> On 7/5/18 8:54 AM, Konstantin Belousov wrote:
> > On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
> >> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
> >>> On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
>  Author: mmacy
>  Date: Tue Jul  3 23:05:42 2018
>  New Revision: 335916
>  URL: https://svnweb.freebsd.org/changeset/base/335916
> 
>  Log:
>    Enable MODULE_TIED by default for modules compiled with the kernel
> >>> But why ?
> >>
> >> I think we should enable KLD_TIED to inline critical_* etc. for modules
> >> built as part of a kernel that are installed alongside the kernel in 
> >> /boot/.
> > 
> >> I don't think we need to support modules built with kernel A loaded into 
> >> kernel B.
> >>
> > This is the crusial point.  I do not object, but this this is a radical
> > change from the previous mode of modules build.
> > 
> > I do not want to put words in other person mouth, but I beliee that the
> > original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
> > specific modules were to be tied.
> 
> Yes, this is a change though I find it the logical outcome of the original 
> change
> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
> intended to use MODULE_TIED in a few places, but I think tagging all those
> places will be cumbersome and tedious compared to just doing it in this way.  
> I
> think this will also tie into something I proposed earlier in a commit reply 
> and
> that I also brought up at BSDCan which is that I think that kernel modules in
> ports should install their sources and build glue to some location we choose
> (e.g. /usr/local/sys/modules/) and that we should support a variable 
> folks
> can set in their kernel config file similar to MODULES_OVERRIDE that is a list
> of local modules to recompile and install into /boot/kernel along with other
> modules (and that these recompiled modules would be TIED).  The binary module
> from the package would still be present in /boot/modules, but the tied module
> in /boot/kernel would be preferred and used instead when it exists (our 
> existing
> module_path already does this last part).  This would replace the existing
> PORTS_MODULES but in a way that is more graceful and works with packages, not
> just ports IMO.
> 

I probably need to say more explicit why this change made me surprised,
and the surprise is fueled even more by your proposal.  It basically
means that we do not need stable KBI, and detecting KBI breakage in such
setup is practically impossible.  Most consumers would be recompiled,
except the modules used in very specific scenario:  inter-release updates
with the modules used from the portmgr-provided packages while packages
are still built against the older release.

Again, I do not object against the proposed new world order, I do not
believe that KBI stability gives positive value comparing with the burden
and restrictions it puts on the liveness of the stable branches.

But I do believe that the migration to such new attitude to the kernel
interfaces would benefit from the discussion.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/5/18 8:54 AM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
>> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
>>> On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
 Author: mmacy
 Date: Tue Jul  3 23:05:42 2018
 New Revision: 335916
 URL: https://svnweb.freebsd.org/changeset/base/335916

 Log:
   Enable MODULE_TIED by default for modules compiled with the kernel
>>> But why ?
>>
>> I think we should enable KLD_TIED to inline critical_* etc. for modules
>> built as part of a kernel that are installed alongside the kernel in 
>> /boot/.
> 
>> I don't think we need to support modules built with kernel A loaded into 
>> kernel B.
>>
> This is the crusial point.  I do not object, but this this is a radical
> change from the previous mode of modules build.
> 
> I do not want to put words in other person mouth, but I beliee that the
> original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
> specific modules were to be tied.

Yes, this is a change though I find it the logical outcome of the original 
change
to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
intended to use MODULE_TIED in a few places, but I think tagging all those
places will be cumbersome and tedious compared to just doing it in this way.  I
think this will also tie into something I proposed earlier in a commit reply and
that I also brought up at BSDCan which is that I think that kernel modules in
ports should install their sources and build glue to some location we choose
(e.g. /usr/local/sys/modules/) and that we should support a variable folks
can set in their kernel config file similar to MODULES_OVERRIDE that is a list
of local modules to recompile and install into /boot/kernel along with other
modules (and that these recompiled modules would be TIED).  The binary module
from the package would still be present in /boot/modules, but the tied module
in /boot/kernel would be preferred and used instead when it exists (our existing
module_path already does this last part).  This would replace the existing
PORTS_MODULES but in a way that is more graceful and works with packages, not
just ports IMO.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Matthew Macy]

On Thu, Jul 5, 2018 at 8:54 AM, Konstantin Belousov  wrote:
> On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
>> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
>> > On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
>> >> Author: mmacy
>> >> Date: Tue Jul  3 23:05:42 2018
>> >> New Revision: 335916
>> >> URL: https://svnweb.freebsd.org/changeset/base/335916
>> >>
>> >> Log:
>> >>   Enable MODULE_TIED by default for modules compiled with the kernel
>> > But why ?
>>
>> I think we should enable KLD_TIED to inline critical_* etc. for modules
>> built as part of a kernel that are installed alongside the kernel in 
>> /boot/.
>
>> I don't think we need to support modules built with kernel A loaded into 
>> kernel B.
>>
> This is the crusial point.  I do not object, but this this is a radical
> change from the previous mode of modules build.
>
> I do not want to put words in other person mouth, but I beliee that the
> original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
> specific modules were to be tied.


My intention was only to allow it for select modules compiled _with_
the kernel. Then there was a heated discussion about documentation and
how to communicate it's distinction with DECLARE_MODULE_TIED. In
response to which John said (assuming I understood correctly,
communication is hard) that it should be the default and specified
doing it the way I did it. That seemed reasonable - but I don't have
strong feelings one way or the other. I apologize if I misunderstood
any guidance I was provided.

-M
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Konstantin Belousov]

On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
> > On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
> >> Author: mmacy
> >> Date: Tue Jul  3 23:05:42 2018
> >> New Revision: 335916
> >> URL: https://svnweb.freebsd.org/changeset/base/335916
> >>
> >> Log:
> >>   Enable MODULE_TIED by default for modules compiled with the kernel
> > But why ?
> 
> I think we should enable KLD_TIED to inline critical_* etc. for modules
> built as part of a kernel that are installed alongside the kernel in 
> /boot/.

> I don't think we need to support modules built with kernel A loaded into 
> kernel B.
> 
This is the crusial point.  I do not object, but this this is a radical
change from the previous mode of modules build.

I do not want to put words in other person mouth, but I beliee that the
original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
specific modules were to be tied.

> I think we should not enable it for "standalone" module builds done in ports 
> or via
> "cd /sys/modules/foo; make" that install to /boot/modules so that those 
> modules can
> work with different kernels.  This still permits someone to load a module 
> into kernel
> A that they had disabled in kernel A's config file (via NO_MODULES or 
> MODULES_OVERRIDE
> or some such) by doing 'cd /sys/modules/foo; make; make load'.
> 
> -- 
> John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/4/18 7:22 AM, Konstantin Belousov wrote:
> On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue Jul  3 23:05:42 2018
>> New Revision: 335916
>> URL: https://svnweb.freebsd.org/changeset/base/335916
>>
>> Log:
>>   Enable MODULE_TIED by default for modules compiled with the kernel
> But why ?

I think we should enable KLD_TIED to inline critical_* etc. for modules
built as part of a kernel that are installed alongside the kernel in 
/boot/.
I don't think we need to support modules built with kernel A loaded into kernel 
B.

I think we should not enable it for "standalone" module builds done in ports or 
via
"cd /sys/modules/foo; make" that install to /boot/modules so that those modules 
can
work with different kernels.  This still permits someone to load a module into 
kernel
A that they had disabled in kernel A's config file (via NO_MODULES or 
MODULES_OVERRIDE
or some such) by doing 'cd /sys/modules/foo; make; make load'.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Konstantin Belousov]

On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
> Author: mmacy
> Date: Tue Jul  3 23:05:42 2018
> New Revision: 335916
> URL: https://svnweb.freebsd.org/changeset/base/335916
> 
> Log:
>   Enable MODULE_TIED by default for modules compiled with the kernel
But why ?

>   
>   Requested by: jhb
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Matthew Macy]

I didn't want it to be global. Note that I did _exactly_ what John told me
to. I don't believe the tone or word choice is justified.

-M

On Tue, Jul 3, 2018 at 17:32 Warner Losh  wrote:

> And this is why I wanted it to conform to the current build paradigm in my
> review... I'll mop it up once Bryan is done...
>
> Warner
>
> On Tue, Jul 3, 2018, 6:05 PM Matt Macy  wrote:
>
>> Author: mmacy
>> Date: Tue Jul  3 23:05:42 2018
>> New Revision: 335916
>> URL: https://svnweb.freebsd.org/changeset/base/335916
>>
>> Log:
>>   Enable MODULE_TIED by default for modules compiled with the kernel
>>
>>   Requested by: jhb
>>
>> Modified:
>>   head/sys/conf/kern.post.mk
>>
>> Modified: head/sys/conf/kern.post.mk
>>
>> ==
>> --- head/sys/conf/kern.post.mk  Tue Jul  3 22:54:46 2018(r335915)
>> +++ head/sys/conf/kern.post.mk  Tue Jul  3 23:05:42 2018(r335916)
>> @@ -14,6 +14,7 @@ MKMODULESENV+=DESTDIR="${DESTDIR}"
>>  .endif
>>  SYSDIR?= ${S:C;^[^/];${.CURDIR}/&;:tA}
>>  MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}"
>> +MKMODULESENV+=  MODULE_TIED=yes
>>
>>  .if defined(CONF_CFLAGS)
>>  MKMODULESENV+= CONF_CFLAGS="${CONF_CFLAGS}"
>>
>>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335916 - head/sys/conf

[Warner Losh]

And this is why I wanted it to conform to the current build paradigm in my
review... I'll mop it up once Bryan is done...

Warner

On Tue, Jul 3, 2018, 6:05 PM Matt Macy  wrote:

> Author: mmacy
> Date: Tue Jul  3 23:05:42 2018
> New Revision: 335916
> URL: https://svnweb.freebsd.org/changeset/base/335916
>
> Log:
>   Enable MODULE_TIED by default for modules compiled with the kernel
>
>   Requested by: jhb
>
> Modified:
>   head/sys/conf/kern.post.mk
>
> Modified: head/sys/conf/kern.post.mk
>
> ==
> --- head/sys/conf/kern.post.mk  Tue Jul  3 22:54:46 2018(r335915)
> +++ head/sys/conf/kern.post.mk  Tue Jul  3 23:05:42 2018(r335916)
> @@ -14,6 +14,7 @@ MKMODULESENV+=DESTDIR="${DESTDIR}"
>  .endif
>  SYSDIR?= ${S:C;^[^/];${.CURDIR}/&;:tA}
>  MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}"
> +MKMODULESENV+=  MODULE_TIED=yes
>
>  .if defined(CONF_CFLAGS)
>  MKMODULESENV+= CONF_CFLAGS="${CONF_CFLAGS}"
>
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r335916 - head/sys/conf

[Matt Macy]

Author: mmacy
Date: Tue Jul  3 23:05:42 2018
New Revision: 335916
URL: https://svnweb.freebsd.org/changeset/base/335916

Log:
  Enable MODULE_TIED by default for modules compiled with the kernel
  
  Requested by: jhb

Modified:
  head/sys/conf/kern.post.mk

Modified: head/sys/conf/kern.post.mk
==
--- head/sys/conf/kern.post.mk  Tue Jul  3 22:54:46 2018(r335915)
+++ head/sys/conf/kern.post.mk  Tue Jul  3 23:05:42 2018(r335916)
@@ -14,6 +14,7 @@ MKMODULESENV+=DESTDIR="${DESTDIR}"
 .endif
 SYSDIR?= ${S:C;^[^/];${.CURDIR}/&;:tA}
 MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" SYSDIR="${SYSDIR}"
+MKMODULESENV+=  MODULE_TIED=yes
 
 .if defined(CONF_CFLAGS)
 MKMODULESENV+= CONF_CFLAGS="${CONF_CFLAGS}"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"