All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: Rules on how to use sysfs in userspace programs
Date: Fri, 22 Jun 2007 17:46:02 -0400	[thread overview]
Message-ID: <200706221746.03298.rob@landley.net> (raw)
In-Reply-To: <20070608203637.GA9259@kroah.com>

On Friday 08 June 2007 16:36:37 Greg KH wrote:
> Over time there have been a number of problems when sysfs has changed in
> "unexpected" ways.  Here's a document that Kay wrote a while ago that
> I'd like to add to the kernel Documentation directory to help userspace
> programmers out.
>
> Any comments or critique of this is greatly appreciated.

Still catching up from my laptop dying.

I find the explanation of /sys/subsystem almost unintelligible.  What will the 
new one actually look like?

If I want to find all block devices in the system, it looks like I should now 
look at /sys/subsystem/block.  (And "subsystem" is not a variable here but 
the actual directory name?  I presume it moved for Feng Shui reasons.)  

If I want to find char devices, where do I look?  /sys/subsystem...  char?  
class?  Is a char device now anything under /sys/subsystem that is _not_ 
in /sys/subsystem/block?  (Minus bus devices?)  Is there a specific directory 
for these?

This document is highly polluted with what NOT to do.  I'm looking for a 
clear "what SHOULD I do", and it takes some wading to find it.  (Historical 
cruft about what not to do is potentially a separate document, it's not 
useful for people learning this stuff now who weren't playing with the legacy 
mechanisms.)  The description of /sys/subsystem spends so much time talking 
about old legacy issues it never gives a clear description of the new way of 
doing things, which is theoretically what this document is about...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

  parent reply	other threads:[~2007-06-22 21:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08 20:36 Rules on how to use sysfs in userspace programs Greg KH
2007-06-09  7:42 ` Jan Engelhardt
2007-06-09 12:32 ` Alexander E. Patrakov
2007-06-09 17:27   ` Kay Sievers
2007-06-09 20:08 ` Jesper Juhl
2007-06-10 14:02 ` Theodore Tso
2007-06-10 16:56   ` Randy Dunlap
2007-06-10 20:55     ` Kay Sievers
2007-06-22 21:46 ` Rob Landley [this message]
2007-06-23 12:49   ` Kay Sievers
2007-06-24  1:31     ` Rob Landley
2007-06-24 11:03       ` Kay Sievers
2007-06-24 19:24         ` Rob Landley
2007-06-25 14:57           ` Kay Sievers
2007-06-25 18:14             ` Rob Landley

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=200706221746.03298.rob@landley.net \
    --to=rob@landley.net \
    --cc=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.