Re: [BUG] mtdinfo -a: Tries to open NULL pointer for NOR with Eraseblock Regions

[Mike Frysinger <vapier@gentoo.org>]

On Fri, Aug 5, 2011 at 17:09, Brian Norris wrote:
> On Thu, Aug 4, 2011 at 3:41 PM, Mike Frysinger wrote:
>> On Thu, Aug 4, 2011 at 10:46, Brian Norris wrote:
>>> On Tue, Jul 26, 2011 at 12:21 AM, Brian Foster wrote:
>>>>> It seems that the basic issue we need to solve is how to find the
>>>>> correct file devfs/udev path  [...]
>>>>
>>>>  As an FYI, in our current embedded systems (plural),
>>>>  a static /dev is used (no udev, mdev, &tc).  Hence,
>>>>  udev (and I assume also, devfs) path may not work
>>>>  in such an environment?
>>>
>>> Now that I think about it, this doesn't seem like a very reliable
>>> solution. Too much user-space variability.
>>
>> when extending mtdinfo, we decided to only support device paths which
>> the user gave us.  hence the -m option going away.  libmtd itself has
>> /dev/mtd# hardcoded (and imo, that's the only path we should support
>> "automatically"), so if we're going to keep the all option, we'll want
>> to continue with that (by using the func that libmtd provides rather
>> than mtdinfo constructing the string itself).
>
> Hmm, where exactly in mtd-utils/libmtd is the /dev/mtd# hardcoded?

i was thinking of legacy_get_dev_info1()

alternatively, we punt --all and just make users run `mtdinfo
/dev/mtd?`.  i'm fine with that too.

>>>>> Also, is "region_info" a potential candidate for exporting via sysfs?
>>>>> That would make this support easier to include in libmtd.
>>>>
>>>>  I don't know if it is exportable or not, but I concur
>>>>  this seems like a possible/plausible solution.
>>>
>>> Even if we do this (which seems like a lot of info), it would only
>>> apply to the newest kernels, where mtd-utils are *supposed* to be
>>> backwards-compatible if possible, where they can fall back to old
>>> methods if needed...
>>
>> i posted this question recently, and iirc the answer was that it isnt
>> currently exported via sysfs, but shouldnt be hard to extend.  just
>> have to find someone who wants to do it ;).
>
> "someone who wants to do it" - that's the key for everything, isn't it?

indeed.  i have no interest or need, let alone any way of testing it :).

>>> Anyway, since I don't have these types of flash readily available, I
>>> don't even use these options :) And apparently, one of the biggest
>>> contributors for mtd-utils, Mike Frysinger, doesn't use region_info
>>> either...
>>
>> i dont think any of the flashes (parallel nor, spi nor, nand, etc...)
>> included region_info.  that's why the func print_region_info() sets up
>> a dummy region_info struct that describes the entire flash before
>> calling print_region_map().
>
> I don't know much about this, but what's the feature for if no one uses it?

i use the print_region_map() which is why i wrote it.  if the kernel
doesnt define any regions, then i still want to see the whole device
as one region.
-mike