Brad Chapman writes:
> --- Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > Brad Chapman writes:
> > > I'm trying to create a sort of tracing system where you can
> > > specify a mask on the command line (or a simple integer) and get a
> > > vareity of traced information about what devfsd is doing. The stuff
> > > I printed above was just an example of an incremental trace level
> > > system.
> >
> > It's making things more complex than I'm happy with. I don't want the
> > code riddled with more debugging output.
>
> Why not? Having a view into the inner workings of devfsd
> without having to read the code itself would be helpful.
Because it will bloat the code. A lot. We don't do that in the kernel
either. Critical system components should be compact and efficient.
That means there can't be lots of debugging code.
[...]
> In the short time I've been following this list, I've noticed
> your reluctance to include things which you believe would make
> devfsd bloated, difficult to use, and could possibly break devfsd
> horribly (and make work for yourself cleaning the mess
> up). Therefore I'm proposing this: Create a newexperimental devfsd
> tree which acts as a testing ground for wild devfsd ideas.
>
> With this tree, you can continue to be maintainer, or have
> someone else do it (one name that comes to mind is Russell
> Coker). The maintainer of the new tree would accept almost
> _anything_, put it in the experimental tree, and allow people to
> test it. If it explodes, then it's backed out and the submittor of
> the patch tries again. If it works and is cool enough, then it gets
> pushed to you for consideration.
>
> Do you think this is a good idea? It seems to work for the
> kernel......
That's only of use if those "wild ideas" might eventually be accepted
into the mainline. Further, it's a lot more work (eventual merging of
the two codebases is a lot of work) for a project that, in the scheme
of things, isn't anywhere near big or as important as the kernel.
There isn't the need for that level of experimentation.
Remember, Linux is Unix. If you want to fiddle with things at a low
level, you need to be prepared to get your hands dirty. That means
being prepared to read the source code. No amount of debugging
information will ever displace the need to read the code. And if you
can read the code, you can trivially insert a custom debugging
statement.
BTW: you might want to remove your netscape address from your
signature. The mailing list anti-spam filters treat it as a forbidden
keyword and dump the messages (I didn't set it up, but that's how the
oss lists are done).
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|