Re: [Linux-diag-devel] RE: How to describe what data a given diag nostic test expects

[Daniel E. F. S. <dst...@us...>]

On Thursday 07 March 2002 06:10 pm, Lynch, Rusty wrote:
> Ok, I see a couple of topics here:
>
> 1. Do we really have to support arbitrary data structures passed to
> diagnostic functions
> 2. How much information does a device driver really have to surface in
> order for a user space component to implement a CIM provider that supplies
> the CDM classes (i.e. represent a diagnostic test as a CIM_DiagnosticTest
> object with settings passed to it as a CIM_DiagnosticSetting object and
> results delivered as a CIM_DiagnosticsResult object)
>
>
> For #1:
> Life would be a lot easier if we could specify exactly what configuration
> information is needed for all diagnostic tests.  So that any driver would
> provide a sub set of std_test1, std_test2, std_test3.  I am just worried
> that it would be impractical to define a sufficient set of standard test
> for the large array of devices out there.
>
> I'm kind of thinking out loud here because I'm not completely sold on
> either approach.  One could argue that any diagnostic test that really
> needs a wide range of parameters (like a dependency tree of subnodes to
> ping on some kind of fibre switch) could be implemented in user space with
> the aid of standardized device diagnostics.


We envisioned diagnostics or self tests in drivers to be mostly hidden from 
User Space. We don't really care what the implementation is so long as it 
tests the device and returns lots of information useful for debugging. 
Basically, we could run -> diag_run_test with some common parameters and have 
the device driver do what ever it does and return to us a successful return 
code or error codes with detailed information. Specific knowledge of the 
device belongs in the device drivers and not spread out in User Space 
applications and management software. 

Different tests could be implemented by the device drivers. The tests could 
depend on thoroughness and invasiveness to normal processing. All we would 
need to do is specify the level of diagnostic to be run.  

The processing to make sense of the returned information would be in User 
Space along with all the stuff necessary to work with CDM/CIM. The idea is to 
keep the device drivers as specific to the device with as little extra stuff 
as necessary. Is this an oversimplification? 

Perhaps it would be better if we analyzed what exactly device drivers will 
implement - especially for the five targeted drivers for carrier space. Could 
the maintainers create diagnostics to a standard model? Are they willing to 
write diagnostics in the first place? Are they willing to use a MOF file? 



> For #2:
> I agree that there are several simplifications you could make for driver
> level diagnostics.  The driver just needs to provide the minimum amount of
> information to allow a user space component so represent the diagnostic
> test in a CDM implementation.
>
> I think you can add the ResourcesUsed attribute to the list proposed below.
> The driver doesn't have to provide an unint16 array like the CIM
> specification says.  We could just specific a bits in a bitmap and then the
> user space component that translates  all of this to CDM could supply an
> unint16 array in the associated CIM_DiagnosticTest object.


This was our approach and we feel this is a good strategy. Otherwise, we're 
asking too much of device drivers and making drivers that much more 
complicated. 



>
>
> 	-rusty
>
>
>
> -----Original Message-----
> From: david oleszkiewicz [mailto:da...@us...]
> Sent: Thursday, March 07, 2002 4:29 PM
> To: lin...@li...
> Subject: Re: [Linux-diag-devel] RE: How to describe what data a given
> diagnostic test expects
>
>
> As i am beginning to read the CIM/CDM class definitions i am
> beginning to think that we may need to spend some time defining a barrier
> between what should be done in user space and kernel space.
>
> For instance, handling percent of coverage and completion would seem to
> apply more for user space diagnostics (as their example of a partial disk
> scan).  Off the top of my head, i cannot devise any similar circumstances
> where a diagnostic at the driver level would deal with percent completion.
> I
> would guess that driver level diagnostics would concentrate on consistency
> checks or device error register checks rather than any sort of repetitive
> stressing.
>
> CIM/CDM defines (among other) these named characteristics of a diagnostic
> test:
>      is_exclusive
>      is_interactive
>      is_destructive
>      is_risky
>      is_package
>      support_percentage_of_coverage
>      in_use
>
> A diagnostic located within a device driver could probably get away
> with only defining these characteristics: is_exclusive, is_interactive,
> in_use.  For a driver level diagnostic, percent completion can
> be forged by user level diagnostic instrumentation for the satisfaction of
> CIM...if the test hasn't completed, it's 0% complete.
>
> likewise, if a driver declared that it handles diagnostic tests (of it's
> own naming) A, B and C, a user space application could implement the
> run_diag_test CDM fnx calling the appropriate test based on a settings
> struct (the CIM is all done in user space).  Here the device driver would
> only need to announce that it supports these arbitrarily named diagnostic
> functions.  This might be too little structure though.  I kind of _do_
> like the diagnostics calls into the kernel all going though one place.
> </rambling>
>
> So my answer to rusty would be that we can keep the diagnostic
> descriptions in both kernel and user space.  We should have a diagnostic
> scheme that works reasonably well with out CIM, yet still keep in mind that
> we want to extend it with CIM/CDM.
>
> On Thu, 7 Mar 2002, Dan Stekloff wrote:
> > I have two questions:
> >
> > 1. Why must we support arbitrary settings for running diagnostics or self
> > tests in device drivers? Why can't we outline a set of settings that
> > device drivers will use such as diag level, logging level, etc? If its
> > purpose is to outline arbitrary tests implemented by the device driver,
> > why must those tests be arbitrary? Why not outline a set of tests to be
> > implemented or a set method of calling different tests?
> >
> >
> > 2. Are you set on pushing CDM into device driver implementations?
> > Couldn't we create User Space providers/objects/wrappers to handle
> > communicating with CIM structures?
> >
> >
> > Just curious.
> >
> >
> > Regards,
> >
> > Dan
> >
> > _______________________________________________
> > Linux-diag-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-diag-devel