From nobody Fri Aug 02 00:50:37 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WZnLr144kz5RpGK for ; Fri, 02 Aug 2024 00:50:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WZnLq15nHz413p; Fri, 2 Aug 2024 00:50:43 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=AAZ+oFkE; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f2e as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-6b97097f7fdso47476456d6.0; Thu, 01 Aug 2024 17:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722559841; x=1723164641; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=aVAyTsBPCnVnWVPf+qO9rchUG27iHn71Ar8jdRrvo9U=; b=AAZ+oFkE5V8YDCuZJLs4cLyCjvy5mK2nQr/rRNzoQ3dMtiW0iKQDJDrcdMdydwvPyh hOLOt+XkRD1Qos94jLf2wnMwR/tT6PMTpogTYHPLwLXGtgb2wE2Ok3PpTM6mg6V0/H+Y WnF6xKrAdhE2sXLngugfOn4Y0shamXNEMRAEgpwic90kVwYjyJR6zNQzAE7C7iMJImcy 9h+cq3Vsks9+lDO2xZEFYZdL63pwdWWOG+U/0VHXhy5zZL0NwXzb5HC26XFk3KDxmRme +HBvHXAMzyFD5OLvUTpP1HCrOYh3ZUVK4Ld1HtgGveFk9zEzz7trKS2anymYE9BJGMDw 1jiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722559841; x=1723164641; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aVAyTsBPCnVnWVPf+qO9rchUG27iHn71Ar8jdRrvo9U=; b=FpbE+7BgaQdwiulYqr4+q7Tv+eOMaF/xskLVknJ8jExEfUi5+nahMuEnU52IY30ogU 5r9G/wrCONjC/2TwAScWNZbcNHBqUc4D76OTkKqAgOFzXHMq3Z9Zuyf0F4XUtA+IUelw LL7Hv8HOdcPpIa12V1SUnoEg+gS/bBVZrLTO4T3Poci/V0ZdfScYN7t5EZswhlR9wDQR byRURIl6EcZ0FmLHkJ/DaFBIKtuj9rFpyHzsl8ZDWy8Q7Rjw1+k1MI5PPlq7hQHK2nw9 hAav59JRcnaXD4leFfihQ5AiJZGuTWTT+hb3MfbgTczjtptb/rlbMA2Un6Mn1Iyzabwg /3eg== X-Forwarded-Encrypted: i=1; AJvYcCWvJlvAHS1X8UzCvMAqX/qTMNq9hVE1g6NDuU5SXseode/hmNTuRE2WhcNSX8IyZXjzvBIFieSwEnZmu6zQZhK4vF5YuCxd9Csh8oUvNluSQA== X-Gm-Message-State: AOJu0YyNB6s+CgzxlaVTNK4u9ZMEDhqn54gc7PLhcIGYodLdh4ZR3Qzj brHwbySr7ITOdmXdoFWmgIeTt0j/nXrlk2MG8RwA7uRpxY4Vkd+AE3WFJOUz X-Google-Smtp-Source: AGHT+IFU0b1UD0j3exOECUMzyBsd3sjBR83rWxQykLOprTS6XSmZSTJyCpjIE/tU10NV0xu5RYUhJg== X-Received: by 2002:a05:6214:5405:b0:6b4:b179:8eea with SMTP id 6a1803df08f44-6bb98346b73mr27528756d6.3.1722559841467; Thu, 01 Aug 2024 17:50:41 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6bb9c864ee0sm1882236d6.119.2024.08.01.17.50.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Aug 2024 17:50:40 -0700 (PDT) Date: Thu, 1 Aug 2024 20:50:37 -0400 From: Mark Johnston To: obiwac Cc: freebsd-hackers , imp@freebsd.org, John Baldwin , "shawn.webb@hardenedbsd.org" Subject: Re: Questions about best practices w.r.t. writing a kernel module port which modified LinuxKPI (BATMAN) Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2e:from]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4WZnLq15nHz413p 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.) >