From: Christoph Hellwig <hch@lst.de>
To: Stefan Haberland <sth@linux.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
axboe@kernel.dk, linux-block@vger.kernel.org,
hoeppner@linux.ibm.com, linux-s390@vger.kernel.org,
heiko.carstens@de.ibm.com, gor@linux.ibm.com,
borntraeger@de.ibm.com, linux-kernel@vger.kernel.org,
Peter Oberparleiter <oberpar@linux.ibm.com>
Subject: Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver
Date: Tue, 5 May 2020 14:44:23 +0200 [thread overview]
Message-ID: <20200505124423.GA26313@lst.de> (raw)
In-Reply-To: <70f541fe-a678-8952-0753-32707d21e337@linux.ibm.com>
On Mon, May 04, 2020 at 10:45:33AM +0200, Stefan Haberland wrote:
> > findthe corresponding device for example. Not sure if this is that easy.
>
> I did some additional research on this.
> What I could imagine:
>
> The gendisk->private_data pointer currently contains a pointer to
> the dasd_devmap structure. This one is also reachable by iterating
> over an exported dasd_hashlist.
> So I could export the dasd_hashlist symbol, iterate over it and try
> to find the dasd_devmap pointer I have from the gendisk->private_data
> pointer.
> This would ensure that the gendisk belongs to the DASD driver and I
> could use the additional information that is somehow reachable through
> the gendisk->private_data pointer.
>
> But again, I am not sure if this additional code and effort is needed.
> From my point of view checking the gendisk->major for DASD_MAJOR is
> OK to ensure that the device belongs to the DASD driver.
With CONFIG_DEBUG_BLOCK_EXT_DEVT you can't rely on major numbers.
And compared to all the complications I think the biodasdinfo method
is the least of all those evils. Jens, any opinion?
next prev parent reply other threads:[~2020-05-05 12:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 11:17 [PATCH 0/1] remove ioclt_by_bdev from DASD Stefan Haberland
2020-04-30 11:17 ` [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver Stefan Haberland
2020-04-30 13:13 ` Christoph Hellwig
2020-04-30 14:02 ` Stefan Haberland
2020-05-04 8:45 ` Stefan Haberland
2020-05-05 12:44 ` Christoph Hellwig [this message]
2020-05-05 15:09 ` Stefan Haberland
2020-05-06 4:52 ` Christoph Hellwig
2020-05-07 15:22 ` Stefan Haberland
2020-05-07 15:29 ` Christoph Hellwig
2020-05-07 15:43 ` Stefan Haberland
2020-05-07 15:45 ` 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=20200505124423.GA26313@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=borntraeger@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hoeppner@linux.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=sth@linux.ibm.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 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.