fault-injection-developer — Developer discussions about creating a fault injection test harness.

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Tue, 2002-10-22 at 11:22, Lynch, Rusty wrote:
> I think we need to be a little more clear on the terms we are using.  I
> think that when Rob refers to "extending dprobes", he means patching dprobes
> to enable some additional features, not taking advantage of various kernel
> hooks that the dprobes patch adds to the kernel.
> 
> For example, a very small tweak to dprobes could enable an extra instruction
> in the probe rpn files that allows arbitrary exit points to be called from
> the rpn file.  This could enable something like:
> 1. Some user space tool analysis a driver module and then and generates a
> rpn file that would insert probe points for each of the in/out operations
> where each probe point calls an exit function in a FITH loadable kernel
> module
> 2. Once the exit function in the FITH module has been called then the rest
> of the design for FITH would be the same
> 
> 	-rusty 
> 

Yes, that was similar to what I was thinking. It would be nice though,
if the user-space tool could also work on more than just modules though.
Does dprobes allow you to insert anywhere in the kernel (i.e. not just
kernel modules)? It would be nice to be able to insert probe points for
compiled in drivers as well. This could be tricky, but you could use the
tool to run through the kernel System.map and vmlinux (uncompressed
compiled kernel ELF file) to figure out where to insert probe points in
the rpn file for a running kernel. Just a thought...

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Lynch, R. <rus...@in...>]

I think we need to be a little more clear on the terms we are using.  I
think that when Rob refers to "extending dprobes", he means patching =
dprobes
to enable some additional features, not taking advantage of various =
kernel
hooks that the dprobes patch adds to the kernel.

For example, a very small tweak to dprobes could enable an extra =
instruction
in the probe rpn files that allows arbitrary exit points to be called =
from
the rpn file.  This could enable something like:
1. Some user space tool analysis a driver module and then and generates =
a
rpn file that would insert probe points for each of the in/out =
operations
where each probe point calls an exit function in a FITH loadable kernel
module
2. Once the exit function in the FITH module has been called then the =
rest
of the design for FITH would be the same

	-rusty=20

-----Original Message-----
From: Wang, Stanley [mailto:sta...@in...]
Sent: Monday, October 21, 2002 10:40 PM
To: 'Rob Rhoads'
Cc: fau...@li...; Perez-Gonzalez,
Inaky
Subject: RE: [Fault-injection-developer] Couple of issues downloading
and building the FITH source code


Hi Rob,
I think it is what FITH did indeed.=20
Dprobes' fault injection mechanism causes that the faultset must be =
updated
after the driver was recompiled.
FITH uses almost all hooks (GKHI) that Dprobes places in kernel, but =
its
faultset needn't to be updated after you=20
recompiled the driver. FITH is extending the Dprobes, doing something =
better
:)

Stanley Wang=20
SW Engineer, Intel Corporation.
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1171=20
iNet: 8-752-1171=20
=20
Opinions expressed are those of the author and do not represent Intel
Corporation


-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:23
To: Wang, Stanley
Cc: fau...@li...;
ina...@in...
Subject: RE: [Fault-injection-developer] Couple of issues downloading =
and
building the FITH source code


On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote:
> Hi, Rob
> Dprobes replaces the instruction in the specified addrees with =
"int3".
> We replace all "in/out".

Why can't dprobes be modified/extended to do that?

>=20
> Thanks,
> Stanley
>=20

--=20
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value=3D"pointless">
This email message solely contains my own personal views,=20
and not necessarily those of my employer.
</disclaimer>


-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future of=20
Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))=20
program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
http://www.sun.com/javavote
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Wang, S. <sta...@in...>]

Hi Rob,
I think it is what FITH did indeed.=20
Dprobes' fault injection mechanism causes that the faultset must be =
updated
after the driver was recompiled.
FITH uses almost all hooks (GKHI) that Dprobes places in kernel, but =
its
faultset needn't to be updated after you=20
recompiled the driver. FITH is extending the Dprobes, doing something =
better
:)

Stanley Wang=20
SW Engineer, Intel Corporation.
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1171=20
iNet: 8-752-1171=20
=20
Opinions expressed are those of the author and do not represent Intel
Corporation


-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:23
To: Wang, Stanley
Cc: fau...@li...;
ina...@in...
Subject: RE: [Fault-injection-developer] Couple of issues downloading =
and
building the FITH source code


On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote:
> Hi, Rob
> Dprobes replaces the instruction in the specified addrees with =
"int3".
> We replace all "in/out".

Why can't dprobes be modified/extended to do that?

>=20
> Thanks,
> Stanley
>=20

--=20
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value=3D"pointless">
This email message solely contains my own personal views,=20
and not necessarily those of my employer.
</disclaimer>

[Fault-injection-developer] DProbes and FITH

[Wang, F. <fra...@in...>]

Good questions raised by Rob. So let's discuss this with a new subject.

>>Also, can you explain why we aren't modifying & using dprobes? Why are
>>we instead using a modified version of insmod? With your current FITH
>>implementation, can you inject faults in statically compiled/linked
>>drivers or kernel code (e.g. not just kernel modules)? 

>>I have concerns that using a modified insmod, won't fly with kernel
>>developers. If dprobes isn't sufficient, why can't it be modified, so we
>>don't have to use a modified version of insmod. I may be drawing the
>>wrong conclusion here, so don't change it until you explain it. 

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 21:15, Wang, Stanley wrote:
> Hi, Rob
> Dprobes replaces the instruction in the specified addrees with "int3".
> We replace all "in/out".

Why can't dprobes be modified/extended to do that?

> 
> Thanks,
> Stanley
> 

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

[Fault-injection-developer] FW: Kernel Probes - Is this the same as dynamic probes?

[Rhoads, R. <rob...@in...>]

Just an FYI from the lkml kprobes vs dprobes...

-----Original Message-----
From: Suparna Bhattacharya [mailto:su...@sp...]
Sent: Tuesday, October 22, 2002 2:39 AM
To: undisclosed-recipients
Subject: Re: Kernel Probes - Is this the same as dynamic probes?


On Tue, 22 Oct 2002 08:58:48 +0530, Mike Grundy wrote:

