12:47 p.m.
I'm thinking we can probably drop some stuff from the spec.
Any thoughts on these ?
- Some of the requires/conflicts are ancient, and kinda pointless to keep around
(they reach back to rhl days)
- We still have some xen cruft in there. We're not going to be building xen kernels
from HEAD any time soon, so why bother?
- kdump is kind of a disaster, it's never worked in fedora afair.
jarod was poking at it from a rhel context, but I doubt he has the time to maintain
it fulltime in fedora. lets just drop it all ?
- the sparse stuff was fun for a while, but I don't think anyone uses it any more.
- there's no more mkinitrd in f14, so dracut or gtfo ?
I've got some other ideas too, but this is a start.
Dave
1:24 p.m.
Dave Jones wrote:
I'm thinking we can probably drop some stuff from the spec.
Any thoughts on these ?
- Some of the requires/conflicts are ancient, and kinda pointless to keep around
(they reach back to rhl days)
- We still have some xen cruft in there. We're not going to be building xen kernels
from HEAD any time soon, so why bother?
- kdump is kind of a disaster, it's never worked in fedora afair.
jarod was poking at it from a rhel context, but I doubt he has the time to maintain
it fulltime in fedora. lets just drop it all ?
there was a side discussion to update kdump in fedora, including
kexec-tools..
so we would like to keep kdump in the fedora tree if possible.
- the sparse stuff was fun for a while, but I don't think anyone
uses it any more.
- there's no more mkinitrd in f14, so dracut or gtfo ?
I've got some other ideas too, but this is a start.
Dave
_______________________________________________
kernel mailing list
kernel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
1:33 p.m.
On Tue, 2010-06-08 at 14:24 -0400, Linda Wang wrote:
Dave Jones wrote:
> I'm thinking we can probably drop some stuff from the spec.
> Any thoughts on these ?
>
> - Some of the requires/conflicts are ancient, and kinda pointless to keep around
> (they reach back to rhl days)
> - We still have some xen cruft in there. We're not going to be building xen
kernels
> from HEAD any time soon, so why bother?
> - kdump is kind of a disaster, it's never worked in fedora afair.
> jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
> it fulltime in fedora. lets just drop it all ?
>
there was a side discussion to update kdump in fedora, including
kexec-tools..
so we would like to keep kdump in the fedora tree if possible.
I'd like to see an existence proof of it working first.
- ajax
7:22 p.m.
I'd like to see an existence proof of it working first.
I
got it basically working for the kvm guest - ide based after applied patches for
kexec-tools from RHEL6,
https://bugzilla.redhat.com/show_bug.cgi?id=597588
and hit a possible module-init-tools bug that jcm just fixed it in RHEL6,
https://bugzilla.redhat.com/show_bug.cgi?id=597579
C.
1:46 p.m.
Dave Jones (davej(a)redhat.com) said:
- kdump is kind of a disaster, it's never worked in fedora
afair.
jarod was poking at it from a rhel context, but I doubt he has the time to maintain
it fulltime in fedora. lets just drop it all ?
...
- there's no more mkinitrd in f14, so dracut or gtfo ?
Actually, why can't/shouldn't the kdump stuff use dracut?
Bill
1:52 p.m.
On 06/08/2010 02:46 PM, Bill Nottingham wrote:
Dave Jones (davej(a)redhat.com) said:
> - kdump is kind of a disaster, it's never worked in fedora afair.
> jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
> it fulltime in fedora. lets just drop it all ?
...
> - there's no more mkinitrd in f14, so dracut or gtfo ?
Actually, why can't/shouldn't the kdump stuff use dracut?
It absolutely should if we keep it at all.
--
Peter
Power corrupts. Absolute power is kind of neat.
-- John Lehman, Secretary of the Navy, 1981-1987
2:44 p.m.
On Tue, Jun 08, 2010 at 02:52:52PM -0400, Peter Jones wrote:
On 06/08/2010 02:46 PM, Bill Nottingham wrote:
> Dave Jones (davej(a)redhat.com) said:
>> - kdump is kind of a disaster, it's never worked in fedora afair.
>> jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
>> it fulltime in fedora. lets just drop it all ?
> ...
>> - there's no more mkinitrd in f14, so dracut or gtfo ?
>
> Actually, why can't/shouldn't the kdump stuff use dracut?
It absolutely should if we keep it at all.
We have an additional config mechansim that uses dracut thats partially
complete. I've been meaning to finish it forever, but have never gotten around
to it, because there was always something higher priority in the way in making
kexec function on RHEL.
As for keeping it, lets clarify what exactly we're talking about here: the
kexec bits in the spec file that Dave is referring to are completely useless
now, yes, and can be removed. but the kexec-tools package and the kdump
infrastructure that goes with it does work in several cases. Its broken in alot
of cases (mostly because no one tests it, I've gotten 36 legitimate kexec bugs
in fedora since Fedora 7, most of those from partners who opened them at the
same time as a corresponding RHEL bug). But it does work in several use cases,
and can work in more if we have the users to test them, and the time to fix
issues they report.
So, what exactly are we talking about here Dave: removing the kexec bits from
the kernel spec file, or the entire user space package? I vote yes to the former, and
absolutely not to the latter.
Neil
3:31 p.m.
On Tue, Jun 08, 2010 at 03:44:08PM -0400, Neil Horman wrote:
So, what exactly are we talking about here Dave: removing the kexec
bits from
the kernel spec file, or the entire user space package? I vote yes to the former, and
absolutely not to the latter.
Yes, just the kernel spec file. The userspace bits I couldn't care less about.
(well, I'd care more if it worked, last time I looked it didn't, though that was
a year or so back)
Dave
3:37 p.m.
On Tue, Jun 08, 2010 at 04:31:48PM -0400, Dave Jones wrote:
On Tue, Jun 08, 2010 at 03:44:08PM -0400, Neil Horman wrote:
> So, what exactly are we talking about here Dave: removing the kexec bits from
> the kernel spec file, or the entire user space package? I vote yes to the former,
and
> absolutely not to the latter.
Yes, just the kernel spec file. The userspace bits I couldn't care less about.
(well, I'd care more if it worked, last time I looked it didn't, though that was
a year or so back)
Dave
Ok, ACK to removing the kernel bits relating to kexec, they're completely
useless right now
As for the user space stuff, it works in some cases, not in others. Sadly the
cases in which it doesn't work, tend to be very sensitive to the conditions in
which its setup (i.e. a standard network interface scp works, an scp of a core
over a bridge that has a bond as the selected output interface, not so much).
Its also pretty dependent on hardware. x86_64 usualy can be made to work, while
ppc64 is just completely borked). Anywho, as mentioned dracut will help with
alot of this, if we can get that config system done.
What will help more than anything else is testing and bug reporting. Theres way
to much stuff for me to test myself, so if anyone has a need for kdump, please
use it, otherwise its just going to keep hobbling along as best it can.
Neil
1:55 p.m.
On Tue, Jun 08, 2010 at 02:46:54PM -0400, Bill Nottingham wrote:
Dave Jones (davej(a)redhat.com) said:
> - kdump is kind of a disaster, it's never worked in fedora afair.
> jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
> it fulltime in fedora. lets just drop it all ?
...
> - there's no more mkinitrd in f14, so dracut or gtfo ?
Actually, why can't/shouldn't the kdump stuff use dracut?
The with_kdump stuff we have in the spec now doesn't do anything at all afaict.
It hasn't since we stopped building ppc64-kdump.
The mechanism for how kdump works is unrelated, this is all just cruft for
building a special kernel from when it wasn't relocatable. The only arch
that still has that affliction is s390 apparently, and well.. fedora-s390? really?
Dave
1:58 p.m.
On Tue, Jun 8, 2010 at 2:55 PM, Dave Jones <davej(a)redhat.com> wrote:
On Tue, Jun 08, 2010 at 02:46:54PM -0400, Bill Nottingham wrote:
> Dave Jones (davej(a)redhat.com) said:
> > - kdump is kind of a disaster, it's never worked in fedora afair.
> > jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
> > it fulltime in fedora. lets just drop it all ?
> ...
> > - there's no more mkinitrd in f14, so dracut or gtfo ?
>
> Actually, why can't/shouldn't the kdump stuff use dracut?
The with_kdump stuff we have in the spec now doesn't do anything at all afaict.
It hasn't since we stopped building ppc64-kdump.
The mechanism for how kdump works is unrelated, this is all just cruft for
building a special kernel from when it wasn't relocatable. The only arch
that still has that affliction is s390 apparently, and well.. fedora-s390? really?
Yeah, the with_kdump bits should probably all be obsolete now, we have
relocatable kernels for all arches Fedora is built for (and possibly
even for ppc64 now? not sure...), and s390 doesn't *really* build a
true kdump kernel iiuc, its zfcpdump, which we're not going to patch
in on top of Fedora. I can take a look at the spec bits if you like to
double-check, but I'm pretty sure it can all go away w/o causing any
problems anywhere.
--
Jarod Wilson
jarod(a)wilsonet.com
2 p.m.
Dave Jones wrote:
On Tue, Jun 08, 2010 at 02:46:54PM -0400, Bill Nottingham wrote:
> Dave Jones (davej(a)redhat.com) said:
> > - kdump is kind of a disaster, it's never worked in fedora afair.
> > jarod was poking at it from a rhel context, but I doubt he has the time to
maintain
> > it fulltime in fedora. lets just drop it all ?
> ...
> > - there's no more mkinitrd in f14, so dracut or gtfo ?
>
> Actually, why can't/shouldn't the kdump stuff use dracut?
The with_kdump stuff we have in the spec now doesn't do anything at all afaict.
It hasn't since we stopped building ppc64-kdump.
The mechanism for how kdump works is unrelated, this is all just cruft for
building a special kernel from when it wasn't relocatable. The only arch
that still has that affliction is s390 apparently, and well.. fedora-s390? really?
ah.. totally misunderstood your email. never mind, please feel free...
Dave
_______________________________________________
kernel mailing list
kernel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kernel
1:57 p.m.
- the sparse stuff was fun for a while, but I don't think anyone
uses it any more.
Do you mean sparse isn't really used upstream any more? If you just mean
that people haven't been doing rpmbuild --with-sparse much, then that
doesn't seem like a reason to remove the spec stuff for it. It's really
only a few lines and does not confuse the rest of the macro weirdness.
2:04 p.m.
On Tue, Jun 08, 2010 at 11:57:56AM -0700, Roland McGrath wrote:
> - the sparse stuff was fun for a while, but I don't think
anyone uses it any more.
Do you mean sparse isn't really used upstream any more? If you just mean
that people haven't been doing rpmbuild --with-sparse much, then that
doesn't seem like a reason to remove the spec stuff for it. It's really
only a few lines and does not confuse the rest of the macro weirdness.
I meant anyone who is using in typically isn't doing rpmbuilds.
Dave
2:07 p.m.
another one caught my eye..
379 %if %{nopatches}
380 # XXX temporary until last vdso patches are upstream
381 %define vdso_arches ppc ppc64
382 %endif
Is this stale ? It's been 'temporary' for almost three years.
Dave
3:29 p.m.
On Tue, Jun 08, 2010 at 12:29:59PM -0700, Roland McGrath wrote:
> another one caught my eye..
>
> 379 %if %{nopatches}
> 380 # XXX temporary until last vdso patches are upstream
> 381 %define vdso_arches ppc ppc64
> 382 %endif
>
> Is this stale ? It's been 'temporary' for almost three years.
Yup.
what about the rest of the vdso_arch stuff ? want to clean that out ?
or do we need all the rest ?
Dave
6:12 p.m.
what about the rest of the vdso_arch stuff ? want to clean that out
?
or do we need all the rest ?
There is nothing obsolete about it. Upstream only arch/x86, arch/powerpc,
and arch/s390 have a vdso_install target. Other arch's that have a vdso
(ia64, mips, sh) ought to grow a vdso_install target too. (Or perhaps
upstream would now be happy with rolling that into modules_install so we
don't have to keep track of which ones support it, but I haven't asked.)
Other machines like sparc, alpha, arm don't have a vdso at all. If they
grew one in future they should grow a vdso_install target to go with it.
But unless we change more of how we do the file lists, we'd still need some
%ifarch-based conditionalization for the file list part.
Thanks,
Roland
5067
days inactive
5068
days old
kernel@lists.fedoraproject.org
18 comments
9 participants
participants (9)
-
Adam Jackson -
Bill Nottingham -
CAI Qian -
Dave Jones -
Jarod Wilson -
Linda Wang -
Neil Horman -
Peter Jones -
Roland McGrath