How to compile a custom driver.

[Bruce Ferjulian]

I have a custom SCSI block driver that I would like to add. Without this driver I can't install on bare-metal.

I do not wish to have this code be part of the mainstream build but would like to include it for my environment.

Since there are no package managers on the current CoreOS 3.19.0 version I am using, how does one compile a newer kernel?

On other distros, I could just install the kernel sources and code development packages and build my module either as loadable or into the kernel using the current configuration in ( /proc/config.gz ).




-Bruce-

[Brandon Philips]

On Wed, Mar 25, 2015 at 1:51 PM, Bruce Ferjulian
<bruce.f...@gmail.com> wrote:
> I have a custom SCSI block driver that I would like to add. Without this
> driver I can't install on bare-metal.
>
> I do not wish to have this code be part of the mainstream build but would
> like to include it for my environment.

Why don't you want it upstream? It makes everyone's lives much easier
if it exists in the upstream kernel.

> Since there are no package managers on the current CoreOS 3.19.0 version I
> am using, how does one compile a newer kernel?

We have been meaning to finish our "SDK Container" for a while to
enable this sort of use case. Essentially it would let people compile
custom Kernel modules using the same environment that was used to
generate each release of CoreOS. Unfortunately, it doesn't exist
today; primarily because the need for it has been so rare since nearly
all drivers are upstream.

Perhaps you could describe your use case a bit more and we could help
out. You could generate a custom image of CoreOS from the SDK for this
machine but you wouldn't get updates.

What would your ideal workflow look like for bumping your external
module when CoreOS receives an update?

Thanks,

Brandon

[Bruce Ferjulian]

All good questions.

Q1: Why don't you want it upstream?

A1: The target user base would be small in comparisson to the general Linux user
    community. Yes, it would make this OEM happy to not be maintaining this driver
    and let CoreOS be responsible for building it into each release. The question
    then becomes, when does the kernel become too bloated with every request no matter
    how small the intended user base. In my use case, it makes more sense for CoreOS
    to keep the distribution compact which is impressive, I would like to keep it
    this way and not contribute to the creep.

Q2: Perhaps you could describe your use case a bit more and we could help

    out. You could generate a custom image of CoreOS from the SDK for this
    machine but you wouldn't get updates.

A2: This device behaves like a standard PCI SCSI controller, it is actually a pseudo
    controller created by a hypervisor. Some code to communicate is proprietary and
    exposing it is not preferable. The SDK sounds like a feature we may have to wait
    on before looking closer at CoreOS. End users would like to get timely updates
    for CoreOS but if getting the driver updated in each new distribution is too
    difficult for OEM(s) then it's use could limit us/them. We will wait.


-Bruce-

[Greg KH]

On Thu, Mar 26, 2015 at 06:15:52AM -0700, Bruce Ferjulian wrote:
> All good questions.
>
> Q1: Why don't you want it upstream?
>
> A1: The target user base would be small in comparisson to the general Linux
> user
> community. Yes, it would make this OEM happy to not be maintaining this
> driver
> and let CoreOS be responsible for building it into each release. The
> question
> then becomes, when does the kernel become too bloated with every request no
> matter
> how small the intended user base. In my use case, it makes more sense for
> CoreOS
> to keep the distribution compact which is impressive, I would like to keep
> it
> this way and not contribute to the creep.

This is a false statement, sorry. The kernel community _wants_ your
custom drivers for "small numbers" of hardware. By submitting it
upstream, you will end up with a more robust, usually smaller,
maintained driver that will work with all future kernel versions. If
your driver is out of the tree, it will grow quickly stale and require
constant development to keep it up to date and working.

You will also be responsible for any and all kernel bugs / issues that
happen while running this driver. Without the driver being merged, no
company, or community member will look at any bug reports as they all
will be "assumed" to be from your driver as they can't see the source
for it.

So please submit it upstream, it will save you time and money and will
get the hardware to work for all kernel distributions for all time in
the future.

Do you have a pointer to the source anywhere that I can take a look at
it?

thanks,

greg k-h

[Bruce Ferjulian]

You: In response to "This is a false statement, sorry. The kernel community _wants_ your custom drivers for "small numbers" of hardware."

Me: The community may want the driver, but as previously mentioned, intellectual property in the driver is closed, how do you handle this scenario where the user does not wish to expose their work and still use the CoreOS.

Q: Do you have a pointer to the source anywhere that I can take a look at it?
A: I am sorry but I do not.

Thanks to all that responded so far. We will wait until an SDK is made available.

[Greg KH]

On Thu, Mar 26, 2015 at 07:19:20AM -0700, Bruce Ferjulian wrote:
> You: In response to "This is a false statement, sorry. The kernel community
> _wants_ your custom drivers for "small numbers" of hardware."
>
> Me: The community may want the driver, but as previously mentioned,
> intellectual property in the driver is closed, how do you handle this scenario
> where the user does not wish to expose their work and still use the CoreOS.

You can't have "closed" IP in a Linux kernel driver, sorry. That goes
against the license of the kernel itself, if you were to distribute that
driver. So if some vendor is trying to provide that to you, be _very_
worried, as you are seriously on your own, there's nothing anyone can do
to help you out.

good luck,

greg k-h

[Bruce Ferjulian]

Tell me that NVIDIA provides all the sources for their drivers.

-Bruce-

[Seán C. McCord]

For the kernel interface, they do just that, yes.

[Michael Marineau]

Although there are many awkward aspects to using external kernel
modules on CoreOS the dev container for building them is available,
just poorly documented. A quick guide I wrote in response to a
previous email is available here:
https://gist.github.com/marineam/9914debc25c8d7dc458f

Hope that helps get you started. Also it is worth noting that the
kernels we ship are vanilla kernel.org kernels so if you want to build
modules on a different system but target CoreOS just get the source
from kernel.org. There are a few guides for nvidia around the web that
use that approach.

On Wed, Mar 25, 2015 at 1:51 PM, Bruce Ferjulian
<bruce.f...@gmail.com> wrote:

[Greg KH]

On Thu, Mar 26, 2015 at 07:25:36PM -0700, Bruce Ferjulian wrote:
> Tell me that NVIDIA provides all the sources for their drivers.

The GPL doesn't kick in until distribution, so nVidia is very careful
about how they distribute their closed source kernel drivers, and who
they make distribute the binaries (hint, it's not them...)

If you wish to spend as much money and time as nVidia does, in order to
properly keep up to date with kernel api changes, and require your
customers to assume the liability of any GPL violations, wonderful, best
of luck, it's a lot of work. But if not, be very careful and consult
with lawyers as to what your risks are here, it's not trivial at all.

Best of luck,

greg k-h

[Seán C. McCord]

Perhaps they have changed things (I haven't used nVidia in many years, thanks to their driver problems and proprietariness), but at least for many years, they supplied the source code for their kernel driver.  It was terribly unclean with binary blobs (which is why it is not included in the kernel tree), but it supposedly met the terms of the license, if by skirting them as much as possible.  The closed-source components are distributed as a separate, user-space module which communicates with the kernel driver, allowing it to (presumably) bypass the GPL requirements of the kernel.

In any case, the Linux kernel is licensed under GPLv2 (https://www.gnu.org/licenses/gpl-2.0.html), and plank 3 explicitly discusses the terms of binary distribution, which is just as Greg describes.