Roman Zippel wrote:
> Ok, great.
> BTW I don't really expect the first version to be fully optimized (unless
> you want to :) ), but once the basics are right, that can still be added
> later.
Agreed. Tom will post updated patches sometime this week. I'll follow up
with the LTT stuff separately
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory wit
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data structure which will only
Karim Yaghmour wrote:
> This is not good for any client that doesn't know beforehand the exact
> size of their data units, as in the case of LTT. If LTT has to use this
> code that means we are going to loose performance because we will need to
> fill an intermediate data structure which will only
Hello Roman,
Roman Zippel wrote:
> Well, let's concentrate for a moment on the last thing and check later
> if and how they fit into relayfs. Since ltt will be first main user, let's
> optimize it for this.
> Also since relayfs is intended for large, fast data transfers, per cpu
> buffers are
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
> I should have avoided earlier confusing the use of a certain type of
> relayfs channel for a given purpose (i.e. LTT should not necessarily
> depend on the managed mode.) I believe that there is a need for
> more than one mode in relayfs independen
OK, I finally come around to answering this ...
Roman Zippel wrote:
> Sorry, you missunderstood me. At the moment I'm only secondarily
> interested in the API details, primarily I want to work out the details of
> what exactly relayfs/ltt are supposed to do. One main question here I
> can't an
Werner Almesberger wrote:
> - if the probe target is an instruction long enough, replace it with
>a jump or call (that's what I think the kprobes folks are working
>on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything cam
[ 3rd try. Apologies to Karim, Thomas, and Roman, who apparently also
received my previous attempts. For some reason, one of my upstream
DNS servers decided to send me highly bogus MX records. ]
Karim Yaghmour wrote:
> Might I add that this is part of the problem ... No personal
> offence inte
On Wed, Jan 19, 2005 at 11:06:10PM +, Marcos D. Marado Torres wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 14 Jan 2005, Barry K. Nathan wrote:
>
> >This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
> >users) "ACPI shutdown bug" -- poweroff hangs inst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 14 Jan 2005, Barry K. Nathan wrote:
This isn't new to 2.6.11-rc1-mm1, but it has the infamous (to Fedora
users) "ACPI shutdown bug" -- poweroff hangs instead of actually turning
the computer off, on some computers. Here's the RH Bugzilla report
Alle 13:42, mercoledì 19 gennaio 2005, bert hubert ha scritto:
> On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> > vmstat under load is the following, and config.gz attached. Of course I
> > can provide any other needed detail; many thanks for any hint.
>
> Looks mightily like DMA i
Werner Almesberger wrote:
>>From all I've heard and seen of LTT (and I have to admit that most
> of it comes from reading this thread, not from reading the code),
Might I add that this is part of the problem ... No personal
offence intended, but there's been _A LOT_ of things said about
LTT that
Christoph Hellwig wrote:
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
file
On Tue, Jan 18, 2005 at 10:39:35PM +0100, Fabio Coatti wrote:
> vmstat under load is the following, and config.gz attached. Of course I can
> provide any other needed detail; many thanks for any hint.
Looks mightily like DMA is not on, even though you compiled the PIIX driver
in, which lists
> 0
On Sun, Jan 16, 2005 at 01:05:19PM -0600, Tom Zanussi wrote:
> One of the things that uses these functions to read from a channel
> from within the kernel is the relayfs code that implements read(2), so
> taking them away means you wouldn't be able to use read() on a relayfs
> file.
Removing them
On Sun, Jan 16, 2005 at 02:30:33PM -0600, Tom Zanussi wrote:
> This would allow an application to write trace events of its own to a
> trace stream for instance.
I don't think this is a good idea. Userspace could aswell easily write
its trace into shared memory segments.
> Also, I added a user-r
>From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
I have the impression that it may try to be a bit too specialized,
and thus might miss opportunities for synergy.
You must be getting tired of people trying to red
Karim Yaghmour writes:
>
> Tom Zanussi wrote:
> > I have to disagree. Awhile back, if you remember, I posted a patch to
> > the LTT daemon that would monitor the trace stream in real time, and
> > process it using an embedded Perl interpreter, no less:
> >
> > http://marc.theaimsgroup.com
Tom Zanussi wrote:
> I have to disagree. Awhile back, if you remember, I posted a patch to
> the LTT daemon that would monitor the trace stream in real time, and
> process it using an embedded Perl interpreter, no less:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109405724500237&w=2
>
>
Thomas,
Thomas Gleixner wrote:
> Yes, I did already start cleaning
>
> cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
so
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to ha
Hi,
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
> Hello,
>
> I?m a developer of yet another kernel tracer, LKST. I and co-developers
> are very glad to hear that LTT was merged into -mm tree and to talk
> about the kernel tracer on this ML. Because we think that the kernel
> e
Hello,
I’m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event tracer is useful to debug Linux systems, and to improve the kernel
reliab
On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > If we add another hardwired implementation then we do not have said
> > benefits.
>
> Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
> and others actually made specific requests for changes
Karim Yaghmour writes:
>
> Aaron Cohen wrote:
> > I've got a quick question and I just want to be clear that it
> > doesn't have a political agenda behind it.
>
> :)
>
> > Here goes, why can't LTT and/or relayfs, work similar to the way
> > syslog does and just fill a buffer (aka ring
Aaron Cohen wrote:
> I've got a quick question and I just want to be clear that it
> doesn't have a political agenda behind it.
:)
> Here goes, why can't LTT and/or relayfs, work similar to the way
> syslog does and just fill a buffer (aka ring-buffer or whatever is
> appropriate), while a use
Hi,
I'm very much a newbie to all of this, but I'm finding this
discussion fairly interesting.
I've got a quick question and I just want to be clear that it
doesn't have a political agenda behind it.
Here goes, why can't LTT and/or relayfs, work similar to the way
syslog does and just fill
Hello Roman,
Roman Zippel wrote:
> Why is so important that it's at the start of the buffer? What's wrong
> with a special event _near_ the start of a buffer?
[snip]
> What gives you the idea, that you can't do this with what I proposed?
> You can still seek freely within the data at buffer boun
Thomas Gleixner wrote:
> Provide a hook, export it and load your filters as a module, but keep
> the filters out of the mainline kernel code.
Great idea! I will do exactly that.
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Lim
Hello Roman,
Roman Zippel wrote:
> An additional comment about the order of events. What you're doing in
> lockless_reserve is bogus anyway. There is no single correct time to
> write into the event. By artificially synchronizing event order and event
> time you only cheat yourself. You either
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> a) create indexes, b) reorder events, and likely c) have to rewrite
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially
J.A. Magallon wrote:
This does not patch against -mm1. -mm1 looks like a mix of plain 2.6.10
and your code.
Could you revamp it against -mm1, please ? I looked at it but seems out
of my understanding...
My patch replaces the one in -mm1.
Just revert the waiting-10s-... patch that is in 2.6.11-rc1-m
On Mon, 2005-01-17 at 18:41 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > I know, what I have said. I said reduce the filtering to the absolute
> > minimum and do the rest in userspace.
>
> You keep adopting the interpretation which best suits you, taking
> quotes out of context, and k
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> > Periodically can also mean a buffer start call back from relayfs
> > (although that would mean the first entry is not guaranteed) or a
> > (per cpu) eventcnt from the subsystem. The amount of needed search would
> > be limited. The main point
Thomas Gleixner wrote:
> If we add another hardwired implementation then we do not have said
> benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think yo
On Mon, 2005-01-17 at 17:42 -0500, Robert Wisniewski wrote:
> I believe (and Karim can correct me if I'm wrong) the idea is to have
> groups of events that can be disabled and enabled via a one word mask. No
> checking multiple variables, no #ifdefing, something very streamlined. By
> userspace
Thomas Gleixner wrote:
> I know, what I have said. I said reduce the filtering to the absolute
> minimum and do the rest in userspace.
You keep adopting the interpretation which best suits you, taking
quotes out of context, and keep repeating things that have already
been answered. There are limi
On 2005.01.16, Daniel Drake wrote:
> Hi,
>
> Joseph Fannin wrote:
> > On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
> >
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> >>waiting-10s-before-mounting-root-filesystem.patch
>
On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > Thats the point. Adding another hardwired implementation does not give
> > us a possibility to solve the hardwired problem of the already available
> > stuff.
>
> Well then, like I said before, you know what you
n <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PRO
On Mon, 2005-01-17 at 15:32 -0500, Karim Yaghmour wrote:
> You're either on crack or I don't know how to read english. Here's what
> you said:
Maybe you should read your own comment about ad-hominem attacks earlier
in this thread and consider if it might apply to you.
I know, what I have said. I
On Fri, Jan 14, 2005 at 06:58:10PM -0800, William Lee Irwin III wrote:
> No idea what hit me just yet. x86-64 doesn't boot. Still going through
> the various architectures. The same system (including the initrd FPOS
> bullcrap, though, of course, I'm using an initrd built just for this
> kernel) bo
Hello Chistoph,
Christoph Hellwig wrote:
> The thing I'm unhappy with is what the code does currently. I haven't
> looked at the code enough nor through about the problem enough to tell
> you what's the right thing to do. Knowing that will involve review of
> the architecture and serious benchm
Hello Roman,
Roman Zippel wrote:
> Periodically can also mean a buffer start call back from relayfs
> (although that would mean the first entry is not guaranteed) or a
> (per cpu) eventcnt from the subsystem. The amount of needed search would
> be limited. The main point is from the relayfs PO
Thomas Gleixner wrote:
> Thats the point. Adding another hardwired implementation does not give
> us a possibility to solve the hardwired problem of the already available
> stuff.
Well then, like I said before, you know what you need to do:
http://www-124.ibm.com/developerworks/oss/linux/projects
Thomas Gleixner wrote:
> Sorting out disabled events is the filtering you have to do in kernel
> and you should do it in the hot path or remove the unneccecary
> tracepoints at compiletime.
Do you actually read my replies or do you just grep for something
you can object to? If you care to read m
Hi, Andrew Morton schrub am Fri, 14 Jan 2005 10:35:34 -0800:
> What filesystem(s) do you use, and why?
sshfs (best idea for file access through firewalls).
gmailfs (best free off-site backup facility).
Will use encfs as soon as FUSE is in mainline
(I'm using cryptoloop now, but that's not san
Karim Yaghmour writes:
>
> Hello Roman,
>
>
> What we are dropping for later review: read/write semantics from
> user-space. It has to be understood that we believe that this is
> a major drawback. For one thing, you won't be able to do something
> like:
> $ cat /relayfs/xchg/my-file >
On Mon, Jan 17, 2005 at 10:48:52AM -0500, Robert Wisniewski wrote:
> Wow - disabling interrupts is handfuls to tens of cycles, so that means
> some architectures take thousands of cycles to do atomic operations. Then
> I would definitely agree we should not be using atomic operations on those,
> f
Arjan van de Ven writes:
> On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
>
> > :-) - as above. Furthermore, it seems that reducing the places where
> > interrupts are disabled would be a good thing?
>
> depends at the price. On several cpus, disabling interupts is hundreds
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> > You can make it even simpler by dropping this completely. Every buffer is
> > simply a list of events and you can let ltt write periodically a timer
> > event. In userspace you can randomly seek at buffer boundaries and search
> > for the time
On Sun, 2005-01-16 at 21:24 -0500, Karim Yaghmour wrote:
> > Sorting out disabled events in the hot path and moving the if
> > (pid/gid/grp) whatever stuff into userspace postprocessing is not an
> > alien request.
>
> It is. Have you even read what I suggested to change in my other mail:
> if ((
On Sun, 2005-01-16 at 20:54 -0500, Karim Yaghmour wrote:
> If you really want to define layers, then there are actually four
> layers:
> 1- hooking mechanism
> 2- event definition / registration
> 3- event management infrastructure
> 4- transport mechanism
>
> LTT currently does 1, 2 & 3. Clearly
Hi Karim,
> Thomas Gleixner wrote:
>> It's not only me, who needs constant time. Everybody interested in
>> tracing will need that. In my opinion its a principle of tracing.
>
> relayfs is a generalized buffering mechanism. Tracing is one application
> it serves. Check out the web site: "high-spe
Thomas Gleixner wrote:
> Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
> GB's of data when the 1.42 seconds elapse without an event.
My argument was about being able to browse the amount of data I was
refering to. The hearbeat thing was an asside to Roman as to the
fact tha
Thomas Gleixner wrote:
> This implies to seperate
>
> - infrastructure
> - event registration
> - transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Current
On Sun, 2005-01-16 at 16:18 -0500, Karim Yaghmour wrote:
> We already do write a heartbeat event periodically to have readable
> traces in the case where the lower 32 bits of the TSC wrap-around.
Which is every 1.42 seconds on a 3GHz machine. I guess we don't have
GB's of data when the 1.42 secon
On Sat, 2005-01-15 at 23:23 -0500, Karim Yaghmour wrote:
> > Well, that's really a core problem. We don't want to duplicate
> > infrastructure, which practically does the same. So if relayfs isn't
> > usable in this kind of situation, it really raises the question whether
> > relayfs is usable a
On Sun, 2005-01-16 at 16:06 -0500, Robert Wisniewski wrote:
> :-) - as above. Furthermore, it seems that reducing the places where
> interrupts are disabled would be a good thing?
depends at the price. On several cpus, disabling interupts is hundreds
of times cheaper than doing an atomic op.
Christoph Hellwig writes:
> On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
> > int global_val;
> >
> > modify_val_spin()
> > {
> >acquire_spin_lock()
> >// calculate some_value based on global_val
> >// for example c=global_val; if (c%0) some_value=10; else
Hello Roman,
Roman Zippel wrote:
> It seems we first need to specify, what relayfs actually is supposed to
> be. Is it a relaying mechanism for large amount of data from kernel to
> user space or is it a general communication channel between kernel and
> user space? You have to choose one, if
Andrew Morton writes:
> Robert Wisniewski <[EMAIL PROTECTED]> wrote:
> >
> > modify_val_spin()
> > {
> >acquire_spin_lock()
> >// calculate some_value based on global_val
> >// for example c=global_val; if (c%0) some_value=10; else some_value=20;
> >global_val = global_val
On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
> int global_val;
>
> modify_val_spin()
> {
> acquire_spin_lock()
> // calculate some_value based on global_val
> // for example c=global_val; if (c%0) some_value=10; else some_value=20;
> global_val = globa
Robert Wisniewski <[EMAIL PROTECTED]> wrote:
>
> modify_val_spin()
> {
> acquire_spin_lock()
> // calculate some_value based on global_val
> // for example c=global_val; if (c%0) some_value=10; else some_value=20;
> global_val = global_val + some_value
> release_spin_
Karim Yaghmour writes:
>
> Christoph Hellwig wrote:
> > the lockless mode is really just loops around cmpxchg. It's spinlocks
> > reinvented poorly.
Christoph,
Sadly they're not the same, atomic operations provide a set of
functionality that simple spin locks do not give you. Consider
Christoph Hellwig writes:
> On Fri, Jan 14, 2005 at 04:11:38PM -0500, Karim Yaghmour wrote:
> >Where does this appear in relayfs and what rights do
> >user-space apps have over it (rwx).
>
> Why would you want anything but read access?
This would allow an application to write trace e
Christoph Hellwig wrote:
> the lockless mode is really just loops around cmpxchg. It's spinlocks
> reinvented poorly.
I beg to differ. You have to use different spinlocks depending on
where you are:
- serving user-space
- bh-derivatives
- irq
lockless is the same primitive regardless of your cu
Hello Christoph,
Christoph Hellwig wrote:
> Why would you want anything but read access?
Fine, we can put it read-only, we'll drop the "mode" field.
> I think random access is overkill. Keeping the code simple is more
> important and user-space can post-process it.
it's overkill if you're thi
Joseph Fannin wrote:
>>With this patch, initrds seem to get 'skipped'. I think this is
>> probably the cause for the reports of problems with RAID too.
On Sun, Jan 16, 2005 at 07:09:31PM +, Daniel Drake wrote:
> This seems likely and is probably also the cause of wli's problems
> mention
Hi,
Joseph Fannin wrote:
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting the root filesystem at boot time
With this patch,
Karim Yaghmour writes:
>
> What I'm dropping for now is all the functions that allow a
> subsystem to read from a channel from within the kernel. So,
> for example, if you want to obtain large amounts of data from
> user-space via a relayfs channel you won't be able to. Here
> are the functi
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> The per-cpu buffering issue is really specific to the client. It just
> so happens that LTT creates one channel for each CPU. Not everyone
> who needs to ship lots of data to user-space needs/wants one channel
> per cpu. You could, for example, use
Joseph Fannin wrote:
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
waiting-10s-before-mounting-root-filesystem.patch
retry mounting the root filesystem at boot time
With this patch, init
On Fri, Jan 14, 2005 at 06:09:23PM -0500, Karim Yaghmour wrote:
> relayfs implements two schemes: lockless and locking. The later uses
> standard linear locking mechanisms. If you need stringent constant
> time, you know what to do.
the lockless mode is really just loops around cmpxchg. It's spin
On Sat, Jan 15, 2005 at 01:24:16AM +0100, Thomas Gleixner wrote:
> Putting a 200k patch into the kernel for limited usage and maybe
> restricting a generic simple non intrusive and more generic
> implementation by its mere presence is making it inapplicable enough.
>
> Merge the instrumentation po
On Fri, Jan 14, 2005 at 04:11:38PM -0500, Karim Yaghmour wrote:
> Where does this appear in relayfs and what rights do
> user-space apps have over it (rwx).
Why would you want anything but read access?
> bufsize, nbufs:
> Usually things have to be subdivided in sub-buffers to ma
Karim Yaghmour writes:
>
> Hello Thomas,
>
> In the interest of avoiding expanding the thread too thin, I'm replying to
> both emails in the same time.
>
> Thomas Gleixner wrote:
> >>relayfs is a generalized buffering mechanism. Tracing is one application
> >>it serves. Check out the we
Daniel Kirsten <[EMAIL PROTECTED]> writes:
>> Are you using an initrd?
> yes.
Then read Documentation/initrd.txt ...
Your initrd must be deprecated, i guess you have to use
root=/dev/whatever/your_final_root_fs with it while it should be
root=/dev/ram0. (pretty sure it doesn't use pivot_root
Hello Roman,
Roman Zippel wrote:
> It's interesting to read more about ltt's requirements, but I still think
> it's possible to leave this work to the relayfs layer.
Ok, I'm willing to play ball, but can you be a little bit more specific.
> Why not just move the ltt buffer management into rela
Hello Roman,
Roman Zippel wrote:
> On Sat, 15 Jan 2005, Karim Yaghmour wrote:
>>In addition, and this is a very important issue, quite a few
>>kernel developers mistook LTT for a kernel debugging tool, which
>>it was never meant to be. When, in fact, if you ask those who have
>>looked at using it
Hello Thomas,
In the interest of avoiding expanding the thread too thin, I'm replying to
both emails in the same time.
Thomas Gleixner wrote:
>>relayfs is a generalized buffering mechanism. Tracing is one application
>>it serves. Check out the web site: "high-speed data-relay filesystem."
>>Fanc
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
> In addition, and this is a very important issue, quite a few
> kernel developers mistook LTT for a kernel debugging tool, which
> it was never meant to be. When, in fact, if you ask those who have
> looked at using it for that purpose (try Marcelo
Hi,
On Fri, 14 Jan 2005, Karim Yaghmour wrote:
> > Why should a subsystem care about the details of the buffer management?
>
> Because it wants to enforce a data format on buffer boundaries.
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this w
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More below
On Fri, Jan 14, 2005 at 12:23:52AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> waiting-10s-before-mounting-root-filesystem.patch
> retry mounting the root filesystem at boot time
With this patch, initrds seem to
> Are you using an initrd?
yes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, 2005-01-14 at 15:22 -0800, Tim Bird wrote:
> but not 1) supporting infrastructure for timestamping, managing event
> data, etc., and 2) a static list of generally useful tracepoints.
Both points are well taken. Thats the essential minimum what
instrumentation needs.
I'd like to see th
On Fri, 2005-01-14 at 20:25 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
>
> You have previously demonstrated that you do not understand the
> implementation you are criticizing. You keep repeating the size
> of the patch like a mantra, yet when pressed for actual bits of
> code that need
Hi Karim,
On Fri, 2005-01-14 at 20:14 -0500, Karim Yaghmour wrote:
> Gee Thomas, I guess you really want to take this one until the last
> man is standing. Feel free to use the ad-hominem tone if it suits
> you. Don't hold it against me though if I don't bite :)
No personal offence was intended.
Sorry about the missing quotes. It should read:
You wrote:
> Some things I'd like to see (as I am currently using the KIO
> equivalent) implemented as FUSE fs:
> - "fish", virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload f
Some things I'd like to see (as I am currently using the KIO
equivalent) implemented as FUSE fs:
- "fish", virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload fuse-2.2-pre3 and sshfs-1.0. It should work on
any kernel including
93 matches
Mail list logo
