On Wednesday, 10/12/2005 at 07:01 CET, Alan Cox <[EMAIL PROTECTED]> wrote: > Which basically is the same as generic DIAG, the only difference being > that you are wrapping it in something. The more I follow this thread the > more generic diag seems right, even if it has a bitmask of "not > supported" diags that have "hard" features and a kernel side > table/function handlers for hard cases that people can contribute > updates to when they need a specific interface.
Though this whole discussion, a few things have become obvious: - Linux needs access to some more native VM functions (diagnose, IUCV, VMCF, ...) - Some of these services have persistent state, some don't. - Some have inputs, some don't (i.e. read only). - Some have extremely complex inputs, most don't. - Some of these functions have already been provided, but are hidden under rocks in the /proc file system or in other zSeries-specific Linux commands (Did you know the output of diag 0 is already available in cpuinfo or some such?) - IBM hasn't done a very good job of telling VM-oriented Linux application developers about the aforementioned rocks. Delivering function without doc is not good. - Programs and scripts have different requirements (file descriptors vs. commands), so diags that might be useful in a script should come with userspace commands. - People have different philosophical views of how these services should be surfaced. - The diagnose instructions do not all have to surfaced as "diagnose" instructions. Consistency isn't important; integration into the Linux application model is. - The process of upstreaming should eliminate most Bad Ideas. - It's ok for CMS and Linux to do things differently; they have different pedigrees. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
