linux-kernel - Re: [patch] megaraid: fix CONFIG_PROC

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] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2007 21:25:23 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Neela Kolli <Neela.Kolli@...enio.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] megaraid: fix CONFIG_PROC_FS compile errors

Andrew Morton wrote:
> On Mon, 30 Apr 2007 08:44:14 -0700 Randy Dunlap <randy.dunlap@...cle.com> wrote:
> 
>> On Mon, 30 Apr 2007 07:35:00 -0700 (PDT) David Rientjes wrote:
>>
>>> Only declare mega_proc_dir_entry() in CONFIG_PROC_FS.  We should call
>>> mega_create_proc_entry() only in this configuration so make sure it's defined
>>> if we call it.
>>>
>>> Only define mega_adapinq() in CONFIG_PROC_FS.  mega_internal_dev_inquiry()
>>> and mega_print_inquiry() were never declared without CONFIG_PROC_FS so
>>> make sure we don't have prototypes for them if we aren't going to define
>>> them.
>>>
>>> Move the declaration of 'buf' in mega_remove_one() because we only use it
>>> in the CONFIG_PROC_FS case.
>> Just noting the presence of:
>>   http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/megaraid-fix-warnings-when-config_proc_fs=n.patch
>>
> 
> That patch has been submitted fourteen times in the past year, and was
> completely ignored each time.
> 
>> Oh, and that SCSI patches need to go to the linux-scsi mailing list.
>>
> 
> There seem to be little point in doing that.

Yes, I guess I was speaking theory instead of reality.

I suppose that one alternative is for you to merge those long-queued
patches instead of sending them on to linux-scsi over and over again.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/