[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER
From: |
Kevin Wolf |
Subject: |
Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER |
Date: |
Thu, 28 Jul 2022 15:29:58 +0200 |
Am 28.07.2022 um 11:46 hat Peter Maydell geschrieben:
> On Wed, 27 Jul 2022 at 20:03, Kevin Wolf <kwolf@redhat.com> wrote:
> >
> > Am 18.07.2022 um 11:49 hat Markus Armbruster geschrieben:
> > > An OTP device isn't really a parallel flash, and neither are eFuses.
> > > More fast-and-lose use of IF_PFLASH may exist in the tree, and maybe of
> > > other interface types, too.
> > >
> > > This patch introduces IF_OTHER. The patch after next uses it for an
> > > EEPROM device.
> > >
> > > Do we want IF_OTHER?
> >
> > What would the semantics even be? Any block device that doesn't pick up
> > a different category may pick up IF_OTHER backends?
> >
> > It certainly feels like a strange interface to ask for "other" disk and
> > then getting as surprise what this other thing might be. It's
> > essentially the same as having an explicit '-device other', and I
> > suppose most people would find that strange.
> >
> > > If no, I guess we get to abuse IF_PFLASH some more.
> > >
> > > If yes, I guess we should use IF_PFLASH only for actual parallel flash
> > > memory going forward. Cleaning up existing abuse of IF_PFLASH may not
> > > be worth the trouble, though.
> > >
> > > Thoughts?
> >
> > If the existing types aren't good enough (I don't have an opinion on
> > whether IF_PFLASH is a good match), let's add a new one. But a specific
> > new one, not just "other".
>
> I think the common thread is "this isn't what anybody actually thinks
> of as being a 'disk', but we would like to back it with a block device
> anyway". That can cover a fair range of possibilities...
How confident are we that no board will ever have two devices of this
kind?
As long as every board has at most one, if=other is a bad user interface
in terms of descriptiveness, but still more or less workable as long as
you know what it means for the specific board you use.
But if you have more than one device, it becomes hard to predict which
device gets which backend - it depends on the initialisation order in
the code then, and I'm pretty sure that this isn't something that should
have significance in external interfaces and therefore become a stable
API.
Kevin
- [PATCH v5 1/8] hw/i2c: Clear ACK bit in NPCM7xx SMBus module, (continued)
- [PATCH v5 1/8] hw/i2c: Clear ACK bit in NPCM7xx SMBus module, Hao Wu, 2022/07/14
- [PATCH v5 2/8] hw/i2c: Read FIFO during RXF_CTL change in NPCM7XX SMBus, Hao Wu, 2022/07/14
- [PATCH v5 3/8] hw/adc: Fix CONV bit in NPCM7XX ADC CON register, Hao Wu, 2022/07/14
- [PATCH v5 4/8] hw/adc: Make adci[*] R/W in NPCM7XX ADC, Hao Wu, 2022/07/14
- [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Hao Wu, 2022/07/14
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Markus Armbruster, 2022/07/18
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Thomas Huth, 2022/07/18
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Kevin Wolf, 2022/07/27
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Peter Maydell, 2022/07/28
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER,
Kevin Wolf <=
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Peter Maydell, 2022/07/28
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Cédric Le Goater, 2022/07/28
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Markus Armbruster, 2022/07/28
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Peter Maydell, 2022/07/28
- Re: [PATCH v5 5/8] blockdev: Add a new IF type IF_OTHER, Kevin Wolf, 2022/07/28
[PATCH v5 6/8] hw/arm: npcm8xx_boards: EEPROMs can take bus as parameter, Hao Wu, 2022/07/14
[PATCH v5 7/8] hw/arm: Set drive property for at24c eeprom, Hao Wu, 2022/07/14
[PATCH v5 8/8] hw/arm: quanta-gbs-bmc add i2c devices, Hao Wu, 2022/07/14
Re: [PATCH v5 0/8] Misc NPCM7XX patches, Peter Maydell, 2022/07/15