"The fact that we continue to expose internal data structures via sysfs is a gaping open pit [and] is far more likely to cause any kind of problems than changing an error return," Theodore Ts'o noted, responding to a thread discussing a patch to fix an error return code. Andrew Morton agreed, "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." He continued, "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." Andrew then added a humorous quip, "I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. oh, wait.."
Sysfs maintainer Greg KH replied, "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?" He noted that when sysfs is used properly from user space no breakage occurs, "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." He went on to explain that most sysfs changes are to support things like containers, requiring per-user/per-container views, something sysfs wasn't originally designed for. "These aren't being done just because we like to break things, we are trying to make things better, and fix real bugs here."
Theodore cautioned, "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_." He acknowledged the documentation, but stressed:
"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 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."
Greg asked, "Ok, how then should I advertise this better? What can we do better to help userspace programmers out in this regard?" In reference to Rusty Russell's 2003 OLS Keynote, he replied:
"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."
Greg concluded:
"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."
From: Alan Cox <alan@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 11:19 am 2007
> 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
-
From: Theodore Tso <tytso@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 11:59 am 2007
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
-
From: Andrew Morton <akpm@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 1:23 pm 2007
On Thu, 27 Sep 2007 11:59:02 -0400 Theodore Tso <tytso@mit.edu> 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..
-
From: Greg KH <greg@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 1:59 pm 2007
On Thu, Sep 27, 2007 at 10:23:43AM -0700, Andrew Morton wrote:
> On Thu, 27 Sep 2007 11:59:02 -0400 Theodore Tso <tytso@mit.edu> 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
-
From: Theodore Tso <tytso@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 2:37 pm 2007
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
-
From: Greg KH <greg@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 5:34 pm 2007
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
-
From: Theodore Tso <tytso@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 7:19 pm 2007
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
-
From: Greg KH <greg@...>
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Sep 27, 11:21 pm 2007
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
-
