From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nicolas Graves via "Development of GNU Guix and the GNU System distribution." Newsgroups: gmane.comp.gnu.guix.devel,gmane.emacs.devel Subject: Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file Date: Sun, 12 May 2024 13:11:50 +0200 Message-ID: <8734qn9te1.fsf@ngraves.fr> References: <20240410234923.29319-2-ngraves@ngraves.fr> <875xwotg35.fsf@trop.in> <87zfu0m9ps.fsf@ngraves.fr> <87jzl22u5w.fsf@gnu.org> <87frvp4a4u.fsf@ngraves.fr> <87msow5cm8.fsf@ngraves.fr> <87msow7xrs.fsf@ngraves.fr> <86bk5b1r1i.fsf@gnu.org> <87cyprbhap.fsf@ngraves.fr> <861q671idt.fsf@gnu.org> Reply-To: Nicolas Graves Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11953"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, ludo@gnu.org, emacs-devel@gnu.org, andrew@trop.in, guix-devel@gnu.org, bjorn.bidar@thaodan.de, rudi@constantly.at, felix.lechner@lease-up.com To: Eli Zaretskii Original-X-From: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sun May 12 13:12:31 2024 Return-path: Envelope-to: gcggd-guix-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s6783-0002ud-45 for gcggd-guix-devel@m.gmane-mx.org; Sun, 12 May 2024 13:12:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s677g-0007oQ-GL; Sun, 12 May 2024 07:12:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s677a-0007lG-JH for guix-devel@gnu.org; Sun, 12 May 2024 07:12:06 -0400 Original-Received: from 19.mo561.mail-out.ovh.net ([178.32.98.231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s677U-0002nG-FB for guix-devel@gnu.org; Sun, 12 May 2024 07:12:01 -0400 Original-Received: from director11.ghost.mail-out.ovh.net (unknown [10.109.176.101]) by mo561.mail-out.ovh.net (Postfix) with ESMTP id 4Vcg1P1gpPz1FPn for ; Sun, 12 May 2024 11:11:53 +0000 (UTC) Original-Received: from ghost-submission-6684bf9d7b-pdfqg (unknown [10.110.96.35]) by director11.ghost.mail-out.ovh.net (Postfix) with ESMTPS id D15421FDFF; Sun, 12 May 2024 11:11:51 +0000 (UTC) Original-Received: from ngraves.fr ([37.59.142.109]) by ghost-submission-6684bf9d7b-pdfqg with ESMTPSA id pd+xLvejQGaQegEARJCOCQ (envelope-from ); Sun, 12 May 2024 11:11:51 +0000 Authentication-Results: garm.ovh; auth=pass (GARM-109S00366b277de-fe17-4e58-9fe7-7c0a3edcf0dd, 657DB11BEA81279387F13E7D9D19D75D6CB13AAA) smtp.auth=ngraves@ngraves.fr X-OVh-ClientIp: 176.191.136.151 In-Reply-To: <861q671idt.fsf@gnu.org> X-Ovh-Tracer-Id: 11815475100104122920 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvledrvdegvddgfeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkgggtgfesthhqredttddtjeenucfhrhhomheppfhitgholhgrshcuifhrrghvvghsuceonhhgrhgrvhgvshesnhhgrhgrvhgvshdrfhhrqeenucggtffrrghtthgvrhhnpeefvedutedvgeejteeivdejtdfghffhteefhfdugeekuedvvddtveeiteefvddvgeenucffohhmrghinhepmhgrshhtohguohhnrdhsohgtihgrlhdpghhithhhuhgsrdgtohhmpdhfrhgvvgguvghskhhtohhprdhorhhgnecukfhppeduvdejrddtrddtrddupddujeeirdduledurddufeeirdduhedupdefjedrheelrddugedvrddutdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehnghhrrghvvghssehnghhrrghvvghsrdhfrhdpnhgspghrtghpthhtohepuddprhgtphhtthhopehguhhigidquggvvhgv lhesghhnuhdrohhrghdpoffvtefjohhsthepmhhoheeiuddpmhhouggvpehsmhhtphhouhht Received-SPF: pass client-ip=178.32.98.231; envelope-from=ngraves@ngraves.fr; helo=19.mo561.mail-out.ovh.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Original-Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.comp.gnu.guix.devel:70200 gmane.emacs.devel:319181 Archived-At: On 2024-05-12 12:36, Eli Zaretskii wrote: >> From: Nicolas Graves >> Cc: monnier@iro.umontreal.ca, ludo@gnu.org, emacs-devel@gnu.org, >> andrew@trop.in, guix-devel@gnu.org, bjorn.bidar@thaodan.de, >> rudi@constantly.at, felix.lechner@lease-up.com >> Date: Sun, 12 May 2024 09:50:06 +0200 >>=20 >> On 2024-05-12 09:29, Eli Zaretskii wrote: >>=20 >> > Thanks. What was the motivation for this, again? >>=20 >> A light summary (all is in the preceding exchanges in the mailing list): >>=20 >> - Ludovic Court=C3=A8s suggested this change because linking with system= d is >> unnecessary (very light usage), and increases the attack surface. >>=20 >> - Rudolf Schlatte highlights that Lennart Poettering says that the >> notify protocol is stable and independent of libsystemd. >> https://mastodon.social/@pid_eins/112202687764571433 >> https://mastodon.social/@pid_eins/112202696589971319 >> This mastondon thread itself contains a lot of info/answers about >> this, including examples of similar work on other projects: >> - https://github.com/FRRouting/frr/pull/8508 >> - https://github.com/OISF/suricata/pull/10757 >> Lennart Poettering also says that the protocol has been stable for a >> decade and will surely be for at least another decade. >>=20 >> This should also answer the worry about significant maintenance. > > I'm sorry, but I'm wary of believing such assertions, especially when > systemd is involved. E.g., what's to prevent people from asking us to > support the various forks of systemd as well? Don't they also support this precise protocol? Originally this thread was precisely about some limitations about emacs's integration with GNU shepherd, exposing a "manual" pid-file solution I found, and Ludovic answering "great, but look GNU shepherd can emulate notify protocol's server side and GNU emacs can do it on the client side". What I get from that is that systemd is so ubiquitously used that even GNU Shepherd needed to emulate systemd's notify protocol to properly manage some services, this protocol is probably already emulated in most init system (is it?). In my own experience, it's indeed simpler to rely on it rather than manually implementing proper emacs-shepherd integration. > Reimplementing everything in-house doesn't scale, definitely not in a > project as large as Emacs. So the argument about smaller attack > surface doesn't really convince me. Emacs uses quite a lot of > external libraries to the benefit of our users, and that will not > change any time soon. Lennart himself wrote "if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API", I'm (with my biases) more worried about "if all you want" and what happens if users ask for deeper integration with systemd than these two functions than about systemd's stability promise. One example is what I did with my pid-file emacs-shepherd integration : be able to notify (in the sense of libnotify, not systemd) when server has started but is not ready yet. This could be done with some smart use of sd_notify_reloading, and would require the vendoring of this other function (although this one is provided as such by Lennart too ; but any deeper use (I can't find an example though) might be harder to implement). I'm not going to push much for this, currently rewriting the patch, will make that working again with recommended changes. If maintainers get convinced and licensing is ok, use it. If Guix or some other distro want to use it as a vendored patch, fine (indeed it doesn't make sense on Guix to pass elogind as an input for this). I just wrote that after Stefan's suggestion, and after seeing that the actual code is basically two C functions, I'm not actively pushing for it. >> What I'm less confident about is edge cases as I highlighted earlier >> (are there cases where systemd's safe_atoi is necessary compared to >> strtol ? Is it fine if LISTEN_FDS is set but LISTEN_PID unset, or >> should be check for LISTEN_PID definition too ?) > > This is exactly the kind of maintenance burden I'm concerned about: > who will help us answer these questions, now and in the future? We > cannot rely on having systemd experts on board at all times. I'll add a tiny check to also verify that LISTEN_PID is set. The first question is the kind of questions that come up when adapting foreign code, but when strictly reading the protocol, it should be fine, the point is to parse LISTEN_FDS. >> >> > - The sd_notify code is taken from >> >> > https://www.freedesktop.org/software/systemd/man/devel/sd_notify.ht= ml#Notes >> > >> > I'm not sure what would be the legal aspects of such code borrowing. >>=20 >> The code is given as MIT-0, hence also the two different licenses for >> the two functions sd_notify and sd_is_socket. Not an expert on licenses >> either, but with a proper flag about what this function's license is, I >> guess it should be fine, since other projects also do that. > > The license is only half of the problem. Every non-trivial > contribution to Emacs must have its copyright assigned to the FSF, > because the FSF is in charge of protecting the Emacs sources, > something that only the copyright holder can do, at least in some > countries. You will need to assign the copyright as well (a > relatively simple procedure of filling a form and emailing it), but if > the code is not yours, you cannot assign its copyright. Don't emacs have some C functions coming mainly from other codebases? How is it handled in this case? I have a development question. Where should be the functions declaration header? There are specific to gnu-linux/aix/hpux. Thanks. NB. In emacs's configure.ac, the note about finding which libsystemd version is the first supported, with 222 truly working, has an answer in=20 https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes Interfaces used have been introduced in 217. Requires a test, but that is almost certainly the answer. --=20 Best regards, Nicolas Graves