Ok, pre5 gets us in sync with most of the important and easy
to merge bits. Here's a list of whats left between the trees.
Pending:
o Bunch of __devexit changes
o Keith's text.lock -> .subsection changes
Better to merge this first and see whats left broken before merging
the __devexit changes, in case there are any more bogus ones.
o Small EISA cleanups
o Lots of driver updates for ieee1394, ISDN, network drivers, parport
& paride, USB, MTD. Hopefully the larger subsystems like USB will
get pushed by the relevant maintainers who can explain their bits
to Linus a lot better than I can.
o VM updates.
o Various documentation (Will do this last).
o A few other small things that don't fall under any specific category.
Code formatting cleanups etc..
Things unlikely to merge yet.
o Alans aacraid driver (not bio aware)
o James Simmons fbdev cleanups (needs more testing)
o Thomas Hoods PNPBIOS work (little more testing to be sure)
o sbp2 driver fixes from 2.4 (They break with bio)
o Simple Boot Flag support (more work needed)
o Small MP Table parsing changes (more testing needed)
o Reiserfs fixes.
(Waiting to hear back from the reiserfs folks that I did these ok)
Maybe:
o Various other driver fixes
Look ok, depends on next steps for bio.
o Various sound driver updates.
Worth doing these with ALSA hopefully on the way ?
o Manfreds Dynamic LDT
Needs checking that it hasn't broken x86 math-emu.
o net core updates
I'd rather leave this to davem, and see whats left over.
o Large arch updates for PPC, s390/s390x & Sparc/Sparc64
Could merge these, or wait for relevant arch maintainer
to feed maybe newer updates to Linus.
--
Dave Jones. http://www.codemonkey.org.uk
SuSE Labs.
On Mon, 31 Dec 2001 03:15:06 +0000,
Dave Jones <[email protected]> wrote:
>Ok, pre5 gets us in sync with most of the important and easy
>to merge bits. Here's a list of whats left between the trees.
>
>Pending:
>o Bunch of __devexit changes
>o Keith's text.lock -> .subsection changes
> Better to merge this first and see whats left broken before merging
> the __devexit changes, in case there are any more bogus ones.
The __devexit_p changes are required in addition to .text.lock ->
.subsection, they are fixing different parts of the same problem. Most
of the devexit_p changes were in my patch against 2.4.17-pre6, all of
those changes are needed. The only devexit changes from 2.4.17-pre6 to
2.4.17 are :-
drivers/char/synclink.c
Spurious, there is no point in specifying __init, __exit etc. on the
declaration, those attributes only affect the function body. The
change has no effect. Anybody want to go through and remove spurious
__init, __exit etc. on forward function declarations?
drivers/pcmcia/i82092.c
Mine, valid AFAICT.
drivers/isdn/hisax/hisax_fcpcipnp.c
Don't know who changed it but it is valid. hisax_fcpcipnp was added
after my first patch against 2.4.16 and I missed the new driver when
I redid the devexit_p patch for 2.4.17.
I would add all the devexit_p changes through 2.4.17 at least, in
addition to the .text.lock changes.
On Mon, 31 Dec 2001, Dave Jones wrote:
> Pending:
> o Lots of driver updates for ieee1394, ISDN, network drivers, parport
> & paride, USB, MTD. Hopefully the larger subsystems like USB will
> get pushed by the relevant maintainers who can explain their bits
> to Linus a lot better than I can.
I'll take care of ISDN. Should I include the ISDN __devexit changes, or do
you want to push all of these in one batch?
--Kai
> Things unlikely to merge yet.
> o Alans aacraid driver (not bio aware)
Thats fine. I don't plan to worry about that until 2.5 is a lot more stable.
Its more important to get the 64bit stuff tidied. I'll push that forward in
time along with the NCR5380 series changes in 2.4 that are needed before you
can even begin to fix the 5380 driver for 2.5
Alan
On Mon, 31 Dec 2001, Kai Germaschewski wrote:
> I'll take care of ISDN. Should I include the ISDN __devexit changes, or do
> you want to push all of these in one batch?
If you push all the drivers/isdn/ bits I'd rather not not worry about
that at all..
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Dec 31 2001, Alan Cox wrote:
> > Things unlikely to merge yet.
> > o Alans aacraid driver (not bio aware)
>
> Thats fine. I don't plan to worry about that until 2.5 is a lot more stable.
I'm assuming you mean stable wrt code base changes, otherwise I'd like
to hear about any instability of the kernel wrt bio.
--
Jens Axboe
> On Mon, Dec 31 2001, Alan Cox wrote:
> > > Things unlikely to merge yet.
> > > o Alans aacraid driver (not bio aware)
> >
> > Thats fine. I don't plan to worry about that until 2.5 is a lot more stable.
>
> I'm assuming you mean stable wrt code base changes, otherwise I'd like
> to hear about any instability of the kernel wrt bio.
Until I am sure the block I/O layer is totally stable and the changes to
both it and the scsi layer are complete.
On Mon, Dec 31 2001, Alan Cox wrote:
> > On Mon, Dec 31 2001, Alan Cox wrote:
> > > > Things unlikely to merge yet.
> > > > o Alans aacraid driver (not bio aware)
> > >
> > > Thats fine. I don't plan to worry about that until 2.5 is a lot more stable.
> >
> > I'm assuming you mean stable wrt code base changes, otherwise I'd like
> > to hear about any instability of the kernel wrt bio.
>
> Until I am sure the block I/O layer is totally stable and the changes to
> both it and the scsi layer are complete.
Fair enough
--
Jens Axboe