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
