From: Mike Anderson <andmike@us.ibm.com>
To: Willem Riede <wrlk@riede.org>
Cc: Kai Makisara <Kai.Makisara@kolumbus.fi>,
linux-scsi@vger.kernel.org, Matt_Domsch@Dell.com,
Douglas Gilbert <dougg@torque.net>,
mochel@osdl.org
Subject: Re: [PATCH / RFC] osst, st, sg sysfs removes
Date: Sun, 12 Jan 2003 11:59:01 -0800 [thread overview]
Message-ID: <20030112195901.GC1414@beaverton.ibm.com> (raw)
In-Reply-To: <20030111154802.GS1378@linnie.riede.org>
Willem Riede [wrlk@riede.org] wrote:
> > Looks OK to me (at least the st part). I have been planning to export some
> > settings in the directories this patch removes but it has to wait until
> > corresponding entries can be created into the (currently non-existent)
> > char tree.
> >
> > While looking at the sysfs/bus/scsi tree after this patch, I noticed that
> > all devices currently get linked to the sd driver:
> >
This is a bug see previous response to Kai / this thread.
> So from that analogy, I take it, that /char should contain st[0-N], osst[0-M]
> and sg[0-L], with the mode and {non}rewind variants for tapes as appropriate,
> agreed?
>
> Each directory should then have the old files kdev, name, power and type that
> existed before? Plus whatever extra files Kai, Doug and I feel the user might
> be interested in and that in 2.4 one might find in /proc somewehere?
Yes, I would believe that /char would be modeled after block and
contained that special nodes that tape devices need as you describe.
If /char follows the model of block by creating a back link to the char
device like (/sysfs/bus/scsi/devices/0:0:0:0/char) than there will be
a issue with sg and other char devices registering on the same device.
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2003-01-12 19:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-09 22:21 [PATCH / RFC] osst, st, sg sysfs removes Mike Anderson
2003-01-11 12:25 ` Kai Makisara
2003-01-11 15:48 ` Willem Riede
2003-01-12 19:59 ` Mike Anderson [this message]
2003-01-14 15:26 ` Patrick Mochel
2003-01-14 18:33 ` Mike Anderson
2003-01-14 23:08 ` Andries Brouwer
2003-01-11 17:02 ` Mike Anderson
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=20030112195901.GC1414@beaverton.ibm.com \
--to=andmike@us.ibm.com \
--cc=Kai.Makisara@kolumbus.fi \
--cc=Matt_Domsch@Dell.com \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=wrlk@riede.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.