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
>
