From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751507AbdE3Kp0 (ORCPT ); Tue, 30 May 2017 06:45:26 -0400 Received: from ozlabs.org ([103.22.144.67]:41819 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbdE3KpS (ORCPT ); Tue, 30 May 2017 06:45:18 -0400 From: Michael Ellerman To: Mahesh Jagannath Salgaonkar , Michal Suchanek , Benjamin Herrenschmidt , Paul Mackerras , Hari Bathini , Andrew Morton , Colin Ian King , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] powerpc/fadump: return error when fadump registration fails In-Reply-To: References: <20170527154615.29684-1-msuchanek@suse.de> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Tue, 30 May 2017 20:45:13 +1000 Message-ID: <87bmqa62ti.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mahesh Jagannath Salgaonkar writes: > On 05/27/2017 09:16 PM, Michal Suchanek wrote: >> - log an error message when registration fails and no error code listed >> in the switch is returned >> - translate the hv error code to posix error code and return it from >> fw_register >> - return the posix error code from fw_register to the process writing >> to sysfs >> - return EEXIST on re-registration >> - return success on deregistration when fadump is not registered >> - return ENODEV when no memory is reserved for fadump > > Why do we need this ? Because that's how we do error handling. > Userspace can always read back the fadump registration status from > /sys/kernel/fadump_registered (after echo 1 to it) to find out > whether fadump registration succeeded or not. That's a terrible API. If we followed that example, open() wouldn't return a value, you'd have to do another syscall to check if it worked. I'd appreciate if someone could test this and give me a Tested-by. cheers