Hi, On Thursday 13 December 2007 17:35:20 Artur Szymiec wrote: > Kel Modderman pisze: > > Package: sysvinit > > Version: 2.86.ds1-38.1 > > > > Hi, > > > > I'm following up on this ticket, since I've not received any response > > for the > > > best part of 6 months. > > > > The patch I proposed here is, IMHO, the most complete of the ones offered > > so far. Recently, I was made aware of someone also claiming [0] the > > patch [1] > > > from Werner Fink, discussed [2] on the novell bug tracker, would be > > great to > > > include into our own Debian version of sysvinit to fix the shutdown > > issue of > > > spinning down disks correctly (...or not). > > > > However, r1067 [3] was committed to pkg-sysvinit trunk, which merges the > > changes done in the "libata-fixes" branch which was for testing [4]. > > Tejun Heo, > > > an active libata/kernel hacker, replied [5] with information that > > Werner Fink > > > was also working on this issue. Tejun was also active in the development > > of the patch as seen on the novell bug discussion [2]. > > > > I emailed the list [6] with discussion requested at [4], created a > > patch for > > > the debian package [7], and tested the patch thoroughly on a very wide > > variety > > > of hardware from debian installed and live-cd environments over the last > > 6 months. The patch works as advertised. > > > > opensuse 10.3 also contains a sysvinit using the mentioned patch. This > > means > > > it has seen widespread testing from a variety of people on a variety of > > hardware. > > > > The patch matches the criteria set out at [8] about how hddown.c could > > best handle this (except using /proc): > > > > [quote] > > a) it uses sysfs and not /proc to locate disks, and that it locates > > all IDE and SCSI/libata disks, or maybe do both /proc and sysfs. > > b) that it verifies the state of kernel disk spindown control for > > each disk, and for the disks where it is unavailable: > > b1) issue cache sync to disk > > b2) issue spin down to disk > > c) for the disks where kernel spin down control is available, enable > > it and skip to next disk. > > [/quote] > > > > The patch does not suffer from limitation of an alternate patch offered > > to fix the situation that is discussed at [9], which seems to be similar > > in limitation to what has been merged [3]. > > > > Ok, there are too many damn numbers listed below with references. But > > you get > > > the picture I hope, that I'm concerned about the direction the > > maintainers [10] > > > intend to take in order to fix this issue, and that I've laid out as much > > information, patch and help that I can to try and convince them there is > > a better solution. > > > > Thanks, Kel. > > > > [0] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/0 >02141.html > > > [1] https://bugzilla.novell.com/attachment.cgi?id=145904 > > [2] https://bugzilla.novell.com/show_bug.cgi?id=229210 > > [3] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2007-November >/000955.html > > > [4] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00196 >1.html > > > [5] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00196 >3.html > > > [6] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00197 >2.html > > > [7] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00197 >4.html > > > [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224#10 > > [9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436703 > > [10] > > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/0 >02142.html > > > _______________________________________________ > > Pkg-sysvinit-devel mailing list > > [EMAIL PROTECTED] > > http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel > > Greetings, > > I've sent a patch for Debian sysv init hdd down over a month ago > (4.11.2007). > Till now I haven't receive any comment regarding it. > Could you please review it too ? > Attached files (hdd.c and a patch in attachment).
Why would I want to look up another patch to review it after already investing time recommending what I truly believe to be a comprehensive fix? This is surely the job of the maintainers to discuss the options and choose their choice of action. The trick is to solicit a response from them. If you really want me to, make it a bit easier by giving a unambiguous link to the content _and_ state what it does better in comparison to what we could inherit from Werner Fink that I've argued in favour of a long long time ago, and referenced again in the mail you replied to. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
