linux-kernel - Re: [PATCH 01/61] Rules on how to use sysfs in userspace programs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070712221402.GA30182@suse.de>
Date:	Thu, 12 Jul 2007 15:14:02 -0700
From:	Greg KH <gregkh@...e.de>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH 01/61] Rules on how to use sysfs in userspace programs

On Thu, Jul 12, 2007 at 10:48:46AM +0200, Pavel Machek wrote:
> On Wed 2007-07-11 16:31:20, Greg Kroah-Hartman wrote:
> > From: Kay Sievers <kay.sievers@...y.org>
> > 
> > Here's a document to help clear things up.
> > 
> > Signed-off-by: Kay Sievers <kay.sievers@...y.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> > ---
> >  Documentation/sysfs-rules.txt |  166 +++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 166 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/sysfs-rules.txt
> > 
> > diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt
> > new file mode 100644
> > index 0000000..42861bb
> > --- /dev/null
> > +++ b/Documentation/sysfs-rules.txt
> > @@ -0,0 +1,166 @@
> > +Rules on how to access information in the Linux kernel sysfs
> > +
> > +The kernel exported sysfs exports internal kernel implementation-details
> > +and depends on internal kernel structures and layout. It is agreed upon
> > +by the kernel developers that the Linux kernel does not provide a stable
> > +internal API. As sysfs is a direct export of kernel internal
> > +structures, the sysfs interface can not provide a stable interface eighter,
> > +it may always change along with internal kernel changes.
> 
> It is also agreed upon by the kernel developers that the Linux kernel
> does have a stable user<->kernel API... so we have a small problem
> here. 

I agree, that is why we have described the proper ways to use /sys in a
manner that is acceptable to future changes in it.

> Maybe solution is to declare /sys unstable, but... perhaps /sys can
> stop mirroring internal structures? I do not think we should codify
> our failure to keep /sys stable here.

I think that /sys is to valuable to say it can just never be used by
userspace programs.  With these suggestions, do you see any problems
with any potential future changes in the layout that you can come up
with?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/