Peter Memishian wrote:
> FYI, placing the binaries in /ws/onnv-gate/public will be our first
> goal, after that we want to integrate the source code in to ON, and
> there are great chances it would be under usr/src not usr/closed. And we
> have the plan to release warlock into opensolaris to bring more
> features. It's maybe just a matter of time.
I'm confused about the last part. I thought (as per earlier parts of this
thread) and lock_lint and warlock are closely related -- so why would we
want to develop new features for warlock? It would make more sense to me
to focus on converging lock_lint and warlock before adding new features.
The main difference between lock_lint and warlock is that warlock (actually
wlanalyze which warlock calls and does the main job) has a command line
interface which can be used to accept a command file (.wlcmd files in
ON source tree). This is because warlock is written as a shell script but
lock_lint is written in C. And this command line interface is critical
to ON.
If we want lock_lint to provide the same interface, the design is very weird
and ugly. I think Alexander has already mentioned that.
So converting lock_lint to support warlock features is not a very good idea.
I hope we can add more features into warlock so that warlock could also do
what lock_lint does, and further what lock_lint does not. Remember warlock
is not just for kernel and there are no known lock_lint users today.
I know lock_lint is made a product of Sun, and if we make warlock capable of
what lock_lint can do there is maybe duplicated work. Do you have any good
idea and suggestions?
Aaron
_______________________________________________
tools-discuss mailing list
[email protected]
