All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Andy Grover <agrover@redhat.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/3] scsi: Move user-shareable stuff in scsi/scsi.h to uapi/scsi/scsi.h
Date: Fri, 09 Jan 2015 07:50:38 -0800	[thread overview]
Message-ID: <1420818638.2064.5.camel@HansenPartnership.com> (raw)
In-Reply-To: <20150109154613.GA29124@lst.de>

On Fri, 2015-01-09 at 16:46 +0100, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 07:27:46AM -0800, James Bottomley wrote:
> > Actually, they are exported.  If you look at what glibc supplies, it has
> > it's own copies of scsi.h and scsi_ioctl.h.  If we try to repace those
> > with uapi, we have to make sure nothing breaks, so the opcodes have to
> > be in scsi.h somehow.
> > 
> > Now, I agree that the opcodes in our scsi.h shouldn't be the definitive
> > ones because they're the only the ones the kernel cares about.  However,
> > the fact is that any userspace programme including scsi.h and
> > scsi_ioctl.h is expecting to get the opcodes and we can't break that.
> > 
> > Were you thinking of moving opcodes to scsi_opcodes.h and #including
> > that in scsi.h but not exporting it so glibc supplies its own?
> 
> I don't think trying to replace glibcs fork of our scsi/*.h is
> a good use of our time.  They will have keep it complatible with
> their old version anyway.  So they will still have to provide their
> old subset of operations.

Right, that's why I'm dubious about this effort.  uapi files either have
to become the glibc headers or be exported in a way that allows
inclusion into glibc headers for there to be any point.

> What does however make sense is to export our ioctl ABI.  As with
> most other ioctls we should do that through and UAPI linux/*.h file,
> e.g. linux/scsi_ioctl.h.  On our side it will replace the existing
> ioctl defintions, and if we're careful glibc can also use it include
> it from their files.  Trying to export all the opcodes, device types,
> SCSI-2 messages and similar on the other hand is a lot of pain for
> little gain.
> 
> Oh, and we also should have a uapi/linux/sg.h for the ioctls that
> came from the sg driver.

Agreed, but I think we need to start with the glibc people first to find
out how they want our uapi exports structured so they can replace part
of the copy they have.

James



  reply	other threads:[~2015-01-09 15:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08 19:47 [PATCH 0/3] Add uapi/scsi/scsi.h Andy Grover
2015-01-08 19:47 ` [PATCH 1/3] scsi: add WRITE_VERIFY_16 to scsi.h Andy Grover
2015-01-08 19:47 ` [PATCH 2/3] scsi: Move user-shareable stuff in scsi/scsi.h to uapi/scsi/scsi.h Andy Grover
2015-01-09 10:14   ` Christoph Hellwig
2015-01-09 15:27     ` James Bottomley
2015-01-09 15:46       ` Christoph Hellwig
2015-01-09 15:50         ` James Bottomley [this message]
2015-01-09 16:01           ` Christoph Hellwig
2015-01-09 16:33             ` James Bottomley
2015-01-09 17:11               ` Christoph Hellwig
2015-01-09 17:44                 ` James Bottomley
2015-01-08 19:47 ` [PATCH 3/3] scsi: Remove scsi_ioctl.h Andy Grover
2015-01-08 20:35   ` James Bottomley
2015-01-08 21:26     ` Andy Grover
2015-01-09  9:05     ` Christoph Hellwig

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=1420818638.2064.5.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=agrover@redhat.com \
    --cc=hch@lst.de \
    --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 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.