* 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;
> how
* 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 r
* 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 x
* Alexander Graf 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 because
* Anca Emanuel 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 downside of libc
* Américo Wang wrote:
> On Tue, Nov 8, 2011 at 5:32 PM, Ingo Molnar 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
* Arnaldo Carvalho de Melo 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 thin
* Steven Rostedt 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
* Arnaldo Carvalho de Melo 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 colors I
* Gerd Hoffmann 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[] = {
> > {
> >
* John Kacur 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
* Ted Ts'o 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 familia
* 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 have to disagree
* Peter Zijlstra 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 guy
* Theodore Tso 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
* Pekka Enberg 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 written with that exa
* Vince Weaver 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
> > compatib
* Peter Zijlstra 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
* Ted Ts'o 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
> already
* Theodore Tso 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 share
* Vince Weaver 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.
The ABI is
* Pekka Enberg 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 against) it.
* Jan Kiszka 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
