From nobody Thu Aug 8 23:54:30 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 4Wg3n20S7Sz5ScHw for ; Thu, 08 Aug 2024 23:54:46 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 4Wg3n06n6cz4DKC; Thu, 8 Aug 2024 23:54:44 +0000 (UTC) (envelope-from obiwac@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=obiwac@gmail.com Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2f029e9c9cfso23671521fa.2; Thu, 08 Aug 2024 16:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723161283; x=1723766083; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gB4yCdHFlK9M2H1mkHxrvY4a3pk2GdjRWhXnDIq1GgQ=; b=jYlQNCYCoDDnrR7zXl1gMYTzn+g6nGazXj8sRIZmM5lLWuXvQppSJ0DvRw/l6FelIX aIIb0kdetJbDIufBJap6BAWxE4oYRn4z120JXKL1cnc+mMZlvX4Dz0ko5DmmBJGClQpL iDd7zroWxwgjtv8THlLYFmAUQkWomR0rVmDbrwU9HVGCcUvvmSHC+GyTpHKBNQxL78H8 zidOQMQ0ul6TTU4i6Im/qJXdnHw6qZPvXYbK+QBdy6gipsU4ReUYGIYueUPMW9+tJIqF mPa3ZWxCwfz44t1JMYyuwMW5YXdPV0ZLSK+RoN6/b/+yvHXo6vCvmRgZXvwIieKaPLp4 4HQA== X-Forwarded-Encrypted: i=1; AJvYcCVsN4WG153MprwebxEWdqLf1L4Dj7WkPVgZVXXq5PSOB9JnB8u2QBCrCmuY8Ezl0hKJhQ1s@freebsd.org, AJvYcCWDIYjIogypskv35+URSH1Bzoe/DfkiwQ8B9ZjMo56tpN0wWGncqbSEzdxdIqVzFUPY8A4=@freebsd.org X-Gm-Message-State: AOJu0Yz6cw5SN/HFROsRiVrOWr7gxR0qHezcC7X0Wp5U+TCy2V/X4xC1 KWGWg1Wyw1DPgfqufjk/ScbyD9Tuc6z9stwM8favXTbxRFxL3ZClczG7wU/a9Ds= X-Google-Smtp-Source: AGHT+IHHG1gX2q6kO8TsWh0UCrPwng7QqiJh2NMCv05jsyLnPVTPLuhgXSLICX+WE2J8Ye56nF5/pg== X-Received: by 2002:a05:651c:337:b0:2ef:2e3f:35d9 with SMTP id 38308e7fff4ca-2f19de74259mr29476931fa.33.1723161282135; Thu, 08 Aug 2024 16:54:42 -0700 (PDT) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9bc3cb3sm783590766b.27.2024.08.08.16.54.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Aug 2024 16:54:41 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a7d638a1f27so61704166b.2; Thu, 08 Aug 2024 16:54:41 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVqDabQmiwNl4uFbFFVWzl4gLH9LWFJoZpSSIxw5TrDQPTAFcc0LBQ0yuV2PMnYVd4/VJUq@freebsd.org, AJvYcCWRAyWXcAVFdzCwtf/iA5RLWhNndZ2V4BSU2CE3vnO8AGq3OyueZweCRB/ivXSKoO0RWgQ=@freebsd.org X-Received: by 2002:a05:6402:2709:b0:599:4d01:1fb6 with SMTP id 4fb4d7f45d1cf-5bbb23456d1mr3323182a12.16.1723161281633; Thu, 08 Aug 2024 16:54:41 -0700 (PDT) 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 References: In-Reply-To: From: obiwac Date: Fri, 9 Aug 2024 01:54:30 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Questions about best practices w.r.t. writing a kernel module port which modified LinuxKPI (BATMAN) To: Mark Johnston Cc: freebsd-hackers , imp@freebsd.org, John Baldwin , "shawn.webb@hardenedbsd.org" Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.72)[-0.721]; FORGED_SENDER(0.30)[obiwac@freebsd.org,obiwac@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_SPAM_SHORT(0.13)[0.134]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.179:from,209.85.218.48:received]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[obiwac]; RCPT_COUNT_FIVE(0.00)[5]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[obiwac@freebsd.org,obiwac@gmail.com]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.179:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4Wg3n06n6cz4DKC > 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 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.) > >