[sane-devel] As instructed by /etc/udev/rules.d/libsane.rules

[Johannes Meixner]

Hello,

On Nov 18 13:35 Richard Ryniker wrote (shortened):
> The syscall interface is how applications request kernel services.
> It is not a general mechanism for the kernel to start userspace
> applications.

I did not mean only the particular "syscall interface".

I mean the general idea behind what Greg K-H wrote in
http://www.kroah.com/log/linux/stable_api_nonsense.html

As far as I understand Greg K-H the general idea behind
is that on the one hand kernel internal stuff must be
intentionally unstable to allow kernel development
and is therefore not meant to be used by userspace
but accordingly on the other hand the kernel provides
for userspace an interface which is _very_ stable
over time and will not break.

If I understand the general idea behind correctly,
I fully agree with what Greg K-H wrote because I think
that in gerneral it is the same for any piece of software:

Internal stuff for whatefer piece of software is not
meant and must not be used by whatever "outer stuff"
regardless if this "outer stuff" is other software
which may call a library function or a user which
uses the piece of software.

If any piece of software should be used by whatever
"outer stuff", the piece of software must provide
a stable interface.

Here "interface" does also not only mean an API.
With "interface" I mean anything which is needed to
use the piece of software like API plus the allowed values
for the API function calls, command line programs
plus its options and the allowed option values,
config file syntax plus the allowed values therein,
and so on and so on...

Therefore also udev must provide such kind of
stable interface to be a useful piece of software.

For example udev may declare its rules files as
internal stuff and provide stable command line tools
how to view/add/modify/remove entries therein.

Such a tool could additionally even test if the whole
set of udev rules which actually exits currently
on a particular system "makes sense" - for example
it could show warning messages when the same LABEL
is used in different udev rules files.

With a tool to view/add/modify/remove udev rules,
udev could declare the actual rules as internal stuff
and demand that only this tool is allowed to
view/add/modify/remove udev rules and then udev
could change how udev rules are stored as it likes.
Perhaps storing the udev rules in files is not the best
solution to notice changes during runtime therein? ;-)

Compare
https://bugzilla.novell.com/show_bug.cgi?id=438867#c54

If there was a stable udev command line tool
to add udev rules, I would simply call this tool
with a list of known USB scanner USB IDs.

If there was a stable udev command line tool,
there would be of course a kernel version dependency
for udev because its tool must write the right values
for its rules but this is one single point of maintenance
at a much better place because udev is (at least from my
point of view) kernel related software.

In contrast the current totally unmaintainable mess is
that each end-user application like SANE, IScan, HPLIP,...
(which should really be kernel independent software
  perhaps except major kernel version changes at the most)
has an unexpected implicite kernel minor version dependency.

If the udev authors/maintainers like to have even udev to be
kernel independent software, the kernel itself would have
to provide whatever kind of stable interface so that udev
can use the kernel in a kernel-version-independent way.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex