From nobody Tue Jul 30 20:09:27 2024 X-Original-To: freebsd-current@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 4WYRCQ0CNkz5RtPF for ; Tue, 30 Jul 2024 20:09:38 +0000 (UTC) (envelope-from peter@wemm.org) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:559:8585:200:4::78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp2.wemm.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WYRCP3wQxz4hr5; Tue, 30 Jul 2024 20:09:37 +0000 (UTC) (envelope-from peter@wemm.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.0.0.62] (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 15A931576D; Tue, 30 Jul 2024 13:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1722370168; bh=TlDACKF6XbJhQfdHSWQc+9ESLTAjILcEEuulzcV7dwk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=V0gpiPhOxRqGwuWn2HAiLVFtGtB7yR5fum1c54hj1nrzkI7pBxZdjy7TaBUHlwk+E Zw+zBsvkJPX532wssjCwu+ZumwJ36D0DS3FXzUKNRrrMTVAfahvLyDOLkdcaa2Ic4o xtaBD/VQytDdM50mqZoLpEHc715UiOA4WwG1RPec= Content-Type: multipart/alternative; boundary="------------bEkkkBPmtyjlbIwuFL9xtp9e" Message-ID: Date: Tue, 30 Jul 2024 13:09:27 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: filemon To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Poul-Henning Kamp Cc: Gary Jennejohn , freebsd-current@freebsd.org, peter@freebsd.org References: <20240727170122.675f6bfe@ernst.home> <865xsn6ya9.fsf@ltc.des.dev> <202407301049.46UAnrXX011101@critter.freebsd.dk> <86o76f5ckt.fsf@ltc.des.dev> Content-Language: en-US From: Peter Wemm In-Reply-To: <86o76f5ckt.fsf@ltc.des.dev> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:33651, ipnet:2001:559:8585::/48, country:US] X-Rspamd-Queue-Id: 4WYRCP3wQxz4hr5 This is a multi-part message in MIME format. --------------bEkkkBPmtyjlbIwuFL9xtp9e Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote: > "Poul-Henning Kamp" writes: >> Dag-Erling Smørgrav writes: >>> There is very little difference between options and devices in kernel >>> configuration files, but for what it's worth, filemon is a device, not >>> an option. >> Apart from the internals of config(8) and it's input data, is there >> any actual difference left ? > From the perspective of including files in the build, there is no > difference: `foo/foo.c optional foo` does not care whether "foo" is an > option or a device. However, options generate macros, while devices > don't. So adding `option FILEMON` to your kernel config will cause > filemon to be compiled into the kernel, but it will also generate an > unneeded opt_filemon.h with `#define FILEMON 1`. Or it would, if it > weren't for this: > > % git annotate sys/conf/options |& grep -i filemon > 6c6f1f0185b84 (Peter Wemm 2013-07-03 20:22:12 +0000 109)FILEMON opt_dontuse.h > > which suggests Peter intended filemon to be an option rather than a > device. > > DES Yes it probably should have been a device from the start.  I do not recall why I picked one over the other.  It was originally not config(8)able at all. -Peter --------------bEkkkBPmtyjlbIwuFL9xtp9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote:
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:

Dag-Erling Smørgrav <des@FreeBSD.org> writes:

There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.

Apart from the internals of config(8) and it's input data, is there
any actual difference left ?

>From the perspective of including files in the build, there is no
difference: `foo/foo.c optional foo` does not care whether "foo" is an
option or a device.  However, options generate macros, while devices
don't.  So adding `option FILEMON` to your kernel config will cause
filemon to be compiled into the kernel, but it will also generate an
unneeded opt_filemon.h with `#define FILEMON 1`.  Or it would, if it
weren't for this:

    % git annotate sys/conf/options |& grep -i filemon
    6c6f1f0185b84	(Peter Wemm	2013-07-03 20:22:12 +0000	109)FILEMON	opt_dontuse.h

which suggests Peter intended filemon to be an option rather than a
device.

DES

Yes it probably should have been a device from the start.  I do not recall why I picked one over the other.  It was originally not config(8)able at all.

-Peter

--------------bEkkkBPmtyjlbIwuFL9xtp9e--