From: bame@riverrock.org
To: parisc-linux@puffin.external.hp.com
Subject: Re: [parisc-linux] kernel merge
Date: Fri, 10 Nov 2000 14:28:33 -0700 [thread overview]
Message-ID: <m13uLiv-001Vp3C@chalet> (raw)
In-Reply-To: Your message of "Thu, 09 Nov 2000 11:47:51 MST." <E13twjn-0004fw-00@noam.fc.hp.com>
=
= We're getting ready to do a kernel merge (to -test10 I think). Anybody
= concerns before we get started?
=
I'm getting ready to commit the changes to merge us up to 2.4.0-test10 as
soon as I'm confident 64-bit kernels are OK (32-bit seems fine).
Here's a brief list of changes made (and yet to be made -- if anyone
has the time/energy) to our parisc code (does not include changes in
common code!). While there's plenty yet to do, I think we're
no worse off than before the merge. Some parts of our parisc code
are getting rather moldy compared to the other ports FYI.
Important tags:
LINUS_240_TEST6 Linus' 2.4.0-test6
LINUS_240_TEST10 Linus' 2.4.0-test10
LINUS_240_TEST10_PREMERGE Our tree before the -test10 merge
LINUS_240_TEST10_MERGED Our tree after the -test10 merge
------------
Lots of 'extern __inline__' turned into 'static __inline__' and there
are more to do (TODO).
Beginnings of several smp_mb*() macros -- implemented as no-ops in
the non-SMP case (asm/bitops.h, asm/system.h)
SET_PERSONALITY() macro in asm/elf.h needs updating (TODO).
fcntl.h acquired a 'struct fcntl64' used with 64-bit offsets, implementing
fcntl(fd, F_S/GETLK[W]64, ...). Several other locking-related #defines added.
asm/mmu_context.h:init_new_context() now returns int (always 0), not void.
Should our asm/bitops.h routines be re-coded in assembly? (TODO)
Added #define RLIMIT_LOCKS to asm/resource.h
Added #define CLOCKS_PER_SEC to asm/param.h (how did we miss this one?)
Our asm/string.h is behind the times. Fixing it might get rid of a
bunch of compiler warnings! (TODO)
Removed mktime from drivers/char/genrtc.c (it's in a header file now)
x86 made a bunch of changes to asm-i386/floppy.h -- should we? (TODO)
looks like maybe the get/put_user_ret() functions in asm/uaccess.h are
obsolete? (TODO)
We'll need to add the getdents64() and fcntl64() syscall glue. (TODO!!!)
Our arch/parisc/config.in is in BAD SHAPE (TODO)
arch/parisc/process.c: added new argsto do_fork() and copy_thread().
IA64 seems to use the copy_thread() arg.
arch/parisc/signal.c: minor change to common data structure
drivers/scsi sym53c8xx_comm.h #ifdef doesn't work on parisc -- eliminates
unmap_pci_mem() causing link error (TODO - rhirst)
next prev parent reply other threads:[~2000-11-10 21:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-09 18:47 [parisc-linux] kernel merge Paul Bame
2000-11-10 21:28 ` bame [this message]
2000-11-11 2:18 ` Randolph Chung
2000-11-13 0:25 ` bame
2000-11-13 2:20 ` bame
2000-11-13 7:32 ` Helge Deller
2000-11-13 12:13 ` Richard Hirst
2000-11-13 22:54 ` sym53c8xx-driver (was: Re: [parisc-linux] kernel merge) Helge Deller
2000-11-13 23:27 ` Richard Hirst
2000-11-14 0:13 ` Helge Deller
2000-11-14 10:17 ` Richard Hirst
2000-11-14 13:11 ` Helge Deller
2000-11-14 16:10 ` [parisc-linux] dino maintainer? Grant Grundler
2000-11-15 9:58 ` Richard Hirst
2000-11-15 16:06 ` Grant Grundler
2000-11-15 16:50 ` Alex deVries
2000-11-15 16:17 ` Grant Grundler
2000-11-15 22:19 ` Richard Hirst
2000-11-14 10:29 ` [parisc-linux] kernel merge Matthew Wilcox
2000-11-14 17:02 ` Paul Bame
2000-11-14 17:14 ` Paul Bame
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m13uLiv-001Vp3C@chalet \
--to=bame@riverrock.org \
--cc=parisc-linux@puffin.external.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.