Mailing List Archive

On Thu, 27 Sep 2007 14:29:19 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 27 Sep 2007 07:01:18 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

> On Thu, 27 Sep 2007 14:29:19 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, Sep 27 2007, Alan Cox wrote:
> On Thu, 27 Sep 2007 07:01:18 -0700
> Arjan van de Ven <arjan@infradead.org> wrote:
>
> > On Thu, 27 Sep 2007 14:29:19 +0100
> > Alan Cox <alan@lxorguk.ukuu.org.uk> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> > 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/