Hi Linus,
I have 19 patches for you, all of them affect only s390. The patches are
against todays bitkeeper tree. I've seen that 32 bit dev_t are finally
in. We'll have another patch for dasd soon :-))
Short descriptions:
1) The usual base bug fix collection for s390.
2) Bug fixes/improvements for the common i/o layer.
3) 31 bit compatability fixes.
4) Some micro optimizations.
5) Fix for the system tick misaccounting problem. LPAR and VM have the
tedious habit to deliver timer ticks after i/o interrupts if they
are close enough together although the timer interrupt arrived first.
In some szenarios (network benchmarks) this happens all the time and
this leads to high system time numbers although the system is mostly
idle.
6) Restarting of system calls crashes if the svc instruction was done via
an execute instruction.
7) Make use of sysfs_create_group.
8) Kconfig update. Arnd added a condition to BLK_DEV_FD in
drivers/block/Kconfig so that we can use it in the s390 config.
In addition the s390 block device configs now reside in
drivers/s390/block/Kconfig where they belong.
9) Guillaume Morin tested xpram on a 64 bit machine and found some bugs.
10) dasd format fix. Now unformatted dasd device can be accessed with 2.6.
11) Bug fix for the dasd partition support.
12) Bug fixes for the block device interface of the tape driver.
13) Update of the ctc network driver.
14) Bug fixes and update of the iucv network driver.
15) Update of the lcs network driver.
16) Bug fixes and update of the qeth network driver.
17) Add support for vt220 console over sclp.
18) Documentation changes.
19) Remove some outdates files. The ipl boot records have been moved
to a userspace package.
blue skies,
Martin.
Hi Martin,
you missed the Makefile updates I sent you last time.
Or at least I did not see them after a quick glance.
Do you want me to send them againg?
Sam
> Short descriptions:
>[...]
Are you going to submit zfcp and zcrypt and if yes, when?
-- Pete
Hi Pete,
> Are you going to submit zfcp and zcrypt and if yes, when?
The zfcp rework is going well but isn't quite finished yet.
It's up to Heiko when he consideres the driver to be in state
for inclusion into 2.6. For the zcrypt driver the news aren't
so good. It very likely won't make it for 2.6.0.
blue skies,
Martin
> Hi Pete,
>
> > Are you going to submit zfcp and zcrypt and if yes, when?
>
> The zfcp rework is going well but isn't quite finished yet.
> It's up to Heiko when he consideres the driver to be in state
> for inclusion into 2.6. For the zcrypt driver the news aren't
> so good. It very likely won't make it for 2.6.0.
Actually, the latest z90crypt driver for 2.4.21 compiles on 2.6
with only one trivial patch (see below). The chances are good
that it works just as much as on older kernels. It's mostly
just a matter of style and the fact that there is no standard
API for linux hardware crypto driver yet that keeps us from
submitting the driver.
Arnd <><
diff -u ../linux-2.3/drivers/s390/misc/z90main.c drivers/s390/misc/z90main.c
--- ../linux-2.3/drivers/s390/misc/z90main.c 2003-08-18 18:51:14.000000000 +0200
+++ drivers/s390/misc/z90main.c 2003-09-26 13:15:49.000000000 +0200
@@ -567,7 +567,6 @@
int result,nresult;
struct proc_dir_entry * entry;
- EXPORT_NO_SYMBOLS;
PDEBUG("init_module -> PID %d\n", PID());
//
On Fri, Sep 26, 2003 at 11:32:09AM +0200, Martin Schwidefsky wrote:
> The zfcp rework is going well but isn't quite finished yet.
> It's up to Heiko when he consideres the driver to be in state
> for inclusion into 2.6. For the zcrypt driver the news aren't
> so good. It very likely won't make it for 2.6.0.
What's wrong with current zcrypt from 2.4, aside from the
reading from urandom? It looked a relatively decent driver to me.
-- Pete
> What's wrong with current zcrypt from 2.4, aside from the
> reading from urandom? It looked a relatively decent driver to me.
Reading from urandom, the ioctls are sick (linked lists in user that
are parsed by the kernel) and the timer stuff is somewhat strange
as well. Some of it has its reason in the hardware interface.
What really bothers me is
1) coding style
2) coding style
and
3) coding style.
blue skies,
Martin
Hi Sam,
> you missed the Makefile updates I sent you last time.
> Or at least I did not see them after a quick glance.
> Do you want me to send them againg?
They are still on my disk. I tried them but a simple "make"
didn't create the image. I'll have to find out whats wrong
before I'll include your patch.
blue skies,
Martin