Linux 2.4.0test11pre1ac1

Linux 2.4.0test11pre1ac1

[Alan Cox]

This is the patches I have in my pending/twiddled with pile at the moment.
I'll also send bits of this off to Linus

Whats different

o	Ramfs allows size limiting (very handy when fiddling with PDA's)
o	Knows the 'kgcc' convention for conectiva/mandrake/red hat
o	Build ACPI if you have ACPI but no interpreter
o	Tidy up naming on machine check code
o	36bit MTRR
o	Fix PIV ident bug
o	Fix K6 CPU on dual board crash
o	Much faster block copy functions on the Athlon
o	Fix daemonize to do exit_files. All callers do this or should do
	anyway
o	Cpqarray procfs fix
o	Fix build bug with old hard disk driver
o	Fix free then reference with pcbit isdn
o	Check/requestion region clean for radio drivers
o	Cleaner version of the PnP cadet radio patch
o	Seperate tx timeout code for 8390
o	Network driver request region fixes
o	de4x5 user space copy in spinlock fix
o	epic100 delay fixes
o	Avoid crash on iph5526 on out of memory
o	Fix locking bugs on roadrunner
o	Fix crash on insmod risk with many scsi drivers
o	Fix incorrect runtime panics in some scsi drivers
o	Fix HZ in the aha152x driver
o	Remove escaped and dead check for I2O in megaraid
o	Fix i810 audio driver
o	Fix cramfs initrd data loss bug
o	Fix power management locking
o	Fix resource printks that only print 4 digits
o	Fix missing return value in atm pvc
o	Disable SPX (doesnt work, no maintainer etc)

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0test11pre1ac1

[Jeff Garzik]

the network driver changes look ok except for:
epic100:
* CARDBUS is never defined.  Should that be CONFIG_CARDBUS?
* just increment the version number.  There's no need to add "a" on the
end...  this version number just differentiates us from the 'canonical'
Donald Becker version of epic100.c.


net/atm/pvc:  return the error value from sock_register, not toss it
away.


ramfs comments:
* Hang on to the ramfs changes for a day or two, there is kmap cleanup
(now returns void*) going to Linus RSN.
* Does ramfs_statfs() need that sb lock in it?  Sure free_pages/inodes
might be getting updated on some other CPU, but its statfs so who
cares...
* the default ramfs maxsize, half of all RAM, seems a little
conservative.
* there is no need to kmalloc a private superblock structure, when room
is already allocated inside the superblock structure for private data. 
(sb->u)
* 


I wonder if we really need removepage added to struct address_space? 
That's one API change we shouldn't throw in without discussion, IMHO...
it screams "ramfs-specific hack in core code!"
 void __remove_inode_page(struct page *page)
 {
+       struct address_space *mapping = page->mapping;
+
+       if (mapping && mapping->a_ops && mapping->a_ops->removepage)
+               mapping->a_ops->removepage(page);
+


And finally, don't you need to EXPORT_SYMBOL pm_devs_lock ?



-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0test11pre1ac1

[Alan Cox]

> * CARDBUS is never defined.  Should that be CONFIG_CARDBUS?

Yep

> * just increment the version number.  There's no need to add "a" on the
> end...  this version number just differentiates us from the 'canonical'
> Donald Becker version of epic100.c.

Ok

> net/atm/pvc:  return the error value from sock_register, not toss it
> away.

> 
> 
> ramfs comments:

Note: the ramfs changes are in there for one reason only - that Im hacking
on some bits with a pda type box and I cannot be bothered to keep two
sets of trees

> That's one API change we shouldn't throw in without discussion, IMHO...
> it screams "ramfs-specific hack in core code!"

Absolutely

> And finally, don't you need to EXPORT_SYMBOL pm_devs_lock ?

Yep


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

VPN Masquerade patch going into 2.2.18final?

[Dan Browning]

Would you care to comment on the VPN Masquerade patch that has been
floating around?  Will it make it into an official 2.2.x kernel soon?  The
VPN-Masq HOWTO seems to think it is going into 2.2.18 proper.

ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn-2.2.17.patch.gz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: VPN Masquerade patch going into 2.2.18final?

[Alan Cox]

> Would you care to comment on the VPN Masquerade patch that has been
> floating around?  Will it make it into an official 2.2.x kernel soon?  The
> VPN-Masq HOWTO seems to think it is going into 2.2.18 proper.

There is already more than enough in 2.2. The code is on my pending queue
(some of it anyway)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0test11pre1ac1

[David S. Miller]

   Date: 	Wed, 8 Nov 2000 23:01:50 +0000 (GMT)
   From: Alan Cox <alan@lxorguk.ukuu.org.uk>

   o	Fix incorrect runtime panics in some scsi drivers

In drivers/scsi/fcal.c you correctly free "ages", in the
equivalent drivers/scsi/pluto.c fix you forget to do this.

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/