Re: [Ndiswrapper-general] rfc - perl script to eat large chunks of logfiles

[Pavel R. <pr...@gn...>]

Hello!

On Thu, 2006-04-27 at 12:45 -0400, Giridhar Pemmasani wrote:
> On Thu, 27 Apr 2006 11:56:52 -0400, Jim Cromie <jim...@gm...> said:
> 
>   Jim> heres the beginnings of a script that eats ndiswrapper logs for
>   Jim> lunch.
> 
> I am not sure if this is useful. I would prefer to see full log (the
> bigger log, the better). Moreover, each log tends to be unique, so it
> is difficult to decide which parts are not interesting with a script.
> At the least, the effort in getting something that _may be_ useful
> would be too much to justify.

Being a driver maintainer myself, I agree fully.  When you give too many
tools to the users, they become confused, and you don't get the
information you need.

But while on the topic of the log reduction, remember a patch I posted
to initialize values passed to the drivers by reference?  I think it's a
good idea, it would reduce the size of the logs, and it would reduce the
difference between logs.

We are not dealing with the hardware where saving a couple of CPU cycles
would matter.  But we are dealing with potentially buggy software.
Providing controlled (to a certain degree) environment for the Windows
drivers would make ndiswrapper more predictable, and it would reduce the
amount of irrelevant data in the logs.

>   Jim> PS; If you outline what you want wrt ini-file parsing, I can
>   Jim> take a swing at integrating one from CPAN, likely a pretty
>   Jim> solid/robust implementation.
> 
> This certainly would be helpful. 

In particular, it would be nice to split, trim and remove quotes in one
operation, so that spaces and commas inside the quotes are preserved.
If I had to write it correctly, I would probably use a state machine,
like a C programmer would.  I hope Perl gurus already came up with
something more readable and reliable.

And by the way, error handling in the ndiswrapper script needs serious
rework.  ndiswrapper shouldn't install a driver if it's considered
invalid.

-- 
Regards,
Pavel Roskin