Commit Graph

5 Commits

Author SHA1 Message Date
Paolo 'Blaisorblade' Giarrusso d99c4022f6 [PATCH] uml: inline mk_pte and various friends
Turns out that, for UML, a *lot* of VM-related trivial functions are not
inlined but rather normal functions.

In other sections of UML code, this is justified by having files which
interact with the host and cannot therefore include kernel headers, but in
this case there's no such justification.

I've had to turn many of them to macros because of missing declarations. While
doing this, I've decided to reuse some already existing macros.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10 12:00:18 -07:00
Jeff Dike 77fa5adcda [PATCH] uml: remove duplicated exports
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> spotted a bunch of duplicated
exports - this removes them.

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:22 -07:00
Jeff Dike 41a9cf8ebe [PATCH] uml: Export clear_user_*
From: Oleg Drokin: This patch is needed to support kernel modules that want to
use clear_user() (that is exported symbol on all other architectures).

Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-20 15:48:18 -07:00
Bodo Stroesser 5fd861b682 [PATCH] uml: s390 preparation, delay moved to arch
s390 has fast read access to realtime clock (nanosecond resolution).  So it
makes sense to have an arch-specific implementation not only of __delay, but
__udelay also.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
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:38 -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