2000-11-08 23:00:59

by Alan Cox

[permalink] [raw]
Subject: Linux 2.4.0test11pre1ac1

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


2000-11-08 23:38:46

by Jeff Garzik

[permalink] [raw]
Subject: Re: Linux 2.4.0test11pre1ac1

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 |

2000-11-08 23:57:47

by Alan Cox

[permalink] [raw]
Subject: Re: Linux 2.4.0test11pre1ac1

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


2000-11-09 01:04:43

by David Miller

[permalink] [raw]
Subject: Re: Linux 2.4.0test11pre1ac1

Date: Wed, 8 Nov 2000 23:01:50 +0000 (GMT)
From: Alan Cox <[email protected]>

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
[email protected]

2000-11-09 03:14:15

by Dan Browning

[permalink] [raw]
Subject: VPN Masquerade patch going into 2.2.18final?

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

2000-11-09 13:09:23

by Alan Cox

[permalink] [raw]
Subject: Re: VPN Masquerade patch going into 2.2.18final?

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