On Friday, October 09, 2015 07:59:06 PM Edward Tomasz Napierała wrote:
> On 0917T1630, John Baldwin wrote:
> > On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote:
> > >
> > > > On 17 Sep 2015, at 20:43 , John Baldwin wrote:
> > > >
> > > > On Thursday, September 17, 2015 08:36:47 P
On 0917T1630, John Baldwin wrote:
> On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote:
> >
> > > On 17 Sep 2015, at 20:43 , John Baldwin wrote:
> > >
> > > On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:
> > >> Author: jhb
> > >> Date: Thu Sep 17 20:36:46 2015
> >
On Fri, 2015-10-02 at 12:10 -0700, Adrian Chadd wrote:
> On 2 October 2015 at 11:04, Rui Paulo wrote:
> > On Thu, 2015-09-24 at 08:29 -0700, Adrian Chadd wrote:
> > > ... I'm confused about the "load it by hand" stuff in net80211.
> > > Why
> > > don't we just do the kldload at that point?
> > >
On 2 October 2015 at 11:04, Rui Paulo wrote:
> On Thu, 2015-09-24 at 08:29 -0700, Adrian Chadd wrote:
>> ... I'm confused about the "load it by hand" stuff in net80211. Why
>> don't we just do the kldload at that point?
>>
>
> I was talking about ieee80211_load_module. net80211 module auto
> load
On Thu, 2015-09-24 at 08:29 -0700, Adrian Chadd wrote:
> ... I'm confused about the "load it by hand" stuff in net80211. Why
> don't we just do the kldload at that point?
>
I was talking about ieee80211_load_module. net80211 module auto
loading doesn't work probably because kern_kldload() can't
That's the idea... When we load an 802.11 driver we'd need to then load
the other associated modules. The key is, which ones and how do the
special needs crowd do things other than the default.
Warner
On Thu, Sep 24, 2015 at 8:29 AM, Adrian Chadd
wrote:
> ... I'm confused about the "load it by
>
> The other approach I suggested earlier is to make the kernel relocatable
> (and allow the module metadata to be anywhere and live in a chain instead
> of an array) so that we can just load things wherever and leave them there
> without having to relocate.
For ia64 I linked the kernel against
... I'm confused about the "load it by hand" stuff in net80211. Why
don't we just do the kldload at that point?
-a
On 23 September 2015 at 21:06, Warner Losh wrote:
> You're right about the Wifi drivers. There's some number you'll want loaded
> and we should have sensible defaults. But how to
You're right about the Wifi drivers. There's some number you'll want loaded
and we should have sensible defaults. But how to get there from here may
be a bit interesting... Though if I go with the devd.conf writer early in
boot,
I can make them be rc.conf variable controlled.
Warner
On Wed, Sep
Those were the issues that I encountered when I started using MINIMAL.
I didn't do a thorough investigation.
Auto loading is a much bigger problem that just loading drivers for
PCI/USB/etc devices. For example, net80211 doesn't auto load the wlan
crypto modules by default nor the amrr module.
On
I gave you feedback: it crashed somewhere else. I haven't had time to
work on it.
However, go ahead and commit that fix. That code was clearly wrong.
On Mon, 2015-09-21 at 23:21 -0700, Scott Long wrote:
> As a side note, I’m still waiting for feedback on the patch I sent
> you for scsi_sg. I’d
As a side note, I’m still waiting for feedback on the patch I sent you for
scsi_sg. I’d like to get this fixed.
Scott
> On Sep 21, 2015, at 3:53 PM, Rui Paulo wrote:
>
> No, that doesn't work very well. Not only the modules don't auto-load, the
> way the modules are compiled is different.
Apart from the inlining issue John raised (which I agree with his solution on,
btw)
and the one cam ctl module, what other modules are meaningfully different when
compiled as modules.
Assume that the auto-loading bit is solved, at least for devices on
self-enumerating
busses.
Warner
> On Sep
I have both a modules-only kernel (checked in as MINIMAL, but it
needs a little love).
I also have most of the modules loading automatically infrastructure
in place, except for some code to parse data and create devd.conf
scripts on boot. Konstantin asked that I write this before pushing
the bulk
No, that doesn't work very well. Not only the modules don't auto-load, the way
the modules are compiled is different. See, for example, cam ctl which doesn't
compile the sg code when it's built into the kernel, but compiles it when it's
built as a module. The sg code is currently buggy and c
On Mon, Sep 21, 2015 at 03:31:11PM -0700, John Baldwin wrote:
> (I'm of the opinion we should inline atomics and locks, etc. in modules
> built as part of a kernel to match that kernel's config and only use shims
> for modules built standalone. Most of this can probably be accomplished by
> having
On Monday, September 21, 2015 11:24:27 AM Adrian Chadd wrote:
> Hi,
>
> Warner has been working on the modular kernel thing. But honestly, I
> think we should just start biting that bullet and ship a modules-only
> GENERIC by default..
That will not help. In fact, that will probably make it wors
Hi,
Warner has been working on the modular kernel thing. But honestly, I
think we should just start biting that bullet and ship a modules-only
GENERIC by default..
-a
On 21 September 2015 at 11:02, Rui Paulo wrote:
> So, we're going to keep ignoring the problem and keep patching things up?
>
So, we're going to keep ignoring the problem and keep patching things up?
It's a bit sad that a single driver (pmspcv) is able to cause so much problems.
--
Rui Paulo
On Sep 17, 2015, at 01:36 PM, John Baldwin wrote:
Author: jhb
Date: Thu Sep 17 20:36:46 2015
New Revision: 287934
URL: htt
On Thursday, September 17, 2015 10:30:15 PM Bjoern A. Zeeb wrote:
>
> > On 17 Sep 2015, at 20:43 , John Baldwin wrote:
> >
> > On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:
> >> Author: jhb
> >> Date: Thu Sep 17 20:36:46 2015
> >> New Revision: 287934
> >> URL: https://svnweb.f
> On 17 Sep 2015, at 20:43 , John Baldwin wrote:
>
> On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:
>> Author: jhb
>> Date: Thu Sep 17 20:36:46 2015
>> New Revision: 287934
>> URL: https://svnweb.freebsd.org/changeset/base/287934
>>
>> Log:
>> The EFI boot loader allocates a s
On Thursday, September 17, 2015 08:36:47 PM John Baldwin wrote:
> Author: jhb
> Date: Thu Sep 17 20:36:46 2015
> New Revision: 287934
> URL: https://svnweb.freebsd.org/changeset/base/287934
>
> Log:
> The EFI boot loader allocates a single chunk of contiguous memory to
> hold the kernel, modul
Author: jhb
Date: Thu Sep 17 20:36:46 2015
New Revision: 287934
URL: https://svnweb.freebsd.org/changeset/base/287934
Log:
The EFI boot loader allocates a single chunk of contiguous memory to
hold the kernel, modules, and any other loaded data. This memory block
is relocated to the kernel's
23 matches
Mail list logo
