On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
According to Arnd, yes this is okay.
quoted
Isn't this some user/kernel api here?
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
quoted
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
quoted
According to Arnd, yes this is okay.
quoted
quoted
Isn't this some user/kernel api here?
quoted
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
quoted
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
greg k-h
From: Grant Likely <hidden> Date: 2011-10-09 22:59:53
On Fri, Oct 7, 2011 at 6:12 PM, Greg KH [off-list ref] wrote:
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks@vt.edu wrote:
quoted
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
quoted
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
quoted
According to Arnd, yes this is okay.
quoted
quoted
Isn't this some user/kernel api here?
quoted
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
quoted
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
Really? When we've only currently used approximately 2^9 of a 2^31
numberspace? I'm fine with making sure that the number doesn't show
up in the userspace headers, but it makes no sense to overload the
#defines. Particularly so in this case where it isn't feasible to
audit every driver to figure out what probe might possibly return. It
is well within the realm of possibility that existing drivers are
already returning -EAGAIN.
Besides; linux/errno.h *already* has linux-internal error codes that
do not get exported out to userspace. There is an #ifdef __KERNEL__
block around ERESTARTSYS through EIOCBRETRY which is filtered out when
exporting headers. I can't see any possible reason why we wouldn't
add Linux internal error codes here.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote:
On Fri, Oct 7, 2011 at 6:12 PM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks@vt.edu wrote:
quoted
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
quoted
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
quoted
According to Arnd, yes this is okay.
quoted
quoted
Isn't this some user/kernel api here?
quoted
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
quoted
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
Really? When we've only currently used approximately 2^9 of a 2^31
numberspace? I'm fine with making sure that the number doesn't show
up in the userspace headers, but it makes no sense to overload the
#defines. Particularly so in this case where it isn't feasible to
audit every driver to figure out what probe might possibly return. It
is well within the realm of possibility that existing drivers are
already returning -EAGAIN.
I doubt they are, but you are right, it's really hard to tell.
Besides; linux/errno.h *already* has linux-internal error codes that
do not get exported out to userspace. There is an #ifdef __KERNEL__
block around ERESTARTSYS through EIOCBRETRY which is filtered out when
exporting headers. I can't see any possible reason why we wouldn't
add Linux internal error codes here.
As long as it stays internal, that's fine, I was worried that this would
be exported to userspace.
Alan, still object to this?
greg k-h
On Sun, Oct 09, 2011 at 06:06:56PM -0700, Greg KH wrote:
On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote:
quoted
On Fri, Oct 7, 2011 at 6:12 PM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks@vt.edu wrote:
quoted
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
quoted
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
quoted
According to Arnd, yes this is okay.
quoted
quoted
Isn't this some user/kernel api here?
quoted
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
quoted
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
Really? When we've only currently used approximately 2^9 of a 2^31
numberspace? I'm fine with making sure that the number doesn't show
up in the userspace headers, but it makes no sense to overload the
#defines. Particularly so in this case where it isn't feasible to
audit every driver to figure out what probe might possibly return. It
is well within the realm of possibility that existing drivers are
already returning -EAGAIN.
I doubt they are, but you are right, it's really hard to tell.
quoted
Besides; linux/errno.h *already* has linux-internal error codes that
do not get exported out to userspace. There is an #ifdef __KERNEL__
block around ERESTARTSYS through EIOCBRETRY which is filtered out when
exporting headers. I can't see any possible reason why we wouldn't
add Linux internal error codes here.
As long as it stays internal, that's fine, I was worried that this would
be exported to userspace.
Alan, still object to this?
I hope no one has objections to use EPROBE_DEFER
-M
From: Grant Likely <hidden> Date: 2011-10-13 04:10:20
On Wed, Oct 12, 2011 at 11:48:23AM +0530, G, Manjunath Kondaiah wrote:
On Sun, Oct 09, 2011 at 06:06:56PM -0700, Greg KH wrote:
quoted
On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote:
quoted
On Fri, Oct 7, 2011 at 6:12 PM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks@vt.edu wrote:
quoted
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
quoted
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH [off-list ref] wrote:
quoted
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
quoted
quoted
quoted
+#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this?
quoted
According to Arnd, yes this is okay.
quoted
quoted
Isn't this some user/kernel api here?
quoted
quoted
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
quoted
overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
Really? When we've only currently used approximately 2^9 of a 2^31
numberspace? I'm fine with making sure that the number doesn't show
up in the userspace headers, but it makes no sense to overload the
#defines. Particularly so in this case where it isn't feasible to
audit every driver to figure out what probe might possibly return. It
is well within the realm of possibility that existing drivers are
already returning -EAGAIN.
I doubt they are, but you are right, it's really hard to tell.
quoted
Besides; linux/errno.h *already* has linux-internal error codes that
do not get exported out to userspace. There is an #ifdef __KERNEL__
block around ERESTARTSYS through EIOCBRETRY which is filtered out when
exporting headers. I can't see any possible reason why we wouldn't
add Linux internal error codes here.
As long as it stays internal, that's fine, I was worried that this would
be exported to userspace.
Alan, still object to this?
I hope no one has objections to use EPROBE_DEFER
I say go with that value. If Alan still objects, then he will speak up.
g.