Re: Getting rid of sysprof-kmod
On Dec 2, 2007 8:10 AM, Dave Jones [EMAIL PROTECTED] wrote: The problem is I really hate adding patches that provide new user interfaces. I understand this concern It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel. I can't grok this sentence. what do stop working upstream if we add this? And what happens if someone starts building more things on top of the sysprof exports? Who should be this someone? Anyway, the answer looks like: he get bite when we will drop the patch. How bad is it? It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel. Of all the complaints I have seen in the past about our kernels, this never shown up, but I'm sure you collected much more than me... Point is, you are the kernel maintainer here so, though I can't fully understand your concerns, I assume they are valid and I better stop arguing on things I can not fully evaluate. So my last question for you is: how are those scenarios likely? I mean, do you see a concrete risk someone will build something on top of the current sysprof interface? It would be really a pity (and a regression) if sysprof will lack the binary module because of some recondite reason. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Getting rid of sysprof-kmod
On Dec 2, 2007 10:33 PM, David Zeuthen [EMAIL PROTECTED] wrote: What if the sysprof author offered a. to maintain the patch in the SRPM (e.g. make sure it works) This looks like an easy target; I can witness the module sources always worked since the package entered in the repo (around FC5 IIRC). The few occasional glitches were promptly fixed b. to work with upstream to either get it his patch in or migrate to another interface when available Well, last time I asked, the former was not going to happen and I fear the latter will be too late for F9... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Getting rid of sysprof-kmod
On Dec 2, 2007 1:09 AM, Dave Jones [EMAIL PROTECTED] wrote: On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote: Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above. I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package. Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/ The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches. Thanks Dave, this is an interesting information, so I am CCing the upstream author (just in case he is not subscribed to this list). Now I still wonder what to do here because: 1. it's not sure if this perfmon2 will be in Fedora kernels before F9 ships 2. sysprof has to be adapted to use perfmon2 I mean, it's clear that 1+2 it's the best thing we could come out with, but I'd like to have working sysprof in the repo until that materialize. To this end, please weight in that this is just a single module (one .c and its .h) loaded by the user only when needed. Of course, I can not argue with you about the implications of including this into the kernel package, but I really would like a B plan if we will not have a perfmon enabled kernel+userspace available in time. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
