merge in progress.

merge in progress.

[Dave Jones]

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.

Re: merge in progress.

[Keith Owens]

On Mon, 31 Dec 2001 03:15:06 +0000, 
Dave Jones <davej@suse.de> 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.

Re: merge in progress.

[Kai Germaschewski]

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

Re: merge in progress.

[Dave Jones]

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

Re: merge in progress.

[Alan Cox]

> 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

Re: merge in progress.

[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.

-- 
Jens Axboe

Re: merge in progress.

[Alan Cox]

> 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.

Re: merge in progress.

[Jens Axboe]

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