Date: Thu, 19 Jan 2017 17:36:38 -0500 (EST)
From: Mouse
> please consider lukem's proposal from a large number of years ago
> where the kernel + modules are considered a unit and are stored
> together (in a tarball? in a subdir? details..)
To put on my iconoclast hat for a mo
On Fri, 20 Jan 2017, matthew green wrote:
The 'tarball' variant has other problems, such as "how does the kernel
extract a module from the tarball to facilitate auto-load?" Last time
I looked, there was no kernel version of tar or pax. :) IMHO, Loss of
the autoload capability would severely r
> The 'tarball' variant has other problems, such as "how does the kernel
> extract a module from the tarball to facilitate auto-load?" Last time
> I looked, there was no kernel version of tar or pax. :) IMHO, Loss of
> the autoload capability would severely reduce the useability of modules.
the
On Thu, 19 Jan 2017, Mouse wrote:
please consider lukem's proposal from a large number of years ago
where the kernel + modules are considered a unit and are stored
together (in a tarball? in a subdir? details..)
To put on my iconoclast hat for a moment, how does this differ from a
non-modula
On Fri, 20 Jan 2017, matthew green wrote:
please consider lukem's proposal from a large number of years
ago where the kernel + modules are considered a unit and are
stored together (in a tarball? in a subdir? details..)
doing it like this enables all sorts of useful things to be
done besides
> please consider lukem's proposal from a large number of years ago
> where the kernel + modules are considered a unit and are stored
> together (in a tarball? in a subdir? details..)
To put on my iconoclast hat for a moment, how does this differ from a
non-modular kernel, inherently bound to al
please consider lukem's proposal from a large number of years
ago where the kernel + modules are considered a unit and are
stored together (in a tarball? in a subdir? details..)
doing it like this enables all sorts of useful things to be
done besides testing kernel+modules.
.mrg.
On Jan 19, 1:39pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: Fixed modular kernel path and different kernels
| OK, I looked into this a bit more.
|
| Doing the 'prompt for module path' thing is non-trivial, at least for
| someone who is totally unfamiliar with the boot
Re: Fixed modular kernel path and different kernels
|
| Well, yes, that's what I said above regarding modules "pushed from the
| boot loader." :-)
|
| It seems to me that we have a similar restriction on where the boot
| loader locates the /boot.cfg file. It currently comes from
On Wed, 18 Jan 2017, Christos Zoulas wrote:
On Jan 19, 6:48am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: Fixed modular kernel path and different kernels
|
| Well, yes, that's what I said above regarding modules "pushed from the
| boot loader." :-)
|
| It seem
On Jan 19, 6:48am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: Fixed modular kernel path and different kernels
|
| Well, yes, that's what I said above regarding modules "pushed from the
| boot loader." :-)
|
| It seems to me that we have a similar restriction on
On Wed, 18 Jan 2017, Christos Zoulas wrote:
In article ,
Paul Goyette wrote:
-=-=-=-=-=-
On Wed, 18 Jan 2017, Paul Goyette wrote:
One obvious and trivial way to allow for testing like this is to have
boot -a also ask for an override of the module path.
This should not be too difficult, a
In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>On Wed, 18 Jan 2017, Paul Goyette wrote:
>
>>> One obvious and trivial way to allow for testing like this is to have
>>> boot -a also ask for an override of the module path.
>>
>> This should not be too difficult, although it would (continue to) ha
On Wed, 18 Jan 2017, Paul Goyette wrote:
One obvious and trivial way to allow for testing like this is to have
boot -a also ask for an override of the module path.
This should not be too difficult, although it would (continue to) have the
restriction that modules "pushed" from the boot loader
One obvious and trivial way to allow for testing like this is to have
boot -a also ask for an override of the module path.
This should not be too difficult, although it would (continue to) have
the restriction that modules "pushed" from the boot loader (those which
are loaded via /boot.conf as
One obvious and trivial way to allow for testing like this is to have
boot -a also ask for an override of the module path.
Once that is there, also provide the override via userconf or /boot.cfg.
Martin
I've added this issue to the list, in src/doc/TODO.modules
It's not the first time it has been discussed.
On Sat, 14 Jan 2017, David Holland wrote:
On Sat, Jan 14, 2017 at 04:53:50PM +0100, Thomas Klausner wrote:
> Perhaps there are other, even better solutions. My point is, we should
> switc
On Sat, Jan 14, 2017 at 04:53:50PM +0100, Thomas Klausner wrote:
> Perhaps there are other, even better solutions. My point is, we should
> switch away from our current method.
>
> Am I overlooking something?
No.
It's the way it is because, mostly, of strident dogmatic insistence on
the part
Hi!
One issue that made me avoid modular kernels is that updating is
finickier.
When you switch from one modular kernel to another, you have to
replace /netbsd and /stamd/amd64/${VERSION}/modules.
So for example, when testing two different kernels of the same
-current major version, you can not
19 matches
Mail list logo
