Commit Graph

7 Commits

Author SHA1 Message Date
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