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: <51CABA73.6020003@asianux.com>
Date:	Wed, 26 Jun 2013 17:54:59 +0800
From:	Chen Gang <gang.chen@...anux.com>
To:	Richard Weinberger <richard@....at>
CC:	Jeff Dike <jdike@...toit.com>, Arnd Bergmann <arnd@...db.de>,
	dhsharp@...gle.com,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	uml-devel <user-mode-linux-devel@...ts.sourceforge.net>,
	uml-user <user-mode-linux-user@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] include/asm-generic/io.h: add 'UML' case just like 'no-MMU'

On 06/26/2013 05:38 PM, Richard Weinberger wrote:
> Am 26.06.2013 11:33, schrieb Chen Gang:
>> > On 06/26/2013 05:03 PM, Richard Weinberger wrote:
>>> >> Am 26.06.2013 10:58, schrieb Chen Gang:
>>>>> >>>> On 06/26/2013 04:39 PM, Richard Weinberger wrote:
>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The drivers internal code has already check the related return value,
>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> so it is the architecture's duty to 'tell' the driver whether support
>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> io memory (e.g. define ioremap, but return NULL).
>>>>>>>>>>>>>>> >>>>>>>>>>>>>> It does so already by setting CONFIG_HAS_IOMEM=n
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>> Excuse me, I use "grep -rn ioremap *" under "include/" and "arch/um/"
>>>>>>>>>>> >>>>>>>>>> directory, but can not find the related definition for 'ioremap'.
>>>>>>>>>>> >>>>>>>>>>
>>>>>>>>>>> >>>>>>>>>> Is there another declaration or definition way which I don't know ?
>>>>>>>>>>> >>>>>>>>>> (maybe it is).
>>>>>>> >>>>>> Both UML and s390 (in the !CONFIG_PCI) do not define ioremap() because
>>>>>>> >>>>>> without io memory you cannot have a ioremap().
>>>>>>> >>>>>>
>>>>> >>>>
>>>>> >>>> I assume if ioremap() return NULL, it means "without io memory", is it
>>>>> >>>> correct ?
>>>>> >>>>
>>>>> >>>> If it is correct, "define a dummy ioremap(), and return NULL" is just
>>>>> >>>> the meaning that you mentioned above.
>>>>> >>>>
>>>>> >>>> If so, for UML, it is not requirement, but recommend to define a dummy
>>>>> >>>> ioremap() which return NULL, so can be generic enough to mach all cases.
>>> >> No.
>>> >> Not setting CONFIG_HAS_IOMEM=y means "This arch has no io memory and therefore no
>>> >> functions to mess with it".
>>> >>
>> > 
>> > Since the API itself already contents the meaning: "return NULL means
>> > the arch has no related io memory",
>> > 
>> > Why not define a generic dummy one in "include/asm-generic/io.h" instead
>> > of "HAS_IOMEM" (which has already spread many various places, and also,
>> > most of new drivers have to know about it).
>> > 
>> > e.g: in "include/asm-generic/io.h", if "CONFIG_HAS_IOMEM=n", define a
>> > dummy ioremap() which return NULL ... (also need consider more details).
> Because we don't even want to build these drivers and not make them fail while
> executing io memory related functions.
> 

It is one reason, but it seems not quite enough for it, it depends on
our requirements.

If we are also the 'platform' of all kernel modules (not only for user
mode), and "include/asm-generic/*" plays an important role for it.

It is the modules their own choice to determine which architectures they
want to support, and which architecture they won't, not need be directed
or forced by 'platform'.

Also better to let kernel modules free to determine whether build in or
not, when actually do not support the specific features of architecture
currently, not need be directed or forced by 'platform'.


Thanks.
-- 
Chen Gang

Asianux Corporation
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