Questions about best practices w.r.t. writing a kernel module port which modified LinuxKPI (BATMAN)
Date: Sun, 28 Jul 2024 21:04:03 UTC
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? 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? 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? 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? 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)? 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.)