tech-kern archive

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

Re: CVS commit: src/sys



Thanks for looking at this, Paul.

Please hold on with commits though. I'm finishing MP fixes for nvme(4)
and I want to commit the code on Sunday afternoon (GMT-2). That set
also includes fix for to the module attachment to also attach nvme
cdevsw (to make nvmectl work). I'll look on your patches after that.

One thing to note though - ld(4) is not regular pseudo-device, it can
be attached to several different 'busses'. I haven't seen a way in the
module framework to make them configure properly - i.e. you can't have
e.g. ld_nvme and ld_aac and expect them to work, they would have
conflicting ld_cd. Maybe I didn't look hard enough though. Also it
doesn't really make sense to separate nvme and nvme_pci at this
moment, there is no non-pci nvme.

Jaromir

2016-09-17 10:19 GMT+02:00 Paul Goyette <paul%whooppee.com@localhost>:
> (Redirecting to tech-kern, and moving source-changes-d to bcc)
>
> The attached diffs make a first pass at dealing with this mess.  It creates
> two new modules (ld common code, and ld_nvme attach specific), and updates
> the sets lists as appropriate.  It also modifies the nvme code to be able to
> handle "bus rescan" - attaching a modular driver requires rescan capability
> on the parent device.  And finally, the changes remove the ld code from the
> nvme module.
>
> I'm not prepared to commit this yet, since I'm not in a position to do any
> serious testing (for one thing, I don't have a nvme device...)  I have
> successfully built a release with these changes.
>
> There's still more work that eventually needs to be done.  First, the other
> attachments for ld should be modularized, and the parents should be taught
> how to do a rescan.  Secondly, the nvme module itself needs to be split into
> nvme-common and nvme-pci pieces.  But neither of these is urgent.
>
> I'd very much appreciate it if someone with the appropriate hardware could
> do some testing.  Just build a kernel with neither ld nor nvme devices
> included, and build the modules.  Put everything in the right places,
> reboot, and try to 'modload ld_nvme'.  You should see other modules get
> autoloaded (turn on sysctl kern.module.verbose for more details), and
> hopefully the nvme device will get attached.  (But I'd be very surprised if
> this works on the first attempt!)
>
>
>
>
> On Sat, 17 Sep 2016, Paul Goyette wrote:
>
>> On Fri, 16 Sep 2016, Paul Goyette wrote:
>>
>>>> Log Message:
>>>> make it possible to load nvme(4) as module to ease testing; currently
>>>> somewhat
>>>> non-optimal, since it includes the ld(4) code also and hence requires
>>>> the
>>>> kernel config to have 'no ld'
>>>
>>>
>>> Wouldn't it make more sense to also enable ld(4) as its own module, and
>>> then have nvme "require" ld?
>>
>>
>> Actually, it looks like we really should have four separate modules
>> here...
>>
>> * ld        For the common ld code
>> * ld_nvme   For the 'ld* at nvme?' attachment code, requires "ld,nvme"
>> * nvme      For the common nvme code
>> * nvme_pci  For the 'nvme* at pci?' attachment code, requires "nvme,pci"
>>
>>
>>
>>
>> +------------------+--------------------------+------------------------+
>> | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
>> | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
>> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
>> +------------------+--------------------------+------------------------+
>>
>
> +------------------+--------------------------+------------------------+
> | Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
> | (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +------------------+--------------------------+------------------------+


Home | Main Index | Thread Index | Old Index