> Hi Folks -
> 
> Rob posed the question in his merge candidate list. Kprobes is an api
> for placing arbitrary break (probes) points in kernel code and provides
> for handlers (your function) to execute before and after the probed
> instruction is executed.
> 
> Dynamic probes on the other hand does the same thing ;-)
> 
> Vamsi and co. designed kprobes to provide the core of the dprobes
> engine: probe point management and insertion, probe point interrupt
> handler, and post interrupt clean up (replacing the original
> instruction, single stepping it and then putting the probe back) in a
> lightweight patch so that it would be more palitable for inclusion in
> the kernel.
> 
> The next version of dprobes could use the api as well as any module
> thrown together to debug a problem (without having to reboot).
> 
> Anyway getting back to my quip about dprobes doing the same thing,
> dprobes can put probes in kernel or userland code, has a debug engine we
> call the dprobes_interpreter that runs probe point handler programs
> (kind of pseudo assembler programs) that can change / record register
> values, change / record memory locations, core the process or call LKCD
> and much more.
> 
> kprobes doesn't have two things (IIRC) it needs to handle userland probe
> points, I don't know if this was a planned addition or if Vamsi figured
> out a way to handle it within the existing kprobes api.

Yes there's a patch to add user space probes enablement to kprobes which
Vamsi should be posting shortly along with patches for watchpoint
support using debug registers (he'll be back in office later today). 

> 
> dprobes has support for i386, s390, s390x, ppc and ppc64. kprobes has
> i386 support right now, and after we review and beat upon the code I
> posted to the dprobes list tonight, we'll have s390 and s390x support as
> well.
> 
> Comments welcome.
> 
> Thanks
> Mike
> 
> --
> If we blow up, whatever's left of me is kicking your butt! - To
> unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg... More majordomo info
> at  http://vger.kernel.org/majordomo-info.html Please read the FAQ at 
> http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Wang, S. <sta...@in...>]

Hi, Rob
Dprobes replaces the instruction in the specified addrees with "int3".
We replace all "in/out".

Thanks,
Stanley

-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 12:12
To: Wang, Stanley
Cc: fau...@li...
Subject: RE: [Fault-injection-developer] Couple of issues downloading =
and
building the FITH source code


On Mon, 2002-10-21 at 21:07, Wang, Stanley wrote:
> Hi Rob,
> The modified version insmod's job is very simple:=20
> 1. finds out all "in_x/out_x" instruction in the tested module and
replaces
> them with "int3"
> 2. redirect "ioremap" and "request_irq" to FITH's hook
>

What does dprobes do?
=20
> These work can be done in kernel space with more difficulty :(
> So we do it in user space (insmod).
>=20
> Thanks,
> Stanley
>=20

--=20
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value=3D"pointless">
This email message solely contains my own personal views,=20
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 21:07, Wang, Stanley wrote:
> Hi Rob,
> The modified version insmod's job is very simple: 
> 1. finds out all "in_x/out_x" instruction in the tested module and replaces
> them with "int3"
> 2. redirect "ioremap" and "request_irq" to FITH's hook
>

What does dprobes do?
 
> These work can be done in kernel space with more difficulty :(
> So we do it in user space (insmod).
> 
> Thanks,
> Stanley
> 

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code]

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 20:47, Wang, Stanley wrote:
> Hi, Rob
> 
> I think the reason why we used a modified version insmod is that we have not
> enough time to complete a FITH's insmod:) And we can write a insmod when
> time permits. And we really want :)
> 
> Thank,
> Stanley 
> 

Let me rephrase the question. Why have a special version of insmod at all? 
Why have any other version of insmod than the original one that ships with 
any Linux distro?

IOW, can we modify dprobes to make it work so you don't need a special
FITH version of insmod? 

I'm looking for an explanation of what's wrong with dprobes, that
requires us to have a special FITH version of insmod. 

I could be way off the mark here. These may be entirely two different 
& unrelated issues. 

These could be just two separate question:
1) why are we only using part of dprobes? 

2) why a special FITH version of insmod? 

Assume I don't know anything about how dprobes works, or how FITH works. 
(Because I don't)

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Wang, S. <sta...@in...>]

Hi, Rob

I think the reason why we used a modified version insmod is that we =
have not
enough time to complete a FITH's insmod:) And we can write a insmod =
when
time permits. And we really want :)

Thank,
Stanley=20

-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: 2002=E5=B9=B410=E6=9C=8822=E6=97=A5 11:41
To: fau...@li...
Cc: Zhuang, Louis; Perez-Gonzalez, Inaky; Wang, Frank
Subject: RE: [Fault-injection-developer] Couple of issues downloading =
and
building the FITH source code


On Mon, 2002-10-21 at 20:05, Rob Rhoads wrote:
> On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote:
> > I agree totally. We'll change README and INSTALL against stock =
kernel
> > 2.4/2.5.=20

Upon further reflection...just so I'm even more clear (sorry if you
already knew this):

At a minimum, break FITH out into 2 packages:

1. One for kernel patches, kernel modules, plus kernel related build
instructions.

2. One for user-space components, plus build scripts (configure file) &
instructions

IOW don't package FITH up as a single tarball that contains both kernel
and user-space components, and one big README for building both.
Bundling them together just isn't a good idea from a Linux kernel
developers perspective.

Also, can you explain why we aren't modifying & using dprobes? Why are
we instead using a modified version of insmod? With your current FITH
implementation, can you inject faults in statically compiled/linked
drivers or kernel code (e.g. not just kernel modules)?=20

I have concerns that using a modified insmod, won't fly with kernel
developers. If dprobes isn't sufficient, why can't it be modified, so =
we
don't have to use a modified version of insmod. I may be drawing the
wrong conclusion here, so don't change it until you explain it.=20

Anyone should feel free to jump-in in this discussion, if you
disagree/agree or whatever.

> >=20
> Just to clarify, I never expected FIFTH to work on the kernel that
> shipped with RH 8.0. Just that I could build both a stock kernel w/
> relevant patches, and the FIFTH user-space components on a RH 8.0
> system.=20
>=20
> So it sounds like we are then in agreement. Cool. ;-)
>=20

--=20
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value=3D"pointless">
This email message solely contains my own personal views,=20
and not necessarily those of my employer.
</disclaimer>



-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future=20
of  Java(TM) technology. Join the Java Community=20
Process(SM) (JCP(SM)) program now.=20
http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javav=
ote
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 20:00, Zhuang, Louis wrote:
> FITH has nothing to do with CGLE indeed except for some reference to
> hardened driver spec. :-) We'll eliminate all references for CGLE in
> documents.

Hardened Driver spec? What's that? 

I claim no knowledge of that dreaded beast! :-)

*ouch!*

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 20:05, Rob Rhoads wrote:
> On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote:
> > I agree totally. We'll change README and INSTALL against stock kernel
> > 2.4/2.5. 

Upon further reflection...just so I'm even more clear (sorry if you
already knew this):

At a minimum, break FITH out into 2 packages:

1. One for kernel patches, kernel modules, plus kernel related build
instructions.

2. One for user-space components, plus build scripts (configure file) &
instructions

IOW don't package FITH up as a single tarball that contains both kernel
and user-space components, and one big README for building both.
Bundling them together just isn't a good idea from a Linux kernel
developers perspective.

Also, can you explain why we aren't modifying & using dprobes? Why are
we instead using a modified version of insmod? With your current FITH
implementation, can you inject faults in statically compiled/linked
drivers or kernel code (e.g. not just kernel modules)? 

I have concerns that using a modified insmod, won't fly with kernel
developers. If dprobes isn't sufficient, why can't it be modified, so we
don't have to use a modified version of insmod. I may be drawing the
wrong conclusion here, so don't change it until you explain it. 

Anyone should feel free to jump-in in this discussion, if you
disagree/agree or whatever.

> > 
> Just to clarify, I never expected FIFTH to work on the kernel that
> shipped with RH 8.0. Just that I could build both a stock kernel w/
> relevant patches, and the FIFTH user-space components on a RH 8.0
> system. 
> 
> So it sounds like we are then in agreement. Cool. ;-)
> 

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Wang, F. <fra...@in...>]

Good comments from Rob!

-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: 2002?10?22? 10:59
To: Zhuang, Louis
Cc: fau...@li...; Perez-Gonzalez, Inaky;
Wang, Frank
Subject: RE: [Fault-injection-developer] Couple of issues downloading and
building the FITH source code


Louis, not that I want to hammer you some more (better me though, than
someone on the LKML -- I learned the hard way *ouch!*) but ...

When you respond to someone's e-mail with in-line comments, you need to
clearly mark your response or the original text w/ something. So the
reader can distinguish what you are saying and what the original poster
said.

Needless to say, I had a very difficult time distinguishing my comments
from yours in your response below.

-RobR

On Mon, 2002-10-21 at 19:37, Zhuang, Louis wrote:
> OK, got the source, and I'm now going through the build steps and
> reading the documentation. In short, its way too TLT specific for a
> general announcement on the LKML.
> 
> I haven't attempted to build it yet, but this is what I see so far that
> needs to be fixed before the project is announced (in any form) to the
> LKML:
> 
> 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
> everything. The README file is full of TLT & carrierlinux 'isms. If this
> is going to be posted on LKML, the instructions and code had better work
> on a stock kernel by applying relevant kernel patches.
> 
> If you rely on the TLT or CGLE kernel no one on the LKML, outside of
> OSDL developers, will take a second look at it.
> 
> The instructions need to be written so anyone can take a stock kernel
> apply the relevant patches and make it work. For example, dprobes is
> required, but the instruction don't clearly state that you need to apply
> the patch to the stock kernel sources.
> We'll fix these issues. thx
> 
> 
> 2. You need to break-out the required kernel patches from the user-space
> components. Separate source tarballs & separate instructions, might be
> one way to do it. Right now it's confusing from reading the README what
> exactly you need to do in order to get going. At the very least you need
> to build a new kernel with the right patches applied, and then make the
> user-space components.
> Good point! Fixing... :)
> 
> 
> 3. A lot of the info that's in the README should be in the INSTALL file.
> The INSTALL file has good info, but is pretty much generic to running
> ./configure.
> INSTALL file is generated by 'automake' automatically. We'd like put all
> information in README. If you think it is an issue, we'll change some
> installation-relative information into INSTALL.
> 
> 
> 4. To get the best exposure on the LKML, it would be better to also
> provide instructions on how to make it work on the 2.5 kernel. I would
> think that would be just a matter of getting the patches working on the
> 2.5 kernel. This could be any area where we ask for community help in
> making it work on 2.5. This shouldn't stop us from announcing, but after
> listening to Greg K-H yesterday and my past experience this is the
> conclusion I come to.
> We all have little experience in 2.5, but we'll try to merge our things
into
> 2.5. Maybe we need some help from other kernel guys :) 
> 
> 
> More comments to follow...stay tuned...
> 
> -RobR
> 
> 

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 20:08, Zhuang, Louis wrote:
> Just for fun. I call this project FITH (Fault Injection Test Harness). I
> wonder what FIFTH stands for? :-)
> 

It could mean one of the following:
a) fifth of gin
b) fifth of vodka
c) Or for O.J. Simpson,  I take the fifth...

Just kidding... :-)

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

Just for fun. I call this project FITH (Fault Injection Test Harness). I
wonder what FIFTH stands for? :-)

    > -----Original Message-----
    > From: Rob Rhoads [mailto:err...@li...]
    > Sent: Tuesday, October 22, 2002 11:05 AM
    > To: Zhuang, Louis
    > Cc: fau...@li...; 
    > Perez-Gonzalez, Inaky; Wang, Frank
    > Subject: RE: [Fault-injection-developer] Couple of issues 
    > downloading and building the FITH source code
    > 
    > 
    > On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote:
    > > I agree totally. We'll change README and INSTALL 
    > against stock kernel
    > > 2.4/2.5. 
    > > 
    > Just to clarify, I never expected FIFTH to work on the kernel that
    > shipped with RH 8.0. Just that I could build both a stock 
    > kernel w/
    > relevant patches, and the FIFTH user-space components on a RH 8.0
    > system. 
    > 
    > So it sounds like we are then in agreement. Cool. ;-)
    > 
    > -- 
    > Rob Rhoads                     mailto:err...@li...
    > Telecom Software Platforms     office: 503-677-5498
    > Intel Communications Group
    > 
    > <disclaimer value="pointless">
    > This email message solely contains my own personal views, 
    > and not necessarily those of my employer.
    > </disclaimer>
    > 

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 19:54, Zhuang, Louis wrote:
> I agree totally. We'll change README and INSTALL against stock kernel
> 2.4/2.5. 
> 
Just to clarify, I never expected FIFTH to work on the kernel that
shipped with RH 8.0. Just that I could build both a stock kernel w/
relevant patches, and the FIFTH user-space components on a RH 8.0
system. 

So it sounds like we are then in agreement. Cool. ;-)

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

It is first time for me to use plain text format in outlook, so... pardon me
:-)

    > -----Original Message-----
    > From: Rob Rhoads [mailto:err...@li...]
    > Sent: Tuesday, October 22, 2002 10:59 AM
    > To: Zhuang, Louis
    > Cc: fau...@li...; 
    > Perez-Gonzalez, Inaky; Wang, Frank
    > Subject: RE: [Fault-injection-developer] Couple of issues 
    > downloading and building the FITH source code
    > 
    > 
    > Louis, not that I want to hammer you some more (better me 
    > though, than
    > someone on the LKML -- I learned the hard way *ouch!*) but ...
    > 
    > When you respond to someone's e-mail with in-line 
    > comments, you need to
    > clearly mark your response or the original text w/ 
    > something. So the
    > reader can distinguish what you are saying and what the 
    > original poster
    > said.
    > 
    > Needless to say, I had a very difficult time 
    > distinguishing my comments
    > from yours in your response below.
    > 
    > -RobR
    > 
    > On Mon, 2002-10-21 at 19:37, Zhuang, Louis wrote:
    > > OK, got the source, and I'm now going through the build 
    > steps and
    > > reading the documentation. In short, its way too TLT 
    > specific for a
    > > general announcement on the LKML.
    > > 
    > > I haven't attempted to build it yet, but this is what I 
    > see so far that
    > > needs to be fixed before the project is announced (in 
    > any form) to the
    > > LKML:
    > > 
    > > 1. Remove all mention & dependencies on TLT, 
    > carrierlinux, etc. from
    > > everything. The README file is full of TLT & 
    > carrierlinux 'isms. If this
    > > is going to be posted on LKML, the instructions and 
    > code had better work
    > > on a stock kernel by applying relevant kernel patches.
    > > 
    > > If you rely on the TLT or CGLE kernel no one on the 
    > LKML, outside of
    > > OSDL developers, will take a second look at it.
    > > 
    > > The instructions need to be written so anyone can take 
    > a stock kernel
    > > apply the relevant patches and make it work. For 
    > example, dprobes is
    > > required, but the instruction don't clearly state that 
    > you need to apply
    > > the patch to the stock kernel sources.
    > > We'll fix these issues. thx
    > > 
    > > 
    > > 2. You need to break-out the required kernel patches 
    > from the user-space
    > > components. Separate source tarballs & separate 
    > instructions, might be
    > > one way to do it. Right now it's confusing from reading 
    > the README what
    > > exactly you need to do in order to get going. At the 
    > very least you need
    > > to build a new kernel with the right patches applied, 
    > and then make the
    > > user-space components.
    > > Good point! Fixing... :)
    > > 
    > > 
    > > 3. A lot of the info that's in the README should be in 
    > the INSTALL file.
    > > The INSTALL file has good info, but is pretty much 
    > generic to running
    > > ./configure.
    > > INSTALL file is generated by 'automake' automatically. 
    > We'd like put all
    > > information in README. If you think it is an issue, 
    > we'll change some
    > > installation-relative information into INSTALL.
    > > 
    > > 
    > > 4. To get the best exposure on the LKML, it would be 
    > better to also
    > > provide instructions on how to make it work on the 2.5 
    > kernel. I would
    > > think that would be just a matter of getting the 
    > patches working on the
    > > 2.5 kernel. This could be any area where we ask for 
    > community help in
    > > making it work on 2.5. This shouldn't stop us from 
    > announcing, but after
    > > listening to Greg K-H yesterday and my past experience 
    > this is the
    > > conclusion I come to.
    > > We all have little experience in 2.5, but we'll try to 
    > merge our things into
    > > 2.5. Maybe we need some help from other kernel guys :) 
    > > 
    > > 
    > > More comments to follow...stay tuned...
    > > 
    > > -RobR
    > > 
    > > 
    > 
    > -- 
    > Rob Rhoads                     mailto:err...@li...
    > Telecom Software Platforms     office: 503-677-5498
    > Intel Communications Group
    > 
    > <disclaimer value="pointless">
    > This email message solely contains my own personal views, 
    > and not necessarily those of my employer.
    > </disclaimer>
    > 

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

FITH has nothing to do with CGLE indeed except for some reference to
hardened driver spec. :-) We'll eliminate all references for CGLE in
documents.

    > -----Original Message-----
    > From: Zhuang, Louis 
    > Sent: Tuesday, October 22, 2002 10:55 AM
    > To: 'Rob Rhoads'; Zhuang, Louis
    > Cc: fau...@li...; 
    > Perez-Gonzalez, Inaky; Wang, Frank
    > Subject: RE: [Fault-injection-developer] Couple of issues 
    > downloading and building the FITH source code
    > 
    > 
    > I agree totally. We'll change README and INSTALL against 
    > stock kernel 2.4/2.5. 
    > 
    >     > -----Original Message-----
    >     > From: Rob Rhoads [mailto:err...@li...]
    >     > Sent: Tuesday, October 22, 2002 10:53 AM
    >     > To: Zhuang, Louis
    >     > Cc: fau...@li...; 
    >     > Perez-Gonzalez, Inaky; 'Rob Rhoads'; Wang, Frank
    >     > Subject: RE: [Fault-injection-developer] Couple of issues 
    >     > downloading and building the FITH source code
    >     > 
    >     > 
    >     > On Mon, 2002-10-21 at 19:27, Zhuang, Louis wrote:
    >     > > Thanks Rob for his push! :) 
    >     > > We've made FITH conformable to Red hat 8.0. Now, it is 
    >     > conformable to ISO
    >     > > C99, aclocal 1.6, autoconf 2.53, automake 1.6. But, 
    >     > kernel with Red hat 8.0
    >     > > is not suitable for compiling and running FITH because 
    >     > DProbes and some
    >     > > symbol exports are needed. The CGL precompiled kernel 
    >     > is most suitable for
    >     > > that. :) 
    >     > 
    > http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable
    >     > > 
    >     > > Louis Zhuang, SW Engineer, Intel Corporation.
    >     > > My opinions are my own and NEVER the opinions of Intel 
    >     > Corporation.
    >     > 
    >     > Sorry Louis, but if we want this to be a useful SF 
    >     > project & one that we
    >     > can announce on the LKML, we've got to provide the 
    > patches and
    >     > instructions for someone to take a stock 2.4.x or 2.5.x 
    >     > kernel and get
    >     > it working for use with FIFTH. I would further argue that 
    >     > 2.5.x is more
    >     > important than 2.4.x, at least to the kernel 
    > developer community.
    >     > 
    >     > Look at this way, someone on LKML has no idea what CGLE 
    >     > is, let alone
    >     > TLT. You need to assume your intended audience only knows 
    >     > about the
    >     > stock kernel sources on kernel.org.
    >     > 
    >     > -RobR
    >     > 
    > 

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

Louis, not that I want to hammer you some more (better me though, than
someone on the LKML -- I learned the hard way *ouch!*) but ...

When you respond to someone's e-mail with in-line comments, you need to
clearly mark your response or the original text w/ something. So the
reader can distinguish what you are saying and what the original poster
said.

Needless to say, I had a very difficult time distinguishing my comments
from yours in your response below.

-RobR

On Mon, 2002-10-21 at 19:37, Zhuang, Louis wrote:
> OK, got the source, and I'm now going through the build steps and
> reading the documentation. In short, its way too TLT specific for a
> general announcement on the LKML.
> 
> I haven't attempted to build it yet, but this is what I see so far that
> needs to be fixed before the project is announced (in any form) to the
> LKML:
> 
> 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
> everything. The README file is full of TLT & carrierlinux 'isms. If this
> is going to be posted on LKML, the instructions and code had better work
> on a stock kernel by applying relevant kernel patches.
> 
> If you rely on the TLT or CGLE kernel no one on the LKML, outside of
> OSDL developers, will take a second look at it.
> 
> The instructions need to be written so anyone can take a stock kernel
> apply the relevant patches and make it work. For example, dprobes is
> required, but the instruction don't clearly state that you need to apply
> the patch to the stock kernel sources.
> We'll fix these issues. thx
> 
> 
> 2. You need to break-out the required kernel patches from the user-space
> components. Separate source tarballs & separate instructions, might be
> one way to do it. Right now it's confusing from reading the README what
> exactly you need to do in order to get going. At the very least you need
> to build a new kernel with the right patches applied, and then make the
> user-space components.
> Good point! Fixing... :)
> 
> 
> 3. A lot of the info that's in the README should be in the INSTALL file.
> The INSTALL file has good info, but is pretty much generic to running
> ./configure.
> INSTALL file is generated by 'automake' automatically. We'd like put all
> information in README. If you think it is an issue, we'll change some
> installation-relative information into INSTALL.
> 
> 
> 4. To get the best exposure on the LKML, it would be better to also
> provide instructions on how to make it work on the 2.5 kernel. I would
> think that would be just a matter of getting the patches working on the
> 2.5 kernel. This could be any area where we ask for community help in
> making it work on 2.5. This shouldn't stop us from announcing, but after
> listening to Greg K-H yesterday and my past experience this is the
> conclusion I come to.
> We all have little experience in 2.5, but we'll try to merge our things into
> 2.5. Maybe we need some help from other kernel guys :) 
> 
> 
> More comments to follow...stay tuned...
> 
> -RobR
> 
> 

-- 
Rob Rhoads                     mailto:err...@li...
Telecom Software Platforms     office: 503-677-5498
Intel Communications Group

<disclaimer value="pointless">
This email message solely contains my own personal views, 
and not necessarily those of my employer.
</disclaimer>

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

I agree totally. We'll change README and INSTALL against stock kernel
2.4/2.5. 

    > -----Original Message-----
    > From: Rob Rhoads [mailto:err...@li...]
    > Sent: Tuesday, October 22, 2002 10:53 AM
    > To: Zhuang, Louis
    > Cc: fau...@li...; 
    > Perez-Gonzalez, Inaky; 'Rob Rhoads'; Wang, Frank
    > Subject: RE: [Fault-injection-developer] Couple of issues 
    > downloading and building the FITH source code
    > 
    > 
    > On Mon, 2002-10-21 at 19:27, Zhuang, Louis wrote:
    > > Thanks Rob for his push! :) 
    > > We've made FITH conformable to Red hat 8.0. Now, it is 
    > conformable to ISO
    > > C99, aclocal 1.6, autoconf 2.53, automake 1.6. But, 
    > kernel with Red hat 8.0
    > > is not suitable for compiling and running FITH because 
    > DProbes and some
    > > symbol exports are needed. The CGL precompiled kernel 
    > is most suitable for
    > > that. :) 
    > http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable
    > > 
    > > Louis Zhuang, SW Engineer, Intel Corporation.
    > > My opinions are my own and NEVER the opinions of Intel 
    > Corporation.
    > 
    > Sorry Louis, but if we want this to be a useful SF 
    > project & one that we
    > can announce on the LKML, we've got to provide the patches and
    > instructions for someone to take a stock 2.4.x or 2.5.x 
    > kernel and get
    > it working for use with FIFTH. I would further argue that 
    > 2.5.x is more
    > important than 2.4.x, at least to the kernel developer community.
    > 
    > Look at this way, someone on LKML has no idea what CGLE 
    > is, let alone
    > TLT. You need to assume your intended audience only knows 
    > about the
    > stock kernel sources on kernel.org.
    > 
    > -RobR
    > 

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

On Mon, 2002-10-21 at 19:27, Zhuang, Louis wrote:
> Thanks Rob for his push! :) 
> We've made FITH conformable to Red hat 8.0. Now, it is conformable to ISO
> C99, aclocal 1.6, autoconf 2.53, automake 1.6. But, kernel with Red hat 8.0
> is not suitable for compiling and running FITH because DProbes and some
> symbol exports are needed. The CGL precompiled kernel is most suitable for
> that. :) http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable
> 
> Louis Zhuang, SW Engineer, Intel Corporation.
> My opinions are my own and NEVER the opinions of Intel Corporation.

Sorry Louis, but if we want this to be a useful SF project & one that we
can announce on the LKML, we've got to provide the patches and
instructions for someone to take a stock 2.4.x or 2.5.x kernel and get
it working for use with FIFTH. I would further argue that 2.5.x is more
important than 2.4.x, at least to the kernel developer community.

Look at this way, someone on LKML has no idea what CGLE is, let alone
TLT. You need to assume your intended audience only knows about the
stock kernel sources on kernel.org.

