All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <code@tyhicks.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: ecryptfs@vger.kernel.org, brauner@kernel.org
Subject: Re: [PATCH 2/2] ecryptfs: Convert ecryptfs to use the new mount API
Date: Wed, 30 Oct 2024 16:08:37 -0500	[thread overview]
Message-ID: <ZyKgVY8ekrJEKLZl@redbud> (raw)
In-Reply-To: <c9874487-f31f-42e8-a715-e010d166e5ac@redhat.com>

On 2024-10-28 09:22:35, Eric Sandeen wrote:
> On 10/21/24 9:07 AM, Eric Sandeen wrote:
> 
> >>> +
> >>> +	opt = fs_parse(fc, ecryptfs_fs_param_spec, param, &result);
> >>> +	if (opt < 0)
> >>> +		return opt;
> >>> +
> >>> +	switch (opt) {
> >>> +	case Opt_sig:
> >>> +	case Opt_ecryptfs_sig:
> >>> +		rc = ecryptfs_add_global_auth_tok(mount_crypt_stat,
> >>> +						  param->string, 0);
> >>> +		if (rc) {
> >>> +			printk(KERN_ERR "Error attempting to register "
> >>> +			       "global sig; rc = [%d]\n", rc);
> >>
> >> Are we expected to be using errorf() and friends here rather than
> >> printk()?
> > 
> > That's kind of a debate. If you'd rather get rid of the kernel message and
> > send it out through the mount api message channel instead, I can make that
> > change. But if userspace doesn't capture the message from errorf, that change
> > would lose the message altogether.
> > 
> > I kind of feel like once userspace is really making use of the message channel,
> > we could go back and selectively change printks to the message channel where it
> > makes sense.
> 
> Ok, without any further input I'll send V2 w/ the whitespace and double semicolon
> fixes, and leave the printks etc in place for the reasons stated above.

Apologies. I agree that this was the correct approach for v2.

> If anyone wants to redirect pritnks to the API message channel, that can always
> be done as a followup patch. ecryptfs would certainly not be an outlier if it
> leaves the printks in place for now.

Thanks for that info. I'll review v2 shortly.

Tyler

> 
> -Eric
> 

  reply	other threads:[~2024-10-30 21:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07 15:27 [PATCH 0/2] ecryptfs: convert to the new mount API Eric Sandeen
2024-10-07 15:27 ` [PATCH 1/2] ecryptfs: Factor out mount option validation Eric Sandeen
2024-10-21  6:06   ` Tyler Hicks
2024-10-07 15:27 ` [PATCH 2/2] ecryptfs: Convert ecryptfs to use the new mount API Eric Sandeen
2024-10-21  6:09   ` Tyler Hicks
2024-10-21 14:07     ` Eric Sandeen
2024-10-28 14:22       ` Eric Sandeen
2024-10-30 21:08         ` Tyler Hicks [this message]
2024-10-16 15:46 ` [PATCH 0/2] ecryptfs: convert to " Eric Sandeen

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=ZyKgVY8ekrJEKLZl@redbud \
    --to=code@tyhicks.com \
    --cc=brauner@kernel.org \
    --cc=ecryptfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.