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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5520F73E.3020602@plexistor.com>
Date:	Sun, 05 Apr 2015 11:50:06 +0300
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Christoph Hellwig <hch@....de>,
	Dan Williams <dan.j.williams@...el.com>
CC:	linux-nvdimm <linux-nvdimm@...1.01.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [Linux-nvdimm] [PATCH] pmem: Add prints at module load and unload

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/