Re: [PATCH 0/32] ide-tape redux v1
On Wed, Jan 30, 2008 at 01:29:55AM +0100, Bartlomiej Zolnierkiewicz wrote: On Monday 28 January 2008, Borislav Petkov wrote: Hi Bart, [...] the BKL in idetape_write_release() with finer-grained locking etc, probably also some pipeline improvements, removal of OnStream support, etc. but that'll come later. On-Stream support has been long gone but it seems that deprecation warning etc. managed to survive. w.r.t. to the pipeline-mode: it should be pipelined into /dev/null rationale: - it is _very_ complex - causes errors to be deferred till the next user-space access - direct I/O using blk_rq_map_user() will offer superior performance the only question is whether to remove it... Well, on the one hand, since the driver is only being maintained we should not remove code that works. Also, i don't know how many users ide-tape really has but, would it be worth the trouble at all? Because if nobody's using it, we could just as well pipe the whole thing into /dev/null.. On the other hand, the This may be the other alternative... [ there is always libata PATA... ] If you want to give ide-tape removal a try, go ahead (I suggest starting with adding warning printk() and keeping patch in -mm for some time)... Well, we don't have any numbers on whether someone is using the driver at all, so i probably the best thing we should do is give it a grace period of 1/2 year before we get rid of it. In the meantime, let's see how many souls cry out :) --- commit 5b4566d1ed9b050d53d776285da84f8c3cc13d2c Author: Borislav Petkov [EMAIL PROTECTED] Date: Fri Feb 1 09:12:02 2008 +0100 ide-tape: schedule driver for removal after 6 months in case it doesn't have any users left. Signed-off-by: Borislav Petkov [EMAIL PROTECTED] diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 20c4c8b..21d71a9 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,13 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger [EMAIL PROTECTED] --- + +What: ide-tape driver +When: July 2008 +Files: drivers/ide/ide-tape.c +Why: This driver might not have any users anymore and maintaining it for no + reason is an effort no one wants to make. +Who: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED], Borislav Petkov + [EMAIL PROTECTED] + +--- diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c index f51712c..fd81f4c 100644 --- a/drivers/ide/ide-tape.c +++ b/drivers/ide/ide-tape.c @@ -3829,6 +3829,11 @@ static int ide_tape_probe(ide_drive_t *drive) g-fops = idetape_block_ops; ide_register_region(g); + printk(KERN_WARNING It is possible that this driver does not have any +users anymore and, as a result, it will be REMOVED soon. +Please notify Bart [EMAIL PROTECTED] or Boris +[EMAIL PROTECTED] in case you still need it.\n); + return 0; out_free_tape: -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/32] ide-tape redux v1
On Monday 28 January 2008, Borislav Petkov wrote: Hi Bart, [...] the BKL in idetape_write_release() with finer-grained locking etc, probably also some pipeline improvements, removal of OnStream support, etc. but that'll come later. On-Stream support has been long gone but it seems that deprecation warning etc. managed to survive. w.r.t. to the pipeline-mode: it should be pipelined into /dev/null rationale: - it is _very_ complex - causes errors to be deferred till the next user-space access - direct I/O using blk_rq_map_user() will offer superior performance the only question is whether to remove it... Well, on the one hand, since the driver is only being maintained we should not remove code that works. Also, i don't know how many users ide-tape really has but, would it be worth the trouble at all? Because if nobody's using it, we could just as well pipe the whole thing into /dev/null.. On the other hand, the This may be the other alternative... [ there is always libata PATA... ] If you want to give ide-tape removal a try, go ahead (I suggest starting with adding warning printk() and keeping patch in -mm for some time)... pipelining part _is_ kinda big and, right, it is not that straightfoward to look at it and know what it actually does - it truly is a student project :) I have pipelining code figured out to some degree but reworking it is a rather low-prio on my TODO list... [...] Anyway, resending #23 to you in a private mail. Thanks. Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/32] ide-tape redux v1
On Sunday 27 January 2008, Bartlomiej Zolnierkiewicz wrote: BTW what happend to patch #23? my bad, the patch got eaten by gmail's spam filter... - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/32] ide-tape redux v1
Hi Bart, [...] the BKL in idetape_write_release() with finer-grained locking etc, probably also some pipeline improvements, removal of OnStream support, etc. but that'll come later. On-Stream support has been long gone but it seems that deprecation warning etc. managed to survive. w.r.t. to the pipeline-mode: it should be pipelined into /dev/null rationale: - it is _very_ complex - causes errors to be deferred till the next user-space access - direct I/O using blk_rq_map_user() will offer superior performance the only question is whether to remove it... Well, on the one hand, since the driver is only being maintained we should not remove code that works. Also, i don't know how many users ide-tape really has but, would it be worth the trouble at all? Because if nobody's using it, we could just as well pipe the whole thing into /dev/null.. On the other hand, the pipelining part _is_ kinda big and, right, it is not that straightfoward to look at it and know what it actually does - it truly is a student project :) Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++ drivers/ide/Kconfig|3 +- drivers/ide/ide-tape.c | 4146 +--- 3 files changed, 1991 insertions(+), 2563 deletions(-) [...] BTW what happend to patch #23? Well, it appeared in my lkml mailbox having gone over vger which means at least somebody got it :). But, yeah, that was a real nightmare yesterday sending all those patches in one go. See, i got a stupid umts modem behind a not so transparent proxy :) whose subnet is listed in almost every spam database on the planet and whenever i try to send more than one mail i hit all sorts of mail server restrictions like yahoo's maximum messages per day crap.. Gmail seems a bit smarter ?! and scans the mail message and then says all kinds of funny stuff :): 27 10:48:31 gollum postfix/smtp[4011]: F1710123BFD: to=linux-ide@vger.kernel.org, relay=vger.kernel.org[209.132.176.167]:25, delay=10, delays=0.19/0.29/2.7/7.2, dsn=2.7.1, status=sent (250 2.7.1 Looks like Linux source DIFF email.. BF:H 1.55041e-06; S1753942AbYA0Js4) what's next, probably something like: ...(250 3.x.x uh, ok, i'm gonna relay your mail but please have another coffee, please) hash; Anyway, resending #23 to you in a private mail. -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/32] ide-tape redux v1
Hi, On Sunday 27 January 2008, Borislav Petkov wrote: Hi Bart, after a lot of hammering ide-tape got pimped pretty considerably (ca. 600 lines shorter and slicker :)). I'm sure there's more to be done like, e.g. replacing Good work. :) the BKL in idetape_write_release() with finer-grained locking etc, probably also some pipeline improvements, removal of OnStream support, etc. but that'll come later. On-Stream support has been long gone but it seems that deprecation warning etc. managed to survive. w.r.t. to the pipeline-mode: it should be pipelined into /dev/null rationale: - it is _very_ complex - causes errors to be deferred till the next user-space access - direct I/O using blk_rq_map_user() will offer superior performance the only question is whether to remove it... Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++ drivers/ide/Kconfig|3 +- drivers/ide/ide-tape.c | 4146 +--- 3 files changed, 1991 insertions(+), 2563 deletions(-) applied #1-6, #8-9, #11-20, #29, #31 #10, #24 and #25 are also fine but since they depend on other patches I couldn't merge them immediately #7 and #21 need some recasting #22 should be deferred for now #26-28, #30 and #32 are still to be reviewed BTW what happend to patch #23? Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
