Mailinglist Archive: yast-devel (129 mails)

< Previous Next >
Re: [yast-devel] SCR usage statistics.
  • From: Jiri Srain <jsrain@xxxxxxx>
  • Date: Fri, 16 Nov 2007 11:07:36 +0100
  • Message-id: <200711161107.41063.jsrain@xxxxxxx>
Dne Thursday 15 of November 2007 18:35:23 Klaus Kaempf napsal(a):
* Michal Svec <msvec@xxxxxxx> [Nov 15. 2007 18:05]:
On Thu, 15 Nov 2007, Klaus Kaempf wrote:
I scanned all files below /usr/share/YaST2/{modules,clients,include}
grepping for "SCR::". Just to get statistical relevant data, not for
complete coverage.

The goal is to get relevant data for a SCR redesign to be implemented
in parallel to the current SCR and have modules converted over time
and shut down SCR is some distant future.

May be a dumb question, but which problems are we trying to fix?

I see sevaral problems

- Code cleanup / refactoring
SCR is not fully understood by developers (coding all kinds of
workarounds) and incomplete in some regards (developers parsing files
in ycp). This should be fixed.

- No / Inconsistent modeling
The pathes and data structures used in SCR effectively define a model.
There is no clear documentation nor consistency in this model. Should
we make the SCR model consistent or pick up an existing one (i.e. HAL
for hardware probing or CIM for everything)

- Reuse of existing code
For historical reasons (non-GPL license of YaST), SCR agents don't use
existing implementations for instrumentation. For Code11, we have the
requirement of 'friendly coexistance' with CIM instrumentation. A
resonable combination would be to replace agents with existing CIM
provider code.

- Separation of rights
Security and 'role based' considerations recommend to separate the
controller code (WFM in YaST) from the backend (SCR in YaST). The
controller code should run without root rights, the backend code should
assume root rights on demand (i.e. rpm -qa does not need root). This
requires a redesign of the SCR backend.

Also, are you suggesting a completely different SCR(-like) approach
or just "fixed" and more unified paths?

Thats what I'm trying to find out and get more input from developers.

The current thinking is to implement a completely different approach
while keeping the current SCR in place and migrate modules one-by-one.

This is something which we already tried with LiMaL. The actual result is that
we have two "standard" ways to access system.

If we decide for any new approach, we should decide for an existing standard.
With the requirement for code reuse, CIM seems to me to be the way to go
provided we get reasonably over the coding overhead.



Jiri Srain
YaST Team Leader
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxx
Lihovarska 1060/12 tel: +420 284 028 959
190 00 Praha 9 fax: +420 284 028 951
Czech Republic
< Previous Next >