| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <46E24177.7070702@leemhuis.info> Date: Sat, 08 Sep 2007 08:30:15 +0200 From: Thorsten Leemhuis <fedora@...mhuis.info> To: Takashi Iwai <tiwai@...e.de> CC: Thorsten Leemhuis <fedora@...mhuis.info>, Romano Giannetti <romano@....icai.upcomillas.es>, Andrew Morton <akpm@...ux-foundation.org>, roger@...puter-surgery.co.uk, linux-kernel@...r.kernel.org, perex@...e.cz Subject: Re: easy alsa patches for the stable kernel? On 08.09.2007 01:38, Takashi Iwai wrote: > At Fri, 07 Sep 2007 21:42:36 +0200, > Thorsten Leemhuis wrote: > [...] >> Sorry, but why? >> It's just this line afaics... >> + SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA), >> ...which afaics is doing nothing more then "if DMI-Data matches FOO then >> apply know workaround BAR". Is that correct or am I missing something >> here (another patch that this one depends on that isn't in 2.6.23 yet >> maybe?)? > The patch is based on the workaround codes that have been added after > 2.6.23. Thus the patch cannot work for 2.6.23 or earlier. Yeah, that's why I said: you are in the best position to route patches to stable and why I didn't send the patch for my particular problem to the stable maintainers myself. ;-) But there are now and then patches that just take care of applying already known workarounds on specific machines automatically by adding the proper DMI informations; here are some from 2.6.23 which might IMHO would be of interest for 2.6.22.x as well: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8f41b56645f03e6f50407211d6f0f0627ae95e4e http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=febe3375ea690a6cf544c33fa0fea1a06ff451ee http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8481da5a8d009d9bbac3d1483b579940e6dd9d59 http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8f794ab27dd3c6d9965ec5434775ead23d3d7a2 http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef64adbbba1b215e8b523b50ef9d568b4bf2e1e3 http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7d87de2db2213e6e9413532445b14c92dae42c85 >>> The problem is often that I >>> want first the merge to Linus tree, and then I forget to submit to >>> stable tree when the merge takes long time in the end. (Ther merge of >>> alsa.git is too spotty, and that's another big problem for me. In >>> short, I do NOT maintain alsa.git tree at all...) >> Then I as one of all those long-time-lkml-lurkers without programming >> skills dare to say that maybe the alsa-project might need to improve its >> workflow? Maybe you guys should maintain two git-trees (or multiple >> branches in one tree; sorry, I'm not a git expert and not sure what the >> correct terms are)? > We do have different branches, too. Most fix patches are usually in > the branch to be pushed (although they are rarely done). Well, the latter is IMHO one problem. > But, the point is that I am no official subsystem maintainer. Well, I suppose he reads LKML now and then as well? > I have an access right to add the patches to ALSA HG tree, which is > converted to git tree automatically. So, eventually, 90% of patches > come from me. But, the maintenance of git tree and push request are > out of my hand. It's a frustrating situation to me, too. Yeah, I can feel your pain. >> some will just say "linux sucks" and switch back to some other OS -- >> especially if they never have heard of alsa or don't really know what a >> kernel really is or does. > > Linux will suck really if one breaks so-called stable thing easily > without actually testing. For stable stuff, "it should be good" isn't > enough. It must be: "it IS good." Linux IMHO will suck even more if crucial pieces of hardware does not work for people easily, because Linux won't get even used then and will frustrate people. Don't get me wrong; I understand and agree mostly to the points you raised. But we nevertheless need to find a way to make todays hardware usable more quickly, as that hardware is often on the market only for some months or a year until the successor-model replaces it (which might need new drivers or workarounds) -- but it sometimes even for small alsa-fixes takes as many months to make it from the developers out to the kernel and from there to the distributions the user uses. It works better in some areas of the kernels (SATA and Network drivers come to my mind) where patches make it quicker into the linus- and stable-kernels -- in parts that is due to better cooperation with the hardware-vendors, but it seems the sub-tree maintainers have a better patch-/workflow, which has a strong impact as well. > [...] CU knurd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists