The early LFS work that Linux uses favours EFBIG in various places. SuSv3
specifically uses EOVERFLOW for this as noted by Michael (Bug 7253)
--
[EOVERFLOW]
The named file is a regular file and the size of the file cannot be
represented correctly in an object of type off_t. We should
On Thu, 27 Sep 2007 14:29:19 +0100
Alan Cox [EMAIL PROTECTED] wrote:
The early LFS work that Linux uses favours EFBIG in various places.
SuSv3 specifically uses EOVERFLOW for this as noted by Michael (Bug
7253)
isn't this an ABI change?
What's the gain for doing this ABI change?
-
To
On Thu, 27 Sep 2007 07:01:18 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Thu, 27 Sep 2007 14:29:19 +0100
Alan Cox [EMAIL PROTECTED] wrote:
The early LFS work that Linux uses favours EFBIG in various places.
SuSv3 specifically uses EOVERFLOW for this as noted by Michael (Bug
7253)
On Thu, Sep 27 2007, Alan Cox wrote:
On Thu, 27 Sep 2007 07:01:18 -0700
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Thu, 27 Sep 2007 14:29:19 +0100
Alan Cox [EMAIL PROTECTED] wrote:
The early LFS work that Linux uses favours EFBIG in various places.
SuSv3 specifically uses
Its a change of a specific error return from the wrong error to the right
one, nothing more. Fixing the returned error gives us correct behaviour
according to the standards and other systems.
It may still break applications. Waving some standard at them if they
complain is unlikely to
On Thu, Sep 27 2007, Alan Cox wrote:
Its a change of a specific error return from the wrong error to the right
one, nothing more. Fixing the returned error gives us correct behaviour
according to the standards and other systems.
It may still break applications. Waving some standard
Well it's not my call, just seems like a really bad idea to change the
error value. You can't claim full coverage for such testing anyway, it's
one of those things that people will complain about two releases later
saying it broke app foo.
Strange since we've spent years changing error values
On Thu, Sep 27, 2007 at 04:19:12PM +0100, Alan Cox wrote:
Well it's not my call, just seems like a really bad idea to change the
error value. You can't claim full coverage for such testing anyway, it's
one of those things that people will complain about two releases later
saying it broke
On Thu, 27 Sep 2007 11:59:02 -0400 Theodore Tso [EMAIL PROTECTED] wrote:
On Thu, Sep 27, 2007 at 04:19:12PM +0100, Alan Cox wrote:
Well it's not my call, just seems like a really bad idea to change the
error value. You can't claim full coverage for such testing anyway, it's
one of those
On Thu, Sep 27, 2007 at 10:23:43AM -0700, Andrew Morton wrote:
On Thu, 27 Sep 2007 11:59:02 -0400 Theodore Tso [EMAIL PROTECTED] wrote:
On Thu, Sep 27, 2007 at 04:19:12PM +0100, Alan Cox wrote:
There are real things to worry about - sysfs, sysfs, sysfs, ... and all
the other crap which
On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
I'm reminded of Rusty's 2003 OLS Keynote, where he points out that
what's important is not making an interface easy to use, but _hard_
_to_ _misuse_. That fact that sysfs is all laid out in a directory,
but for which some
On Thu, Sep 27, 2007 at 10:59:17AM -0700, Greg KH wrote:
Come on now, I'm _very_ tired of this kind of discussion. Please go
read the documentation on how to _use_ sysfs from userspace in such a
way that you can properly access these data structures so that no
breakage occurs.
I've read it;
On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
On Thu, Sep 27, 2007 at 10:59:17AM -0700, Greg KH wrote:
Come on now, I'm _very_ tired of this kind of discussion. Please go
read the documentation on how to _use_ sysfs from userspace in such a
way that you can properly access
On Sep 27, 2007, at 17:34:45, Greg KH wrote:
On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
That fact that sysfs is all laid out in a directory, but for which
some directories/symlinks are OK to use, and some are NOT OK to
use --- is why I call the sysfs interface an open pit.
On Thu, Sep 27, 2007 at 06:27:48PM -0400, Kyle Moffett wrote:
On Sep 27, 2007, at 17:34:45, Greg KH wrote:
On Thu, Sep 27, 2007 at 02:37:42PM -0400, Theodore Tso wrote:
That fact that sysfs is all laid out in a directory, but for which some
directories/symlinks are OK to use, and some are NOT
On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
Would you accept a patch which causes the deprecated sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
defined, via a boot-time parameter?
How about a mount option? That way people can test without a reboot:
On Thu, Sep 27, 2007 at 05:28:57PM -0600, Matthew Wilcox wrote:
On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
Would you accept a patch which causes the deprecated sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
defined, via a boot-time parameter?
On Thu, Sep 27, 2007 at 05:28:57PM -0600, Matthew Wilcox wrote:
On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
Would you accept a patch which causes the deprecated sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
defined, via a boot-time parameter?
On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
On Thu, Sep 27, 2007 at 02:34:45PM -0700, Greg KH wrote:
Ok, how then should I advertise this better? What can we do better to
help userspace programmers out in this regard?
Would you accept a patch which causes the deprecated
19 matches
Mail list logo
