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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox