Re: CVS commit: src/sys

[Paul Goyette]

(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 |
+------------------+--------------------------+------------------------+

[Jaromír Doleček]

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

[Paul Goyette]

On Sun, 18 Sep 2016, Jaromír DoleÄ~Mek wrote:

> 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.

No problem - I'm in no hurry. When you're done, I'll make sure to merge
your changes into my sources and provide another patch-set for further
review.

> 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.

For ld, I'm actually creating two separate modules. The 'ld' common
code handles attachment of the ld_cd while the attachment-specific
'ld_nvme' module handles the rest of the data structures. I've not
actually done this before, but it "should just work". :)

Eventually we'll need more attachment-specific modules, but I haven't
done that yet. (I noted this as a To-Do earlier.)

> !DSPAM:57dde2bd165372090633693!