From: Rob Landley <rob@landley.net>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: dougg@torque.net, James Bottomley <James.Bottomley@steeleye.com>,
linux-scsi@vger.kernel.org
Subject: Re: Some quick scsi documentation questions:
Date: Fri, 3 Aug 2007 17:39:32 -0400 [thread overview]
Message-ID: <200708031639.32343.rob@landley.net> (raw)
In-Reply-To: <46B383DE.9060408@s5r6.in-berlin.de>
On Friday 03 August 2007 2:37:02 pm Stefan Richter wrote:
> Rob Landley wrote:
> > They keep using the fact that they're exporting random kernel data as an
> > excuse for not documenting a stable subset of this as an API userspace
> > can rely on.
>
> At least sysfs-rules.txt is a start, although it contains more Don'ts
> than Dos.
I've noticed this. :)
> > This is a bug, not a feature. Linux has always had a
> > stable _USERSPACE_ API. This is exposed to userspace, and userspace is
> > expected to be able to use this. If they're exporting stuff they
> > shouldn't be exporting, then they should stop exporting it.
>
> The kernel log is exported to userspace too.
The kernel log is debug info, and nothing but debug info. You should only
ever need to look at if something bad has happened. Attempts to extract
information from it in an automated fashion during the normal operation of
the system are a bad idea, and always have been.
Sysfs _claims_ to provide information for use by userspace programs. It
claims to do so without providing a stable API. This is a contradiction in
terms.
I realize that the easy way to see what name the scsi layer assigned to the
USB key you just plugged in is dmesg | tail and then look at it a bit, but
this is a horrible workaround for the scsi layer's tendency to conflate
different classes of devices into a single arbitrarily ordered sequence, and
there are less horrible workarounds.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
next prev parent reply other threads:[~2007-08-03 21:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200707252328.28981.rob@landley.net>
[not found] ` <1185455711.3501.46.camel@localhost.localdomain>
2007-07-27 21:29 ` Some quick scsi documentation questions: Rob Landley
2007-08-02 18:41 ` Douglas Gilbert
2007-08-02 21:19 ` Stefan Richter
2007-08-03 0:55 ` Rob Landley
2007-08-03 10:43 ` Stefan Richter
2007-08-03 21:11 ` Rob Landley
2007-08-04 0:08 ` Stefan Richter
2007-08-04 0:35 ` Stefan Richter
2007-08-05 16:50 ` Douglas Gilbert
2007-08-06 16:29 ` Rob Landley
2007-08-06 18:30 ` Stefan Richter
2007-08-02 21:39 ` Stefan Richter
2007-08-03 1:12 ` Rob Landley
2007-08-03 8:15 ` Stefan Richter
2007-08-03 19:07 ` Rob Landley
2007-08-03 19:37 ` Stefan Richter
2007-08-03 21:39 ` Rob Landley [this message]
2007-08-03 0:39 ` 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=200708031639.32343.rob@landley.net \
--to=rob@landley.net \
--cc=James.Bottomley@steeleye.com \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
/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