Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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?
>
> How about a mount option? That way people can test without a reboot:
>
> mount -o remount,deprecated={yes,no} /sys
Unfortunatly, due to the way sysfs and kobjects are built up, this is
pretty impossible to do.
sorry,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 sysfs > files/directories to disappear, even if CONFIG_SYS_DEPRECATED is > defined, via a boot-time parameter? As discussed in the kernel summit talk about this very topic, Kay is working on a patch to do just that :) > Many people and distros are > likely to keep CONFIG_SYS_DEPRECATED defined just our of paranoia that > things might break. Doing a quick google, I note that Fedora has been > going back and forth of turning it off, watching things break, and > then turning it back on. The latest time, the changelog said: > > * Fri Jan 26 23:00:00 2007 Bill Nottingham > > - turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh* > > (and I've checked, Fedora's CVS still has CONFIG_SYSFS_DEPRECATED > defined; it's not just Debian at fault here.) That's odd, SuSE and Gentoo have been working for quite some time just fine with that option disabled :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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?
>
> How about a mount option? That way people can test without a reboot:
>
> mount -o remount,deprecated={yes,no} /sys
It would be nice if that would be easy to make work, but the problem
is that remounting /sysfs doesn't change the entries in the sysfs tree
that have already been made in the tree. We could do something such
as creating an sysfs_create_link_deprecated() call which created a
kobject with a new flag indicating it's deprecated, so it could be
filtered out dynamically when /sys is remounted, or when some file
such as /sys/kernel/deprecated_sysfs_files has "0" or "1" written to
it.
The question is whether it's worth it, since we'd have to bloat the
kobject structure by 4 bytes (it currently doesn't have a flags field
from which we could borrow a bit), or whether it's OK just to make the
user reboot. (I do agree it would be nicer if the user didn't have to
reboot, but most of the time they will need to test the initrd and
init scripts anyway.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 about two releases later > > > saying it broke app foo. > > > > Strange since we've spent years changing error values and getting them > > right in the past. > > I doubt there any apps which are going to specifically check for EFBIG > and do soemthing different if they get EOVERFLOW instead. If it was > something like EAGAIN or EPERM, I'd be more concerned, but EFBIG > vs. EOVERFLOW? C'mon! It's not checking EFBIG vs EOVERFLOW, it's checking one and not the other. But I digress, not trying to NAK the patch, just voicing my opinion on the matter. It's not something you can easily test and claim good app coverage, though. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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:
mount -o remount,deprecated={yes,no} /sys
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 OK to use --- is why >>> I call the sysfs interface "an open pit". >> >> And because of the original design mistakes, we have only been able to >> change things for the better in a slow manner. We have had userspace >> programs fixed up for _years_ before we are able to make the corresponding >> changes in the kernel, so as to not break the distros that are slow to >> upgrade packages and kernels (like Debian.) > > Hey! No poking fingers at Debian here; it's been *MUCH* improved lately. Heh, sorry, but Debian in the past had a lot of problems in this area. It's good to know that this is no longer a issue :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 is defined, via a boot-time parameter? Many people and distros are likely to keep CONFIG_SYS_DEPRECATED defined just our of paranoia that things might break. Doing a quick google, I note that Fedora has been going back and forth of turning it off, watching things break, and then turning it back on. The latest time, the changelog said: * Fri Jan 26 23:00:00 2007 Bill Nottingham - turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh* (and I've checked, Fedora's CVS still has CONFIG_SYSFS_DEPRECATED defined; it's not just Debian at fault here.) So having a boot-time parameter would make it much easier for application programmers (who run distro kernels and who are unlikely to want to compile their own custom kernel) to test to see what breaks without CONFIG_SYS_DEPRECATED. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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". And because of the original design mistakes, we have only been able to change things for the better in a slow manner. We have had userspace programs fixed up for _years_ before we are able to make the corresponding changes in the kernel, so as to not break the distros that are slow to upgrade packages and kernels (like Debian.) Hey! No poking fingers at Debian here; it's been *MUCH* improved lately. I far more frequently have problems with boxes still running some ancient release of RHEL-4 or something than I do with those running Debian stable (virtually always the latest Debian stable). Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 these data structures so that no > > breakage occurs. > > I've read it; the question is whether every single application > programmer or system shell script programmer who writes code my system > depends upon has read it this document buried in the kernel sources, > or whether things will break spectacularly --- one of those things > that leaves me in suspense each time I update the kernel. Ok, how then should I advertise this better? What can we do better to help userspace programmers out in this regard? > 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_. Me and Pat Mochel sat in that talk and instantly had an "oh shit" moment when it came to the in-kernel usage of sysfs and the driver model. Ever since then, I have been working to change the code to make it better. With the exception of the recent help from Kay, I am the only one doing this as Pat has been gone for a few years and isn't coming back. > 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". We (well, Kay mostly) have also been working on fixing this all up to make it much harder to use sysfs incorrectly. We will have a single device tree (well, almost a single tree, it's getting there), so that all of the information is only in one place, and you don't have to go searching all over the place for it. That is a direct improvement over the old design where somethings were in one place, and others in another. And because of the original design mistakes, we have only been able to change things for the better in a slow manner. We have had userspace programs fixed up for _years_ before we are able to make the corresponding changes in the kernel, so as to not break the distros that are slow to upgrade packages and kernels (like Debian.) If I had my druthers, we could instantly put some patches into the tree to fix up the sysfs "mess" once and for all, creating a unified, single tree, with only a handful of needed symlinks to be able to categorize certain things. We have the patches (Kay wrote them over a year ago), and userspace programs work just fine with them (udev and HAL), but because we need to support 5 year old userspace programs running tomorrows kernel, we must take very tiny, slow steps to get there. And yes, sysfs has slowly changed over the years, and along the way we have kept things working, with only very minor problems. You have no idea the crazy mismatch of kernels and userspace programs we have had to deal with. And it will continue to change, slowly, until we reach the unified-tree goal, and all of those old crufty userspace programs are dead and buried (I got a bug report about RHEL's udev version 039 just yesterday.) So you can't have it both ways. You can't complain that sysfs isn't stable, and isn't "properly userspace friendly" at the same time. In order to fix the issues, we have to change it, and do it slowly, because I don't want to break some distros that can't keep up with the others. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 directories/symlinks are OK to use, and some are > NOT OK to use --- is why I call the sysfs interface "an open pit". > Sure, if you have the map to the minefield, a minefield is perfectly > safe when you know what to avoid. But is that the best way to > construct a path/interface for an application programmer to get from > point A to point B? Maybe, maybe not. I agree with your criticism of sysfs (indeed, I think I've made many of them before in somewhat stronger language), but do you have a suggestion as to an interface that would be harder to misuse? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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; the question is whether every single application programmer or system shell script programmer who writes code my system depends upon has read it this document buried in the kernel sources, or whether things will break spectacularly --- one of those things that leaves me in suspense each time I update the kernel. 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 directories/symlinks are OK to use, and some are NOT OK to use --- is why I call the sysfs interface "an open pit". Sure, if you have the map to the minefield, a minefield is perfectly safe when you know what to avoid. But is that the best way to construct a path/interface for an application programmer to get from point A to point B? Maybe, maybe not. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 is continually breaking stuff, not spec compliance > > > corrections that don't break things but move us into compliance with the > > > standard > > > > I've got to agree with Alan, the sysfs/udev breakages that we've done > > are far more significant I'm sorry, have I missed a breakage lately? I don't know of one in over a year that has not been fixed. Do you? > > , and the fact that we continue to expose internal data structures > > via sysfs is a gaping open pit is far more likely to cause any kind > > of problems than changing an error return. 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. And if you want to propose some other kind of alternative to exporting this kind of _needed_ information to userspace, in a simple and easy-to-use manner, please do so. Until then, stop complaining unnecessarily. > Funny you should mention that. I was staring in astonishment at the > pending sysfs patch pile last night. Forty syfs patches and twenty-odd > patches against driver core and the kobject layer. And _none_ of them change any userspace interaction. Well, ok, the block one can, if the CONFIG_SYSFS_DEPRECATED is disabled, but that's not going into 2.6.24 as I stated in my status report. > That's a huge amount of churn for a core piece of kernel infrastructure > which has been there for four or five years. Not a good sign. I mean, > it's not as if, say, the CPU scheduler guys keep on rewriting all their > junk. The sysfs changes are almost all due to the need for the containers/vserver/whatever people to be able to see different views of sysfs depending on the user/container. That is a radical change that was never designed for in the beginning. The other changes that Tejun has made have actually cleaned up the code and made it simpler to use and more robust and fixed bugs. Same thing goes for the driver core changes. We are cleaning things up, fixing bugs that have been found when the driver core has been used in ways that we never originally anticipated. We are also trying to make it easier to use, and simpler overall, as the original design was quite half-hazard at best in numerous places (kset/subsystem/ktype anyone?) So these aren't being done just because we like to break things, we are trying to make things better, and fix real bugs here. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 things that people will complain about two releases later > > > saying it broke app foo. > > > > Strange since we've spent years changing error values and getting them > > right in the past. > > I doubt there any apps which are going to specifically check for EFBIG > and do soemthing different if they get EOVERFLOW instead. If it was > something like EAGAIN or EPERM, I'd be more concerned, but EFBIG > vs. EOVERFLOW? C'mon! Yeah. There's no correct answer here (apart from "get it right the first time"). There are risks either way, and it _is_ a bug. Bummer. > > There are real things to worry about - sysfs, sysfs, sysfs, ... and all > > the other crap which is continually breaking stuff, not spec compliance > > corrections that don't break things but move us into compliance with the > > standard > > I've got to agree with Alan, the sysfs/udev breakages that we've done > are far more significant, and the fact that we continue to expose > internal data structures via sysfs is a gaping open pit is far more > likely to cause any kind of problems than changing an error return. Funny you should mention that. I was staring in astonishment at the pending sysfs patch pile last night. Forty syfs patches and twenty-odd patches against driver core and the kobject layer. That's a huge amount of churn for a core piece of kernel infrastructure which has been there for four or five years. Not a good sign. I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. oh, wait.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 app foo. > > Strange since we've spent years changing error values and getting them > right in the past. I doubt there any apps which are going to specifically check for EFBIG and do soemthing different if they get EOVERFLOW instead. If it was something like EAGAIN or EPERM, I'd be more concerned, but EFBIG vs. EOVERFLOW? C'mon! > There are real things to worry about - sysfs, sysfs, sysfs, ... and all > the other crap which is continually breaking stuff, not spec compliance > corrections that don't break things but move us into compliance with the > standard I've got to agree with Alan, the sysfs/udev breakages that we've done are far more significant, and the fact that we continue to expose internal data structures via sysfs is a gaping open pit is far more likely to cause any kind of problems than changing an error return. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
> 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 and getting them right in the past. There are real things to worry about - sysfs, sysfs, sysfs, ... and all the other crap which is continually breaking stuff, not spec compliance corrections that don't break things but move us into compliance with the standard Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 at them if they > > complain is unlikely to impress them. > > And our existing behaviour may well break correctly written > portable applications, and is incorrect as well. It's been that way for ages, how likely do you think that is? Not very, is my guess. Existing practice trumps standard description in my book. > Testing so far says it doesn't break anything, which is no suprise if you > apply about ten braincells to the case under consideration. 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. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
> > 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 impress them. And our existing behaviour may well break correctly written portable applications, and is incorrect as well. Testing so far says it doesn't break anything, which is no suprise if you apply about ten braincells to the case under consideration. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 EOVERFLOW for this as noted by Michael (Bug > > > 7253) > > isn't this an ABI change? > > 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 impress them. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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) > isn't this an ABI change? 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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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) isn't this an ABI change? 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. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 EOVERFLOW for this as noted by Michael (Bug 7253) isn't this an ABI change? 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 impress them. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 impress them. And our existing behaviour may well break correctly written portable applications, and is incorrect as well. Testing so far says it doesn't break anything, which is no suprise if you apply about ten braincells to the case under consideration. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 at them if they complain is unlikely to impress them. And our existing behaviour may well break correctly written portable applications, and is incorrect as well. It's been that way for ages, how likely do you think that is? Not very, is my guess. Existing practice trumps standard description in my book. Testing so far says it doesn't break anything, which is no suprise if you apply about ten braincells to the case under consideration. 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. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 and getting them right in the past. There are real things to worry about - sysfs, sysfs, sysfs, ... and all the other crap which is continually breaking stuff, not spec compliance corrections that don't break things but move us into compliance with the standard Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 app foo. Strange since we've spent years changing error values and getting them right in the past. I doubt there any apps which are going to specifically check for EFBIG and do soemthing different if they get EOVERFLOW instead. If it was something like EAGAIN or EPERM, I'd be more concerned, but EFBIG vs. EOVERFLOW? C'mon! There are real things to worry about - sysfs, sysfs, sysfs, ... and all the other crap which is continually breaking stuff, not spec compliance corrections that don't break things but move us into compliance with the standard I've got to agree with Alan, the sysfs/udev breakages that we've done are far more significant, and the fact that we continue to expose internal data structures via sysfs is a gaping open pit is far more likely to cause any kind of problems than changing an error return. - Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 things that people will complain about two releases later saying it broke app foo. Strange since we've spent years changing error values and getting them right in the past. I doubt there any apps which are going to specifically check for EFBIG and do soemthing different if they get EOVERFLOW instead. If it was something like EAGAIN or EPERM, I'd be more concerned, but EFBIG vs. EOVERFLOW? C'mon! Yeah. There's no correct answer here (apart from get it right the first time). There are risks either way, and it _is_ a bug. Bummer. There are real things to worry about - sysfs, sysfs, sysfs, ... and all the other crap which is continually breaking stuff, not spec compliance corrections that don't break things but move us into compliance with the standard I've got to agree with Alan, the sysfs/udev breakages that we've done are far more significant, and the fact that we continue to expose internal data structures via sysfs is a gaping open pit is far more likely to cause any kind of problems than changing an error return. Funny you should mention that. I was staring in astonishment at the pending sysfs patch pile last night. Forty syfs patches and twenty-odd patches against driver core and the kobject layer. That's a huge amount of churn for a core piece of kernel infrastructure which has been there for four or five years. Not a good sign. I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. oh, wait.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 is continually breaking stuff, not spec compliance corrections that don't break things but move us into compliance with the standard I've got to agree with Alan, the sysfs/udev breakages that we've done are far more significant I'm sorry, have I missed a breakage lately? I don't know of one in over a year that has not been fixed. Do you? , and the fact that we continue to expose internal data structures via sysfs is a gaping open pit is far more likely to cause any kind of problems than changing an error return. 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. And if you want to propose some other kind of alternative to exporting this kind of _needed_ information to userspace, in a simple and easy-to-use manner, please do so. Until then, stop complaining unnecessarily. Funny you should mention that. I was staring in astonishment at the pending sysfs patch pile last night. Forty syfs patches and twenty-odd patches against driver core and the kobject layer. And _none_ of them change any userspace interaction. Well, ok, the block one can, if the CONFIG_SYSFS_DEPRECATED is disabled, but that's not going into 2.6.24 as I stated in my status report. That's a huge amount of churn for a core piece of kernel infrastructure which has been there for four or five years. Not a good sign. I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. The sysfs changes are almost all due to the need for the containers/vserver/whatever people to be able to see different views of sysfs depending on the user/container. That is a radical change that was never designed for in the beginning. The other changes that Tejun has made have actually cleaned up the code and made it simpler to use and more robust and fixed bugs. Same thing goes for the driver core changes. We are cleaning things up, fixing bugs that have been found when the driver core has been used in ways that we never originally anticipated. We are also trying to make it easier to use, and simpler overall, as the original design was quite half-hazard at best in numerous places (kset/subsystem/ktype anyone?) So these aren't being done just because we like to break things, we are trying to make things better, and fix real bugs here. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 directories/symlinks are OK to use, and some are NOT OK to use --- is why I call the sysfs interface an open pit. Sure, if you have the map to the minefield, a minefield is perfectly safe when you know what to avoid. But is that the best way to construct a path/interface for an application programmer to get from point A to point B? Maybe, maybe not. I agree with your criticism of sysfs (indeed, I think I've made many of them before in somewhat stronger language), but do you have a suggestion as to an interface that would be harder to misuse? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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; the question is whether every single application programmer or system shell script programmer who writes code my system depends upon has read it this document buried in the kernel sources, or whether things will break spectacularly --- one of those things that leaves me in suspense each time I update the kernel. 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 directories/symlinks are OK to use, and some are NOT OK to use --- is why I call the sysfs interface an open pit. Sure, if you have the map to the minefield, a minefield is perfectly safe when you know what to avoid. But is that the best way to construct a path/interface for an application programmer to get from point A to point B? Maybe, maybe not. - Ted - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 these data structures so that no breakage occurs. I've read it; the question is whether every single application programmer or system shell script programmer who writes code my system depends upon has read it this document buried in the kernel sources, or whether things will break spectacularly --- one of those things that leaves me in suspense each time I update the kernel. Ok, how then should I advertise this better? What can we do better to help userspace programmers out in this regard? 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_. Me and Pat Mochel sat in that talk and instantly had an oh shit moment when it came to the in-kernel usage of sysfs and the driver model. Ever since then, I have been working to change the code to make it better. With the exception of the recent help from Kay, I am the only one doing this as Pat has been gone for a few years and isn't coming back. 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. We (well, Kay mostly) have also been working on fixing this all up to make it much harder to use sysfs incorrectly. We will have a single device tree (well, almost a single tree, it's getting there), so that all of the information is only in one place, and you don't have to go searching all over the place for it. That is a direct improvement over the old design where somethings were in one place, and others in another. And because of the original design mistakes, we have only been able to change things for the better in a slow manner. We have had userspace programs fixed up for _years_ before we are able to make the corresponding changes in the kernel, so as to not break the distros that are slow to upgrade packages and kernels (like Debian.) If I had my druthers, we could instantly put some patches into the tree to fix up the sysfs mess once and for all, creating a unified, single tree, with only a handful of needed symlinks to be able to categorize certain things. We have the patches (Kay wrote them over a year ago), and userspace programs work just fine with them (udev and HAL), but because we need to support 5 year old userspace programs running tomorrows kernel, we must take very tiny, slow steps to get there. And yes, sysfs has slowly changed over the years, and along the way we have kept things working, with only very minor problems. You have no idea the crazy mismatch of kernels and userspace programs we have had to deal with. And it will continue to change, slowly, until we reach the unified-tree goal, and all of those old crufty userspace programs are dead and buried (I got a bug report about RHEL's udev version 039 just yesterday.) So you can't have it both ways. You can't complain that sysfs isn't stable, and isn't properly userspace friendly at the same time. In order to fix the issues, we have to change it, and do it slowly, because I don't want to break some distros that can't keep up with the others. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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. And because of the original design mistakes, we have only been able to change things for the better in a slow manner. We have had userspace programs fixed up for _years_ before we are able to make the corresponding changes in the kernel, so as to not break the distros that are slow to upgrade packages and kernels (like Debian.) Hey! No poking fingers at Debian here; it's been *MUCH* improved lately. I far more frequently have problems with boxes still running some ancient release of RHEL-4 or something than I do with those running Debian stable (virtually always the latest Debian stable). Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 OK to use --- is why I call the sysfs interface an open pit. And because of the original design mistakes, we have only been able to change things for the better in a slow manner. We have had userspace programs fixed up for _years_ before we are able to make the corresponding changes in the kernel, so as to not break the distros that are slow to upgrade packages and kernels (like Debian.) Hey! No poking fingers at Debian here; it's been *MUCH* improved lately. Heh, sorry, but Debian in the past had a lot of problems in this area. It's good to know that this is no longer a issue :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 is
defined, via a boot-time parameter? Many people and distros are
likely to keep CONFIG_SYS_DEPRECATED defined just our of paranoia that
things might break. Doing a quick google, I note that Fedora has been
going back and forth of turning it off, watching things break, and
then turning it back on. The latest time, the changelog said:
* Fri Jan 26 23:00:00 2007 Bill Nottingham notting{%}redhat{*}com
- turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh*
(and I've checked, Fedora's CVS still has CONFIG_SYSFS_DEPRECATED
defined; it's not just Debian at fault here.)
So having a boot-time parameter would make it much easier for
application programmers (who run distro kernels and who are unlikely
to want to compile their own custom kernel) to test to see what breaks
without CONFIG_SYS_DEPRECATED.
- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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:
mount -o remount,deprecated={yes,no} /sys
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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?
How about a mount option? That way people can test without a reboot:
mount -o remount,deprecated={yes,no} /sys
It would be nice if that would be easy to make work, but the problem
is that remounting /sysfs doesn't change the entries in the sysfs tree
that have already been made in the tree. We could do something such
as creating an sysfs_create_link_deprecated() call which created a
kobject with a new flag indicating it's deprecated, so it could be
filtered out dynamically when /sys is remounted, or when some file
such as /sys/kernel/deprecated_sysfs_files has 0 or 1 written to
it.
The question is whether it's worth it, since we'd have to bloat the
kobject structure by 4 bytes (it currently doesn't have a flags field
from which we could borrow a bit), or whether it's OK just to make the
user reboot. (I do agree it would be nicer if the user didn't have to
reboot, but most of the time they will need to test the initrd and
init scripts anyway.
- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 about two releases later saying it broke app foo. Strange since we've spent years changing error values and getting them right in the past. I doubt there any apps which are going to specifically check for EFBIG and do soemthing different if they get EOVERFLOW instead. If it was something like EAGAIN or EPERM, I'd be more concerned, but EFBIG vs. EOVERFLOW? C'mon! It's not checking EFBIG vs EOVERFLOW, it's checking one and not the other. But I digress, not trying to NAK the patch, just voicing my opinion on the matter. It's not something you can easily test and claim good app coverage, though. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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?
How about a mount option? That way people can test without a reboot:
mount -o remount,deprecated={yes,no} /sys
Unfortunatly, due to the way sysfs and kobjects are built up, this is
pretty impossible to do.
sorry,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: Correct SuS compliance for open of large file without options
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 sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
defined, via a boot-time parameter?
As discussed in the kernel summit talk about this very topic, Kay is
working on a patch to do just that :)
Many people and distros are
likely to keep CONFIG_SYS_DEPRECATED defined just our of paranoia that
things might break. Doing a quick google, I note that Fedora has been
going back and forth of turning it off, watching things break, and
then turning it back on. The latest time, the changelog said:
* Fri Jan 26 23:00:00 2007 Bill Nottingham notting{%}redhat{*}com
- turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh*
(and I've checked, Fedora's CVS still has CONFIG_SYSFS_DEPRECATED
defined; it's not just Debian at fault here.)
That's odd, SuSE and Gentoo have been working for quite some time just
fine with that option disabled :)
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
