linux-kernel - Re: [x86 patch] Fix UML signal.h build errors

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:	Sat, 27 Oct 2007 07:38:49 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Balbir Singh <balbir@...ux.vnet.ibm.com>
Cc:	Jeff Dike <jdike@...toit.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	hpa@...or.com
Subject: Re: [x86 patch] Fix UML signal.h build errors

On Sat, Oct 27, 2007 at 11:35:10AM +0530, Balbir Singh wrote:
> > b) I'd rather have __arch_um__ mentioned explicitly in 3 places where
> > we do care about difference between i386 and uml/i386 than have certain
> > to be forgotten rules for places like include/asm-x86
> > 
> > c) if you look at those places, you'll see
> > 	* drivers/char/mem.c::uncached_access().  Really per-architecture
> > and I wonder if it might be include/asm-* fodder...
> > 	* kernel/signal.c debugging printks.  Should die or be sanitized, IMO.
> > 	* raid6 algorithms.  Hell knows - immediate reason why we don't do
> > those on uml is the lack of kernel_fpu_begin()/kernel_fpu_end() (and
> > boot_cpu_has(), but that's easier to add).  Do we care to implement that
> > stuff?

> I suspect that list might grow and anybody writing i386 or x86_64 code
> will need to double check if the code will work under __arch_um__.
> Probably worth documenting somewhere.

For x86-only code it's not really a problem - i.e. if we pull it into
uml build at all, checks for BITS_PER_LONG/__i386__/CONFIG_64BIT/etc.
are all the same.  For arch-dependent drivers... we have very good
reasons not pull them into uml builds anyway.  And arch-independent
code shouldn't care at all, so we are left with random bits of arch-dependent
code ifdefed in generic one _and_ not handled via asm/*.h.  I.e. with very
few odd cases - it's not that we wanted to add and keep such places anyway,
uml or no uml.

I'd say that raid6 is the only legitimate current case and even that is
somewhat dubious - we might e.g. not bother with x86-only parts of
raid456-objs on other targets and handle that on Kconfig/Makefile level.
-
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/