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
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
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
On Thu, Sep 27 2007, Theodore Tso 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 things that people
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 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
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 sysfs
files/directories to disappear, even if
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
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
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
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
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
> > >
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
> 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
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
> > 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
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
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
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
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
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 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 sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATED
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, Theodore Tso 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 things that people will complain
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
42 matches
Mail list logo