Commit Graph

13 Commits

Author SHA1 Message Date
Al Viro
2b8b611e9a [PATCH] uml: cross-build support : mk_thread
mk_thread converted

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:35 -07:00
Al Viro
a31769ed3e [PATCH] uml: cross-build support : kernel_offsets
The next group of helpers is a bit trickier - they want the constants similar
to those in user-offsets.h, but we need target sc.h for it.  So we can't put
that into user-offsets (sc.h depends on it) and need the second generated
header for that stuff (kernel-offsets.h.  BFD...

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:35 -07:00
Al Viro
6bae32d395 [PATCH] uml: cross-build support: mk_sc
Ditto for mk_sc

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:34 -07:00
Al Viro
8d0b9dc9be [PATCH] uml: start cross-build support : mk_user_constants
Beginning of cross-build fixes.  Instead of expecting that mk_user_constants
(compiled and executed on the build box) will see the sizeof, etc.  for target
box, we do what every architecture already does for asm-offsets.  Namely, have
user-offsets.c compiled *for* *target* into user-offsets.s and sed it into the
header with relevant constants.  We don't need to reinvent any wheels - all
tools are already there.

This patch deals with mk_user_constants.  It doesn't assume any relationship
between target and build environment anymore - we pick all defines we need
from user-offsets.h.  Later patches will deal with the rest of mk_...  helpers
in the same way.

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:34 -07:00
Paolo 'Blaisorblade' Giarrusso
776cfebb43 [PATCH] uml kbuild: avoid useless rebuilds
- Fix some problems with usage of $(targets) (sometimes missing, sometimes
  used badly) that trigger partial rebuilds when doing a rebuild.

- At that purpose, also factor out some common code for symlinks creation.

- Fix a x86-64 build warning, caused by -L/usr/lib, which is anyway useless,
  and invalid in the x86-64 case.

Tested on x86_64 and x86.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:33 -07:00
Paolo 'Blaisorblade' Giarrusso
0c28130b5c [PATCH] x86_64: make string func definition work as intended
In include/asm-x86_64/string.h there are such comments:

/* Use C out of line version for memcmp */
#define memcmp __builtin_memcmp
int memcmp(const void * cs,const void * ct,size_t count);

This would mean that if the compiler does not decide to use __builtin_memcmp,
it emits a call to memcmp to be satisfied by the C out-of-line version in
lib/string.c.  What happens is that after preprocessing, in lib/string.i you
may find the definition of "__builtin_strcmp".

Actually, by accident, in the object you will find the definition of strcmp
and such (maybe a trick intended to redirect calls to __builtin_memcmp to the
default memcmp when the definition is not expanded); however, this particular
case is not a documented feature as far as I can see.

Also, the EXPORT_SYMBOL does not work, so it's duplicated in the arch.

I simply added some #undef to lib/string.c and removed the (now duplicated)
exports in x86-64 and UML/x86_64 subarchs (the second ones are introduced by
another patch I just posted for -mm).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
CC: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:33 -07:00
Paolo 'Blaisorblade' Giarrusso
23352fc252 [PATCH] uml: kludgy compilation fixes for x86-64 subarch modules support
These are some trivial fixes for the x86-64 subarch module support.  The only
potential problem is that I have to modify arch/x86_64/kernel/module.c, to
avoid copying the whole of it.

I can't use it verbatim because it depends on a special vmalloc-like area for
modules, which for now (maybe that's to fix, I guess not) UML/x86-64 has not.
I went the easy way and reused the i386 vmalloc()-based allocator.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:33 -07:00
Paolo 'Blaisorblade' Giarrusso
f7fe878174 [PATCH] uml: obvious compile fixes for x86-64 Subarch and x86 regression fixes
This patch does some totally trivial compilation fixes.  It also restores the
debugregs manipulation, which was commented out simply because it doesn't
compile on x86_64 (we haven't yet implemented there debugregs handling).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:32 -07:00
Stephen Rothwell
7d87e14c23 [PATCH] consolidate sys_shmat
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:59:12 -07:00
Paolo 'Blaisorblade' Giarrusso
80f9507886 [PATCH] uml: fix syscall table by including $(SUBARCH)'s one, for x86-64
Reuse asm-x86-64/unistd.h to build our syscall table, like x86-64 already
does.

Like for i386, we must add some #defines for all the (right!) changes UML does
to x86-64 syscall table.

Note: I noted a bogus:
	[ __NR_sched_yield ] = (syscall_handler_t *) yield,

while doing this patch (which could only be a workaround for some strange bug,
but I would ignore this possibility).  I'm changing this without notice.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:58:55 -07:00
Paolo 'Blaisorblade' Giarrusso
ddcd6b1757 [PATCH] uml: quick fix syscall table for x86_64
Fix the moved syscall table for the x86_64 SUBARCH:

- redirect __NR_chown and such to versions aware of 32-bit UIDs,

- avoid the useless hack for sys_nfsservctl,

- use sys_sendfile64 in the table rather than sys_sendfile.

- __NR_uselib is sys_ni_syscall on x86_64 (which does not support A.OUT).

- __NR_getrlimit is sys_getrlimit, not sys_old_getrlimit

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:58:55 -07:00
Paolo 'Blaisorblade' Giarrusso
5e7b83ffc6 [PATCH] uml: fix syscall table by including $(SUBARCH)'s one, for i386
Split the i386 entry.S files into entry.S and syscall_table.S which is
included in the previous one (so actually there is no difference between them)
and use the syscall_table.S in the UML build, instead of tracking by hand the
syscall table changes (which is inherently error-prone).

We must only insert the right #defines to inject the changes we need from the
i386 syscall table (for instance some different function names); also, we
don't implement some i386 syscalls, as ioperm(), nor some TLS-related ones
(yet to provide).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:58:55 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00