public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Jones <pjones@redhat.com>
To: dougg@torque.net
Cc: Jens Axboe <axboe@suse.de>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: BSG question
Date: Thu, 16 Sep 2004 11:11:51 -0400	[thread overview]
Message-ID: <1095347511.4852.38.camel@localhost.localdomain> (raw)
In-Reply-To: <41493D5C.9000700@torque.net>

On Thu, 2004-09-16 at 17:14 +1000, Douglas Gilbert wrote:

> > (you should cc the author when you ask questions about the patch :-)
>
> I have cc-ed Peter Jones now.

It's really Jens's project, but thanks for including me as well ;)

> > I'll try and set up a tree that gets regularly updated, if people are
> > interested in it. Last time I basically came to the conclusion that bsg
> > wasn't 'interesting enough'. SG_IO might not be a pretty interface (I
> > mean the ioctl, not the sg_io_hdr structure), but as long as you don't
> > require queueing or async io it works well enough. And that covers just
> > about 99.5% of the use of sg.
> 
> It has another advantage. It allows device policy
> (including error processing) to be decoupled from
> the primary device interface. For example cdrecord
> does not want to see EROFS (when it opens O_RDWR)
> and does want to see all sense data back from the device **.

And, excuse me for sounding like a broken record, it's traceable with
strace.  I still count this as a big win, even though it horribly abuses
some API for that.

> On the other hand there does seem to be a security issue
> with bsg. Perhaps there could be a "non_root" sysfs attribute
> (default 0, root only writable) on devices that bsg can
> bind to. Then a bsg bind to a specific device needs
> a user with CAP_SYS_RAWIO (or CAP_SYS_ADMIN) or the
> device with non_root=1.

Or, rather, the filtering stuff that's been discussed on l-k...  It's an
idea suitable for a really grungy dumpster, but it works ok.  It'd be
simple enough to add in.

> >>bsg has one device node (i.e. "/dev/bsg") which users can
> >>open and then bind/attach to an existing block device
> >>node (e.g. /dev/sda). Extending this to bind to sysfs
> >>device paths might be handy as well for
> >>   - (SCSI) devices that have an unsupported peripheral device
> >>      type (e.g. SES)
> >>   - other devices (e.g. SMP port of an SAS expander)

It'd be better to get rid of the binding all together, as it's pretty
ugly to begin with.  It's fairly straightforward to make a file in
sysfs, "/sys/block/hda/rawio" or whatnot, and hang it off of a gendisk.
That way there'd be no binding to do whatsoever; you'd just open the
right device to begin with.  Jens and I discussed that earlier, but
didn't really work on it in light of the biarch problems.

-- 
        Peter


      parent reply	other threads:[~2004-09-16 15:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-16  2:36 BSG question Douglas Gilbert
2004-09-16  6:05 ` Jens Axboe
2004-09-16  7:14   ` Douglas Gilbert
2004-09-16  7:24     ` Jens Axboe
2004-09-16 15:11     ` Peter Jones [this message]

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=1095347511.4852.38.camel@localhost.localdomain \
    --to=pjones@redhat.com \
    --cc=axboe@suse.de \
    --cc=dougg@torque.net \
    --cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox