Re: [Linux-nvdimm] [PATCH] pmem: Add prints at module load and unload

From: Boaz Harrosh
Date: Sun Apr 05 2015 - 04:50:33 EST


On 04/02/2015 07:44 PM, Christoph Hellwig wrote:
> On Thu, Apr 02, 2015 at 09:01:14AM -0700, Dan Williams wrote:
>>>> If anything I think these should be dev_dbg().
>>>
>>> We do not have a dev at any of this point, and it does not
>>> belong to any specific device.
>>
>> Ah, true this is prior to the driver attaching... that said it seems
>> more relevant to print from probe() (where we do have a device) than
>> init where the device may remain idle due to some other policy.
>>
>>> Also I would like this
>>> _info and not _dbg so to always have it, also for production.
>>> See the chatter for a single SCSI disk the minimum we need
>>> is just the small print that tells all that we need (for now)
>>
>> Not sure we want to follow so closely in the footsteps of SCSI's chattiness.
>
> Defintively not! A single dev_info at ->probe time sounds ok, something
> like:
>
> dev_info(dev, "registering region [0x%pa:0x%zx]\n",
> &pmem->phys_addr, pmem->size);
>
> but there are plenty other drivers not that chatty, e.g. virtio and we're
> doing just fine for them.
>

For me, my print is just the exact amount.

So I will see in my dmesg:

[ +0.000000] user: [mem 0x0000000100000000-0x000000015fffffff] persistent (type 12)
[ +0.000000] user: [mem 0x0000000160000000-0x00000001dfffffff] persistent (type 12)

...
[ +0.000537] pmem: init 2 devices => 0

So I have all the information. And I know the driver was actually loaded
successfully on the expected two regions.

Your print above will give me two prints with information I already have.
All I want to know from users logs is that the driver was actually loaded
successful or not. And when it was unloaded. I think this is the bear minimum
that gives me all the information I need. Less then this I would be missing
a very important event.

Thanks
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/