* H. Peter Anvin wrote:
> > Such an extended header could use a more modern (self-extending) ABI as
> > well.
>
> Yes, although I don't really think it is as much of an issue as it seems at
> this point.
>
> The limit comes from having used a one-byte jump instruction at the beginning;
>
* H. Peter Anvin wrote:
> On 11/9/18 5:40 AM, Li Zhijian wrote:
> > Just noticed that there is a field xloadflags at recent protocol
> > 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> > extension fields
> > 61 to struct boot_params for loading bzImage and
* Li Zhijian wrote:
> > If the kernel initrd creation process creates an initrd which
> > is larger than 2GB and also claims that it can't be placed
> > with any part of it above 2GB, then that sounds like a bug
> > in the initrd creation process...
>
> Exactly, it's a real problem.
>
> Add
* Anca Emanuel anca.eman...@gmail.com wrote:
I'd even argue that that C library is obviously something the
kernelshould offer as well - so klibc is the way to go and would
help usfurther streamline this and keep Linux quality high.
I think there is code to share. Why not ?
The biggest
* Alexander Graf ag...@suse.de wrote:
[...]
Outside of the kernel tree, you can do your own decisions. If
someone thinks it's a great idea to write device emulation in
python (I would love that!), he could go in and implement it
without having to worry about Linus possibly rejecting it
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I have to disagree; my main worry is that integration
* Ted Ts'o ty...@mit.edu wrote:
On Tue, Nov 08, 2011 at 07:14:57PM +0200, Anca Emanuel wrote:
@Ten Ts'o: you are sponsored by something like microsoft (joking)
? Stop trolling. If you are not familiar with perf, or other
tools, save your time and do some useful things.
I am quite
* John Kacur jka...@redhat.com wrote:
On Tue, 8 Nov 2011, Ted Ts'o wrote:
On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
I guess you can do well with a split project as well - my main
claim is that good compatibility comes *naturally* with
integration.
Here I
* Gerd Hoffmann kra...@redhat.com wrote:
For reference, the default set of colors now is (from
tools/perf/util/ui/browser.c):
static struct ui_browser__colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
sure the colors have enougth contrast so they are readable.
Problem is figuring out something that is considered a good default
:-\ There will always be somebody that will complain.
When doing the coding to allow using the default xterm
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, Nov 08, 2011 at 10:32:25AM +0100, Ingo Molnar wrote:
None of the perf developers with whom i'm working complained
about the shared repo so far - publicly or privately. By all
means they are enjoying it and if you look at the stats
* Arnaldo Carvalho de Melo a...@redhat.com wrote:
Em Wed, Nov 09, 2011 at 10:30:50AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Wed, Nov 09, 2011 at 01:26:34PM +0100, Gerd Hoffmann escreveu:
Its fully configurable as of now, what we need is a set of .perfconfigs
that show how people
* Américo Wang xiyou.wangc...@gmail.com wrote:
On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar mi...@elte.hu wrote:
So i think you should seriously consider moving your projects
*into* tools/ instead of trying to get other projects to move out
...
You should at least *try* the unified
* Theodore Tso ty...@mit.edu wrote:
On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote:
The kernel ecosystem does not have to be limited to linux.git.
There could be a process to be a kernel.org project for
projects that fit a certain set of criteria. These projects
could all
* Ted Ts'o ty...@mit.edu wrote:
I don't believe there's ever been any guarantee that perf test
from version N of the kernel will always work on a version N+M of
the kernel. Perhaps I am wrong, though. If that is a guarantee
that the perf developers are willing to stand behind, or have
* Peter Zijlstra a.p.zijls...@chello.nl wrote:
The ABI yes, the tool no, the tool very much relies on some newer
ABI parts. Supporting fallbacks isn't always possible/wanted.
Yeah, sure - and an older tool cannot possibly support newer features
either.
Thanks,
Ingo
* Vince Weaver vi...@deater.net wrote:
On Mon, 7 Nov 2011, Ingo Molnar wrote:
I think we needed to do only one revert along the way in the past
two years, to fix an unintended ABI breakage in PowerTop.
Considering the total complexity of the perf ABI our
compatibility track record
* Pekka Enberg penb...@cs.helsinki.fi wrote:
[...] There's an easy fix for this too: improve perf test to
cover the cases you're intested in. While ABI spec would be a nice
addition, it's not going to make compatibility problems magically
go away.
Yes, exactly - 'perf test' has been
* Theodore Tso ty...@mit.edu wrote:
On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote:
No ifs and when about it, these are the plain facts:
- Better features, better ABIs: perf maintainers can enforce clean,
functional and usable tooling support *before* committing to an
ABI
* Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Tue, 2011-11-08 at 13:15 +0100, Ingo Molnar wrote:
The one notable thing that isnt being tested in a natural way is
the 'group of events' abstraction - which, ironically, has been
added on the perfmon guys' insistence. No app beyond
* Pekka Enberg penb...@cs.helsinki.fi wrote:
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development
process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and
* Vince Weaver vi...@deater.net wrote:
On Mon, 7 Nov 2011, Pekka Enberg wrote:
I've never heard ABI incompatibility used as an argument for
perf. Ingo?
Correct, the ABI has been designed in a way to make it really hard to
break the ABI via either directed backports or other mess-ups.
* Jan Kiszka jan.kis...@siemens.com wrote:
Ingo Molnar pointed out that sending the timer signal to the whole
process, just blocking it everywhere, is suboptimal with an increasing
number of threads. QEMU is using this pattern so far.
But Linux provides a (non-portable) way to restrict
23 matches
Mail list logo
