Gary Winiger wrote: >>> So why are both "class" and "xdpy" required? How should xdpy >>> be used? >>> >>> >> The output of list devices is consumed by the CDE and JDS device >> allocation tools. This has been the design for over 10 years. The output >> is in the form of key=value lists, and is parseable. >> > > Exactly my point. In the original case 2005/691 and in this > case and in my conversations in pre-review, the output from > list_devices is NOT a programming interface. It was previously > ARCed as Unstable. It is stable, but extensible. I think that may have been the source of confusion. > That was clarified here to be Not-An-Interface. > I find no contracts in 2005/691 for any consumers, nor options > on the man page for a format of output that is an interface. > Nor documentation of what that output might be. Indeed when I > talked with the project team (long before the last minute addition > of xdpy), I explicitly asked how the output was consumed. IIRC, > the answer was it was displayed verbatim to the user who then > choose what to do.
Sorry, that was a mistake. The user in TX cannot directly run or observe any of these commands. The only user interface is the GUI. The GUI is the consumer. > And I suggested a possible stable form of > output in XML, with a new option "-x." > > The project cannot have it both ways. Not-An-Interface != Committed > The output of list_devices is an interface which is parsable. It contains a set of key-value pairs which is extensible. For example, here is the output of the entry for the console audio device, which has been allocated by me in the public zone. device=audio0;type=audio;auths=solaris.device.allocate;clean=/etc/security/lib/audio_clean_wrapper;minlabel=admin_low:maxlabel=admin_high;zone=public:owner=11115;files=/dev/audio /dev/audioctl:xdpy=0 The output of list_devices was changed to be parsable in TSOL 7. This case is partly about specifying what the interfaces are, but the actual architecture (especially the CDE code) has not changed in 10 years. Prior to that the GUIs contained a copy of most of the source code of the allocate command (the file allocate3.c). > >> The xdpy value is the display number corresponding to the specific X >> server associated with the logged in user. Each user, whether on the >> console or a Sun Ray appliance, has his own X server with a unique port >> > > I got that. That's clear. What wasn't clear is how xdpy was > to be used. There is no stable interface to consume it, thus > it had to be used only internally to allocate/deallocate/list_devices. > And that didn't make sense. > The implementation of the device_allocate file is extensible, like the RBAC databases. The list_devices command will simply display all the keywords in the file. The GUI's parse the output to generate the UI components. > >>> This seems different from "zone," which I can intuit being used >>> for internal bookkeeping in allocate/deallocate to identify the >>> labeled zone where the allocated device nodes reside. >>> >>> >> It is not related to zone. Remember that in a given zone there could be >> a hundred Sun Ray users, each with their own xdpy value. >> > > That's what I was trying to say "zone" was used internally for > bookkeeping and allocate/deallocate/list_devices filtering. > There is no proposed equivalent to "-c" (class) or "-z" (zonename) > to filter on "xdpy". > zone is one of the keywords output by list_devices. It is interpreted by the GUI, which looks up the label of the device and displays it. > It seems like there are missing interfaces one way or another. > More filter options, or stable parsable output options for > list_devices seem the alternatives. > Yes, the output of list_devices is stable in that it consists of key=value pairs separated by colons. The keys are extensible. > I'm not trying to design on the fly here. The design's up to > the project team. > The design was completed long ago, but the interfaces have not been properly conveyed to PSARC. --Glenn
