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 divide
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.
##########
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 divide
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.
##########
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.
##########
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:
> That argument has value if the solution is 100% compatible with Linux.
Linux only provides the partition offset information via `sysfs`, a
subsystem that NuttX does not currently have.
So 100% compatibility with Linux is not possible at the moment.
But, the approach via `ioctl` is the most compatible to Linux.
##########
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:
> That argument has value if the solution is 100% compatible with Linux.
Linux only provides the partition offset information via `sysfs`, a
subsystem that NuttX does not currently have.
https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-class-mtd#L226-L234
So 100% compatibility with Linux is not possible at the moment.
But, the approach via `ioctl` is the most compatible to Linux.
##########
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:
Please, explain which approach does make sense to you then.
I really hope that you have a better proposal than the string parsing
approach via `procfs`.
##########
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:
Please, explain which approach does make sense to you then.
I really hope that you have a better proposal than the string parsing
approach via `procfs`.
Remember the original intent of this PR, which is to provide the first
sector information from an MTD partition.
##########
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:
> I would prefer in this order: A 100% Linux compatible solution then
string parsing via the existing procfs.
A 100% Linux compatible solution implies the creation of a `sysfs` subsystem
for Linux. Although much desirable, unfortunately is far beyond the scope for
this PR.
And string parsing via `procfs` when compared to `ioctl` solution is
sub-optimal in terms of execution time and code size. Execution time will scale
depending on the number of partitions to be returned from `/proc/partitions`.
Code size will increase due to the requirement of enabling the optional
`procfs` subsystem.
Besides the fact that the only available method for identifying a partition
from `/proc/partitions` is via the partition name, which is once again
sub-optimal considering it involves comparison of strings.
Using `ioctl` only requires a valid file descriptor and does not impose any
architectural changes to the OS, since the MTD subsystem already implements
several other `ioctl` commands. Also, the value to be returned via the `ioctl`
command is readily available in the MTD partition information.
@xiaoxiang781216 Please kindly evaluate the answers from
https://github.com/apache/incubator-nuttx/pull/4248#discussion_r682578813 and
also the above reasoning.
##########
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:
> I would prefer in this order: A 100% Linux compatible solution then
string parsing via the existing procfs.
A 100% Linux compatible solution implies the creation of a `sysfs` subsystem
for NuttX. Although much desirable, unfortunately is far beyond the scope for
this PR.
And string parsing via `procfs` when compared to `ioctl` solution is
sub-optimal in terms of execution time and code size. Execution time will scale
depending on the number of partitions to be returned from `/proc/partitions`.
Code size will increase due to the requirement of enabling the optional
`procfs` subsystem.
Besides the fact that the only available method for identifying a partition
from `/proc/partitions` is via the partition name, which is once again
sub-optimal considering it involves comparison of strings.
Using `ioctl` only requires a valid file descriptor and does not impose any
architectural changes to the OS, since the MTD subsystem already implements
several other `ioctl` commands. Also, the value to be returned via the `ioctl`
command is readily available in the MTD partition information.
@xiaoxiang781216 Please kindly evaluate the answers from
https://github.com/apache/incubator-nuttx/pull/4248#discussion_r682578813 and
also the above reasoning.
--
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
