Convert floppy98.c to use kernel min/max, like floppy.c.
diffstat:=
drivers/block/floppy98.c | 28 ++++++----------------------
1 files changed, 6 insertions(+), 22 deletions(-)
diff -Naurp ./drivers/block/floppy98.c~fd98_minmax ./drivers/block/floppy98.c
--- ./drivers/block/floppy98.c~fd98_minmax 2004-04-18 17:54:42.000000000 -0700
+++ ./drivers/block/floppy98.c 2004-04-18 18:12:38.000000000 -0700
@@ -720,25 +720,9 @@ static void reschedule_timeout(int drive
timeout_message = message;
}
-static int maximum(int a, int b)
-{
- if (a > b)
- return a;
- else
- return b;
-}
-
-#define INFBOUND(a,b) (a)=maximum((a),(b));
-
-static int minimum(int a, int b)
-{
- if (a < b)
- return a;
- else
- return b;
-}
+#define INFBOUND(a,b) (a)=max_t(int, a, b)
-#define SUPBOUND(a,b) (a)=minimum((a),(b));
+#define SUPBOUND(a,b) (a)=min_t(int, a, b)
/*
* Bottom half floppy driver.
@@ -2556,12 +2540,12 @@ static void copy_buffer(int ssize, int m
int size, i;
max_sector = transfer_size(ssize,
- minimum(max_sector, max_sector_2),
+ min(max_sector, max_sector_2),
current_req->nr_sectors);
if (current_count_sectors <= 0 && CT(COMMAND) == FD_WRITE &&
buffer_max > fsector_t + current_req->nr_sectors)
- current_count_sectors = minimum(buffer_max - fsector_t,
+ current_count_sectors = min_t(int, buffer_max - fsector_t,
current_req->nr_sectors);
remaining = current_count_sectors << 9;
@@ -2580,7 +2564,7 @@ static void copy_buffer(int ssize, int m
}
#endif
- buffer_max = maximum(max_sector, buffer_max);
+ buffer_max = max(max_sector, buffer_max);
dma_buffer = floppy_track_buffer + ((fsector_t - buffer_min) << 9);
@@ -2733,7 +2717,7 @@ static int make_raw_rw_request(void)
max_sector = 2 * _floppy->sect / 3;
if (fsector_t >= max_sector) {
current_count_sectors =
- minimum(_floppy->sect - fsector_t,
+ min_t(int, _floppy->sect - fsector_t,
current_req->nr_sectors);
return 1;
}
--
~Randy
Hi Randy,
I wonder if PC9800 fixes are worth the hassle as PC9800 merge
(AFAIR first patch went into 2.5.50!) was never finished.
I think somebody should fix it or we should just remove it completely.
Cheers,
Bartlomiej
On Monday 19 of April 2004 04:51, Randy.Dunlap wrote:
> Convert floppy98.c to use kernel min/max, like floppy.c.
>
>
> diffstat:=
> drivers/block/floppy98.c | 28 ++++++----------------------
> 1 files changed, 6 insertions(+), 22 deletions(-)
>
>
> diff -Naurp ./drivers/block/floppy98.c~fd98_minmax
> ./drivers/block/floppy98.c ---
> ./drivers/block/floppy98.c~fd98_minmax 2004-04-18 17:54:42.000000000 -0700
> +++ ./drivers/block/floppy98.c 2004-04-18 18:12:38.000000000 -0700 @@
> -720,25 +720,9 @@ static void reschedule_timeout(int drive
> timeout_message = message;
> }
>
> -static int maximum(int a, int b)
> -{
> - if (a > b)
> - return a;
> - else
> - return b;
> -}
> -
> -#define INFBOUND(a,b) (a)=maximum((a),(b));
> -
> -static int minimum(int a, int b)
> -{
> - if (a < b)
> - return a;
> - else
> - return b;
> -}
> +#define INFBOUND(a,b) (a)=max_t(int, a, b)
>
> -#define SUPBOUND(a,b) (a)=minimum((a),(b));
> +#define SUPBOUND(a,b) (a)=min_t(int, a, b)
>
> /*
> * Bottom half floppy driver.
> @@ -2556,12 +2540,12 @@ static void copy_buffer(int ssize, int m
> int size, i;
>
> max_sector = transfer_size(ssize,
> - minimum(max_sector, max_sector_2),
> + min(max_sector, max_sector_2),
> current_req->nr_sectors);
>
> if (current_count_sectors <= 0 && CT(COMMAND) == FD_WRITE &&
> buffer_max > fsector_t + current_req->nr_sectors)
> - current_count_sectors = minimum(buffer_max - fsector_t,
> + current_count_sectors = min_t(int, buffer_max - fsector_t,
> current_req->nr_sectors);
>
> remaining = current_count_sectors << 9;
> @@ -2580,7 +2564,7 @@ static void copy_buffer(int ssize, int m
> }
> #endif
>
> - buffer_max = maximum(max_sector, buffer_max);
> + buffer_max = max(max_sector, buffer_max);
>
> dma_buffer = floppy_track_buffer + ((fsector_t - buffer_min) << 9);
>
> @@ -2733,7 +2717,7 @@ static int make_raw_rw_request(void)
> max_sector = 2 * _floppy->sect / 3;
> if (fsector_t >= max_sector) {
> current_count_sectors =
> - minimum(_floppy->sect - fsector_t,
> + min_t(int, _floppy->sect - fsector_t,
> current_req->nr_sectors);
> return 1;
> }
> --
> ~Randy
On Mon, 19 Apr 2004 14:14:15 +0200 Bartlomiej Zolnierkiewicz wrote:
|
| Hi Randy,
|
| I wonder if PC9800 fixes are worth the hassle as PC9800 merge
| (AFAIR first patch went into 2.5.50!) was never finished.
|
| I think somebody should fix it or we should just remove it completely.
I agree -- completely, on all counts, and I'm trying to take that up
with Osamu Tomita, but he hasn't replied to my emails.
BTW, I have fixes for about 95% of all of the PC-9800 modules
and can successfully build a PC-9800 kernel, with IDE, SCSI,
speaker, etc. However, I can't test it. So I think that it is
fixable, but if it's been abandoned, it can also be removed.
--
~Randy
On Monday 19 of April 2004 17:51, Randy.Dunlap wrote:
> On Mon, 19 Apr 2004 14:14:15 +0200 Bartlomiej Zolnierkiewicz wrote:
> | Hi Randy,
> |
> | I wonder if PC9800 fixes are worth the hassle as PC9800 merge
> | (AFAIR first patch went into 2.5.50!) was never finished.
> |
> | I think somebody should fix it or we should just remove it completely.
>
> I agree -- completely, on all counts, and I'm trying to take that up
> with Osamu Tomita, but he hasn't replied to my emails.
:-(
> BTW, I have fixes for about 95% of all of the PC-9800 modules
> and can successfully build a PC-9800 kernel, with IDE, SCSI,
Cool, do you also have these patches?
http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/2045.html
BTW at least PC9800 IDE support needs reworking - it is one BIG hack
> speaker, etc. However, I can't test it. So I think that it is
> fixable, but if it's been abandoned, it can also be removed.
Yep, somebody needs to maintain it or at least report when it breaks.
Cheers,
Bartlomiej
On Mon, Apr 19, 2004 at 06:59:29PM +0200, Bartlomiej Zolnierkiewicz wrote:
> BTW at least PC9800 IDE support needs reworking - it is one BIG hack
Please just kill it then. PC9800 wasn't completly merged ever and there
haven't been atempts for ages. No need to stall development because of it.
On Mon, 19 Apr 2004 18:59:29 +0200 Bartlomiej Zolnierkiewicz wrote:
| On Monday 19 of April 2004 17:51, Randy.Dunlap wrote:
| > On Mon, 19 Apr 2004 14:14:15 +0200 Bartlomiej Zolnierkiewicz wrote:
| > | Hi Randy,
| > |
| > | I wonder if PC9800 fixes are worth the hassle as PC9800 merge
| > | (AFAIR first patch went into 2.5.50!) was never finished.
| > |
| > | I think somebody should fix it or we should just remove it completely.
| >
| > I agree -- completely, on all counts, and I'm trying to take that up
| > with Osamu Tomita, but he hasn't replied to my emails.
|
| :-(
|
| > BTW, I have fixes for about 95% of all of the PC-9800 modules
| > and can successfully build a PC-9800 kernel, with IDE, SCSI,
|
| Cool, do you also have these patches?
| http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/2045.html
I saw that, but I began with the latest linux98 tarball that I
could find at http://sourceforge.jp/projects/linux98/, for
2.5.67-bk9. There are still lots of build issues with that
tarball, but I have most of them fixed.
| BTW at least PC9800 IDE support needs reworking - it is one BIG hack
Not a surprise.
| > speaker, etc. However, I can't test it. So I think that it is
| > fixable, but if it's been abandoned, it can also be removed.
|
| Yep, somebody needs to maintain it or at least report when it breaks.
Yup.
--
~Randy
On Mon, 19 Apr 2004 18:05:22 +0100 Christoph Hellwig wrote:
| On Mon, Apr 19, 2004 at 06:59:29PM +0200, Bartlomiej Zolnierkiewicz wrote:
| > BTW at least PC9800 IDE support needs reworking - it is one BIG hack
|
| Please just kill it then. PC9800 wasn't completly merged ever and there
| haven't been atempts for ages. No need to stall development because of it.
Is some development stalled because of it?
The current (status quo) isn't good.
It either needs to be fixed or removed.
--
~Randy
On Monday 19 of April 2004 20:05, Randy.Dunlap wrote:
> On Mon, 19 Apr 2004 18:05:22 +0100 Christoph Hellwig wrote:
> | On Mon, Apr 19, 2004 at 06:59:29PM +0200, Bartlomiej Zolnierkiewicz wrote:
> | > BTW at least PC9800 IDE support needs reworking - it is one BIG hack
> |
> | Please just kill it then. PC9800 wasn't completly merged ever and there
> | haven't been atempts for ages. No need to stall development because of
> | it.
>
> Is some development stalled because of it?
Well, for IDE there are bigger problems than PC9800... ;-)
> The current (status quo) isn't good.
> It either needs to be fixed or removed.
Yep, there is no doubt that it slow downs development,
i.e. recent i386 standard resources fixups/cleanups.
Bartlomiej