Re: Questions about best practices w.r.t. writing a kernel module port which modified LinuxKPI (BATMAN)

On Sun, Jul 28, 2024 at 11:04:03PM +0200, obiwac wrote:
> Hi!
> 
> I worked on porting the batman_adv Linux kernel module to FreeBSD
> using the LinuxKPI last year as part of a GSoC project and I now have
> time to work on WiFi support for it (which is necessary for it to
> actually be useful in practice). Before I do so though, I'd like to
> create a port for it. I have a few questions about best practices
> w.r.t. going about this which I was unable to answer by myself by
> looking around at other ports (specifically drm-kmod, it's the only
> other port that I know of that distributes a kernel module that
> depends on the LinuxKPI). Here are the two main questions I have:
> 
> 1. I have made changes to the LinuxKPI headers and other parts of the
> kernel in order to accommodate batman_adv. Is it okay for me to
> upstream those changes, or should I expect users to apply a patchset
> on their kernel source and to recompile it?

It's most likely better to try and upstream your changes.  Doing so
lowers the amount of effort required of users that wish to test your
module, which makes it more likely that users will test it.

> If I can upstream them,
> what should I do about older versions than -CURRENT? Will I just have
> to wait for those changes to go into the next -STABLE release?

In general, yes.  Depending on the nature of your linuxkpi
modifications and/or extensions, it might be possible to bundle them in
such a way that the module is portable to different versions of FreeBSD.

> And if
> so, will that mean that any updates that I make to the LinuxKPI
> headers necessary for newer versions of batman_adv will either have to
> wait until the next release or be distributed alongside the port?

It's hard to say in general.  It might be possible to bundle your own
linuxkpi extensions, but it depends on what you're changing and adding.

> 2. I have made changes to ifconfig to support the creation of BATMAN
> soft interfaces. Should I upstream those changes and somehow disable
> them when the kernel module is not loaded, or should I distribute a
> patched version of ifconfig with my port?

The typical behaviour for ifconfig is to load requisite kernel modules
automatically when creating a new interface.  See ifmaybeload() in
sbin/ifconfig/ifconfig.c.  So, it's generally fine for ifconfig to
support functionality that requires a kernel module.

> Or should I go with a
> different solution entirely, and write and distribute a tool similar
> to batctl (which from what I understand was the route taken when
> distributing BATMAN on most Linux distros before iproute2 added
> support for managing BATMAN interfaces)?

It's hard to say without some pointers your code.  As a general rule,
integrating your code into FreeBSD reduces the amount of work needed to
keep out-of-tree code up-to-date, but requires more work up front, so
there's a tradeoff involved.

Given that you said that some additional WiFi support is needed to make
your module useful, I wonder if it's worth your time to create a port
first - if I install it locally, would I be able to do anything with it?
You might find that it's better to focus on the module in the near term,
and maybe try to upstream linuxkpi changes in parallel so that it's
easier to create a port later.

> Thank you so much in advance for your answers & help!
> 
> (Warner, John, I've CC'd you two as you were in the thread on the
> possibility of upstreaming this to the source tree.)
>