Hmm. At least two of my older drivers use it, a flash memory driver and an FRAM driver. The block protocol may have been obsolete from your point of view but were users aware of the fact? You may encounter a few howls of anguish with this one.

At least two of my older drivers use it, a flash memory driver and an FRAM driver.

Ok, I didn't appreciate that it was being used. It would be nice to deprecate it so that 1) it doesn't take up code space; 2) doesn't need to be maintained; 3) users switch to the newer protocol.

In general we need a plan to move forward with breaking changes so that the code base doesn't need to maintain a lot of legacy stuff. I would like to eventually switch to semantic versioning (https://semver.org) which allows for breaking changes with a change of major version number. But until then there needs to be a different solution, like deprecation warnings.

I successfully use Peter's FRAM driver in a data logger app. Would be nice if this can be continued to be used :-)

Would be nice if this can be continued to be used

It can continue. It can use the new protocol and everything would work the same as before.

Sure, but that requires all authors of block device drivers to know about this and to find time to write and test the necessary nontrivial (in this instance) changes.

If there are N drivers using the block protocol each with an average of M users, suddenly N*M people have projects which suddenly break on a f/w upgrade.

I became aware of this because I check GitHub daily. It's likely that there are other people who've published device drivers who are still unaware of this issue. If breaking changes are going to be introduced it should be announced well in advance on the Forum, preferably with guidance on how to remedy the situation.

Am I missing something here? The official sdcard driver seems still to use the block protocol. It implements count(), readblocks() and writeblocks() with no ioctl().

FWIW this was my main source of information for writing my drivers.

@dpgeorge It would help if the official sdcard driver were adapted to use the new protocol so we could better understand what is involved in converting drivers. On reflection I'm not confident I fully understand the implications and sdcard.py is the obvious place to look for example code.

Am I missing something here? The official sdcard driver seems still to use the block protocol. It implements count(), readblocks() and writeblocks() with no ioctl().

Yes you are right! I totally missed this.

In that case it really doesn't make sense to drop support for this "old" block protocol, since it's not really "old".

Then the plan to move forward would be: 0) document the block protocol -- this is already done in 8359210 ; 1) change all existing drivers in this repo to not use the old protocol; 2) make it known that the old protocol is being deprecated, and how to change to the new protocol; 3) wait some time for deprecation; 4) then finally remove it.

I'll close this PR then.

Thanks @peterhinch for raising the counter points.

The official sdcard driver seems still to use the block protocol.

In 8b8c083 I updated the sdcard.py driver to use the new protocol.

In which case I entirely misunderstood what was involved envisioning a radical driver rewrite. Phew!

As a matter of interest shouldn't ioctl honour BP_IOCTL_SEC_SIZE (5) queries?

Nevertheless I agree with your proposed implementation plan.

@rolandvs I've updated the FRAM driver so it should survive future changes. If you look at the test program it now uses VFS mounting and I recommend adapting your code to that approach if you install the new version.

As a matter of interest shouldn't ioctl honour BP_IOCTL_SEC_SIZE (5) queries?

If ioctl returns None (ie does nothing) for this query then a default value of 512 bytes is used (this default is documented in the docs).