>>Only slightly :-) Thank you, Christian. The one thing I don't know is whether there is anybody on the list who feels that they need the module with the CONFIG_VFIO_NOIOMMU set. Actually, I have a huge hole in my knowledge base in the entire area of VFIO, UIO, IOMMU. But if there is interest in a custom module at this time with that option set, I may have provided a service: although my procedure has a number of steps, they are simple in comparison to building a kernel that has a standard configuration. The latter requires lots of disk space and lots of time.
>>I'm believing in the good of people and expect all misinformation to be based on some case that worked for whoever wrote it in the past :-) Yes, I have mischaracterized the situation a bit; my frustration was that I invariably find the same use case, which is slightly different from what we have here. The standard case that is addressed is essentially: you are writing a custom module from scratch, it does not have any CONFIG_... options in it, or at least, none that differ from the running kernel .config. The other piece of information that I found misleading was the idea expressed in /var/lib/dpkg/status for package linux-source-4.8.0 If you are simply trying to build third-party modules for your kernel, you do not want this package. Install the appropriate linux-headers package instead. I still think I have a case where I want both linux-headers and linux-source. So reading that WHILE I was struggling to figure out a solution was further throwing me off the track. I did attempt one simplification to my procedure: just work with the linux-source package, and do the make menuconfig in its top directory, and then do the kernel make command I showed earlier with the M= option. This simpler procedure did not work; I believe there are a few extra "goodies" in the linux-headers packages I needed. Note that the steps of copying to my home directory keep the originals pristine and allow me to work without being root. Now I was not thorough earlier to check that CONFIG_VFIO_NOIOMMU or VFIO_NOIOMMU does not show up in unexpected places that would lead to an inconsistent kernel, but since then I grepped through all .c, .h, and Kconfig* to verify. Looks good; things are limited to vfio.c. Your DKMS method is probably the best, I have not tried it, but I don't think it will directly handle the CONFIG option in vfio.c. Am I correct? Perhaps a smarter approach than my first one is to modify vfio.c, and add the line #define CONFIG_VFIO_NOIOMMU 1 just below the existing #defines, and then use DKMS. If I can combine this with getting the vfio.c source from the appropriate git repo, the only manual effort is to occasionally do a git pull to pick up updates. Well, not quite, but almost; it won't happen if I am locked to a tag. Anyway, my earlier method was seeking the "graceful" meaning of elegance, rather than the "simple" definition of elegance that occurs with simply adding the #define to vfio.c. I'll play around with DKMS and see if I can get results -- I have not used DKMS enough. Burt On Fri, Jan 27, 2017 at 3:38 AM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > > On Thu, Jan 26, 2017 at 6:46 PM, Burt Silverman <bur...@gmail.com> wrote: > >> Thanks, Christian, this is great information. >> >> Just for fun, before I read this, I wanted to test some of my kernel >> building skills. So I just wish to build modules in the drivers/vfio >> directory. I want to do what might be called "building an external module" >> or "building only one kernel module" as in http://askubuntu.com/questions >> /515407/how-recipe-to-build-only-one-kernel-module or "building a third >> party module". But the Google hits like that one assume that you have no >> interest in changing the .config. >> > > Is that "Building a module with a different kernel config than the kernel"? > In that case that as so close to breaking it intentionally as possible :-) > > >> And one Ubuntu package that may be useful, linux-source, has info showing >> up in Synaptic saying "you don't want this package." >> > > That is what you really want - https://wiki.ubuntu.com/ > Kernel/Dev/KernelGitGuide > Maybe we should say this in the package - yet URLs tend to change ... > > >> Here is my procedure and I hope it works -- it is relatively painless. >> I'll describe it for a particular level. I am using the desktop version of >> Ubuntu. >> > [...] > >> This is tricky stuff because there is plenty of non-information and >> misinformation out there AND >> > > IMHO it just is complex enough to confuse everybody more often than not > (myself included if I haven't done it for a few weeks/months). > I'm believing in the good of people and expect all misinformation to be > based on some case that worked for whoever wrote it in the past :-) > In that sense, yours likely will fail for many others AND even for you in > a certain time int he future. > > [...] > > >> Well, this stuff may be slightly off topic, > > > Only slightly :-) > > >> but if I ever have to retrieve my instructions, I'll know where to >> search, chuckle. > > > For me the (currently) "right" way to build an external kernel module is > DKMS (https://help.ubuntu.com/community/DKMS). > For the reasons I mentioned above - intentionally not buidling with > different kernel config (never do that, if you want build the full kernel). > At a slightly higher rampup time DKMS gives you automatic rebuild of the > module on kernel update. > So you update your system and get a new security update - fine your extra > module will automatically be re-built for you and work - yeah. > That is e.g. what we do for the out-of-tree igb_uio module (to get it a > bit back to topic) - see https://gerrit.fd.io/r/ > gitweb?p=deb_dpdk.git;a=blob;f=debian/dpdk-igb-uio-dkms.dkms;h= > 5141ff61221afeb0b2bb63034665780532c2a46d;hb=refs/heads/16.11.x > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
