MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: TAKADA Yoshihito <takada@mbf.nifty.com>
Cc: mingo@elte.hu, tglx@linutronix.de, linux-kernel@vger.kernel.org,
       stable@kernel.org
Subject: Re: [PATCH] x86 ptrace: fix PTRACE_GETFPXREGS error
In-Reply-To: TAKADA Yoshihito's message of  Thursday, 3 July 2008 10:58:58 +0900 <20080703.105858.193690507.takada@mbf.nifty.com>
References: <20080630.134445.193700135.takada@mbf.nifty.com>
	<20080630210241.93738154077@magilla.localdomain>
	<20080703.105858.193690507.takada@mbf.nifty.com>
Message-Id: <20080703030001.4CC2215416D@magilla.localdomain>
Date: Wed,  2 Jul 2008 20:00:01 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1569
Lines: 33

> Hi. Thanks for your right patch.
> BTW, are FXSAVE and FXRSTOR instructions device?
> Is it right to return ENODEV?
> I think I had bettor return EXIO or ENOTSUP. 
> If it discussed, tell me URL of tree at lkml.org.

I don't think it was discussed.  It's clearly documented in the
linux/regset.h kerneldoc comments that define the interface.  
I don't recall any feedback about error codes when that went in.

Device, eh, whatever.  We're not going to add a new code that means
precisely "this user_regset refers to hardware not present", that would be
silly.  It's going to be chosen by some analogy with the original use of
some existing code.  ENXIO is fine too.  I probably chose ENODEV over ENXIO
just because it's easier to read the name and remember what it might mean
(and it's easier to type).  

All that really matters is that for the particular case of user_regset
functions, there be clearly specified one errno code that means "all's well,
but this supported hardware is not here".  Then callers know to check for
that, and any other error code value is potentially an unexpected sort of
error.  I see nothing wrong with ENODEV.  The only thing wrong with ENXIO is
trying to type it correctly twice in a row.  ENOTSUP does not seem like a
good fit as an analogy to its other specified uses.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/