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.
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.
-Eric
