From: Florian Mickler <florian@mickler.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org,
Randy Dunlap <rdunlap@xenotime.net>,
"John W. Linville" <linville@tuxdriver.com>,
Alan Jenkins <alan-jenkins@tuffmail.co.uk>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [PATCH 1/2] Document the rfkill sysfs ABI
Date: Sun, 21 Feb 2010 12:21:55 +0100 [thread overview]
Message-ID: <20100221122155.7b163b55@schatten.dmk.lab> (raw)
In-Reply-To: <1266746930.18491.1.camel@violet>
On Sun, 21 Feb 2010 11:08:50 +0100
Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johannes,
>
> > > This moves sysfs ABI info from Documentation/rfkill.txt to the
> > > ABI subfolder and reformats it.
> > >
> > > Signed-off-by: Florian Mickler <florian@mickler.org>
> >
> > This is fine with me.
>
> we have to be careful here. Some of these sysfs details needs to be
> deprecated and removed. Applications should use /dev/rfkill actually.
>
> Regards
>
> Marcel
>
There are three different categories:
Documentation/ABI/stable
Documentation/ABI/obsolete
Documentation/ABI/testing
Quoting from the ABI/README:
> The different levels of stability are:
>
> stable/
> This directory documents the interfaces that the developer has
> defined to be stable. Userspace programs are free to use these
> interfaces with no restrictions, and backward compatibility for
> them will be guaranteed for at least 2 years. Most interfaces
> (like syscalls) are expected to never change and always be
> available.
>
> testing/
> This directory documents interfaces that are felt to be stable,
> as the main development of this interface has been completed.
> The interface can be changed to add new features, but the
> current interface will not break by doing this, unless grave
> errors or security problems are found in them. Userspace
> programs can start to rely on these interfaces, but they must be
> aware of changes that can occur before these interfaces move to
> be marked stable. Programs that use these interfaces are
> strongly encouraged to add their name to the description of
> these interfaces, so that the kernel developers can easily
> notify them if any changes occur (see the description of the
> layout of the files below for details on how to do this.)
>
> obsolete/
> This directory documents interfaces that are still remaining in
> the kernel, but are marked to be removed at some later point in
> time. The description of the interface will document the reason
> why it is obsolete and when it can be expected to be removed.
> The file Documentation/feature-removal-schedule.txt may describe
> some of these interfaces, giving a schedule for when they will
> be removed.
>
> removed/
> This directory contains a list of the old interfaces that have
> been removed from the kernel.
>
So the question is: are the state and claim file deprecated or obsolete?
If they are considered obsolete I presume it would be ok, to put this
part of the ABI description into the obsolete/ subfolder.
And should they be obsolete, should there be a new file ("blocked",
"state2.0",whatever,...) which exposes all possible states? I assume it
do be handy for scripted access to the rfkill device.
cheers,
Flo
next prev parent reply other threads:[~2010-02-21 11:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-20 21:40 [PATCH 0/2] Document and enhance rfkill sysfs abi florian
2010-02-20 21:40 ` [PATCH 1/2] Document the rfkill sysfs ABI florian
2010-02-20 22:19 ` Johannes Berg
2010-02-21 10:08 ` Marcel Holtmann
2010-02-21 11:21 ` Florian Mickler [this message]
2010-02-22 15:00 ` John W. Linville
2010-02-22 15:17 ` Johannes Berg
2010-02-22 18:16 ` Marcel Holtmann
2010-02-24 11:05 ` [PATCH v2 0/2] Document and enhance rfkill sysfs abi florian
2010-02-24 11:05 ` [PATCH v2 1/2] Document the rfkill sysfs ABI florian
2010-02-24 11:05 ` [PATCH v2 2/2] enhance sysfs rfkill interface florian
2010-02-25 23:35 ` Henrique de Moraes Holschuh
2010-02-26 11:01 ` florian
2010-02-26 11:01 ` [PATCH v3] " florian
2010-02-26 13:11 ` [PATCH v2 2/2] " Marcel Holtmann
2010-02-26 16:32 ` Florian Mickler
2010-02-20 21:40 ` [PATCH 2/2] enhance /sys/class/rfkill/<rfkill>/state interface florian
2010-02-20 22:14 ` Johannes Berg
2010-02-20 23:07 ` Florian Mickler
2010-02-21 10:07 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2010-03-12 18:03 [PATCH 0/2] rfkill sysfs ABI florian
2010-03-12 18:03 ` [PATCH 1/2] Document the " florian
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=20100221122155.7b163b55@schatten.dmk.lab \
--to=florian@mickler.org \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=gregkh@suse.de \
--cc=johannes@sipsolutions.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcel@holtmann.org \
--cc=rdunlap@xenotime.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.