From: Greg KH <greg@kroah.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Theodore Tso <tytso@mit.edu>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jens Axboe <jens.axboe@oracle.com>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: Correct SuS compliance for open of large file without options
Date: Thu, 27 Sep 2007 10:59:17 -0700 [thread overview]
Message-ID: <20070927175917.GB8339@kroah.com> (raw)
In-Reply-To: <20070927102343.1a113ccc.akpm@linux-foundation.org>
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
next prev parent reply other threads:[~2007-09-27 18:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-27 13:29 Alan Cox
2007-09-27 14:01 ` Arjan van de Ven
2007-09-27 14:19 ` Alan Cox
2007-09-27 14:35 ` Jens Axboe
2007-09-27 14:44 ` Alan Cox
2007-09-27 15:08 ` Jens Axboe
2007-09-27 15:19 ` Alan Cox
2007-09-27 15:59 ` Theodore Tso
2007-09-27 17:23 ` Andrew Morton
2007-09-27 17:59 ` Greg KH [this message]
2007-09-27 18:37 ` Theodore Tso
2007-09-27 18:45 ` Matthew Wilcox
2007-09-27 21:34 ` Greg KH
2007-09-27 22:27 ` Kyle Moffett
2007-09-27 23:11 ` Greg KH
2007-09-27 23:19 ` Theodore Tso
2007-09-27 23:28 ` Matthew Wilcox
2007-09-28 2:21 ` Theodore Tso
2007-09-28 3:22 ` Greg KH
2007-09-28 3:21 ` Greg KH
2007-09-27 23:41 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070927175917.GB8339@kroah.com \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome