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

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

Great!

> In general, yes.

That's what I feared.

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

I'll save myself the complexity and just base my changes against -CURRENT then.

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

I was unaware of this, thank you. This indeed makes most of my
ifconfig changes redundant. The only extra thing I was doing was
adding a special argument on creation to select the batman routing
algorithm, but I guess I can just default it to the most commonly used
one and have an external tool available in case someone needs the
other routing algo.

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

Is there a policy against integrating code into FreeBSD which isn't
directly useful to what comes with it out of the box though? I.e., the
kernel module for batman can't be shipped with FreeBSD as it's GPL. If
I write a userspace utility similar to batctl to control these
interfaces, I'm assuming this also must be distributed separately and
can't be integrated into FreeBSD?

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

Not really, no. Without WiFi support it's really just an alternative to OLSR.

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

Okay, that's what I'll do.

Thank you for your detailed response and have a great evening!



On Fri, 2 Aug 2024 at 02:50, Mark Johnston <markj@freebsd.org> wrote:
>
> 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.)
> >