All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@kernel.org>,
	Sagi Grimberg <sagi@grimberg.me>, Keith Busch <kbusch@kernel.org>,
	linux-nvme@lists.infradead.org
Subject: Re: [PATCH 5/9] nvme: split off TLS sysfs attributes into a separate group
Date: Wed, 24 Jul 2024 15:41:06 +0200	[thread overview]
Message-ID: <20240724134106.GA12516@lst.de> (raw)
In-Reply-To: <210a37b2-cc26-43ee-99f3-19dee796e677@suse.de>

On Tue, Jul 23, 2024 at 07:29:59PM +0200, Hannes Reinecke wrote:
>> I would have also kinda expected that this attribute group lives in
>> tcp.c, is there a good reason to keep it in the core code?
>>
> I knew this argument would be coming.
> Thing is: these options depend on CONFIG_NVME_TCP_TLS, so
> they will always be encapsulated in some #ifdef, be it in sysfs.c
> or in tcp.c.

I don't really mind the ifdefs per se.  It's just that we'll have
this code built into nvme-core.ko for common kernel setups where no
one uses nvme-tcp at all.

> And as we always will have to have an #ifdef in one of the files
> I thought it easier to keep it in sysfs.c, and save us having to
> have an exported attribute_group which might even be empty.

I'm ok with this series of fixes going forward without it for now,
but in the long run I'd like to keep the core code as lean as
possible.



  parent reply	other threads:[~2024-07-24 13:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-22 12:02 [PATCHv8 0/9] nvme: fixes for secure concatenation Hannes Reinecke
2024-07-22 12:02 ` [PATCH 1/9] nvme-keyring: restrict match length for version '1' identifiers Hannes Reinecke
2024-07-23 14:43   ` Christoph Hellwig
2024-07-22 12:02 ` [PATCH 2/9] nvme-tcp: sanitize TLS key handling Hannes Reinecke
2024-07-22 12:02 ` [PATCH 3/9] nvme-tcp: check for invalidated or revoked key Hannes Reinecke
2024-07-23 14:43   ` Christoph Hellwig
2024-07-29 14:43   ` Keith Busch
2024-07-31  9:45     ` Sagi Grimberg
2024-08-12  6:25       ` Hannes Reinecke
2024-08-12 14:09         ` Hannes Reinecke
2024-08-12 15:17           ` Keith Busch
2024-08-13 19:29             ` Sagi Grimberg
2024-07-22 12:02 ` [PATCH 4/9] nvme: add a newline to the 'tls_key' sysfs attribute Hannes Reinecke
2024-07-22 12:02 ` [PATCH 5/9] nvme: split off TLS sysfs attributes into a separate group Hannes Reinecke
2024-07-23 14:49   ` Christoph Hellwig
2024-07-23 17:29     ` Hannes Reinecke
2024-07-23 18:17       ` Sagi Grimberg
2024-07-24 13:41       ` Christoph Hellwig [this message]
2024-07-22 12:02 ` [PATCH 6/9] nvme-sysfs: add 'tls_configured_key' sysfs attribute Hannes Reinecke
2024-07-22 12:02 ` [PATCH 7/9] nvme-sysfs: add 'tls_keyring' attribute Hannes Reinecke
2024-07-22 12:02 ` [PATCH 8/9] nvmet-auth: allow to clear DH-HMAC-CHAP keys Hannes Reinecke
2024-07-22 12:02 ` [PATCH 9/9] nvme-target: do not check authentication status for admin commands twice Hannes Reinecke
2024-07-28 20:50 ` [PATCHv8 0/9] nvme: fixes for secure concatenation Sagi Grimberg
  -- strict thread matches above, loose matches on Subject: below --
2024-07-19  8:38 [PATCHv7 " Hannes Reinecke
2024-07-19  8:38 ` [PATCH 5/9] nvme: split off TLS sysfs attributes into a separate group Hannes Reinecke
2024-07-21 11:15   ` Sagi Grimberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240724134106.GA12516@lst.de \
    --to=hch@lst.de \
    --cc=hare@kernel.org \
    --cc=hare@suse.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.