All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Thomas Heinz <thomasheinz@gmx.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SCSI DVD-RAM partitions
Date: Sun, 31 Jul 2005 15:01:57 +0100	[thread overview]
Message-ID: <20050731140157.GA6173@infradead.org> (raw)
In-Reply-To: <42D37DF5.6060902@gmx.net>

On Tue, Jul 12, 2005 at 10:23:17AM +0200, Thomas Heinz wrote:
> Hi Christoph
> 
> You wrote:
> >While adding support for partitions on sr is trivial it has a huge
> >drawback: it's chaning the dev_t space by using up device numbers
> >for partitions, so /dev/sr0 ff will have different device numbers
> >with that change applied.  I have an old patch that's supposed to
> >enable support for partitioned scsi removable devices at
> >http://rechner.lst.de/~hch/hacks/sr-parts.diff, I'm not sure it
> >actually ever worked (but you should get the basic idea from it)
> 
> Ok, thanks for your valuable input. In fact, I thought about making
> the device available both as /dev/srX and /dev/sdX at the same time
> in order to support partitions. In my case it would even suffice to
> make it available as /dev/sdX instead of /dev/srX.

That doesn't make sense because sd is a very different driver from sd.
Besides that aliasing different dev_ts to the same underlying blockdevice
can't work, it's cause all sorts of aliasing problems.

> Since I have no expert knowledge about this topic, I would be
> interested in the general attitude towards "partitions on SCSI
> DVD-RAM media / SCSI removable devices":
> - Are partitions intentionally not supported? If so, why?

Historical coincidence.

> - Does it usually work but not with my specific DVD-RAM model?
>   If so, why?
> - Do you think that this should be fixed?

There's no nice way to fix it unfortunately.

> Please note that personally, I can live with the "losetup hack"
> since it is easy enough to write a program which encapsulates
> partition mounting. However, there might be people which would
> prefer plugging in a (possibly pre-)partitioned medium and
> having the partitions work out of the box in the expected way.

It would probably be better to use device-mapper than the loop device.
I think there's already userland partition parsing code for dm, and
having a simple command line tool to do that, and maybe even automatically
run through udev and creating /dev/sr<num>p<partition> devices would
be very nice to have as an almost invisible workaround.


  reply	other threads:[~2005-07-31 14:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-09 12:32 SCSI DVD-RAM partitions Thomas Heinz
2005-07-12  2:37 ` Christoph Hellwig
2005-07-12  8:23   ` Thomas Heinz
2005-07-31 14:01     ` Christoph Hellwig [this message]
2005-08-05 17:02       ` Thomas Heinz

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=20050731140157.GA6173@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomasheinz@gmx.net \
    /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.