-RobR

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

OK, got the source, and I'm now going through the build steps and
reading the documentation. In short, its way too TLT specific for a
general announcement on the LKML.

I haven't attempted to build it yet, but this is what I see so far that
needs to be fixed before the project is announced (in any form) to the
LKML:

1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
everything. The README file is full of TLT & carrierlinux 'isms. If this
is going to be posted on LKML, the instructions and code had better work
on a stock kernel by applying relevant kernel patches.

If you rely on the TLT or CGLE kernel no one on the LKML, outside of
OSDL developers, will take a second look at it.

The instructions need to be written so anyone can take a stock kernel
apply the relevant patches and make it work. For example, dprobes is
required, but the instruction don't clearly state that you need to apply
the patch to the stock kernel sources.
We'll fix these issues. thx


2. You need to break-out the required kernel patches from the user-space
components. Separate source tarballs & separate instructions, might be
one way to do it. Right now it's confusing from reading the README what
exactly you need to do in order to get going. At the very least you need
to build a new kernel with the right patches applied, and then make the
user-space components.
Good point! Fixing... :)


3. A lot of the info that's in the README should be in the INSTALL file.
The INSTALL file has good info, but is pretty much generic to running
./configure.
INSTALL file is generated by 'automake' automatically. We'd like put all
information in README. If you think it is an issue, we'll change some
installation-relative information into INSTALL.


4. To get the best exposure on the LKML, it would be better to also
provide instructions on how to make it work on the 2.5 kernel. I would
think that would be just a matter of getting the patches working on the
2.5 kernel. This could be any area where we ask for community help in
making it work on 2.5. This shouldn't stop us from announcing, but after
listening to Greg K-H yesterday and my past experience this is the
conclusion I come to.
We all have little experience in 2.5, but we'll try to merge our things into
2.5. Maybe we need some help from other kernel guys :) 


More comments to follow...stay tuned...

-RobR


On Thu, 2002-10-17 at 13:25, Rob Rhoads wrote:
> I'm attempting to download the source to FITH for building, but it
> appears that it is only available via checking out directly from CVS. It
> would be nice if you post a tarball of the source code to both the
> project web page and under the file section on the project page.
>
> Also make me a member of the project (my SF account errhoads), so I
> don't have to monkey around with trying to get anonymous :pserver to
> work around the our stupid corporate firewall.
>
> Thanks.
>
> --
> Rob Rhoads                     mailto:err...@li...
> Telecom Software Platforms     office: 503-677-5498
> Intel Communications Group
>
> <disclaimer value="pointless">
> This email message solely contains my own personal views,
> and not necessarily those of my employer.
> </disclaimer>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer




-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Zhuang, L. <lou...@in...>]

Thanks Rob for his push! :) 
We've made FITH conformable to Red hat 8.0. Now, it is conformable to ISO
C99, aclocal 1.6, autoconf 2.53, automake 1.6. But, kernel with Red hat 8.0
is not suitable for compiling and running FITH because DProbes and some
symbol exports are needed. The CGL precompiled kernel is most suitable for
that. :) http://builds.developer.osdl.org/index.php?ver=v1_0&type=stable

Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.

-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: Friday, October 18, 2002 7:39 AM
To: fau...@li...
Cc: ina...@in...
Subject: Re: [Fault-injection-developer] Couple of issues downloading and
building the FITH source code

Ran into a problem...

Since we are targeting any Linux kernel developer & not just developers
using CGLE, I tried to build FITH on my CoosBay (Intel P4 DP SMP box)
running RedHat 8.0.

After making sure that the appropriate shared libraries/packages were
installed (i.e. libdissasm, libxml2, etc.), I attempted to get the
./configure script built by running Makefile.cvs file. Below was error
output.

NOTE: When we get around to packaging up a source tarball, we need to
include ./configure script already built, so they can just run it and
then do a Make all.


