gustavonihei commented on a change in pull request #4248:
URL: https://github.com/apache/incubator-nuttx/pull/4248#discussion_r682578813
##########
File path: drivers/mtd/mtd_partition.c
##########
@@ -413,6 +413,25 @@ static int part_ioctl(FAR struct mtd_dev_s *dev, int cmd,
unsigned long arg)
}
break;
+ case MTDIOC_PARTINFO:
+ {
+ FAR struct partition_info_s *info =
+ (FAR struct partition_info_s *)arg;
+ if (info != NULL)
+ {
+ info->magic = 0;
+ info->numsectors = priv->neraseblocks * priv->blkpererase;
+ info->length = info->numsectors * priv->blocksize;
+ info->sectorsize = priv->blocksize;
+ info->startsector = priv->firstblock;
+ info->endsector = priv->firstblock + info->numsectors;
+ info->parent = priv->parent->name;
+
+ ret = OK;
+ }
+ }
+ break;
+
Review comment:
> It's good to follow Linux design, two question:
>
> 1. Should we also use MEMGETINFO and mtd_info_t too?
For compatibility purposes, I think we should.
On Linux `mtd_info_t` is a typedef to `struct mtd_info_user` and some of its
fields overlap with NuttX `mtd_geometry_s`. So this would require to refactor
`MTDIOC_GEOMETRY` to avoid having two `ioctl` commands returning the same
information.
Since this is not a simple task, I'd suggest to refactor it in another PR.
> 2. How about block driver which should have the similar requirement too?
I also agree on this one.
The intent with the proposed `struct partition_info_s` was to make it
generic, so that it could be used by block devices also.
But, again, I'd like to restrict the scope of this PR to MTD only to split
the validation effort.
I believe that the proposed `MTDIOC_PARTINFO` does not overlap with
`MEMGETINFO` nor `MEMGETREGIONINFO`. As explained by @patacongo, the MTD
partition abstraction is more of a software abstraction than a real partition,
and it is different to what Linux refers to a MTD Region, which means areas of
an MTD with distinct erase sizes, something that we don't have in NuttX so far
(to my knowledge).
So merging this proposal would not be a wasted effort. We may later have
both `MEMGETINFO` for compatibility purposes by refactoring the
`MTDIOC_GEOMETRY`, and also `MEMGETREGIONINFO` if eventually we support these
types of MTD with more than one erase region.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
