From: Tony Battersby <tonyb@cybernetics.com>
To: dgilbert@interlog.com, James Bottomley <jejb@linux.vnet.ibm.com>,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-api@vger.kernel.org
Cc: martin.petersen@oracle.com, hare@suse.de, bvanassche@acm.org,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 00/20] sg: add v4 interface
Date: Thu, 8 Aug 2019 17:37:44 -0400 [thread overview]
Message-ID: <5a80d09c-c1a5-429d-d46a-5e108b6292df@cybernetics.com> (raw)
In-Reply-To: <7edab448-22cc-493a-f745-acc5be38f6a5@interlog.com>
On 8/8/19 5:08 PM, Douglas Gilbert wrote:
>
> Here is the full set of extra ioctls I have, or will be proposing:
> SG_IOSUBMIT
> SG_IOSUBMIT_V3
> SG_IORECEIVE
> SG_IORECEIVE_V3
> SG_IOABORT
> SG_SG_SET_GET_EXTENDED
>
> They are all new style ioctls using the _IOR(W) macros with fixed size
> objects referenced by the ioctl's third argument. ioctls have been
> referred to as the "garbage bin of Unix". Well that last one is a garbage
> bin within a garbage bin :-) On the plus side, it keeps that list
> relatively short.
>
> Doug Gilbert
>
>
> *** Tony Battersby is a sg driver power user. He has lamented wading through
> very large logs looking for some hint of why the sg driver is playing
> up. He has stated the strong preference for more, not less, ioctls.
>
One of the reasons ioctls have a bad reputation is because they can be
used to implement poorly-thought-out interfaces. So kernel maintainers
push back on adding new ioctls. But the push back isn't about the
number of ioctls, it is about the poor interfaces. My advice was that
in general, to implement a given API, it would be better to add more
ioctls with a simple interface for each one rather than to add fewer
extremely complex multiplexing ioctls.
Tony Battersby
Cybernetics
next prev parent reply other threads:[~2019-08-08 21:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190807114252.2565-1-dgilbert@interlog.com>
2019-08-08 19:10 ` [PATCH v3 00/20] sg: add v4 interface James Bottomley
2019-08-08 21:08 ` Douglas Gilbert
2019-08-08 21:37 ` Tony Battersby [this message]
2019-08-08 22:25 ` Bart Van Assche
2019-08-09 13:28 ` Tony Battersby
2019-08-08 23:00 ` James Bottomley
2019-08-14 4:19 ` Douglas Gilbert
2019-08-15 17:30 ` Bart Van Assche
2019-08-16 15:59 ` Douglas Gilbert
2019-08-16 17:19 ` Greg KH
2019-08-16 18:10 ` Bart Van Assche
2019-08-16 18:44 ` Douglas Gilbert
2019-08-12 15:23 ` 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=5a80d09c-c1a5-429d-d46a-5e108b6292df@cybernetics.com \
--to=tonyb@cybernetics.com \
--cc=arnd@arndb.de \
--cc=bvanassche@acm.org \
--cc=dgilbert@interlog.com \
--cc=hare@suse.de \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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;
as well as URLs for NNTP newsgroup(s).