[errhoads@fuente FITH]$ make -f Makefile.cvs
aclocal
autoconf
automake --add-missing
configure.in: installing `./install-sh'
configure.in: installing `./mkinstalldirs'
configure.in: installing `./missing'
man/Makefile.am:1: installing `man/texinfo.tex'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)'
: change your target to read `fith_dm.o$(EXEEXT)'
src/dm/Makefile.am: installing `./depcomp'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)'
: change your target to read `fith_fakeirq.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)'
: change your target to read `fith_clean$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)'
: change your target to read `fith_insmod$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)'
: change your target to read `mkfithdev$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)'
: change your target to read `fith_aslt.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)'
: change your target to read `fith_dbp.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)'
: change your target to read `fith_dr.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)'
: change your target to read `fith_ovr.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)'
: change your target to read `fith_pf.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)'
: change your target to read `fith_dm.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)'
: change your target to read `fith_fakeirq.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)'
: change your target to read `fith_clean$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)'
: change your target to read `fith_insmod$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)'
: change your target to read `mkfithdev$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)'
: change your target to read `fith_aslt.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)'
: change your target to read `fith_dbp.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)'
: change your target to read `fith_dr.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)'
: change your target to read `fith_ovr.o$(EXEEXT)'
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449.
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)'
: change your target to read `fith_pf.o$(EXEEXT)'
make: *** [all] Error 1

On Thu, 2002-10-17 at 15:17, Rob Rhoads wrote:
> OK, got the source, and I'm now going through the build steps and
> reading the documentation. In short, its way too TLT specific for a
> general announcement on the LKML.
>
> I haven't attempted to build it yet, but this is what I see so far that
> needs to be fixed before the project is announced (in any form) to the
> LKML:
>
> 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
> everything. The README file is full of TLT & carrierlinux 'isms. If this
> is going to be posted on LKML, the instructions and code had better work
> on a stock kernel by applying relevant kernel patches.
>
> If you rely on the TLT or CGLE kernel no one on the LKML, outside of
> OSDL developers, will take a second look at it.
>
> The instructions need to be written so anyone can take a stock kernel
> apply the relevant patches and make it work. For example, dprobes is
> required, but the instruction don't clearly state that you need to apply
> the patch to the stock kernel sources.
>
> 2. You need to break-out the required kernel patches from the user-space
> components. Separate source tarballs & separate instructions, might be
> one way to do it. Right now it's confusing from reading the README what
> exactly you need to do in order to get going. At the very least you need
> to build a new kernel with the right patches applied, and then make the
> user-space components.
>
> 3. A lot of the info that's in the README should be in the INSTALL file.
> The INSTALL file has good info, but is pretty much generic to running
> ./configure.
>
> 4. To get the best exposure on the LKML, it would be better to also
> provide instructions on how to make it work on the 2.5 kernel. I would
> think that would be just a matter of getting the patches working on the
> 2.5 kernel. This could be any area where we ask for community help in
> making it work on 2.5. This shouldn't stop us from announcing, but after
> listening to Greg K-H yesterday and my past experience this is the
> conclusion I come to.
>
> More comments to follow...stay tuned...
>
> -RobR
>
>
> On Thu, 2002-10-17 at 13:25, Rob Rhoads wrote:
> > I'm attempting to download the source to FITH for building, but it
> > appears that it is only available via checking out directly from CVS. It
> > would be nice if you post a tarball of the source code to both the
> > project web page and under the file section on the project page.
> >
> > Also make me a member of the project (my SF account errhoads), so I
> > don't have to monkey around with trying to get anonymous :pserver to
> > work around the our stupid corporate firewall.
> >
> > Thanks.
> >
> > --
> > Rob Rhoads                     mailto:err...@li...
> > Telecom Software Platforms     office: 503-677-5498
> > Intel Communications Group
> >
> > <disclaimer value="pointless">
> > This email message solely contains my own personal views,
> > and not necessarily those of my employer.
> > </disclaimer>
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: viaVerio will pay you up to
> > $1,000 for every account that you consolidate with us.
> > http://ad.doubleclick.net/clk;4749864;7604308;v?
> > http://www.viaverio.com/consolidator/osdn.cfm
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer



-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Lynch, R. <rus...@in...>]

Yea, I see the same problem when I attempt to build from a RH 8.0 system.
The newer version of autoconf/automake seems to have turned off some legacy
options.

	-rusty

-----Original Message-----
From: Rob Rhoads [mailto:err...@li...]
Sent: Thursday, October 17, 2002 4:39 PM
To: fau...@li...
Cc: ina...@in...
Subject: Re: [Fault-injection-developer] Couple of issues downloading
and building the FITH source code


Ran into a problem... 

Since we are targeting any Linux kernel developer & not just developers
using CGLE, I tried to build FITH on my CoosBay (Intel P4 DP SMP box)
running RedHat 8.0. 

After making sure that the appropriate shared libraries/packages were
installed (i.e. libdissasm, libxml2, etc.), I attempted to get the
./configure script built by running Makefile.cvs file. Below was error
output. 

NOTE: When we get around to packaging up a source tarball, we need to
include ./configure script already built, so they can just run it and
then do a Make all. 


[errhoads@fuente FITH]$ make -f Makefile.cvs 
aclocal 
autoconf 
automake --add-missing 
configure.in: installing `./install-sh' 
configure.in: installing `./mkinstalldirs' 
configure.in: installing `./missing' 
man/Makefile.am:1: installing `man/texinfo.tex' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)' 
: change your target to read `fith_dm.o$(EXEEXT)' 
src/dm/Makefile.am: installing `./depcomp' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)' 
: change your target to read `fith_fakeirq.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)' 
: change your target to read `fith_clean$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)' 
: change your target to read `fith_insmod$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)' 
: change your target to read `mkfithdev$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)' 
: change your target to read `fith_aslt.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)' 
: change your target to read `fith_dbp.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)' 
: change your target to read `fith_dr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)' 
: change your target to read `fith_ovr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)' 
: change your target to read `fith_pf.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)' 
: change your target to read `fith_dm.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)' 
: change your target to read `fith_fakeirq.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)' 
: change your target to read `fith_clean$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)' 
: change your target to read `fith_insmod$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)' 
: change your target to read `mkfithdev$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)' 
: change your target to read `fith_aslt.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)' 
: change your target to read `fith_dbp.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)' 
: change your target to read `fith_dr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)' 
: change your target to read `fith_ovr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)' 
: change your target to read `fith_pf.o$(EXEEXT)' 
make: *** [all] Error 1 

On Thu, 2002-10-17 at 15:17, Rob Rhoads wrote:
> OK, got the source, and I'm now going through the build steps and
> reading the documentation. In short, its way too TLT specific for a
> general announcement on the LKML.
> 
> I haven't attempted to build it yet, but this is what I see so far that
> needs to be fixed before the project is announced (in any form) to the
> LKML:
> 
> 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
> everything. The README file is full of TLT & carrierlinux 'isms. If this
> is going to be posted on LKML, the instructions and code had better work
> on a stock kernel by applying relevant kernel patches. 
> 
> If you rely on the TLT or CGLE kernel no one on the LKML, outside of
> OSDL developers, will take a second look at it.
> 
> The instructions need to be written so anyone can take a stock kernel
> apply the relevant patches and make it work. For example, dprobes is
> required, but the instruction don't clearly state that you need to apply
> the patch to the stock kernel sources.
> 
> 2. You need to break-out the required kernel patches from the user-space
> components. Separate source tarballs & separate instructions, might be
> one way to do it. Right now it's confusing from reading the README what
> exactly you need to do in order to get going. At the very least you need
> to build a new kernel with the right patches applied, and then make the
> user-space components.
> 
> 3. A lot of the info that's in the README should be in the INSTALL file.
> The INSTALL file has good info, but is pretty much generic to running
> ./configure.
> 
> 4. To get the best exposure on the LKML, it would be better to also
> provide instructions on how to make it work on the 2.5 kernel. I would
> think that would be just a matter of getting the patches working on the
> 2.5 kernel. This could be any area where we ask for community help in
> making it work on 2.5. This shouldn't stop us from announcing, but after
> listening to Greg K-H yesterday and my past experience this is the
> conclusion I come to.
> 
> More comments to follow...stay tuned...
> 
> -RobR
> 
> 
> On Thu, 2002-10-17 at 13:25, Rob Rhoads wrote:
> > I'm attempting to download the source to FITH for building, but it
> > appears that it is only available via checking out directly from CVS. It
> > would be nice if you post a tarball of the source code to both the
> > project web page and under the file section on the project page.
> > 
> > Also make me a member of the project (my SF account errhoads), so I
> > don't have to monkey around with trying to get anonymous :pserver to
> > work around the our stupid corporate firewall.
> > 
> > Thanks.
> > 
> > -- 
> > Rob Rhoads                     mailto:err...@li...
> > Telecom Software Platforms     office: 503-677-5498
> > Intel Communications Group
> > 
> > <disclaimer value="pointless">
> > This email message solely contains my own personal views, 
> > and not necessarily those of my employer.
> > </disclaimer>
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: viaVerio will pay you up to
> > $1,000 for every account that you consolidate with us.
> > http://ad.doubleclick.net/clk;4749864;7604308;v?
> > http://www.viaverio.com/consolidator/osdn.cfm
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer



