From: Jens Axboe <axboe@kernel.dk>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Christoph Hellwig <hch@lst.de>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: remove the cmd_type field from struct request
Date: Tue, 31 Jan 2017 13:09:49 -0800 [thread overview]
Message-ID: <deae073a-ae3b-eedb-5c86-4f52746a281c@kernel.dk> (raw)
In-Reply-To: <ebcc36be-9c02-eff3-33a0-20f7dedc3c0b@cogentembedded.com>
On 01/31/2017 10:58 AM, Sergei Shtylyov wrote:
> On 01/31/2017 09:51 PM, James Bottomley wrote:
>
>>>> [1] which were a pain in the ass to untangle and debug during
>>>> development, it's really time for it to die..
>>>
>>> Outside of the patch series in question, how to we expedite the
>>> euthanasia of IDE? What explicit features/support are we missing
>>> through libata that would need to be added, before we can git rm
>>> drivers/ide/?
>>
>> I thought the primary objection was actually embedded in that libata
>
> Back at MontaVista, even embedded uses switched to libata years ago...
Indeed, that would be my assumption as well, not too worried about that
side.
> DaveM thinks we still can't prove that libata works everywhere the IDE works.
> Besided, there are still a number of non-x86 drivers not converted over to
> libata (like DaVinci, etc.)...
That argument is getting harder to buy. IDE has become a considerable
maintenance burden - not for Dave, but for the rest of us that have
to carry a subsystem forward. Personally I would _love_ to kill IDE
at some point in the future, where that future hopefully isn't too far
off. But if we have hardware that is being used and where IDE works and
libata support does not exist, then weneed to fix that first.
> Do you remember how many years ago a libata's own block driver was
> promised to you? ;-)
> I'd gladly wrote one, getting tired of my current OSS work... :-)
Pretty sure I told Jeff originally that libata should only go into the
kernel, if there was a plan to make it independent of SCSI. A promise
was made that of course it would, but that promise was never held,
unfortunately.
--
Jens Axboe
next prev parent reply other threads:[~2017-01-31 21:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 15:57 Christoph Hellwig
2017-01-31 15:57 ` [PATCH 01/10] scm_blk: remove unneeded REQ_TYPE_FS check Christoph Hellwig
2017-01-31 15:57 ` [PATCH 02/10] ѕd: remove pointless " Christoph Hellwig
2017-01-31 15:57 ` [PATCH 03/10] mmc: remove pointless request type check in mmc_prep_request Christoph Hellwig
2017-01-31 15:57 ` [PATCH 04/10] ms_block: remove pointless prep_fn Christoph Hellwig
2017-01-31 15:57 ` [PATCH 05/10] mspro_block: " Christoph Hellwig
2017-01-31 15:57 ` [PATCH 06/10] nbd: remove REQ_TYPE_DRV_PRIV leftovers Christoph Hellwig
2017-01-31 15:57 ` [PATCH 07/10] nbd: move request validity checking into nbd_send_cmd Christoph Hellwig
2017-01-31 15:57 ` [PATCH 08/10] block: introduce blk_rq_is_passthrough Christoph Hellwig
2017-01-31 15:57 ` [PATCH 09/10] ide: don't abuse cmd_type Christoph Hellwig
2017-01-31 16:11 ` David Miller
2017-01-31 15:57 ` [PATCH 10/10] block: fold cmd_type into the REQ_OP_ space Christoph Hellwig
2017-01-31 18:02 ` remove the cmd_type field from struct request Jens Axboe
2017-01-31 18:51 ` James Bottomley
2017-01-31 18:58 ` Sergei Shtylyov
2017-01-31 21:09 ` Jens Axboe [this message]
2017-02-01 6:53 ` Hannes Reinecke
2017-02-01 10:55 ` Sergei Shtylyov
[not found] ` <CGME20170201103729epcas1p12708473d0e5257bef65e1d92712af885@epcas1p1.samsung.com>
2017-02-01 10:37 ` Bartlomiej Zolnierkiewicz
2017-01-31 21:07 ` Jens Axboe
2017-02-01 2:58 ` Martin K. Petersen
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=deae073a-ae3b-eedb-5c86-4f52746a281c@kernel.dk \
--to=axboe@kernel.dk \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.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
Powered by JetHome