-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

Re: [Fault-injection-developer] Couple of issues downloading and building the FITH source code

[Rob R. <err...@li...>]

Ran into a problem... 

Since we are targeting any Linux kernel developer & not just developers
using CGLE, I tried to build FITH on my CoosBay (Intel P4 DP SMP box)
running RedHat 8.0. 

After making sure that the appropriate shared libraries/packages were
installed (i.e. libdissasm, libxml2, etc.), I attempted to get the
./configure script built by running Makefile.cvs file. Below was error
output. 

NOTE: When we get around to packaging up a source tarball, we need to
include ./configure script already built, so they can just run it and
then do a Make all. 


[errhoads@fuente FITH]$ make -f Makefile.cvs 
aclocal 
autoconf 
automake --add-missing 
configure.in: installing `./install-sh' 
configure.in: installing `./mkinstalldirs' 
configure.in: installing `./missing' 
man/Makefile.am:1: installing `man/texinfo.tex' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)' 
: change your target to read `fith_dm.o$(EXEEXT)' 
src/dm/Makefile.am: installing `./depcomp' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)' 
: change your target to read `fith_fakeirq.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)' 
: change your target to read `fith_clean$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)' 
: change your target to read `fith_insmod$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)' 
: change your target to read `mkfithdev$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)' 
: change your target to read `fith_aslt.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)' 
: change your target to read `fith_dbp.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)' 
: change your target to read `fith_dr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)' 
: change your target to read `fith_ovr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)' 
: change your target to read `fith_pf.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dm.o' overrides `fith_dm.o$(EXEEXT)' 
: change your target to read `fith_dm.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_fakeirq.o' overrides
`fith_fakeirq.o$(EXEEXT)' 
: change your target to read `fith_fakeirq.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_clean' overrides `fith_clean$(EXEEXT)' 
: change your target to read `fith_clean$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_insmod' overrides `fith_insmod$(EXEEXT)' 
: change your target to read `fith_insmod$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `mkfithdev' overrides `mkfithdev$(EXEEXT)' 
: change your target to read `mkfithdev$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_aslt.o' overrides `fith_aslt.o$(EXEEXT)' 
: change your target to read `fith_aslt.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dbp.o' overrides `fith_dbp.o$(EXEEXT)' 
: change your target to read `fith_dbp.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_dr.o' overrides `fith_dr.o$(EXEEXT)' 
: change your target to read `fith_dr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_ovr.o' overrides `fith_ovr.o$(EXEEXT)' 
: change your target to read `fith_ovr.o$(EXEEXT)' 
Use of uninitialized value in concatenation (.) or string at
/usr/bin/automake line 8449. 
: deprecated feature: `fith_pf.o' overrides `fith_pf.o$(EXEEXT)' 
: change your target to read `fith_pf.o$(EXEEXT)' 
make: *** [all] Error 1 

On Thu, 2002-10-17 at 15:17, Rob Rhoads wrote:
> OK, got the source, and I'm now going through the build steps and
> reading the documentation. In short, its way too TLT specific for a
> general announcement on the LKML.
> 
> I haven't attempted to build it yet, but this is what I see so far that
> needs to be fixed before the project is announced (in any form) to the
> LKML:
> 
> 1. Remove all mention & dependencies on TLT, carrierlinux, etc. from
> everything. The README file is full of TLT & carrierlinux 'isms. If this
> is going to be posted on LKML, the instructions and code had better work
> on a stock kernel by applying relevant kernel patches. 
> 
> If you rely on the TLT or CGLE kernel no one on the LKML, outside of
> OSDL developers, will take a second look at it.
> 
> The instructions need to be written so anyone can take a stock kernel
> apply the relevant patches and make it work. For example, dprobes is
> required, but the instruction don't clearly state that you need to apply
> the patch to the stock kernel sources.
> 
> 2. You need to break-out the required kernel patches from the user-space
> components. Separate source tarballs & separate instructions, might be
> one way to do it. Right now it's confusing from reading the README what
> exactly you need to do in order to get going. At the very least you need
> to build a new kernel with the right patches applied, and then make the
> user-space components.
> 
> 3. A lot of the info that's in the README should be in the INSTALL file.
> The INSTALL file has good info, but is pretty much generic to running
> ./configure.
> 
> 4. To get the best exposure on the LKML, it would be better to also
> provide instructions on how to make it work on the 2.5 kernel. I would
> think that would be just a matter of getting the patches working on the
> 2.5 kernel. This could be any area where we ask for community help in
> making it work on 2.5. This shouldn't stop us from announcing, but after
> listening to Greg K-H yesterday and my past experience this is the
> conclusion I come to.
> 
> More comments to follow...stay tuned...
> 
> -RobR
> 
> 
> On Thu, 2002-10-17 at 13:25, Rob Rhoads wrote:
> > I'm attempting to download the source to FITH for building, but it
> > appears that it is only available via checking out directly from CVS. It
> > would be nice if you post a tarball of the source code to both the
> > project web page and under the file section on the project page.
> > 
> > Also make me a member of the project (my SF account errhoads), so I
> > don't have to monkey around with trying to get anonymous :pserver to
> > work around the our stupid corporate firewall.
> > 
> > Thanks.
> > 
> > -- 
> > Rob Rhoads                     mailto:err...@li...
> > Telecom Software Platforms     office: 503-677-5498
> > Intel Communications Group
> > 
> > <disclaimer value="pointless">
> > This email message solely contains my own personal views, 
> > and not necessarily those of my employer.
> > </disclaimer>
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: viaVerio will pay you up to
> > $1,000 for every account that you consolidate with us.
> > http://ad.doubleclick.net/clk;4749864;7604308;v?
> > http://www.viaverio.com/consolidator/osdn.cfm
> > _______________________________________________
> > Fault-injection-developer mailing list
> > Fau...@li...
> > https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer